You are currently browsing the tag archive for the ‘google’ tag.

…right now, not so much.  It’s shaping up to be the choice I made between MP3 and Ogg Vorbis: MP3 makes the most sense to use for compressed storage and playback on devices, and Vorbis is preferred for streaming.  In this case, H.264 is like MP3 and WebM is like Vorbis (appropriately, since WebM includes Vorbis audio).  Right now it’s not as easy for me to create WebM videos as it was for me to create Vorbis files back in the day.  I remember using the “spinning fish” applet that Xiph published before there was more embedded support for Vorbis.  Miro Video Converter has a WebM output mode, but it doesn’t appear to be tunable.  Spelunking with the ffmpeg or vpxenc parameters tp create WebM videos doesn’t appeal to me.  It’s one thing to get into the LAME and OggEnc parameters when you’re dealing with a single audio stream.  Add video with its more complex set of parameters to that and it’s scary.

I really like being able to crunch out H.264 videos of decent quality from Handbrake that I can use on my iDevices and computers.  While I would like it if the Handbrake developers would provide similar support for WebM, I really don’t have a reason to use WebM videos right now other than for computer playback in certain scenarios.

Google’s decision to remove native H.264 support from Chrome (and hence, Chrome OS) is going to be great for the web because the trickle-down effect of this will be to:

  • Force MPEG LA to choose whether or not to sue Google for patent infringement over the technologies in WebM and finally get some resolution to the same argument that has always prevented companies like Apple from supporting Ogg Vorbis: the lurking possibility that patented techniques are embedded in the open-source media solution.  I don’t think this will happen since it appears that some of the On2 patents have been infringed by MPEG LA’s solutions.
  • Incent hardware makers to add support for WebM because websites, led by Youtube, will make it their native format.  There were (are?) several makers that supported Vorbis decoding in hardware, and I’m not aware any of them got sued.
  • Make H.264 a completely free implementation for all uses because if it isn’t available for free, software and hardware makers will favor the lower-cost WebM technology.

As far as VP8 video not performing as well as H.264 at similar resolutions and bitrates: it took quite a while for MP3 encoding to catch up to, and in some cases surpass, Vorbis.  There no reason to think that with more development, VP8 won’t catch up.  I look forward to using WebM when I have an easy way to encode to the format and I can use it in as many places as I can H.264/MPEG-4.

I see this decision more like HD-DVD vs. Blu-Ray; different logical formats that could be equally supported by hardware and software.  In fact, until Toshiba killed HD-DVD I thought that (playback of both formats) was the solution that was going to win out.  There’s no reason other than these licensing issues that support for H.264/MPEG-4 and WebM couldn’t co-exist.

How about this?:  Google will continue to ship H.264 support in Chrome if Microsoft and Apple agree to support WebM in their browsers.

  1. Validate that my existing Chrome bookmarks and apps are indeed available on the new computer once I sign in. << DONE
  2. Browse the web! (Duh.) << DONE
  3. Plug in my Blue Snowball and Eyeball 2.0 and attempt to use them with GTalk.
  4. Browse to the Squeezebox Server instance on my Windows Home Server to listen to music. << Squeezebox didn’t work.  I got this going with Firefly Media Server and Fireplay.  However, couldn’t save the Fireplay web page as a bookmark or app. Filed a bug report.
  5. Plug in my digital camera and iPhone to upload pictures and video to Flickr. << Plugged in my iPhone and couldn’t browse the file system while trying to use Flickr’s web uploader.  Filed  a bug report.
  6. See, what, if any, of my podcast production workflow might be able to be done using ChromeOS.
  7. Carry it in a side pocket of my main work laptop case and use it while on the go. << DONE.  When you’ve got six geeks ogling your new tech toy, you know it’s popular. 🙂
  8. (New) Edited my WordPress blog!

 

