vaapi: Support PAL8

Message ID 20161209162400.18234-1-lu_zero@gentoo.org
State New
Headers show

Commit Message

Luca Barbato Dec. 9, 2016, 4:24 p.m.
It is used to allocate scratch buffers by the qsv hwaccel.
---
 libavutil/hwcontext_vaapi.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Mark Thompson Dec. 10, 2016, 5:44 p.m. | #1
On 09/12/16 16:24, Luca Barbato wrote:
> It is used to allocate scratch buffers by the qsv hwaccel.
> ---
>  libavutil/hwcontext_vaapi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index b2e212c..e955add 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -111,6 +111,8 @@ static struct {
>    //MAP(XBGR, RGB32,   0BGR),
>      MAP(ARGB, RGB32,   ARGB),
>    //MAP(XRGB, RGB32,   0RGB),
> +    // Special scratch buffer format
> +    { VA_FOURCC_P208, VA_FOURCC_P208, AV_PIX_FMT_PAL8 },
>  };
>  #undef MAP

Um, what?  The internet thinks that P208 is a YUV 4:2:2 two-plane format analogous to NV12 (I guess named like P010), which does not in any way resemble PAL8.

Also, the middle field there should be a VA_RT_FORMAT (I suggest using the macro).

Thanks,

- Mark
Luca Barbato Dec. 10, 2016, 6:29 p.m. | #2
On 10/12/2016 18:44, Mark Thompson wrote:
> Um, what?  The internet thinks that P208 is a YUV 4:2:2 two-plane format analogous to NV12 (I guess named like P010), which does not in any way resemble PAL8.

I know ...

> Also, the middle field there should be a VA_RT_FORMAT (I suggest using the macro).

I know ...

Yet that's the way (TM), Intel examples are using to support hevc
encoding + vaapi...

If you have better ideas I'm all ears.

lu
Anton Khirnov Dec. 12, 2016, 12:09 p.m. | #3
Quoting Luca Barbato (2016-12-10 19:29:44)
> On 10/12/2016 18:44, Mark Thompson wrote:
> > Um, what?  The internet thinks that P208 is a YUV 4:2:2 two-plane format analogous to NV12 (I guess named like P010), which does not in any way resemble PAL8.
> 
> I know ...
> 
> > Also, the middle field there should be a VA_RT_FORMAT (I suggest using the macro).
> 
> I know ...
> 
> Yet that's the way (TM), Intel examples are using to support hevc
> encoding + vaapi...
> 
> If you have better ideas I'm all ears.

HEVC encoding seems to work here without any such things.
Luca Barbato Dec. 12, 2016, 1:15 p.m. | #4
On 12/12/2016 13:09, Anton Khirnov wrote:
> HEVC encoding seems to work here without any such things.

how are you testing it?

lu
Luca Barbato Dec. 12, 2016, 3:01 p.m. | #5
On 12/12/2016 13:09, Anton Khirnov wrote:
> Quoting Luca Barbato (2016-12-10 19:29:44)
>> On 10/12/2016 18:44, Mark Thompson wrote:
>>> Um, what?  The internet thinks that P208 is a YUV 4:2:2 two-plane format analogous to NV12 (I guess named like P010), which does not in any way resemble PAL8.
>>
>> I know ...
>>
>>> Also, the middle field there should be a VA_RT_FORMAT (I suggest using the macro).
>>
>> I know ...
>>
>> Yet that's the way (TM), Intel examples are using to support hevc
>> encoding + vaapi...
>>
>> If you have better ideas I'm all ears.
> 
> HEVC encoding seems to work here without any such things.
> 

avconv -hwaccel qsv -c:v h264_qsv \
    -i ~/Samples/bbb_sunflower_1080p_60fps_normal.mp4 \
    -r 25 -b:v 3M -q:v 20 -c:v hevc_qsv -load_plugin hevc_hw \
    -an -f null -

this produces:

[AVHWFramesContext @ 0x43d7ca0] Unsupported format: pal8.
[AVHWFramesContext @ 0x41ee5e0] Error initializing a child frames context
[AVHWFramesContext @ 0x41ee5e0] Error creating an internal frame pool
[hevc_qsv @ 0x30461a0] Error initializing a frames context for an
internal frame allocation request
[hevc_qsv @ 0x30461a0] Error initializing the encoder: failed to
allocate memory (-4)

Without the patch.

