Dan,

> And from the code you linked here:
https://github.com/freedesktop/mesa/blob/master/src/gallium/state_trackers/omx/bellagio/vid_dec_h265.c

Yep, to show a feature that was ALREADY OPENSOURCED BY MESA that couldn't be
used without additional source which was either not upstreamed or not in a well
known location. Why would I be linking to the source code for something in the
original POST and then asking for the source code to be opensourced via a LGPL
request????? WT#? You are not making sense. Please quit flogging the dead horse
here.

The request was a LGPL source code request to AMD (yes not freedesktop) for
their bundling LGPL licensed libraries libopenmax-bellagilo (not modified in
AMD's case like other openmax implementations were for HEVC suport) OR the LGPL
licensed gst-plugins-omx. 

Yes I am guilty as charged, I used the freedestop.org bug tracker as a shortcut
to get in touch with some AMD devs by only putting the request in the AMD
Gallium section, and it was mission accomplished.

However this request did relates to a feature in MESA gallium state tracker
that can't easily be implemented due to no documentation or info on what
libraries can use said feature, hence why it's also relevant to freedesktop.org
/ mesa support.

---

Christian,

Thanks for your help. The reason I was playing with openmax because of encoding
problems with FFMPEG that are still not resolved, and because ffmpeg vaapi
until recently didn't support EGL / play nice with mpv.

Thanks for linking to the AMD fork of libgst-openmax, I'll see how it works, if
not so good, I think I'll try tizonia-openmax-il as it supports EGL and hope
you'll implement gstreamer h265-encoding/decoding down the track there too. The
openmax interface to the encoder previously was more stable than the
ffmpeg/vaapi one.

Cheers,

Luke