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

[Michael Niedermayer]

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


> Even if packet2 
> had pts=1, frame_pts would stay set at 0, since this is relevant pts for 
> the first frame. I.e., the parser will return correct pts=0 and _then_ 
> set frame_pts to undefined (so next call with next packet will set it 
> again to the pts of the packet3, which contains frame2).
> 
> In case packet2 having pts=1 and containing already portion of frame2, 
> the codec-specific parser would call a function to announce this fact. 
> This would then set next_pts to cur_pts (i.e., 1), so after returning 
> the first frame with frame_pts == 0 copied to pts, frame_pts would be 
> set to next_pts == 1. So packet3 completing frame2 would return pts 1, 
> which is correct pts for frame2.
> 
> 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?

no just that the parser will not tell you where the frames end until after
them.


> 
> pts/dts/position of the frame is equal to pts/dts/position of first 
> packet in stream which contains starting portion of frame data.
> 
> All of these cases will be handled correctly by my algorithm.

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?

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090301/47d4fe21/attachment.pgp>