I received a Google CR-48 netbook from their Pilot Program yesterday.  One of the first things I wanted to do with it was get it to play music from my home library, which is hosted on my Windows Home Server.  I have used both Firefly Media Server and Squeezebox Server on there for a few years.  Firefly serves out iTunes-compatible DAAP, and Squeezebox Server can serve to Squeezebox-compatible clients like MainSqueeze on the Roku.  Since I knew Squeezebox had an HTTP interface, I thought it would be the way to integrate with ChromeOS.  But I’d forgotten that that was only a control interface; playback happened on a device, not the web page itself.

That reminded me of the Fireplay add-on for Firefly, which I had read about but never had a need to use.  While there is a packaged add-on of it available for WHS, installing that didn’t put the necessary files in the Firefly web interface directory.  Manually putting the files in the directory and restarting the Firefly service did the trick.  Fireplay is a flash-based player that communicates directly with the Firefly Media Server.

Fireplay on ChromeOS

Brief instructions:

  1. Obtain and install Firefly Media Server.  I have mine configured to use port 9999 for its web service.  It has an admin password, but not a music (streaming) password.
  2. Obtain Fireplay from here.
  3. Unzip the Fireplay files into your Firefly instance’s admin-root folder; mine’s at “C:\Program Files\Firefly Media Server\admin-root”.  Detailed directions are here.
  4. Restart the Firefly Media Server service.
  5. Browse to the Firefly server using a URL like “http://<servername&gt;:<port>/FirePlay.html”; mine is http://ghostrider:9999/FirePlay.html
  6. Login with a blank username and your admin (not music) password.
  7. Enjoy!
  1. Validate that my existing Chrome bookmarks and apps are indeed available on the new computer once I sign in.
  2. Browse the web! (Duh.)
  3. Plug in my Blue Snowball and Eyeball 2.0 and attempt to use them with GTalk.
  4. Browse to the Squeezebox Server instance on my Windows Home Server to listen to music.
  5. Plug in my digital camera and iPhone to upload pictures and video to Flickr.
  6. See, what, if any, of my podcast production workflow might be able to be done using ChromeOS.
  7. Carry it in a side pocket of my main work laptop case and use it while on the go.

Here’s hoping I’ll get to play with one of these over the Christmas holiday.

Update: I received a CR-48 today! Will be unboxing later tonight.

Reading this NYT article in the Sunday Patriot-News, I couldn’t help but think that the officials that are up in arms about Google’s “inadvertent” Wi-Fi data collection are ignorant about the security available when web browsing:

“Google is in the process of frittering away its last shred of credibility,” Mr. [Till] Steffen [the justice senator for the city-state of Hamburg] said. “The company must immediately disclose to what degree it has secretly eavesdropped as we’ve sent e-mails to friends in Germany and the rest of Europe or as we’ve done our banking in the Internet.”

This prompts a question: are there still banks that don’t use HTTPS when dealing with customers’ sensitive data over the internet?  Even if someone is using open, unencrypted Wi-Fi, their HTTPS session data is protected with encryption.  That would also be the case for any other protocols that encrypt their payload end-to-end (POP3S, SFTP, SSH, etc.).  For example, I use HTTPS sessions by default with Gmail and Google Reader.

The cited German privacy laws as they apply to electronic communications seem to be a way to compensate for the ignorance of those who implement and use this technology in unsecure ways.  I’m not a fan of Google’s collection of that data, but I don’t think that they are on the wrong side of this issue.  Wi-Fi is a broadcast-based technology using public airwaves, and if you’re not securing your broadcast you’re open to being spied upon.

I think the bigger issue here is whether the benefits of technologies like Street View and Wi-Fi-based geolocation outweigh the personal liberty of people whose image or data might be caught by a machine.  Would it make a difference if the Street View vehicles had a bunch of photographers in the back as opposed to automated cameras?  If they had nerds wardriving with laptops as opposed to automated Wi-Fi sniffers/collectors?  I can only recommend that you protect your communcations and wear a mask in public if you’re worried about this kind of stuff.  Or, for now, move to Germany. 🙂

Yes, I’m a fan of Google in general and Street View in particular.  It’s nice to be able to view pictures of an unfamiliar location before having to navigate it for the first time.

@aharden

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Archives