Am 27.05.2016 um 15:16 schrieb Emil Velikov:
On 27 May 2016 at 11:28, Christian König <deathsim...@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
<deathsim...@vodafone.de> wrote:
From: Christian König <christian.koe...@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

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to