gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Flash HD (H.264) video decoding acceleration


From: Gwenole Beauchesne
Subject: Re: [Gnash-dev] Flash HD (H.264) video decoding acceleration
Date: Wed, 23 Sep 2009 15:10:12 +0200 (CEST)
User-agent: Alpine 1.10 (DEB 962 2008-03-14)

Hi,

On Wed, 23 Sep 2009, Bastiaan Jacques wrote:

I would be interested in merging the VA API integration if we have some indication that the free GPU driver community (i.e., Nouveau or AMD-free) will soon be supported by VA API.

I don't believe this will happen, especially under the "soon" constraint. The only option left to the community for those chips is to use the saders and I doubt this will be as effective as the dedicated ASIC. That is, there are no specs for AMD's UVD neither for NVIDIA's PureVideo circuits.

Intel is still working on the H.264 codec for G45. This one is completely Open Source. The driver that is currently available is only limited to MPEG-2 VLD at this time, and this is not very useful here.

Thank you for your early comments. I will address them and submit the individual hunks instead. The original patch was only generated with a git diff origin master for a rough overview.

+GnashTexture::GnashTexture(unsigned int width, unsigned int height,
ImageType type)
+    : _width(width), _height(height), _texture(0), _format(type),
_flags(0)
+{
+    D(bug("GnashTexture::GnashTexture()\n"));
+
+    init();
+}

And what of init()'s return value?

The longer term was to throw exceptions but I have not yet reviewed the current practises. e.g. who will/should catch the exception and how to handle it.

+    struct TextureState {
+       unsigned int    old_texture;
+       unsigned int    was_enabled : 1;
+       unsigned int    was_bound   : 1;
+    }                  _texture_state;

Do performance numbers indicate that bitfields should be preferred over
clarity (i.e., using bool) here?

To be honest, this should not make any difference. Actually, this was a raw copy of some other code I wrote.

For sending future patches, it would be nice to have the VA API patch seperate from other bugfixes.

Yes, of course. Most of the VA API additions now even live in their specific directory.

Regards,
Gwenole.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]