On Wed May 24 19:28:47 2023 +0000, Paul Gofman wrote:
I've checked (with both the tests in the patchset and a bit different ones I had on the matter) and it seems to work here. There is an unrelated failure with my older test though from Proton patches. That is not about flushing the pipeline but checking sample size before querying the data from wg_transform, which check is wrong because the call might not need to output a sample at all or maybe return a sample of a smaller size. I am attaching the test and a Proton patch which is fixing that (rebased on top of the present MR). This is apparently a different aspect orthogonal to what this MR, attaching that for future reference only. [0001-mf-tests-Add-a-test-with-h264-reuse-with-a-different.patch](/uploads/dc71eb65faa61f463f0cccc5540587fd/0001-mf-tests-Add-a-test-with-h264-reuse-with-a-different.patch) [0002-winegstreamer-Don-t-pre-check-sample-size-in-wg_tran.patch](/uploads/581fe905c6ca3e4f1c11eaf162d5ef10/0002-winegstreamer-Don-t-pre-check-sample-size-in-wg_tran.patch)
Thanks, I've included a similar test into the concatenated stream test. I believe the problem only happens before the first stream type change, when we don't know yet what size the buffer should be.
I've split these into https://gitlab.winehq.org/wine/wine/-/merge_requests/2901, which I think should come before this MR, as generating the timestamps ourselves also solve the mismatches that drain and flush are sometimes causing.
It doesn't look like Windows really respect the stream embedded information that h264parse generates, and once we do it ourselves it becomes useless, so I've removed the element and it then works pretty much like Proton.