[FFmpeg-user] Towards better trims & concatenations

[Andrew Randrianasulu]

вт, 9 янв. 2024 г., 15:04 Rob Hallam <ffmpeg at roberthallam.com>:

> On Mon, 8 Jan 2024 at 23:02, Mark Filipak <markfilipak.imdb at gmail.com>
> wrote:
>
> > [explanation snipped]
> > Oh, I think I see why your difficulty, Rob.
>
> Thank you for taking the time to write the explanations, they are much
> appreciated.
>
> My difficulty, as you guessed, is I don't know about the internals of
> video containers.
>
> I thought it might work like being handed pages from a book- annoying
> if they're in the wrong order, but fixable to get the right order
> since there are page numbers. From what you say, it sounds like in
> this analogy not only are the pages (packets) in the wrong order, the
> page numbers (timestamps) are wrong- and not even consistently wrong?
>
> > Trimming errors are wrecking concatenations ...
> > [snip]
> > trimming has to take PTS into account so that the cut happens in the
> right spot with no leftover
> > packets that shouldn't be there, but that apparently isn't happening and
> I have the proof.
>
> That certainly sounds consistent with behaviour I saw in the past when
> I tried to re-join trimmed clips.
>
> > To be frank, Rob, if you want to help yourself, you may want to help me.
> I published my procedure.
> > Duplicate it and apply it to some of the videos you've had problems
> with. Learn how to use
> > '-framecrc' and '-showinfo'. It will take you awhile, but it will be
> time well spent. It will
> > demystify a lot for you. I'll be here to help if you like.
>
> Thank you. The videos I've worked with in the past were simple
> h264-in-mkv/mp4, but at the time having to do a full re-encode was
> irksome. If I get a chance to replicate your procedure I'll post the
> results.
>
> Regardless, good luck!
>


I looked again into "cut h264" (bluray stream often h264 encoded) video
situation and found this answer on avidemux forum (from 2020 so may be
ffmpeg end was fixed in meantime):

https://avidemux.org/smif/index.php?topic=19284.0

=====

In most H.264 and HEVC streams, each frame includes a counter in its header
which reflects the order in which the decoded picture should be displayed –
POC (picture order count). This counter is reset only on IDR (instant
decoder refresh) frames.

In a video stream with closed GOPs, each keyframe is an IDR frame and we
can cut at every keyframe not caring about POC. But in H.264 and HEVC
streams used for digital broadcast, the closed GOP mode is not viable
because of huge variability in bitrate between frames in this mode.
Therefore broadcasters use open GOP mode, where keyframes just mark a point
in the stream which can be directly accessed (technically it means that
parts of the picture which don't depend on other pictures to be decoded are
spread over a number of frames, reducing bitrate fluctuations).

When we cut at a non-IDR keyframe, we can run into the situation that the
POC of the next frame after the cut is (much) less than the POC of previous
frame. Here the trouble starts.

Some if not most decoder libraries and hardware players discard such a
sudden jump of POC and just carry on, so everything works fine. But the
most important library at the heart of most popular players and video
editors including Avidemux – libavcodec – actually evaluates the invalid
POC jump at the boundary of the cut and will not continue with playback
until a frame with POC higher than before the cut or an IDR frame arrives.

As we cannot command millions of people to stop using VLC, we need to avoid
triggering this problem by checking the POC values at the cut points.

The only other option is to re-encode the video.
====

other forum post hints at possibility of doing bitstream analysis for
re-creating some of missing info on cutting, but does not go into details:

https://forum.videohelp.com/threads/398119-Cutting-Open-GOP-H264-videos-properly

so may be those commercial programs sometimes work better for this specific
task, but not sure if you want to dump money on them for one off job.



> Cheers,
> Rob
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>