end_of_stream on crash group down about membrane_core HOT 6 CLOSED

I agree 😉 It works though, thanks.

from membrane_core.

Whenever a dynamic input pad is unlinked, an end_of_stream is generated (as long as a start_of_stream has arrived before). It seems that's your case too.

from membrane_core.

Hi @mat-hek! This is a no-go for our pipeline. Is there a clean way to distinguish between an "upstream" end_of_stream and this one?

from membrane_core.

Currently, there's not :/ But I think we can add such information to the callback context. To work this around, you can send your custom event before the end_of_stream and handle that instead

from membrane_core.

I was thinking about sending myself a message when the end_of_stream arrives. If an handle_pad_removed callback is called before the message comes, back, I'll discard it. Otherwise I'll deliver the end_of_stream. WDYT? We basically have a "dynamic input pad adapter" before each crash group so that we can isolate the different portions of the pipeline, we are not actually dynamically adding/removing pads in there if not on a crash.

from membrane_core.

Yes, it's quite hacky but it should work ;)

from membrane_core.