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. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
