[FFmpeg-user] Inaccurate trimming with re-encoding

[thljcl]

cmharwood89 wrote
> @thljcl,
> 
> Wow, thanks for putting together those slides! That looks like a very
> helpful solution. I see the value of changing to 1fps, because I could
> essentially use time as a dummy variable for frame number, but I don't
> understand how that would allow me to trim at non keyframes. 
> 
> From my (limited) understanding, there simply is no way to trim at a
> P-frame without decompressing into a raw format first, trimming at the
> shiny new keyframe, and then recompressing back into my desired. Right
> now, I'm having pretty good results doing it this way. If I change the
> framerate to 1fps, it's not going to redistribute keyframes, right? If I
> choose a cutting point, say at frame 300, but the nearest I-frame is at
> 295, then my output video will be trimmed at 5 frames/5 seconds from the
> desired cut-point. 
> 
> For reference, my input and desired output are:
> INPUT:
> h264 codec @59.94 fps, 1920x1080 res; AAC audio codec; MP4 container
> 
> OUTPUT
> h264 codec @59.94 fps, 1920x1080 res; NO AUDIO; AVI container
> 
> I want the output video to be encoded with no subjectively observable
> losses.  Computing time and disk space are not a concern, but video
> quality and accurate trimming are absolutely necessary.
> 
> My original problem has been solved (by removing the square brackets
> surrounding my millisecond count in the -ss argument), but I'm definitely
> interested in making my approach smarter- i.e. avoiding a brute-force
> complete encoding of the video. I like the speed and losslessness of
> container-only manipulation and cutting at keyframes, and I like the
> accuracy of a decompress-then-cut approach. My new challenge is finding a
> way to combine the two.

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 of
“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.



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