GNOME Bugzilla – Bug 656154
Juddery MPEG TS playback
Last modified: 2011-11-09 20:04:02 UTC
Created attachment 193415 [details] GST_DEBUG=3 gst-launch-0.10 ... log while playing the transport stream It seems like MPEG TS demuxer has an issue with channels like ITV1 and Sky News on DVB-S here in the UK. Video playback pauses briefly and periodically (round about once per 1-2 second). Audio sounds OK. I think the message from below could be telling. It seems to be repeating parallel to the judder period. mpegtsdemux gstmpegtsdemux.c:2869:gst_mpegts_demux_src_pad_query:<mpegtsdemux0> unsupported query format or no bitrate yet to approximate duration from bytes Full debug (=3) log attached. I can provide a sample stream on request.
Which version of gst-ffmpeg are you using? gst-ffmpeg 0.10.12 fixes a timestamp bug that was causing similar issues with some DVB transport streams: https://bugzilla.gnome.org/show_bug.cgi?id=651714
Version 0.10.12. Just realized I raised this against the wrong component, sorry about that, fixed.
Could you make that sample stream available please, as well as the gst-launch command lines used to stream/play it ? Thanks
For the record, preliminary testing shows it seems to be an issue with the ffmpeg decoder, not the demuxer, as it all plays smoothly when using the libmpeg2 based decoder, but not the ffmpeg based one. Investigating...
The issue is that, when using the ffmpeg based decoder, legacympegparse is needed. However, when setting the rank of ffdec_mpeg2dec to PRIMARY+1, legacyparse ends up not being selected. The solution is to remove mpeg2dec (eg, set its rank to NONE - note that SECONDARY wasn't enough), then it all works smoothly as legacympegparse gets used. Your patch to bump ffdec_mpeg2dec to PRIMARY+1 is not then needed. diff --git a/ext/mpeg2dec/gstmpeg2dec.c b/ext/mpeg2dec/gstmpeg2dec.c index 4e03c69..848ef0d 100644 --- a/ext/mpeg2dec/gstmpeg2dec.c +++ b/ext/mpeg2dec/gstmpeg2dec.c @@ -1788,7 +1791,7 @@ init_failed: static gboolean plugin_init (GstPlugin * plugin) { - if (!gst_element_register (plugin, "mpeg2dec", GST_RANK_PRIMARY, + if (!gst_element_register (plugin, "mpeg2dec", GST_RANK_NONE, GST_TYPE_MPEG2DEC)) return FALSE;
Right, so this is a patch to ugly plugins. There is no way to fiddle with ranks at runtime?
By "fiddle with ranks at runtime", do you mean something like your original patch ? If so, it's certainly possible, the issue here was one of which particular ranks were used, leading to autoplugging choosing a different set of plugins (which I found out was the issue by pure chance, actually). Setting plugins to PRIMARY+1 seems dodgy (though it is done on a few plugins, I believe), as the assumption when a plugin sets itself to PRIMARY is that it will be used - so PRIMARY will be used on plugins which the programmer expects to be used. Those assumptions become void when anohter plugin may become higher priority, and, well, that's bound to come back and bite you at some point. Is a patch to -ugly (or simply leaving out libgstmpeg2dec.*) an issue instead of a patch to -ffmpeg ?
(In reply to comment #7) > By "fiddle with ranks at runtime", do you mean something like your original > patch ? No, that was at compile time. I meant modifying ranks via some API when library is loaded. > If so, it's certainly possible, the issue here was one of which particular > ranks were used, leading to autoplugging choosing a different set of plugins > (which I found out was the issue by pure chance, actually). > > Setting plugins to PRIMARY+1 seems dodgy (though it is done on a few plugins, I > believe), as the assumption when a plugin sets itself to PRIMARY is that it > will be used - so PRIMARY will be used on plugins which the programmer expects > to be used. Those assumptions become void when anohter plugin may become higher > priority, and, well, that's bound to come back and bite you at some point. Hm, that sounds a bit against the spirit of the architecture and also doesn't it mean lowering priorities would be exactly the same? > Is a patch to -ugly (or simply leaving out libgstmpeg2dec.*) an issue instead > of a patch to -ffmpeg ? Not a huge issue, I just prefer having to carry fewer packages which need patching and rebuilding. But never mind that, I already rebuilt ugly plugins and are testing with that.
> No, that was at compile time. I meant modifying ranks via some API when library > is loaded. Well, there is the plugin registry, I suppose you could load it, fiddle with other plugins' priorites, and write it back, though I couldn't recommend it. It's also going to be lost at any time, should GStreamer decide to rewrite the registry, until your modification code runs again. > Hm, that sounds a bit against the spirit of the architecture and also doesn't > it mean lowering priorities would be exactly the same? Adding 1 to the priority of a plugin is only equivalent to removing 1 from the priority of every other plugin (in practice, every other plugin that shares caps with the bumped plugin, and which could get considered for autoplugging). So in this case there was some MPEG parser who did not get its rank bumped to match. Intead of decreasing mpeg2dec, you could have kept the ffec_mpeg2video increase, and also increased that parser. But then the parser rank interacts with... etc. You see where I'm going ? :) > > Is a patch to -ugly (or simply leaving out libgstmpeg2dec.*) an issue instead > > of a patch to -ffmpeg ? > > Not a huge issue, I just prefer having to carry fewer packages which need > patching and rebuilding. But never mind that, I already rebuilt ugly plugins > and are testing with that. Well, in this particular case, if you're not planning to use the mpeg2dec plugin anyway, it is enough to just not install it, instead of decreasing its rank.
This was due to a rank change cauding the parser to not be plugged, so closing as invalid.