[Libva] [PATCH] vainfo/va.h: add VAProfileCount in va.h.
Zhao, Halley
halley.zhao at intel.com
Mon Jul 8 17:27:23 PDT 2013
No, sw codecs will not be picked up, ( I will send you a mpeg4-2 stream for test).
Playbin2 (I haven't check it for gst1.0 yet) filters a set of element which support a given cap, playbin2 try to link one of them (ordered by rank) with uplink srcpad.
If link success, it will NOT try other elements (even if there is failure in the future auto-plug).
If link failure, it will try another element with lower rank.
I tried a simple test (gst0.10, since I don't want to install gst-ffmpeg for gst1.0 in my Ubuntu12.04, I think it should be same for gst1.0):
1) install gst-ffmpeg only, (no gst-vaapi); mpeg4 stream is ok to play
2) install gst-vaapi, mpeg4 stream fail to play; since qtdemux fail to push data downlink
3) apply my patch, then mpeg4-2 stream comeback to play.
By the way:
I don't know when "decode->is_ready" is added in gst_vaapidecode_get_caps, it will disable my improvement.
I temporarily disable that for my test.
-----Original Message-----
From: Gwenole Beauchesne [mailto:gb.devel at gmail.com]
Sent: Monday, July 08, 2013 3:33 PM
To: Zhao, Halley
Cc: libva at lists.freedesktop.org
Subject: Re: [Libva] [PATCH] vainfo/va.h: add VAProfileCount in va.h.
Hi,
2013/7/8 Zhao, Halley <halley.zhao at intel.com>:
> You shouldn't assume there is no other sw codec in system.
> For example, there is fluendo sw code in tizen/pc; there is ffmepg sw codec in tizen/mobile.
Yes, and the SW codecs will be picked up instead, if they are indeed installed. So, I still don't see the issue here, please be more specific.
Thanks,
Gwenole.
> -----Original Message-----
> From: Gwenole Beauchesne [mailto:gb.devel at gmail.com]
> Sent: Friday, July 05, 2013 5:23 PM
> To: Zhao, Halley
> Cc: libva at lists.freedesktop.org
> Subject: Re: [Libva] [PATCH] vainfo/va.h: add VAProfileCount in va.h.
>
> Hi,
>
> 2013/7/5 Zhao, Halley <halley.zhao at intel.com>:
>
>> Return back to gst-vaapi:
>> It is one issue reported by dlna client (they may not use gst playbin).
>
> They used playbin.
>
>> Anyway, in get_caps, we'd return real hw capability instead of gst-vaapi supported features.
>> The patch looks like attachment, I haven't update it according to vaMaxNumProfiles/vaQueryConfigProfiles yet.
>
> This patch is still not needed.
>
> For JPEG images or videos, jpegdec gets auto-plugged. For MPEG-4:2 videos, there is no SW decoder either because xviddec is not ported to GStreamer 1.0 APIs. You could try gst libav/ffmpeg plug-ins too, but I don't think they would go to the release.
>
> Regards,
> Gwenole.
>
>>> -----Original Message-----
>>> From: Gwenole Beauchesne [mailto:gb.devel at gmail.com]
>>> Sent: Thursday, July 04, 2013 1:19 AM
>>> To: Zhao, Halley
>>> Cc: libva at lists.freedesktop.org
>>> Subject: Re: [Libva] [PATCH] vainfo/va.h: add VAProfileCount in va.h.
>>>
>>> Hi,
>>>
>>> 2013/7/3 Zhao, Halley <halley.zhao at intel.com>:
>>> > This patch helps middleware (gst-vaapi for example) not over
>>> > commit
>>> capability.
>>>
>>> I don't understand this usage model. vaQueryConfigProfiles() will
>>> report the correct number of VA profiles returned in profile_list[]
>>> array. There is no risk of overcommit unless the API is mis-used or
>>> the VA driver not returning the right number of profiles. This used
>>> to be the case with a pretty ancient version of the PowerVR driver,
>>> but the Intel HD Graphics driver does not have this issue AFAIK.
>>>
>>> > The scenario is:
>>> > Gst-vaapi supports mpeg4 and jpeg decoder, but Sandybridge hw
>>> > doesn't
>>> really support that.
>>> > Some player may misuse vaapidecode.
>>>
>>> What is the root cause of this issue please? Do you mean vaapidecode
>>> was auto-plugged in whereas the HW does not support that codec? This
>>> sounds like a bug though the current gstreamer-vaapi git and back to
>>> 0.5.3 actually does not exhibit this behaviour. i.e. SW decoding
>>> plug- in elements are plugged in if the underlying HW doesn't
>>> support acceleration for MPEG-4:2 or JPEG for example. Only tested
>>> with JPEG though.
>>>
>>> Regards,
>>> Gwenole.
>>>
>>> >> -----Original Message-----
>>> >> From: Zhao, Halley
>>> >> Sent: Wednesday, July 03, 2013 5:47 PM
>>> >> To: libva at lists.freedesktop.org
>>> >> Cc: Zhao, Halley
>>> >> Subject: [PATCH] vainfo/va.h: add VAProfileCount in va.h.
>>> >>
>>> >> it facilitate driver capability probing.
>>> >> ---
>>> >> test/vainfo/vainfo.c | 2 +-
>>> >> va/va.h | 3 ++-
>>> >> 2 files changed, 3 insertions(+), 2 deletions(-)
>>> >>
>>> >> diff --git a/test/vainfo/vainfo.c b/test/vainfo/vainfo.c index
>>> >> 2578d30..1f35693 100644
>>> >> --- a/test/vainfo/vainfo.c
>>> >> +++ b/test/vainfo/vainfo.c
>>> >> @@ -111,7 +111,7 @@ int main(int argc, const char* argv[])
>>> >> printf("%s: Driver version: %s\n", name, driver ? driver :
>>> >> "<unknown>");
>>> >>
>>> >> printf("%s: Supported profile and entrypoints\n", name);
>>> >> - for (profile = VAProfileNone; profile <=
>>> >> VAProfileH264ConstrainedBaseline; profile++) {
>>> >> + for (profile = VAProfileNone; profile < VAProfileCount;
>>> >> profile++) {
>>> >> char *profile_str;
>>> >>
>>> >> va_status = vaQueryConfigEntrypoints(va_dpy, profile,
>>> >> entrypoints, diff --git a/va/va.h b/va/va.h index
>>> >> 0eceea7..b25a55b
>>> >> 100644
>>> >> --- a/va/va.h
>>> >> +++ b/va/va.h
>>> >> @@ -286,7 +286,8 @@ typedef enum
>>> >> VAProfileVC1Advanced = 10,
>>> >> VAProfileH263Baseline = 11,
>>> >> VAProfileJPEGBaseline = 12,
>>> >> - VAProfileH264ConstrainedBaseline = 13
>>> >> + VAProfileH264ConstrainedBaseline = 13,
>>> >> + VAProfileCount = 14
>>> >> } VAProfile;
>>> >>
>>> >> /*
>>> >> --
>>> >> 1.7.9.5
>>> >
>>> > _______________________________________________
>>> > Libva mailing list
>>> > Libva at lists.freedesktop.org
>>> > http://lists.freedesktop.org/mailman/listinfo/libva
More information about the Libva
mailing list