app

The encoder is good, but it doesn't hold a candle to x264. It's is still _very_ slow.

Don't forget hardware.

That's true, my only point is that it's a trend in the wrong direction: after Google makes this change there will be people will be using Flash for playback than there were before.

Mainly this: http://digitaldaily.allthingsd.com/20100520/googles-royalty-...

For full compatibility, yes, but realistically there was no reason to use to WebM. With h.264 you cover the following:

1) All browsers with Flash players 2) Any "web connected" set top device/TV 3) About 50% of HTML5 video compatible browsers

With this move by Google #3 falls to 25% or less. And they're looking to add WebM support to #2. At some point consumer demands you support both because their shiny new Macbook Air/Chrome OS tablet/TV doesn't play video. Good move by Google to justify their $125M investment in On2, but end users will end up being inconvenienced as the splintering continues.

This is just going to feel like a regression to most end users who really don't give a crap about who holds what patents.

They aren't supporting h.264 in the <video> element anymore, meaning there won't be anymore HTML5 video players that use h.264. As for Flash, who knows?

A big step backwards for HTML5 video adoption and premature IMO. Other than Android there isn't an existing consumer device out there that plays WebM that I know of. Certainly there is no hardware decoding. Now content creators who host their own video will have to double storage costs or be relegated to Flash and the smallest of the big browsers.

I don't believe YT transcodes during upload, since last I checked they are doing 2-pass encoding (its been awhile though).

However they do examine the buffer during an upload. Try uploading an MOV with bad edit points, they will warn you about A/V sync issues before the upload is complete. I assume they also abort uploads for invalid files.

Is this limited to 1-pass encoding only?

I can't think of anyone who embodies the hacker mentality better than the MakerBot guys. The polish on this version really shows. Keep it up!

Vimeo, NYC

We're looking for web app devs and a sysadmin. Specifics here: vimeo.com/jobs

It's a great place to work, and it's growing like mad.

Interesting, thanks!

I haven't used Google Reader on an iPad/iPhone but I think it's unlikely YouTube is using HTML5 there. Mobile Safari actually has a built in parser for YouTube embed code, so nearly any YT embed will work even thought it's clearly an <embed> tag right to a SWF. Normally Mobile Safari will completely ignore *.swf URLs.

So in some sense we're just now getting feature parity, in another we're ahead.

Disclosure: I work for Vimeo.

It's live now: http://vimeo.com/blog:334

He's already worked for Facebook :)

Because stealing someone's iPhone off a restaurant table isn't a felony, it's petty theft. You're trivializing what the new iPhone is. It represented millions of dollars of R&D and contained proprietary information so is therefor potentially protected under trade secret laws. There's no functional difference between publicizing the physical phone or it's blueprints: you're competition knows what you're up to (and can't sell yet) and your customers are going to forgo buying your current product.

But what did they lose in sales to people who are now holding out for a 4G? Thats the primary reason Apple is so secrative. I also very much doubt this story eclipsed a normal Apple media buy in terms of exposure.

Vimeo is hiring backend and frontend devs, a DBA, and a designer. You have to be in NYC.

http://vimeo.com/jobs

It wouldn't be good for YouTube or other video sharing sites. There are two (well, two that don't require Flash) competing video codecs now-- it's expense that keeps them from both being utilized. Like the article says storage is the mitigating factor to adoption by the video sharing companies.

Didn't Viddler do this like 3 years ago?

Vimeo is hiring: http://vimeo.com/jobs

These encodes are also in ABR-- yuck!!

Totally true!

No, the order of operations the OP posted is correct-- restoring content removed by DMCA is the lawful response to counter notifications, specifically to discourage abuse of the DMCA: if the notifying company is serious about the takedown, they have to be willing to sue you, and the evidence has to be there.

"No, because by putting your content back up the host is opening themselves to liability if it turns out you are wrong. Nobody is going to do that"

No, the point of DMCA is the provider is agnostic to who owns the content. Its the making a decision on who owns the copyright that opens them up to litigation, because they would lose safe harbor protection. Incidentally, NOT putting the content back up would be a violation of the DMCA, which also opens you up to litigation.

"The person who filed the complaint is a mailinator address, or in Russia/Iran/Cuba or works for a corporation with more lawyers than you."

So they're either a 1) liar, in which case your content is back online and you're back where you started or 2) a big corp who can threaten to get their way? Welcome to the fundamental problem with the DMCA: it can be abused.

Cranking up the volume on my MacBook I could barely make out every other word. That and the crappy 8fps + terrible lighting was a big turn off. Putting in the tiniest effort to production value goes a long way and shows you care a lot about what you're talking about!

How is bandwidth pricing built from scratch? You're transferring bits like everyone else. Sure you might be doing it CHEAPER, but they didn't rewrite the rules to peering.

These myths aren't "busted," they just refuted reported numbers with "that ain't true!"

"OGG file for Firefox 3.5, and one MP4 file for everything else (Flash / Safari / iPhone)." I think this illustrates the problem with FF's choice of codecs-- you could do this all with one encode!

Also, the iPhone's supported h.264 profile lacks major features that other platforms (ie Flash) support. Serving one encode downsampled to the iPhone's limited profile is serving to the lowest common denominator. Serving a smaller iPhone-only copy and a second copy with B-frames and more efficient encoding would not only be smaller but would look a lot better too!

Does anyone know if there's any plans to support <video> for other codecs?

* less Erlang posts

51% == 100%