[PATCH 2/3] winegstreamer: Use decodebin to initialize media streams.

[Derek Lesho]

On 9/11/20 11:24 AM, Zebediah Figura wrote:
> On 9/11/20 10:18 AM, Derek Lesho wrote:
>> On 9/10/20 6:43 PM, Zebediah Figura wrote:
>>
>>> I got the impression from some past communication that the reason for
>>> using appsink in the first place (instead of just a solitary sink pad)
>>> is so that we can buffer, or is there some other reason?
>> Well, buffering is necessary, as media streams operate in a sort of
>> pull/push mode where we can only send them samples if they have
>> requested one with IMFMediaStream::RequestSample.
> Sure, but it also seems potentially simple enough to just wait on a
> semaphore in the chain function.
It's definitely more complicated for a system like that (I used to have 
it that way).  With appsink, we just insert the request sample call into 
a command queue, and pull the buffer from the appsink in the async 
command.  The command queue is completely synchronous so we don't have 
to worry about stuff like seeking or stopping interfering.  With the 
semaphore solution, I'm not sure how much we have to worry about those 
cases, but I remember having all sorts of strange bugs.
>   If it makes sense (for latency reasons)
> to buffer more than that, then there's a potential argument for appsink
> (but also, perhaps, just an argument for appending a queue element after
> each stream). I don't know/remember the relevant details for Media
> Foundation timing.
>
>> Also, appsink is just
>> more convenient than manually setting up a pad, I've also considered
>> changing the source pad to appsrc, but if it isn't broken....
>>
> Is it, though? I don't know what all the things you need to hook up are,
> but it looks to me like you essentially have to set up the same
> callbacks

We don't set up any callbacks for appsink, just pull a buffer when we 
need one.  And given how much boilerplate and how many naming problems 
callbacks cause in winegstreamer, it's probably better this way.

https://github.com/Guy1524/wine/commit/366946876d7a53f80d91749f290f511294415cf5#diff-2873f4b2d2de6a23dbc67b2960e28f88

> , just in a different form. In the case of caps it makes things
> more than a little uglier
What does, appsink or a custom pad?  With appsink all you need to do is 
set the desired caps property.
> , especially if you later end up doing more
> complicated caps negotiation. Note also that GstPad has default handling
> of EOS events and GST_PAD_IS_EOS(), which I'm inclined to understand is
> more useful for MF than handling GST_EVENT_EOS directly.
I'm not sure what you're referring to here.  All we need to do in terms 
of end of stream is read the "eos" property on the appsink during the 
RequestSample-derived command, and dispatch the relevant events.
>