GNOME Bugzilla – Bug 736819
mpegtsbase: Handle STREAM_START in PUSHING mode.
Last modified: 2018-05-04 09:45:45 UTC
Created attachment 286407 [details] [review] Implements the proposed enhancement + tsdemux: Add pad immediately when a stream is added instead of doing it on activation. The logic here is that we need to remove pads for old streams after exposing our new pads and emitting no-more-pads, so that decodebin knows not to propagate the EOS.
Let me first push the GAP tsdemux fixes first (which properly handles adding pad at the beginning).
Just realized the GAP issue (and adding pads straight away) is orthogonal to this issue (as opposed to blocking it). Looks good, will give it a try and push it
Small (big) issue I noticed: * assume the new program has one or more elementary stream PID in common with the old one (say 0x0021) of the same type (say video), * when we get to activating the new program ... adding the pad for that elementary stream will fail (because there already is a pad with the same name, in this example video_0x0021), * the new pad doesn't get exposed... but the old one gets removed * data goes nowhere * sad panda This isn't the fault of this commit, but it's exacerbated by it.
Let's fix that ? Using solely the stream pid to set the name of the pad seems fragile to me, we could use a simple int that we increment for each pad, or if the pid is a valuable information to expose as the pad name (I don't think it is but not sure), then a combination of both ? Please tell me which solution makes the panda happy and I'll implement it.
A element-global counter will have to do and name the pads {video|audio|private}_{counter}_{hex_pid} That will still help make the pad names recognizable for debugging purposes
This isn't needed anymore with a streams-aware context (like parsebin,decodebin3, etc..) pads will be created if/when needed.