[FFmpeg-user] H264 VAAPI Encoder

Discussion:

Armin K.

2016-05-13 19:43:52 UTC

Hi everyone,

I noticed that recently a VAAPI based H264 encoder was added to ffmpeg.
I built ffmpeg from git and now I have h264_vaapi listed in ffmpeg -encoders
output.

However, when I try to use ffmpeg ... -vcodec h264_vaapi I get the following
error:

Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto-inserted scaler 0'

The command I use is:

ffmpeg -hwaccel vaapi -i <inputfile> -vcodec h264_vaapi <outfile>.mkv

I'm trying this on Intel Skylake GT2 HW on Linux x86_64, using libva and
libva-intel driver from git master in combination with linux 4.6.0-rc7.

Can anyone assist here?

Thanks!

Mark Thompson

2016-05-14 16:41:17 UTC

Permalink

Post by Armin K.
I noticed that recently a VAAPI based H264 encoder was added to ffmpeg.
I built ffmpeg from git and now I have h264_vaapi listed in ffmpeg -encoders
output.
However, when I try to use ffmpeg ... -vcodec h264_vaapi I get the following
Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto-inserted scaler 0'
ffmpeg -hwaccel vaapi -i <inputfile> -vcodec h264_vaapi <outfile>.mkv

Short answer:

ffmpeg -vaapi_device /dev/dri/renderD128 -i <inputfile> -vf 'format=nv12,hwupload' -c:v h264_vaapi <outfile>.mkv

Longer answer:

It's somewhat awkward to use because it only accepts input as VAAPI surfaces (AV_PIX_FMT_VAAPI), with underlying format depending on the particular hardware.

"-vaapi_device" sets the hardware device to use. It takes either a DRI device (ideally a render node, as above) or an X11 display name (only if you are actually in X).

Then we use libavfilter to get the input into the right form:

"format=nv12" forces software conversion to NV12, which is the underlying format required by the Intel driver.

"hwupload" uploads that software image into a VAAPI surface, which can then be fed into the encoder.

You need a bit more trickiness to do a pure hardware transcode, see <https://wiki.libav.org/Hardware/vaapi> for additional explanation.

- Mark
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with subject "unsubscri

Armin K.

2016-05-15 17:12:28 UTC

Permalink

Post by Mark Thompson

ffmpeg -vaapi_device /dev/dri/renderD128 -i <inputfile> -vf 'format=nv12,hwupload' -c:v h264_vaapi <outfile>.mkv
It's somewhat awkward to use because it only accepts input as VAAPI surfaces (AV_PIX_FMT_VAAPI), with underlying format depending on the particular hardware.
"-vaapi_device" sets the hardware device to use. It takes either a DRI device (ideally a render node, as above) or an X11 display name (only if you are actually in X).
"format=nv12" forces software conversion to NV12, which is the underlying format required by the Intel driver.
"hwupload" uploads that software image into a VAAPI surface, which can then be fed into the encoder.
You need a bit more trickiness to do a pure hardware transcode, see <https://wiki.libav.org/Hardware/vaapi> for additional explanation.
- Mark
_______________________________________________
ffmpeg-user mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email

Thanks! That seems to work just great!

Andy Furniss

2016-06-17 22:33:50 UTC

Permalink

Post by Mark Thompson

AMD are working on vaapi encode for mesa, only a few patches about so
far and they got rejected - though not for functionality.

They do work with gstreamer, but trying above with ffmpeg fails as below
(render node or X) seems the surface is seen as rgb - but the h/w takes
nv12.

Maybe mesa/the driver is giving false info?

vainfo
libva info: VA-API version 0.38.1
libva info: va_getDriverName() returns 0
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.38 (libva 1.6.3.pre1)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264Baseline : VAEntrypointVLD
VAProfileH264Baseline : VAEntrypointEncSlice
VAProfileH264Baseline : VAEntrypointEncPicture
VAProfileH264Main : VAEntrypointVLD
VAProfileH264High : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc

ffmpeg doesn't seem to care about VAProfileH264Baseline

I tried avconv and it does care = bail, but I can use -profile 66 and
then get the same error as ffmpeg (though it converts to rgba rather
than rgb0)

