Digitalwerks » x264 http://www.digitalwerks.org Complex issues, efficient discussion. Fri, 11 Feb 2011 04:51:32 +0000 en hourly 1 MKV’s on Blu-Ray Players http://www.digitalwerks.org/2009/04/27/mkvs-on-blu-ray-players/ http://www.digitalwerks.org/2009/04/27/mkvs-on-blu-ray-players/#comments Mon, 27 Apr 2009 19:56:08 +0000 kosmonaut http://www.digitalwerks.org/?p=338

The fight for dominance in the living room continues apace, with a large number of contenders and no clear cut leader at the moment.  Everybody wants their device to be the central hub for delivering content, both local and Internet-based to the masses on their couches.  The major players remain:

  • Cable Set-Top-Boxes
  • Gaming systems (PS3, Xbox 360)
  • Stand alone devices (Roku, Tivo, AppleTV, etc.)
  • Digital Media Adaptors (Popcorn Hour, DLNA devices, etc.)
  • Networked HDTV’s (DLNA, widgets, etc.)
  • Blu-Ray devices with extended functionality
  • Home theater PC’s (Windows Media Center, Mac Mini w/ Boxee, etc.)

All of the above have both positive and negative aspects, and none of them have really taken off enough to be considered a mainstream success, at least in the context of advanced content delivery. Cost and complexity are probably the biggest hurdles to wide acceptance for all of them, but we are seeing some interesting moves to increase attractiveness to consumers.  

On Saturday, Richard Lawler on EngadgetHD reported that the first JVC Blu-Ray player to hit the US will be the first such device to support the playback of Matroska (.mkv) files.  The move to support codecs and file formats beyond those required for the official player specifications developed on standard definition DVD players in 2003 and then really took off with the growth of DivX certification thereafter.  The move by JVC is interesting for a few reasons.  First, the Matroska format is not officially backed by any legitimate content creators, it is wholly used for the distribution of Blu-Ray rips among file-sharing communities.  Generally speaking Hollywood Blu-Ray rips at 1920x1080p are encoded in h.264 or VC-1 using the .mts transport stream format, with sizes ranging from 20GB to 50GB’s.  After being cracked, these discs get re-compressed using the open source x264 implementation of h.264 to either 9GB at 1920×1080 or 4.5GB for 1280×720.  The 5.1 DTS or AC3 soundtrack along with subtitles are included as well depending on the particular film.  Without knowing the specifics of the JVC player’s capabilities it’s impossible to say for sure that it could play back these files, but from a horsepower perspective it should not be difficult, though, for the bitrates of the rips is significantly lower than those of the original discs.  It would be good to know as well if the JVC player can play back .mkv’s from burned Blu-Ray discs, from DVD-R’s, from USB devices or from networked sources.  I would suspect yes to all, but until some one gives it a thorough review of the player it’s impossible to know.

Clearly JVC is trying to differentiate themselves from their Blu-Ray player competitors by appealing to a subset of consumers that are downloading Blu-Ray rips but would like to watch them on devices other than their PC’s.  Also interesting is that JVC is not working with DivX to do this, in fact they explicitly say “DivX files” are incompatible.  I wonder if they mean .avi files encoded in DivX or the specific .divx file format?  In any case, this is certainly not a good sign for the success of the DivX Plus/7 hardware certification program, as it was explicitly designed to support playback of .mkv’s on Blu-Ray devices.

From my perspective, I am not sure how successful this particular JVC device will be, or the attempt to increase the functionality of Blu-Ray devices in general (adding Netflix, YouTube, etc.).  Despite the much lauded AACS DRM scheme, Blu-ray rips have been available almost from the first release of Blu-Ray discs, so anybody interested in watching these kinds of files has probably been doing it for quite some time by now, and has their own method of doing so.  Likely that method is watching from an HTPC of some kind.  Once someone connects a PC to their main viewing device, and accepts the cost, complexity and noise issues, going back to a CE device seems like a significant step backwards, in my opinion.  No matter how well JVC (or more likely whomever their ODM is in) implement .mkv playback, or YouTube integration, it is not likely to match the user experience of an HTPC.  That is not to say HTPC’s are generally user friendly, for in fact putting one together is currently far beyond the capabilities of the mainstream, but I suspect things are likely to change in the near future.  Services like Boxee, hardware like the Atom platform from Intel, or the Ion from AMD, the hoped-for improvements from Windows 7 point towards a real opportunity for HTPCs to become far more accepted in mainstream living rooms.  As someone who has used an HTPC for many years, and is currently putting together a second one for the bedroom, I certainly know the difficulties of the process, but that said, I have absolutely no interest in switching to a Blu-Ray player, even with expanded capabilities.  There is no way that a CE device could possibly cover all the things I want to do, all the content I want to watch, all the services I would like to try, at least in comparison to a general purpose PC with a high speed Internet connection.  Maybe if the prices got really, really low ($99 or less) but certainly not at the reported MSRP of $299 for the JVC player.
]]> http://www.digitalwerks.org/2009/04/27/mkvs-on-blu-ray-players/feed/ 4 Video encoding for the Android: Step-by-Step http://www.digitalwerks.org/2009/03/15/video-encoding-for-the-android-step-by-step/ http://www.digitalwerks.org/2009/03/15/video-encoding-for-the-android-step-by-step/#comments Mon, 16 Mar 2009 06:51:45 +0000 kosmonaut http://www.digitalwerks.org/?p=245

