Serious timing/caching problem with Flash fallback about html5media HOT 10 CLOSED

Thanks for reporting this.

I've run the player with a test video of my own. You can see the result here:

http://praegnanz.de/html5video/html5media.php?mp4=http%3A%2F%2Fstatic.etianen.com%2Fhtml5media%2Fdemo%2Fvideo.mp4&ogg=

It works fine on my FIrefox install. How is it one yours?

Potentially we've got a video encoding issue here.

from html5media.

Well, look at this screencast I took with Firefox 5 on my Mac, using your provides URL. It’s quite unstable. Sometimes it will load Flowplayer, sometimes not, perhaps depending on whether I load, reload or force reload the page:

http://praegnanz.de/html5video/fftest.swf

Web page relaunch. New URL:

http://praegnanz.de/html5video/p_html5media.php?mp4=http%3A%2F%2Fstatic.etianen.com%2Fhtml5media%2Fdemo%2Fvideo.mp4&ogg=

from html5media.

Wow, thanks for the clarification. I can now reproduce the issue.

If it's a timing issue, then I suspect it has to do with detecting the DOMReady event. html5media comes in two flavours, both with and without jQuery. The non-jQuery version being used by your site relies on a small DOMReady library that could very well be out of date. I'll investigate this over the next few days.

In the meanwhile, thanks for your post on the html5 video topic. html5media was one of the early contenders for cross-browser html5 video, and takes a different approach to most. One of the original ideas behind html5 video tags was allowing people to get familiar their browsers native controls, rather than a different set of controls on each site. This vision has arguably been stomped on by most recent players' attempts to create a standard cross-browser UI. There's arguments for a cross-browser video UI, and arguments for letting the user's browser determine a consistent set of controls for each site.

html5media remains valid as one of the smallest and simplest cross-browser implementations out there. The idea with html5media was that as mainstream browsers supported the video tag natively, it would become obsolete. Other players, such as mediaelement.js, will always be useful to provide a beautiful, customisable UI. Nevertheless, I do think that the original html5 vision of using simple

from html5media.

this great explanation could be on the readme file =)

Edit: About the approach and what's the current scenario and other contenders.

from html5media.

So, switching to jQuery-Dom will solve the problem? Let’s see!

from html5media.

Switching to jQuery-Dom will maybe solve the problem. :P

If it doesn't then there's something really odd going on...

from html5media.

Not really. I changed the script from to "html5media.min.js" to "jquery.html5media.min.js"... Nothing different. Thanks for invetigating. Take your time!

from html5media.

@gerritvanaaken, you are with a server configuration issue, not related to the loading script.

Your SWF is being gziped by Apache, and this is know to cause problems with flowplayer. This is pretty hard to find out, but not long ago this topic was discussed on HTML5-boilerplate project. There you should fild a nice discussion about that =)

https://github.com/paulirish/html5-boilerplate/issues/549

from html5media.

@irae Wow, I wouldn’t have thought of that in a hundred years. Problem solved, obviously! Just added this lines to my .htaccess file:

< Files *.swf>
SetEnv no-gzip
< /Files>

from html5media.

@etianen: Maybe you can provide this information in the docu as well. Thanks for being so quick in response!

from html5media.