HTML5 Video: Not Quite There Yet
Online video is an exciting field to work in. As creator of the JW Player, I'm privileged to be at the forefront of the industry. Every week, our team receives thousands of emails from web developers regarding various bug reports, product feature requests and general thoughts about the online video space. In these emails, we've seen a growing interest in HTML5, since its video implementation allows web developers to independently control video content.
Apple's launch of the iPad and its successive arguments with Adobe over Flash accelerated HTML5 video development. One could argue that today's tech industry is in a state of video tag euphoria. Although many high level discussions regarding online video are circulating through the blogosphere, the practical side of HTML5 video development has been overlooked. Therefore, when working hands-on with HTML5 for video development, it becomes clear the standard faces a major threat.
The video tag is still in its infancy and misses certain core functionalities. As developers demand these features, browser vendors are tempted to implement incompatible solutions instead of agreeing upon standards. These hasty developments, already underway, are setting HTML video up for the same chaos as HTML styling in the pre-CSS era.
Here are a couple of the most pressing issues:
Codecs
The H264 versus OGG debate is ongoing, but all browsers have placed their bets - Firefox and Opera favor OGG, Internet Explorer and Safari choose H264. Chrome plays it safe and does both.
While their reasoning is noble, Firefox's choice to support just OGG isn't practical. The majority of online video content is encoded in H264. Nearly all mobile devices that support web browsing use H264. Desktops and laptops can do hardware decoding of H264. By contrast, content in OGG is virtually nonexistent and the number of mobile devices supporting OGG decoding is devoid. The lack of hardware decoding for OGG makes playback of HD content a resource hog. Apparently, developers don't want this.
Perhaps OGG (or VP8) will gain traction in the coming years. However, developers want to use HTML5 video today. And today's online video format is H264.
Streaming
HTML5 does not specify a streaming mechanism yet. While this is being worked on (W3C: Fragments, Media Multitrack API), it means that live, DVR and long-form video content cannot be played using a video tag. Most browsers do provide an alternative, such as utilizing the range request header to do pseudo-streaming, but this is no long-term solution.
Safari, however, does provide a working streaming solution. It is easy to use (although a simple ingestion tool is still missing) and follows the emerging standard of chopping up videos into small fragments and delivering those to the browser. Unfortunately there are small differences between Safari's implementation and that of, say, Silverlight and Flash:
1) Safari requires the video fragments to be wrapped in an MPEG TS container, while both Flash and Silverlight use MP4 containers.
2) Safari uses M3U8 text files to tell the browser which video fragments are available. Silverlight and Flash both use XML files.
Since streaming is the single biggest block missing in HTML5 video, other browsers may rush to implement their own streaming solutions (for example, IE9 might support Silverlight's fragmentation and manifesting). A single standard is needed for HTML5 video streaming to ensure its usefulness.
Fullscreen
While a small feature at first sight, fullscreen playback is essential to the success of HTML5 video. Fullscreen video captivates the viewer, greatly enhancing the visual experience, and tends to increase viewer engagement. Without fullscreen, HTML5 video is mostly useful for presenting short clips.
Browser-wise, things get a little complicated. The W3C video draft specifically states that browsers should not provide a public API to cause videos to be shown full-screen. The underlying reasoning (phishing) is valid, but technologies like Flash and Silverlight have already proven that simple restrictions can mitigate these risks.
Meanwhile, developers have demanded fullscreen playback and browser vendors worked around the W3C spec to implement custom solutions. In Firefox 3.6, fullscreen viewing is available by right-clicking a video (no API). In Webkit (the rendering engine both Safari and Chrome are based on), fullscreen mode can be activated by means of ALT-clicking (semi-API). Both options are too obscure to gain any traction. A single public API with clear restrictions is needed.
Conclusion
Video is an important part of today's internet. It deserves to become a first-class citizen and the video tag provides the opportunity to make that happen. Browser vendors should be stringent when building solutions that are both practical and compatible. If not, crossbrowser HTML5 video will be too difficult, not to mention expensive, to implement. This presents the risk of web development regression.
In favor of its advancement, we cannot allow this to happen. Online video will go mobile and big screen. It also needs to become accessible and searchable. HTML5 video will advance the progress in these areas, if developed carefully and intelligently. However, without compatible solutions, online video is in definite jeopardy of a setback.
Follow us on Twitter: 
Comments
Jeroen,
this is a thoughtful and very valuable contribution to the whole debate. I was slightly disappointed in the Bright article earlier today, but this is much more interesting. Thanks.
I have to say though, I strongly disagree with the notion that H.264 is the way to go. H.264 is a patent-riddled disaster waiting to happen. It's not impossible that MPEG LA will pull the same stunt Unisys did when they suddenly tried to charge everyone for .GIF.
Submitted by Dario Gieselaar on Mon, 2010-05-10 17:19.
Good article!
Submitted by Uncle Ninja on Mon, 2010-05-10 17:37.
Nice article by someone who knows what he's talking about!
Submitted by Bill P on Mon, 2010-05-10 18:31.
JW thanks for a concise review. Maybe you should say why H.264 was already your choice in Longtail/BOTR and how it is likely to be future proofed?
Submitted by John Wallett on Tue, 2010-05-11 03:46.
And what about ads solutions? We (video sites with a flash player) had implemented prerolls and overlays ads, it's what nowadays pays our servers bills and salaries, so we wouldn't be able to move to HTML5-video until ads solutions for HTML5-video appear.
Submitted by mmolina on Tue, 2010-05-11 10:09.
@DARIO: That could indeed happen. However, from a practical point of view, H264 is the way to go right now. It works on most browsers. And most of the content that's pushed live today won't be there anymore in five years, when MPEG-LA revisits its licensing scheme.
@John: We supported H.264 in BOTR very early on, for various reasons. First, we wanted to be cross-device from the start. H264 allowed us to support iTunes, iPods, PSPs and Miro at that time. Obviously, right now nearly all mobile devices support H264.
Second, our encoding software (FFMPEG) has an amazing H264 encoder (x264). This encoder allows us to do so-called quality-based encoding, instead of fixed-bitrate encoding. MP4 files are encoded very efficiently (as opposed to FLV), resulting in way less traffic usage per video.
We still support FLV and - since a few months - OGG, but new accounts default to all-H264. Next to that, we backup original videos in case we have to re-transcode in a future format (VP8?).
@MMOLINA: Advertising is indeed not available for HTML5. For this reason, the ones listed above, and others (e.g. analytics, security), Flash will remain to be the technology of choice for some time. Right now, HTML5 is preferred for streaming to the iPhone/iPad.
Submitted by JeroenW on Wed, 2010-05-12 10:56.
I'm the implementor of <video> for Opera and have followed these issues closely for a long time. So far, the browser vendors have all played nice and suggested new features and improvements to the spec. For example, we (the WHATWG/HTMLWG) are working on adding subtitle support right now. Right now, I don't see a risk of fragmentation because of browsers ignoring the spec, if the spec is wrong (cannot be implemented) we just change it. This will happen for fullscreen too, soon enough. Even Microsoft is participating a little, so things are looking good.
The streaming you're talking about seems to be on-the-fly bitrate switching, not live streaming. This would be neat, but hardly a show-stopper. We'll see. Live streaming should already be possible over HTTP, but it hasn't been used much so there may be bugs.
The proper capitalization of Ogg is Ogg. If we end up in a situation where you cannot use <video> without H.264, then we have truly failed. When Opera first suggested <video> the use of a free video codec was one of the most important parts. Things never go away on the web, if we (or Mozilla) were to accept a proprietary solution today, we will have to support it forever. No thanks.
Submitted by Philip Jägenstedt on Sat, 2010-05-15 07:38.
The "streaming" you are so condemning using HTTP byte range requests is actually what Apple do in their HTTP Live Streaming to do direct access to any time offset and to switch between files of different bandwidth on the server. HTTP byte range requests are indeed the way to go for direct access to any time offset - and it works for both, MPEG and Ogg files.
HTTP Live Streaming is only an optimisation on top of that, which allows to dynamically switch between different bandwidth-encoded files. The Ogg community is working on a similar approach. In fact, MicroSoft's Smooth Streaming and Adobe's Dynamic Streaming are also solutions along similar lines. It seems the MPEG community isn't decided yet on which standard to choose - in fact, ISO/MPEG seems to just get to the point of wanting to publish a common standard, see http://multimediacommunication.blogspot.com/2010/05/http-streaming-of-mpeg-media.html .
Video on the Web is indeed an evolving standard and many things are still in the process of being developed. It is quite amazing to see that Web developers are so quickly jumping on a half-finished boat. That really tells me that there is a huge need to move away from Flash and go native in the browsers. Anyone developing applications around HTML5 video right now should be aware that they may build some crutches which may later not be required any more since the standards and the browser implementations have progressed to provide some of their required features natively.
I guess it is a business decision whether to wait a bit longer (as Hulu have done) or to jump on board already (as Brightcove, YouTube, Vimeo and others have done) with less features. But rest assured, the standards will continue to evolve, the browser implementations will continue to evolve, and everyone is committed to introducing as much interoperability as is possible. If you have a concrete issue with any missing features or lack of interoperability, you can always approach the WHATWG or the W3C.
Submitted by Silvia Pfeiffer on Sat, 2010-05-15 08:11.
@Silvia HTTP Live Streaming does not use HTTP range requests. It deliberately avoids it by using fragmented files that are requested in full by simple HTTP GETs.
Submitted by Captain Right on Sat, 2010-05-15 18:47.
@PHILIP: good to hear there's so much cooperation between browser vendors. Both captions and fullscreen support would be big steps forward for HTML5 video.
In terms of streaming, I was hinting towards both bitrate switching and live streaming. I'd be very interested to learn how live streaming is supported at present though. Do you refer to Icecast/Ogg live streaming?
I totally agree that we shouldn't end up in a situation where H264 is the only codec choice. However, every major browser should currently also include support for H264, simply because that is the codec most content is encoded in.
@SYLVIA: as Captain Right pointed out, HTTP live streaming indeed uses fragmented files. Next to that, both Safari and Mobile Safari support seeking through byteranges for unfragmented files. It's good to hear that the MPEG community is working on a standardization for this functionality.
I would say that HTTP Streaming is rather a requirement than an optimization of HTML5 video. As stated above, playing a single video with range request seeking is OK for smaller clips, but not very useful for high-quality, long-form, live and/or multi-device video delivery.
It is indeed amazing to see the speed at which developers start using HTML5 video. Hence this article: to increase awareness that HTML5 video is not "ready" yet. I guess it's up to middleware providers like Brightcove and us to abstract out the current shortcomings and browser incompatibilities and take away the pain from developers.
Submitted by JeroenW on Tue, 2010-05-18 04:59.
Glad you said this. It's something I've been thinking lately about HTML5 and trying to convey to others.
Here's to hoping for complete standards when the dust settles!
Submitted by Kevin Conner on Wed, 2010-05-19 15:43.
Built-in captioning, subtitling, description, and dubbing are necessary from day zero or this thing will work solely for developers in Silicon Valley, who as ever make products just for themselves.
Submitted by Joe Clark on Tue, 2010-05-25 15:27.
Until there is just one format for all, nothing will ever be stable.
TV works because standards are by government borders not by corporate interests.
Good article anyway.
Submitted by Chris on Wed, 2010-05-26 10:24.
Jeroen,
Great article.
What are your thoughts on Google's WebM (http://www.webmproject.org/).
I would think it has to be an important part of the conversation now.
- Sam
Submitted by Sam on Thu, 2010-05-27 04:46.
Submitted by JeroenW on Thu, 2010-05-27 05:03.
Jeroen, thanks for taking the time to clarify a number of things few people have addressed with authority (and who better than you for that!). Thanks also for all the development you've done. I'm happy to say I've purchased a number of licenses for your players over the years for various sites.
Keep being positive and constructive, it's the only way anything will ever get done!
Submitted by randulo on Thu, 2010-05-27 05:05.
As long as secure streaming where people cannot easily grab the stream (or streamed file) and play it from another site or standalone player I think html5 video is of not much use...
Is there any development going on in this direction?
Submitted by Nico on Thu, 2010-05-27 05:35.
Why do I get a sense that the direction is all being driven by Apple? Their recent history is one of locking down and develop a large commercial base rather than promote free delivery of content. The largest share of the market must surely still be computers where they are still not the dominant player
Apple is doing its best, for whatever reasons it may have, to bury flash and I think the community at large should be concerned at this shift in the way development is being driven by hardware
Hardware and O/S manufactures should be working the other way to make their products compatible with as many sources as they can - I fear the world will be driven headlong into a format that is by no means settled or clear, simply to feed the ipad and iphone
Submitted by gbswales on Thu, 2010-05-27 06:10.
Have you considered an additional version/configuration for your beta - one that would first play say an WMV file if Silverlight is installed, then fall back to flash (1-3 formats) or vice versa, then fall back to HTML5 <video> ?
Submitted by Sukha on Thu, 2010-05-27 07:31.
YES YES and YES!!!!! Thanx Jerome!
Submitted by Keith on Thu, 2010-05-27 07:49.
Great article and more clear than many on the Blogs and other sources. HTML5 is not going to replace Flash, and as for the video container / tags, Flash still is more mature and can do way more. What about the fact that us developers also include Video inside our Flash projects for clients, HTML 5 cant do that! And what about the fact that if it were not for Flash video, and Flash animation, applications, online games, and other flash uses, I would not have a job right now! It has been a large part of my business, and just because Apple started off negative press saying that Flash player was hogging resources, it is really false. The blogs of today and people in general just seem to love to jump in and be negative for no good reasons. No facts. Flash has helped the internet become what it is today. You could also say it is FLASH that has helped your video player become so hugely popular!!! Everytime I right-mouse click on a video playing on a website to see what player it is, your name is there!
Submitted by James in NY on Thu, 2010-05-27 08:06.
Pretty much echoed my thoughts exactly. Well said, JW!
Submitted by Jason on Thu, 2010-05-27 09:36.
@Philip Jägenstedt
I never used Opera in my life. thank you.
Submitted by Just another Tag on Thu, 2010-05-27 10:04.
@Nico: secure streaming for HTML5 is not really in the pipeline, though there are discussions on the topic, e.g. at WhatWG and W3C. Security (Encryption/DRM) might stay a distinctive feature of Flash & Silverlight.
@Sukha: we are indeed working on such a feature, as part of our own javascript embedding library (think JWEmbed instead of SWFObject). This lib would simplify embedding, make the javascript API of all three players 100% compatible, and allow you to select the fallback chain. Expect something to popup in our repository next month, and to be released in ~ 3 months.
Submitted by JeroenW on Thu, 2010-05-27 10:51.
HTTP is really not an appropriate protocol for live video streaming. The design decisions made for that protocol are all wrong for live multimedia. Using HTTP to send video data should not be a goal!
RTMP or RTSP need to be implemented in <video>
Live streaming is about delivering a consistent real-time stream of video data to a large number of viewers simultaneously. Because the video is live and continuous we can brook no delays. If there is an interruption in the smooth delivery of the data over the network (which happens all the time) we don't want to wait for that data to be resent, we want to skip it and keep going.
Video needs to be streamed using UDP because TCP's guaranteed delivery and resend algorithms are all wrong for live continuous video.
Now, as for byte-range requests to seek to time-indexes in archived videos... This only works for short videos.
The highest quality archived videos are encoded with a dynamic bitrate. More data is used for complex, fast-motion scenes and less for slow/static scenes. Because of this you cannot simply calculate using the average bitrate of the video what byte-range you need in order to arrive at a specific time index.
To seek in these files you need an index. For short videos you can send the index first but when the video is 2, 4, 8 hours long the index becomes huge and impractical to send before starting playback.
It is much better to use a protocol like RTMP and have the player simply request a time-range rather than a byte-range.
Furthermore, network designers and administrators can and do make accommodations for live video streams at the network layer. Continuous real-time data and bursty, bulk data transfers can be handled differently, improving network performance for everyone. If we disguise our video as web traffic by wrapping it in HTTP we bypass a whole lot of hard work our network engineers did to optimize traffic and we reduce the overall efficiency of the network.
Submitted by Deadplant on Thu, 2010-05-27 12:29.
Another thing that I guess hasn't been touch on much is all of the webcam related sites out there.
I don't suppose there is anything in the works to provide direct web cam access via the HTML5 video tag. This would require a backend server more than likely as Flash requires the use of FMS or some other server setup like Wowza.
So for sites like ustream.tv, justin.tv etc. HTML5 wouldn't be a viable option. While it's not technically videos in the sense of watching videos, it's still the same concept of using video for streaming and chatting etc.
HTML5 doesn't push Flash or Silverlight out of the market, it just provides a better avenue to reach certain devices, and someday perhaps it will provide a solution to delivering video content inherantly across all browsers.
Good article, well and balanced opinion.
Submitted by Joe on Thu, 2010-05-27 12:49.
I'm very frustrated by a trend going on in the web development world. So, I'm sorry, but I need to shout this one.
DO NOT CONFORM TO THE 'ARTIFICIAL' RESTRICTIONS IMPOSED BY A SINGLE DEVICE!!!
The iPad is a single device with very little footprint. Why are people jumping on this bandwagon of... 'Oh, I need to make my sites iPad friendly'? What?
Think people!
Hummer created a very wide vehice, more than twice as wide as some other vehicles. Can you imagine the guys that made roads, parking structures, bridges, tunnels, drive-thru restaraunts, car washes, etc... decided that they needed to be more 'Hummer friendly'. The idea is simply ludicrous.
The people making the cars don't determine how the roads are built. The car manufactures need to conform to the current infrastructure.
So if you have/buy an iPad you can either tolerate the fact that the whole web is not available to you or you can complain to the manufacturer to fix their device. It's insane for developer to bend to Apple's will on this despite the fact that the rest of the net connected planet will soon have flash on both their tablet computers and their phones.
Submitted by Todd in Southern Cal on Thu, 2010-05-27 14:11.
I agree html5 isn't there yet and I indeed dread the codec war which is already waging, because it is clear that it is primarily an emotional discussion instead of a rational one.
Hopefully, the google solution might bring us a way out. However, it is very clear that Flash is not written off yet, notwithstanding a lot of people are jumping up and down to get Flash to its knees. Most people against Flash appear not to understand the software at all, hence the emotional outbursts. Yet, Flash is much more then just a vehicle to show video and audio, but that seems to fall to deaf ears. JW player has been living proof of the power of Flash, I'm convinced there is no player around that takes such clever advantage of Flash strengths.
Chees, Jeroen!
Submitted by Rudolf Boogerman on Thu, 2010-05-27 18:39.
Its amazing how many people have this backwards. Flash is the quintessential closed proprietary system on the web. Developers should be welcoming any movement of the web towards open standards and away from Flash. Thinking that because you know Flash this is a threat to you is incredibly short-sighted.
Whatever your opinion is of Apple's general behavior, they ARE acting in the interests of developers and general web progress as far as their HTML5 push goes. Don't let your iPad hatred fool you into thinking Adobe is the good guy here. They, along with IE, have had the web in a stranglehold for way too long, and thank god its finally coming to an end.
Submitted by Mark Edwards on Thu, 2010-05-27 19:51.
A few big points have been missed in all of this.
Firstly, this fight is not about the merits of Flash V's HTML5. It's about advertising. Apple has now moved into the world of advertising and wants to take on Google on at their own game. Look at the new iPhone SDK and you will see iAd. Most web based advertising is delivered through the Flash Player, Ban that off the platform that has currently cornered the mobile device market and then offer an add delivery solution and your in the money.
Secondly, as I work in Education and I do this in Australia where our copyright laws are much tougher than the US, If we cannot secure streams to the client as we currently do with Wowza and JW player then simply the iWhatever Apple releases cannot be involved in education. Flash is NOT simply a video technology it's interactive multimedia platform <video> ain't that.
Question: Can I have video embedded in content destined for the <canvas> tag ?
Gus
Submitted by Gus Denton on Thu, 2010-05-27 21:31.
@Gus
No, but Javascript + HTML5 + a modern browser IS an interactive media platform. The Flash plugin still has a part to play in that, but it is diminishing.
Nobody is claiming HTML5 is the only piece of the puzzle except those who feel invested in Flash and threatened by change. Flash is becoming obsolete, start planning for the future now or fall behind. Flash flourished because of a lack of standard tools to do certain tasks in HTML, and a lack of performance in Javascript. Those shortcomings are being addressed finally, and that spells obsolescence for Flash.
Jeroen obviously sees this or he wouldn't be bothering with the HTML5 player and this post.
Submitted by Mark Edwards on Thu, 2010-05-27 21:46.
I have only heard "flash is obsolete" from brain washed apple robots who are blinded by the cult mantra
Submitted by ThePlasticSurgeryChannel on Thu, 2010-05-27 22:16.
@ THEPLASTICSURGERYCHANNEL:
No matter how hard you try to turn this into being about Apple, you really can't. This is not about what Apple wants or what's good for Apple. That's political nonsense being forced by people like you.
This is about the maturation of web standards. Flash is an old kludge. Yes, it currently has a place on the web, we get that. Nobody's even arguing that. But the standards are in the process of finally adapting so that complete reliance on plugins to do anything is no longer necessary. Have you even read the blog post above?
And wake up already. The 1995 Apple-vs-Microsoft world is gone.
Submitted by Mark Edwards on Fri, 2010-05-28 04:42.
@Deadplant: I agree to all points when referring to the current state of HTML5 video. However, HTTP Streaming by means of small chunks of video solves the issues you raise:
1) Because files are sent in chunks, the user-agent may decide to skip a chunk, wait for it, or request a lower quality one when delivery takes too long.
2) Chunks also solve the byte-range issue, since they are generally time based (e.g. chunks are all 2sec in length). This makes it an excellent mechanism for long-form content. Seeks are way faster than with UDP protocols, since the first chunk after a seek can be pulled in at the full bandwidth.
3) As to network optimization: our experience is that network admins are mostly working on firewalling UDP traffic outside their walls. One of the biggest complaints over the RTMP protocol is its inability to be transferred into (corporate) firewalls. HTTP solves this issue.
Now, if only the standards committees would look into adding HTTP streaming to the specs. To date, this doesn't seem to be the case.
@Joe: Note there is the proposal of a <device> tag in HTML5. This tag would represent e.g. a webcam or microphone. I don't think this is already implemented in a browser though.
@Gus: yes this is possible. You can do cool stuff with video + canvas. Search the web for HTML5 explode video
And @all: thanks for weighting in!
Submitted by JeroenW on Fri, 2010-05-28 07:07.
Adobe Should provide HTML5 publishing support in flash and Flex so the flash developers will still be able to use their skills they learned in flash and Flex and apply in html5 developement . Something like Google Web Toolkit for Actions Script May be FWT(Flex Web Toolkit) . IT will be great.
Submitted by ATIF on Sat, 2010-05-29 15:32.
While I appreciate and use apple products but I am very concerned when one entity tries control the market be it Microsoft or Apple. Flash has gotten to be the ubiquitous application it has on of its merits not because of market manipulation. Flash is a landmark application that can't simply be dismissed. What Apple/Jobs is doing is market manipulation plain and simple. Suppose Gates and Microsoft decided early on it would not allow QuickTime on its machines. Apple would have been justifiably outraged. If Flash is not up to the task then let the market make that determination not some technology dictator and his minions.
Submitted by Solara on Mon, 2010-05-31 12:29.
I agree with Apple, Flash will perhaps disappear in next few years.
WEB 2.0 is the answer, and many toolkits and application, as well as SVG standard (which is much more precise than flash when calculating float values like GPS coordinates).
There was the time of flash, and I understand who took many years in learning it, I also used it and I found the last versions great, but..
I'm sorry to bash Adobe here, but really, flash games and video streaming are just a small portion of the internet world. I wonder why big services like RAI (Radio Televisione Italiana) or other big video streaming realities use SilverLight instead of flash for their web pages. And the quality is kick ass!
The problem here is still the usual one: Competition, impossibility to achieve a standard in this society, nor for the power plugs and for the internet video neither.
What is sad, is those companies spending BILLION in suing by lawyers each other, and not willing to cooperate to make the digital experience less frustrating for the users.
What I am seeing now, is people drowning in their mobiles, laptops etc..
We are not getting our life better thanks to technology, is more like technology owns our hands/eyes and hearts, perhaps this is what must be paid for living, after all, at just the begin of this new technological era
Submitted by Flash or not Flash on Fri, 2010-06-04 08:59.
As a developer, I believe the dust has settled. H264 for mobile/Apple/Microsoft and H264 with a Flash shell for Google/Firefox/Opera. I am not going to use another video codec nor recommend a browser which only supports another video codec. The time for pissing contests and justifications is over folks, let it go. A lot of formats that became Web standards, like .jpeg, .gif and .mp3 had a rights owner like H264, but the market decided the winner. Google/Firefox/Opera seem to not understands it's the market who decides what becomes standard.
Submitted by Somebody on Mon, 2011-01-17 01:20.
(Probably) agreed. I'm working on a new blogpost on this. Stay tuned ;).
Submitted by JeroenW on Wed, 2011-01-19 07:55.
Great interesting discussion. Thanks to all of you sharing your opinion and for JW initiating it. Gives me lot to think and definitely no conclusions as of yet. It is an open ended discussion and time will tell where this all is going. I hope it will lead to a freer web where standards are not imposed by money and power, but by intelligence, social consideration and common sense.
Submitted by René on Tue, 2011-03-29 12:04.
A few big points have been missed in all of this.
Firstly, this fight is not about the merits of Flash V's HTML5. It's about advertising. Apple has now moved into the world of advertising and wants to take on Google on at their own game. Look at the new iPhone SDK and you will see iAd. Most web based advertising is delivered through the Flash Player, Ban that off the platform that has currently cornered the mobile device market and then offer an add delivery solution and your in the money.
Secondly, as I work in Education and I do this in Australia where our copyright laws are much tougher than the US, If we cannot secure streams to the client as we currently do with Wowza and JW player then simply the iWhatever Apple releases cannot be involved in education. Flash is NOT simply a video technology it's interactive multimedia platform <video> ain't that.
Question: Can I have video embedded in content destined for the <canvas> tag ?
Santiago Vargas
<a href="http://www.ki-design.com.ar/">diseño web</a>
Submitted by Santiago on Mon, 2011-06-27 12:26.
HTML5 spec doesn’t yet cover any meta data outside of duration, width and height (the video spec is one of the more volatile aspects of HTML5). You may have to do it the old fashioned way - with a data object (json or XML) of timestamps for cuepoints.
http://hdwebplayer.com
Submitted by johncein on Mon, 2011-07-25 01:43.
The ability to have video WITH captions is an extremely high priority for anyone in the education or government areas (and increasingly in corporate areas). It's a requirement to provide videos with captions. Right now the only way to provide captions via HTML5 video tag is to have the videos open captioned, which means they are there in the video and no way to turn them on or off. So, we either have to provide two separate videos (one with and one without) or just force everyone to view the captions. Not a good option IMO.
Submitted by Steve V on Fri, 2011-09-02 11:15.
@Santiago: Yes, you can draw video in a canvas element.
@SteveV: Correct. Luckily, there is some movement around the <track> element (for captions) and the WebVTT captions format (basically SRT with some extra tricks).
Submitted by JeroenW on Mon, 2011-09-05 04:06.
is the HTML5 does not support online streaming of audio and video?????????
Submitted by Harmeet Singh on Sat, 2011-10-22 15:00.
Currently not indeed. Only progressive downloading is supported cross-browser (in MP4+WebM).
You can use the HTTP Live Streaming protocol from Apple to stream to iOS, and Flash to continue streaming to desktops. Future versions of Android (4.0) will also support HTTP Live Streaming.
Submitted by JeroenW on Mon, 2011-10-24 08:29.
Post new comment