After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 624697 - Add 'video/x-raw-va' in DEFAULT_RAW_CAPS for va api support
Add 'video/x-raw-va' in DEFAULT_RAW_CAPS for va api support
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-07-19 05:35 UTC by Zhao, Halley
Modified: 2012-09-12 08:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Zhao, Halley 2010-07-19 05:35:18 UTC
1.
raw caps are defined in $gst-plugins-base/gst/playback/gstrawcaps.h:
#define DEFAULT_RAW_CAPS \
    "video/x-raw-yuv; " \
    "video/x-raw-rgb; " \
    "video/x-raw-gray; " \
    "audio/x-raw-int; " \
 ...
decodebin depends on this raw caps to stop auto-plug (expose_pad).

2. 
libva is designed to enable hardware accelerated video decode/encode at various entry-points (VLD, IDCT, Motion Compensation etc.)
http://freedesktop.org/wiki/Software/vaapi

3. 
we need a new raw caps like 'video/x-raw-va' adding to DEFAULT_RAW_CAPS for libva support in gst.
Comment 1 Zhao, Halley 2010-07-19 05:40:00 UTC
proposed patch attached:

diff --git a/gst/playback/gstrawcaps.h b/gst/playback/gstrawcaps.h
index 0297e33..a791869 100644
--- a/gst/playback/gstrawcaps.h
+++ b/gst/playback/gstrawcaps.h
@@ -29,6 +29,7 @@ G_BEGIN_DECLS
     "video/x-raw-yuv; " \
     "video/x-raw-rgb; " \
     "video/x-raw-gray; " \
+    "video/x-raw-va; " \
     "audio/x-raw-int; " \
     "audio/x-raw-float; " \
     "text/plain; " \
Comment 2 Sebastian Dröge (slomo) 2010-07-19 07:13:33 UTC
Is the va stuff autoplugged? Are the va elements only working (e.g. setting them to READY succeeds) if the hardware supports the required features?
Comment 3 Zhao, Halley 2010-07-19 08:30:59 UTC
in some condition, va stuff is autoplugged, because playbin2 could stop auto-plug when it realize it has come to a sink element.
but if we set playbin2 'video-sink' property with customized sink, customized sink doesn't work. 
    1. decodebin2 auto-plug doesn't stop when it comes to 'video/x-raw-va'
    2. then it will comes to a sink (vaimagesink for example)
    3. playbin2 will stop auto-plug in autoplug_select_cb() when it find a sink element is reached.
    4. playbin2 will use vaimagesink in no_more_pads_cb(), while not the sink set by 'video-sink' property.

va element only works if the hardware supports the required features.
Comment 4 Sebastian Dröge (slomo) 2010-07-19 08:43:23 UTC
(In reply to comment #3)
> in some condition, va stuff is autoplugged, because playbin2 could stop
> auto-plug when it realize it has come to a sink element.
> but if we set playbin2 'video-sink' property with customized sink, customized
> sink doesn't work. 
>     1. decodebin2 auto-plug doesn't stop when it comes to 'video/x-raw-va'

That's what the autoplug-continue is used for. playbin2 checks (should check) if the sink supports the caps and tell decodebin2 to stop autoplugging in that case.

>     2. then it will comes to a sink (vaimagesink for example)

That's a bug in your sink then, decodebin2/uridecodebin must not autoplug sinks and will not autoplug sinks unless they have the wrong classification in the element details (does your sink say it's a Decoder or Parser or Demuxer or Depayloader? If it does: that's the problem)

> va element only works if the hardware supports the required features.

Does that mean, that changing the state of those elements to READY will fail? Or will the elements fail later? If they fail later that's a problem for autoplugging (e.g. if you have the va elements on hardware that doesn't support va).
Comment 5 Zhao, Halley 2010-07-19 09:06:10 UTC
(In reply to comment #4)
> (In reply to comment #3)
> >     1. decodebin2 auto-plug doesn't stop when it comes to 'video/x-raw-va'
> 
> That's what the autoplug-continue is used for. playbin2 checks (should check)
> if the sink supports the caps and tell decodebin2 to stop autoplugging in that
> case.
I mean decodebin2 doesn't 'goto expose_pad' in analyze_new_pad() because are_raw_caps() fail for 'video/x-raw-va'.
> 
> >     2. then it will comes to a sink (vaimagesink for example)
> 
> That's a bug in your sink then, decodebin2/uridecodebin must not autoplug sinks
> and will not autoplug sinks unless they have the wrong classification in the
> element details (does your sink say it's a Decoder or Parser or Demuxer or
> Depayloader? If it does: that's the problem)
> 
> > va element only works if the hardware supports the required features.
> 
> Does that mean, that changing the state of those elements to READY will fail?
> Or will the elements fail later? If they fail later that's a problem for
> autoplugging (e.g. if you have the va elements on hardware that doesn't support
> va).
those elements fail when setting to READY.
Comment 6 Robert Jobbagy 2011-07-28 13:45:44 UTC
somebody works on VA project or gst VA support ?
Comment 7 Tim-Philipp Müller 2011-07-28 13:53:59 UTC
> somebody works on VA project or gst VA support ?

Yes.
Comment 8 Tim-Philipp Müller 2012-09-12 07:54:10 UTC
What's up with this? Is this still needed. I thought it Just Worked(tm) now in playbin2, even in 0.10?
Comment 9 Zhao, Halley 2012-09-12 08:07:58 UTC
gstreamer-vaapi works in playbin2: https://gitorious.org/vaapi/gstreamer-vaapi.
so, you can close it if you like.

however, I don't think it works perfect now, because:
auto-plug ends when a sink element is connected (vaapisink), not by pre-defined caps type.
maybe we can add 'video/x-surface;' to the list.

use raw_caps (default one or set from app) to control auto-plug is more flexible than ends with a sink element. for example: we sometimes do require raw caps, thumbnail generation is one case. in such case vaapidownload element can be auto-pluged to get the raw data of a hw surface.
Comment 10 Edward Hervey 2012-09-12 08:36:04 UTC
For 1.0 we will not add this. It should have caps of video/x-raw and use/expose the needed GstMeta.

So if it works in 0.10 ... shall we close this ?
Comment 11 Tim-Philipp Müller 2012-09-12 08:47:42 UTC
Yes, I'd prefer to close this and focus on making it work nicely in 1.0.

I'm reluctant to add this to 0.10 at this point (and it'd be unlikely to ever get released anyway, so probably not so useful anyway).