[Cin] Fwd: Re: [Libav-user] NV12->RGB24 vs YUV420P->RGB24
randrianasulu at gmail.com
Thu May 21 19:06:07 CEST 2020
В сообщении от Thursday 21 May 2020 17:12:21 Phyllis Smith написал(а):
> 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
If you use mesa you can try to call GALLIUM_HUD=help cin
and then add relevant for your GPU meters to Gallium HUD
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
> 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...
Size: 552686 bytes
Desc: not available
More information about the Cin