Log in

View Full Version : Speed of Current Flash H.264 Decoder?


iwod
17th September 2009, 04:22
I am getting sick and tired of Flash 10 insanely slow H.264 decoder.

Since Mainconcept has been acquired by Divx.

What are the percentage of improvement we can expect if Flash has been updated to use the new Divx decoder.

Dark Shikari
17th September 2009, 05:26
The reason Flash's decoder is mildly slow is because it has to convert YV12->RGB in software for the compositing engine to work with.

benwaggoner
21st September 2009, 19:42
I expect that Flash's playback problems have more to due with the end-to-end pipeline than the decoder per se.

littleD
21st September 2009, 20:10
What about real hardware acceleration? DXVA maybe. Is it possible for steaming videos?

nm
21st September 2009, 22:03
Yes, Adobe is teaming up with NVIDIA on that though:
http://www.adobe.com/aboutadobe/pressroom/pressreleases/200906/060209AdobeandNvidia.html

DXVA is probably out of the question for browser-embedded content, but perhaps some expert can clarify.

Shinigami-Sama
21st September 2009, 23:43
Yes, Adobe is teaming up with NVIDIA on that though:
http://www.adobe.com/aboutadobe/pressroom/pressreleases/200906/060209AdobeandNvidia.html

DXVA is probably out of the question for browser-embedded content, but perhaps some expert can clarify.

it is possible, it seems that its mostly political at this point

jakor
22nd September 2009, 00:13
for DXVA1 if you can access video renderer (build your own directshow graph at least)- you get access to hardware acceleration.
With DXVA2 it is even simplier. D3D9 object will do it.

nm
22nd September 2009, 01:06
for DXVA1 if you can access video renderer (build your own directshow graph at least)- you get access to hardware acceleration.
With DXVA2 it is even simplier. D3D9 object will do it.
I still wonder how DXVA1 would fit to the rendering model of Flash or Silverlight. DXVA2 support appears to be more feasible, and maybe the userbase is getting there after Windows 7 is released. Currently XP seems to have a 60-70% market share.

benwaggoner
22nd September 2009, 01:58
it is possible, it seems that its mostly political at this point
It's actually pretty hard.

Also, it only helps relatively recent GPUs. So it's nice for netbooks (slow CPU, but DXVA2 capable GPU), but not that great for just generically older machines.

Shinigami-Sama
22nd September 2009, 04:34
It's actually pretty hard.

Also, it only helps relatively recent GPUs. So it's nice for netbooks (slow CPU, but DXVA2 capable GPU), but not that great for just generically older machines.

I fail to see how it would be terribly hard
video -> decode(hardware) -> render(hardware) -> RBG conversion -> back to browser -> do as normal

benwaggoner
22nd September 2009, 04:54
I fail to see how it would be terribly hard
video -> decode(hardware) -> render(hardware) -> RBG conversion -> back to browser -> do as normal
Except that there's all kinds of transforms and overlays that can be applied to the video.

Plus living as a brower plugin means all kinds of high priority thread tricks are harder, and there's a big chance the user might be running a few different Flash instances each across a dozen or more open pages/tabs.

Shinigami-Sama
22nd September 2009, 06:42
Except that there's all kinds of transforms and overlays that can be applied to the video.

Plus living as a brower plugin means all kinds of high priority thread tricks are harder, and there's a big chance the user might be running a few different Flash instances each across a dozen or more open pages/tabs.

then the obvious solution is to not start playback of the ones in the background or otherwise non-active instances

as for renderers I don't really see how this is a problem...

jakor
22nd September 2009, 08:42
I expect that Flash's playback problems have more to due with the end-to-end pipeline than the decoder per se.
this is 100% true. There is no such a thing as a flash decoder.
There is a flash player. Which is doing all the playback and whatever.

benwaggoner
22nd September 2009, 21:25
then the obvious solution is to not start playback of the ones in the background or otherwise non-active instances
Indeed. But users don't heed that advice :).

as for renderers I don't really see how this is a problem...
Because the rendering always needs to be able to support anti-aliased alpha-blended processing. Which means lots of existing hardware needs to fall back to a software rendering model because the GPU hardware isn't capable enough.

Flash's GPU compositing is pretty buggy so lots of sites avoid it. In Silverlight (where pretty much all Silverlight 3 sites are using it by default), we've found it allows about a 3x improvement in pixels/second we can display on Netbooks.

Shinigami-Sama
23rd September 2009, 04:26
Indeed. But users don't heed that advice :).

I mean disable them when the tab/window isn't active


Because the rendering always needs to be able to support anti-aliased alpha-blended processing. Which means lots of existing hardware needs to fall back to a software rendering model because the GPU hardware isn't capable enough.

Flash's GPU compositing is pretty buggy so lots of sites avoid it. In Silverlight (where pretty much all Silverlight 3 sites are using it by default), we've found it allows about a 3x improvement in pixels/second we can display on Netbooks.
then just pass off color space conversion to the GPU and let the CPU do the rest?
shouldn't this be fairly straight forward for a large software house

benwaggoner
24th September 2009, 05:17
I mean disable them when the tab/window isn't active
...and if the app has a clock timer in it?

Flash is fundamentally a frame-based animation model, which is Considered Harmful in my book.

Developers of Flash apps should do a much better job of including specific "idle" modes that don't burn CPU, but that's no done much in practice.

In Silverlight, we're time-based, not frame-based, so our animations and stuff still can work with a very small slice of CPU, just at a lower fps.


then just pass off color space conversion to the GPU and let the CPU do the rest?
shouldn't this be fairly straight forward for a large software house
You may be quite astounded to see a list of all the different Y'CbCr flavors supported in one card or another. Unfortunately, native YV12 input is far from universal. The only thing that gives reliably the same visual appearance on all cards is handing the GPU RGBA frames. Getting Y'=16 reliably R'G'B'=0 isn't a given with deployed GPUs.

Pixel-shader based YV12>RGBA is interesting, but leaves out a whole lot of existing hardware. Once we've go Silverlight 13 and Win7 is our minimum version, no prob, but we still need to run on 2K and XP.