Recherche avancée

Sur d’autres sites (4624)

• Google’s YouTube Uses FFmpeg

  9 février 2011, par Multimedia Mike — General

  Controversy arose last week when Google accused Microsoft of stealing search engine results for their Bing search engine. It was a pretty novel sting operation and Google did a good job of visually illustrating their side of the story on their official blog.

  This reminds me of the fact that Google’s YouTube video hosting site uses FFmpeg for converting videos. Not that this is in the same league as the search engine shenanigans (it’s perfectly legit to use FFmpeg in this capacity, but to my knowledge, Google/YouTube has never confirmed FFmpeg usage), but I thought I would revisit this item and illustrate it with screenshots. This is not new information— I first empirically tested this fact 4 years ago. However, a lot of people wonder how exactly I can identify FFmpeg on the backend when I claim that I’ve written code that helps power YouTube.

  Short Answer
  How do I know YouTube uses FFmpeg to convert multimedia ? Because :

  1. FFmpeg can decode a number of impossibly obscure multimedia formats using code I wrote
  2. YouTube can transcode many of the same formats
  3. I screwed up when I wrote the code to support some of these weird formats
  4. My mistakes are still present when YouTube transcodes certain fringe formats

  Longer Answer (With Pictures !)
  Let’s take a video format named RoQ, developed by noted game designer Graeme Devine. Originated for use in the FMV-heavy game The 11th Hour, the format eventually found its way into the Quake 3 engine as well as many games derived from the same technology.

  Dr. Tim Ferguson reverse engineered the format (though it would later be open sourced along with the rest of the Q3 engine). I wrote a RoQ playback system for FFmpeg, and I messed up in doing so. I believe my coding error helps demonstrate the case I’m trying to make here.

  Observe what happened when I pushed the jk02.roq sample through YouTube in my original experiment 4 years ago :

  
  
  

  Do you see how the canyon walls bleed into the sky ? That’s not supposed to happen. FFmpeg doesn’t do that anymore but I was able to go back into the source code history to find when it did do that :

  
  
  

  Academic Answer
  FFmpeg fixed this bug in June of 2007 (thanks to Eric Lasota). The problem had to do with premature colorspace conversion in my original decoder.

  Leftovers
  I tried uploading the video again to see if the problem persists in YouTube’s transcoder. First bit of trivia : YouTube detects when you have uploaded the same video twice and rejects the subsequent attempts. So I created a double concatenation of the video and uploaded it. The problem is gone, illustrating that the backend is actually using a newer version of FFmpeg. This surprises me for somewhat esoteric reasons.

  Here’s another interesting bit of trivia for those who don’t do a lot of YouTube uploading— YouTube reports format details when you upload a video :

  
  
  

  So, yep, RoQ format. And you can wager that this will prompt me to go back through the litany of unusual formats that FFmpeg supports to see how YouTube responds.

