GNOME Bugzilla – Bug 722330
streamsplitter: negotiation problems with parsers
Last modified: 2014-01-21 10:20:14 UTC
Created attachment 266458 [details] dotfile image With encodebin the following pipeline fails: gst-launch-1.0 filesrc location="/home/cschalle/Videos/gravity.mpg" ! mpegaudioparse ! "audio/mpeg, mpegversion=1, mpegaudioversion=1, layer=2, rate=44100, channels=2, parsed=true" ! mpegpsmux ! filesink location="/tmp/test.mpg" The gst-launch example above works, but in encodebin it fails as shown by attached dot file graphics. My assumption is that this is the 'same' issue that was resolved for AAC in bug https://bugzilla.gnome.org/show_bug.cgi?id=705024
Ok, so it is probably not the same as the AAC bug. I also get the same stalling behaviour with a Vorbis remux pipeline. Will try to attach some GST_DEBUG logs.
ok, with some help from Wim discovered that the multique element is filling up and that is what is causing this. Last line in debug log: 0:00:10.130385240 16322 0x7f3cf400d630 DEBUG multiqueue gstmultiqueue.c:2021:single_queue_check_full:<multiqueue1> queue 0: visible 915/915, bytes 2099412/2097152, time 14581244445/0 Full log here: http://uraeus.fedorapeople.org/output.txt.bz2
Updated in gst-plugins-base, please check (and reopen if not fixed) commit 5df274f824b1ce493c66fb1a922c47f56cfbc7b2 Author: Wim Taymans <wtaymans@redhat.com> Date: Thu Jan 16 16:32:34 2014 +0100 streamsplitter: handle ACCEPT_CAPS query correctly We can accept a caps when one of the downstream peers can accept the caps. This is not the same as checking a subset of the getcaps result because parsers might accept broader caps than what their getcaps function returns (See https://bugzilla.gnome.org/show_bug.cgi?id=677401). Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722330
It seems to get a little further now, I do get an output file, but it seems to stop after having generated a few hundred K. New debug log with current behaviour here: http://uraeus.fedorapeople.org/new-debug.txt.bz2
commit e58a00b2a2ec637b61cea808537d469b3649a116 Author: Wim Taymans <wtaymans@redhat.com> Date: Mon Jan 20 16:25:51 2014 +0100 mpegpsmux: fix timestamp handling If the first buffer that we handle for a stream has no timestamp, we would never consider this pad again for muxing which causes queues to fill up and pipelines to stall. Instead, try to mux pads with -1 timestamps as soon as possible. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722330 commit 4e10667aad93ee049337f458d6069a7e6229f1cf Author: Wim Taymans <wtaymans@redhat.com> Date: Mon Jan 20 16:23:49 2014 +0100 mpegpsmux: return GST_FLOW_EOS when we pushed EOS Return GST_FLOW_EOS from the collected function when we pushed EOS or else it simply keeps on calling our collected function.
commit 0bb2e2f74fbfaa4ea299a286e0d34de48b5b32eb Author: Wim Taymans <wtaymans@redhat.com> Date: Tue Jan 21 10:27:20 2014 +0100 mpegpsmux: update last_ts to mux correctly We use last_ts to decide what buffer to mux next so make sure that it always contains the last known valid timestamp.