On Wed Apr 23 04:20:59 2025 +0000, Brendan McGrath wrote:
Looks like it's stuck in a `multiqueue`:
0:00:25.705899699 234331 0x7fffa4001e80 LOG multiqueue gstmultiqueue.c:3249:single_queue_overrun_cb:<multiqueue1:queue_1> EOS 1, visible 60/62, bytes 142289/8388608, time 2000000000/0 0:00:25.710933936 234331 0x7fffa40019a0 DEBUG multiqueue gstmultiqueue.c:3369:single_queue_check_full:<multiqueue1:queue_1> visible 60/62, bytes 142289/8388608, time 2000000000/0These are the very last entries for `multiqueue1`. You can see that `EOS` is `1`, but there is also still `142289` bytes of data queued. The `EOS` is sent in-band, so all that pending data needs to cleared prior to delivery of the `eos`. However, because of the deadlock, the data (and thus the `EOS` event) are not moving. I've attached an image of the pipeline so you can see where `multiqueue1` exists.[0.00.03.764973074-wg_parser_caps.dot](/uploads/311fd6ab73121937aa507ed5961da6e7/0.00.03.764973074-wg_parser_caps.dot)
I see, that implies the application isn't actually reading all the data out of the other stream. I guess native is supposed to not block in that case, although it may be worth looking into anyway, since that doesn't sound like things are working correctly.
It's probably worth adding a comment here to that effect. Something like:
/* decodebin collects EOS and sends them only when all streams are EOS. In place it sends stream-group-done notifications for individual streams. This is mainly meant to accommodate chained OGGs. However, Windows is generally capable of reading from arbitrary streams while ignoring others, and should still send EOS in that case. Therefore translate stream-group-done back to EOS. */