On 9/21/20 10:56 AM, Derek Lesho wrote:
Well, for that matter, you don't exactly need to use gst_app_sink_pull_preroll(); gst_app_sink_pull_sample() also blocks. But I'm led to believe that mfplat requires you to know the caps before you start queuing samples.
Well, as of right now, our pipeline is fully setup in the stream-added callback for decodebin, so it's not like once we know our caps, we have to modify the pipeline elements. Also, this is completely transparent to media foundation, pulling from the preroll queue will not affect the main queue. Of course, in the case where media source user decides to use a different type (which pretty much means using videoconvert or audioconvert), we just update the appsink "caps" property and the caps are renegotiated.
That seems about right, actually. (I think you also need to restart the pipeline, but that's true no matter what.) With this in mind I'm inclined to think that appsink + static caps renegotiation + gst_app_sink_pull_preroll() is the best fit for mfplat.
I actually thought that GstPad had similar support for static caps, but it doesn't really—only support for setting the caps at creation time, which is usable but at that point not actually better than GstAppSink.