Hi,
Il 11/06/21 07:55, Nikolay Sivov ha scritto:
Counter sounds certainly easier. How are you going to check that on Windows? By looking at stream data access? Event if it does read when paused, I don't know if we care, because that shouldn't happen in session context, and in source reader context source is never paused.
No, I am not looking at the stream access. I don't think it is really meaningful to do it, it can depends on a lot of implementation details, including local caching, and I don't want to unravel that.
What I noticed is the following observable behavior on Windows: if you request samples while the stream is paused and then restart without seeking, then you immediately receive a corresponding number of samples, of course starting from the position you left your stream at. I don't know whether they have been processed while the stream was paused or just after it was restarted, but it shouldn't matter much, because I need to replicate the behavior of the media source, not its internal status.
When I pause the media source, request samples and then restart with a seek, then the sample requests I had done while paused are dropped.
In order to implement this behavior, it is enough to queue sample requests while paused, together with their tokens. After yesterday's discussion, this seems more sensible than queuing samples, because it saves on CPU time and memory.
I will submit an updated version of my patch soon.
Giovanni.