[yocto] [PATCH 1/1] meta-intel: make video acceleration choice dependent on LICENSE_FLAGS

[Tom Zanussi]

On Fri, 2012-09-14 at 21:51 +0100, Burton, Ross wrote:
> On 14 September 2012 20:27,  <tom.zanussi at intel.com> wrote:
> > The gst-ffmpeg recipe in oe-core had LICENSE_FLAGS added to make it
> > "commercial", so to avoid build errors the BSPs that use it (via the
> > gst-va-intel VA_FEATURE) should only include it if the user has added
> > "commercial" to LICENSE_FLAGS_WHITELIST when building.
> 
> It's entirely possible to use gst-vaapi without commercial plugins,
> the problem is the (mysterious to me) dependency on gst-ffmpeg.
> 

>From the gstreamer-vaapi README:

"vaapidecoder currently relies on FFmpeg"

> How about making gst-ffmpeg a recommends instead of rdepends, so that
> if it's blacklisted due to license flags there isn't a build failure.

I can try that and see what happens.

> gst-vaapi doesn't have license issues to making it disappear when
> avoiding commercial licenses doesn't make sense.
> 
> (I'd also like to understand why gst-ffmpeg is a rdepends at all)
> 

The only avenue I was able to find (that worked, an important point) to
get gstreamer to use video acceleration was via ffmpeg (via gst-ffmpeg,
needed for making ffmpeg available to the gstreamer pipeline) with the
--with-vaapi option.

Believe me, I went through a bunch of iterations of different versions
and combinations of all these components before hitting on something
that didn't always segfault and gave more than 1/2 a frame a second
(literally), and that was after using code that supposedly worked for an
ELC demo...

Anyway, it would be nice if someone who had a better understanding of
this 'stack' could suggest better ways of doing things - at this point
it works for 3 different video acceleration implementations (emgd, pvr
and standard intel va) and I'm not looking forward to going through that
exercise again - for now I'll just be trying to fix the build problems
introduced by the new licensing restrictions.

Tom

> Ross