Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-22 Thread Andy Furniss 

Zhang, Boyuan wrote:

Hi Andy,

I just submitted another patch set.

1. Fixed previously reported regression when using ffmpeg to encode.
2. Fixed I420 "width=720,height=480" garbage output issue.

Please give a try from your side.


Hi,

The width 720 is OK now. Colors are still wrong. It seems from more
testing that it's not just I420, inputting YV12 is also wrong, which
makes me think that the conversions could be producing nv21 rather
than nv12.

I updated my gstreamer to current git just in case it changed something
but it didn't, though they decided to make vaapi264enc default to high, 
so now I have to add ! video/x-h264,profile=baseline ! everywhere.


ffmepeg/avconv no longer hit the division by zero.

There is something a bit strange about their rate control though, it's
like there is a max bitrate per frame limit - maybe they are sending
a min qp as well as bitrate or something, but I think it may be more
complicated that that.

Below this limit bitrate control works as expected with varying 
framerates eg. 2560x1440 24mbit fps 50 and 25 = OK, start going higher

and things start getting limited for the lower fps. The source is not
limiting, qp is high 20s at this rate/fps.

Of course this may just be an ffmpeg/avconv issue when the patches go
in I will ask the author of the vaapi code (who IIRC has a bonaire) so
will be able to test.

Another ffmpeg specific feature is that though the files made play OK,
the JM ref decoder doesn't like them as below. It was always like this
though I can't recall the frame numbering being in 4s IIRC it used to
be paired like gstreamer.

gstreamer doesn't have the POC issue, example output below.

ffmpeg/avconv -

 ./ldecod.exe -i /mnt/ramdisk/av-2425.264 -o /dev/null
Setting Default Parameters...
Parsing Configfile decoder.cfg
...

- JM 19.0 (FRExt) -
--
 Input H.264 bitstream  : /mnt/ramdisk/av-2425.264
 Output decoded YUV : /dev/null
 Input reference file   : test_rec.yuv
--
 Input reference file   : test_rec.yuv does not exist
  SNR values are not available
Profile IDC  : 66
Image Format : 2560x1440 (2560x1440)
Color Format : 4:2:0 (8:8:8)
--
POC must = frame# or field# for SNRs to be correct
--
  Frame  POC  Pic#   QPSnrY SnrU SnrV   Y:U:V Time(ms)
--
0(IDR)0 031 4:2:0 238
0( P )0 131 4:2:0  93
0( P )1 229 4:2:0  84
0( P )1 329 4:2:0  84
1( P )2 429 4:2:0  86
1( P )2 529 4:2:0  86
1( P )3 629 4:2:0  88
1( P )3 729 4:2:0  89
2( P )4 829 4:2:0 165
2( P )4 929 4:2:0  88
2( P )51028 4:2:0 189
2( P )51128 4:2:0 100
3( P )61228 4:2:0 189
3( P )61328 4:2:0 102
output POC must be in ascending order
output POC must be in ascending order
output POC must be in ascending order
output POC must be in ascending order
output POC must be in ascending order
output POC must be in ascending order
output POC must be in ascending order


Gstreamer -

./ldecod.exe -i /mnt/ramdisk/gs-2425.264 -o /dev/null
Setting Default Parameters...
Parsing Configfile decoder.cfg
...

- JM 19.0 (FRExt) -
--
 Input H.264 bitstream  : /mnt/ramdisk/gs-2425.264
 Output decoded YUV : /dev/null
 Input reference file   : test_rec.yuv
--
 Input reference file   : test_rec.yuv does not exist
  SNR values are not available
Profile IDC  : 66
Image Format : 2560x1440 (2560x1440)
Color Format : 4:2:0 (8:8:8)
--
POC must = frame# or field# for SNRs to be correct

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-21 Thread Zhang, Boyuan 
Hi Andy,

I just submitted another patch set.

1. Fixed previously reported regression when using ffmpeg to encode.
2. Fixed I420 "width=720,height=480" garbage output issue.

