[FFmpeg-user] Inaccurate trimming with re-encoding

thljcl jiachielee at live.com
Tue Aug 6 20:11:03 CEST 2013

thljcl wrote
> In H.264, or any other codecs, there is a compression technique called
> inter-frame compression. Because of inter-frame compression, typically you
> cannot cut H.264 video stream based on frame numbers without round-off
> error. You’re right, round-off error ‘usually’ resulted in inaccurate
> trimming; instead of cutting at exactly the frame number you specified,
> what you got was usually with round-off error. In fact, that’s exactly
> what happened if you use mkvtoolnix directly to cut the video into pieces.
> However, the method I described in the slideshow did not have such issue.
> The round-off error problem was put away because of the constant frame
> rate of 1 FPS. No, it would not get to the nearest key frame; it would get
> to exactly the frame or ‘time’ you specified. If you think about it, it’s
> pretty much like how to extract all frames (no matter whether or not they
> are key frames) to individual images; to be in more details, it actually
> involves both decoding and encoding process.
> The typical lossy encoding process would result in the loss of quality.
> Strictly speaking, it’s not possible for absolutely accurate trimming to
> happen without re-encoding process for the source with inter-frame
> compression. However, what really happens here is can be thought to be
> “lossless encoding”; but it’s not to create a video file of “lossless
> compression” but just cut a portion of video out. As you may already know
> -codec “copy” is to instruct the encoder the copy the stream without
> re-encoding. But you can also say re-encoding is also happening; it’s just
> that no change of information would occur in direct stream copying. To be
> more specific, you just copy a single frame from the H.264 source; if that
> happens to be non-key frame from the source, it would be the key frame for
> the output file; but this is strictly stream-copying process, thus no
> mathematical loss of information would occur in this process; it’s copying
> data from multiple frames from the source to be a single key frame in the
> output file.

While I use mkvtoolnix to manipulate the MKV container, if you like your
video/audio track to be stored in other containers, if you use the -codec
“copy” to do that; that’s subject to limitation of the containers; other
containers may not have supported the as many codecs as MKV does. Not only
the video/audio streams would be copied, the stored container information
would be copied as well, subject to the container’s limitation. If not, as I
said earlier, the output file cannot be played correctly because h.264
elementary stream does not store frame rate information.

View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Inaccurate-trimming-with-re-encoding-tp4660437p4660529.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.

More information about the ffmpeg-user mailing list