ffmpeg -loglevel debug -vaapi_device /dev/dri/renderD128 -i
~/Pendulum-prog.mpg -vf 'format=nv12,hwupload' -c:v h264_vaapi out.mkv
ffmpeg version N-80356-g7f1b503 Copyright (c) 2000-2016 the FFmpeg
developers
built with gcc 5.3.0 (GCC)
configuration: --prefix=/usr --disable-doc --enable-gpl --enable-omx
--enable-opencl --enable-libzimg --enable-libvpx --enable-libx265
--enable-libmp3lame --enable-libx264 --enable-gnutls
libavutil 55. 24.100 / 55. 24.100
libavcodec 57. 46.100 / 57. 46.100
libavformat 57. 38.100 / 57. 38.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 46.101 / 6. 46.101
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
Splitting the commandline.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging
level) with argument 'debug'.
Reading option '-vaapi_device' ... matched as option 'vaapi_device' (set
VAAPI hardware device (DRM path or X11 display name)) with argument
'/dev/dri/renderD128'.
Reading option '-i' ... matched as input file with argument
'/home/andy/Pendulum-prog.mpg'.
Reading option '-vf' ... matched as option 'vf' (set video filters) with
argument 'format=nv12,hwupload'.
Reading option '-c:v' ... matched as option 'c' (codec name) with
argument 'h264_vaapi'.
Reading option 'out.mkv' ... matched as output file.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument debug.
Applying option vaapi_device (set VAAPI hardware device (DRM path or X11
display name)) with argument /dev/dri/renderD128.
[vaapi @ 0x190e300] Cannot open X11 display /dev/dri/renderD128.
[vaapi @ 0x190e300] Opened VA display via DRM device /dev/dri/renderD128.
libva info: VA-API version 0.38.1
libva info: va_getDriverName() returns -1
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
[vaapi @ 0x190e300] Initialised VAAPI connection: version 0.38
[AVHWDeviceContext @ 0x3ca4c40] Format 0x3231564e -> unknown.
[AVHWDeviceContext @ 0x3ca4c40] Format 0x32315659 -> unknown.
[AVHWDeviceContext @ 0x3ca4c40] Format 0x56595559 -> unknown.
[AVHWDeviceContext @ 0x3ca4c40] Format 0x59565955 -> unknown.
[AVHWDeviceContext @ 0x3ca4c40] Format 0x41524742 -> bgra.
[AVHWDeviceContext @ 0x3ca4c40] Format 0x41424752 -> rgba.
[AVHWDeviceContext @ 0x3ca4c40] Format 0x58524742 -> bgr0.
[AVHWDeviceContext @ 0x3ca4c40] Format 0x58424752 -> rgb0.
Successfully parsed a group of options.
Parsing a group of options: input file /home/andy/Pendulum-prog.mpg.
Successfully parsed a group of options.
Opening an input file: /home/andy/Pendulum-prog.mpg.
[file @ 0x3bfb680] Setting default whitelist 'file,crypto'
[mpeg @ 0x3bfb060] Format mpeg probed with size=2048 and score=26
[mpeg @ 0x3bfb060] Before avformat_find_stream_info() pos: 0 bytes
read:32768 seeks:0 nb_streams:0
[mpeg @ 0x3bfb060] probing stream 0 pp:2500
[mpeg @ 0x3bfb060] Probe with size=2005, packets=1 detected mpegvideo
with score=25
[mpeg @ 0x3bfb060] probed stream 0
[mpeg @ 0x3bfb060] max_analyze_duration 7000000 reached at 7000000
microseconds st:0
[mpeg @ 0x3bfb060] After avformat_find_stream_info() pos: 0 bytes
read:2019472 seeks:2 frames:177
Input #0, mpeg, from '/home/andy/Pendulum-prog.mpg':
Duration: 00:00:39.84, start: 0.500000, bitrate: 1969 kb/s
Stream #0:0[0x1e0], 177, 1/90000: Video: mpeg2video (Main), 1
reference frame, yuv420p(tv, left), 720x576 [SAR 1:1 DAR 5:4], 0/1, 25
fps, 25 tbr, 90k tbn, 50 tbc
Successfully opened the file.
Parsing a group of options: output file out.mkv.
Applying option vf (set video filters) with argument format=nv12,hwupload.
Applying option c:v (codec name) with argument h264_vaapi.
Successfully parsed a group of options.
Opening an output file: out.mkv.
File 'out.mkv' already exists. Overwrite ? [y/N] y
[file @ 0x3ce8680] Setting default whitelist 'file,crypto'
Successfully opened the file.
detected 4 logical cores
[Parsed_format_0 @ 0x3cf4840] compat: called with args=[nv12]
[Parsed_format_0 @ 0x3cf4840] Setting 'pix_fmts' to value 'nv12'
[graph 0 input from stream 0:0 @ 0x3cd5fc0] Setting 'video_size' to
value '720x576'
[graph 0 input from stream 0:0 @ 0x3cd5fc0] Setting 'pix_fmt' to value '0'
[graph 0 input from stream 0:0 @ 0x3cd5fc0] Setting 'time_base' to value
'1/90000'
[graph 0 input from stream 0:0 @ 0x3cd5fc0] Setting 'pixel_aspect' to
value '1/1'
[graph 0 input from stream 0:0 @ 0x3cd5fc0] Setting 'sws_param' to value
'flags=2'
[graph 0 input from stream 0:0 @ 0x3cd5fc0] Setting 'frame_rate' to
value '25/1'
[graph 0 input from stream 0:0 @ 0x3cd5fc0] w:720 h:576 pixfmt:yuv420p
tb:1/90000 fr:25/1 sar:1/1 sws_param:flags=2
[format @ 0x3cf1660] compat: called with args=[vaapi_vld]
[format @ 0x3cf1660] Setting 'pix_fmts' to value 'vaapi_vld'
[auto-inserted scaler 0 @ 0x3cf2a60] Setting 'flags' to value 'bicubic'
[auto-inserted scaler 0 @ 0x3cf2a60] w:iw h:ih flags:'bicubic' interl:0
[Parsed_format_0 @ 0x3cf4840] auto-inserting filter 'auto-inserted
scaler 0' between the filter 'graph 0 input from stream 0:0' and the
filter 'Parsed_format_0'
[auto-inserted scaler 1 @ 0x3cf4ec0] Setting 'flags' to value 'bicubic'
[auto-inserted scaler 1 @ 0x3cf4ec0] w:iw h:ih flags:'bicubic' interl:0
[Parsed_hwupload_1 @ 0x3cd6100] auto-inserting filter 'auto-inserted
scaler 1' between the filter 'Parsed_format_0' and the filter
'Parsed_hwupload_1'
[AVFilterGraph @ 0x3cf9ce0] query_formats: 5 queried, 2 merged, 2
already done, 0 delayed
[auto-inserted scaler 1 @ 0x3cf4ec0] picking rgb0 out of 4 ref:nv12 alpha:0
[auto-inserted scaler 0 @ 0x3cf2a60] w:720 h:576 fmt:yuv420p sar:1/1 ->
w:720 h:576 fmt:nv12 sar:1/1 flags:0x4
[auto-inserted scaler 1 @ 0x3cf4ec0] w:720 h:576 fmt:nv12 sar:1/1 ->
w:720 h:576 fmt:rgb0 sar:1/1 flags:0x4
[hwupload @ 0x3cd61c0] Surface format is rgb0.
[AVHWFramesContext @ 0x3cf1700] Created surface 0x1.
[AVHWFramesContext @ 0x3cf1700] Direct mapping possible.
[h264_vaapi @ 0x3ce7dc0] Using fixed QP = 20 / 20 / 24 for IDR / P / B
frames.
[h264_vaapi @ 0x3ce7dc0] Using (null) as format of reconstructed frames.
[AVHWFramesContext @ 0x3d37fa0] Unsupported format: (null).
[h264_vaapi @ 0x3ce7dc0] Failed to initialise reconstructed frame
context: -22.
Output #0, matroska, to 'out.mkv':
Stream #0:0, 0, 0/0: Unknown: none, SAR 1:1 DAR 0:0
Metadata:
encoder : Lavc57.46.100 h264_vaapi
Stream mapping:
Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (h264_vaapi))
Error while opening encoder for output stream #0:0 - maybe incorrect
parameters such as bit_rate, rate, width or height
[AVIOContext @ 0x3ce8760] Statistics: 0 seeks, 0 writeouts
[AVIOContext @ 0x3bfa540] Statistics: 2019472 bytes read, 2 seeks

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-u

Andy Furniss

2016-06-18 09:00:09 UTC

Permalink

Post by Andy Furniss
libva info: va_openDriver() returns 0

Hmm, so this bit is a bit strange saying unknown as searching tells me
that it's nv12.

http://01org.github.io/libva_master_doxygen/group__api__core.html

#define VA_FOURCC_NV12 0x3231564E
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ

Mark Thompson

2016-06-18 15:37:12 UTC

Permalink

