Forums | MacLife

resedit · 2009-09-19 6:35 am

As a Lunix user, html 5 media is very attractive, it removes the plugin mess that plagues many web sites.

Yes, plugins like gxine, mplayer-plugin, totem-plugin *sometimes* work but they all have their limitations which can be quite severe.

So I've been playing with html 5 media.
Unfortunately, it isn't ready for prime time.

The biggest problem:

Many webkit based browsers do not properly handle the fall-back methods.

Epiphany and Midori (gtk-webkit) refuse to render flash and even plain text fallback, leaving the use with nothing.
If they can't handle the video, audio, and source tags - they are suppose to ignore them. They don't.

google chrome (linux) is a little better - it will handle some fallback (IE text) but will not render flash fallback even when flash is installed.

If the non Safari webkit based browsers were the only problem, I wouldn't give a smurf mushroom.

However - Safari on Windows is a problem.

A) QuickTime on Windows blows. It really blows. It can not play many mp4 files from disk without skipping that play just fine via streaming flash or video lan client. If Apple isn't going to fix QuickTime on Windows, they need to either disable html5 media support in their Windows build or use a Windows Media Player backend to handle it.

B) FireFox 3.5 on Windows has trouble buffering large files, at least over 802.11g. As in it just sits there spinning. Consistently. Doesn't seem to be a problem with smaller files sizes or when connected via wired lan. Also doesn't seem to be a problem with the linux build of FireFox 3.5. However, flash buffering / streaming is not a problem.

C) Safari breaks the html5 spec by auto-buffering even when you have not specified that it should. I suspect it just ignores the web page and uses the QuickTime plugin setting. The problem is that if you have a bunch of pieces of multimedia on a page via html 5 media, Safari will buffer them all thus sucking your bandwidth even if the user doesn't wish to view any of them. Shame on you Apple, bandwidth isn't free. I don't mind serving it to those who want to see/hear the content, but I shouldn't have to for those who really have no interest in seeing it.

So - for now, html5 media is not IMHO quite ready for prime time.

What I am doing instead -

http://www.shastaherps.org/herps/Americ … multimedia

I'm using a div with an id tag that has hyperlinks:

Code:

<div id="MM182-bullfrog2">
    <p>
       <a href="/media/mp4/182-bullfrog2.mp4">182-bullfrog2.mp4</a>
       <br/>
       <a href="/media/ogv/182-bullfrog2.ogv">182-bullfrog2.ogv</a>
    </p>
</div>

Unfortunately, for people with JavaScript disabled, that's all they will get.
If JavaScript is enabled, I detect whether or not flash is installed, and if it is, whether or not flash version 9 is installed.
To do that I'm using this open source JavaScript library:

http://www.featureblend.com/javascript- … brary.html

I then check to see if flash major version 9 or newer is available. If flash 9 or newer is available, the above div has it's children removed and it is used for Flowplayer. If flash is not available or is too old, the above div is removed and replaced with html5 media tags.

Example dynamically javascript that does it:

http://www.shastaherps.org/js/38-flowplay.js

Other methods I tried -

A) Using html5 media with flowplayer as fallback if and only if js and flash 9+ available.
Advantage - html5 media in web page even with JS disabled.
Problem was the linux webkit browsers, safari on windows, and firefox on windows.

B) Using JS to replace html5 media on browsers with JS and appropriate flash
Advantage - html5 media still there for browsers w/o js and/or flash
webkit browsers properly render flash.
Problem was that it looked funny on html5 capable browsers because the html5 media would start to load only to vanish and then be replaced by flash.

C) What I'm doing now. Start with plain text hyperlinks, use JS to insert flash for capable players, html5 media for non flash capable.
Advantage is it solves the issue of momentary html5 appearing only to vanish.
Dis-advantage is people w/ scripting disabled only get hyperlinks.

Webkit browsers w/o flash still get failed content because webkit refuses to render the fall back text.

C is what I'm going with, but I hope html 5 media support improves so I can go back to A.

-=-

Yes, I know the audio clips on my page look funny. That's because I'm using the free version of FlowPlayer.
I am impressed enough that I will license it, allowing me to use the streaming media (and other) plugins so I can use mp3 instead of flv for audio, and won't need the log in audio clips (I don't mind their logo on video, it's non obtrusive).

Yes, I know a plethora of free mp3 flash players exist, but I don't want two different interfaces, I'd rather just license Flowplayer, which I will do in October. There's some other plugins I want as well.

-=-

So that's my analysis of html5 media.
Not quite ready for prime time, hopefully the issues will be fixed shortly and I can go back to option A.

Dear Apple,

Fix QuickTime on Windows. It blows.

Fracai · 2009-09-19 9:35 am

Have you tried the technique from http://camendesign.com/code/video_for_everybody ?

resedit · 2009-09-19 2:39 pm

Yes - but his technique uses some non flash plugins for fallback which can extremely problematic in Linux land because they trigger gxine / mplayer-plugin / totem-plugin.

It's better IMHO not to do anything that requires a plugin other than flash, and that only when you have tested that an appropriate version is installed. If that means some users get text links to download the files, that's probably better than possibly triggering a media player that may not properly play the media.

His solution for example falls back to QuickTime before flash.
QuickTime on Windows really does suck. You don't want to trigger QuickTime on Windows. And on Linux, QuickTime will trigger gxine or mplayer-plugin or totem that will only handle h.264 if the user has installed software that probably didn't come with their distro, as h.264 is patent encumbered. Flash however is something that many if not most desktop users have installed, so for a html5 fallback, it's a much better choice.

resedit · 2009-10-04 6:04 am

OK - I did some work on it last night.

http://www.shastaherps.org/xml_MMmediaClass.phps

Example usage -

Code:

$media = new embedMedia($DOM,'imunique,'/media/mp4/boo.mp4' ,'/media/ogv/boo.ogv');
$media->type = 'video';
$media->poster = '/img/boo.jpg';
$media->autobuffer = true;
$media->width = '640';
$media->height = '480';

for html5 content w/ flash fallback:

Code:

$foo=$media->html5();
print($foo->saveHTML());

for flash w/ html5 fallback:

Code:

$foo=$media->flow();
print($foo->saveHTML());

Right now I'm doing the latter because of a number of problems with html5.
Nutshell - when the only browsers that support html5 have shortcomings in their implementations that don't exist with flash / flowplayer, then flowplayer should be the default.

Hopefully html5 support improves.

Last edited by resedit (2009-10-04 6:08 am)

Forums | MacLife

#1 2009-09-19 6:35 am

Experimenting with HTML5 media

Code:

#2 2009-09-19 9:35 am

Re: Experimenting with HTML5 media

#3 2009-09-19 2:39 pm

Re: Experimenting with HTML5 media

#4 2009-10-04 6:04 am

Re: Experimenting with HTML5 media

Code:

Code:

Code:

Board footer