[Libva] [PATCH] vainfo/va.h: add VAProfileCount in va.h.
Gwenole Beauchesne
gb.devel at gmail.com
Tue Jul 9 03:56:49 PDT 2013
Hi,
2013/7/9 Zhao, Halley <halley.zhao at intel.com>:
> How do you expect ffdec_mpeg4 is picked up when vaapidecode also claims to support mpeg4? (they have same rank).
> The issue is reported from Tizen/ivi, it isn't only reproduced on my pc.
Simple: get_caps() returns the expected set of codecs supported by the
hardware. So, if MPEG-4:2 is not supported, then it's not reported in
caps, and then the auto-plugger tries to find another decoder, which
yields ffdec_mpeg4 if it is installed.
> For gst-vaapi code, I use your 0.4-branch.
The 0.4-branch is obsolete and is missing several other fixes. In particular,
cadc42eafea8de67f2d93a2d2f1d4f9dcd372d1b
Regards,
Gwenole.
>> -----Original Message-----
>> From: Gwenole Beauchesne [mailto:gb.devel at gmail.com]
>> Sent: Tuesday, July 09, 2013 4:50 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/9 Zhao, Halley <halley.zhao at intel.com>:
>> > 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
>>
>> I will try on Sandybridge, but on Ivybridge and Ubuntu 12.04-LTS, I
>> could not reproduce that. The SW decoder from ffmpeg is correctly
>> picked up and the stream is playing. I don't expect any issue on
>> Sandybridge either.
>>
>> The system GStreamer 0.10 stack comes from the original Ubuntu 12.04-
>> LTS packages, and this includes gst-ffmpeg.
>> The system GStreamer 1.0 stack comes from Ubuntu 13.04, and this
>> includes gst-libav.
>> In both cases, MPEG-4:2 are correctly played back while gst-vaapi is
>> installed.
>>
>> I think you probably have other local changes that break the normal
>> behaviour. Is this upstream gst-vaapi?
>>
>> Regards,
>> Gwenole.
>>
>> > -----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