On Wed, 20 May 2020, Emanuele Oriani wrote:
If that was the only concern against it, then I'd say it is acceptable.
> But there are some other concerns, also it seems to me xcbgrab can be
> improved to reach the same smoothness as this attempt, and that was the
> main distinctive feature of
On 20.05.2020 14:31, Nicolas George wrote:
Anton Khirnov (12020-05-20):
You said it: "from the user". The user chose it. The documentation says
"this demuxer user OpenGL, don't use it if applications are not ready
for it", the user chose to use it.
That means we are now forcing all the
Anton Khirnov (12020-05-20):
> > You said it: "from the user". The user chose it. The documentation says
> > "this demuxer user OpenGL, don't use it if applications are not ready
> > for it", the user chose to use it.
>
> That means we are now forcing all the application to be aware that
>
Quoting Nicolas George (2020-05-20 11:34:04)
> Anton Khirnov (12020-05-20):
> > To a calling program, this demuxer would appear as any other demuxer.
> > Many programs using libavformat will take the demuxer name from the user
> > and use it as-is, which might break them in non-obvious ways if
Anton Khirnov (12020-05-20):
> To a calling program, this demuxer would appear as any other demuxer.
> Many programs using libavformat will take the demuxer name from the user
> and use it as-is, which might break them in non-obvious ways if they use
> OpenGL themselves.
You said it: "from the
Quoting Nicolas George (2020-05-20 10:47:57)
> Anton Khirnov (12020-05-20):
> > For what my opinion is worth, I agree with Lynne here. Messing with
> > OpenGL global state in the libraries is something we absolutely should
> > not do.
>
> Good thing we would not be "messing with" anything. We
Anton Khirnov (12020-05-20):
> For what my opinion is worth, I agree with Lynne here. Messing with
> OpenGL global state in the libraries is something we absolutely should
> not do.
Good thing we would not be "messing with" anything. We would be using
the global OpenGL state at the request of the
Quoting Lynne (2020-05-19 21:52:29)
>
> That's a driver issue, no fault of kmsgrab, and I can't even confirm seeing
> those bugs happen to anyone
> using kmsgrab, either on intel or amd, so maybe your system state was
> somewhat broken?
> Either way, there's still the issue of OpenGL state,
> If that was the only concern against it, then I'd say it is acceptable.
> But there are some other concerns, also it seems to me xcbgrab can be
> improved to reach the same smoothness as this attempt, and that was the
> main distinctive feature of it. With that advantage lost, I'd say fixing
>
On Tue, 19 May 2020, Nicolas George wrote:
Marton Balint (12020-05-19):
As Nicolas mentioned, kmsgrab practically requires root. Also, I tried it on
Intel half a year ago on Ubuntu 18.04, and it simply does not work
correctly. There were crashes, there were random failures with cryptic error
May 19, 2020, 19:02 by c...@passwd.hu:
>
>
> On Tue, 19 May 2020, Lynne wrote:
>
>> May 19, 2020, 09:23 by e...@fastwebnet.it:
>>
>>> Hi Marton,
>>>
>>> Thanks very much for the feedback; below answers to your points - let me
>>> know further feedback if any.
>>>
And sorry, I cannot say how
On Tue, 19 May 2020, Lynne wrote:
May 19, 2020, 11:25 by e...@fastwebnet.it:
I wouldn't be surprised if the xlib code has some PTS issues and schedules
downloading a frame late.
I'm far from being an expert, but I would be surprised if that had issues
considering it's the main Linux
Marton Balint (12020-05-19):
> As Nicolas mentioned, kmsgrab practically requires root. Also, I tried it on
> Intel half a year ago on Ubuntu 18.04, and it simply does not work
> correctly. There were crashes, there were random failures with cryptic error
> messages, usually at the beginning of
May 19, 2020, 13:09 by geo...@nsup.org:
> Nicolas George (12020-05-19):
>
>> The doc says:
>>
>> Requires either DRM master or CAP_SYS_ADMIN to run.
>>
>> Does it work for a normal user on a desktop distribution freshly
>> installed, without configuration?
>>
>> (I should test, but all my boxes
On Tue, 19 May 2020, Lynne wrote:
May 19, 2020, 09:23 by e...@fastwebnet.it:
Hi Marton,
Thanks very much for the feedback; below answers to your points - let me know
further feedback if any.
And sorry, I cannot say how useful this would be, maybe now is the time
for people to speak up
May 19, 2020, 11:25 by e...@fastwebnet.it:
> Hi Lynne,
>
> Thanks for the feedback.
> Some more discussion points below.
>
>> There already is a zero-overhead capture on linux - kmsgrab. It works on AMD
>> and Intel.
>>
>
> Does it work on Nvidia too? Does it have smooth capture?
> Does it work
May 19, 2020, 11:40 by geo...@nsup.org:
> This is me NAKing your NAK.
>
You're not allowed to remove NAKs of other developers.
Feel free to disagree of course.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Lynne (12020-05-19):
> You underestimate how many library users use OpenGL.
Oh, I just noticed two seconds after sending: There is a big reasoning
mistake here.
I do not underestimate how many library users use OpenGL.
You overestimate how many library users use OpenGL and allow users to
use
Lynne (12020-05-19):
> New versions of libdrm can allow it to work without root. It needs
> modifications.
When these versions have landed in Debian Stable, we will see. In the
meantime, it is useful now.
> You underestimate how many library users use OpenGL.
> My NAK still stands, whether you
May 19, 2020, 09:23 by e...@fastwebnet.it:
> Hi Marton,
>
> Thanks very much for the feedback; below answers to your points - let me know
> further feedback if any.
>
>> And sorry, I cannot say how useful this would be, maybe now is the time
>> for people to speak up if somebody is particularly
Nicolas George (12020-05-19):
> The doc says:
>
> Requires either DRM master or CAP_SYS_ADMIN to run.
>
> Does it work for a normal user on a desktop distribution freshly
> installed, without configuration?
>
> (I should test, but all my boxes are very far from the default
>
Lynne (12020-05-19):
> You're not allowed to remove NAKs of other developers.
Says who? “NAK”s have no value anyway.
> Feel free to disagree of course.
Feel free to provide the technical information useful to make the
discussion go forward:
# Does it work for a normal user on a desktop
Out of curiosity if I was proposing/using the native NVidia proprietary
library for screen capture (linked at runtime dynamically), would that
be more acceptable in terms of conflicts (I wouldn't like it because it
wouldn't support AMD/Intel based hardware)?
Are the headers for those
Lynne (12020-05-19):
> There already is a zero-overhead capture on linux - kmsgrab. It works
> on AMD and Intel.
The doc says:
Requires either DRM master or CAP_SYS_ADMIN to run.
Does it work for a normal user on a desktop distribution freshly
installed, without configuration?
(I
Hi Lynne,
Thanks for the feedback.
Some more discussion points below.
> There already is a zero-overhead capture on linux - kmsgrab. It works
on AMD and Intel.
Does it work on Nvidia too? Does it have smooth capture?
Does it work for 3d applications?
>> Wouldn't a hwaccel frame imply no
Hi Marton,
Thanks very much for the feedback; below answers to your points - let me
know further feedback if any.
> And sorry, I cannot say how useful this would be, maybe now is the time
> for people to speak up if somebody is particularly against adding this
> for any reason.
I haven't
On Mon, 18 May 2020, Emanuele Oriani wrote:
Hi Marton/ffmpeg devs/all,
Haven't seen any response to the proposed XComposite windows capture.
As per below the reasoning for adding this code to libav*/ffmpeg is that
seems to be better in quality than x11grab, although it uses more CPU in
Hi Marton/ffmpeg devs/all,
Haven't seen any response to the proposed XComposite windows capture.
As per below the reasoning for adding this code to libav*/ffmpeg is that
seems to be better in quality than x11grab, although it uses more CPU in
its current implementation (uses OpenGL and PBO -
Hi Marton/all,
I've re-uploaded the firefox send link (expired) with some sample
capture at 60 FPS:
https://send.firefox.com/download/51b45decae720c08/#r5o4J2SgCJZndRdMOxxRBg
Please note I have integrated usage of OpenGL's Pixel Buffer Objects -
now the memory management of the captured
Hi Marton,
Capturing at 60 FPS 1920x1080, the difference is even more noticeable:
x11grab is choppy, xcompgrab is smooth (this time I used H264 ultrafast
to encode).
https://send.firefox.com/download/17001ef60837a5ec/#FaQTa-dP4MB28YfPNMXxuw
CPU performance:
realuser sys
Hi Marton,
TL;DR
xcompgrab uses more CPU but produces much better streams than x11grab.
I have the following CPU usage performance report (on my i7-8700k,
Nvidia 2080 Ti RTX, governor set to 'performance', on Ubuntu 18.04 using
Gnome shell).
The capture has been a surface area of 1720x1376
On Thu, 7 May 2020, Emanuele Oriani wrote:
Hi FFMPEG devel,
I have been writing a simple XComposite window capture demuxer, heavily
inspired from x11grab sources and OBS Window capture logic/code.
Have you compared performance to x11grab for various resolutions and
frame rates? Do you
32 matches
Mail list logo
