GStreamer vs. Windows Media Player

I’ve always been quietly impressed with GStreamer — in a world of multimedia where everything is so complicated, applications using GStreamer pretty much “just work” without any problems.

This was until today. I subscribe to a Polish TV archive, that has archived versions of soaps my girlfriend enjoys (M jak miłość). Windows Media Player 11 plays the mms stream perfectly, with no visual artifects or sound skipping, but in totem the video is unwatchable. As a further point, mplayer seems to play this mms stream with no video glitches, and only an occasional audio blip.

On gstreamer-0.10.21-2.fc10.i386, using playbin and debug level 2, I get:

0:00:11.977812682 15562  0x8ab4e50 WARN              asfdemux asfpacket.c:104:asf_payload_find_previous_fragment: Previous fragment does not match continued fragment
...
0:00:19.046052292 15562  0x8ab4e50 WARN              asfdemux asfpacket.c:336:gst_asf_demux_parse_payload:<asfdemux0> Offset doesn't match previous data?!
0:00:19.046086304 15562  0x8ab4e50 WARN              asfdemux asfpacket.c:104:asf_payload_find_previous_fragment: Previous fragment does not match continued fragment


Which I guess means the payload timestamps are wrong, then then I get about a bazillion of:

0:00:31.263371321 15562  0x8e0b408 WARN              GST_PADS gstpad.c:2992:gst_pad_iterate_internal_links_default:<selector_video_src1:src> Making unsafe iterator
...

and then when it skips:

0:00:36.949382321 15644  0x9d0c538 WARN         baseaudiosink gstbaseaudiosink.c:1395:gst_base_audio_sink_render:<audiosink-actual-sink-pulse> warning: Compensating for audio synchronisation problems
0:00:36.949410537 15644  0x9d0c538 WARN         baseaudiosink gstbaseaudiosink.c:1395:gst_base_audio_sink_render:<audiosink-actual-sink-pulse> warning: Unexpected discontinuity in audio timestamps of more than half a second (0:00:00.649705215), resyncing
WARNING: from element /GstPlayBin:playbin0/GstBin:abin/GstAutoAudioSink:audiosink/GstPulseSink:audiosink-actual-sink-pulse: Compensating for audio synchronisation problems
Additional debug info:
gstbaseaudiosink.c(1395): gst_base_audio_sink_render (): /GstPlayBin:playbin0/GstBin:abin/GstAutoAudioSink:audiosink/GstPulseSink:audiosink-actual-sink-pulse:
Unexpected discontinuity in audio timestamps of more than half a second (0:00:00.649705215), resyncing
...

This makes the video unwatchable. I’m guessing the server is somehow broken, but it works in Windows Media Player perfectly and 99% okay on mplayer.
Any help on how to debug this or report a proper bug gratefully received. Thanks.

9 responses to “GStreamer vs. Windows Media Player”

  1. Erik

    Dump the streams using mplayer and watch them locally.

  2. Stefan Kost

    First step would be to give us the mms:// url :)

  3. Tom Parker

    http://live.gnome.org/Bugsquad/TriageGuide/ProductSpecificGuidelines suggests running

    gst-launch-0.10 playbin uri=”file:///path/to/file”

    and saving the output. Apparently adding “–gst-debug-level=5″ before the playbin bit may also help (but output levels get a tad insane).

  4. wtay
  5. DeeJay1

    I think he means the streams under http://www.itvp.pl/
    The sad thing is that it’s a public broadcaster who specifically excludes users of other operating systems than the “most popular” one and says it isn’t going to fix it…

  6. sxpert

    lemme guess… MS has come out with an “update” to the encoder that “breaks” the streams…
    that, or the community hasn’t reverse engineered enough of the format *yet*

  7. Bastien

    Bet it’s a dupe of http://bugzilla.gnome.org/show_bug.cgi?id=560348
    Richard already got a kicking for using his blog as a bug tracker :)

  8. Vladimír

    The same problem is with Public broadcasting in the Czech Republic:

    http://www.ceskatelevize.cz/vysilani/

    http://www.ct24.cz/vysilani/

  9. anon

    I bet it will work with gstreamer-ffmpeg, since Mplayer also uses FFmpeg.

Bad Behavior has blocked 2769 access attempts in the last 7 days.