[MPlayer-users] [Bug] Choppy video in mplayer svn

[Mrc Gran]

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