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).