This event indicates that there will be no more data. Handling it like an EOS fixes a dead lock that occurs when a stream completes.
From: Brendan McGrath bmcgrath@codeweavers.com
This event indicates that there will be no more data. Handling it like an EOS fixes a dead lock that occurs when a stream completes. --- dlls/winegstreamer/wg_parser.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/winegstreamer/wg_parser.c b/dlls/winegstreamer/wg_parser.c index 710cfe6a0a5..b2c92e2c314 100644 --- a/dlls/winegstreamer/wg_parser.c +++ b/dlls/winegstreamer/wg_parser.c @@ -598,6 +598,7 @@ static gboolean sink_event_cb(GstPad *pad, GstObject *parent, GstEvent *event) break; }
+ case GST_EVENT_STREAM_GROUP_DONE: case GST_EVENT_EOS: pthread_mutex_lock(&parser->mutex); stream->eos = true;
Why don't we get an actual EOS? What's the deadlock?
Why don't we get an actual EOS?
It's hooked by `decodebin` and replaced with a `stream-group-done` event (which we currently ignore):
``` 0:00:25.709251065 234331 0x7fffa40019a0 DEBUG decodebin gstdecodebin2.c:5053:source_pad_event_probe:decodebin0:src_1 we received EOS 0:00:25.709295681 234331 0x7fffa40019a0 DEBUG decodebin gstdecodebin2.c:4305:gst_decode_pad_handle_eos:<decodebin0> Sending stream-group-done for group 1 to pad decodebin0:src_1 0:00:25.709568396 234331 0x7fffa40019a0 WARN WINE wg_parser.c:665:sink_event_cb: Ignoring "stream-group-done" event. 0:00:25.710063153 234331 0x7fffa40019a0 DEBUG GST_PADS gstpad.c:4099:push_sticky:decodebin0:src_1 event eos was dropped, mark pending
```
What's the deadlock?
Because we ignore the `stream-group-done`, we wait indefinitely within `wait_on_sample` for another buffer (of which there are none) or an `eos` (which got dropped). This also means the media source critical section is held indefinitely, so a subsequent call to `media_stream_RequestSample` also deadlocks: ``` 8269.020:0020:0148:err:sync:RtlpWaitForCriticalSection section 00007FFFFEC7FB30 "../../dlls/winegstreamer/media_source.c: cs" wait timed out in thread 0148, blocked by 016c, retrying (60 sec) ```
Simply treating the `stream-group-done` event the same as the `eos` event that it replaced fixes this (as the `wait_on_sample` call will exit with eos).
On Fri Apr 18 01:24:20 2025 +0000, Brendan McGrath wrote:
Why don't we get an actual EOS?
It's hooked by `decodebin` and replaced with a `stream-group-done` event (which we currently ignore):
0:00:25.709251065 234331 0x7fffa40019a0 DEBUG decodebin gstdecodebin2.c:5053:source_pad_event_probe:<decodebin0:src_1> we received EOS 0:00:25.709295681 234331 0x7fffa40019a0 DEBUG decodebin gstdecodebin2.c:4305:gst_decode_pad_handle_eos:<decodebin0> Sending stream-group-done for group 1 to pad <decodebin0:src_1> 0:00:25.709568396 234331 0x7fffa40019a0 WARN WINE wg_parser.c:665:sink_event_cb: Ignoring "stream-group-done" event. 0:00:25.710063153 234331 0x7fffa40019a0 DEBUG GST_PADS gstpad.c:4099:push_sticky:<decodebin0:src_1> event eos was dropped, mark pendingWhat's the deadlock?
Because we ignore the `stream-group-done`, we wait indefinitely within `wait_on_sample` for another buffer (of which there are none) or an `eos` (which got dropped). This also means the media source critical section is held indefinitely, so a subsequent call to `media_stream_RequestSample` also deadlocks:
8269.020:0020:0148:err:sync:RtlpWaitForCriticalSection section 00007FFFFEC7FB30 "../../dlls/winegstreamer/media_source.c: cs" wait timed out in thread 0148, blocked by 016c, retrying (60 sec)Simply treating the `stream-group-done` event the same as the `eos` event that it replaced fixes this (as the `wait_on_sample` call will exit with eos).
Normally EOS is sent once all streams reach it. What's preventing that here?
On Tue Apr 22 17:24:51 2025 +0000, Elizabeth Figura wrote:
Normally EOS is sent once all streams reach it. What's preventing that here?
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/0 ```
These 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)
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. */
-
Brendan McGrath -
Brendan McGrath (＠redmcg)
-
Elizabeth Figura (＠zfigura)