[Mesa-dev] [PATCH] radeon/uvd: fix the H264 level for Tonga

[Andy Furniss]

Christian König wrote:
> Am 26.05.2016 um 11:27 schrieb Andy Furniss:
>> Alex Deucher wrote:
>>> On Wed, May 25, 2016 at 10:57 AM, Christian König
>>> <deathsimple at vodafone.de> wrote:
>>>> From: Christian König <christian.koenig at amd.com>
>>>>
>>>> We support 5.1 for a while now.
>>
>> Resend as the last one didn't have the CCs.
>>
>> I know (well think) vdpau doesn't really mention 5.2 anywhere, but
>> for ffmpeg I've been making this change for some time to say 5.2.
>>
>> Tonga can easily do 5.2, players don't seem to look at this field,
>> but ffmpeg cli now does and will refuse to use uvd for 5.2 vids.
>>
>
> 5.2 requires the hardware to handle more than twice as much
> macroblocks per second than 5.1. So the decoder needs to handle 4k at
> 66fps.
>
> I'm not sure about the absolute numbers, but I think that could be to
>  much even for a Tonga.

300 mbit 2160p60 works fine for me and I don't think an extra 6 fps will
make any difference - the reason being I can go a lot above 5.2
(4080x4096 60 fps) and it still decodes OK, with the caveat that it
seems to expose a powerplay/clocks issue as noted in my powerplay bug.
(issue = OK with clocks forced high, but distort/lock on auto, no lock
with pp=0 but distorted.

I don't need to force clocks for 4kp60 - which is all that really exists
"for real".

Review sites that tested tonga on windows list 4kp60 as a feature as
does wikipedia - and testing on windows it does work OK with dxva2.


>> In the past ffmpeg cli also didn't look at this, but they merged
>> something in from libav which changed things.
>>
>> I have a trac open, but the dev who replied said fix the driver -
>> he didn't reply further when I said I didn't think vdpau went as
>> high as 5.2 ...
>
> VDPAU actually doesn't have an enumeration for the level, so you can
>  even return something like 9.9 without a problem.

Yea, it's a bit strange that they didn't do all the levels.

So the patch as is limits anything that actually obeys that info to
4kp30 rather that 4kp60 which is working.

Given players with more pragmatic devs than ffmpeg ignore it anyway it
doesn't really matter that much. Another example being Constrained
baseline being listed as not supported - also ignored due to being wrong.