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

[Christian König]

Am 27.05.2016 um 15:16 schrieb 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 ?

No, what I'm saying is that it is a number and not an enum.

This way you don't need to change the specification when you want to 
support a new level.

Christian.

>   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