I have written a couple of previous posts about my experiences using the T-Mobile HTC G1 Android Google phone, including an in-depth look at how it handles video playback.  As a way to help other G1 users get video on to their phones, I put together this step-by-step guide to using the MeGUI application to encode video into a format that the G1 can play, while retaining as much quality as possible.  Because of the relatively low resolution of G1 compatible video, I have not focused as much on making the files as small in size as possible, but once you’ve mastered the basic steps outlined here, you should not have too much trouble tweaking the process to get smaller sizes if that is of importance to you.  With microSD cards getting cheaper and cheaper, I frankly have not found much need to really optimize encoding for size, but your needs may differ.

Necessary tools:
The first step is to download and install the required software.  This first version of this guide is PC only, but again, it would not take too much effort to replicate the steps shown here on a Mac of Linux computer.  If anybody has specific questions about those alternatives, please just drop me a line.  

MeGUI is a free, open source encoding application available for download from Sourceforge.  It is quite mature and is very powerful, although we will only be scratching the surface of its capabilities here.  
Also necessary is the AAC encoding executable from Nero.  The AAC encoder is also free, but after download, make sure to note where on your system the application gets installed.  Later on, you will need to show MeGUI where it is located.
After basic installation of MeGUI and neroaacenc.exe, you will want to update MeGUI using the built in update function.  The application actually bundles a number of other apps, all of which are updated quite frequently, so it is always worth your while to make sure everything is as current as possible.  

After updating, also check to ensure that the neroaacenc executable is properly installed.

Next, you will want to download my Android-G1 encoding profile.  Once downloaded, you will import it to MeGUI to make it available for use.

Step 1: AVS Script
So, you should be all set up by this point, and ready to actually get to the task of encoding.  MeGUI is a bit different from many other video encoding applications, in that it requires you to create an AVISynth file, or AVS script.  It’s not as complicated as it sounds, but it is an extra step.  Luckily, MeGUI takes the hard part out of it by providing an interface for inputing the necessary information into your script under the Tools menu.



The key items to pay attention to for Android encodes are resize and crop. Set the first number (width) of resize to 480, and then let the program automatically set the resulting width while maintaining the proper aspect ratio. Then click the “crop” button and hit auto-crop. If there are any black borders to remove (which is very important when screen real estate is at a premium as on the Android) the program will figure it out automatically.
Once finished with resize and crop settings you will click “Save” which should pop up a preview window of what the new video will look like, and take you back to the original MeGUI interface page.

Step 1: Prepping the encode
After creating your AVS script, and assuming you have the G1-Android preset properly imported, then the only setting you need to look at now is output format, which needs to be set to “MP4.” If so, hit “Enqueue.”
At this stage you can also set up the audio encoding. Choose the original souce file for input, select the Nero AAC: NDAAC-LC 96kbps preset, make sure the audio output format is MP4-AAC, select a new name for the audio output file, and hit “Enqueue.”

Step 2: Encoding
Click the Queue tab, see that your audio and video encoding jobs are lined up properly, and hit “Start.”
One progress on both audio and video is finished, open up the Muxing/Muxing MP4 tool, and queue up the process of bringing together the audio and video streams into one MP4 file.

Once that job is finished, you should be all set to transfer the completed file to your Android phone. If you have a Video Player application installed from the Android Marketplace, you should be now watching high quality video on your Android.

MPEG-2 Sources
For MPEG-2 sources, there are additional steps. The first is the DG Indexer -> D2V creator.

Run your source file through the D2V creator. (You will have to Queue the process up and run it).

Afterwards you will have an audio stream for later encoding, while for video the AVS script creator will pop up using the D2V file you’ve created. For MPEG-2 sources you will most likely want to de-interlace the video, so that will be set at this stage as well.
Go to the Filters tab of the AVS script creator and click “Analyze.”

It will take a little while for the analysis process to complete, but at the end you if you are in need of it, the “Deinterlace button” will be automatically clicked for you. At this point you can go back to the main AVS script creator page and move ahead in the encoding process normally, as described above. When it comes time to set the encoding processes from the main MeGUI interface, choose the audio stream that was established by the D2V creation process to be encoded into AAC audio.

]]> http://www.digitalwerks.org/2009/03/15/video-encoding-for-the-android-step-by-step/feed/ 1 Video on the Android G1 http://www.digitalwerks.org/2009/02/27/video-on-the-android-g1/ http://www.digitalwerks.org/2009/02/27/video-on-the-android-g1/#comments Fri, 27 Feb 2009 09:07:41 +0000 kosmonaut http://www.digitalwerks.org/?p=218 far dorkier than Data ever was!

As a follow up to my previous posts about the G1 Android phone from T-Mobile (and Google!), and from a personal interest, I wanted to gather as much information about the phone’s video capabilities as I could.  In general, there has not been much information available about the detailed video specifications of the G1, which has proven somewhat frustrating to those people interested in using it as a portable viewing device.

At the basic level, the G1 can decode the h.264 codec in .mp4 and .m4v container formats.  If you are familiar with iPod/iPhone video capabilities, you should recognize those specs, as they are pretty close to what Apple is using.  And that is likely not a coincidence, as my guess is that video was somewhat neglected in the G1′s development and choices were defaulted to an already established format.  I assume that video as a category was overlooked for a number of reasons: unlike the iPhone with iTunes, there is no established commercial entity selling video content for the G1.  But probably more important is the fact that Android is a platform targeted for a number of different hardware devices, and not just phones but MID’s, netbooks, etc. It probably did not make a lot of sense for the Android developers at Google to put a lot of time into a video format that may only be specific one device, the G1.  And from the other direction, the actual manufacturer of the phone, HTC, I suspect probably handed everything over to Google, since video can be something of a headache for phone makers without a lot of expertise in this area.  In other words, G1 users were kind of left on their own when it comes to video, something pretty clearly shown by the fact that the phone did not even come with a native video player application!  A couple popped up almost immediately, but they are not particularly sophisticated or polished.
 
So, reaching back to my days with the DivX Certification lab, I devised to determine what, in fact, the video capabilities of the phone actually are and then to come up with an encoding profile that would take the most advantage of what the G1 offers.  I created dozens of test clips with a wide variety of encoding parameters and tried to play them on the phone.  Once I had learned what the G1 can and cannot play, I started looking at which options provided the best compression compromise between size of file, quality of image, and speed of encoding process.  Dozens of PSNR and SSIM tests later, I had some preliminary answers.  Usually, a compressionist can only have two of the three (quality, size, and speed) but must make sacrifices on the third.  In my case, I favored quality and speed, without too much attention paid to size since with the G1 we are not limited by a specific medium size (i.e. we are not trying fit a file on a 700MB CD or something similar to that.  A G1 user can fit however much video they want on to whichever size microSD card they have.  I recently purchased an 8GB card from Fry’s for less than $20, which provides a great deal of space and does not make size concerns primary for me.  Your mileage may vary, of course.
 
It turns out that the G1′s capabilities are pretty similar to later generation iPods, iPhones and Zunes.  H.264 video on the G1 needs to conform to the Baseline Profile and the 3.0 Level, which govern some of the impermissible encoding options like CABAC and B-Slices, that are powerful options but also drastically increase the complexity of the file and the power needed to decode the video content. Maybe even more crucially, G1 video has to be follow very strict resolution limits, as no video can be wider than 480 pixels across and no higher than 368 pixels. Bitrate does not appear to be nearly as strict.  I’ve gotten the G1 to play files with surprisingly high bitrates, up to 2000 kbps, but that is generally way overkill for files with sub-SD resolutions.
 
In order to make my findings useful, I created a profile for the encoding application MeGUI, considered to be the pre-eminent solution for high quality encoding of h.264 video (using the amazing x264 implementation) into .mp4′s or .mkv’s (mkv, the matroska container format is the accepted standard for high def x264 video among current file traders but is not currently supported on the G1).  Barring any hidden bugs I’ve missed, my G1-Android profile should become available for MeGUI auto-updates in the future, or you can download and install it yourself right now.  I also checked with the lead developer of x264 to make sure the profile made sense from a compression standpoint, so I am fairly confident in it.  But test it out for yourself and see if it meets your particular needs.  If you are not interested in using MeGUI, you can just read the profile as an XML file and take the encoding settings and apply them manually in whichever application you prefer (Handbrake, Ripbot, etc.).
 
One reminder, when using MeGUI you will need to create an Avisynth script first, in which you will need to re-size the video to  480×368 or below.  You should also crop and de-interlace the video if necessary at that stage. Then MeGUI can use the G1 Android profile to do the actual encoding.
 
You will also notice I did not say much about audio, but that is pretty clear for the G1 encoders should stick with MeGUI’s Nero AAC LC 96 kbps profile.  That will be more than sufficient for portable watching, imo.
]]> http://www.digitalwerks.org/2009/02/27/video-on-the-android-g1/feed/ 6