[PATCH 1/2] winegstreamer: Implement pausing the media source.

Nikolay Sivov nsivov at codeweavers.com
Fri Jun 11 00:55:09 CDT 2021


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.





More information about the wine-devel mailing list