[FFmpeg-user] Packet corrupt on cut, notice on concat

[Mark Filipak]

On 19/02/2024 14.49, Paul B Mahol wrote:
> On Mon, Feb 19, 2024 at 6:47 PM Mark Filipak wrote:
>> SUMMARY:
>> I'm cutting solely on packets that contain I-frames. I'm joining packets
>> that contain I-frames on both sides of the join. There's no decoding,
>> no encoding. There's only remuxing. I'm well aware of DTS-order versus
>> PTS-order.
>>
>> I began with
>> ffmpeg -ss <starttime> -to <endtime> -i this.m2ts
>> of course. It cut at the right place but the output included 52 audio
>> frames and a B-frame that should have been cut. The join was not
>> correct of course and the MPV player behaved as one would expect
>> from a bad join.
>>
>> I tried
>> ffmpeg -i this.m2ts -ss <starttime> -to <endtime>
>> but that cut at the wrong PTSs -- hundreds of packets early. There were
>> other issues, too. No one could explain that behavior.
>>
>> I asked if there is a way to discard specific packets based on PTSs. Gyan
>> suggested I try
>> ffmpeg -i this.m2ts -bsf noise
>> I used '-bsf noise' to do _all_ the cutting and that appeared to work
>> beautifully. The outputs appeared to be perfect in every way.
>>
>> It was when I joined (concatenated) those segments what I discovered
>> another problem: FFmpeg had corrupted the final B-frame just before
>> the ending I-frame. When I 'moved' the cuts and join around in time,
>> the 'corruption' followed the moves, always the final B-frame just
>> before the ending I-frame.
> 
> Perhaps this is bug how flush in code is handled after each reached EOF?

That would be a good place to look.

> Might be bug somewhere.

What? A bug in FFmpeg?

> Best to create minimal reproducible usecase with all required files to
> reproduce it, upload it somewhere and link it on ffmpeg trac site.

I did that. It didn't get any interest.

Methinks it would be best for someone to confirm it before going to trac.

Note that the last B-frame before the ending I-frame has a special place in DTS-order. Agreed?

>> The video is 24/1.001fps, so ticks-per-frame is 3753.75. Because PTSs are
>> integers, 3753.75 tick intervals must be turned into integer PTSs. That
>> was when I discovered that FFmpeg is not truncating correctly, so PTSs are
>> not correct.

What do you think? Could that cause FFmpeg to 'miss' a frame or become confused about a frame?

Now, I've seen up-truncations like that before. They were done to make other things work because 
those other things were not 'seeing' what they expected.

--Mark.