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

[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 <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160720/308abd59/attachment.html>