Opened 12 years ago

Last modified 8 years ago

#799 new defect

Choppy video when handling MMS streams

Reported by: mrc.gran@… Owned by: reimar
Priority: normal Component: demuxer
Version: HEAD Severity: normal
Keywords: Cc: cosoleto@…
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

According to this thread, "Choppy video in mplayer SVN",
http://lists.mplayerhq.hu/pipermail/mplayer-users/2007-April/066705.html
mplayer is not handling correctly the handshake of MMS streams, resulting sometimes in the server sending the wrong bitrate variations of the MMS stream.

This bug can be verified by executing
player -playlist "http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=650349|banda=N|ext.asx"
with or without cache.

After a few seconds, mplayer will consume any cache and the video will start interrupting several times a second. From the thread above:
"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."
More details can be found in the thread.

Totem-xine and Windows Media Player work both fine with the video url above. Totem-xine should probably be analyzed to find out why it works fine and it handles the mms handshake right while mplayer does not.

Change History (4)

comment:1 Changed 11 years ago by amir@…

Is anybody working on this bug ? Can I provide any help ?

comment:2 Changed 10 years ago by cosoleto@…

The first problem concerning this bug is that current stream selector code is fully in a not working state. A patch to fix this problem is pending for approvation in developers mailing-list (http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2009-March/060964.html). The second problem is that the server doesn't support a data trasfer to speed major than 200000 bit/s (as suggested from the string "&WMContentBitrate=200000" in the URL), but sum of default streams selectioned are greater. A patch to add a bandwidth based stream selection is posted too (http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2009-March/060966.html). After that these patches are applied (there is also a third useful patch), the following workaround is available:

mplayer -bandwidth 200000 -playlist "http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=650349|banda=N|ext.asx"

I'll try to fix better the problem later.

comment:3 Changed 10 years ago by cosoleto@…

  • Cc cosoleto@… added

comment:4 Changed 8 years ago by compn

  • Owner changed from r_togni@… to reimar
Note: See TracTickets for help on using tickets.