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.