[MPlayer-dev-eng] Re: [MPlayer-users] [Bug] Choppy video in mplayer svn

[Ivan Kalvachev]

2007/4/15, Mrc Gran <mrc.gran at gmail.com>:
> On 4/8/07, Jorge Fábregas <jfabregas at onelinkpr.net> wrote:
> >
> > On Saturday 07 April 2007 3:45 pm, Marcus Granado wrote:
> > >The following video works fine on Windows Media Player.
> > >But it is *very* choppy in mplayer, impossible to watch.
> > mplayer -playlist "
> > http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=661559|banda=N|ext.asx<http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=661559%7Cbanda=N%7Cext.asx>
> > "
> > > Do you observe the same behaviour as I do?
> >
> > I tried the new link you provided on Windows Media Player and it plays
> > fine
> > there.  I tried on mplayer (with cache 4096) and initially plays fine but
> > then the chopping starts.  So, basically I have the same results as you.
> >
> >
> I believe I discovered the origin of the problem in mplayer, it seems to
> boil down to a deficiency in it when initializing mms video streams.
>
> I'm CCing the mplayer-dev list as well because I think they will be better
> prepared to confirm or deny the following statements:
>
> it seems that in the mms header there's space for a set of different bitrate
> variations for the same video. the example url above uses a server which
> caps the maximum bandwidth available for downloading the stream. the client
> should choose the bitrate variation which is the fastest one yet uses less
> than the maximum video bandwidth cap.
>
> totem-xine correctly implements this hand-shake during mms stream
> initialization, in order to command the server to serve the best bitrate
> using less than the server bandwidth cap. (see for instance the
> asf_header_choose_streams() function inside this function
> http://xine.cvs.sourceforge.net/xine/xine-lib/src/demuxers/demux_asf.c?view=markup#l_560,its
> implementation is at
> http://xine.cvs.sourceforge.net/xine/xine-lib/src/demuxers/asfheader.c?view=markup#l_797
> )
>
> so, totem-xine (and -of course- windows media player) works with the example
> mms video without problems.
>
> but not mplayer: it currently uses a simplified version of an old 2002 xine
> version which doesn't do the mms handshake. (
> http://svn.mplayerhq.hu/mplayer/trunk/stream/asf_mmst_streaming.c?view=markup
> )
> so, mplayer ends up choosing (or forcing the server to choose) the best
> available bitrate variation in the mms header, which (for some reason in
> their servers) is faster than the bandwidth cap of the server. therefore,
> the server is never able to keep the buffer full, and buffer underflow
> always creeps up in the initial seconds, after the initial local cache has
> been quickly consumed.
>
> as another interesting sidenote, mplayer, instead of pausing for some
> seconds in order to refill the cache, starts to play intermittently,
> consuming the 'under-bitrated' fresh frame(s) as soon as the are received,
> therefore exacerbating the problem, resulting in a video which plays/pauses
> several times per second.
>
> would some developer with experience in the mms implementation of mplayer
> please elaborate on this??
> thanks,
> Marcus

`man mplayer`  use '/' for search.
look up for "-bandwidth"
The value from it seems to be used (also) in streams/asf_streaming.c