Adobe's Linux Video API Rant Extended

[deanjo]

That site has very confusing feedback layout.

Hehe whoops, yup your right.

[md1032]

I got a kick out of Stephan's post,

[something posted by Spencer]

and Jon's post

[something written by Stephen]

as they show the industry is listening and are willing to help which contradicts his statement,

That site has very confusing feedback layout.

[Hoodlum]

It seems the only "deaf ears" are his own.

I find it sad. I used to view adobe as an innovator, a company that produced a product far superior to all others (Photoshop); I was also a big fan of inDesign. It is a shame that they have become so incompetent they cannot even provide stable video playback through a browser plugin, oh how the mighty have fallen.

[deanjo]

I got a kick out of Stephan's post,

I agree with jbus: perhaps you should move on. You're clearly not a Linux developer.
And if this is the tone Adobe uses to deal with its userbase, I welcome HTML5 as a replacement.

and Jon's post

In summary: If you have any issues understanding or using VDPAU, please feel free to contact NVIDIA. We'd be very happy to help you.

as they show the industry is listening and are willing to help which contradicts his statement,

I've wanted to write this post for awhile but always hesitated since previous attempts at technical exposition largely fell on deaf ears.

It seems the only "deaf ears" are his own.

[Hoodlum]

Decided to pay absolutely zero attention to that guy after his "Welcome to the jungle" post where he showed himself to be completely ignorant / disingenuous (see: http://blogs.adobe.com/penguin.swf/linuxaudio.png).

Clearly Arts (irrelevant years ago), Jack (Totally different use than standard audio output) and OSS (irrelevant years ago) are such a huge problem for the audio stack on Linux.

I realise his post was intended to highlight the "travesty" of the audio stack on Linux but please, he could at least be honest about what is even applicable. Really only PulseAudio / GStreamer / SDL / libao to ALSA and then the output device are the only things that are even relevant.

What next? Making a list of every distro ever to exist and claiming choosing an enterprise distro is near impossible?

[deanjo]

Nice to see Aaron get into the cause there.

And Stephan, and Gwenole and Jay. Might see some action on this after all.

[deanjo]

http://blogs.adobe.com/penguin.swf/2...omment-2133409

Nice to see Aaron get into the cause there.

[Dragoran]

http://blogs.adobe.com/penguin.swf/2010/01/solving_different_problems.html#comment-2133409

[deanjo]

That was the time before HD, when 640x480 (DVDs) where the highest resolution you'd have to deal with

DVD Resolutions are 720/704?480 for NTSC and 720/704?576 for PAL.

[KotH]

Colorspace Conversion: Isn't it simple to have 50MB of RAM reserved for YUV -> RGB conversion lookup table, for users that have no HW acceleration, but have plenty (well, 50MB) of RAM? This table can be shared in RAM for all running video encoding/decoding instances. In such table you can simply define RGB for each YUV combination and have image converted in no time.

No, you want to do this conversion using math. Using a lookup table will kill your cache. Ie all memory access would then have to hit your SDRAM, which is very very very very slow.

Scaling: How is scaling a problem? Did Second Reality demo scaled a bold guy's face in full screen on 486 back in Ronald Reagan era? Yes, it also used look-up table, you don't have to calculate everything all the time. For video scaled to 1920x1080 screen (size of source image is not important), you need only 8MB lookup table. Again, conversion is done in no time.

Scaling increases the demand of bandwith. Although we've a lot more BW with PCI-E these days, it's still a pontential bottle neck. 1920x1080 is 6MB of data per frame (in 4:4:4 RGB). That's 177MByte/s with a 30fps movie, only of raw data, not counting the control data.

Can somebody enlighten me why things that were simple in late eighties are complicated and _slow_ again on more then 100x times faster CPUs?

Things weren't simple in the 80's but people were more easily impressed, even if it was obvious that you cheated.

But actually, there was a time when video coding was "easy"... That was the time before HD, when 640x480 (DVDs) where the highest resolution you'd have to deal with and CPU clock frequency still increased every month. Then you could use more and more complex encoding strategies and didn't have to worry about BW use or CPU, as the next generation computers were for sure able to play it all!