GNOME Bugzilla – Bug 692785
input-selector: STREAM_START event not forwarded for new active pad
Last modified: 2013-08-22 09:56:45 UTC
Created attachment 234714 [details] [review] Patch When selecting a new active pad, forward_sticky_events() is called but does not forward STREAM_START event. I imagine this might have been a development choice but it can be annoying if this event is required for downstream elements willing to detect the presence of a new stream (and this is my case :)). Would it not be better to let the choice of the user to drop this event, using a prob for instance? Cheers, Paul HENRYS
Comment on attachment 234714 [details] [review] Patch Looking at commit c33d2f7a, it seems that you need to forward only the first one, you probably don't want to forward a new stream-start when the input it switched.
Yes, indeed. As I was saying that's probably a choice but in the case described in the bug #692787, I use these STREAM_START events and would need to forward it but that's really a specific case. But since STREAM_START event is a marker of a new stream I would have expected to receive it for each new stream in the pipeline.
I don't think it's right that the input-selector forwards the first STREAM_START, it should create a new one and send that instead. The PPS/SPS stuff could be handled like I described in the other bug. I don't think sending a new stream-start whenever input-selector switches streams is right. I think you're onto something here that we don't do fully right yet (e.g. tags will also not get cleared when switching streams, for example), but it's not clear to me that using stream-start events is the right solution for that. I gather you're mostly looking to make your use case work right? That should be possible with the mechanism I outlined in the other bug.
(In reply to comment #3) > I don't think it's right that the input-selector forwards the first > STREAM_START, it should create a new one and send that instead. The PPS/SPS > stuff could be handled like I described in the other bug. > > I don't think sending a new stream-start whenever input-selector switches > streams is right. ACK, it shouldn't send when switching streams. And it shouldn't forward the upstream one, but instead also use a different stream-id. It's not the same stream in the end after all.
input-selector is now always forwarding the stream-start evnet (and all sticky events) of the currently active pad. And everything is fixed to properly work with that.