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 thoughts on “GStreamer vs. Windows Media Player”
Dump the streams using mplayer and watch them locally.
First step would be to give us the mms:// url :)
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).
Try this patch first: http://bugzilla.gnome.org/show_bug.cgi?id=560348
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…
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*
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 :)
The same problem is with Public broadcasting in the Czech Republic:
I bet it will work with gstreamer-ffmpeg, since Mplayer also uses FFmpeg.
Comments are closed.