On 2/26/22 11:40, Marvin wrote:
=== debian11 (64 bit WoW report) ===
mf: mf.c:6208: Test failed: ProcessInput returned 0x80004001 mf.c:6213: Test failed: ProcessInput returned 0x80004001
I'll fix these, but also I found that there's going to be an issue with the queue:
Call of Duty Black Ops III really doesn't care about the return status of ProcessInput, and apparently expects a stream change result after a certain number of ProcessInput / ProcessOutput calls.
Adding a queue in front introduces too much decoupling, and we either:
1) don't accept buffers when there's already one in the queue, like here, and as the game doesn't even bother pushing the sample again we then miss some,
2) or, if we queue more buffers, accept too many input buffers and the game is confused that it pushed too many samples before receiving its stream change result,
It is possible, and I was doing this locally with an earlier version using a queue, to put the queue in the middle of the pipeline, after the h264 decoder element.
It helps this particular case as pushing a buffer also parses it and triggers the caps change, or output buffer, but it then causes some problems I need to resolve first.
More specifically, if we block on the output end, waiting for ProcessOutput like here, we won't process queries that could be triggered concurrently by a gst_pad_push, causing a deadlock.