Hi there,

I know this may be a won't fix, but I figured this suggestion is probably better here than trying to start a new project.

Would it be possible to adapt SWFTools to use the HTML 5 <audio> and <video> tags, as a primary method of inserting content, and falling back to flash were needed?

For example, if I provide a m4v file, could SWFTools wrap it in a <video> for Safari 3.1+, MobileSafari 3 & Chrome, and then play the m4v with a flash player for other browsers?

I would love to help, but don't really know where to start.

Soli Deo Gloria

Jerome

Comments

sinasalek’s picture

+1

Jerome F’s picture

subscribing

comparellc’s picture

also subscribing

ManyNancy’s picture

yes please

Stuart Greenfield’s picture

Is the idea here that there is some sort of client side detection? And if the browser can do it we just use <audio> or >video> tags?

So that would mean some sort of JavaScript to a more complex replacement I guess?

The primary aim of SWF Tools is swf embedding, so I'm not going to focus on this feature in the short term as I need to get the new SWF Tools out, but I'll park it to one side for development later.

If anyone wants to make a start and contribute some proposed code then that would be great!

nirbhasa’s picture

Or we could have it the other way around - basically go with the swf embed, and then if we detect an iPhone or iPad we fall back to tags. Im not sure about anyone else, but that's our primary concern right now, that we have a whole bunch of user-contributed video embeds using the [swf ] tags and they cant play on an iPhone.

Ill try and look at the code if I get time.

lil.destro’s picture

The consensus regarding html5 at this point would be to declare the html5 src first then provide fallbacks for unsupported browsers. There is no need for any javascript browsers will just grab what they need and pass over the rest. The only problem lies in have to supply multiple files.

If you think of it this way right now you probably want to use html5 to reach a broader audience rather than a increase performance. So what we can do is eliminate one file and kill off Firefox (chances are if they are in firefox they have flash). So then you have your iPad/iPhone friendly html 5 markup and a flash embed to fall back on.

ie.

<audio>
  <source src="elvis.ogg" /> <!-- Firefox -->
  <source src="elvis.mp3" /> <!-- Safari/Chrome -->
  <!-- now include flash fall back -->
</audio>
nirbhasa’s picture

Hmm. I was thinking the point of SWF tools was to give admins the control over the display of SWFs. If html5 takes precedence then the browser takes over the display.

Im sure we could just have a toggle to choose which takes precedence, and in the long run, it is certainly the right thing to do to declare the html5 first. However, inserting html5 tags as a fallback for now seems easier to implement and more in keeping with the purpose of the module.

bonked’s picture

>However, inserting html5 tags as a fallback for now seems easier to implement and more in keeping with the purpose of the module.