• Announcing the first free software Blu-ray encoder

  25 avril 2010, par Dark Shikari — blu-ray, x264

  For many years it has been possible to make your own DVDs with free software tools. Over the course of the past decade, DVD creation evolved from the exclusive domain of the media publishing companies to something basically anyone could do on their home computer.

  But Blu-ray has yet to get that treatment. Despite the “format war” between Blu-ray and HD DVD ending over two years ago, free software has lagged behind. “Professional” tools for Blu-ray video encoding can cost as much as $100,000 and are often utter garbage. Here are two actual screenshots from real Blu-rays : I wish I was making this up.

  But today, things change. Today we take the first step towards a free software Blu-ray creation toolkit.

  Thanks to tireless work by Kieran Kunyha, Alex Giladi, Lamont Alston, and the Doom9 crowd, x264 can now produce Blu-ray-compliant video. Extra special thanks to The Criterion Collection for sponsoring the final compliance test to confirm x264′s Blu-ray compliance.

  With x264′s powerful compression, as demonstrated by the incredibly popular BD-Rebuilder Blu-ray backup software, it’s quite possible to author Blu-ray disks on DVD9s (dual-layer DVDs) or even DVD5s (single-layer DVDs) with a reasonable level of quality. With a free software encoder and less need for an expensive Blu-ray burner, we are one step closer to putting HD optical media creation in the hands of the everyday user.

  To celebrate this achievement, we are making available for download a demo Blu-ray encoded with x264, containing entirely free content !

  On this Blu-ray are the Open Movie Project films Big Buck Bunny and Elephant’s Dream, available under a Creative Commons license. Additionally, Microsoft has graciously provided about 6 minutes of lossless HD video and audio (from part of a documentary project) under a very liberal license. This footage rounds out the Blu-ray by adding some difficult live-action content in addition to the relatively compressible CGI footage from the Open Movie Project. Finally, we used this sound sample, available under a Creative Commons license.

  You may notice that the Blu-ray image is only just over 2GB. This is intentional ; we have encoded all the content on the disk at appropriate bitrates to be playable from an ordinary 4.7GB DVD. This should make it far easier to burn a copy of the Blu-ray, since Blu-ray burners and writable media are still relatively rare. Most Blu-ray players will treat a DVD containing Blu-ray data as a normal Blu-ray disc. A few, such as the Playstation 3, will not, but you can still play it as a data disc.

  Finally, note that (in accordance with the Blu-ray spec) the disc image file uses the UDF 2.5 filesystem, which may be incompatible with some older virtual drive and DVD burning applications. You’ll also need to play it on an actual Blu-ray player if you want to get the menus and such working correctly. If you’re looking to play it on a PC, a free trial of Arcsoft TMT is available here.

  What are you waiting for ? Grab a copy today !

  UPDATE : Here is an AVCHD-compliant version of the above, which should work better when burned on a DVD-5 instead of a BD-R. (mirror)
  

  What’s left before we have a fully free software Blu-ray creation toolkit ? Audio is already dealt with ; AC3 audio (aka Dolby Digital), the format used in DVD, is still supported by Blu-ray, and there are many free software AC3 encoders. The primary missing application is a free software Blu-ray authoring tool, to combine the video and audio streams to create a Blu-ray file structure with the menus, chapters, and so forth that we have all come to expect. But the hardest part is dealt with : we can now create compatible video and audio streams.

  In the meantime, x264 can be used to create streams to be authored using Blu-Print, Scenarist, Encore or other commercial authoring tools.

  More detailed documentation on the new Blu-ray support and how to use it can be found in the official commit message. Do keep in mind that you have to export to raw H.264 (not MKV or MP4) or else the buffering information will be slightly incorrect. Finally, also note that the encoding settings given as an example are not a good choice for general-purpose encoding : they are intentionally crippled by Blu-ray restrictions, which will significantly reduce compression for ordinary non-Blu-ray encoding.

  In addition to Blu-ray support, the aforementioned commit comes with a lot of fun extras :

  x264 now has native variable-framerate ratecontrol, which makes sure your encodes get a correct target bitrate and proper limiting of maximum bitrate even if the duration of every frame is different and the “framerate” is completely unknown. This helps a lot when encoding from variable-framerate container formats such as FLV and WMV, along with variable-framerate content such as anime.

  x264 now supports pulldown (telecine) in much the same fashion as it is handled in MPEG-2. The calling application can pass in flags representing how to display a frame, allowing easy transcoding from MPEG-2 sources with pulldown, such as broadcast television. The x264 commandline app contains some examples of these (such as the common 3:2 pulldown pattern).

  x264 now also exports HRD timing information, which is critical for compliant transport stream muxing. There is currently an active project to write a fully DVB-compatible free software TS muxer that will be able to interface with x264 for a seamless free software broadcast system. It will likely also be possible to repurpose this muxer as part of a free software Blu-ray authoring package.

  All of this is now available in the latest x264.

  http://mirror05.x264.nl/Dark/bluray%20fail.png

• H.264 and VP8 for still image coding : WebP ?

  
  1er octobre 2010, par Dark Shikari — google, H.264, psychovisual optimizations, VP8

  Update : post now contains a Theora comparison as well ; see below.

  JPEG is a very old lossy image format. By today’s standards, it’s awful compression-wise : practically every video format since the days of MPEG-2 has been able to tie or beat JPEG at its own game. The reasons people haven’t switched to something more modern practically always boil down to a simple one — it’s just not worth the hassle. Even if JPEG can be beaten by a factor of 2, convincing the entire world to change image formats after 20 years is nigh impossible. Furthermore, JPEG is fast, simple, and practically guaranteed to be free of any intellectual property worries. It’s been tried before : JPEG-2000 first, then Microsoft’s JPEG XR, both tried to unseat JPEG. Neither got much of anywhere.

  Now Google is trying to dump yet another image format on us, “WebP”. But really, it’s just a VP8 intra frame. There are some obvious practical problems with this new image format in comparison to JPEG ; it doesn’t even support all of JPEG’s features, let alone many of the much-wanted features JPEG was missing (alpha channel support, lossless support). It only supports 4:2:0 chroma subsampling, while JPEG can handle 4:2:2 and 4:4:4. Google doesn’t seem interested in adding any of these features either.

  But let’s get to the meat and see how these encoders stack up on compressing still images. As I explained in my original analysis, VP8 has the advantage of H.264′s intra prediction, which is one of the primary reasons why H.264 has such an advantage in intra compression. It only has i4x4 and i16x16 modes, not i8x8, so it’s not quite as fancy as H.264′s, but it comes close.

  The test files are all around 155KB ; download them for the exact filesizes. For all three, I did a binary search of quality levels to get the file sizes close. For x264, I encoded with --tune stillimage --preset placebo. For libvpx, I encoded with --best. For JPEG, I encoded with ffmpeg, then applied jpgcrush, a lossless jpeg compressor. I suspect there are better JPEG encoders out there than ffmpeg ; if you have one, feel free to test it and post the results. The source image is the 200th frame of Parkjoy, from derf’s page (fun fact : this video was shot here ! More info on the video here.).

  Files : (x264 [154KB], vp8 [155KB], jpg [156KB])

  Results (decoded to PNG) : (x264, vp8, jpg)

  This seems rather embarrassing for libvpx. Personally I think VP8 looks by far the worst of the bunch, despite JPEG’s blocking. What’s going on here ? VP8 certainly has better entropy coding than JPEG does (by far !). It has better intra prediction (JPEG has just DC prediction). How could VP8 look worse ? Let’s investigate.

  VP8 uses a 4×4 transform, which tends to blur and lose more detail than JPEG’s 8×8 transform. But that alone certainly isn’t enough to create such a dramatic difference. Let’s investigate a hypothesis — that the problem is that libvpx is optimizing for PSNR and ignoring psychovisual considerations when encoding the image… I’ll encode with --tune psnr --preset placebo in x264, turning off all psy optimizations. 

  Files : (x264, optimized for PSNR [154KB]) [Note for the technical people : because adaptive quantization is off, to get the filesize on target I had to use a CQM here.]

  Results (decoded to PNG) : (x264, optimized for PSNR)

  What a blur ! Only somewhat better than VP8, and still worse than JPEG. And that’s using the same encoder and the same level of analysis — the only thing done differently is dropping the psy optimizations. Thus we come back to the conclusion I’ve made over and over on this blog — the encoder matters more than the video format, and good psy optimizations are more important than anything else for compression. libvpx, a much more powerful encoder than ffmpeg’s jpeg encoder, loses because it tries too hard to optimize for PSNR.

  These results raise an obvious question — is Google nuts ? I could understand the push for “WebP” if it was better than JPEG. And sure, technically as a file format it is, and an encoder could be made for it that’s better than JPEG. But note the word “could”. Why announce it now when libvpx is still such an awful encoder ? You’d have to be nuts to try to replace JPEG with this blurry mess as-is. Now, I don’t expect libvpx to be able to compete with x264, the best encoder in the world — but surely it should be able to beat an image format released in 1992 ?

  Earth to Google : make the encoder good first, then promote it as better than the alternatives. The reverse doesn’t work quite as well.

  Addendum (added Oct. 2, 03:51) :

  maikmerten gave me a Theora-encoded image to compare as well. Here’s the PNG and the source (155KB). And yes, that’s Theora 1.2 (Ptalarbvorm) beating VP8 handily. Now that is embarassing. Guess what the main new feature of Ptalarbvorm is ? Psy optimizations…

  Addendum (added Apr. 20, 23:33) :

  There’s a new webp encoder out, written from scratch by skal (available in libwebp). It’s significantly better than libvpx — not like that says much — but it should probably beat JPEG much more readily now. The encoder design is rather unique — it basically uses K-means for a large part of the encoding process. It still loses to x264, but that was expected.

  [155KB]