GNOME Bugzilla – Bug 745216
Add a vaapidecodebin element
Last modified: 2015-03-09 14:56:27 UTC
Add a "vaapidecodebin" element to vaapi plugins. Child Elements: "vaapidecode ! queue ! vaapipostproc" This has a number of major advantages: -- Autoplugging of vaapipostproc with out dependency to upstream gstreamer. Nowadays it is taking multiple months (sometimes multiple years too!!) to get something non-trivial accepted in upstream, which is really blocking the gstreamer-vaapi development. eg:https://bugzilla.gnome.org/show_bug.cgi?id=687182. This has other side benefits like, no need to wait for upstream stable releases, customers using older gstreamer versions (1.2 and 1.4) will also get the benefit of autoplugging and hardware accelerated deinterlacing support etc.. -- Use a single thread implementation in vaapidecode and still maintains the parallelism through the usage of queue element in vaapidecodebin (which means there is no explicit user requirements like "always add queue in pipeline manually"). This will result a dead-lock free vaapidecode in most of the cases (more details here:https://bugzilla.gnome.org/show_bug.cgi?id=742605 )
commit 8eabe9f3774eedf14a029da3385b744f38af4b19 Author: Sreerenj Balachandran <sreerenj.balachandran@intel.com> Date: Mon Mar 2 15:19:40 2015 +0200 plugins: Add a vaapidecodebin element Add a "vaapidecodebin" element to vaapi plugins. Child Elements: "vaapidecode ! queue ! vaapipostproc" The Reasons for implementing a new bin element: -- Help to Autoplug Hardware Accelerated Video Postprocessing element in playbin with out any dependency to upstream gstreamer. This is to overcome the *unacceptable* delay in upstream gstreamer to get new features in. Eg: https://bugzilla.gnome.org/show_bug.cgi?id=687182. Also customers using older gstreamer versions (1.2 and 1.4) will get the benefit of autoplugging, hardware accelerated deinterlacing support etc. -- Help to maintain a single thread implementation in vaapidecode. This will result a dead-lock free vaapidecode in most of the cases. More details here: https://bugzilla.gnome.org/show_bug.cgi?id=742605 https://bugzilla.gnome.org/show_bug.cgi?id=745216
Adding myself to CC list for this bug. I don't have time today to test vaapidecodebin, but will look at it and report back here later today, and test later this week.
One comment on the code (not been able to test yet); you don't expose any of the vaapipostproc properties to the user, nor are they controlled by other means (e.g. GstMeta). We've found that the default deinterlace-mode looks bad in most situations, and it's useful to be able to change it from 'bob' to 'motion-compensated' or 'motion-adaptive'.
I deliberately did that :) .. I would like to get some discussion on this topic. Whether to make it simple which is only useful for playbin and don't expose any properties OR to make it as a replaceable element for vaapipostproc too. Will get back to this later...
(In reply to sreerenj from comment #4) > I deliberately did that :) .. > I would like to get some discussion on this topic. > Whether to make it simple which is only useful for playbin and don't expose > any properties OR to make it as a replaceable element for vaapipostproc too. > > Will get back to this later... Maybe worth discussing a change to the default deinterlace-method? "bob" looks awful, whereas (assuming field order is right in the source material) "motion-compensated" looks good on HSW, and falls back nicely to "motion-adaptive" on SNB and "bob" on things that can't do advanced deinterlacing.
Lets move the discussion to https://bugzilla.gnome.org/show_bug.cgi?id=745901