[FFmpeg-devel] [PATCH] Fix MPEG-TS seek and frame positions in general

[Ivan Schreter]

Michael Niedermayer wrote:
> On Sun, Mar 01, 2009 at 05:58:30PM +0100, Ivan Schreter wrote:
>   
>> Michael Niedermayer wrote:
>>     
>>> On Sun, Mar 01, 2009 at 02:31:27PM +0100, Ivan Schreter wrote:
>>>   
>>> [...]
>>>       
>>>> Why do we need the array with several timestamps? I'd say the code can be 
>>>> simplified to (names possibly suboptimal):
>>>>
>>>> 1) set cur_pts, cur_dts, cur_pos to pts/dts/pos of currently-arriving 
>>>> (packet) buffer,
>>>> 2) if frame_pts, frame_dts and frame_pos is unset, set them to cur_pts, 
>>>> cur_dts and cur_pos,
>>>> 3) unset next_pts, next_dts and next_pos,
>>>> 4) call actual parser,
>>>> 5) if the parser returns a buffer, frame_pts, frame_dts and frame_pos are 
>>>> actual pts/dts/pos for the parsed buffer, so return them in pts, dts and 
>>>> pos,
>>>> 6) reset frame_pts, frame_dts and frame_pos to next_pts, next_dts and 
>>>> next_pos,
>>>> 7) reset next_pts, next_dts and next_pos to unset.
>>>>     
>>>>         
>>> this will not work, not at all
>>> example
>>> packet1 50% of frame1 pts=0 (iam just writing one timestamp due to lazyness)
>>> (1) cur_pts=0
>>> (2) frame_pts=0
>>> (3) next_pts=-
>>> (45) parser says nothing yet
>>> (6) frame_pts=-
>>> (7) next_pts=-
>>> packet2 50% of frame1 pts=-
>>> (1) cur_pts=-
>>> (2) frame_pts=-
>>> (3) next_pts=-
>>> (45) parser returns the packet, correct pts is 0 but you return nothing
>>>
>>> this is just the most trivial case, a frame split in 2 packets and detected
>>> in the second
>>>   
>>>       
>> Uhm, I think this is a misunderstanding of (2). For packet 2, (2) will 
>> NOT set frame_pts to (unset) cur_pts, but leave it set.
>>     
>
> frame_pts has been already wiped out in (6) of the previous packet.
> (2) is setting it to unset because it is unset already. its a NOP
>
>
>   
Sorry I messed it up, 6 and 7 were meant to be executed also only if 
buffer returned, as:

1) set cur_pts, cur_dts, cur_pos to pts/dts/pos of currently-arriving 
(packet) buffer,
2) if frame_pts, frame_dts and frame_pos is unset, set them to cur_pts, 
cur_dts and cur_pos,
3) unset next_pts, next_dts and next_pos,
4) call actual parser,
5) if the parser returns a buffer:
   5a) frame_pts, frame_dts and frame_pos are 
       actual pts/dts/pos for the parsed buffer, so return them in
       pts, dts and pos,
   5b) reset frame_pts, frame_dts and frame_pos to next_pts,
       next_dts and next_pos,
   5c) reset next_pts, next_dts and next_pos to unset.

> [...]
> i dont know what "your algorithm" does because your description of it does
> not work
>
> maybe a description in form of a patch that passes regression tests
> would clarify this?
>   
Can do (later). Sorry for causing confusion & stealing your time :-(

But you didn't answer my principial question:

AFAIK, we have only following cases, what a packet (buffer coming into 
the parser) can contain:
a) data for frame i
b) data for end of frame i _and_ data for beginning of frame i+1 (either 
one can also be a complete frame)
c) data for end of frame i, several complete frames i+1 to i+k and data 
for beginning of frame i+k+1 (either i or i+k+1 can also be complete frames)

Any other case? If yes, what?



Thanks & regards,

Ivan