<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="Generator" content="Microsoft Exchange Server"> <style></style> </head> <body> <meta content="text/html; charset=UTF-8"> <style type="text/css" style="">  </style> <div dir="ltr"> <div id="x_divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif"> 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 </div> <hr tabindex="-1" style="display:inline-block; width:98%"> <div id="x_divRplyFwdMsg" dir="ltr">From: Andy Furniss <adf.lists@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 <div> </div> </div> </div> <div class="PlainText">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. </div> </body> </html>