10

I convert videos using FFMPEG. My goal is to convert them to the MP4 container format (MPEG-4 Part 14) with AAC-encoded audio stream and MPEG-4 part 10-encoded video stream.

I use the following line to convert the videos:

ffmpeg -y -i "{inputFile}" "{outputFile}"

The converted video looks fine, however the duration of streams in the converted file and the input file doesn't always match.

I've made some experiments and the difference in the duration is undoubtedly there, however, it is not that much - anyway I'm testing with small videos. Here are my results:

| InputFile  | InputAudio | InputVideo | OutputAudio | OutputVideo  |
|------------|------------|------------|-------------|--------------|
| h.avi      | 3s 631ms   | 3s 567ms   | 3s 668ms    | 3s 567ms     |
| h.flv      | 3s 631ms   | 3s 558ms   | 3s 668ms    | 3s 567ms     |
| h.mov      | 3s 532ms   | 3s 533ms   | 3s 682ms    | 3s 534ms     |
| h.mp4      | 3s 605ms   | 3s 534ms   | 3s 682ms    | 3s 567ms     |
| h.mpg      | 3s 605ms   | 3s 533ms   | 3s 563ms    | 3s 534ms     |
| h.wmv      | 3s 620ms   | 3s 633ms   | 3s 659ms    | 3s 567ms     |

Since I would build a software on the top of FFMPEG, I would be happier if I could at least understand the reason of this difference. Is it because of some unnecessary transcoding?

In this case, can I turn this transcoding off to prevent FFMPEG to resample my input video file?

If I cannot turn it off, how can I be sure (besides testing) that this difference is not proportional to the size of the video?

If I convert for example a 10-hour video, a difference of multiple seconds or even minutes is not suitable for me.

Improve this question
3
  • 1
    I would think that it depends on your input and output codecs. Long GOP codecs might change the video stream duration in order to put key frames where they need be and close GOPs. You shouldn't face this issue when transcoding from intra codecs to intra codecs. If you don't need to reencode video, use the option 'c:v copy' if the target container supports this codec.
    – audionuma
    May 20, 2015 at 15:56
  • I expect the length differences won't get worse with longer videos. It's more likely a start/end issue, not a speed-drift or something. When I xcode stuff with ffmpeg, the number of frames, framerate, and length in seconds always stays the same. (unless I want it to change!).
    – Peter Cordes
    Jun 5, 2015 at 20:12
  • @audionuma: no sane codec will add/remove frames. mencoder sometimes does, because of a/v sync, BEFORE feeding frames to the video codec. A codec will put keyframes where it sees fit (fixed interval or at scenecuts), and when the encoder tells the codec that this is the last frame, it will close that last GOP, however long it is. Even with non-adaptive keyframe placement, no codec will add extra frames just to make the last GOP the same length!
    – Peter Cordes
    Jun 5, 2015 at 20:21

1 Answer 1

Reset to default
8

Hope this explanation is what you're looking for:

  • When you transcode to an encoding such as H.264 (MPEG-4 part 10) you necessarily also resample the video, that's part of H.264 compression technique. Nontheless, I doubt if this is the reason you experience a timing gap since the resampling doesn't necessarily influence the clock rate of the media. So, I wouldn't worry too much about resampling, it can cause some variance, but probably very marginal.

  • The container formats you listed are kinda irrelevant, because they define how the compressed stream is packaged, whereas the the source of the timing difference is the compression itself. The .flv file, for example, may contain a stream encoded by the legacy Flash Sorenson codec or the newer H.264. In the first case you would be transcoding the video stream, but in the latter it is possible the you're not - depending on the audio codec used. The .avi and .wmv containers are codec agnostic, so there's no way of even guessing their content's encoding.

  • You didn't mention how the duration was tested. Note that ffmpeg by default shows you the duration that appears in the file's metadata and not a computed value. If your list is based on the data that ffmpeg dumps as part of its splash notices then you should note that this is explicitly metadata and not an actual measured value.

  • The delta in the durations you presented are within the range of one or two frames in a 25 or 30 fps range. It is reasonable for codecs to pad-with or strip-from streams blank frames according to their algorithm (or developer's tidiness...). It shouldn't influence timestamping when you properly concatenate streams.

  • There are only two reasons I can think of that can substantially change your media's duration, neither applicable in your specific case:

    1. Re-encoding at a different target speed. Sometimes this happens unintentionally due to bad metadata in the input file. But not in your case, which, as noted above, correspond with a single frame dropped or gained.

    2. When you apply a codec that recreates either stream. Examples include ad-stripping, silence detection, noise cleansing, etc.

Bottom line, if you are concerned what's gonna happen with a 10-hour video - just run an actual test. If you run into trouble and seek assistance then keep in mind to post the input file's codec details and the method that you measured the stream duration.

Hope this helps.

Improve this answer
4
  • Actually, container format is probably relevant. Different containers store timestamps / frame durations differently. And length-calculators need different code for different container formats, and that code might behave differently. e.g. counting the duration the last frame is shown for in one, but not in another.
    – Peter Cordes
    Jun 5, 2015 at 20:14
  • @PeterCordes, what do you mean as "length" in you comment? If you wanted to mean "duration" then you are wrong, the duration is always the number of frames times the timebase. If you mean something else then please indicate what do you mean by "length".
    – avnr
    Jun 6, 2015 at 20:19
  • I meant duration. Not all video is constant-framerate. And the way frame durations are stored (as a fraction or whatever, usually multiples of a timebase) is different for different containers. This is kind of hand-wavy and making-stuff-up on my part, since I haven't looked at the details, but I'm pretty sure it's not as simple as we wish it was.
    – Peter Cordes
    Jun 7, 2015 at 21:47
  • @PeterCordes, okay, but this is so rare and doesn't really belong here, it is used only in some edge cases like screen recording, slideshows, etc. There is some misuse of the term Variable Frame Rate in editing software, but the more concise term in their case is hybrid video (that is, streams with different rates or time bases, retaining their original constant rates when muxed together). In the case of a "regular movie" there's almost always a known frame rate, regardless of how the container represents it in its metadata.
    – avnr
    Jun 8, 2015 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.