[oi-dev] gstreamer1 and OpenGL/EGL

[Tim Mooney]

In regard to: gstreamer1 and OpenGL/EGL, Tim Mooney said (at 2:44pm on Oct...:

> I'm working my way through updating the gstreamer1 components to the
> latest version (1.16.2 -> 1.18.5).  They've switched from autoconf to
> meson, so the biggest hurdle has been converting the Makefile to use
> the new configuration options.

With a bunch of help from Andreas, I've made good progress on these
updates.

There are lots of optional things that aren't being built, but in reading
through the options, there's a couple of dependencies that might be useful
to add (eventually):

- the modified Fraunhaufer AAC codec, fdk-aac, which is supposedly quite
   good:

   https://en.wikipedia.org/wiki/Fraunhofer_FDK_AAC

   It builds very easily on OI.

- We already have libx264 in encumbered, but several A/V packages could
   also make use of OpenH264:

   	https://www.openh264.org/

   That would require some porting, though, as it currently only has
   knowledge of headers and such for Linux, MacOS, FreeBSD and Android.
   It may be difficult and not worth the effort, or it might be easy. I'll
   try find out in the next couple weeks.

I have a couple questions about these, though.

1) both components are ostensibly codecs and we have a FMRI "namespace"
    for codecs, but there aren't many packages in there and some packages
    that I might have guessed would be under codec/ are instead in
    libraries/audio/ or just video/

    So what defines whether codec/fdk-aac or codec/openh264 is a better fit
    than e.g. library/audio/fdk-aac ?  What are the guidelines that would
    help someone decide whether these two packages should go?  I personally
    would probably choose codec/ for both of them, but if there are some
    guidelines that can help clarify, I would be happy to hear them.

2) openh264 has a very open license so there are no licensing concerns
    with including it in OI.  It wouldn't even need to go in encumbered,
    which is a potential "pro" for including it.

    I'm less certain about fdk-aac.  According to the licensing section of
    that wikipedia article, both Red Hat's legal team and the EFF have
    decided fdk-aac is "open", at least for redistribution, but apparently
    to actually use it the end user should have a "use license".

    Anyone have any aversion to including this because of licensing issues?
    I tempted to say this wouldn't need to go in encumbered either, but
    it's less clear with fdk-aac.

Thanks,

Tim
-- 
Tim Mooney                                             Tim.Mooney at ndsu.edu
Enterprise Computing & Infrastructure /
Division of Information Technology    /                701-231-1076 (Voice)
North Dakota State University, Fargo, ND 58105-5164