[Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface
Zhang, Boyuan
Boyuan.Zhang at amd.com
Wed Jul 20 22:25:05 UTC 2016
Hi Andy,
Thanks very much for providing all the information.
The I420 U V swapping issue still can't be reproduced from my side, I will try it again later. CQP issue is fixed in the new patch set I just submitted. Please use " ... vaapiencodeh264 rate-control=cqp init-qp=x ..." command, where x can be any value b/w 0--51. Please give a try and let me know the result. Other issues, e.g. encoding speed, ffmpeg, will be addressed/investigated later in separate patch as I mentioned. This initial patch set is to bring up VAAPI encode for gstreamer with basic functionality working. I will update with you once we make progress.
Regards,
Boyuan
-----Original Message-----
From: Andy Furniss [mailto:adf.lists at gmail.com]
Sent: July-20-16 5:31 AM
To: Zhang, Boyuan; 'Christian König'; mesa-dev at lists.freedesktop.org
Subject: Re: [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface
Zhang, Boyuan wrote:
> Hi Andy,
>
>
> Thanks for the confirmation. It seems like all basic functionality is
> working now.
>
>
> I will look into the cqp issue. And for the speed related issue, we
> understand the reason and have already planned to work on it after
> this bring-up. However, it will be a separate patch in future, and
> won't be included in this bring-up patch set.
OK, though I didn't list it as remaining below due to sending a separate mail - the I420 issue is still present. I don't know what other s/w decoders output, but ffmpeg (so avdec_h264 in a gatreamer pipeline) always seem to use I420 (yuv420p) rather than YV12 which the conversion assumes.
So far I've been testing with gstreamer. ffmpeg needs patches from libav and always had some issues.
I tried again, and there's a possible further regression - though I have no idea whether it's ffmpeg or the newer patches here.
Just thought I would mention it, as I haven't had time to look into it further yet.
The regression is that when asking for a bitrate there is now a floating point exception, -qp still works (comes out at 0 like gst).
andy [vce-tests]$ gdb /mnt/sdb1/Gits/ffmpeg/ffmpeg_g GNU gdb (GDB) 7.10.1 Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/sdb1/Gits/ffmpeg/ffmpeg_g...done.
(gdb) run -vaapi_device /dev/dri/renderD128 -f rawvideo -framerate 50 -s
2560x1440 -pix_fmt nv12 -i /mnt/ramdisk/trees-1440p50.nv12 -vf 'hwupload' -c:v h264_vaapi -profile:v 66 -b:v 40M -bf 0 -y
/mnt/ramdisk/ffm-40M.264
Starting program: /mnt/sdb1/Gits/ffmpeg/ffmpeg_g -vaapi_device
/dev/dri/renderD128 -f rawvideo -framerate 50 -s 2560x1440 -pix_fmt nv12 -i /mnt/ramdisk/trees-1440p50.nv12 -vf 'hwupload' -c:v h264_vaapi -profile:v 66 -b:v 40M -bf 0 -y /mnt/ramdisk/ffm-40M.264 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0x7fffea690700 (LWP 907)]
[New Thread 0x7fffe9c8b700 (LWP 908)]
[New Thread 0x7fffe948a700 (LWP 909)]
[New Thread 0x7fffe8c89700 (LWP 910)]
[New Thread 0x7fffe8488700 (LWP 911)]
[New Thread 0x7fffe7c87700 (LWP 912)]
[New Thread 0x7fffe7486700 (LWP 913)]
[New Thread 0x7fffe6c85700 (LWP 914)]
[New Thread 0x7fffe6484700 (LWP 915)]
[Thread 0x7fffe6484700 (LWP 915) exited] [Thread 0x7fffe6c85700 (LWP 914) exited] [Thread 0x7fffe7486700 (LWP 913) exited] [Thread 0x7fffe7c87700 (LWP 912) exited] ffmpeg version N-81050-g9bf3fdc 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. 28.100 / 55. 28.100
libavcodec 57. 50.100 / 57. 50.100
libavformat 57. 43.100 / 57. 43.100
libavdevice 57. 0.102 / 57. 0.102
libavfilter 6. 47.100 / 6. 47.100
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
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 [New Thread 0x7fffe6484700 (LWP 916)] [New Thread 0x7fffe6c85700 (LWP 917)] [New Thread 0x7fffe7486700 (LWP 918)] [New Thread 0x7fffe7c87700 (LWP 919)] [New Thread 0x7fffe4b03700 (LWP 920)] libva info: va_openDriver() returns 0 [rawvideo @ 0x1f15800] Estimating duration from bitrate, this may be inaccurate Input #0, rawvideo, from '/mnt/ramdisk/trees-1440p50.nv12':
Duration: 00:00:10.00, start: 0.000000, bitrate: 2211840 kb/s
Stream #0:0: Video: rawvideo (NV12 / 0x3231564E), nv12, 2560x1440,
2211840 kb/s, 50 tbr, 50 tbn, 50 tbc
[New Thread 0x7fffd7ab8700 (LWP 921)]
[New Thread 0x7fffd72b7700 (LWP 922)]
[New Thread 0x7fffd6ab6700 (LWP 923)]
[New Thread 0x7fffd62b5700 (LWP 924)]
[New Thread 0x7fffd5ab4700 (LWP 925)]
[h264 @ 0x1e2c300] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Output #0, h264, to '/mnt/ramdisk/ffm-40M.264':
Metadata:
encoder : Lavf57.43.100
Stream #0:0: Video: h264 (h264_vaapi) (Baseline), vaapi_vld, 2560x1440, q=2-31, 40000 kb/s, 50 fps, 50 tbn, 50 tbc
Metadata:
encoder : Lavc57.50.100 h264_vaapi
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (h264_vaapi)) Press [q] to stop, [?] for help
Program received signal SIGFPE, Arithmetic exception.
vlVaRenderPicture (ctx=<optimized out>, context_id=<optimized out>, buffers=<optimized out>, num_buffers=<optimized out>) at picture.c:496
496 vaStatus = handleVAEncMiscParameterBufferType(context,
buf);
(gdb) bt
#0 vlVaRenderPicture (ctx=<optimized out>, context_id=<optimized out>, buffers=<optimized out>, num_buffers=<optimized out>) at picture.c:496
#1 0x0000000000e628ed in vaapi_encode_issue (avctx=avctx at entry=0x1f1f780, pic=pic at entry=0x1f30820) at
libavcodec/vaapi_encode.c:374
#2 0x0000000000e62b86 in vaapi_encode_step (avctx=avctx at entry=0x1f1f780, target=target at entry=0x1f30820) at
libavcodec/vaapi_encode.c:580
#3 0x0000000000e62f9d in ff_vaapi_encode2 (avctx=0x1f1f780, pkt=<optimized out>, input_image=<optimized out>,
got_packet=0x7fffffffd52c) at libavcodec/vaapi_encode.c:860
#4 0x0000000000b02293 in avcodec_encode_video2 (avctx=avctx at entry=0x1f1f780, avpkt=avpkt at entry=0x7fffffffd670, frame=frame at entry=0x1f6c160,
got_packet_ptr=got_packet_ptr at entry=0x7fffffffd52c) at
libavcodec/utils.c:1962
#5 0x0000000000499c9d in do_video_out (s=0x1e2c300, ost=ost at entry=0x1f1e320, next_picture=next_picture at entry=0x1f6c160,
sync_ipts=<optimized out>, sync_ipts at entry=-7.62939453125e-06) at
ffmpeg.c:1176
#6 0x000000000049c5ff in reap_filters (flush=flush at entry=0) at
ffmpeg.c:1367
#7 0x000000000049e227 in transcode_step () at ffmpeg.c:4118
#8 transcode () at ffmpeg.c:4162
#9 0x00000000004808e7 in main (argc=<optimized out>,
argv=0x7fffffffdfb8) at ffmpeg.c:4355
>
>
> Regards,
>
> Boyuan
>
> ________________________________ From: Andy Furniss
> <adf.lists at gmail.com> Sent: July 19, 2016 2:39:44 PM To: Zhang,
> Boyuan; 'Christian König'; mesa-dev at lists.freedesktop.org Subject:
> Re: [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface
>
> Andy Furniss wrote:
>> Zhang, Boyuan wrote:
>>> Hi Andy,
>>>
>>> I just submitted another patch set, most of the issues you reported
>>> are solved, please see the information below:
>>>
>>> - Giving different frame rate should result different output size.
>>> The final result from my side is very close to the CBR I set. Please
>>> give a try with different frame rate and bit rate.
>>>
>>> - Picture corruption (half height pic) is caused by interlaced
>>> setting. Interlace encoding is not supported. However, for
>>> transcoding case, VAAPI decode will use interlace mode, which will
>>> cause this issue. The temp solution is to use an Environmental
>>> Variable to disable interlace when doing transcoding. Please try the
>>> following command with the new patch:
>>> DISABLE_INTERLACE=true gst-launch-1.0 filesrc
>>> location=~/big_buck_bunny_720p_1mb.mp4 ! qtdemux ! h264parse !
>>> vaapidecode ! vaapih264enc ! filesink location=out.264
>>>
>>> - I420 yuv -> nv12 case seems working fine on my side, can you
>>> please provide the testing raw file and command you were using?
>>> I want to reproduce the issue from my side and try to fix it if
>>> possible. Thanks a lot!
>>
>> Will try new patches tomorrow.
>
> DISABLE_INTERLACE=true does fix the decode -> encode issue.
>
> bitrate seems to be working OK now with different fps and various
> rates I tested. Gstreamer apparently can't count > 102M so that was as
> high as I could go.
>
> Stability on Tonga is good.
>
> Remaining issues -
>
> The default people will get just using ... ! vaapih264enc ! ... is not
> sane - it encodes with a qp=0 so is huge. vaapih264enc parameters
> init-qp and min-qp have no effect, though I am not sure they would be
> the right ones to specify cqp anyway.
>
> Speed - though omxh264dec has issues with bitrates, so a direct
> comparison is hard, it's always 3x faster than vaapi.
>
> Speed 2 - there seems to be an issue in the case where the bitrate
> requested is higher than can be achieved WRT the content to be
> encoded.
>
> It's up to twice as slow as it would be encoding something that had
> the detail to be constrained by the bitrate. This leads to the strange
> situation when say screen recording 1080p60 that when nothing much is
> happening the framerate can't be reached, but if there is a lot going
> on then it can. This is at very high rates = 100M, but then to record
> an fps type game the higher rate may be needed for the fast action.
>
More information about the mesa-dev
mailing list