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

[Giovanni Mascellani]

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.

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

Giovanni.