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.