[MPlayer-dev-eng] Lots of stuff for NUT

Rich Felker dalias at aerifal.cx
Mon Jan 2 20:08:35 CET 2006


On Mon, Jan 02, 2006 at 02:05:47PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Jan 02, 2006 at 12:57:30PM +0100, Michael Niedermayer wrote:
> [...]
> > > This solution is overcomplicated and makes a compliant muxer harder to 
> > > write. When I thought it was the only viable solution, I voted for it, but 
> > > I now like the "pts per stream" idea much much better. It is much simpler, 
> > > and I've yet to find a flaw in it except overhead, and I think it might be 
> > > possible to reduce that. The steps to find the syncpoint you want:
> > 
> > personally iam much more liking the idea of droping multiple backpointers
> > and store a single one per syncpoint, i still have great doubt about the
> > advantages of multiple ones, you at least need 2 streams with large keyframe
> > distances, but this already means large distance in bytes and that simply isnt
> > possible on slow media, not to mention large distance might mean lots of time
> > to decode to a common timestamp ...
> 
> heres a specific case where problems might occur
> 
> subtitle   K0        K1
> video      K0 F1 ... F299 K300
> 
> now try to seek to F299 -> the left keyframes are the video K0 and sub K1
> but you will need to decode 299 video frames then to reach a common point

I don't consider this a problem. This is the behavior that's necessary
if you want to seek to F299. What I would consider a bug/limitation in
NUT is if F299 were instead K299, and the demuxer still could not tell
if it had to seek back to K0 or not.

BTW, keep in mind that a player that does not care about exact seeking
can always do something aside from the frame-exact behavior to
optimize for speed, for reaching desired pts with low latency, for
reducing time with no picture available, etc..

Rich




More information about the MPlayer-dev-eng mailing list