GNOME Bugzilla – Bug 757957
vaapidecodebin: improve context sharing
Last modified: 2015-11-19 11:32:03 UTC
Right now, within the playbin logic, vaapisink will create it's own VADisplay and vaapidecode, inside vaapidecodebin, will create another; finally, vaapipostproc will get the VADisplay from the vaapisink. It is more consistent to vaapidpostproc to get the VADisplay context from the vaapidecode, using the new bin logic for context propagation[1]. But also, the vaapidecodebin should be able to query other elements to find its VADisplay context. For that purpose, we should retake patch [2] which adds the postproc dinamically 1. http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=d5ded1588920c4471eefe055d09095d9e5e989b5 2. https://bugzilla.gnome.org/show_bug.cgi?id=749554#c26
Created attachment 315289 [details] [review] vaapidecodebin: delay the bin configuration Delay the bin configuration until changing to READY state. This is because we should add the vaapipostproc element until the vaapidecode has emitted the HAVE_CONTEXT message, so de gst_bin_add() could set the context set to vaapipostproc. Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Created attachment 315292 [details] [review] vaapidecodebin: add postprocessor dynamically The former approach to left the bin unfinished has some problems: the context cannot be shared because the vaapidecode is unlinked in many cases, leading to creating a VADisplay twice. Initially the bin is fully functional, constructed as (--------------------------------------------------) | vaapidecodebin | | (-------------) (-------) (----------) | |<--| vaapidecode |--->| queue |--->| identity |-->| | (-------------) (-------) (----------) | (--------------------------------------------------) When the context is shared and the VADisplay has VPP capabilities, before changing to READY state, the bin is reconfigured dynamically, adding the vaapipostproc element between the queue and the identity element: (-----------------------------------------------------------------------) | vaapidecodebin | | (-------------) (-------) (---------------) (----------) | |<--| vaapidecode |--->| queue |--->| vaapipostproc |--->| identity |-->| | (-------------) (-------) (---------------) (----------) | (-----------------------------------------------------------------------) Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
@victor: Please add your name/email to vaapidecodebin's gst_element_class_set_static_metadata() and Author under copyright message too :)
Created attachment 315326 [details] [review] vaapidecodebin: delay the bin configuration Delay the bin configuration until changing to READY state. This is because we should add the vaapipostproc element until the vaapidecode has emitted the HAVE_CONTEXT message, so de gst_bin_add() could set the context set to vaapipostproc. Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Created attachment 315327 [details] [review] vaapidecodebin: delay the bin configuration Delay the bin configuration until changing to READY state. This is because we should add the vaapipostproc element until the vaapidecode has emitted the HAVE_CONTEXT message, so de gst_bin_add() could set the context set to vaapipostproc. Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Created attachment 315328 [details] [review] vaapidecodebin: add postprocessor dynamically The former approach to left the bin unfinished has some problems: the context cannot be shared because the vaapidecode is unlinked in many cases, leading to creating a VADisplay twice. Initially the bin is fully functional, constructed as (-----------------------------------) | vaapidecodebin | | (-------------) (-------) | |<--| vaapidecode |--->| queue |--->| | (-------------) (-------) | (-----------------------------------) When the context is shared and the VADisplay has VPP capabilities, before changing to READY state, the bin is reconfigured dynamically, adding the vaapipostproc element afeter the queue: (--------------------------------------------------------) | vaapidecodebin | | (-------------) (-------) (---------------) | |<--| vaapidecode |--->| queue |--->| vaapipostproc |--->| | (-------------) (-------) (---------------) | (--------------------------------------------------------) Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Created attachment 315329 [details] [review] vaapidecodebin: try to get display from decoder Rather than create a dummy display, if none has propagated as a context, we should try to get the one from vaapidecode. As the bin is already in READY state, the vaapidecode should be also in that state. That means that the contexts have been negotiated, and it should have already a display. Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Created attachment 315330 [details] [review] vaapidecodebin: add me as element co-author Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Attachment 315327 [details] pushed as ce3d1a6 - vaapidecodebin: delay the bin configuration Attachment 315328 [details] pushed as bd4395c - vaapidecodebin: add postprocessor dynamically Attachment 315329 [details] pushed as 7c71ffc - vaapidecodebin: try to get display from decoder Attachment 315330 [details] pushed as ac8d19d - vaapidecodebin: add me as element co-author