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

Zebediah Figura zfigura at codeweavers.com
Wed Feb 9 10:28:18 CST 2022


On 2/9/22 01:54, Giovanni Mascellani wrote:
> Hi,
> 
> Il 08/02/22 22:13, Zebediah Figura ha scritto:
>> In that case it seems sufficient to check stream->eos in
>> wait_on_sample(). There should be no need to modify the Unix side here.
> 
> Ok, I guess I can try that approach.
> 
>> Somewhat out of curiosity, have you actually observed both
>> MF_E_END_OF_STREAM from RequestSample() and MEError with
>> MF_E_END_OF_STREAM from the same media source on Windows? It seems
>> awkward that we're reporting the same condition in two different ways
>> like that, but if that's the way Windows behaves...
> 
> I wouldn't say it doesn't feel awkward, but not more awkward than the
> rest of MF event architecture. On this specific point, I think that the
> philosophy is pretty transparent, and even decently explained on MSDN:
> when RequestSample() is able to determine at the time of the call that
> the stream is already EOS, it can return the error directly. If it only
> later sees that condition, it has no way other than emitting MEError,
> because the RequestSample() call has already returned.

Okay, makes sense.

> 
> (Now, one might slyly ask what happens if the EOS condition would have
> been cleared between the RequestSample() call and the moment when that
> call would be serviced, for example because another Start() call is in
> the queue; AFAICT, MSDN answers in the most Microsoft way possible: it
> doesn't at all, and I have not researched that specific point)
> 
> At the same time, I admit I did no specific testing, but actually seeing
> the MEError being sent on Windows might be difficult, because you have
> to somehow cause the EOS to be detected between when RequestSample() has
> returned and when it is serviced. I don't know the implementation
> details of Microsoft's media source, so it might take a lot of time
> before I find the right conditions, and maybe it's not really a good
> idea to spend time on that thing.

Yeah, I wasn't suggesting to actually research this, I don't think it's 
really worth looking into. If the documentation says this is how it 
behaves that makes sense.



More information about the wine-devel mailing list