Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-24 Thread Andy Furniss 

Mark Thompson wrote:

On 20/09/17 17:10, Andy Furniss wrote:

Mark Thompson wrote:

On 19/09/17 22:21, Andy Furniss wrote:



That point being around 7k frames it will run out of something.

[AVHWFramesContext @ 0x31ed880] Failed to create surface from DRM object: 2 
(resource allocation failed).
[Parsed_hwmap_0 @ 0x3114c40] Failed to map frame: -5.

I see that memory is reducing before this although I still have spare - is this 
the same issue you explained on users WRT leaking on decode?


Yeah, I also run out of ... something ... at around 7200 frames.  It's not fds 
or memory.  I don't think it's the buffer problem (which, incidentally, should 
finally be fixable sensibly in libva2 soon), because that ended up manifesting 
as leaking memory.  It's also not a problem for Intel (I've already been 
running that for a long time to test).  Maybe some other sort of handle on the 
Mesa side?  I'll investigate further tomorrow.


Leo has fixed the leak.


Yep, checked with the updated Mesa postproc patches + libva2 fixes and it all 
looks good now.  (And colours are even correct, yay!  I still need to look into 
why the default comes out wrong with the postproc bits for that on Intel...)


One thing that comes out in testing the patches WRT postproc is that for 
deinterlace 1080i25 -> 1080p50 there is an issue with the surface size 
being 1088.
This means the result gets scaled to 1088. It is possible to put scale 
after to get 1080, but this seems sub-optimal, costs about 8% perf and 
hypothetical quality issue (not that I could see it).


Apparently vaapi_scale does things differently and the driver is set for 
that way, so changing in the driver will break scale.


AFAICT this is orthogonal to the 1080/1088 encode issue discussed long 
ago where ffmpeg is doing the right thing, that should be fixable in the 
driver.


This case can be demonstrated with 1920x1080 nv12 hwupload -> deint -> 
hwdownload, so no chance for h26x cropping info being used.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-20 Thread Mark Thompson 
On 20/09/17 17:10, Andy Furniss wrote:
> Mark Thompson wrote:
>> On 19/09/17 22:21, Andy Furniss wrote:
> 
>>> That point being around 7k frames it will run out of something.
>>>
>>> [AVHWFramesContext @ 0x31ed880] Failed to create surface from DRM object: 2 
>>> (resource allocation failed).
>>> [Parsed_hwmap_0 @ 0x3114c40] Failed to map frame: -5.
>>>
>>> I see that memory is reducing before this although I still have spare - is 
>>> this the same issue you explained on users WRT leaking on decode?
>>
>> Yeah, I also run out of ... something ... at around 7200 frames.  It's not 
>> fds or memory.  I don't think it's the buffer problem (which, incidentally, 
>> should finally be fixable sensibly in libva2 soon), because that ended up 
>> manifesting as leaking memory.  It's also not a problem for Intel (I've 
>> already been running that for a long time to test).  Maybe some other sort 
>> of handle on the Mesa side?  I'll investigate further tomorrow.
> 
> Leo has fixed the leak.

Yep, checked with the updated Mesa postproc patches + libva2 fixes and it all 
looks good now.  (And colours are even correct, yay!  I still need to look into 
why the default comes out wrong with the postproc bits for that on Intel...)

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-20 Thread Andy Furniss 

Mark Thompson wrote:

On 19/09/17 22:21, Andy Furniss wrote:



That point being around 7k frames it will run out of something.

[AVHWFramesContext @ 0x31ed880] Failed to create surface from DRM object: 2 
(resource allocation failed).
[Parsed_hwmap_0 @ 0x3114c40] Failed to map frame: -5.

I see that memory is reducing before this although I still have spare - is this 
the same issue you explained on users WRT leaking on decode?


Yeah, I also run out of ... something ... at around 7200 frames.  It's not fds 
or memory.  I don't think it's the buffer problem (which, incidentally, should 
finally be fixable sensibly in libva2 soon), because that ended up manifesting 
as leaking memory.  It's also not a problem for Intel (I've already been 
running that for a long time to test).  Maybe some other sort of handle on the 
Mesa side?  I'll investigate further tomorrow.


Leo has fixed the leak.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-19 Thread Mark Thompson 
On 19/09/17 22:21, Andy Furniss wrote:
> Mark Thompson wrote:
>> On 15/09/17 00:15, Andy Furniss wrote:
>>> Andy Furniss wrote:
 Mark Thompson wrote:
> ---
> Now sets the trusted packet flag; otherwise unchanged.
>
>
>    configure    |   1 +
>    libavdevice/Makefile |   1 +
>    libavdevice/alldevices.c |   1 +
>    libavdevice/kmsgrab.c    | 455 
> +++
>    4 files changed, 458 insertions(+)
>    create mode 100644 libavdevice/kmsgrab.c
>
> diff --git a/configure b/configure
> index 6581c53c1a..76a7591ceb 100755
> --- a/configure
> +++ b/configure
> @@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder"
>    iec61883_indev_deps="libiec61883"
>    jack_indev_deps="jack"
>    jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
> +kmsgrab_indev_deps="libdrm"

 Doesn't get built for me = doesn't show up as indev after configure 
 anything special needed?
>>>
>>> Never mind I found --enable-libdrm (had tried --enable-kmsgrab)
>>
>> I assume you're going to try AMD + Mesa + VAAPI.
>>
>> VAAPI_DISABLE_INTERLACE=1 ./ffmpeg_g -y -format bgr0 -device /dev/dri/card1 
>> -f kmsgrab -i - -vsync 0 -init_hw_device vaapi=v:/dev/dri/renderD129 
>> -filter_hw_device v -vf 'hwmap,scale_vaapi=w=1920:h=1080:format=nv12' -c:v 
>> h264_vaapi -profile 578 -bf 0 out.mp4
>>
>> Three Mesa issues I had to get around:
>>
>> * Device derivation doesn't work because the Mesa driver doesn't want to 
>> initialise on the DRM master device for some reason; making the matching 
>> device separately does work.
>> * Against current git, you need to reapply the VAAPI_DISABLE_INTERLACE patch 
>> and use it - if not, the colour conversion just barfs because it wants 
>> interlaced surfaces.
>> * The postproc scaler seems to only write the luma plane when converting 
>> from RGB - this is also visible when uploading normal RGB images, so just a 
>> bug somewhere.
>>
>> With that, it works to record the screen in greyscale...
>>
>> I have some other Mesa stuff to do queued up (libva2 with VAAPI export for 
>> EGL import on AMD), so I'll pursue these further soonish.
> 
> Leo just posted a patchset on the mesa list that makes vaapi work better with 
> this and postproc generally.
> 
> You don't need the env with those and kmsgrab is now working for me - up to a 
> point ...

