Flash + Video + standards compliant + maximum compat.

johanafm

A company asked me to decide on how to standardize delivery of video ads to end user with maximum reach while retaining maximum simplicity in the client side code to make all their clients deliver content in the same way. For this reason, I'd just like to check what your opinions are on the matter.

To me, it seems to be a straightforward decision with no complications, but I thought I'd double check since I've only ever seen javascripted solutions for delivering video whenever I've bothered to check how others do it.

My thoughts are to require video/audio to be in H.264 / AAC as .mp4, alongside a flashplayer which can handle the same format. Since that was introduced in Flash 9 (update 3), and Safari has built in support for it, that should present no problems and enable maximum reach as far as I know.

As for simplicity of handling client side code, this ought to suffice (assuming the flash player takes the URL to the video as part of the flashvars)

<object type="application/x-shockwave-flash" data="http://example.com/flashplayer.swf" width="X" height="Y">
	<param name="movie" value="http://example.com/flashplayer.swf">
	<param name="flashvars" value="video=http%3A%2F%2Fexample.com%2Fvideo.mp4">
	<video type="video/mp4" src="http://example.com/video.mp4" width="X" height="Y" controls></video>
</object>

Optionally with a fall-back message inside the video element.

This should presently work in Safari, FF, Chrome, IE8 & 9 as well as in iPhone and iPad. I presently have no means of testing IE7, and usually simply disregard it, but perhaps anyone here knows wether it will work in IE7 as well?

jeepin81

This is a solution I use with HTML5 that also has a flash fallback and if flash is not available it shows an image. I don't know if this solution is better or not but just offering an alternative that is javascript free.

<video preload="metadata" width="x" height="y" controls="controls">
  <source src="your_video.mp4" type="video/mp4"/>
  <source src="your_video.webm" type="video/webm"/>
  <source src="your_video.ogv" type="video/ogg"/>

 <object width="x" height="y" type="application/x-shockwave-flash" data="your_video.swf">
		<param name="movie" value="your_video.swf" />
		<param name="flashvars" value="controlbar=over&amp;image=your_video_img.jpg&amp;file=your_video.mp4" />
		<img src="your_video_img.jpg" width="x" height="y" alt="this is my video"
		     title="cannot play video with your setup...." />
 </object>
</video>

I've also know a few people that have used vid.ly but I don't like the idea of paying and if the above doesn't catch most and they do... I would like to know what they are doing.

johanafm

Thanks. My solution is also js-free, which means we are using the exact same approach, except I start with the flash object and use the video as backup.

The reason is that some older IEs (don't remember which) do not recognize the video element, and therefor completely ignores it, instead of proceeding to find the flash fallback inside it.

bradgrafelman

johanafm;11013355 wrote:
I start with the flash object and use the video as backup.

Wouldn't that mean if a browser supports both that it will use the Flash object? I would much rather use the video object to avoid using something that consumes more resources than a starved fat kid at a buffet.

johanafm

Hmm, good point! Perhaps it's time to screw older IEs if they don't recognize the video object. Thanks

johanafm

Followup question. I can't get Firefox to fallback to the flash object when there is no supported video type present. Or have I missunderstood the standard so that the fallback object would only be used when the video-element itself isn't supported, rather than when none of the video formats are supported (i.e. the source elements). I'm hoping I'm doing something wrong here, because it seems insane to me that it's video support fallback which is considered rather than video format support fallback.

I don't want to go down the road of having to supply 3 different video formats or demand that others do so either.

Is it possible to get this to work anyway, without js? Or are these really the three options
1. use video with 3 different encoded sources and flash fallback
2. use flash with H.264 encoded .mp4 video and video as fallback
3. use js

jeepin81

My apologies... I did notice your solution is JS free and meant to type "another JS free solution".

In regard to your flash fallback on firefox are you using a relative path to the swf? If so, I believe it needs to be an absolute path.

johanafm

Using absolute paths or relative paths make no difference. This is what my absolute path attempt would look like

<video poster="https://media.example.com/path/screenshot.jpg" controls width="X" height="Y">
	<source type="video/mp4" src="https://media.example.com/path/video.mp4">
	<object type="application/x-shockwave-flash" data="https://example.com/path/flashplayer.swf" width="X" height="Y">
		<param name="movie" value="https://example.com/path/flashplayer.swf">
		<param name="flashvars" value="netstreambasepath=https%3A%2F%2Fmedia.example.com%2F%26image=https%3A%2F%2Fmedia.example.com%2Fpath%2Fimage.jpg%26file=https%3A%2F%2Fmedia.example.com%2Fpath%2Fvideo.mp4">
	</object>
</video>

Which results in the poster image being shown (or plain gray background if no poster image is set), overlayed with the localized text "No video with suppored format or MIME type found." And it does work as it should when the object is the outer element. Any thoughts?

Ashley_Sheridan

You don't really need the WebM format either if you're looking to create only the absolute minimum of required assets. All the browsers which support WebM also support either H264 .mp4 or .ogv. The only real advantage is that WebM is smaller than .ogv of a similar quality, so it may be better in bandwidth terms.

johanafm

Thanks for all the feedback.

After I realized that FF doesn't use object as video fallback, I read the HTML5 spec. It clearly states that only source elements should be considered. The use of other elements as fallback is only intended to be used for older browsers that do not recognize the video element. So while I agree with brad, the only way to implement fallback without use of javascript is to use object as container for video rather than the other way around. Otherwise, you'd need to use two different video formats. WebM and Ogg are supported by FF, Chrome and Opera, while H.264 is supported by IE9, Safari and Chrome.

Since IE8 has no video support, it will fall back to an object child element, while Firefox (and while untested I assume Operar) will not.