cpearce

Back in the day, I worked on this API in Firefox.

It's a very old API that was speced before promises were a thing. Once you ship an API, sites start using it, and if you change behavior, you break them. If your browser ships the behavior change first, and breaks a website, people just assume your browser is the one that's broken, and switch browser. So browsers don't like to change behavior, especially before other browsers have, or if other browsers won't.

At least in Firefox's case, it's hard to be confident that the decoders we use for H.264 (the most commonly used codec at the time) would support a given mime type.

Firefox uses the operating system's H.264 decoders, because we had a policy of not feeding the patent trolls. H.264 has a plethora of different levels, profiles and features [1]. The documentation for operating system's H.264 decoders often isn't very clear as to what profiles/levels/features they support. Sometimes the user has installed codec packs which affect what codecs are playable. Sometimes the user is on Windows K/N which ships without H.264 codecs. So the only way to give an accurate answer to the question, is to actually start up Windows Media Foundation, and run some video through them. This requires loading DLLs from disk, and obviously we don't want to be blocking on disk IO in the browser's JS event loop in order to accurately answer this question, and we might not have an example file for the specific combination of profile/level/features the script was asking about. In the end, we ended up doing a "test decode" on startup of the common profiles and caching the result in the user's profile. But again, if the user asks about an obscure profile or level combination we've not tried, we can't necessarily be confident that we'll actually be able to play this.

Saying "yes" optimistically and being wrong would be bad, as then the player would appear to be broken in your browser, leading users to switch browser. So the idea was script would try a few profile/level/feature combinations and pick the best to which the browser returned yes.

We probably could have done a more accurate job here if we had more time, but it's always a trade off between marginal benefits here, verses fixing something else.

[1] https://blog.pearce.org.nz/2013/11/what-does-h264avc1-codecs...

I have the TP-Link AV2000 and found them good. My office has a bunch of metal laundry appliances and concrete walls between my desk and the wifi router, so wifi signal is terrible there. Solved it with the AV2000.

I also tried using a mesh wifi network, and was able to bounce a signal around the dead zone and get a WiFi signal with a higher bandwidth than the powerline ethernet, but I still found I got a lot of glitches in video calls, so went back to the powerline ethernet.

I've not noticed the problems other commenters here had with their adapters with the AV2000.

I initially tried a cheaper powerline ethernet, and it was worse than WiFi, so I'd recommend you buy the most expensive/best one that you can afford.

Smells like a sandboxing issue to me.

Dear Apple... I will pay $200 extra for the option of a keyboard with physical function keys and no touchbar.

Sincerely, Disappointed Customer.

My bicycle helment saved my life. You'll never convince me they're a bad idea.

Mozilla has an office in New Zealand, you could come work with us... :)

This is not surprising at all. But I'm a dog person. I can identify most of the dogs that live on my street by their barks/howls.

It depends. You'll get better integration into the browser if you transcode. But if you're doing the "YouTube testcase", just using a Flash player fallback (without transcoding) would probably suit your needs adequately.

Note H.264 support in Firefox is only available on Windows 7, and soon Vista. So if you want to support Windows XP, you will still need WebM, Ogg, or Flash fallback.

What about the link between sports and aggression? I've seen more fights at sports games than I've seen at lan parties.

You can install Cinnamon (the window manager used by Linux Mint), and it's very good. It behaves "traditionally" (i.e. like Windows 7), and it's much prettier than XFCE.

Your video fallback behaviour seems superfluous. If you want fullscreen on a video, why don't you just request fullscreen on the video rather than its container?

Having the fullscreen request shift to the descendent video also breaks the case where you actually have an element containing a video that you want to make fullscreen, for example if you have custom controls for your video element... This is simply impossible with your API.

The best JS library for fullscreen that I've found is https://github.com/toji/game-shim

It's good because it shims the W3C specified fullscreen API; you only have to learn the specified API, you don't have to learn some other API.

The comments on that article looks bogus...

Since we're in the mood to call an end to unrealistic portrayals of people's fantasies, I think it's about time we demanded an end to romance novels.

Game doesn't work for me in Firefox.

This won't fly in the real world. If an academic writer includes a link to their code in their paper, when it goes through peer review before being published, it will no longer under be a blind review; the reviewer will know who wrote the code by virtue of the github account or domain it's uploaded to. Blind reviews are important, as if you know you're reviewing a paper by someone who rejected your paper, you're more inclined to reject it. That really happens, people are that petty.

Additionally there's the risk that the reviewer will reject the paper, and download the code and publish a paper about it quickly in some other journal/conference.

No, you need to have units on your data. Without units, numbers mean nothing. You select a country, and then you're presented with a list of other countries and some numbers. It's not clear that these are lifetime immigrants or permanent residents. There should be a title on the country info box "Total lifetime immigrants" or "Total lifetime emigrants", and ideally a legend at the bottom defining what that means.

It's also confusing in that the number format follows a European convention of using decimal points rather than commas in between every three digits the numbers, though I can accept that localising your site isn't a big concern.

I'm amazed by the number of 20 and 30 year olds who'd rather comment about how crap Firefox is rather than working on a patch to make it better!

I hear these open source projects accept patches...

I had wondered if this was the angle Google's legal team were taking, given that they only made a half hearted attempt in the Nortel patent auction.

Sounds worked for me in the latest Windows nightly build.

The money Google pays Mozilla is a split of the ad revenue. Google keeps renewing the contract because it's profitable for Google! They also don't want 25% of the web switching to use a different default search provider.

That's the last straw. I'm switching back to Lynx and Mutt!

How did you find working with Firefox's AudioAPI and Chrome's Web Audio API, how do they compare? What drawbacks and advantages did you find working with each of them?

Can you file a bug with the appropriate browsers' bug trackers so they know about the problem?

"Of course, hardware adoption is still a huge question mark which I noticed Google also failed to discuss further in this post."

This has been discussed on the WebM blog:

"The WebM/VP8 hardware decoder implementation has already been licensed to over twenty partners and is proven in silicon. We expect the first commercial chips to integrate our VP8 decoder IP to be available in the first quarter of 2011."

http://blog.webmproject.org/2011/01/availability-of-webm-vp8...

"They don't address why they're removing it, why they chose to do it now, or whether or not they'll be consistent across their platforms."

Incidentally, months ago they've also blogged about why they'll keep YouTube using Flash, rather than HTML5: http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html

Adobe has not yet shipped a version of Flash which supports VP8, or WebM for that matter. They've remained silent on that matter since their initial announcement at Google IO last year.

Why do you think it's so easy to track North Korean officials? Decapitating the leadership in Iraq didn't happen quickly, why would it so much easier in North Korea, a country with far lusher vegetation?

Seoul is only 35 miles from the border with North Korea. The North has artillery which can hit Seoul, hence the South needs to be very careful not to provoke the North. Any engagement would be costly.