| Message ID | 20161209162400.18234-1-lu_zero@gentoo.org |
|---|---|
| State | New |
| Headers | show |
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
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
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.
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
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
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.
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
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