The problem is that goes against the current implementations on devices (I'm looking at you Apple) and if you declare the flash first, the iPad and iPhone will ignore the html5 fallbacks. So, in real practice, you need to have the html5 tags first and the iPad has a known issue that will not render video that also contains the "poster" element.

I started yesterday on extending swftools + flowplayer3 to have html5 tag support as described here, depending on the success I have with that I'll gladly provide my code back as this is obviously one of those things that sales people are running into when approaching clients with video needs.

ggevalt’s picture

As a non-programmer but enthusiastic user of Drupal and as someone deeply appreciative for all the Drupal community does to help non-profit educational users like me, I really want to tell you how much I appreciate the direction of this thread. Our actual use of an HTML5 player go beyond the iPad, iPhone situation -- sadly, there are many schools we work with who don't have flash loaded up on the school computers or who don't regularly update flash. We also have a lot of students in areas that still only have, gulp, dial-up, so we've been looking for a way to set up one, consistent audio playing solution that would allow several layers of deprecation....

The concept of being able to accommodate users ranging from iPhone, iTouch, iPad users (about 10 percent of the kids) with an html5 player at the front, then flash (broadband, Safari/FireFox/IE) and then a file link to allow playing using resident computer player would be ideal.

Thanks so much for your efforts and look forward to seeing how you make out.

If you need a user tester, let me know. FYI, we are presently using CCK, filefield and mp3player but have been testing swftools for a number of potential uses, including video/slideshows.... so we'd be open to switching our sites...

thanks again.

geoff

kmadel’s picture

I have created exactly such a module - it is under review here: http://drupal.org/node/803312

It uses 'browscap' if installed to only create a 'video' element or an 'object' element with a Flash player - it also has an option to generate a download link.

As far as the poster element is concerned - the poster image is included as an attribute, rather than a child element of the video tag, so there aren't any issues with the poster image on the iPad/iPhone - they work just fine.

Also, there is an additional option (if you have the 'colorbox' module installed) to use a 'lightbox' formatter that will generate a image link out of your poster image, that when clicked on will display the video in a lightbox.

Right now, the module is under some scrutiny because of the use of the 'video' element is not valid for XHTML 1.0 Transitional. I believe that it should be a user decision to weigh whether the benefits of the 'video' element outweigh XHTML 1.0 transitional validation OR could just instruct users to just declare their html (in their page template) as "".

I believe that it is more important to move forward with a module like this as mobile devices with webkit/firefox/opera browsers that support the video element become more and more pervasive and represent more and more of our websites' traffic.

bonked’s picture

Are you positive that poster element works with iPad. It is a pretty well documented bug, it doesn't impact the iPhone (I may have misspoke) but it is a documented flaw with the iPad when using the fallthrough technique. If you are doing serverside checking and not outputting code to fallback, it would never impact you, but the fallback behavior may be desired in some implentations.

Stuart Greenfield’s picture

Sorry - been away for a while and just catching up.

The whole Apple/Adobe/HTML5 thing makes some interesting questions for how to handle video and audio.

I have to admit I've not really been keeping up with the best way forward here, but I have previously come across a suggested solution at http://camendesign.com/code.

Implementing that would mean that SWF Tools needs to be given, potentially, multiple versions of a file to accommodate the various support in different browsers.

Using <audio> or <video> tags are a way of embedding the media, so in that sense maybe an additional embedding method could be created for SWF Tools. Not quite sure how to let SWF Tools work out how to embed the content though, and it could create some interesting issues versus playlists (a playlist is, initially, an array of files. Maybe to handle these tags some array entries are in turn arrays of arrays... I can see this needing some (lots of?!) thought...)

I think some trial work is needed on this to try and determine the best way forward. As such I don't propose to put anything in place for the planned 6.x-3.x release as adding support for a whole new embed method and class of browsers is likely to take some time. But I will come back and look at it as it is clear that some sort of support is going to be needed.

In the meantime, please use this thread to chip in ideas and help move things forward!

mstrelan’s picture

subscribe

gagarine’s picture

suscribe

radj’s picture

+1

HansKuiters’s picture

+1

davebv’s picture

+1

jorisx’s picture

HansKuiters’s picture

@jorisx: nice article. Thanks.

davepotts’s picture

Support for HTML5 in some form or another would be great. Since we're actually streaming and not serving video via http, our preference would be to have HTML5 as the fallback, and not the other way around.

sreynen’s picture

"Is the idea here that there is some sort of client side detection?"

No. It needn't be, anyway. Clients that support <audio> and <video> tags use them automatically and ignore the fallback content inside the tags. Clients that don't support the new tags ignore them (just like any other tags they don't understand). There's no need to code a fallback, as that's all handled by user agents.

There would be a need to do detection if you're treating HTML as a fallback to Flash, but that runs counter to best practices (e.g. progressive enhancement, Drupal JavaScript principles).

binaryreleases’s picture

I just spent a hefty chunk of this evening messing around with views trying to get html5 audio to work. From my initial tests the speed of it with safari vs using the standard flash mp3 player module is quite noticeable.

The biggest problem I have had at this point has been getting the file name to actually sit in the code correctly and trying to pass it work with filefield and replacement patterns. If i get a result I will make sure to post it up.

mandclu’s picture

subscribe

thinkingcap’s picture

Subscribe

butler360’s picture

Just saw this module pop up: http://drupal.org/project/mediaelement

Looks interesting.

geerlingguy’s picture

Looks like Flowplayer 3.2.3 supports iPad/iPhone, at least, by default: http://flowplayer.org/3.2/3/

Could this be implemented in the Flowplayer support, at least? (Or, is it already? Haven't had time to try it out yet).

nirbhasa’s picture

The player works if you place the contents of the latest 3.2.3 version into the /shared/flowplayer3 folder and update the 'Player file' in the settings. I thought it would fall back to quicktime if I disabled flash, but I get the 'flash is missing' message. However, perhaps it works by specifically detecting iphones/ipads, Im off to hunt down someone who has one and find out :)

nirbhasa’s picture

Nope, its not working with iphone straight off the bat, i get the 'flash missing' message.

focal55’s picture

subscribing

bcobin’s picture

subscribe

nickbits’s picture

Am keeping a close eye on this, would love to see the feature. As for which to fall back to, why not have that as a setting so it can be changed to suit individual preferences?

mipaca’s picture

For those that are using FlowPlayer 3, I created a patch against HEAD in CVS that needs review over in the Flowplayer 3 - Add support for iPhone/iPad plugin issue.

rovo’s picture

Seems strange that a module named SWF Tools would have anything to do with being primarily an HTML5 video player, and falling back to Flash...

Robin Monks’s picture

+1

sreynen’s picture

@rob_dean, these are strange times. :) SWF Tools should allow people to use Flash however they want. Until very recently, there was no way for Flash to be a fallback media player, because there was nothing from which to fallback. Now that modern browsers have built-in media players and APIs for controlling them, fallback player is a legitimate use case for Flash. Makes sense that SWF Tools should adapt to these new use cases, strange though they may be.

Stuart Greenfield’s picture

Just to acknowledge that I am watching this thread! At the moment my focus is on getting SWF Tools 7 sorted out. Audio/video tags might be in the first release (depending how things go). I have some ideas for how to implement this under SWF Tools 7 but I've not given it a lot of thought yet. It will come though.

What I might do is work it up for SWF Tools 7 and then port back to 6...

Thanks for your patience!

Stuart Greenfield’s picture

JW5 player has its own embedding method that lets you fall back through different methods. I'm currently experimenting with that on the SWF Tools 7 code, so when I have it worked out I'll aim to port it back. Sorry about the delays (just realised my last post on this thread was MARCH - where has 2011 gone??!!)