On 6/10/21 10:17 PM, Giovanni Mascellani wrote:
Hi,
Il 10/06/21 18:12, Derek Lesho ha scritto:
This patch probably warrants a few tests. I would test at least
In line of principle I would agree. The reason I am not submitting any is that Nikolay told me on the chat, as I understand it, that for this kind of patches he prefers tests to be left out-of-tree. Since he is the one who usually reviews my MF patches, I am inclined to meet his requests.
That was about event tests mostly, that proved to be a problem. Test programs are still useful obviously.
- what happens to ::RequestSample calls when a stream is paused.
As soon as the source is restarted, a corresponding number of MEMediaSample is generated.
I assumed that this means that samples are generated anyway during pause and are later emitted after Start, but as others have noted this is not necessarily true: requests could be queued instead of samples. The two cases differ for example if the Start includes a seek (if requests are stored, then samples are emitted at the freshly seeked location, otherwise they are emitted at the location of pausing). And thinking again about it storing the requests seems more logical than storing the samples. Tomorrow I'll check on Windows to see what's happening there.
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.
- whether MESourcePaused or the MEStreamPaused events come first.
Hmm, does this really make sense? They are emitted on two different queues. Does MF guarantees order of delivery across different queues? Even if one is submitted before the other, the system scheduler might decide to execute in the opposite order, if it wakes up the other thread first. Or is there a stronger guarantee?
They don't explicitly guarantee that, but I think it's more reliable than it appears to be.