[Cin] Fwd: Re: [Libav-user] NV12->RGB24 vs YUV420P->RGB24

Thu May 21 19:47:55 CEST 2020

В сообщении от Thursday 21 May 2020 17:12:21 Phyllis Smith написал(а):
> Andrew,
> BUT I should have mentioned that there is a problem if the
> Settings->Preferences, Playback A, Video Driver is set to X11-OpenGL.
> There appears to be some thrashing.  I have logged this in BT #434 and am
> hoping a Graphics guru can give us a hint of how to avoid this.  Using X11
> driver works at really good hardware speed.  GG was looking at MPV to try
> to avoid this because according to the Forum topic "Multiple GPUs..." it
> works just fine there, as well as on the ffmpeg command line.  I searched
> on the internet and found no clues.   We are hoping there is some GL
> command to avoid the problem but we are not even close to GL experts.

Additionally .... there seems to be OpenGL/Va-api interop, but it may requre new-ish
libva (2.1?) on AMD:

https://www.phoronix.com/forums/forum/hardware/graphics-cards/1008578-va-api-1-0-video-acceleration-is-approved-for-fedora-28
(from late 2018)

mpv old commit:
https://lab.saloun.cz/jakub/mpv/commit/2d58fb3b8e7e87a939220f50a51294f8efdc51e1
6 years ago it was said

"
VA-API's OpenGL/GLX interop is pretty bad and perhaps slow (renders a
X11 pixmap into a FBO, and has to go over X11, probably involves one or
more copies), and this code serves more as an example, rather than for
serious use. On the other hand, this might be work much better than
vo_vaapi, even if slightly slower."

new code uses EGL, according to comment (if I read it correctly)
https://keybase.pub/chittunoo/githubchittunoo/mpv/libmpv/opengl_cb.h

/**
 * Windowing system interop on Intel/Linux with VAAPI
 * --------------------------------------------------
 *
 * The new VAAPI OpenGL interop requires an EGL context. EGL provides no way
 * to query the X11 Display associated to a specific EGL context, so this API
 * is used to pass it through.

I think in Cin's case those only can be used  with direct mode (no effects),
still, if there way to make va-api *encoder* to eat OpenGL/EGL textures directly ..
May be something like gl_draw_buffers ?

https://stackoverflow.com/questions/30025009/in-opengl-is-it-possible-for-one-shader-program-in-one-draw-call-to-render-to

for making data available  both for GPU encoder and display?

https://github.com/intel/libva/issues/271
Add an API to copy OpenGL textures into VA surfaces  #271
Unfortunately not completely answered ...

from 2017 ...
https://ml01.01.org/hyperkitty/list/intel-vaapi-media%40lists.01.org/message/O6KKFTX66H6T3OTODFQFW6IUOJE244ZO/

----copy---

Re: [intel-vaapi-media] Direct encoding of RGBA surface formats

 Sreerenj  

 Понедельник, 25 Сентябрь 2017   Пн, 25 Сен '17  
11:45 

Hi Matt,
The intel-vaapi-driver only supports YUV420 (and it'z 10 bit variant
too) chroma for encoding except JPEG encode.
Actually restriction is not just YUV420, it only support NV12 format
(and the 10 bit variant too).
But driver has a work around to convert any non-NV12 format to NV12
internally. So ideally other input formats can work too.
Unfortunately there is a performance issue here: the internal conversion
using an AVS sampler for Color space conversion which is not optimal
when comparing with explicit VPP which uses 3D sampler.
So I would recommend to use an explicit vpp (eg: vaapipostproc in
gstreamer) for colorspace conversion before encode.
On 09/25/2017 09:33 AM, Matt Fischer wrote:

...
 This is a question about gstreamer-vaapi as well as
libva-intel-driver.  I hope this is the right list for those
components...if not, please let me know where I ought to ask it instead.
I have a situation where I'd like to encode video using the
gstreamer-vaapi plugins that's in plain RGBA format (it's coming out
of an OpenGL rendering pipeline).  As it stands now, though, the
encoder plugins refuse to set up a pipeline for any format other than
YUV 4:2:0/4:2:2.  This is enforced both by an explicit check in
gstvaapiencoder.c (the is_chroma_type_supported() function), as well
as by querying the VAConfigAttribRTFormat attribute from the
underlying vaDisplay.
Just for curiosity's sake, I tried adding the RGB32 format both into
the gstreamer check, as well as into the list of allowed chroma
formats down in libva-intel-driver (in i965_drv_video.c in the
i965_get_default_chroma_formats() function).  To my surprise, this
seemed to work correctly.  The encoded video played back with correct
colors, suggesting that the underlying i965 encoding hardware is
capable of accepting RGB formats and doing the appropriate color
conversions.
If this is true, is there any chance of adding official support for
RGB formats in the way that my hack did?  It's quite useful to be able
to connect OpenGL rendering into the VAAPI pipeline, and the addition
of RGBA support appears to make that possible.  Are there limitations
that would make this difficult, or is the lack of RGBA support thus
far just an oversight?
Thanks,
Matt
_______________________________________________
intel-vaapi-media mailing list
intel-vaapi-media(a)lists.01.org
https://lists.01.org/mailman/listinfo/intel-vaapi-media

--copy end--

so, sorry if it looks very sketchy .... but this is all I was bale to find
(no Intel / AMD  card to test any of it, yet)

Also, for Intel graphics there are two mesa drivers right now:

i965
and gallium-based Iris

https://www.phoronix.com/scan.php?page=news_item&px=Mesa-20.0-Default-Build-Iris
Intel's "Iris" Gallium3D driver is still making good progress in its goal for Mesa 20.0 to 
switch the default "i965" classic driver to Intel Gallium3D for Broadwell and newer hardware. 

If I remember correctly Phyllis have Broadwell-based GPU in laptop ....
So, GALLIUM_HUD thing probably only will work with new-ish mesa.

sorry for not saying this earlier

> 
> On Thu, May 21, 2020 at 7:25 AM Andrew Randrianasulu <
> randrianasulu at gmail.com> wrote:
> 
> > В сообщении от Thursday 21 May 2020 16:18:49 Phyllis Smith написал(а):
> > > Andrew:
> > >
> > > > Is there anything relevant for Cin's internal working (in case when hw
> > > > decoder is used)?
> > > >
> > >
> > > Quoting GG this morning:
> > > "Not especially.  It appears as a normal codec.
> > > But the data path is through the hardware."
> > >
> >
> > Ah, ok (I thought may be libavcodec was picking slow path in this case)
> >
> > Have good morning/day!
> > --
> > Cin mailing list
> > Cin at lists.cinelerra-gg.org
> > https://lists.cinelerra-gg.org/mailman/listinfo/cin
> >
> 