Yep, that works for me now too - with colour!  (The export to GL for playback 
is still messed up by interlacing without patching it out, but that looked 
orthogonal anyway.)

> That point being around 7k frames it will run out of something.
> 
> [AVHWFramesContext @ 0x31ed880] Failed to create surface from DRM object: 2 
> (resource allocation failed).
> [Parsed_hwmap_0 @ 0x3114c40] Failed to map frame: -5.
> 
> I see that memory is reducing before this although I still have spare - is 
> this the same issue you explained on users WRT leaking on decode?

Yeah, I also run out of ... something ... at around 7200 frames.  It's not fds 
or memory.  I don't think it's the buffer problem (which, incidentally, should 
finally be fixable sensibly in libva2 soon), because that ended up manifesting 
as leaking memory.  It's also not a problem for Intel (I've already been 
running that for a long time to test).  Maybe some other sort of handle on the 
Mesa side?  I'll investigate further tomorrow.

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-19 Thread Andy Furniss 

Mark Thompson wrote:

On 15/09/17 00:15, Andy Furniss wrote:

Andy Furniss wrote:

Mark Thompson wrote:

---
Now sets the trusted packet flag; otherwise unchanged.


   configure|   1 +
   libavdevice/Makefile |   1 +
   libavdevice/alldevices.c |   1 +
   libavdevice/kmsgrab.c| 455 
+++
   4 files changed, 458 insertions(+)
   create mode 100644 libavdevice/kmsgrab.c

diff --git a/configure b/configure
index 6581c53c1a..76a7591ceb 100755
--- a/configure
+++ b/configure
@@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder"
   iec61883_indev_deps="libiec61883"
   jack_indev_deps="jack"
   jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
+kmsgrab_indev_deps="libdrm"


Doesn't get built for me = doesn't show up as indev after configure anything 
special needed?


Never mind I found --enable-libdrm (had tried --enable-kmsgrab)


I assume you're going to try AMD + Mesa + VAAPI.

VAAPI_DISABLE_INTERLACE=1 ./ffmpeg_g -y -format bgr0 -device /dev/dri/card1 -f 
kmsgrab -i - -vsync 0 -init_hw_device vaapi=v:/dev/dri/renderD129 
-filter_hw_device v -vf 'hwmap,scale_vaapi=w=1920:h=1080:format=nv12' -c:v 
h264_vaapi -profile 578 -bf 0 out.mp4

Three Mesa issues I had to get around:

* Device derivation doesn't work because the Mesa driver doesn't want to 
initialise on the DRM master device for some reason; making the matching device 
separately does work.
* Against current git, you need to reapply the VAAPI_DISABLE_INTERLACE patch 
and use it - if not, the colour conversion just barfs because it wants 
interlaced surfaces.
* The postproc scaler seems to only write the luma plane when converting from 
RGB - this is also visible when uploading normal RGB images, so just a bug 
somewhere.

With that, it works to record the screen in greyscale...

I have some other Mesa stuff to do queued up (libva2 with VAAPI export for EGL 
import on AMD), so I'll pursue these further soonish.


Leo just posted a patchset on the mesa list that makes vaapi work better 
with this and postproc generally.


You don't need the env with those and kmsgrab is now working for me - up 
to a point ...


That point being around 7k frames it will run out of something.

[AVHWFramesContext @ 0x31ed880] Failed to create surface from DRM 
object: 2 (resource allocation failed).

[Parsed_hwmap_0 @ 0x3114c40] Failed to map frame: -5.

I see that memory is reducing before this although I still have spare - 
is this the same issue you explained on users WRT leaking on decode?

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-15 Thread Mark Thompson 
On 15/09/17 17:19, Mark Thompson wrote:
> On 15/09/17 16:11, Carl Eugen Hoyos wrote:
>> 2017-09-15 16:37 GMT+02:00 Mark Thompson :
>>> On 15/09/17 13:09, Carl Eugen Hoyos wrote:
 2017-09-15 0:37 GMT+02:00 Mark Thompson :
