Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Graphics Media The Internet Technology

A Skeptical Comparison of HTML5 Video Playback To Flash 391

gollum123 writes "Think we'd all be better off if HTML5 could somehow instantly replace Flash overnight? Not necessarily, according to a set of comparisons from Jan Ozer of the Streaming Learning Center website, which found that while HTML5 did come out ahead in many respects, it wasn't exactly a clear winner. They did find that HTML5 clearly performed better than Flash 10 or 10.1 in Safari on a Mac, although the differences were less clear cut in Google Chrome or Firefox. On the other hand, Flash more than held its own on Windows, and Flash Player 10.1 was actually 58% more efficient than HTML5 in Google Chrome on the Windows system tested. As you may have deduced, one of the big factors accounting for that discrepancy is that Flash is able to take advantage of GPU hardware acceleration in Windows, while Adobe is effectively cut out of the loop on Mac." gollum123 also links to additional tests indicating that Flash "does not perform consistently worse on Mac than on Windows."
This discussion has been archived. No new comments can be posted.

A Skeptical Comparison of HTML5 Video Playback To Flash

Comments Filter:
  • by shutdown -p now ( 807394 ) on Sunday March 14, 2010 @05:33AM (#31470914) Journal

    Unless a biggie like Google /MS /Apple back on HTML5 i don't see why it would replace incumbent standard

    Both Google and Apple are heavy HTML5 backers. Not only they're on the W3C working group for it, but their respective browsers already implement large parts of it (including, specifically, HTML5 video).

  • Re:Why compare? (Score:4, Informative)

    by shutdown -p now ( 807394 ) on Sunday March 14, 2010 @05:40AM (#31470946) Journal

    HTML5 hasn't even settled on a video codec

    They aren't goint to settle on it. It will be unspecified, just as image formats were in past HTML specs.

    how can there even be a real comparison here?

    You compare both platforms with the same codec, of course.

    Of course HTML5 can't take advantage of GPU acceleration yet, they don't even know what they'll be accelerating yet!

    If they don't know, how do they play it today?

    In fact, they do know. A de facto standard is already in place (Flash played a part in that as well), and it's called H.264.

    HTML5 hasn't had the chance to implement GPU acceleration and that maybe they should consider it as part of their criteria in their codec selection process.

    HTML5 doesn't implement acceleration, browser vendors do. It's not any harder for them to do so than it is for Adobe, so presumably, if Flash can hardware-accelerate, so can the browser. It's just that they didn't get to that point yet.

  • Since flash is not fully supported in 64-bit. 64-bit OS:es will not be able to be widely spread.

    There are a couple different problems with this statement... I'll just say that I'm posting this from a 64-bit OS and a browser that runs Flash just fine. (Well, as fine as a Flash can be run anyway, which is "not very", but that's sort of beside the point.)

  • by shutdown -p now ( 807394 ) on Sunday March 14, 2010 @05:48AM (#31470984) Journal

    Well, Apple has been pushing for standardizing on H.264 as a primary codec for HTML5 video, specifically... so I guess that would make it "yes".

  • by diamondsw ( 685967 ) on Sunday March 14, 2010 @05:53AM (#31470994)

    gollum123 also links to additional tests indicating that Flash "does not perform consistently worse on Mac than on Windows."

    Yes, tests provided by... Mike Chambers of Adobe. I'm sure that they're completely impartial.

    When I turn on HTML5 video support at YouTube, the exact same clip in the exact same browser on the exact same OS on the exact same session runs at a third of the CPU power. Sure, it's an anecdote - and one that's been observed by hundreds if not thousands of others, consistently over the years. But according to Adobe, nope, no problems at all. Emperor's clothes look really chic.

    Fuck off, Adobe. You had years to improve your damn plugin, and we'll all be better off when it and its horrid performance and security record are no more.

  • by shutdown -p now ( 807394 ) on Sunday March 14, 2010 @06:00AM (#31471016) Journal

    Well, I can't speak for Google, but Apple was one of three companies (two others being Mozilla and Opera) which founded WHATWG, thus putting a start to HTML5 development.

    Also, it doesn't make sense for them to "comply with the standard" when there's no standard yet. As it is, both Google and Apple (and others) are writing the standard, and implementing the current drafts. Google also provides HTML5 beta of YouTube. If, as you say, there is no real business case for them to promote HTML5, they wouldn't do either thing.

    The reason why Google touts Flash support in Android at the same time is because Flash is still relevant today, and because this is a major competitive advantage that Android has over iPhone. It would be foolish of them not to raise that point.

  • by AresTheImpaler ( 570208 ) on Sunday March 14, 2010 @07:02AM (#31471186)

    check this:
    http://jilion.com/sublime/video [jilion.com]

  • That's H.263, which is a horrible piece of crap. It's what youtube used before H.264 and they still do for the low-quality version of videos. There's no question that Theora beats the old flv H.263.

  • Not a crap article (Score:4, Informative)

    by Macka ( 9388 ) on Sunday March 14, 2010 @07:27AM (#31471280)

    The author implies that adobe can't use gpu for flash on mac. Why not?

    It's not a crap article because it's true. If you look at the 10.1 public beta release notes [adobe.com] it says:

    In Flash Player 10.1, H.264 hardware acceleration is not supported under Linux and Mac OS. Linux currently lacks a developed standard API that supports H.264 hardware video decoding, and Mac OS X does not expose access to the required APIs. We will continue to evaluate adding the feature to Linux and Mac OS in future releases.

    How Apple react to this will be a good litmus test of how fair Steve J is prepared to be with Adobe. Will he make the APIs available to benefit his customers but risk making HTML5 less attractive, or will he just ignore them and play hard ball.

    As for Linux, the historical lack of a unified approach to solving this (that includes all interested parties) is going to leave us out in the cold for some time yet. Let's hope that Gallium3D sticks, gains enough traction and doesn't get dropped for something else a few years down the road. That will make a nice change!

  • Re:Agreed (Score:1, Informative)

    by CheshireFerk-o ( 412142 ) <kioshi83.gmail@com> on Sunday March 14, 2010 @07:37AM (#31471304)

    it sure does, if you have an 8xxx+ card and flash 10.1 beta... i have a 7600gt agp, 195.x nvidia beta drivers, and the vdpau libs installed, for some reason i can now play youtubeHD without stutter and the flashplayer load is very much spread even over my four cores.

    http://www.nvidia.com/object/adobe_flashplayer_plus_nvidia.html [nvidia.com]

  • by flyingfsck ( 986395 ) on Sunday March 14, 2010 @07:42AM (#31471320)
    MPEG2 compresses by a factor of about 5 to 10, while H.264 AVC compresses by a factor of about 20 to 30 and the subjective quality is better too, being not blocky.
  • by IntlHarvester ( 11985 ) on Sunday March 14, 2010 @07:56AM (#31471364) Journal

    I wasn't particularly impressed with the Youtube HTML5 beta (using Chrome) and ended up opting out. Playback wasn't very smooth, the video controls are slightly buggy, and HD videos seemed to take more time buffering. As of right now, the Flash player provides a far better experience.

    (And Youtube's player controls are probably far better than anything the average developer could come up with.)

    Internet nerds are predicting that HTML5 will be the death of Flash Video, but IMO it still looks like it has a long way to go.

  • by EvanED ( 569694 ) <{evaned} {at} {gmail.com}> on Sunday March 14, 2010 @09:03AM (#31471592)

    I have to respectfully disagree, even based on your clip. In particular, I notice a lot of artifacts around the edges of objects, especially when moving. Some times I wrote down as being particularly noticeable were 3:47, 4:13, and 4:31. The branch at 4:11 was a bit artifacty, and IMO the opening "The Peach Open Movie Project Presents" lettering wasn't even a contest between the two.

    I was watching both in VLC in full-screen mode on a 22" screen. I'm not convinced VLC actually has great quality, but I don't know of anything else I have that'll play Theora at the moment. I tried to do the test blind, even coming up with the script I pasted below (in case anyone else wants to try it; just change the 'theora' and 'h264' functions at top and run in Bash), but I bungled things a little bit and basically managed to spoil myself. I do think it's hard to compare a clip that's close to 5 minutes long; alternating between 10 second clips would be much better.

    In addition, the Theora version responds terribly to random seeks, with portions of the pre-seek image remaining on screen sometimes for several seconds. (I realize this isn't particularly relevant to the power needed for decompression, but it did mean that I couldn't just seek to the same place and compare, and it presents another practical objection.)

    function h264 {
    /cygdrive/p/Program\ Files\ \(x86\)/VideoLAN/VLC/vlc -f --no-video-title-show bbb_youtube_h264_499kbit.mp4
    }
     
    function theora {
    /cygdrive/p/Program\ Files\ \(x86\)/VideoLAN/VLC/vlc -f --no-video-title-show bbb_theora_486kbit.ogv
    }
     
    if [[ $RANDOM -le 16536 ]]; then
        printf "Press Enter to start...\n"
        read FOO
        while [[ $FOO != "no" ]]; do
            h264
            printf "Press Enter to start second video\n"
            read FOO
            theora
            printf "Again?\n"
            read FOO
        done
     
        printf "First: Theora\n"
    else
        printf "Press Enter to start...\n"
        read FOO
        while [[ $FOO != "no" ]]; do
            theora
            printf "Press Enter to start second video\n"
            read FOO
            h264
            printf "Again?\n"
            read FOO
        done
     
        printf "First: H.264\n"
    fi

  • by realityimpaired ( 1668397 ) on Sunday March 14, 2010 @09:13AM (#31471672)

    .mov is a container format, like .avi. They can standardize on H.264 without giving up on QT. :)

  • by Runaway1956 ( 1322357 ) on Sunday March 14, 2010 @09:17AM (#31471694) Homepage Journal

    Super cookies, yes. Maybe you have some? Read:

    http://www.imasuper.com/66/technology/flash-cookies-the-silent-privacy-killer/ [imasuper.com]

    http://www.fightidentitytheft.com/blog/new-breed-super-cookie-defies-removal-almost [fightidentitytheft.com]

    http://lifehacker.com/5245418/betterprivacy-prevents-tracking-by-flash-other-super+cookies [lifehacker.com]

    In short, if you don't know any better, Adobe enables web sites to install a cookie that your browser doesn't even know about, let alone manage. And, those cookies persist forever, tracking anything that the website chooses to track.

  • by TheRaven64 ( 641858 ) on Sunday March 14, 2010 @09:57AM (#31471872) Journal
    It's not quite true on OS X. There is a standard way of playing back H.264 using hardware acceleration: use QuickTime. Adobe can't use this because they ship their own H.264 implementation (which is slower than the QuickTime one and ffmpeg), rather than using the supplied one. There aren't hooks for adding GPU acceleration to arbitrary CODECs, unless you use OpenCL, but there are APIs for playing back H.264.
  • by Taevin ( 850923 ) on Sunday March 14, 2010 @11:14AM (#31472214)

    Except that Adobe have said they do want to fix it, but can't, because Apple refuses the provide the APIs they need.

    Which is clearly bullshit. Adobe is claiming that Apple won't give anyone access to hardware acceleration APIs, and yet I have a number of games and video players that seem to work just fine. The problem is that Adobe refuses to use the available APIs for video acceleration. Why do you think Flash runs at 100% CPU on every platform (I guess not on Windows now that they have figured out some kind of acceleration)? Adobe insists on using their own, poorly written, software decoder.

    Adobe could just send their h264 stream through the QuickTime API, or probably write something else using one of the Core APIs (Core Video, in particular, provides GPU rendering). Instead, apparently, they'd rather sit around bitching about how Apple won't write an API around their application.

Intel CPUs are not defective, they just act that way. -- Henry Spencer

Working...