Default for H264 is High, so yeah you need -profile 66 to get it to work.
The detection queries the capabilities of a video processor instance (VAProfileNone / VAEntrypointVideoProc) to try to determine which formats are interesting, then ignores the ones which aren't. It should probably have said "not supported" here rather than "unknown" for nv12 (and yv12 immediately below it).

I've sent a patch to change the behaviour slightly which will improve this case, see <https://lists.libav.org/pipermail/libav-devel/2016-June/077669.html>.
hwupload reports its input capabilities based on what is returned above, so it will be saying that it can only take the RGB formats as input. Hence ffmpeg auto-inserts a swscale instance to change it back from nv12 to rgba. (The filter chain becomes 'format=nv12,format=rgba,hwupload'.)
The input to the encode is now in VAAPI rgba surfaces, but that doesn't match any of the capabilities so it doesn't know what to make the reconstructed frames. It should have fallen back to the one supported format (i.e. nv12), but a typo stoped it from doing that: fixed in <https://lists.libav.org/pipermail/libav-devel/2016-June/077668.html>.

Stream #0:0, 0, 0/0: Unknown: none, SAR 1:1 DAR 0:0
encoder : Lavc57.46.100 h264_vaapi
Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (h264_vaapi))
Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

So, I also went and built mesa with the encode patches and had a go. With the changes above, it does get to actually trying to encode, but that nuked my GPU to the point of requiring reboot.

With the linked patch you should be able to have a go too: if it works for you then I'm interested in what your setup is. If it nukes your GPU then, well, you had some warning at least. I think I'll wait until it's a bit more stable before pursuing this further.

Thanks,

- Mark

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg

Mark Thompson

2016-06-18 19:48:45 UTC

Permalink

Post by Mark Thompson

Default for H264 is High, so yeah you need -profile 66 to get it to work.
The detection queries the capabilities of a video processor instance (VAProfileNone / VAEntrypointVideoProc) to try to determine which formats are interesting, then ignores the ones which aren't. It should probably have said "not supported" here rather than "unknown" for nv12 (and yv12 immediately below it).
I've sent a patch to change the behaviour slightly which will improve this case, see <https://lists.libav.org/pipermail/libav-devel/2016-June/077669.html>.
hwupload reports its input capabilities based on what is returned above, so it will be saying that it can only take the RGB formats as input. Hence ffmpeg auto-inserts a swscale instance to change it back from nv12 to rgba. (The filter chain becomes 'format=nv12,format=rgba,hwupload'.)
The input to the encode is now in VAAPI rgba surfaces, but that doesn't match any of the capabilities so it doesn't know what to make the reconstructed frames. It should have fallen back to the one supported format (i.e. nv12), but a typo stoped it from doing that: fixed in <https://lists.libav.org/pipermail/libav-devel/2016-June/077668.html>.

Ok, I tried a bit more (including a few power cycles), and it does work. The critical extra step is to disable B-frames (that should probably happen automatically for baseline profile). It then works with input uploaded from the CPU or from a decode on the GPU.

For example: "./avconv -v 55 -y -vaapi_device /dev/dri/renderD129 -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -profile 66 -bf 0 -b 10M out.mp4".

The bitstream it outputs does work in ffmpeg, but it's very weird. It has CABAC enabled (not allowed in baseline), and the POC seems to only advance on every second frame (as if they were actually fields of an interlaced stream, except it isn't).

So, yeah. I think there is a lot more work to do before this is generally usable, but it is certainly working and I will keep testing it as more versions turn up.

Thanks,

- Mark

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org wit

Andy Furniss

2016-06-18 23:43:59 UTC

Permalink

Post by Mark Thompson

Default for H264 is High, so yeah you need -profile 66 to get it to work.
The detection queries the capabilities of a video processor instance (VAProfileNone / VAEntrypointVideoProc) to try to determine which formats are interesting, then ignores the ones which aren't. It should probably have said "not supported" here rather than "unknown" for nv12 (and yv12 immediately below it).
I've sent a patch to change the behaviour slightly which will improve this case, see <https://lists.libav.org/pipermail/libav-devel/2016-June/077669.html>.
hwupload reports its input capabilities based on what is returned above, so it will be saying that it can only take the RGB formats as input. Hence ffmpeg auto-inserts a swscale instance to change it back from nv12 to rgba. (The filter chain becomes 'format=nv12,format=rgba,hwupload'.)
The input to the encode is now in VAAPI rgba surfaces, but that doesn't match any of the capabilities so it doesn't know what to make the reconstructed frames. It should have fallen back to the one supported format (i.e. nv12), but a typo stoped it from doing that: fixed in <https://lists.libav.org/pipermail/libav-devel/2016-June/077668.html>.

Ok, I tried a bit more (including a few power cycles), and it does work. The critical extra step is to disable B-frames (that should probably happen automatically for baseline profile). It then works with input uploaded from the CPU or from a decode on the GPU.
For example: "./avconv -v 55 -y -vaapi_device /dev/dri/renderD129 -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -profile 66 -bf 0 -b 10M out.mp4".
The bitstream it outputs does work in ffmpeg, but it's very weird. It has CABAC enabled (not allowed in baseline), and the POC seems to only advance on every second frame (as if they were actually fields of an interlaced stream, except it isn't).
So, yeah. I think there is a lot more work to do before this is generally usable, but it is certainly working and I will keep testing it as more versions turn up.
Thanks,

