[PATCH v6 5/5] winegstreamer: Replace source pad interface with GstAppSrc.

Zebediah Figura zfigura at codeweavers.com
Fri Sep 24 11:38:29 CDT 2021


On 9/24/21 3:05 AM, Derek Lesho wrote:
> On 9/21/21 13:02, Zebediah Figura wrote:
> 
>>
>>
>> 1. Rely on the fact that seek-data is sent during a seek, and use it
>> to effectively invalidate any buffers sent before the seek. Unlike the
>> aforementioned problem with validation, this will actually work: at
>> the time that seek-data is sent appsrc should be flushing, so any
>> buffers we send before it will be discarded by appsrc, and any buffers
>> we send afterward can be discarded by us if they aren't valid. This is
>> very fragile, though. There's really no reason for appsrc to send
>> seek-data for random-access streams in the first place, and this kind
>> of synchronization is easy to get wrong if I haven't already.
> 
> This sounds like the best way forward in my opinion, how is it fragile?

It's fragile in general because we're making a lot of assumptions, that 
aren't documented, about when and from which thread gstappsrc will send 
these signals, and what synchronization guarantees it applies when doing so.

> It seems that if we just ensure that a pushed buffer takes into account
> the latest seek/need data pair, not much can go wrong.
> 

That's not enough by itself. We can, generally speaking, send a buffer 
after a seek-data/need-data is triggered but before it is actually sent. 
This happens in practice with flushes.

In order to get around that, you need the hack I mentioned: assume that 
a flush will be accompanied by a seek-data signal. This is especially 
fragile because there's no reason for appsrc to even be sending this 
signal in the first place (it only really makes sense in "seekable" 
mode), and they could easily decide to not do that.



More information about the wine-devel mailing list