lu
Anton Khirnov Dec. 14, 2016, 8:25 a.m. | #6
Quoting Luca Barbato (2016-12-12 16:01:18)
> On 12/12/2016 13:09, Anton Khirnov wrote:
> > Quoting Luca Barbato (2016-12-10 19:29:44)
> >> On 10/12/2016 18:44, Mark Thompson wrote:
> >>> Um, what?  The internet thinks that P208 is a YUV 4:2:2 two-plane format analogous to NV12 (I guess named like P010), which does not in any way resemble PAL8.
> >>
> >> I know ...
> >>
> >>> Also, the middle field there should be a VA_RT_FORMAT (I suggest using the macro).
> >>
> >> I know ...
> >>
> >> Yet that's the way (TM), Intel examples are using to support hevc
> >> encoding + vaapi...
> >>
> >> If you have better ideas I'm all ears.
> > 
> > HEVC encoding seems to work here without any such things.
> > 
> 
> avconv -hwaccel qsv -c:v h264_qsv \
>     -i ~/Samples/bbb_sunflower_1080p_60fps_normal.mp4 \
>     -r 25 -b:v 3M -q:v 20 -c:v hevc_qsv -load_plugin hevc_hw \
>     -an -f null -
> 
> this produces:
> 
> [AVHWFramesContext @ 0x43d7ca0] Unsupported format: pal8.
> [AVHWFramesContext @ 0x41ee5e0] Error initializing a child frames context
> [AVHWFramesContext @ 0x41ee5e0] Error creating an internal frame pool
> [hevc_qsv @ 0x30461a0] Error initializing a frames context for an
> internal frame allocation request
> [hevc_qsv @ 0x30461a0] Error initializing the encoder: failed to
> allocate memory (-4)
> 
> Without the patch.

Ah, I thought we are talking about vaapi for some reason. If you look at
the QSV examples more closely, you'll see they don't actually allocate
P208 surfaces. And your patch does not work for me, the encoder returns
DEVICE_BUSY endlessly.
Luca Barbato July 17, 2017, 11:50 a.m. | #7
On 12/14/16 9:25 AM, Anton Khirnov wrote:
> Quoting Luca Barbato (2016-12-12 16:01:18)
>> On 12/12/2016 13:09, Anton Khirnov wrote:
>>> Quoting Luca Barbato (2016-12-10 19:29:44)
>>>> On 10/12/2016 18:44, Mark Thompson wrote:
>>>>> Um, what?  The internet thinks that P208 is a YUV 4:2:2 two-plane format analogous to NV12 (I guess named like P010), which does not in any way resemble PAL8.
>>>>
>>>> I know ...
>>>>
>>>>> Also, the middle field there should be a VA_RT_FORMAT (I suggest using the macro).
>>>>
>>>> I know ...
>>>>
>>>> Yet that's the way (TM), Intel examples are using to support hevc
>>>> encoding + vaapi...
>>>>
>>>> If you have better ideas I'm all ears.
>>>
>>> HEVC encoding seems to work here without any such things.
>>>
>>
>> avconv -hwaccel qsv -c:v h264_qsv \
>>     -i ~/Samples/bbb_sunflower_1080p_60fps_normal.mp4 \
>>     -r 25 -b:v 3M -q:v 20 -c:v hevc_qsv -load_plugin hevc_hw \
>>     -an -f null -
>>
>> this produces:
>>
>> [AVHWFramesContext @ 0x43d7ca0] Unsupported format: pal8.
>> [AVHWFramesContext @ 0x41ee5e0] Error initializing a child frames context
>> [AVHWFramesContext @ 0x41ee5e0] Error creating an internal frame pool
>> [hevc_qsv @ 0x30461a0] Error initializing a frames context for an
>> internal frame allocation request
>> [hevc_qsv @ 0x30461a0] Error initializing the encoder: failed to
>> allocate memory (-4)
>>
>> Without the patch.
> 
> Ah, I thought we are talking about vaapi for some reason. If you look at
> the QSV examples more closely, you'll see they don't actually allocate
> P208 surfaces. And your patch does not work for me, the encoder returns
> DEVICE_BUSY endlessly.
> 

I eventually have time to have a closer look and...

	if( VA_FOURCC_P208 != va_fourcc )
        {
	   ... normal stuff ...
	} else {
            VAContextID context_id = request->AllocId;
            int codedbuf_size;

            int width32 = 32 * ((request->Info.Width + 31) >> 5);
            int height32 = 32 * ((request->Info.Height + 31) >> 5);

            VABufferType codedbuf_type;
            if (fourcc == MFX_FOURCC_VP8_SEGMAP)
            {
                codedbuf_size = request->Info.Width * request->Info.Height;
                codedbuf_type = (VABufferType)VAEncMacroblockMapBufferType;
            }
            else
            {
                codedbuf_size = static_cast<int>((width32 * height32) *
400LL / (16 * 16));
                codedbuf_type = VAEncCodedBufferType;
            }

            for (numAllocated = 0; numAllocated < surfaces_num;
numAllocated++)
            {
                VABufferID coded_buf;

                va_res = m_libva->vaCreateBuffer(m_dpy,
                                      context_id,
                                      codedbuf_type,
                                      codedbuf_size,
                                      1,
                                      NULL,
                                      &coded_buf);
                mfx_res = va_to_mfx_status(va_res);
                if (MFX_ERR_NONE != mfx_res) break;
                surfaces[numAllocated] = coded_buf;
            }

... Not exactly pretty.

lu

Patch

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index b2e212c..e955add 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -111,6 +111,8 @@  static struct {
   //MAP(XBGR, RGB32,   0BGR),
     MAP(ARGB, RGB32,   ARGB),
   //MAP(XRGB, RGB32,   0RGB),
+    // Special scratch buffer format
+    { VA_FOURCC_P208, VA_FOURCC_P208, AV_PIX_FMT_PAL8 },
 };
 #undef MAP