[FFmpeg-user] Towards better trims & concatenations

[Andrew Randrianasulu]

ср, 10 янв. 2024 г., 06:23 Andrew Randrianasulu <randrianasulu at gmail.com>:

>
>
> вт, 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.
>


oh, according to this forum post main developer of said commercial program
(videoredo 5) moved to some other quests .... after main (1 out of 2)
owner/business partner died in 2022 ....

https://forum.videohelp.com/threads/407142-VideoReDo-owner-passed-away-product-ceased-seeking-alternatives

 .... scratches head ..... at least another link to itu site still around
and encoder can be compiled on aarch64 termux:

http://iphome.hhi.de/suehring/tml/download/

may be this can help in determinating locations of remaining bugs or
unimplemented modes lin ffmpeg ( I get impression full stream scan before
cut is not something most users want due to time reasons, so may be it just
never was implemented as we think it can be implemented )

avidemux2 git

 https://github.com/mean00/avidemux2/commits/master

demuxers apparently in live in plugins, so I missed them at first.


>
>
>> 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".
>>
>