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

[Zebediah Figura]

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. 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, just in a different form. In the case of caps it makes things
more than a little uglier, 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200911/8bc628f8/attachment.sig>