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@entry=0x1f1f780, pic=pic@entry=0x1f30820) at
libavcodec/vaapi_encode.c:374
#2 0x0000000000e62b86 in vaapi_encode_step
(avctx=avctx@entry=0x1f1f780, target=target@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@entry=0x1f1f780, avpkt=avpkt@entry=0x7fffffffd670,
frame=frame@entry=0x1f6c160,
got_packet_ptr=got_packet_ptr@entry=0x7fffffffd52c) at
libavcodec/utils.c:1962
#5 0x0000000000499c9d in do_video_out (s=0x1e2c300,
ost=ost@entry=0x1f1e320, next_picture=next_picture@entry=0x1f6c160,
sync_ipts=<optimized out>, sync_ipts@entry=-7.62939453125e-06) at
ffmpeg.c:1176
#6 0x000000000049c5ff in reap_filters (flush=flush@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.li...@gmail.com> Sent: July 19, 2016 2:39:44 PM To: Zhang,
Boyuan; 'Christian König'; mesa-dev@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
