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

[Emil Velikov]

On 27 May 2016 at 11:28, Christian König <deathsimple at vodafone.de> 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.
>
>> 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.
>
One of us is getting confused here..

Are you saying that VDPAU users have no way of quering the said
numbers ? The way I see it it's the complete opposite.
It is the only API on which the user that _can_ query such info. In
mesa/gallium we have PIPE_VIDEO_CAP_MAX_LEVEL explicitly for VDPAU ;-)

The odd things is that VLC uses/used to? check that information before
feeding the video to the decoder, while others implementations (like
the original one in mplayer done by the Nvidia devs) do/did? not
bother.

Just clarifying some facts, there's nothing wrong with the patch obviously.

-Emil