4

I am having trouble trimming video files without causing the Video/Audio to go out of sync. From what I understand, using the seek argument -ss before or after the input file results in two different behaviors. For Example: 

ffmpeg  -ss 00:00:00.600 -i in.mp4 -c copy out.mp4

This produces a trim with accurate A/V sync but a rough audio trim (trim happens at a video key frame and not the precise seek value) 

ffmpeg  -i in.mp4 -ss 00:00:00.600 -c copy out.mp4

This produces a more accurate audio trim but causes A/V to go out of sync. Frames after the trim position are dependent on frames before the trim position.These frames are assigned negative timestamps and copied to output file, which results in video being out of sync with audio during playback.

On the other hand,

ffmpeg  -i "in.mp4" -ss 00:00:00.600 -strict -2 out.mp4

This produces a more precise trimming and A/V sync. The trim task takes a long time to run and results in quality loss.

My Question is: Is there a way to get an accurate trim without re-encoding the video? maybe by discarding the extra frames at the beginning that cause the A/V to get out of sync. In my case, I can live with a few black frames in the beginning, as long as the audio is trimmed at the precise position and A/V sync is preserved. Is it possible to accomplish this using FFMPEG? if not, can MediaCodec on Android handle such precision when trimming?

Thanks for your time.

Wassim Erriha
  • 53
  • 1
  • 6
  • 1
    You see, most video codecs work by creating key frames at intervals throughout the video, with a dependency relationship that (generally) goes to the _left_. That is, if you "drop" a frame, all the frames to its right become undecodable, until you reach the next keyframe. You can't just replace them with black frames. – greeble31 Dec 23 '19 at 19:35
  • @ greeble31, thanks for pointing out the mistake in the post. I have edited the question to show the correct dependency relationship direction (right to left). – Wassim Erriha Dec 24 '19 at 15:52
  • @ greeble31, Some other post (I cant find the link to it) mentioned that some advanced players do use the frames with the negative timestamp for decoding but not for presentation; this way, the A/V stay in sync.What I meant by black frames in the beginning of the video is that; if there is a way to have ffmpeg not include the frames with the negative timestamp in the output, regular players might just play audio and video in sync with the first few frames being black frames since they would be missing the information they depend on during decoding. – Wassim Erriha Dec 24 '19 at 16:28
  • Don't know too much about ffmpeg or negative timestamp semantics, so I won't comment on that. Android's `MediaMuxer` will let you use whatever timestamps you want, but you'd have to write the code. And `MediaCodec` wouldn't come into play, unless you wanted to re-encode the first group-of-pictures (e.g. to snip the left edge off of it) -- then you could include the remaining frames unmodified, which Android can definitely do (at least for H.264 baseline, given certain constraints). – greeble31 Dec 24 '19 at 18:00

0 Answers0