QueTwo's Blog

thouoghts on telecommunications, programming, education and technology

Tag Archives: Video

Compiling the Apache Flex SDK with IntelliJ

I’ve only been using IntelliJ for a few weeks now, but I love it.  I see myself using this as my primary IDE for all things Apache Flex as time moves forward.

One question that has been asked quite frequently on the Apache Flex Dev mailing list is “How do I compile the Apache Flex SDK with IntelliJ?”  Well, since a picture is worth a thousand words, a video on the subject must be worth… umm.. (11 minute video, at 15 frames a second, times the value of pi… )  9,900,000 words!

Compiling Apache Flex SDK with IntellIJ

  1. Grab the Requirements :
    1. Java JDK 1.5, 1.6 or 1.7
    2. Adobe Open Source Flex SDK 4.6 (needed for the compiler at the time of writing)
    3. IntelliJ with ANT, Flex and Java plugins
  2. Create a new Project
  3. Create a new Java Module.  Name it anything you wish.
  4. Create a new Flex Module within that last Module.  It must be named “frameworks”
  5. Unzip the contents of the Open-Source Flex SDK into your Java Module EXCEPT the frameworks directory.
  6. Check the frameworks directory from the Apache SVN (https://svn.apache.org/repos/asf/incubator/flex/trunk) .  Make sure it ends up in the frameworks directory.
  7. Load up the ANT tab, and add the /frameworks/build_framework.xml  file.
  8. Hit the “Run” icon to start the compile.
  9. Drink a beer, or take a shower — depending on what the clock says.

After about 7 minutes or so (my computer compiles it all in 422 seconds on average), you should have a successful build, and a custom-compiled SDK!

NOTE:  The reason why we created two modules is so that you can create your own branch (or switch to somebody else’s branch) without having a whole lot of heart-ache.  All you would need to do is go to the framework module and change the branch you are checking out from.  This will allow you to create patches and submit them into JIRA against the current “patches” branch, instead of the trunk.

H.264 Being removed from Google’s Chrome Browser

This afternoon Google announced that they were dropping support for the H.264 codec in future releases of their browser, Chrome.  If you want to read more about the announcement, check it out here

Essentially their argument is that they want to support Open-Source.  And there is no better way to support open-source than to include support for the new codec that they just bought (VP8) and announced would be open-source (WebM).  On paper, it sounds great and the world should cheer for them.  I personally support ALL the browsers including support for WebM so at least there is some consistency across the landscape for a single codec.

However, how Google is introducing WebM into their browser is by removing the support for H.264 codec.  For those of you who don’t know what H.264 is, it is by far the most widely supported video codec today — being directly supported by DVD players, Blu-Ray players, video game systems, and more importantly, enterprise video systems. 

Over the last few years we have seen enterprise video make the shift from tape to MPEG-2, to MPEG-4 (H.264) video for recording, editing and storage.  The great thing about the industry was that as time passed more and more devices were getting support for H.264, so there was no need to re-encode your video to support each device under the sun.  It was starting to become a world where we could publish our video in a single format and be able to push it out to a great audience.  Re-encoding video takes time, storage space and typically reduces the quality of the end product.

What is even more unfortunate is that recently we have seen H.264 decoders get moved to hardware on many devices, allowing them to decode high-definition content and display them in full-screen without hitting the processor.  This is starting to allow developers to focus on making more interactive user interfaces and better looking interfaces without worrying about degrading the quality of the video.  A good example of this is the H.264 decoder that is built into the newer Samsung televisions — you can run HD content, as long as you are running H.264 — otherwise you are lucky to see a 640×480 video clip without taxing the processor.   One of the reasons why HD video on the web sucked so bad for Mac based computers was Apple didn’t allow the Flash Player to access the H.264 hardware accelerator.  Newer releases of the Flash Player now support it and HD video is smooth as silk on the web. 

By Google moving to WebM and abandoning H.264 it forces manufactures to reassess their decision to support H.264 in hardware.  It will also force content producers to re-encode their video in yet another format (can you imagine YouTube re-encoding their content into WebM just to support a Chrome users?), and will make the HTML5 video tag to be even harder to work with.  Content producers will need to produce their content in H.264 for Flash, many WebKit browsers, and IE9, WebM for Chrome, and Ogg Theora for Firefox.  The real tricky part right now is there are virtually no commercial products that can encode in all three required formats to date. 

So, if you are looking to support video on the web — what are you to do?  Right now a majority of the users don’t support HTML5 video — but they do support H.264 through the Flash Player.  iPad/iPhone/Android devices support H.264 directly, and embedded systems like the Samsung HDTVs, Sony PS3, etc. all support H.264 encoded video.  The only reason to encode in a different format today is to support Firefox and Chrome users that don’t have the Flash Player installed (less than 1% of all users?).  The recommendation I’m sure will change over the years, but for right now, you still pretty much have a one-codec-meets-most-demands solution that you can count on.

Follow

Get every new post delivered to your Inbox.

Join 29 other followers