[MPlayer-cvslog] r26069 - in trunk/libmpdemux: demuxer.c demuxer.h

[Nico Sabbi]

Il Saturday 23 February 2008 21:13:07 Uoti Urpala ha scritto:
> On Sat, 2008-02-23 at 20:37 +0100, Nico Sabbi wrote:
> > the same principle can be used by other demuxers (rt[s]p comes to mind),
> > and in the future broadcast streams using NUT, too.
> > The idea for this patch originated from a thread in nut-devel where 
> > were discussed techniques to make NUT suitable for streaming
> 
> I see no benefit from exposing this functionality outside the demuxer.
> And the parts of discussion I looked at on nut-devel looked like they
> were talking about the amount of data to buffer before starting
> playback. What you committed doesn't really do that.

not only at the beginning, but at any time. Why do you say that
my patch doesn't do it?

> 
> > > Isn't this similar to your suggestion that was was discussed on IRC
> > > earlier? I thought that back then you understood it would not work...
> > 
> > no, it's not the same: at the time I was suggesting to relent decoding,
> > while this patch permits something different: following the transmitter
> > clock mplayer will always have in the demuxer->(audio|video) queues
> > as much data as the transmitter suggests; in practice the patch
> > is intended to always keep the demuxer's queues full enough.
> 
> There's little practical difference. What your patch does in practice is
> make MPlayer block in the demuxer until a certain "reference clock"
> value has been read. How much data MPlayer has in the demuxed packed
> buffers is mostly IRRELEVANT unless they reach max size and break. What
> matters for playback is whether demuxing calls will block or not.
> 
> So demuxing more data so that "mplayer will always have in the
> demuxer->(audio|video) queues as much data as the transmitter suggests"
> is completely meaningless UNLESS the extra demuxing blocks, and in that
> case the practical effect is to act as a delay which prevents decoding.
> 
> Using demuxers for timing is a bad idea, and IMO blocking in them should
> be avoided when possible. Your patch certainly doesn't implement any
> mechanism that would properly sync MPlayer playback with the source
> speed.
> 
> > I see a lot of improvements with it
> 
> Maybe blocking at another moment happens to give smoother playback in
> some situation, but that does not make your patch correct. If MPlayer's
> playback was too slow before and buffers filled up your patch can only
> make it worse. If playback stuttered because of empty buffers then
> either MPlayer didn't buffer enough data before starting playback or
> playback speed was too high. Your patch doesn't have anything which
> could really fix either cause. Something similar could be used to
> determine the amount to buffer when starting playback, but your current
> code is not a proper implementation of that either.
> 

#if0 the code if you want, but don't remove it, please.
I'll try to find a way to change the playback speed dynamically
if you believe it's more correct (IIRC something like this was
your proposal on irc)