> On 14/09/17 22:30, Carl Eugen Hoyos wrote:
>> 2017-09-07 23:56 GMT+02:00 Mark Thompson :
>>
>>> +static const struct {
>>> +enum AVPixelFormat pixfmt;
>>> +uint32_t drm_format;
>>> +} kmsgrab_formats[] = {
>>> +{ AV_PIX_FMT_GRAY8,DRM_FORMAT_R8   },
>>> +{ AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16  },
>>> +{ AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888   },
>>> +{ AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888   },
>>> +{ AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
>>> +{ AV_PIX_FMT_0BGR, DRM_FORMAT_XBGR },
>>> +{ AV_PIX_FMT_RGB0, DRM_FORMAT_RGBX },
>>> +{ AV_PIX_FMT_BGR0, DRM_FORMAT_BGRX },
>>> +{ AV_PIX_FMT_ARGB, DRM_FORMAT_ARGB },
>>> +{ AV_PIX_FMT_ABGR, DRM_FORMAT_ABGR },
>>> +{ AV_PIX_FMT_RGBA, DRM_FORMAT_RGBA },
>>> +{ AV_PIX_FMT_BGRA, DRM_FORMAT_BGRA },
>>> +{ AV_PIX_FMT_YUYV422,  DRM_FORMAT_YUYV },
>>> +{ AV_PIX_FMT_YVYU422,  DRM_FORMAT_YVYU },
>>> +{ AV_PIX_FMT_UYVY422,  DRM_FORMAT_UYVY },
>>> +{ AV_PIX_FMT_NV12, DRM_FORMAT_NV12 },
>>> +{ AV_PIX_FMT_YUV420P,  DRM_FORMAT_YUV420   },
>>> +{ AV_PIX_FMT_YUV422P,  DRM_FORMAT_YUV422   },
>>> +{ AV_PIX_FMT_YUV444P,  DRM_FORMAT_YUV444   },
>>
>> Which of those were you able to test?
>
> Only the 32-bit RGB0-type ones (all of them are testable because you just 
> get the colours in a different order).

 So RGB0, BGR0, 0RGB and 0BGR all work fine?
>>>
>>> Yes.
>>>
>>> I've verified YUYV/UYVY directly on Intel as well now.
>>>
> Intel at least should work with others in near-future versions (e.g. 
> ),
>  though I haven't actually tested this.  It seemed sensible to include 
> all core DRM formats which map to ffmpeg pixfmts to account for other 
> drivers (possibly future) which I can't test now.
>>
 Good idea, twelve more are attached.
>>>
>>> Looks sensible.
>>
>> May I commit?
> 
> Are you able to test at all?  I believe I should be able to test at least 565 
> properly a bit later today (and settle the ordering question - I do think now 
> that my interpretation is wrong and that it was working because the same 
> method was used in both directions).

Ok, I've done a lot more format testing now, with explicitly created 
framebuffers on Rockchip:

* The four-element RGB formats are indeed in the order stated in the file, not 
the order in the name.  This means they are reversed wrt everything else in 
ffmpeg, so I'm fixing that.
* RGB24 and BGR24 /are/ correct already, the endianness comments in drm_fourcc 
are misleading for them.
* The multiple-plane formats are not usable, because the planes need not be 
contiguous (you get garbage in the chroma plane), so I'm going to remove 
support for them.  There is currently no way to query the offsets of later 
planes, but if that were added then they could be supported.
* RGB565 and BGR565 work correctly, the rest of formats in your patch are 
untested.

Patches follow, including yours.

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-15 Thread Carl Eugen Hoyos 
2017-09-15 18:19 GMT+02:00 Mark Thompson :
> On 15/09/17 16:11, Carl Eugen Hoyos wrote:

>> May I commit?
>
> Are you able to test at all?

No, I am sorry if I gave a wrong impression!

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-15 Thread Mark Thompson 
On 15/09/17 16:11, Carl Eugen Hoyos wrote:
> 2017-09-15 16:37 GMT+02:00 Mark Thompson :
>> On 15/09/17 13:09, Carl Eugen Hoyos wrote:
>>> 2017-09-15 0:37 GMT+02:00 Mark Thompson :
 On 14/09/17 22:30, Carl Eugen Hoyos wrote:
> 2017-09-07 23:56 GMT+02:00 Mark Thompson :
>
>> +static const struct {
>> +enum AVPixelFormat pixfmt;
>> +uint32_t drm_format;
>> +} kmsgrab_formats[] = {
>> +{ AV_PIX_FMT_GRAY8,DRM_FORMAT_R8   },
>> +{ AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16  },
>> +{ AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888   },
>> +{ AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888   },
>> +{ AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
>> +{ AV_PIX_FMT_0BGR, DRM_FORMAT_XBGR },
>> +{ AV_PIX_FMT_RGB0, DRM_FORMAT_RGBX },
>> +{ AV_PIX_FMT_BGR0, DRM_FORMAT_BGRX },
>> +{ AV_PIX_FMT_ARGB, DRM_FORMAT_ARGB },
>> +{ AV_PIX_FMT_ABGR, DRM_FORMAT_ABGR },
>> +{ AV_PIX_FMT_RGBA, DRM_FORMAT_RGBA },
>> +{ AV_PIX_FMT_BGRA, DRM_FORMAT_BGRA },
>> +{ AV_PIX_FMT_YUYV422,  DRM_FORMAT_YUYV },
>> +{ AV_PIX_FMT_YVYU422,  DRM_FORMAT_YVYU },
>> +{ AV_PIX_FMT_UYVY422,  DRM_FORMAT_UYVY },
>> +{ AV_PIX_FMT_NV12, DRM_FORMAT_NV12 },
>> +{ AV_PIX_FMT_YUV420P,  DRM_FORMAT_YUV420   },
>> +{ AV_PIX_FMT_YUV422P,  DRM_FORMAT_YUV422   },
>> +{ AV_PIX_FMT_YUV444P,  DRM_FORMAT_YUV444   },
>
> Which of those were you able to test?

 Only the 32-bit RGB0-type ones (all of them are testable because you just 
 get the colours in a different order).
>>>
>>> So RGB0, BGR0, 0RGB and 0BGR all work fine?
>>
>> Yes.
>>
>> I've verified YUYV/UYVY directly on Intel as well now.
>>
 Intel at least should work with others in near-future versions (e.g. 
 ), 
 though I haven't actually tested this.  It seemed sensible to include all 
 core DRM formats which map to ffmpeg pixfmts to account for other drivers 
 (possibly future) which I can't test now.
> 
>>> Good idea, twelve more are attached.
>>
>> Looks sensible.
> 
> May I commit?

Are you able to test at all?  I believe I should be able to test at least 565 
properly a bit later today (and settle the ordering question - I do think now 
that my interpretation is wrong and that it was working because the same method 
was used in both directions).

>> I think the ordering of the packed-within-bytes formats (565, etc.) should 
>> be verified before applying them, though, just in case there is something 
>> funny going on here.  I had a look at RGB565, which is usable for output on 
>> Intel, but I can't easily get the result anywhere (map fails, VAAPI doesn't 
>> like the format).
>>
>> On BIG_ENDIAN, I'm not sure whether it has any use or testing at all - none 
>> of the libdrm test programs allow it, and it is suspiciously absent from all 
>> but the most generic parts of drivers/gpu/drm in Linux.
>>
 I've tested on amdgpu, exynos, i915 and rockchip.  It should work on other 
 KMS drivers, though if the output is tiled or not-CPU-mappable it can be 
 hard to get the output somewhere where it can actually be used.  (The ARM 
 ones are fine and allow hwdownload directly.  Intels I've tried are 
 mappable but tiled so hwdownload is messed up, but they interoperate 
 cleanly with VAAPI.  The AMD I have makes the objects completely 
 unmappable from the CPU, but they can be imported to other GPU things with 
 Mesa.)

> I find the comments in the header file very misleading:
> What is "little-endian 8:8:8:8 ARGB"?

 It is just A-R-G-B in memory in that order as you might expect
 without the comment.
>>>
>>> So the comment is simply wrong for the 8:8:8:8 RGB formats?
>>> Iirc, the same comment in the SDL sources defines another
>>> order (or OpenGL, I don't remember atm), as does FFmpeg
>>> through its RGB32 formats.
>>
>> Hmm.  Maybe this is actually wrong in my code.  The format is provided by 
>> the user, because there is no way to retrieve that information from the 
>> framebuffer itself, and therefore we are always doing the mapping in both 
>> directions - the default of AV_PIX_FMT_BGR0 is mapped to DRM_FORMAT_BGRX 
>> and then back to AV_PIX_FMT_BGR0 for hwdownload or hwmap.  If the sense were 
>> actually the opposite and the framebuffer was in fact DRM_FORMAT_XRGB, 
>> this would still work identically and have correct output, because the 
>> intermediate doesn't matter as long as it's reversible.
>>
>> I think I need to test this with an explicit program to do the modeset and 
>> set framebuffer formats directly and then match them to the output pixel 
>> values, because there is no other way to tell.
> 
> Thank you!
> 
> Could we agree,

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-15 Thread Carl Eugen Hoyos 
2017-09-15 16:37 GMT+02:00 Mark Thompson :
> On 15/09/17 13:09, Carl Eugen Hoyos wrote:
>> 2017-09-15 0:37 GMT+02:00 Mark Thompson :
>>> On 14/09/17 22:30, Carl Eugen Hoyos wrote:
 2017-09-07 23:56 GMT+02:00 Mark Thompson :

> +static const struct {
> +enum AVPixelFormat pixfmt;
> +uint32_t drm_format;
> +} kmsgrab_formats[] = {
> +{ AV_PIX_FMT_GRAY8,DRM_FORMAT_R8   },
> +{ AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16  },
> +{ AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888   },
> +{ AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888   },
> +{ AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
> +{ AV_PIX_FMT_0BGR, DRM_FORMAT_XBGR },
> +{ AV_PIX_FMT_RGB0, DRM_FORMAT_RGBX },
> +{ AV_PIX_FMT_BGR0, DRM_FORMAT_BGRX },
> +{ AV_PIX_FMT_ARGB, DRM_FORMAT_ARGB },
> +{ AV_PIX_FMT_ABGR, DRM_FORMAT_ABGR },
> +{ AV_PIX_FMT_RGBA, DRM_FORMAT_RGBA },
> +{ AV_PIX_FMT_BGRA, DRM_FORMAT_BGRA },
> +{ AV_PIX_FMT_YUYV422,  DRM_FORMAT_YUYV },
> +{ AV_PIX_FMT_YVYU422,  DRM_FORMAT_YVYU },
> +{ AV_PIX_FMT_UYVY422,  DRM_FORMAT_UYVY },
> +{ AV_PIX_FMT_NV12, DRM_FORMAT_NV12 },
> +{ AV_PIX_FMT_YUV420P,  DRM_FORMAT_YUV420   },
> +{ AV_PIX_FMT_YUV422P,  DRM_FORMAT_YUV422   },
> +{ AV_PIX_FMT_YUV444P,  DRM_FORMAT_YUV444   },

 Which of those were you able to test?
>>>
>>> Only the 32-bit RGB0-type ones (all of them are testable because you just 
>>> get the colours in a different order).
>>
>> So RGB0, BGR0, 0RGB and 0BGR all work fine?
>
> Yes.
>
> I've verified YUYV/UYVY directly on Intel as well now.
>
>>> Intel at least should work with others in near-future versions (e.g. 
>>> ), 
>>> though I haven't actually tested this.  It seemed sensible to include all 
>>> core DRM formats which map to ffmpeg pixfmts to account for other drivers 
>>> (possibly future) which I can't test now.

>> Good idea, twelve more are attached.
>
> Looks sensible.

May I commit?

> I think the ordering of the packed-within-bytes formats (565, etc.) should be 
> verified before applying them, though, just in case there is something funny 
> going on here.  I had a look at RGB565, which is usable for output on Intel, 
> but I can't easily get the result anywhere (map fails, VAAPI doesn't like the 
> format).
>
> On BIG_ENDIAN, I'm not sure whether it has any use or testing at all - none 
> of the libdrm test programs allow it, and it is suspiciously absent from all 
> but the most generic parts of drivers/gpu/drm in Linux.
>
>>> I've tested on amdgpu, exynos, i915 and rockchip.  It should work on other 
>>> KMS drivers, though if the output is tiled or not-CPU-mappable it can be 
>>> hard to get the output somewhere where it can actually be used.  (The ARM 
>>> ones are fine and allow hwdownload directly.  Intels I've tried are 
>>> mappable but tiled so hwdownload is messed up, but they interoperate 
>>> cleanly with VAAPI.  The AMD I have makes the objects completely unmappable 
>>> from the CPU, but they can be imported to other GPU things with Mesa.)
>>>
 I find the comments in the header file very misleading:
 What is "little-endian 8:8:8:8 ARGB"?
>>>
>>> It is just A-R-G-B in memory in that order as you might expect
>>> without the comment.
>>
>> So the comment is simply wrong for the 8:8:8:8 RGB formats?
>> Iirc, the same comment in the SDL sources defines another
>> order (or OpenGL, I don't remember atm), as does FFmpeg
>> through its RGB32 formats.
>
> Hmm.  Maybe this is actually wrong in my code.  The format is provided by the 
> user, because there is no way to retrieve that information from the 
> framebuffer itself, and therefore we are always doing the mapping in both 
> directions - the default of AV_PIX_FMT_BGR0 is mapped to DRM_FORMAT_BGRX 
> and then back to AV_PIX_FMT_BGR0 for hwdownload or hwmap.  If the sense were 
> actually the opposite and the framebuffer was in fact DRM_FORMAT_XRGB, 
> this would still work identically and have correct output, because the 
> intermediate doesn't matter as long as it's reversible.
>
> I think I need to test this with an explicit program to do the modeset and 
> set framebuffer formats directly and then match them to the output pixel 
> values, because there is no other way to tell.

Thank you!

Could we agree, just for the wording (you know that I am all for
commit early), that you were - so far - not able to test any of
above formats?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-15 Thread Mark Thompson 
On 15/09/17 13:09, Carl Eugen Hoyos wrote:
> 2017-09-15 0:37 GMT+02:00 Mark Thompson :
>> On 14/09/17 22:30, Carl Eugen Hoyos wrote:
>>> 2017-09-07 23:56 GMT+02:00 Mark Thompson :
>>>
 +static const struct {
 +enum AVPixelFormat pixfmt;
 +uint32_t drm_format;
 +} kmsgrab_formats[] = {
 +{ AV_PIX_FMT_GRAY8,DRM_FORMAT_R8   },
 +{ AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16  },
 +{ AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888   },
 +{ AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888   },
 +{ AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
 +{ AV_PIX_FMT_0BGR, DRM_FORMAT_XBGR },
 +{ AV_PIX_FMT_RGB0, DRM_FORMAT_RGBX },
 +{ AV_PIX_FMT_BGR0, DRM_FORMAT_BGRX },
 +{ AV_PIX_FMT_ARGB, DRM_FORMAT_ARGB },
 +{ AV_PIX_FMT_ABGR, DRM_FORMAT_ABGR },
 +{ AV_PIX_FMT_RGBA, DRM_FORMAT_RGBA },
 +{ AV_PIX_FMT_BGRA, DRM_FORMAT_BGRA },
 +{ AV_PIX_FMT_YUYV422,  DRM_FORMAT_YUYV },
 +{ AV_PIX_FMT_YVYU422,  DRM_FORMAT_YVYU },
 +{ AV_PIX_FMT_UYVY422,  DRM_FORMAT_UYVY },
 +{ AV_PIX_FMT_NV12, DRM_FORMAT_NV12 },
 +{ AV_PIX_FMT_YUV420P,  DRM_FORMAT_YUV420   },
 +{ AV_PIX_FMT_YUV422P,  DRM_FORMAT_YUV422   },
 +{ AV_PIX_FMT_YUV444P,  DRM_FORMAT_YUV444   },
>>>
>>> Which of those were you able to test?
>>
>> Only the 32-bit RGB0-type ones (all of them are testable because you just 
>> get the colours in a different order).
> 
> So RGB0, BGR0, 0RGB and 0BGR all work fine?

Yes.

I've verified YUYV/UYVY directly on Intel as well now.

>> Intel at least should work with others in near-future versions (e.g. 
>> ), 
>> though I haven't actually tested this.  It seemed sensible to include all 
>> core DRM formats which map to ffmpeg pixfmts to account for other drivers 
>> (possibly future) which I can't test now.
> 
> Good idea, twelve more are attached.

Looks sensible.

I think the ordering of the packed-within-bytes formats (565, etc.) should be 
verified before applying them, though, just in case there is something funny 
going on here.  I had a look at RGB565, which is usable for output on Intel, 
but I can't easily get the result anywhere (map fails, VAAPI doesn't like the 
format).

On BIG_ENDIAN, I'm not sure whether it has any use or testing at all - none of 
the libdrm test programs allow it, and it is suspiciously absent from all but 
the most generic parts of drivers/gpu/drm in Linux.

>> I've tested on amdgpu, exynos, i915 and rockchip.  It should work on other 
>> KMS drivers, though if the output is tiled or not-CPU-mappable it can be 
>> hard to get the output somewhere where it can actually be used.  (The ARM 
>> ones are fine and allow hwdownload directly.  Intels I've tried are mappable 
>> but tiled so hwdownload is messed up, but they interoperate cleanly with 
>> VAAPI.  The AMD I have makes the objects completely unmappable from the CPU, 
>> but they can be imported to other GPU things with Mesa.)
>>
>>> I find the comments in the header file very misleading:
>>> What is "little-endian 8:8:8:8 ARGB"?
>>
>> It is just A-R-G-B in memory in that order as you might expect
>> without the comment.
> 
> So the comment is simply wrong for the 8:8:8:8 RGB formats?
> Iirc, the same comment in the SDL sources defines another
> order (or OpenGL, I don't remember atm), as does FFmpeg
> through its RGB32 formats.

Hmm.  Maybe this is actually wrong in my code.  The format is provided by the 
user, because there is no way to retrieve that information from the framebuffer 
itself, and therefore we are always doing the mapping in both directions - the 
default of AV_PIX_FMT_BGR0 is mapped to DRM_FORMAT_BGRX and then back to 
AV_PIX_FMT_BGR0 for hwdownload or hwmap.  If the sense were actually the 
opposite and the framebuffer was in fact DRM_FORMAT_XRGB, this would still 
work identically and have correct output, because the intermediate doesn't 
matter as long as it's reversible.

I think I need to test this with an explicit program to do the modeset and set 
framebuffer formats directly and then match them to the output pixel values, 
because there is no other way to tell.

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-15 Thread Carl Eugen Hoyos 
2017-09-15 0:37 GMT+02:00 Mark Thompson :
> On 14/09/17 22:30, Carl Eugen Hoyos wrote:
>> 2017-09-07 23:56 GMT+02:00 Mark Thompson :
>>
>>> +static const struct {
>>> +enum AVPixelFormat pixfmt;
>>> +uint32_t drm_format;
>>> +} kmsgrab_formats[] = {
>>> +{ AV_PIX_FMT_GRAY8,DRM_FORMAT_R8   },
>>> +{ AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16  },
>>> +{ AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888   },
>>> +{ AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888   },
>>> +{ AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
>>> +{ AV_PIX_FMT_0BGR, DRM_FORMAT_XBGR },
>>> +{ AV_PIX_FMT_RGB0, DRM_FORMAT_RGBX },
>>> +{ AV_PIX_FMT_BGR0, DRM_FORMAT_BGRX },
>>> +{ AV_PIX_FMT_ARGB, DRM_FORMAT_ARGB },
>>> +{ AV_PIX_FMT_ABGR, DRM_FORMAT_ABGR },
>>> +{ AV_PIX_FMT_RGBA, DRM_FORMAT_RGBA },
>>> +{ AV_PIX_FMT_BGRA, DRM_FORMAT_BGRA },
>>> +{ AV_PIX_FMT_YUYV422,  DRM_FORMAT_YUYV },
>>> +{ AV_PIX_FMT_YVYU422,  DRM_FORMAT_YVYU },
>>> +{ AV_PIX_FMT_UYVY422,  DRM_FORMAT_UYVY },
>>> +{ AV_PIX_FMT_NV12, DRM_FORMAT_NV12 },
>>> +{ AV_PIX_FMT_YUV420P,  DRM_FORMAT_YUV420   },
>>> +{ AV_PIX_FMT_YUV422P,  DRM_FORMAT_YUV422   },
>>> +{ AV_PIX_FMT_YUV444P,  DRM_FORMAT_YUV444   },
>>
>> Which of those were you able to test?
>
> Only the 32-bit RGB0-type ones (all of them are testable because you just get 
> the colours in a different order).

So RGB0, BGR0, 0RGB and 0BGR all work fine?

> Intel at least should work with others in near-future versions (e.g. 
> ), 
> though I haven't actually tested this.  It seemed sensible to include all 
> core DRM formats which map to ffmpeg pixfmts to account for other drivers 
> (possibly future) which I can't test now.

Good idea, twelve more are attached.

> I've tested on amdgpu, exynos, i915 and rockchip.  It should work on other 
> KMS drivers, though if the output is tiled or not-CPU-mappable it can be hard 
> to get the output somewhere where it can actually be used.  (The ARM ones are 
> fine and allow hwdownload directly.  Intels I've tried are mappable but tiled 
> so hwdownload is messed up, but they interoperate cleanly with VAAPI.  The 
> AMD I have makes the objects completely unmappable from the CPU, but they can 
> be imported to other GPU things with Mesa.)
>
>> I find the comments in the header file very misleading:
>> What is "little-endian 8:8:8:8 ARGB"?
>
> It is just A-R-G-B in memory in that order as you might expect
> without the comment.

So the comment is simply wrong for the 8:8:8:8 RGB formats?
Iirc, the same comment in the SDL sources defines another
order (or OpenGL, I don't remember atm), as does FFmpeg
through its RGB32 formats.

> Not sure why it says little-endian - maybe to emphasise that it doesn't 
> change based on the host architecture?

Wouldn't it be better if the comment said "does not change based
on the host architecture"?

Carl Eugen
diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
index 67a83ef..2b8affa 100644
--- a/libavdevice/kmsgrab.c
+++ b/libavdevice/kmsgrab.c
@@ -207,7 +207,17 @@ static const struct {
 #endif
 #ifdef DRM_FORMAT_R16
 { AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16  },
+{ AV_PIX_FMT_GRAY16BE, DRM_FORMAT_R16  | DRM_FORMAT_BIG_ENDIAN },
 #endif
+{ AV_PIX_FMT_BGR8, DRM_FORMAT_BGR233   },
+{ AV_PIX_FMT_RGB555LE, DRM_FORMAT_XRGB1555 },
+{ AV_PIX_FMT_RGB555BE, DRM_FORMAT_XRGB1555 | DRM_FORMAT_BIG_ENDIAN },
+{ AV_PIX_FMT_BGR555LE, DRM_FORMAT_XBGR1555 },
+{ AV_PIX_FMT_BGR555BE, DRM_FORMAT_XBGR1555 | DRM_FORMAT_BIG_ENDIAN },
+{ AV_PIX_FMT_RGB565LE, DRM_FORMAT_RGB565   },
+{ AV_PIX_FMT_RGB565BE, DRM_FORMAT_RGB565   | DRM_FORMAT_BIG_ENDIAN },
+{ AV_PIX_FMT_BGR565LE, DRM_FORMAT_BGR565   },
+{ AV_PIX_FMT_BGR565BE, DRM_FORMAT_BGR565   | DRM_FORMAT_BIG_ENDIAN },
 { AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888   },
 { AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888   },
 { AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
@@ -222,6 +232,8 @@ static const struct {
 { AV_PIX_FMT_YVYU422,  DRM_FORMAT_YVYU },
 { AV_PIX_FMT_UYVY422,  DRM_FORMAT_UYVY },
 { AV_PIX_FMT_NV12, DRM_FORMAT_NV12 },
+{ AV_PIX_FMT_YUV410P,  DRM_FORMAT_YUV410   },
+{ AV_PIX_FMT_YUV411P,  DRM_FORMAT_YUV411   },
 { AV_PIX_FMT_YUV420P,  DRM_FORMAT_YUV420   },
 { AV_PIX_FMT_YUV422P,  DRM_FORMAT_YUV422   },
 { AV_PIX_FMT_YUV444P,  DRM_FORMAT_YUV444   },
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-15 Thread Andy Furniss 

Mark Thompson wrote:

On 15/09/17 00:15, Andy Furniss wrote:

Andy Furniss wrote:

Mark Thompson wrote:

---
Now sets the trusted packet flag; otherwise unchanged.


   configure|   1 +
   libavdevice/Makefile |   1 +
   libavdevice/alldevices.c |   1 +
   libavdevice/kmsgrab.c| 455 
+++
   4 files changed, 458 insertions(+)
   create mode 100644 libavdevice/kmsgrab.c

diff --git a/configure b/configure
index 6581c53c1a..76a7591ceb 100755
--- a/configure
+++ b/configure
@@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder"
   iec61883_indev_deps="libiec61883"
   jack_indev_deps="jack"
   jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
+kmsgrab_indev_deps="libdrm"


Doesn't get built for me = doesn't show up as indev after configure anything 
special needed?


Never mind I found --enable-libdrm (had tried --enable-kmsgrab)


I assume you're going to try AMD + Mesa + VAAPI.

VAAPI_DISABLE_INTERLACE=1 ./ffmpeg_g -y -format bgr0 -device /dev/dri/card1 -f 
kmsgrab -i - -vsync 0 -init_hw_device vaapi=v:/dev/dri/renderD129 
-filter_hw_device v -vf 'hwmap,scale_vaapi=w=1920:h=1080:format=nv12' -c:v 
h264_vaapi -profile 578 -bf 0 out.mp4

Three Mesa issues I had to get around:

* Device derivation doesn't work because the Mesa driver doesn't want to 
initialise on the DRM master device for some reason; making the matching device 
separately does work.
* Against current git, you need to reapply the VAAPI_DISABLE_INTERLACE patch 
and use it - if not, the colour conversion just barfs because it wants 
interlaced surfaces.
* The postproc scaler seems to only write the luma plane when converting from 
RGB - this is also visible when uploading normal RGB images, so just a bug 
somewhere.

With that, it works to record the screen in greyscale...

I have some other Mesa stuff to do queued up (libva2 with VAAPI export for EGL 
import on AMD), so I'll pursue these further soonish.


Thanks for the info, as it happens I am running some testing patches 
from Leo currently that fix up postproc deinterlace now the env is gone.


I'll point Leo at this mail and test this evening.




- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-14 Thread Mark Thompson 
On 15/09/17 00:15, Andy Furniss wrote:
> Andy Furniss wrote:
>> Mark Thompson wrote:
>>> ---
>>> Now sets the trusted packet flag; otherwise unchanged.
>>>
>>>
>>>   configure    |   1 +
>>>   libavdevice/Makefile |   1 +
>>>   libavdevice/alldevices.c |   1 +
>>>   libavdevice/kmsgrab.c    | 455 
>>> +++
>>>   4 files changed, 458 insertions(+)
>>>   create mode 100644 libavdevice/kmsgrab.c
>>>
>>> diff --git a/configure b/configure
>>> index 6581c53c1a..76a7591ceb 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder"
>>>   iec61883_indev_deps="libiec61883"
>>>   jack_indev_deps="jack"
>>>   jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
>>> +kmsgrab_indev_deps="libdrm"
>>
>> Doesn't get built for me = doesn't show up as indev after configure anything 
>> special needed?
> 
> Never mind I found --enable-libdrm (had tried --enable-kmsgrab)

I assume you're going to try AMD + Mesa + VAAPI.

VAAPI_DISABLE_INTERLACE=1 ./ffmpeg_g -y -format bgr0 -device /dev/dri/card1 -f 
kmsgrab -i - -vsync 0 -init_hw_device vaapi=v:/dev/dri/renderD129 
-filter_hw_device v -vf 'hwmap,scale_vaapi=w=1920:h=1080:format=nv12' -c:v 
h264_vaapi -profile 578 -bf 0 out.mp4

Three Mesa issues I had to get around:

* Device derivation doesn't work because the Mesa driver doesn't want to 
initialise on the DRM master device for some reason; making the matching device 
separately does work.
* Against current git, you need to reapply the VAAPI_DISABLE_INTERLACE patch 
and use it - if not, the colour conversion just barfs because it wants 
interlaced surfaces.
* The postproc scaler seems to only write the luma plane when converting from 
RGB - this is also visible when uploading normal RGB images, so just a bug 
somewhere.

With that, it works to record the screen in greyscale...

I have some other Mesa stuff to do queued up (libva2 with VAAPI export for EGL 
import on AMD), so I'll pursue these further soonish.

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-14 Thread Andy Furniss 

Andy Furniss wrote:

Mark Thompson wrote:

---
Now sets the trusted packet flag; otherwise unchanged.


  configure|   1 +
  libavdevice/Makefile |   1 +
  libavdevice/alldevices.c |   1 +
  libavdevice/kmsgrab.c| 455 
+++

  4 files changed, 458 insertions(+)
  create mode 100644 libavdevice/kmsgrab.c

diff --git a/configure b/configure
index 6581c53c1a..76a7591ceb 100755
--- a/configure
+++ b/configure
@@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder"
  iec61883_indev_deps="libiec61883"
  jack_indev_deps="jack"
  jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
+kmsgrab_indev_deps="libdrm"


Doesn't get built for me = doesn't show up as indev after configure 
anything special needed?


Never mind I found --enable-libdrm (had tried --enable-kmsgrab)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-14 Thread Andy Furniss 

Mark Thompson wrote:

---
Now sets the trusted packet flag; otherwise unchanged.


  configure|   1 +
  libavdevice/Makefile |   1 +
  libavdevice/alldevices.c |   1 +
  libavdevice/kmsgrab.c| 455 +++
  4 files changed, 458 insertions(+)
  create mode 100644 libavdevice/kmsgrab.c

diff --git a/configure b/configure
index 6581c53c1a..76a7591ceb 100755
--- a/configure
+++ b/configure
@@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder"
  iec61883_indev_deps="libiec61883"
  jack_indev_deps="jack"
  jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
+kmsgrab_indev_deps="libdrm"


Doesn't get built for me = doesn't show up as indev after configure 
anything special needed?


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-14 Thread Mark Thompson 
On 14/09/17 22:30, Carl Eugen Hoyos wrote:
> 2017-09-07 23:56 GMT+02:00 Mark Thompson :
> 
>> +static const struct {
>> +enum AVPixelFormat pixfmt;
>> +uint32_t drm_format;
>> +} kmsgrab_formats[] = {
>> +{ AV_PIX_FMT_GRAY8,DRM_FORMAT_R8   },
>> +{ AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16  },
>> +{ AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888   },
>> +{ AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888   },
>> +{ AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
>> +{ AV_PIX_FMT_0BGR, DRM_FORMAT_XBGR },
>> +{ AV_PIX_FMT_RGB0, DRM_FORMAT_RGBX },
>> +{ AV_PIX_FMT_BGR0, DRM_FORMAT_BGRX },
>> +{ AV_PIX_FMT_ARGB, DRM_FORMAT_ARGB },
>> +{ AV_PIX_FMT_ABGR, DRM_FORMAT_ABGR },
>> +{ AV_PIX_FMT_RGBA, DRM_FORMAT_RGBA },
>> +{ AV_PIX_FMT_BGRA, DRM_FORMAT_BGRA },
>> +{ AV_PIX_FMT_YUYV422,  DRM_FORMAT_YUYV },
>> +{ AV_PIX_FMT_YVYU422,  DRM_FORMAT_YVYU },
>> +{ AV_PIX_FMT_UYVY422,  DRM_FORMAT_UYVY },
>> +{ AV_PIX_FMT_NV12, DRM_FORMAT_NV12 },
>> +{ AV_PIX_FMT_YUV420P,  DRM_FORMAT_YUV420   },
>> +{ AV_PIX_FMT_YUV422P,  DRM_FORMAT_YUV422   },
>> +{ AV_PIX_FMT_YUV444P,  DRM_FORMAT_YUV444   },
> 
> Which of those were you able to test?

Only the 32-bit RGB0-type ones (all of them are testable because you just get 
the colours in a different order).  Intel at least should work with others in 
near-future versions (e.g. 
), 
though I haven't actually tested this.  It seemed sensible to include all core 
DRM formats which map to ffmpeg pixfmts to account for other drivers (possibly 
future) which I can't test now.

I've tested on amdgpu, exynos, i915 and rockchip.  It should work on other KMS 
drivers, though if the output is tiled or not-CPU-mappable it can be hard to 
get the output somewhere where it can actually be used.  (The ARM ones are fine 
and allow hwdownload directly.  Intels I've tried are mappable but tiled so 
hwdownload is messed up, but they interoperate cleanly with VAAPI.  The AMD I 
have makes the objects completely unmappable from the CPU, but they can be 
imported to other GPU things with Mesa.)

> I find the comments in the header file very misleading:
> What is "little-endian 8:8:8:8 ARGB"?

It is just A-R-G-B in memory in that order as you might expect without the 
comment.  Not sure why it says little-endian - maybe to emphasise that it 
doesn't change based on the host architecture?

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-14 Thread Carl Eugen Hoyos 
2017-09-07 23:56 GMT+02:00 Mark Thompson :

> +static const struct {
> +enum AVPixelFormat pixfmt;
> +uint32_t drm_format;
> +} kmsgrab_formats[] = {
> +{ AV_PIX_FMT_GRAY8,DRM_FORMAT_R8   },
> +{ AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16  },
> +{ AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888   },
> +{ AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888   },
> +{ AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
> +{ AV_PIX_FMT_0BGR, DRM_FORMAT_XBGR },
> +{ AV_PIX_FMT_RGB0, DRM_FORMAT_RGBX },
> +{ AV_PIX_FMT_BGR0, DRM_FORMAT_BGRX },
> +{ AV_PIX_FMT_ARGB, DRM_FORMAT_ARGB },
> +{ AV_PIX_FMT_ABGR, DRM_FORMAT_ABGR },
> +{ AV_PIX_FMT_RGBA, DRM_FORMAT_RGBA },
> +{ AV_PIX_FMT_BGRA, DRM_FORMAT_BGRA },
> +{ AV_PIX_FMT_YUYV422,  DRM_FORMAT_YUYV },
> +{ AV_PIX_FMT_YVYU422,  DRM_FORMAT_YVYU },
> +{ AV_PIX_FMT_UYVY422,  DRM_FORMAT_UYVY },
> +{ AV_PIX_FMT_NV12, DRM_FORMAT_NV12 },
> +{ AV_PIX_FMT_YUV420P,  DRM_FORMAT_YUV420   },
> +{ AV_PIX_FMT_YUV422P,  DRM_FORMAT_YUV422   },
> +{ AV_PIX_FMT_YUV444P,  DRM_FORMAT_YUV444   },

Which of those were you able to test?
I find the comments in the header file very misleading:
What is "little-endian 8:8:8:8 ARGB"?

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-13 Thread James Almer 
On 9/7/2017 6:56 PM, Mark Thompson wrote:
> +pkt->data  = (uint8_t*)frame;
> +pkt->size  = sizeof(*frame);
> +pkt->pts   = now;
> +pkt->flags = AV_PKT_FLAG_TRUSTED;

pkt->flags |= AV_PKT_FLAG_TRUSTED;

I know pkt->flags is zeroed by default, but that may change in the
future. And ORing/XORing is the proper way to set flags anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-11 Thread Paul B Mahol 
On 9/12/17, Mark Thompson  wrote:
> On 07/09/17 22:56, Mark Thompson wrote:
>> ---
>> Now sets the trusted packet flag; otherwise unchanged.
>>
>>
>>  configure|   1 +
>>  libavdevice/Makefile |   1 +
>>  libavdevice/alldevices.c |   1 +
>>  libavdevice/kmsgrab.c| 455
>> +++
>>  4 files changed, 458 insertions(+)
>>  create mode 100644 libavdevice/kmsgrab.c
>
> Series approved by atomnuker on IRC.  Does anyone else want to comment on
> the wrapped_avframe / AV_PKT_FLAG_TRUSTED setup (or anything else)?  If not,
> I'll push this the day after tomorrow.

Missing docs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-11 Thread Mark Thompson 
On 07/09/17 22:56, Mark Thompson wrote:
> ---
> Now sets the trusted packet flag; otherwise unchanged.
> 
> 
>  configure|   1 +
>  libavdevice/Makefile |   1 +
>  libavdevice/alldevices.c |   1 +
>  libavdevice/kmsgrab.c| 455 
> +++
>  4 files changed, 458 insertions(+)
>  create mode 100644 libavdevice/kmsgrab.c

Series approved by atomnuker on IRC.  Does anyone else want to comment on the 
wrapped_avframe / AV_PKT_FLAG_TRUSTED setup (or anything else)?  If not, I'll 
push this the day after tomorrow.

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

2017-09-07 Thread Mark Thompson 
---
Now sets the trusted packet flag; otherwise unchanged.


 configure|   1 +
 libavdevice/Makefile |   1 +
 libavdevice/alldevices.c |   1 +
 libavdevice/kmsgrab.c| 455 +++
 4 files changed, 458 insertions(+)
 create mode 100644 libavdevice/kmsgrab.c

diff --git a/configure b/configure
index 6581c53c1a..76a7591ceb 100755
--- a/configure
+++ b/configure
@@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder"
 iec61883_indev_deps="libiec61883"
 jack_indev_deps="jack"
 jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
+kmsgrab_indev_deps="libdrm"
 lavfi_indev_deps="avfilter"
 libcdio_indev_deps="libcdio"
 libdc1394_indev_deps="libdc1394"
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index 2a27d20388..f40f4d5298 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -32,6 +32,7 @@ OBJS-$(CONFIG_FBDEV_OUTDEV)  += fbdev_enc.o \
 OBJS-$(CONFIG_GDIGRAB_INDEV) += gdigrab.o
 OBJS-$(CONFIG_IEC61883_INDEV)+= iec61883.o
 OBJS-$(CONFIG_JACK_INDEV)+= jack.o timefilter.o
+OBJS-$(CONFIG_KMSGRAB_INDEV) += kmsgrab.o
 OBJS-$(CONFIG_LAVFI_INDEV)   += lavfi.o
 OBJS-$(CONFIG_OPENAL_INDEV)  += openal-dec.o
 OBJS-$(CONFIG_OPENGL_OUTDEV) += opengl_enc.o
diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index 38010e288a..b31558bcb5 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -53,6 +53,7 @@ static void register_all(void)
 REGISTER_INDEV   (GDIGRAB,  gdigrab);
 REGISTER_INDEV   (IEC61883, iec61883);
 REGISTER_INDEV   (JACK, jack);
+REGISTER_INDEV   (KMSGRAB,  kmsgrab);
 REGISTER_INDEV   (LAVFI,lavfi);
 REGISTER_INDEV   (OPENAL,   openal);
 REGISTER_OUTDEV  (OPENGL,   opengl);
diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
new file mode 100644
index 00..d0b9cf5001
--- /dev/null
+++ b/libavdevice/kmsgrab.c
@@ -0,0 +1,455 @@
+/*
+ * KMS/DRM input device
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_drm.h"
+#include "libavutil/internal.h"
+#include "libavutil/mathematics.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixfmt.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/time.h"
+
+#include "libavformat/avformat.h"
+#include "libavformat/internal.h"
+
+typedef struct KMSGrabContext {
+const AVClass *class;
+
+AVBufferRef *device_ref;
+AVHWDeviceContext *device;
+AVDRMDeviceContext *hwctx;
+
+AVBufferRef *frames_ref;
+AVHWFramesContext *frames;
+
+uint32_t plane_id;
+uint32_t drm_format;
+unsigned int width;
+unsigned int height;
+
+int64_t frame_delay;
+int64_t frame_last;
+
+const char *device_path;
+enum AVPixelFormat format;
+int64_t drm_format_modifier;
+int64_t source_plane;
+int64_t source_crtc;
+AVRational framerate;
+} KMSGrabContext;
+
+static void kmsgrab_free_desc(void *opaque, uint8_t *data)
+{
+AVDRMFrameDescriptor *desc = (AVDRMFrameDescriptor*)data;
+
+close(desc->objects[0].fd);
+
+av_free(desc);
+}
+
+static void kmsgrab_free_frame(void *opaque, uint8_t *data)
+{
+AVFrame *frame = (AVFrame*)data;
+
+av_frame_free();
+}
+
+static int kmsgrab_read_packet(AVFormatContext *avctx, AVPacket *pkt)
+{
+KMSGrabContext *ctx = avctx->priv_data;
+drmModePlane *plane;
+drmModeFB *fb;
+AVDRMFrameDescriptor *desc;
+AVFrame *frame;
+int64_t now;
+int err, fd;
+
+now = av_gettime();
+if (ctx->frame_last) {
+int64_t delay;
+while (1) {
+delay = ctx->frame_last + ctx->frame_delay - now;
+if (delay <= 0)
+break;
+av_usleep(delay);
+now = av_gettime();
+}
+}
+ctx->frame_last = now;
+
+plane = drmModeGetPlane(ctx->hwctx->fd, ctx->plane_id);
+if (!plane) {
+av_log(avctx, AV_LOG_ERROR, "Failed to get plane "
+   "%"PRIu32".\n", ctx->plane_id);
+return AVERROR(EIO);
+