Please give a try from your side.

Regards,
Boyuan


Hi Christian,

As stated above, this new patch set just submitted fixed the 2 issue reported 
by Andy. Main change is adding a new patch (8/9) to fix the regression issue, 
detailed information is written in the patch. I believe all basic functionality 
is working fine now if Andy confirmed the 2 fixes. And as discussed, other 
changes/issues will be addressed with the performance improvement in future. 

Please let me know whether this patch set is good enough for pushing to 
upstream?

Regards,
Boyuan 


-Original Message-
From: Andy Furniss [mailto:adf.li...@gmail.com] 
Sent: July-21-16 8:57 AM
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

Zhang, Boyuan wrote:
> 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.

CQP is working OK now.

On the I420 I still see it whatever I try and have just managed to produce a 
totally trashed output.

Below produces "expected" output = colors are wrong for I420 but the vid is OK 
apart from that.

gst-launch-1.0 videotestsrc num-buffers=5 ! 
video/x-raw,format=I420,width=1280,height=720,framerate=1/1 ! 
vaapih264enc ! h264parse ! mp4mux ! filesink location=I420.mp4

gst-launch-1.0 videotestsrc num-buffers=5 ! 
video/x-raw,format=NV12,width=1280,height=720,framerate=1/1 ! 
vaapih264enc ! h264parse ! mp4mux ! filesink location=NV12.mp4

I then decided I would attach a png showing both outputs, to get it to fit I 
repeated above with width=720,height=480 and the result for
I420 was totally trashed, NV12 OK.

Replacing vaapih264enc with x264enc for the trashed case produces good output - 
so I don't think it's the input that is trashed at that res/pix_fmt.




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-21 Thread Andy Furniss 

Zhang, Boyuan wrote:

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.


CQP is working OK now.

On the I420 I still see it whatever I try and have just managed to
produce a totally trashed output.

Below produces "expected" output = colors are wrong for I420 but the
vid is OK apart from that.

gst-launch-1.0 videotestsrc num-buffers=5 ! 
video/x-raw,format=I420,width=1280,height=720,framerate=1/1 ! 
vaapih264enc ! h264parse ! mp4mux ! filesink location=I420.mp4


gst-launch-1.0 videotestsrc num-buffers=5 ! 
video/x-raw,format=NV12,width=1280,height=720,framerate=1/1 ! 
vaapih264enc ! h264parse ! mp4mux ! filesink location=NV12.mp4


I then decided I would attach a png showing both outputs, to get it
to fit I repeated above with width=720,height=480 and the result for
I420 was totally trashed, NV12 OK.

Replacing vaapih264enc with x264enc for the trashed case produces
good output - so I don't think it's the input that is trashed at that
res/pix_fmt.




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-20 Thread Andy Furniss 

Andy Furniss wrote:



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.


I can confirm this is a regression with the current patches, the last
set works with the same command.



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

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:
.
Find the GDB manual and other documentation resources online at:
.
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
   libavformat57. 43.100 / 57. 43.100
   libavdevice57.  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
   libpostproc54.  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.00, 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, 4 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=, context_id=,
buffers=, num_buffers=) at picture.c:496
496  vaStatus = handleVAEncMiscParameterBufferType(context,
buf);
(gdb) bt
#0  vlVaRenderPicture (ctx=, context_id=,
buffers=, num_buffers=) at picture.c:496
#1  0x00e628ed in vaapi_encode_issue
(avctx=avctx@entry=0x1f1f780, pic=pic@entry=0x1f30820) at
libavcodec/vaapi_encode.c:374
#2  0x00e62b86 in

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-20 Thread Zhang, Boyuan 
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.li...@gmail.com] 
Sent: July-20-16 5:31 AM
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

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 
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:
.
Find the GDB manual and other documentation resources online at:
.
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
   libavformat57. 43.100 / 57. 43.100
   libavdevice57.  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
   libpostproc54.  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

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-20 Thread Andy Furniss 

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 


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:
.
Find the GDB manual and other documentation resources online at:
.
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
  libavformat57. 43.100 / 57. 43.100
  libavdevice57.  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
  libpostproc54.  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.00, 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, 4 kb/s, 50 fps, 50 tbn, 50 tbc

