"The Flash Player solves a different problem than your favorite video player."
That problem is largely tracking user behavior across the internet.
Solving Different Problems
31–40 of 50 posts
Re: Solving Different Problems
#32This is an extremely outdated article which was posted before they added "StageVideo", an API that fixes this problem 100%. http://www.adobe.com/devnet/flashplayer/stagevideo.html
So is this evidence that the blog author was full of it when he wrote this?
Re: Solving Different Problems
#33If only there were a way to let a plugin give VLC a URL to open and overlay over a specific part of your screen until you close the tab. Nah, that's crazy talk. Who would want to watch a high-quality hardware-accelerated local video that gets deleted when you close the tab, from the familiar interface of a web browser? Crazy talk, crazy talk.
There is. http://www.videolan.org/doc/play-howto/en/ch04.html#id591206
Then again, I don't use it because I couldn't get any seek UI to appear.
Re: Solving Different Problems
#34This is an extremely outdated article which was posted before they added "StageVideo", an API that fixes this problem 100%. http://www.adobe.com/devnet/flashplayer/stagevideo.html
So is this evidence that the blog author was full of it when he wrote this?
Not really, StageVideo has a bunch of limitations in the compositing pipeline, but that doesn't really matter if all you want to do is build a 2D movie player.
Anyways, I guess Adobe changed their mind later, and decided they wanted to solve both of the "different problems" mentioned in the blog post.
(Remember, Flash used to be all about vector animations. Sometimes it'd seem like the ubiquitous flash-as-a-video-player thing happened almost by accident; it turns out the video support (a relatively small feature in the whole flash featureset) was good enough to bring "universal" video to the web.)
Re: Solving Different Problems
#35Earlier quoted context omitted.
Doubly so if your product crashes even half as often as Flash. That they cannot seem to code for stability doesn't give me any confidence in their ability to code for speed. I heard that they refused to work with Apple to improve its performance on Mac, and that was a core reason why they got excluded from the iOS platform -- searching for this I came up with an explanation directly from Apple: "Symantec recently hig…
You must have heard wrong, and it's the other way around. Apple did not open their video acceleration APIs until they released OS X 10.6.3 circla mid-2010. http://xbmc.org/davilla/2010/05/03/osx-gets-h-264-accellerat...
If that's the major reason preventing them from being performant, then I misunderstood the reason for crashing and the reason for poor performance to be the same. Apple should not be complaining about CPU usage.
That doesn't excuse Adobe from making buggy plugins.
Re: Solving Different Problems
#36Earlier quoted context omitted.
You must have heard wrong, and it's the other way around. Apple did not open their video acceleration APIs until they released OS X 10.6.3 circla mid-2010. http://xbmc.org/davilla/2010/05/03/osx-gets-h-264-accellerat...
If that's the major reason preventing them from being performant, then I misunderstood the reason for crashing and the reason for poor performance to be the same. Apple should not be complaining about CPU usage. That doesn't excuse Adobe from making buggy plugins.
Indeed the flash plugin has been riddled with crashers and security vulnerabilities. But the blame for high CPU usage during video decoding seems to have been mostly in Apple's court before that.
Re: Solving Different Problems
#37Re: Solving Different Problems
#38Earlier quoted context omitted.
Doubly so if your product crashes even half as often as Flash. That they cannot seem to code for stability doesn't give me any confidence in their ability to code for speed. I heard that they refused to work with Apple to improve its performance on Mac, and that was a core reason why they got excluded from the iOS platform -- searching for this I came up with an explanation directly from Apple: "Symantec recently hig…
You must have heard wrong, and it's the other way around. Apple did not open their video acceleration APIs until they released OS X 10.6.3 circla mid-2010. http://xbmc.org/davilla/2010/05/03/osx-gets-h-264-accellerat...
Even without that API 10.6.2 and before video players still used a lot less CPU when decoding video.
Worse yet, nothing stops flash from working in the YUV color space when mixing video and non video elements.
Re: Solving Different Problems
#39Earlier quoted context omitted.
If that's the major reason preventing them from being performant, then I misunderstood the reason for crashing and the reason for poor performance to be the same. Apple should not be complaining about CPU usage. That doesn't excuse Adobe from making buggy plugins.
Indeed the flash plugin has been riddled with crashers and security vulnerabilities. But the blame for high CPU usage during video decoding seems to have been mostly in Apple's court before that.
With Mountain Lion 10.8 Flash is still the same like before those APIs were released. I think Adobe just don't cares about it. I really I can't the strategy behind it. Flash at its best times was nearly on every PC and Mac why is that they didn't want to improve the quality of their app.
I don't want to listen (to customers and developers) you need to feel it.
Re: Solving Different Problems
#40The condescension in that post is galling.
"Try to keep up here." "Again, say it with me:" "Please tell me you know people who aren’t as tech savvy as you. If you don’t, get to know some in order to maintain proper perspective."
A lesson in how to not communicate a technical idea.