[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,

If there was mplayer developer with experience in mms, we wouldn't
need to clone it from xine ;)

Here is what the deal seems to be.
The server is sending data with 360kbps. This is the speed of the
biggest bandwidth video stream. (and is way under my internet limit).
For some reason the bitstream is having all the 3 bandwidths videos,
resulting in 768kbps stream.

 Because the server is sending 768kbps stream with 360kbps speed, it
always starves.

Your bug is confirmed, you can write it in bugzilla. Let's hope that
the release of M$ network protocols would help improving mms handling.