Metadata:

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-19 Thread Zhang, Boyuan 
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.


Regards,

Boyuan


From: Andy Furniss 
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

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-19 Thread Andy Furniss 

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

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-18 Thread Andy Furniss 

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.

Here's a few frames of I420 in mkv at 1 fps, should play directly OK 
with mplayer/mpv - building is yellow.


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

Of course google will make a preview but you should be able to download 
the raw file by moving mouse towards the top of the screen.


Do

gst-launch-1.0 -f filesrc location=I420-5f.mkv ! matroskademux ! 
vaapih264enc ! h264parse ! mp4mux ! filesink location=out-I420-1.mp4


and the result is blue building, force gstreamer to convert to nv12 
result is OK.


gst-launch-1.0 -f filesrc location=~/I420-5f.mkv ! matroskademux ! 
videoconvert ! video/x-raw,format=NV12 ! vaapih264enc ! h264parse ! 
mp4mux ! filesink location=out-I420-2.mp4







___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-18 Thread Zhang, Boyuan 
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!


Hi Christian,

Besides fixing those issue listed above, I also modified the code based on your 
suggestions, e.g. adding mutex lock/unlock. Please take a look at the new patch 
set, and feel free to give any suggestions/comments. Thanks!

Regards,
Boyuan

-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: July-18-16 10:15 AM
To: Zhang, Boyuan; mesa-dev@lists.freedesktop.org
Cc: adf.li...@gmail.com
Subject: Re: [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

Am 16.07.2016 um 00:41 schrieb Boyuan Zhang:
> Add function to copy from yv12 image to nv12 surface for VAAPI putimage call. 
> We need this function in VaPutImage call where copying from yv12 image to 
> nv12 surface for encoding. Existing function can't be used because it only 
> work for copying from yv12 surface to nv12 image in Vaapi.

I think we can keep the patches mostly as they are now, but I would like to get 
a bit more positive feedback from Andy and maybe others.

E.g. at least we should be able to encode something without crashing on Tonga 
and other hardware generations as well before we push it upstream.

Regards,
Christian.

>
> Signed-off-by: Boyuan Zhang 
> >
> ---
>   src/gallium/auxiliary/util/u_video.h | 23 +++
>   1 file changed, 23 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_video.h
> b/src/gallium/auxiliary/util/u_video.h
> index 9196afc..d147295 100644
> --- a/src/gallium/auxiliary/util/u_video.h
> +++ b/src/gallium/auxiliary/util/u_video.h
> @@ -130,6 +130,29 @@ u_copy_yv12_to_nv12(void *const *destination_data,
>   }
>
>   static inline void
> +u_copy_yv12_img_to_nv12_surf(uint8_t *const *src,
> + uint8_t *dest,
> + int *offset,
> + int field) {
> +   if (field == 0) {
> +  for (int i = 0; i < offset[1] ; i++)
> + dest[i] = src[field][i];
> +   } else if (field == 1) {
> +  bool odd = false;
> +  for (int i = 0; i < (offset[1]/2) ; i++){
> + if (odd == false) {
> +dest[i] = src[field][i/2];
> +odd = true;
> + } else {
> +dest[i] = src[field+1][i/2];
> +odd = false;
> + }
> +  }
> +   }
> +}
> +
> +static inline void
>   u_copy_swap422_packed(void *const *destination_data,
>  uint32_t const *destination_pitches,
>  int src_plane, int src_field,


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-18 Thread Christian König 

Am 16.07.2016 um 00:41 schrieb Boyuan Zhang:

Add function to copy from yv12 image to nv12 surface for VAAPI putimage call. 
We need this function in VaPutImage call where copying from yv12 image to nv12 
surface for encoding. Existing function can't be used because it only work for 
copying from yv12 surface to nv12 image in Vaapi.


I think we can keep the patches mostly as they are now, but I would like 
to get a bit more positive feedback from Andy and maybe others.


E.g. at least we should be able to encode something without crashing on 
Tonga and other hardware generations as well before we push it upstream.


Regards,
Christian.



Signed-off-by: Boyuan Zhang 
---
  src/gallium/auxiliary/util/u_video.h | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_video.h 
b/src/gallium/auxiliary/util/u_video.h
index 9196afc..d147295 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -130,6 +130,29 @@ u_copy_yv12_to_nv12(void *const *destination_data,
  }
  
  static inline void

+u_copy_yv12_img_to_nv12_surf(uint8_t *const *src,
+ uint8_t *dest,
+ int *offset,
+ int field)
+{
+   if (field == 0) {
+  for (int i = 0; i < offset[1] ; i++)
+ dest[i] = src[field][i];
+   } else if (field == 1) {
+  bool odd = false;
+  for (int i = 0; i < (offset[1]/2) ; i++){
+ if (odd == false) {
+dest[i] = src[field][i/2];
+odd = true;
+ } else {
+dest[i] = src[field+1][i/2];
+odd = false;
+ }
+  }
+   }
+}
+
+static inline void
  u_copy_swap422_packed(void *const *destination_data,
 uint32_t const *destination_pitches,
 int src_plane, int src_field,


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-15 Thread Boyuan Zhang 
Add function to copy from yv12 image to nv12 surface for VAAPI putimage call. 
We need this function in VaPutImage call where copying from yv12 image to nv12 
surface for encoding. Existing function can't be used because it only work for 
copying from yv12 surface to nv12 image in Vaapi.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/auxiliary/util/u_video.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_video.h 
b/src/gallium/auxiliary/util/u_video.h
index 9196afc..d147295 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -130,6 +130,29 @@ u_copy_yv12_to_nv12(void *const *destination_data,
 }
 
 static inline void
+u_copy_yv12_img_to_nv12_surf(uint8_t *const *src,
+ uint8_t *dest,
+ int *offset,
+ int field)
+{
+   if (field == 0) {
+  for (int i = 0; i < offset[1] ; i++)
+ dest[i] = src[field][i];
+   } else if (field == 1) {
+  bool odd = false;
+  for (int i = 0; i < (offset[1]/2) ; i++){
+ if (odd == false) {
+dest[i] = src[field][i/2];
+odd = true;
+ } else {
+dest[i] = src[field+1][i/2];
+odd = false;
+ }
+  }
+   }
+}
+
+static inline void
 u_copy_swap422_packed(void *const *destination_data,
uint32_t const *destination_pitches,
int src_plane, int src_field,
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-14 Thread Boyuan Zhang 
Add function to copy from yv12 image to nv12 surface for VAAPI putimage call. 
We need this function in VaPutImage call where copying from yv12 image to nv12 
surface for encoding. Existing function can't be used because it only work for 
copying from yv12 surface to nv12 image in Vaapi.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/auxiliary/util/u_video.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_video.h 
b/src/gallium/auxiliary/util/u_video.h
index 9196afc..d147295 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -130,6 +130,29 @@ u_copy_yv12_to_nv12(void *const *destination_data,
 }
 
 static inline void
+u_copy_yv12_img_to_nv12_surf(uint8_t *const *src,
+ uint8_t *dest,
+ int *offset,
+ int field)
+{
+   if (field == 0) {
+  for (int i = 0; i < offset[1] ; i++)
+ dest[i] = src[field][i];
+   } else if (field == 1) {
+  bool odd = false;
+  for (int i = 0; i < (offset[1]/2) ; i++){
+ if (odd == false) {
+dest[i] = src[field][i/2];
+odd = true;
+ } else {
+dest[i] = src[field+1][i/2];
+odd = false;
+ }
+  }
+   }
+}
+
+static inline void
 u_copy_swap422_packed(void *const *destination_data,
uint32_t const *destination_pitches,
int src_plane, int src_field,
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev