3 ms·

As if there's no secure way to allow it access? Of course there is, and it should have that access if it means the difference between being able to stream video

As if there's no secure way to allow it access? Of course there is, and it should have that access if it means the difference between being able to stream video from the web well or not. A safe, high level API exists: QTKit. Adobe wants direct access, so they've ignored this totally. Whether it makes sense to give hardware control to a piece of software notorious for instability and resource consumption is a judgment call, but it seems a pretty clear one.

modeless 17y ago
This argument is ridiculous. Flash is native code and does not run in a sandbox. It already interacts with graphics hardware through numerous other APIs and has the ability to kill your system in innumerable other ways. An API for hardware acceleration of video decoding should be the least of your worries. Furthermore, this argument would apply just as well to WebGL, which gives graphics hardware access directly to Javascript on any website you visit. WebGL is awesome and I believe it can be done safely. I don't know much about QTKit but I think it's entirely plausible that it isn't flexible enough for use in Flash. Flash needs complete control over drawing because videos are integrated with other Flash content (likely rendered at least partially in software), and can be manipulated by ActionScript to produce effects such as 360 degree video: http://www.immersivemedia.com/work/cbc/hockey/index.html http://www.immersivemedia.com/work/cbc/hockey/index.html
- mattdw 17y ago
  > This argument is ridiculous. Flash is native code and does not run in a sandbox. It already interacts with graphics hardware through numerous other APIs and has the ability to kill your system in innumerable other ways. Actually, in Safari 4 (Intel, 64bit) each plugin runs in its own process, and it _is_ effectively sandboxed. If Flash crashes, it no longer takes down the browser, or even the tab a la Chrome; you just get a hole in the page.
  - modeless 17y ago
    That's not what sandboxing means. Flash is in a separate process but not sandboxed. It has full access to the local system.
    - ekiru 17y ago
      Adobe's platform evangelist claims( http://theflashblog.com/?p=1641#comment-639881 http://theflashblog.com/?p=1641#comment-639881 ) that the reason they can't use h.264 hardware acceleration on OS X is due to restrictions on browser plugins, which implies that it does not have full access to the local system.
      - wanderr 17y ago
        I believe it has to do specifically with how drawing to the screen happens; if that has to go through the browser, then it can't utilize hardware acceleration. One interesting test we did recently was to make a very simple flash app that draws some basic controls on the screen and scales to the window size. It also prints out the amount of memory being used by the AVM. In IE, memory usage was extremely low and was about the same regardless of the screen size. In Firefox, memory usage was higher and also almost entirely dependent on window size. To me this implies that IE is allowing Flash to interface with the video card directly, while in Firefox it's having to maintain its own frame buffer internally.

modeless 17y ago

This argument is ridiculous. Flash is native code and does not run in a sandbox. It already interacts with graphics hardware through numerous other APIs and has the ability to kill your system in innumerable other ways. An API for hardware acceleration of video decoding should be the least of your worries. Furthermore, this argument would apply just as well to WebGL, which gives graphics hardware access directly to Javascript on any website you visit. WebGL is awesome and I believe it can be done safely. I don't know much about QTKit but I think it's entirely plausible that it isn't flexible enough for use in Flash. Flash needs complete control over drawing because videos are integrated with other Flash content (likely rendered at least partially in software), and can be manipulated by ActionScript to produce effects such as 360 degree video: http://www.immersivemedia.com/work/cbc/hockey/index.html http://www.immersivemedia.com/work/cbc/hockey/index.html

mattdw 17y ago
> This argument is ridiculous. Flash is native code and does not run in a sandbox. It already interacts with graphics hardware through numerous other APIs and has the ability to kill your system in innumerable other ways. Actually, in Safari 4 (Intel, 64bit) each plugin runs in its own process, and it _is_ effectively sandboxed. If Flash crashes, it no longer takes down the browser, or even the tab a la Chrome; you just get a hole in the page.
- modeless 17y ago
  That's not what sandboxing means. Flash is in a separate process but not sandboxed. It has full access to the local system.
  - ekiru 17y ago
    Adobe's platform evangelist claims( http://theflashblog.com/?p=1641#comment-639881 http://theflashblog.com/?p=1641#comment-639881 ) that the reason they can't use h.264 hardware acceleration on OS X is due to restrictions on browser plugins, which implies that it does not have full access to the local system.
    - wanderr 17y ago
      I believe it has to do specifically with how drawing to the screen happens; if that has to go through the browser, then it can't utilize hardware acceleration. One interesting test we did recently was to make a very simple flash app that draws some basic controls on the screen and scales to the window size. It also prints out the amount of memory being used by the AVM. In IE, memory usage was extremely low and was about the same regardless of the screen size. In Firefox, memory usage was higher and also almost entirely dependent on window size. To me this implies that IE is allowing Flash to interface with the video card directly, while in Firefox it's having to maintain its own frame buffer internally.