GNOME Bugzilla – Bug 643202
encodebin: streamcombiner not completely implemented
Last modified: 2018-11-03 11:18:31 UTC
+++ This bug was initially created as a clone of Bug #641927 +++ The python sample from bug #641927 still crashes. It's a) causing the g_critical() in oggmux to happen (gstoggmux.c:1072) and b) causes a segfault in schroedinger.
Something similar happens when using matroskamux instead of oggmux. Using a different video codec does not work for some reason So essentially this seems to be another problem in encodebin but I have no idea where. valgrind is not very useful here because it only complains about invalid reads inside python's free functions...
Created attachment 186009 [details] test.c Same testcase in C this time, still crashes with schroenc and lots of warnings inside vp8enc when using vp8enc.
Part of the problem here is, that streamsplitter in encodebin sends EOS to all streams downstream if one stream went EOS. Now the non-EOS streams still try to push buffers downstream, which are dropped.
Yes, when using input where all streams have more or less the same duration this works as expected. So we have a bug in encodebin that makes it output EOS too early if one stream ends earlier and a bug in schroenc that makes it explode if it gets buffers after EOS.
This happens because encodebin internally has a streamsplitter that outputs on different srcpads depending on the caps and a streamcombiner that combines these different streams again. In my testcase there's a passthrough sinkpad in the combiner and another one. When EOS is received from upstream in the splitter it is forwarded to all srcpads of streamsplitter. The passthrough part has no queues or anything, as such the EOS event is immediately forwarded to the streamcombiner and from there on downstream. The other EOS event is synchronized correctly and gets send to the encoder after all buffers have passed... but at that time downstream after the streamcombiner already saw EOS and returns UNEXPECTED for the encoded buffers.
Created attachment 186298 [details] test.ogg
Edward? Any news on this?
the streamcombiner should wait until it has received EOS on all pads before pushing it downstream.
We already were beyond that, Edward :) The streamcombiner is simply not implemented yet (in any way) and there are comments that say what should be done inside the code
Clearly not a blocker, reducing severity. Should have picked up on that before pushing it to -base, but too late now.
This should be fixed by http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=2f8b0f1e34833f8da5b3ff7b9b4eb656c4c26a1f
From taking another look at the code, this is only implementing part of streamcombiner. Still more missing, or all the comments are not relevant anymore.
That seems to duplicate funnel exactly. Is there a difference?
Jul 19 09:18:47 <slomo_> bilboed: i wanted to talk about encodebin, streamcombiner/streamsplitter. should it do anything that output-selector and funnel can't do? Jul 19 09:19:17 <bilboed> streamcombiner/streamsplitter were designed to support exclusive paths Jul 19 09:19:44 <bilboed> streamsplitter can chose the path to take based on caps Jul 19 09:20:48 <bilboed> stream ! streamsplitter ! .... many paths .... ! streamcombiner ! <== the output should be consistent with the input Jul 19 09:20:53 <bilboed> and automatic Jul 19 09:21:15 <slomo_> i see Jul 19 09:21:22 <bilboed> afaiu, funnel just shoves all input to the output, and only supports one format ,no ? Jul 19 09:21:24 <slomo_> so streamsplitter is an automatic output-selector Jul 19 09:21:43 <bilboed> I guess, yes Jul 19 09:21:49 <slomo_> funnel just takes whatever it gets from upstream Jul 19 09:21:52 <bilboed> right Jul 19 09:21:58 <slomo_> if only one stream has data, it just takes that Jul 19 09:22:05 <slomo_> is that the case here? Jul 19 09:22:09 <bilboed> no Jul 19 09:22:30 <bilboed> when streamsplitter switches streams, it will send out an EOS on the old stream, before pushing out data on the new stream Jul 19 09:22:34 <slomo_> ok, so not possible to replace any of them... but just implement them properly :) Jul 19 09:22:41 <bilboed> streamcombiner should then wait for the EOS on the old stream before accepting data on another stream Jul 19 09:23:08 <bilboed> yah, sorry about implementation issues :( Jul 19 09:23:11 <slomo_> why would it switch streams at all? Jul 19 09:23:36 <bilboed> you could have queues and different elements between splitter and combiner Jul 19 09:24:03 <bilboed> so you might end up receiving data from the new stream in the combiner ... before you've finished being done with the old stream Jul 19 09:24:08 <slomo_> ah Jul 19 09:24:12 <slomo_> yes Jul 19 09:24:32 <slomo_> i thought you meant streamsplitter could suddenly decide (for the same input) to use a different srcpad Jul 19 09:24:46 <bilboed> not if it's the same caps, no Jul 19 09:24:58 <slomo_> i see, makes all sense then :) Jul 19 09:25:08 <bilboed> the usage is to have two parallel streams in encodebin Jul 19 09:25:22 <bilboed> one with actual converters/encoders, and the other one going straight to the combiner Jul 19 09:25:27 <bilboed> so that you can do smart encoding Jul 19 09:25:31 <slomo_> yes Jul 19 09:25:47 <bilboed> voila
I'm still not sure what's the difference with funnel? Funnel will wait for all pads to get EOS before forwarding it. How do you plan to send data after EOS on streamcombiner anyway?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/45.