I would not be to hard on the guy.
All the different mix of video APIs is a bad thing.
There is, indeed, many places that Linux video falls behind when compared to Windows.
And, yes, Flash is doing lots of things that other applications are not. This is because it's a very complex way of doing things... mostly a bad idea way of doing things, but very complex non-the-less.
But I'd take html5-based video over flash-based video anyday.
Yea.... lots of things can overlay over video (subtitles?) using x-video, not sure I understand why flash can't.
Not only that. If Michael would have looked up who Mike is, he would have known that Mike is one of the main developers behind FFmpeg, the video encoding/decoding library that drives all the FOSS video player (and many things more). Not to mention that Mike reverse engineered VP3 which eventually led to development of Theora.
Originally Posted by StringCheesian
So Mike knows exactly what he is talking about, he knows what a video player is, he knows what the problems with in designing fast video applications are and where Linux lacks behind Windows and where it's far beyond.
To take the claims apart that this article/editorial says are so outragous:
Converting YUV to RGB is a huge task. It can easily use up as much performance as the decoding process itself. If you dont believe it, just try something like
and compare the playback speed (yes, MPlayers format conversion routines are highly optimized, so they are about as fast as you can get).
mplayer -benchmark -vf format=rgb24
I dont see where Mike claims that any of the APIs on Linux aren't fully implemented yet. Neither where he claims that Adobe has any weight within the industry to force chip manufacturers to implement drivers. I think the author has not read the article and just assumes things after skimming over it.
But to put it here straight: The available hardware video decoding APIs on linux ALL SUCK! Why? Because they were designed by people who write graphics card drivers and express what they think is important. Nobody ever asked the guys who develop video players what they actually need or what would help them. It was just assumed that this or that is enough for them to write fast players. And this way of development started as early as Xvideo (compare it to the interface mga_vid or vidix provide, which are both older, and see for yourself how complicated XV is to use). All those that came afterwards XvMC, VA API, VDPAU, XvBA are the same. Designed for nice looking driver code, not for fast playing systems.
The claim that Crystal HD is read for production use goes in the same category. It might be ready for someone who knows how to hack around a system, who is used to upgrade his applications when he upgrades a driver or to wait a few weeks until his favorite application is updated. But for a company that delivers a binary, heck even for a distribution, Crystal HD is not ready yet! Just because there are some patches around does not mean that Joe Average can use it already.
In the end this article is just a huge rant with half informed guesses by someone who has a very RMS-like world view and doesn't see much into the problems of video player development. Comming from this restricted world view and judging other people who work in a totaly different field is more than just questionable.
I read the second blog post as primarily a response to the questions which basically said "other players have done it, why can't Flash". I don't think there was any intention of saying that the need to blend in RGB was stopping Adobe from providing a solution, just that it was more difficult than tossing encoded video into an API's VLD entry point, which *is* an option for most players.
AFAICS Mike is saying that they need APIs which will allow player code to sit between the decode and render operations. As Gwenole pointed out, both the ATI and NVidia implementations have a mechanism to do this (not sure about VA-API), however there are "more differences" between the vendor's implementations of *that* style of playback than between the VLD entry points.
I didn't think blending in YCbCr was really practical, unless the blending algorithm essentially converted to RGB on the fly, blended, then converted back.
Part of the problem, I guess, is that Flash is an extremely powerful and versatile tool, but one of its most common applications is playing back video in a rectangle on a white background. That scenario uses about 5% of Flash's capabilities, but I suspect the issue is that the developers need to make sure the other 95% work as well -- and *that's* where things become difficult.
isn't that just a simple per-pixel matrix multiplication, i.e. a trivial task for any shader-based GPU? If the YUV image is already in video memory, why can't it be converted there before moving it to GPU space for manual blending?
Originally Posted by KotH
It's cheap on a GPU if the YCbCr image is in video memory and you want the result in video memory as well, fairly expensive on a CPU, and moderately expensive on a GPU if you want the result back in system memory so the CPU can chew on it some more.
I don't know what the specific requirements are for Flash, ie whether the decoded image needs to be further processed on the CPU or just via GPU operations using GL. I suspect the requirement is for CPU processing, since AFAIK post-decode processing using GL is already being done by Adobe and other players.
You must be new here...
Originally Posted by jdeslip
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.
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.
Can somebody enlighten me why things that were simple in late eighties are complicated and _slow_ again on more then 100x times faster CPUs?
my comment on the Adobe penguin blog still awaits moderation for the last 12 hours or so.
i've just asked why Adobe did not ask about/for those needed API changes in the nVidia Linux drivers while their teams worked on the Windows Flash 10.1 and 19x.xx integration.
i find it hard to believe that while working at that no one said "hey guys maybe we/you can do that on Linux & Mac too since our/your driver core shares 90% or whatever of the code"
or communists ;)
Originally Posted by DanL