Ahh, good - I hadn't seen this mail before preparing/sending the other
one :-(

The cabac thing is interesting - I have previously noticed that mediainfo
showed gstreamer vaapi as constrained but yes for cabac - but it also
said 2 for ref frames when ffprobe called one.

gstreamer omx files said no to cabac - I failed to find a way with
ffmpeg/ffprobe to see if cabac was off/on - is there one??

Also windows files get called as high, but I don't see any b frames
though the only windows files I have were made with a game recording app
that comes with the driver (raptr).

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg

Andy Furniss

2016-06-18 23:34:58 UTC

Permalink

Post by Mark Thompson

I tried avconv and it does care = bail, but I can use -profile 66 and then get the same error as ffmpeg (though it converts to rgba rather than rgb0)

Default for H264 is High, so yeah you need -profile 66 to get it to work.

OK, does baseline support b frames? I see wikipedia says no for b slices
but I don't know what they mean by that.

I do know examining output of things encoded windows and linux that I
only see I and P - see below.

Post by Mark Thompson
The detection queries the capabilities of a video processor instance (VAProfileNone / VAEntrypointVideoProc) to try to determine which formats are interesting, then ignores the ones which aren't. It should probably have said "not supported" here rather than "unknown" for nv12 (and yv12 immediately below it).
I've sent a patch to change the behaviour slightly which will improve this case, see <https://lists.libav.org/pipermail/libav-devel/2016-June/077669.html>.

Ahh, OK.

Post by Mark Thompson
hwupload reports its input capabilities based on what is returned above, so it will be saying that it can only take the RGB formats as input. Hence ffmpeg auto-inserts a swscale instance to change it back from nv12 to rgba. (The filter chain becomes 'format=nv12,format=rgba,hwupload'.)
The input to the encode is now in VAAPI rgba surfaces, but that doesn't match any of the capabilities so it doesn't know what to make the reconstructed frames. It should have fallen back to the one supported format (i.e. nv12), but a typo stoped it from doing that: fixed in <https://lists.libav.org/pipermail/libav-devel/2016-June/077668.html>.

So, I also went and built mesa with the encode patches and had a go. With the changes above, it does get to actually trying to encode, but that nuked my GPU to the point of requiring reboot.

Same here, I need both patches then it does encode but there are issues.

Post by Mark Thompson
With the linked patch you should be able to have a go too: if it works for you then I'm interested in what your setup is. If it nukes your GPU then, well, you had some warning at least. I think I'll wait until it's a bit more stable before pursuing this further.

I am using an R9 285 Tonga GPU. This uses the amdgpu kernel driver and
is still not totally stable for uvd/vce.

The instability revolves around powerplay (which IIRC isn't enabled by
default yet). I have test cases that will lock vce, but can avoid by not
letting powerplay vary clocks = force them high.

What h/w is yours?

Below is output of a run that produces corrupt video - I guess this is
due to trying to use b frames
but may be totally wrong :-)

The same input OK encoded with gstreamer vaapi. In theory my card should
do UHD, but there's a bug so I am limited smaller - older cards probably
wouldn't even do this res.

The results are the same testing with normal SD input + format=nv12.

Here's what it looks like -

https://drive.google.com/file/d/0BxP5-S1t9VEEUDR4V01Rblp2dlk/view?usp=sharing

