Solving Different Problems
blogs.adobe.com
Solving Different Problems
1–10 of 50 posts
Re: Solving Different Problems
#2> it has to convert YUV data to the RGB colorspace and combine the image with other Flash elements.
The screen has red, green and blue pixels, either way a video is played, the colours have to be converted into RGB.
Re: Solving Different Problems
#3translation: we don't want to do colorspace conversion on the GPU because it's hard. let's go shopping instead!
Re: Solving Different Problems
#4the internet at large has unanimously declared that it appreciates the Flash Player’s solution to the video problem
Really? The Internet at large is able to unanimously declare things, and one of those things is that it appreciates Flash's solution to the video problem? Tell me more...
Re: Solving Different Problems
#5> it has to convert YUV data to the RGB colorspace and combine the image with other Flash elements. The screen has red, green and blue pixels, either way a video is played, the colours have to be converted into RGB.
not every video frame is encoded in RGB. actually, very few transports use that.
the in-memory layout of a YUV-encoded frame is different than the one of a RGB one. it needs conversion, which implies an intermediate copy, as well as traversing a buffer that can go up to 1080 rows.
most video players (and Flash on Windows and MacOS), these days, use shaders and multi-texturing to do that conversion on the GPU; it removes a copy, because you just push the YUV frame as it is to the GPU - and your CPU can go back to a low C state.
I think Flash on Linux does this as well, on nVidia: the blog post linked is from 2010. the way Adobe detect capabilities is, in itself, hilariously bad - instead of checking the GL required GL extensions like any normal people, they do a check on the GL vendor string. the Mesa guys pointed that out, but I doubt they ever received a response.
Re: Solving Different Problems
#6While watching streams of Olympia in both HTML5 (on Chrome) and Flash i found HTML5 to take nearly twice as much CPU then Flash.
Might be due to the implementation of the sites (german broadcasters ard & zdf) but flash works pretty awesome for me.
Re: Solving Different Problems
#7> it has to convert YUV data to the RGB colorspace and combine the image with other Flash elements. The screen has red, green and blue pixels, either way a video is played, the colours have to be converted into RGB.
not every video frame is encoded in RGB. actually, very few transports use that. the in-memory layout of a YUV-encoded frame is different than the one of a RGB one. it needs conversion, which implies an intermediate copy, as well as traversing a buffer that can go up to 1080 rows. most video players (and Flash on Windows and MacOS), these days, use shaders and multi-texturing to do that conversion on the GPU; it remo…
My system isn't shader capable and still playing HTML5 video tag consumes only ~30% of CPU while playing flash ~90%.
There is no excuse for that - I could understand higher CPU usage, but not by factor of 3.
Re: Solving Different Problems
#8Wow. A tip to anyone reading this: if you ever find yourself explaining away poor—nay, pathological—performance with anything other than ‘we made some mistakes in the past and we’re doing what we can to correct them’, please take a good hard look at yourself and consider exiting the software industry. That’s all I have to say.
Edit: that wasn’t all I had to say.
> What about Mac? I’m not sure but my Mac colleagues have mentioned something about Apple not making their hardware decoding APIs available to applications
Well why didn’t you just go ahead and ask them before writing a blog post on company letterhead?! Is the corporate structure here so screwed up that you can’t actually do that, or are you just lazy?
Re: Solving Different Problems
#9translation: we don't want to do colorspace conversion on the GPU because it's hard. let's go shopping instead!
I only skimmed the article, but that strikes me as a "mistranslation".
Adobe is emphasizing that they have to do more compositing logic, so they they need an RGB version of the video frame on the CPU side.
If they did the colorspace conversation on the GPU, they'd have to pull the converted image back and incur the latency hit. Apparently, they see less latency in doing the conversation on the CPU, and have made the call to trade processor efficiency for latency.
To be clear: YUV colorspace conversion on a GPU is really damn simple. I have a ~30 line shader that does it from my video processing codebase. But I can take the hit - I do a substantial amount of image manipulation using shaders on the GPU, and mask the read latency with heavy multi-threading. A Flash application doesn't have this luxury.
But this discussion is largely academic - if you're writing a Flash based video player that doesn't need the flexibility of Flash's full compliment of image manipulation and composting functionality, you'd be using their StageVideo API - an API that does do all the video work on the GPU. This API was introduced in Flash 10.2, which came out after this article from 2010.
Re: Solving Different Problems
#10> Flash Player solves a different problem: It plays linear media files from start to finish while combining the video with a wide array of graphical and interactive elements (buttons, bitmaps, vector graphics, filters)
And therein lies the problem with Flash video: dozens of video player implementations, each frustratingly different and user unfriendly than the next. People are building custom chrome on top of HTML5 video too, unfortunately, but at least it's standardized (and semantic) which allows users to consume web video with any interface they want.