Thursday, January 21, 2010

The HTML5 video rollout is a total mess

It's a temporary lift of my Blog's hiatus to express my opinion on today's HTML5 video rollout. It's an utmost near failure.

First, Mozilla releases the new version of Firefox today, 3.6. This is also the same day many Video sites start rollouts of HTML5 support.

BUT... Most people would associate this 3.6 update to Firefox to the HTML5 rollout. This is nowhere near the truth.

Firefox failed to obtain a license to use H.264 decoding in it's browser, and every implementation in today's HTML5 rollout ALL use H.264. Therefore, this left Firefox entirely cut out of this technological move to a much more streamlined and less resource intensive video playback experience.

Most people reporting on the new HTML5 video playback who actually could watch the videos in that format, like Chrome and Safari users, reported sluggish playback since it's 100% software driven (Like trying to play a video using OpenGL on VLC). The day HTML5 clients can be accelerated with hardware accelerators, (like the Broadcom Chip coming to Intel Pine Trail netbooks or NVIDIA's ION and ION 2) similar to Flash 10.1, then HTML5 would be a contender to push out Flash as a new form of playback.

And now to a couple of drawbacks/criticisms:

Vimeo

*Not all videos are encoded in MP4. Anything with very low motion (such as talking heads) or any old video encoded a long time ago is encoded in Flash VP6. It is impossible to play this in any HTML5 implementation.

*Censorship of the comments for the official blog post for the rollout is Vimeo's way of protecting their community integrity by preventing talk about codecs and browsers and sparking flame wars. I should know, one of my comments about H.264 was censored within 10 seconds.

YT

*Ad-supported videos will never be played in HTML5, since Flash is the only way to integrate the ads. This still makes them protective a little of closed-source infrastructure of applying Google Adsense and banner ads in full-screen videos.

*It's Google. They're sticking to H.264 and are very reluctant to use codecs such as OGG at the moment.

And sites that will never work with HTML5 Video: Hulu and any other TV broadcaster site.

Plus, here's what I'd also like to see in the future as this evolves: Live Streaming playback via HTML5.

So, Mozilla, MPEG-LA, you've learned your mistakes this time, let's hope there's not too big of a mess later on. Also, for those thinking about putting x264 or FFmpeg H.264 decode in Firefox... Well, that's a little of a legal grey area so it shouldn't be attempted at the moment.

And here's an editorial article from a friend: Is VP8 the Codec that solves HTML5's vender problems?

Friday, January 15, 2010

Blog and Twitter now on Hiatus

My blog and Twitter will now be on Hiatus. Tweets will specifically be replies only.

I've also deleted many posts that might have been deemed "worrisome" from the past 2 weeks.

Edit: Twitter is off hiatus, but this Blog will remain in hiatus for quite some time.

Wednesday, January 06, 2010

TWiT Live BitGravity, eat your heart out.




Get Adobe Flash player



Before, I used to be able to watch TWiT Live BitGravity High (1Mbps, which is the above embed) on my 25mbps connection on my Core 2 Quad all the way until the cache refreshed after 1 hour. Now it is in an endless loop of breaking and buffering every 1-5 minutes.

I have no idea if it's my ISP or our DNS server or if it's just the fact that the BitGravity player is barely buffering compared to before, where it buffered 2-3 seconds. I've noticed now that it just instantly starts the video and doesn't really buffer at all. Ustream and Justin.tv both have scratchy sound due to encoding at a 22.05k audio sample rate and crude upsampling, making it not my recommended alternative.

I've tried using manual buffering by pausing, it still quits after 5 minutes. Oh and as I am writing this, I stand corrected, it's both the low and the high connections...

Before all this streaming trouble, I was able to watch NASA TV over the internet for over 12-22 hours. Now after 3 hours that quits. Now this happens? Come on Canada, We need Net Neutrality where our Skype packets aren't limited to the point where reliability is so low, we get disconnections and packet loss all the time... Streaming packet limiting is what will be hit next if no action is taken.

I also remember when we got KylinTV, which was kind of like the Chinese version of the Roku box, it buffered like crazy on our connection, so much so that it became unwatchable.

So, for the rare few that still follow this blog (since I might have scared everyone off with all the recent grim news), How's your TWiT Live BitGravity experience? (Preferably, Canadian people watching the stream.)

Edit: Well, someone listened probably... there's now a starting 2 second buffer on the BitGravity feeds at live.twit.tv, it no longer starts immediately.

It solved one half of the problem to do with the stream breaking, But I still get buffering breaks on my C2Q... There must be issues with my ISP... or it's due to the massive amount of traffic viewing the video all as once.

Edit #2: With a blip which I assume was the restarting of the Streamasaurous, I was able to watch 46 minutes before they went live and the buffering became totally atrocious...

Edit #3 (1/13/2010): Buffering's worse again. It's not breaking but when it buffers in the middle of receiving (not the buffer that starts the stream), it goes on for 2-4 seconds then continues. I freaking hate my ISP...

Edit #4 (1/27/2010): The problem is no longer the struggle to buffer, but dropouts... It drops 2 seconds of video as a buffer pause. Then again, today, there's 10000 people watching the stream at the same time...