andy [vce-tests]$ time ffm -loglevel debug -vaapi_device :0 -f rawvideo
-framerate 50 -s 2560x1440 -pix_fmt nv12 -i
/mnt/ramdisk/ducks-2560x1440.nv12 -vframes 20 -vf 'hwupload' -c:v
h264_vaapi -profile:v 66 -b:v 40M -y /mnt/ramdisk/out.mp4
ffmpeg version N-80356-g7f1b503 Copyright (c) 2000-2016 the FFmpeg
developers
built with gcc 5.3.0 (GCC)
configuration: --prefix=/usr --disable-doc --enable-gpl --enable-omx
--enable-opencl --enable-libzimg --enable-libvpx --enable-libx265
--enable-libmp3lame --enable-libx264 --enable-gnutls
libavutil 55. 24.100 / 55. 24.100
libavcodec 57. 46.100 / 57. 46.100
libavformat 57. 38.100 / 57. 38.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 46.101 / 6. 46.101
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
Splitting the commandline.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging
level) with argument 'debug'.
Reading option '-vaapi_device' ... matched as option 'vaapi_device' (set
VAAPI hardware device (DRM path or X11 display name)) with argument ':0'.
Reading option '-f' ... matched as option 'f' (force format) with
argument 'rawvideo'.
Reading option '-framerate' ... matched as AVOption 'framerate' with
argument '50'.
Reading option '-s' ... matched as option 's' (set frame size (WxH or
abbreviation)) with argument '2560x1440'.
Reading option '-pix_fmt' ... matched as option 'pix_fmt' (set pixel
format) with argument 'nv12'.
Reading option '-i' ... matched as input file with argument
'/mnt/ramdisk/ducks-2560x1440.nv12'.
Reading option '-vframes' ... matched as option 'vframes' (set the
number of video frames to output) with argument '20'.
Reading option '-vf' ... matched as option 'vf' (set video filters) with
argument 'hwupload'.
Reading option '-c:v' ... matched as option 'c' (codec name) with
argument 'h264_vaapi'.
Reading option '-profile:v' ... matched as option 'profile' (set
profile) with argument '66'.
Reading option '-b:v' ... matched as option 'b' (video bitrate (please
use -b:v)) with argument '40M'.
Reading option '-y' ... matched as option 'y' (overwrite output files)
with argument '1'.
Reading option '/mnt/ramdisk/out.mp4' ... matched as output file.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument debug.
Applying option vaapi_device (set VAAPI hardware device (DRM path or X11
display name)) with argument :0.
[vaapi @ 0x190e300] Opened VA display via X11 display :0.
libva info: VA-API version 0.38.1
libva info: va_getDriverName() returns 0
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
[vaapi @ 0x190e300] Initialised VAAPI connection: version 0.38
[AVHWDeviceContext @ 0x28803a0] Format 0x3231564e -> nv12.
[AVHWDeviceContext @ 0x28803a0] Format 0x32315659 -> yuv420p.
[AVHWDeviceContext @ 0x28803a0] Format 0x56595559 -> unknown.
[AVHWDeviceContext @ 0x28803a0] Format 0x59565955 -> uyvy422.
[AVHWDeviceContext @ 0x28803a0] Format 0x41524742 -> bgra.
[AVHWDeviceContext @ 0x28803a0] Format 0x41424752 -> rgba.
[AVHWDeviceContext @ 0x28803a0] Format 0x58524742 -> bgr0.
[AVHWDeviceContext @ 0x28803a0] Format 0x58424752 -> rgb0.
Applying option y (overwrite output files) with argument 1.
Successfully parsed a group of options.
Parsing a group of options: input file /mnt/ramdisk/ducks-2560x1440.nv12.
Applying option f (force format) with argument rawvideo.
Applying option s (set frame size (WxH or abbreviation)) with argument
2560x1440.
Applying option pix_fmt (set pixel format) with argument nv12.
Successfully parsed a group of options.
Opening an input file: /mnt/ramdisk/ducks-2560x1440.nv12.
[file @ 0x28814a0] Setting default whitelist 'file,crypto'
[rawvideo @ 0x288fe00] Before avformat_find_stream_info() pos: 0 bytes
read:32768 seeks:0 nb_streams:1
[rawvideo @ 0x288fe00] All info found
[rawvideo @ 0x288fe00] After avformat_find_stream_info() pos: 5529600
bytes read:5529600 seeks:0 frames:1
Input #0, rawvideo, from '/mnt/ramdisk/ducks-2560x1440.nv12':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0, 1, 1/50: Video: rawvideo, 1 reference frame (NV12 /
0x3231564E), nv12, 2560x1440, 0/1, 2211840 kb/s, 50 tbr, 50 tbn, 50 tbc
Successfully opened the file.
Parsing a group of options: output file /mnt/ramdisk/out.mp4.
Applying option vframes (set the number of video frames to output) with
argument 20.
Applying option vf (set video filters) with argument hwupload.
Applying option c:v (codec name) with argument h264_vaapi.
Applying option profile:v (set profile) with argument 66.
Applying option b:v (video bitrate (please use -b:v)) with argument 40M.
Successfully parsed a group of options.
Opening an output file: /mnt/ramdisk/out.mp4.
[file @ 0x2890920] Setting default whitelist 'file,crypto'
Successfully opened the file.
detected 4 logical cores
[graph 0 input from stream 0:0 @ 0x2880ac0] Setting 'video_size' to
value '2560x1440'
[graph 0 input from stream 0:0 @ 0x2880ac0] Setting 'pix_fmt' to value '25'
[graph 0 input from stream 0:0 @ 0x2880ac0] Setting 'time_base' to value
'1/50'
[graph 0 input from stream 0:0 @ 0x2880ac0] Setting 'pixel_aspect' to
value '0/1'
[graph 0 input from stream 0:0 @ 0x2880ac0] Setting 'sws_param' to value
'flags=2'
[graph 0 input from stream 0:0 @ 0x2880ac0] Setting 'frame_rate' to
value '50/1'
[graph 0 input from stream 0:0 @ 0x2880ac0] w:2560 h:1440 pixfmt:nv12
tb:1/50 fr:50/1 sar:0/1 sws_param:flags=2
[format @ 0x2890d00] compat: called with args=[vaapi_vld]
[format @ 0x2890d00] Setting 'pix_fmts' to value 'vaapi_vld'
[AVFilterGraph @ 0x28809e0] query_formats: 4 queried, 3 merged, 0
already done, 0 delayed
[hwupload @ 0x2884de0] Surface format is nv12.
[AVHWFramesContext @ 0x286b260] Created surface 0x1.
[AVHWFramesContext @ 0x286b260] Direct mapping possible.
[h264_vaapi @ 0x2878e20] Using constant-bitrate = 40000000 bps.
[h264_vaapi @ 0x2878e20] Using nv12 as format of reconstructed frames.
[AVHWFramesContext @ 0x2875b20] Created surface 0x3.
[AVHWFramesContext @ 0x2875b20] Direct mapping possible.
[AVHWFramesContext @ 0x2875b20] Created surface 0x4.
[AVHWFramesContext @ 0x2875b20] Created surface 0x5.
[AVHWFramesContext @ 0x2875b20] Created surface 0x6.
[AVHWFramesContext @ 0x2875b20] Created surface 0x7.
[AVHWFramesContext @ 0x2875b20] Created surface 0x8.
[AVHWFramesContext @ 0x2875b20] Created surface 0x9.
[AVHWFramesContext @ 0x2875b20] Created surface 0xa.
[AVHWFramesContext @ 0x2875b20] Created surface 0xb.
[AVHWFramesContext @ 0x2875b20] Created surface 0xc.
[AVHWFramesContext @ 0x2875b20] Created surface 0xd.
[AVHWFramesContext @ 0x2875b20] Created surface 0xe.
[AVHWFramesContext @ 0x2875b20] Created surface 0xf.
[AVHWFramesContext @ 0x2875b20] Created surface 0x10.
[AVHWFramesContext @ 0x2875b20] Created surface 0x11.
[AVHWFramesContext @ 0x2875b20] Created surface 0x12.
[AVHWFramesContext @ 0x2875b20] Created surface 0x13.
[AVHWFramesContext @ 0x2875b20] Created surface 0x14.
[AVHWFramesContext @ 0x2875b20] Created surface 0x15.
[AVHWFramesContext @ 0x2875b20] Created surface 0x16.
[mp4 @ 0x2891360] Using AVStream.codec to pass codec parameters to
muxers is deprecated, use AVStream.codecpar instead.
Output #0, mp4, to '/mnt/ramdisk/out.mp4':
Metadata:
encoder : Lavf57.38.100
Stream #0:0, 0, 1/12800: Video: h264 (h264_vaapi) (Baseline), 1
reference frame ([33][0][0][0] / 0x0021), vaapi_vld, 2560x1440, 0/1,
q=2-31, 40000 kb/s, 50 fps, 12800 tbn, 50 tbc
Metadata:
encoder : Lavc57.46.100 h264_vaapi
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (h264_vaapi))
Press [q] to stop, [?] for help
cur_dts is invalid (this is harmless if it occurs once at the start per
stream)
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x1.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x1.
Clipping frame in rate conversion by 0.000008
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (0).
[h264_vaapi @ 0x2878e20] Issuing encode for pic 0/0 as type IDR.
[h264_vaapi @ 0x2878e20] No reference pictures.
[h264_vaapi @ 0x2878e20] Input surface is 0x1.
[h264_vaapi @ 0x2878e20] Recon surface is 0x16.
[h264_vaapi @ 0x2878e20] Output buffer is 0x18.
[h264_vaapi @ 0x2878e20] Param buffer (27) is 0x19.
[h264_vaapi @ 0x2878e20] Param buffer (27) is 0x1a.
[h264_vaapi @ 0x2878e20] Param buffer (22) is 0x1b.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x1c.
[h264_vaapi @ 0x2878e20] Packed header buffer (1) is 0x1d/0x1e (176 bits).
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x1f/0x20 (61 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x21.
cur_dts is invalid (this is harmless if it occurs once at the start per
stream)
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Created surface 0x22.
[AVHWFramesContext @ 0x286b260] Map surface 0x22.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x22.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (1).
[h264_vaapi @ 0x2878e20] Pictures: IDR (0/0) B (1/2) B (2/3) P (3/1)
cur_dts is invalid (this is harmless if it occurs once at the start per
stream)
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Created surface 0x23.
[AVHWFramesContext @ 0x286b260] Map surface 0x23.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x23.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (2).
[h264_vaapi @ 0x2878e20] Sync to pic 0/0 (recon surface 0x16).
[h264_vaapi @ 0x2878e20] Output buffer: 146473 bytes (status 027a8350).
[h264_vaapi @ 0x2878e20] Output read for pic 0/0.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x1.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x1.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (3).
[h264_vaapi @ 0x2878e20] Issuing encode for pic 3/1 as type P.
[h264_vaapi @ 0x2878e20] Refers to: 0/0.
[h264_vaapi @ 0x2878e20] Input surface is 0x1.
[h264_vaapi @ 0x2878e20] Recon surface is 0x15.
[h264_vaapi @ 0x2878e20] Output buffer is 0x18.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x24.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x25/0x26 (59 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x27.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 1/2 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 0/0 3/1.
[h264_vaapi @ 0x2878e20] Input surface is 0x22.
[h264_vaapi @ 0x2878e20] Recon surface is 0x14.
[h264_vaapi @ 0x2878e20] Output buffer is 0x28.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x29.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x2a/0x2b (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x2c.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 2/3 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 0/0 3/1.
[h264_vaapi @ 0x2878e20] Input surface is 0x23.
[h264_vaapi @ 0x2878e20] Recon surface is 0x13.
[h264_vaapi @ 0x2878e20] Output buffer is 0x2d.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x2e.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x2f/0x30 (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x31.
[h264_vaapi @ 0x2878e20] Sync to pic 3/1 (recon surface 0x15).
[h264_vaapi @ 0x2878e20] Output buffer: 73208 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 3/1.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Created surface 0x18.
[AVHWFramesContext @ 0x286b260] Map surface 0x18.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x18.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (4).
[h264_vaapi @ 0x2878e20] Pictures: IDR (0/0) B (1/2) B (2/3) P (3/1) B
(4/5) B (5/6) P (6/4)
[h264_vaapi @ 0x2878e20] Sync to pic 1/2 (recon surface 0x14).
[h264_vaapi @ 0x2878e20] Output buffer: 23255 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 1/2.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x1.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x1.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (5).
[h264_vaapi @ 0x2878e20] Sync to pic 2/3 (recon surface 0x13).
[h264_vaapi @ 0x2878e20] Output buffer: 53071 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 2/3.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x23.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x23.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (6).
[h264_vaapi @ 0x2878e20] Issuing encode for pic 6/4 as type P.
[h264_vaapi @ 0x2878e20] Refers to: 3/1.
[h264_vaapi @ 0x2878e20] Input surface is 0x23.
[h264_vaapi @ 0x2878e20] Recon surface is 0x13.
[h264_vaapi @ 0x2878e20] Output buffer is 0x28.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x2d.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x32/0x33 (59 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x34.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 4/5 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 3/1 6/4.
[h264_vaapi @ 0x2878e20] Input surface is 0x18.
[h264_vaapi @ 0x2878e20] Recon surface is 0x14.
[h264_vaapi @ 0x2878e20] Output buffer is 0x35.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x36.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x37/0x38 (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x39.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 5/6 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 3/1 6/4.
[h264_vaapi @ 0x2878e20] Input surface is 0x1.
[h264_vaapi @ 0x2878e20] Recon surface is 0x16.
[h264_vaapi @ 0x2878e20] Output buffer is 0x3a.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x3b.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x3c/0x3d (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x3e.
[h264_vaapi @ 0x2878e20] Sync to pic 6/4 (recon surface 0x13).
[h264_vaapi @ 0x2878e20] Output buffer: 132391 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 6/4.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x22.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x22.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (7).
[h264_vaapi @ 0x2878e20] Pictures: P (3/1) B (4/5) B (5/6) P (6/4) B
(7/8) B (8/9) P (9/7)
[h264_vaapi @ 0x2878e20] Sync to pic 4/5 (recon surface 0x14).
[h264_vaapi @ 0x2878e20] Output buffer: 143867 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 4/5.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x23.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x23.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (8).
[h264_vaapi @ 0x2878e20] Sync to pic 5/6 (recon surface 0x16).
[h264_vaapi @ 0x2878e20] Output buffer: 165976 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 5/6.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x1.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x1.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (9).
[h264_vaapi @ 0x2878e20] Issuing encode for pic 9/7 as type P.
[h264_vaapi @ 0x2878e20] Refers to: 6/4.
[h264_vaapi @ 0x2878e20] Input surface is 0x1.
[h264_vaapi @ 0x2878e20] Recon surface is 0x16.
[h264_vaapi @ 0x2878e20] Output buffer is 0x28.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x35.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x3a/0x3f (59 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x40.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 7/8 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 6/4 9/7.
[h264_vaapi @ 0x2878e20] Input surface is 0x22.
[h264_vaapi @ 0x2878e20] Recon surface is 0x14.
[h264_vaapi @ 0x2878e20] Output buffer is 0x41.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x42.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x43/0x44 (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x45.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 8/9 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 6/4 9/7.
[h264_vaapi @ 0x2878e20] Input surface is 0x23.
[h264_vaapi @ 0x2878e20] Recon surface is 0x15.
[h264_vaapi @ 0x2878e20] Output buffer is 0x46.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x47.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x48/0x49 (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x4a.
[h264_vaapi @ 0x2878e20] Sync to pic 9/7 (recon surface 0x16).
[h264_vaapi @ 0x2878e20] Output buffer: 218441 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 9/7.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x18.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x18.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (10).
[h264_vaapi @ 0x2878e20] Pictures: P (6/4) B (7/8) B (8/9) P (9/7) B
(10/11) B (11/12) P (12/10)
[h264_vaapi @ 0x2878e20] Sync to pic 7/8 (recon surface 0x14).
[h264_vaapi @ 0x2878e20] Output buffer: 155818 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 7/8.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x1.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x1.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (11).
[h264_vaapi @ 0x2878e20] Sync to pic 8/9 (recon surface 0x15).
[h264_vaapi @ 0x2878e20] Output buffer: 183157 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 8/9.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x23.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x23.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (12).
[h264_vaapi @ 0x2878e20] Issuing encode for pic 12/10 as type P.
[h264_vaapi @ 0x2878e20] Refers to: 9/7.
[h264_vaapi @ 0x2878e20] Input surface is 0x23.
[h264_vaapi @ 0x2878e20] Recon surface is 0x15.
[h264_vaapi @ 0x2878e20] Output buffer is 0x28.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x41.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x46/0x4b (59 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x4c.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 10/11 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 9/7 12/10.
[h264_vaapi @ 0x2878e20] Input surface is 0x18.
[h264_vaapi @ 0x2878e20] Recon surface is 0x14.
[h264_vaapi @ 0x2878e20] Output buffer is 0x4d.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x4e.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x4f/0x50 (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x51.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 11/12 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 9/7 12/10.
[h264_vaapi @ 0x2878e20] Input surface is 0x1.
[h264_vaapi @ 0x2878e20] Recon surface is 0x13.
[h264_vaapi @ 0x2878e20] Output buffer is 0x52.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x53.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x54/0x55 (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x56.
[h264_vaapi @ 0x2878e20] Sync to pic 12/10 (recon surface 0x15).
[h264_vaapi @ 0x2878e20] Output buffer: 204621 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 12/10.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x22.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x22.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (13).
[h264_vaapi @ 0x2878e20] Pictures: P (9/7) B (10/11) B (11/12) P (12/10)
B (13/14) B (14/15) P (15/13)
[h264_vaapi @ 0x2878e20] Sync to pic 10/11 (recon surface 0x14).
[h264_vaapi @ 0x2878e20] Output buffer: 140654 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 10/11.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x23.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x23.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (14).
[h264_vaapi @ 0x2878e20] Sync to pic 11/12 (recon surface 0x13).
[h264_vaapi @ 0x2878e20] Output buffer: 150177 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 11/12.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x1.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x1.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (15).
[h264_vaapi @ 0x2878e20] Issuing encode for pic 15/13 as type P.
[h264_vaapi @ 0x2878e20] Refers to: 12/10.
[h264_vaapi @ 0x2878e20] Input surface is 0x1.
[h264_vaapi @ 0x2878e20] Recon surface is 0x13.
[h264_vaapi @ 0x2878e20] Output buffer is 0x28.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x4d.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x52/0x57 (59 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x58.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 13/14 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 12/10 15/13.
[h264_vaapi @ 0x2878e20] Input surface is 0x22.
[h264_vaapi @ 0x2878e20] Recon surface is 0x14.
[h264_vaapi @ 0x2878e20] Output buffer is 0x59.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x5a.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x5b/0x5c (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x5d.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 14/15 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 12/10 15/13.
[h264_vaapi @ 0x2878e20] Input surface is 0x23.
[h264_vaapi @ 0x2878e20] Recon surface is 0x16.
[h264_vaapi @ 0x2878e20] Output buffer is 0x5e.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x5f.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x60/0x61 (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x62.
[h264_vaapi @ 0x2878e20] Sync to pic 15/13 (recon surface 0x13).
[h264_vaapi @ 0x2878e20] Output buffer: 204727 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 15/13.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x18.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x18.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (16).
[h264_vaapi @ 0x2878e20] Pictures: P (12/10) B (13/14) B (14/15) P
(15/13) B (16/17) B (17/18) P (18/16)
[h264_vaapi @ 0x2878e20] Sync to pic 13/14 (recon surface 0x14).
[h264_vaapi @ 0x2878e20] Output buffer: 147924 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 13/14.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 384026
bitrate=65943.5kbits/s speed=0.503x
[AVHWFramesContext @ 0x286b260] Map surface 0x1.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x1.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (17).
[h264_vaapi @ 0x2878e20] Sync to pic 14/15 (recon surface 0x16).
[h264_vaapi @ 0x2878e20] Output buffer: 164388 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 14/15.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x23.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x23.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (18).
[h264_vaapi @ 0x2878e20] Issuing encode for pic 18/16 as type P.
[h264_vaapi @ 0x2878e20] Refers to: 15/13.
[h264_vaapi @ 0x2878e20] Input surface is 0x23.
[h264_vaapi @ 0x2878e20] Recon surface is 0x16.
[h264_vaapi @ 0x2878e20] Output buffer is 0x28.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x59.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x5e/0x63 (59 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x64.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 16/17 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 15/13 18/16.
[h264_vaapi @ 0x2878e20] Input surface is 0x18.
[h264_vaapi @ 0x2878e20] Recon surface is 0x14.
[h264_vaapi @ 0x2878e20] Output buffer is 0x65.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x66.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x67/0x68 (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x69.
[h264_vaapi @ 0x2878e20] Issuing encode for pic 17/18 as type B.
[h264_vaapi @ 0x2878e20] Refers to: 15/13 18/16.
[h264_vaapi @ 0x2878e20] Input surface is 0x1.
[h264_vaapi @ 0x2878e20] Recon surface is 0x15.
[h264_vaapi @ 0x2878e20] Output buffer is 0x6a.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x6b.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x6c/0x6d (62 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x6e.
[h264_vaapi @ 0x2878e20] Sync to pic 18/16 (recon surface 0x16).
[h264_vaapi @ 0x2878e20] Output buffer: 200274 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 18/16.
[rawvideo @ 0x2783060] PACKET SIZE: 5529600, STRIDE: 3840
[AVHWFramesContext @ 0x286b260] Map surface 0x22.
[AVHWFramesContext @ 0x286b260] Unmap surface 0x22.
[h264_vaapi @ 0x2878e20] Encode frame: 2560x1440 (19).
[h264_vaapi @ 0x2878e20] Pictures: P (15/13) B (16/17) B (17/18) P
(18/16) B (19/20) B (20/21) P (21/19)
[h264_vaapi @ 0x2878e20] Sync to pic 16/17 (recon surface 0x14).
[h264_vaapi @ 0x2878e20] Output buffer: 151444 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 16/17.
No more output streams to write to, finishing.
[h264_vaapi @ 0x2878e20] Pictures at end of stream: P (15/13) B (16/17)
B (17/18) P (18/16) P (19/19)
[h264_vaapi @ 0x2878e20] Issuing encode for pic 19/19 as type P.
[h264_vaapi @ 0x2878e20] Refers to: 18/16.
[h264_vaapi @ 0x2878e20] Input surface is 0x22.
[h264_vaapi @ 0x2878e20] Recon surface is 0x12.
[h264_vaapi @ 0x2878e20] Output buffer is 0x28.
[h264_vaapi @ 0x2878e20] Param buffer (23) is 0x65.
[h264_vaapi @ 0x2878e20] Packed header buffer (3) is 0x6f/0x70 (59 bits).
[h264_vaapi @ 0x2878e20] Param buffer (24) is 0x71.
[h264_vaapi @ 0x2878e20] Sync to pic 17/18 (recon surface 0x15).
[h264_vaapi @ 0x2878e20] Output buffer: 137733 bytes (status 8dd0b368).
[h264_vaapi @ 0x2878e20] Output read for pic 17/18.
[h264_vaapi @ 0x2878e20] Sync to pic 19/19 (recon surface 0x12).
[h264_vaapi @ 0x2878e20] Output buffer: 190485 bytes (status 02cd3f60).
[h264_vaapi @ 0x2878e20] Output read for pic 19/19.
frame= 20 fps=0.0 q=-0.0 Lsize= 2919kB time=00:00:00.36
bitrate=66409.8kbits/s speed=0.556x
video:2918kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.033634%
Input file #0 (/mnt/ramdisk/ducks-2560x1440.nv12):
Input stream #0:0 (video): 20 packets read (110592000 bytes); 20
frames decoded;
Total: 20 packets (110592000 bytes) demuxed
Output file #0 (/mnt/ramdisk/out.mp4):
Output stream #0:0 (video): 20 frames encoded; 20 packets muxed
(2988084 bytes);
Total: 20 packets (2988084 bytes) muxed
20 frames successfully decoded, 0 decoding errors
[AVIOContext @ 0x286c0a0] Statistics: 34 seeks, 129 writeouts
[vaapi @ 0x190e300] Terminating VAAPI connection.
[AVIOContext @ 0x2885100] Statistics: 110592000 bytes read, 0 seeks

real 0m0.748s
user 0m0.134s
sys 0m0.070s

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with s

Mark Thompson

2016-06-19 11:35:46 UTC

Permalink

Post by Andy Furniss

Post by Mark Thompson
So, I also went and built mesa with the encode patches and had a go. With the changes above, it does get to actually trying to encode, but that nuked my GPU to the point of requiring reboot.

Same here, I need both patches then it does encode but there are issues.

R7 360 (Bonaire, a Sea Island), so yours is one generation newer. I am therefore using radeonsi, though I believe the back-end parts talking to UVD/VCE here are actually in common between the two drivers so it shouldn't be relevant?

Post by Andy Furniss
Below is output of a run that produces corrupt video - I guess this is due to trying to use b frames
but may be totally wrong :-)

Yeah. The attempt to use B frames when they aren't supported means the frame referencing is all messed up. When I tried with "-bf 0", it made a stream which decoded with no obvious artifacts (though somewhat weird, as noted previously).

Post by Andy Furniss
The same input OK encoded with gstreamer vaapi. In theory my card should
do UHD, but there's a bug so I am limited smaller - older cards probably wouldn't even do this res.
The results are the same testing with normal SD input + format=nv12.

I only tried 1080p, and it was happy. I believe that generation won't be able to do a bigger stream like the one you tested anyway.

Post by Andy Furniss
Here's what it looks like -
https://drive.google.com/file/d/0BxP5-S1t9VEEUDR4V01Rblp2dlk/view?usp=sharing
andy [vce-tests]$ time ffm -loglevel debug -vaapi_device :0 -f rawvideo -framerate 50 -s 2560x1440 -pix_fmt nv12 -i /mnt/ramdisk/ducks-2560x1440.nv12 -vframes 20 -vf 'hwupload' -c:v h264_vaapi -profile:v 66 -b:v 40M -y /mnt/ramdisk/out.mp4

Looks very similar to the streams I got, modulo the funniness around B frames. I guess that's reassuring that it's not wildly different with different GPUs, at least.

On ref frames, it has max_ref_frames = 3 but only ever uses 1. Unsure what to read into that.

Post by Andy Furniss

Post by Mark Thompson
Ok, I tried a bit more (including a few power cycles), and it does work. The critical extra step is to disable B-frames (that should probably happen automatically for baseline profile). It then works with input uploaded from the CPU or from a decode on the GPU.
For example: "./avconv -v 55 -y -vaapi_device /dev/dri/renderD129 -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -profile 66 -bf 0 -b 10M out.mp4".
The bitstream it outputs does work in ffmpeg, but it's very weird. It has CABAC enabled (not allowed in baseline), and the POC seems to only advance on every second frame (as if they were actually fields of an interlaced stream, except it isn't).
So, yeah. I think there is a lot more work to do before this is generally usable, but it is certainly working and I will keep testing it as more versions turn up.

Not that I know of. I test this sort of thing by feeding streams into the reference decoder with trace enabled and reading the bitstream trace :/

Post by Andy Furniss
Also windows files get called as high, but I don't see any b frames
though the only windows files I have were made with a game recording app that comes with the driver (raptr).

It will be the driver (or something further out) writing the headers rather than the hardware, so I don't regard it as surprising that the labelling of the profile is confused.

- Mark

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ

Andy Furniss

2016-06-20 17:58:36 UTC

Permalink

Post by Mark Thompson

Post by Andy Furniss
What h/w is yours?

R7 360 (Bonaire, a Sea Island), so yours is one generation newer. I
am therefore using radeonsi, though I believe the back-end parts
talking to UVD/VCE here are actually in common between the two
drivers so it shouldn't be relevant?

Yea I am still radeonsi as far as mesa is concerned.

There seems to be several different vce versions in the driver files
and in kernel vce 2 and 3 are separate files.

Post by Mark Thompson

Post by Andy Furniss
Below is output of a run that produces corrupt video - I guess
this is due to trying to use b frames but may be totally wrong :-)

Yeah. The attempt to use B frames when they aren't supported means
the frame referencing is all messed up. When I tried with "-bf 0",
it made a stream which decoded with no obvious artifacts (though
somewhat weird, as noted previously).

Yea, it's a bit strange as b frames do get mentioned in the driver code
I don't know why they don't work, but at least someone is working on it
again. While just looking I saw a TODO for b frames on my h/w in
combination with dual pipe which it seems tonga has.

Disabling b-frames does produce good output for me with cbr (though
the POC issue is there and it's not there with gstreamer vaapi.

With both ffmpeg and gstreamer cpq has issues. With ffmpeg depending
on source it may produce unplayable output. With gstreamer it seems to
use qp=0.

Post by Mark Thompson
On ref frames, it has max_ref_frames = 3 but only ever uses 1.
Unsure what to read into that.

Yea strange - again in the code there is apparently provision to use more.

Post by Mark Thompson

Post by Andy Furniss
The cabac thing is interesting - I have previously noticed that
mediainfo showed gstreamer vaapi as constrained but yes for cabac -
but it also said 2 for ref frames when ffprobe called one.
gstreamer omx files said no to cabac - I failed to find a way with
ffmpeg/ffprobe to see if cabac was off/on - is there one??

Not that I know of. I test this sort of thing by feeding streams
into the reference decoder with trace enabled and reading the
bitstream trace :/

I tried using the ref decoder, so I can now see this :-)

I also found some code that controls it and learnt a bit playing.

search cabac in mesa/src/gallium/drivers/radeon/radeon_vce.c

and it's there waiting to be changed - there are 2 places depending
on whether enable_low_level_control is true. For vaapi this is the one
and defaults on. For gst-omx it hits the other one default off.

I guess omx using the other one may go some way to explain why it is
3x faster than vaapi. It does make strange files though = 1 I frame
per 1000.

Post by Mark Thompson

Post by Andy Furniss
Also windows files get called as high, but I don't see any b
frames though the only windows files I have were made with a game
recording app that comes with the driver (raptr).

It will be the driver (or something further out) writing the headers
rather than the hardware, so I don't regard it as surprising that the
labelling of the profile is confused.

Yea, again though the code seems to have provision for different levels
and wikipedia claims VCE 2.0 supports b-frames + 444, so maybe baseline
is just because the code is unfinished.

_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg