[FFmpeg-user] I found the bugs

[Mark Filipak]

Paul, I misunderstood your question. (see at end)

On 17/06/2024 17.59, Mark Filipak wrote:
> On 17/06/2024 17.18, Paul B Mahol wrote:
>> On Mon, Jun 17, 2024 at 8:29 PM Mark Filipak <markfilipak.imdb at gmail.com>
>> wrote:
>>
>>> On 17/06/2024 13.50, Paul B Mahol wrote:
>>>> On Mon, Jun 17, 2024 at 5:35 PM Mark Filipak <markfilipak.imdb at gmail.com
>>>>
>>>> wrote:
>>>>
>>>>> On 17/06/2024 03.16, Paul B Mahol wrote:
>>>>>> On Mon, Jun 17, 2024 at 3:16 AM Mark Filipak <
>>> markfilipak.imdb at gmail.com
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> To expand on my idea:
>>>>>>>
>>>>>>> The video is this:
>>>>>>> I P B B P B B P B B I P B B..
>>>>>>> I want to change it to this:
>>>>>>> I B B P B B P B B P I B B P..
>>>>>>>
>>>>>>
>>>>>> If this is what I think it is, your are wasting your time.
>>>>>
>>>>> It is possible. But can FFmpeg do it? You see, Paul, I read in several
>>>>> places from seemingly
>>>>> authoritative people that professional videos are PTS-ordered. I've
>>> since
>>>>> discovered that
>>>>> professional videos are almost always DTS-ordered -- I now have a packet
>>>>> browser and have seen it to
>>>>> be true. However, I have seen professional videos that are PTS-ordered
>>> but
>>>>> I didn't think too much
>>>>> about it at the time.
>>>>
>>>> PTS order is order once frames are decoded and going to be presented to
>>>> user, thats why it is called presentation timestamps.
>>>
>>> Yes of course.
>>>
>>>>> My idea is to take the 4-second video -- DTS-ordered -- that I sent to
>>>>> trac, change it to
>>>>> PTS-ordered, and see if '-vf showinfo' and '-f show_frames' respond
>>>>> correctly. It's a long shot, but
>>>>> it might show something useful -- what if PTS-order made showinfo
>>>>> show_frames and framecrc all
>>>>> agree? Wouldn't that be something interesting?
>>>>
>>>> If decoder follows specifications for decoding bitstreams correctly than
>>>> changing order of raw encoded frames as stored in bitstream will almost
>>>> every-time cause broken decoding.
>>>>
>>>>>> Its nonsense to change order of encoded frames, no manipulation of
>>> clock
>>>>>> can fix that.
>>>>>
>>>>> No, no. Manipulation of PCR. Fix up the PCRs so that the result is truly
>>>>> PTS-ordered.
>>>>
>>>> If this is at format container layer, I dunno how would that work even if
>>>> its is possible to be useful.
>>>
>>> The container would contain a PES packet stream with PCRs like any other
>>> PES packet stream. It would
>>> work like any PTS-ordered stream does. You know, there _are_ PTS-ordered
>>> streams. And you know, MPEG
>>> is silent on the matter of what physical order frames are in the stream,
>>> only that they must be
>>> given to the decoder in DTS-order.
>>>
>>> Look, I agree that it would be nonsense. I want to turn the DTS-ordered
>>> stream into a PTS-ordered
>>> stream merely as a test: '-f show_frames' appears to be getting DTSes and
>>> PTSes mixed up, then
>>> applying a fix that results in completely new DTSes. If it treats the
>>> PTS-ordered stream
>>> differently, that will say a lot. What is says depends on what it does.
>>> Capiche?
>>>
>>> I thought I could do it by demuxing, then moving them like you can move
>>> frames in a filter_complex,
>>> and then remuxing, but I don't know how to do that to PES packets (instead
>>> of decoded pictures) and
>>> I don't know how to rewrite PCRs.
>>>
>>
>> But aren't you working with HEVC and not MPEG video?

For the test of show_frames and showinfo I'm staying with AVC-M2TS.