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

[Andrew Randrianasulu]

В сообщении от 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.

Well, I remember Cin works with Pbuffers, and those may be
implemented not very optimally (at least in opensource drivers).

I'm not sure if compositing done to specialized pixel buffer, and then displayed with
double-buffering (or just pointer dance/pageflipping around 2x sized buffer), or Cin tries
to composite directly to front buffer? (with X compositing it will be
not real front buffer anyway...)

May be having small 'pool' of those pixel buffers will avoid stalls in decode->effects-> composite 
pipeline ...

If you use mesa you can try to call GALLIUM_HUD=help cin

and then add relevant for your GPU meters to Gallium HUD

Available names:
    fps
    frametime
    cpu
    cpu0
    cpu1
    cpu2
    cpu3
    samples-passed
    primitives-generated
    ia-vertices
    ia-primitives
    vs-invocations
    gs-invocations
    gs-primitives
    clipper-invocations
    clipper-primitives-generated
    ps-invocations
    hs-invocations
    ds-invocations
    cs-invocations
[..]

GALLIUM_HUD=fps,frametime,cpu,instructions,samples-passed cin

for example

So, it will look like attached screenshot

Try to avoid readbacks, like glReadPixels - they tend to be slow even for PCI-E
attached GPU ... May be play with different  pixelfformats (RGBA vs ARGB),
some of them might be faster, or situation might change from times when this code was first
implemented ....


> 
> 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
> >
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: cin_HUD.png
Type: image/png
Size: 552686 bytes
Desc: not available
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20200521/a1579471/attachment-0001.png>