[PATCH v2] winegstreamer: Do not block forever if EOS races with command queue.

Nikolay Sivov nsivov at codeweavers.com
Fri Feb 25 11:17:44 CST 2022



On 2/25/22 19:47, Giovanni Mascellani wrote:
> Hi,
>
> Il 25/02/22 17:22, Nikolay Sivov ha scritto:
>> I tested for Source Reader, and error event is ignored there, it 
>> won't break anything, but won't trigger MF_SOURCE_READERF_ERROR or 
>> MF_SOURCE_READERF_ENDOFSTREAM. In our case it will rely on 
>> MEEndStream being sent before MEError, otherwise it will wait 
>> forever. So at least for reader sending MEError here is unnecessary, 
>> will check the session next.
>
> It's embarrassing how Microsoft seems unable to properly use the 
> (terrible) interfaces they invented themselves. I guess that from the 
> point of view of the bug I was trying to solve, the really important 
> point is to avoid being stuck waiting for an EOS that will never come 
> (because it has already been processed), which blocks the whole media 
> source command queue. I think that queueing an error is a good thing 
> because it makes sense and because it follows the specifications, but 
> maybe is not required for that bug.

I don't think there is anything broken with interface itself. The 
problem is how our source is working - during last successful 
RequestSample -> MEMediaSample response it's probably meant to figure 
out that eos is reached. This way it could fail next request properly.

I'm not proposing to remove MEError right now, but I'll look at fixing 
the other thing I mentioned.

>
> Giovanni.
>




More information about the wine-devel mailing list