Turns out I had done it before, but I’ve always used the built in Magento Form widgets, never specified a custom .phtml template and actually tried to write the Form code by hand. It’s a little more tricky than I anticipated, but we struggled through it and finally found the catch.

The “catch”, as it were, is that you have to send a hidden “form_key”. This lets Magento know that you are who you say you are and not some spoofer posting malicious code to your backend.  Let’s get started.

Let’s presume that I’ve got a Module Spinonesolutions_Helloworld in it I’m going to make a block:

/app/code/local/Spinonesolutions/Helloworld/Block/Adminhtml/Adminform.php

class Spinonesolutions_Helloworld_Block_Adminhtml_Adminform extends Mage_Adminhtml_Block_Template {
public function __construct() {
    parent::__construct();
    $this->setTemplate('helloworld/form.phtml');
    $this->setFormAction(Mage::getUrl('*/*/new'));
  }
}

It’s easily seen that I’m referencing a .phtml template within my Block for the presentation so let’s make that file as well:

/app/design/adminhtml/default/default/template/hellworld/form.phtml

<form action="<? echo $this->getFormAction(); ?>" method="POST">
<input type="text" id="var1" name="var1" />
<input type="submit" id="submit" name="submit" />
</form>

Lastly we need a Controller to handle the POST and to render our Block:

/app/code/local/Spinonesolutions/Helloworld/controllers/Adminhtml/AdminformController.php

class Spinonesolutions_Helloworld_Adminhtml_AdminformController extends Mage_Adminhtml_Controller_Action {

public function indexAction() {
  $this->loadLayout();
  $block = $this->getLayout()->createBlock('spinonesolutions_helloworld/adminhtml_adminform','admin_form');
  $this->getLayout()->getBlock('content')->append($block);
  $this->renderLayout();
}

public function newAction() {
  die('here I am!');
}
}

OK, that’s it for the architecture.  Let’s wire it all up with some XML in config.xml.  Note this is partial, not a full module definition:

<blocks>
<spinonesolutions_helloworld>
<class>Spinonesolutions_Helloworld_Block</class>
</spinonesolutions_helloworld>
</blocks>
<admin>
<routers>

<adminhtml>
<args>
<modules>
<Spinonesolutions_Helloworld before="Mage_Adminhtml">Spinonesolutions_Helloworld_Adminhtml</Spinonesolutions_Helloworld>
</modules>
</args>
</adminhtml>
</routers>
</admin>

Now, if you visit */admin/adminform/index you should see your super simple Form.  If you hit submit your Form will certainly post, but instead of seeing the die output you’ll be redirected to the Dashboard.  This because we haven’t sent through the authentication required by Magento’s internal routing system that will validate our form.  Let’s change form.phtml so that we can POST successfully.

<form action="<? echo $this->getFormAction(); ?>" method="POST">
<input type="hidden" name="form_key" value="<? echo $this->getFormKey(); ?>" />
<input type="text" id="var1" name="var1" />
<input type="submit" id="submit" name="submit" />
</form>

That’s all there is to it!  Notice the “form_key” hidden variable.  That’s the key to submitting Forms in the Magento admin.

If you try to read a value from a session that has not been set your Drupal user will be logged out.

Example:

sess_write('myValue',TRUE);
echo sess_read('myValue');

OK

echo sess_read('myValue');

NOT OK, user is logged out.

Unlike just about every other article on this site, for this one we’re going to be considering the folder /lib.  Note that this folder is NOT within local, but resident in the root.  As such changes here should be put within their own sub-folders so that they too will survive an upgrade.

It’s really quite easy to create your class, just follow the usual Magento naming conventions. I’m going to create Spinonesolutions_Devel_FirePHP so all I do is create the file: /lib/Spinonesolutions/Devel/FirePHP.php.  Note the similarity to Model naming.

In here I create my class definition:

<?php
class Spinonesolutions_Devel_FirePHP {
  public static function send($var, $label = "DEBUG", $style = "LOG") {
    if (Mage::getIsDeveloperMode()) {
      $request = new Zend_Controller_Request_Http();
      $response = new Zend_Controller_Response_Http();
      $channel = Zend_Wildfire_Channel_HttpHeaders::getInstance();
      $channel->setRequest($request);
      $channel->setResponse($response);

      /*
      * Start output buffering
      */
      ob_start();

      Zend_Wildfire_Plugin_FirePhp::send($var, $label, $style);

      /*
      Style     Description
      LOG     Displays a plain log message
      INFO     Displays an info log message
      WARN     Displays a warning log message
      ERROR     Displays an error log message that increments Firebug?s error count
      TRACE     Displays a log message with an expandable stack trace
      EXCEPTION     Displays an error long message with an expandable stack trace
      TABLE     Displays a log message with an expandable table
      */

      /*
      * Flush log data to browser
      */
      $channel->flush();
      $response->sendHeaders();
    } else {
      return null;
    }
  }
}

Now I can call Spinonesolutions_Devel_FirePHP:send() anywhere in my project.  Sweet!

• uploadify – http://www.uploadify.com
• NIVO Slider – http://nivo.dev7studios.com
• Colortip – http://tutorialzine.com/2010/07/colortips-jquery-tooltip-plugin/
• Spritely – http://spritely.net/
• Masonry – http://desandro.com/resources/jquery-masonry/
• Lettering.JS – http://daverupert.com/2010/09/lettering-js/
• YoxView – http://www.yoxigen.com/yoxview/
• tablesorter – http://tablesorter.com/docs/
• jQueryUI – http://jqueryui.com/
• bassistance.de Validation – http://bassistance.de/jquery-plugins/jquery-plugin-validation/
• FancyBox – http://fancybox.net/

The time delta that you set here will be the minimum delta for your Magento jobs.  IE: If your server’s cron  requests /cron.php every ten minutes and you create a cron job within Magento to run every five minutes, you shouldn’t be surprised to see it running every ten minutes instead of every five.

This won’t be a huge deal for all of you who are administering your own box, but for those of you on a shared box; you’ll likely be limited to a certain minimum delta which you’ll want to be aware of.

Setting up a cron job is actually really simple so lets take a look.  The configuration lives in config.xml, which shouldn’t be a surprise for you module developers.  Using my default example module Spinonesolutions_Helloworld:

/app/code/local/Spinonesolutions/Helloworld/etc/config.xml (partial)

<config>
...
<crontab>
<jobs>
<spinonesolutions_helloworld>
<schedule><cron_expr>*/10 * * * *</cron_expr></schedule>
<run><model>spinonesolutions_helloworld/observer::foobar</model></run>
</spinonesolutions_helloworld>
</jobs>
</crontab>
...
</config>

You can do a Google search on cron schedules in order to figure that part out, it’s outside the scope of this article.  The only other piece that deserves explanation is the static method call between the run tag.  As you’d expect my example call is referencing Spinonesolutions_Helloworld_Model_Observer (/app/code/local/Spinonesolutions/Helloworld/Model/Observer.php). This file doesn’t need to contain anything except for a class definition and a static method.

/app/code/local/Spinonesolutions/Helloworld/Observer.php

<?php
class Spinonesolutions_Helloworld_Model_Observer {
  public static function foobar() {
  }
}

That’s it.  Your static method will now be called on the schedule that you set!

The Varien team has provided ways for your module to manage these stores automatically through the “setup” functionality.  Let’s check it out.

First, you have to let Magento know where your setup code is going to live and what version your module is currently at.  You do this in config.xml. As an example I’ll use a module called Helloworld.  You may recognize this Module from the first article.

/app/code/local/Spinonesolutions/Helloworld/etc/config.xml (partial)

<global>
...
<spinonesolutions_helloworld_setup>
<setup>
<module>Spinonesolutions_Helloworld</module>
</setup>
</spinonesolutions_helloworld_setup>
...
</global>

The setup tag is going to cause Magento to look for a folder within the module called ../sql/setup (/Spinonesolutions/Helloworld/sql/setup). We can change the name of the target folder by changing the tag.  Example: <foobar_setup></foobar_setup> would prompt Magento to look for ../sql/foobar_setup.

The files that fall within this folder need to follow a strict naming scheme:

mysql4-install-{version}.php

mysql4-upgrade-{versionFrom}-{versionTo}.php

What happens is that Magento will run each file, in succession, until it reaches the version number specified in your config.xml.

If you ever need to check to see what version of a module Magento THINKS is installed, browse your database for the table core_resource and scan the codes till you find your module’s code.

If you ever need to have Magento re-run your setup scripts, just remove the entry from core_resource and refresh; the module will then be “reinstalled”.

Now lets take a look at some common things to do in a install/upgrade script.  One of the best resources for figuring this stuff out is Varien’s own codebase.  If you go through some modules in ../core/Mage you’ll find all sorts of great material  to copy into your own module.

Install/Update Wrapper

../sql/setup/mysql4-install-1.0.0.php

<?php
$installer = $this;
/* @var $installer Mage_Core_Model_Resource_Setup */
$connection = $installer->getConnection();
/* @var $connection Varien_Db_Adapter_Pdo_Mysql */

$installer->startSetup();
YOUR CODE GOES HERE

$installer->endSetup();

DataBase Table

$installer->run("
DROP TABLE IF EXISTS {$installer->getTable('spinonesolutions_helloworld/foo')};
CREATE TABLE {$installer->getTable('spinonesolutions_helloworld/foo')} (
id int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
created_at DATETIME NOT NULL,
modified_at DATETIME NOT NULL,
store_id int(5) UNSIGNED NOT NULL,
PRIMARY KEY (id)
)
ENGINE = InnoDB;
");

Not much to explain other than the getTable function.  The parameter refers to config.xml -> global -> models -> {resourceModel} -> entities.

/app/code/local/Spinonesolutions/Helloworld/etc/config.xml (partial)

...
<global>
<models>
...
<spinonesolutions_helloworld>
<class>Spinonesolutions_Helloworld</class>
<resourceModel>spinonesolutions_helloworld_mysql4</resourceModel>
</spinonesolutions_helloworld>
<toms_bluehornet_mysql4>
<class>Spinonesolutions_Helloworld_Model_Mysql4</class>
<entities>
<foo><table>spinonesolutions_helloworld_foo</table></foo>
</entities>
</toms_bluehornet_mysql4>
...
</models>
</global>
...

New Attribute

$installer->addAttribute('catalog_product', 'is_recurring', array(
'group'             => 'Recurring Profile',
'type'              => 'int',
'backend'           => '',
'frontend'          => '',
'label'             => 'Enable Recurring Profile',
'note'              => 'Products with recurring profile participate in catalog as nominal items.',
'input'             => 'select',
'class'             => '',
'source'            => 'eav/entity_attribute_source_boolean',
'global'            => Mage_Catalog_Model_Resource_Eav_Attribute::SCOPE_GLOBAL,
'visible'           => true,
'required'          => false,
'user_defined'      => false,
'default'           => '',
'searchable'        => false,
'filterable'        => false,
'comparable'        => false,
'visible_on_front'  => false,
'unique'            => false,
'apply_to'          => 'simple,virtual',
'is_configurable'   => false
));

Mage_Eav_Model_Entity_Setup

Mage_Eav_Model_Entity_Setup has tons of useful methods to call from your setup script.  The installer itself is an object of type Mage_Catalog_Model_Resource_Eav_Mysql4_Setup which extends Mage_Eav_Model_Entity_Setup thus all the instance methods are available from $this or $installer if you use a wrapper like the one shown above.

Questions and comments welcome!

I ended up writing a super simple module that overrides json_server and corrects the issues.

If you compare the two module’s contents you’ll see I only made a couple of really minor tweaks.

You can download it here.

Install

Download and extract.

Copy the module folder to /sites/all/modules or /sites/{preferred-site}/modules.

Navigate to Site Building -> Modules.

Scroll down to SpinOneSolutions -> JSON Server and Enable.

Hit Save

Developed on Drupal 6.16

Widgets can basically be thought of as easily customizable blocks.  The main difference between standard blocks and widgets is that widgets can be added to CMS pages through the WYSIWYG editor and they can easily accept parameters, also defined through the WYSIWYG.  Thus a non-programmer can add quasi-dynamic content to their CMS pages, hurrah!

You should reference previous articles if you want more details about creating custom Modules and Blocks.

As an example I’m going to build a super simple slideshow widget called “Glider”.  It’s going to be a widget that takes four static block_id(s) as parameters and then displays each static block, in succession, as a slideshow.  If you let your imagination work a little you should be able to see some cool possibilities for such a thing, given that you extend it a little.

I’m using static blocks as the source material for each slide because this would allow a content manager to change out the content of a slide by either editing the static block that contains the content or by editing the block id being passed to the widget.  Either way it’s manageable through the interface.

Also note that the template (presentation layer) is going to be statically defined in this example, but you could easily make that a parameter and create multiple templates for the content manager to choose from!

Finally, I’ve used jQuery to build the actual slideshow.  I’m not going to go into very much detail about the presentation of the slideshow as that’s not really the focus of this article.  Feel free to write in if you want to see the details on how to implement jQuery (or any other script).

First let’s setup the Module:

/app/etc/modules/Spinonesolutions_WidgetGlider.xml

<?xml version="1.0"?>
 <config>
 <modules>
 <Spinonesolutions_WidgetGlider>
   <active>true</active>
   <codePool>local</codePool>
   <depends>
     <Mage_Cms />
   </depends>
 </Spinonesolutions_WidgetGlider>
 </modules>
 </config>

/app/code/local/Spinonesolutions/WidgetGlider/etc/config.xml

<?xml version="1.0"?>
 <config>
 <modules>
 <Spinonesolutions_WidgetGlider>
   <version>1.0.0</version>
 </Spinonesolutions_WidgetGlider>
 </modules>
 <global>
 <blocks>
   <spinonesolutions_widgetglider>
     <class>Spinonesolutions_WidgetGlider_Block</class>
   </spinonesolutions_widgetglider>
 </blocks>
 </global>
 </config>

OK!  The next thing we need to do is define our widget’s interface.  To do that we create a widget.xml file inside our module’s “etc” folder.

/app/code/local/Spinonesolutions/WidgetGlider/etc/widget.xml

<?xml version="1.0"?>
<widgets>
<glider type="spinonesolutions_widgetglider/glider">
   <name>SpinoneSolutions: Glider</name>
   <description>Displays the given HTML Sections in a Glider Slideshow</description>
   <parameters>
     <section1>
       <required>0</required>
       <visible>1</visible>
       <label>Section1</label>
       <type>text</type>
     </section1>
     <section2>
       <required>0</required>
       <visible>1</visible>
       <label>Section2</label>
       <type>text</type>
     </section2>
     <section3>
       <required>0</required>
       <visible>1</visible>
       <label>Section3</label>
       <type>text</type>
     </section3>
     <section4>
       <required>0</required>
       <visible>1</visible>
       <label>Section4</label>
       <type>text</type>
     </section4>
     <template>
       <visible>0</visible>
       <value>widgetglider/banner.phtml</value>
     </template>
   </parameters>
</glider>
</widgets>

You can define any number of widgets in here.  We’re only creating one so I’ve only got a single entry, glider.

The type attribute tells Magento what class to use when instantiating objects.  I’ve set it as spinonesolutions_widgetglider/glider.  If you go back and inspect the config.xml and remember your Magento naming conventions you can surmise that this is going to cause Magento to try and instantiate an object of type Spinonesolutions_WidgetGlider_Block_Glider.  That class doesn’t exist yet so we should create it.

/app/code/local/Spinonesolutions/WidgetGlider/Block/Glider.php

<?php
class Spinonesolutions_WidgetGlider_Block_Glider extends Mage_Core_Block_Template
implements Mage_Widget_Block_Interface {
  const MAXSECTIONS = 4;
  public $sectionArr = array();

  protected function _construct() {
    parent::_construct();
  }

  protected function _toHtml() {
    for ($i=1;$i <= self::MAXSECTIONS;$i++) {
      if ($this->getData("section$i")) {
        $blockHTML = $this->getLayout()->createBlock('cms/block')->setBlockId($this->getData("section$i"))->toHtml();
        $this->sectionArr[$i] = $blockHTML;
      }
    }
    return parent::_toHtml();
  }
}

Let’s inspect the class from top to bottom.  The first thing to notice is that in the declaration it implements Mage_Widget_Block_Interface.  This is a requirement for Widgets.

Notice my constant MAXSECTIONS is set to 4, the same number of section parameters that I defined in widget.xml.  There’s probably some room for improvement here: one could probably figure out the number of parameters dynamically and then remove the constant.  That would make the widget more flexible for future uses.

I call the _construct function so that everything gets setup the way it’s supposed to.

Finally the real work gets done in _toHtml.  This function will be called automagically by Magento when it goes to render this object to the screen.

What I do is load up each block that gets passed into the widget and I stuff it’s HTML into an array element.  This way the widget can render any block, independently, by referencing a key in the array.

It’s not the classes job to do the rendering, that’s left to the presentation layer.  This class is just gathering everything that the presentation layer needs.

To move on with the tutorial we need to look back at our widget declaration in widget.xml.  I’m sure you noticed the last parameter template that I haven’t discussed yet.  Notice that the attribute visible is set to false.  What this parameter does is define the template that our widget is going to use for presentation.  My value is widgetglider/banner.phtml this template doesn’t exist by default so let’s create it.

/app/design/frontend/default/spinonesolutions/template/widgetglider/banner.phtml

<style>
.slideshow {
  position:relative;
}

.slideshow .items div {
  float:left;
  opacity:0.0;
  position:absolute;
  z-index:8;
}

.slideshow .items div.active {
  opacity:1.0;
  z-index:10;
}
</style>

<script>
function slideSwitch() {
  var active = jQuery('.slideshow .items .active');
  // use this to pull the images in the order they appear in the markup
  var next =  jQuery(active).next().length ? jQuery(active).next() : jQuery('.slideshow .items div:first');
  jQuery(next).css({opacity: 0.0})
  .addClass('active')
  .animate({opacity: 1.0}, 1000, function() {
    jQuery(active).removeClass('active');
  });

  jQuery(active).animate({opacity:0.0}, 1000, function(){
  });
}

// execute your scripts when the DOM is ready. this is mostly a good habit
jQuery('document').ready(function() {
  var active = jQuery('.slideshow .items .active');
  if ( active.length == 0 ) {
    active = jQuery('.slideshow .items div:first');
    active.addClass('active').animate({opacity: 1.0}, 1000);
  }

  jQuery(function() {
    setInterval( "slideSwitch()", 5000 );
  });
});
</script>
<div class="slideshow">
  <div class="items">
    <?php foreach($this->sectionArr as $key => $section) { ?>
    <div class="">
      <?php echo $section; ?>
    </div>
    <?php } ?>
  </div>
</div>

The first part of that path is determined by the theme that you’ve set in Configuration.

Inspecting this file the real takeaway is simply the foreach loop.  All it does it loop over the array that was defined in the Business Layer and output the HTML stored in each element.  The template file does all the presentation.

The reason for doing things this way is that one can easily envision some department manager coming to you and asking for another, different, presentation of the same data for some other location of your website.  Since you’ve done a good job of separating your layers all you have to do is make a new .phtml file, and then change the template parameter of your widget.xml file and viola, you’ve got a new presentation of your data.

That does it for the code, all we need to do now is build a little demo using the interface.

Load up the admin and navigate to CMS -> Static Blocks.  Create four static blocks and put an image file into each one.  If you hover your mouse over the row you’ll see the block_id.  Make note of these as you’ll need them for when you create the widget.  Mine are: 6,8,9,10.

Go to CMS -> Pages and create a new CMS page to hold the widget.  Alternatively you could add the widget to a preexisting page.  Switch to the Content Tab.  Click the add Widget icon to add your widget.

Choose your new widget from the dropdown menu.

Fill in the block_id(s) of your static blocks.

Hit Insert.

As a learning exercise click the “Show/HideEditor” button.

Notice what was generated!  It should be pretty similar to what’s in your widget.xml file.  As the smart and curious type the you are also realize that you can change these parameters right here.  Thus the widget.xml file serves a template for your widget, which can be customized later to suit your specific needs.

Ok, save your CMS page.  That’s it!

You can see my demo here.

As always, questions and comments welcomed!

Magento: Enterprise ver 1.6.0.0

block

Description
Outputs a virgin block or loads a defined block.

Parameters
type : Type of block to be created.
id : Id of block to be created.
output : The block instance method to call after creation.  If blank “toHtml()” will be called by default.
<parameter> : Any additional parameters will get key value pairs set in the block’s Data array.

Usage
{{block type=”cms/block”}}
Results in a virgin static block with no data.

{{block id=”myBlock”}}
Results in an instance of myBlock.

{{block id=”myBlock” param1=”foo” param2=”bar”}}
Results in an instance of myBlock with a data array containing key value pairs param1=>”foo” param2=>”bar”.

{{block id=”myBlock” output=”myMethod”}}
Results in an instance of myBlock after it has called member method myMethod.

Note that if you already HAVE a block with this particular ID than it will be loaded.  This is great if you want to include a static block into a CMS page or into another static block!  Just create the block in the CMS section of admin and use the ID that you set.

Any parameter that your block class is sensitive too will work as well.  For example:

{{block id=”myBlock” template=”customfolder/customTemplate.phtml”}}
Results in an instance of myBlock using a custom template.

layout

Description
Outputs the contents of the defined layout.

Parameters
area : The area to load.  If blank the layout’s default area will be used.
handle : The layout handle to load.
<parameter> : Any additional parameters will get key value pairs set in the layout’s Data array.

Usage
{{layout handle=”default”}}
Outputs the default layout handle.

skin

Description
Outputs the url for a resource in the current skin.

Parameters
url : The url to reference within the current skin directory.
<parameter> : Any additional parameters will be passed to the getSkinUrl() method.

Usage
{{skin url=”images/myimage.gif”}}
Outputs: http://www.mydomain.com/skin/frontend/default/default/images/myimage.gif
Note: This assumes the current theme and skin are default.

media

Description
Outputs the Base Media URL.

Parameters
url : The url to prefix with the base media url.

Usage
{{media url=”images/myimage.gif”}}
Outputs: http://www.mydomain.com/media/images/myimage.gif
Note: This assumes Base Media URL is set to http://www.mydomain.com/media (See Admin->Configuration->Web)

store

Description
Outputs the store specific Base URL.

Parameters
direct_url : The url to prefix with the Base URL.  Note this method does NOT assume internal routing.
url : The url to prefix with the Base URL.  Note this method DOES assume internal routing.
<parameter> : Any additional parameters will be passed to the getSkinUrl() method.

Usage
{{store direct_url=”images/myimage.gif”}}
Outputs: http://www.mydomain.com/images/myimage.gif

{{store url=”mens”}}
Outputs: http://www.mydomain.com/mens/

Note that the Base URL can be different in a multistore setup.

htmlescape

Parameters
var : The string to be html escaped.
allowed_tags : Tags to be allowed in the escaped string

Usage
{{htmlescape var=”<a href=’#'>Click Here</a>”}}
Outputs: <a href=’#'>Click Here</a>
Note: The string is escaped so that the browser does not interpret it as HTML, instead it’s displayed as a human readable string.

var

Description
Outputs template variables.

Parameters
variable : The variable being requested

Usage
{{var myVariable}
Outputs: Value stored in myVariable

protocol

Description
Outputs the proper protocol (HTTP or HTTPS) depending on current context OR outputs the desired url based on the current protocol.

Parameters
store : The desired store
url : The url to prefix with the proper protocol
http : The url to use if the current protocol is HTTP
https: The url to use if the current protocol is HTTPS

Usage
{{protocol url=”www.mydomain.com/images/checkout/cart.gif”}}
Outputs: http://www.mydomain.com/images/checkout/cart.gif IF current protocol is HTTP
Outputs: https://www.mydomain.com/images/checkout/cart.gif IF current protocol is HTTPS

{{protocol http=”http://unsecure.mydomain.com/images/checkout/cart.gif” https=”https://secure.mydomain.com/images/checkout/cart.gif”}}
Outputs: http://unsecure.mydomain.com/images/checkout/cart.gif IF current protocol is HTTP
Outputs: https://secure.mydomain.com/images/checkout/cart.gif IF current protocol is HTTPS

All of these directives are defined in Mage/Core/Model/Email/Template/Filter.php should you want to explore them further.

You want to encode video for playback on a PS3 using FFmpeg.

The Solution:

I’ve got a working command line option for you right here.  This is a solution, not the only solution.

My Setup:
Ubuntu 9.10 (Karmic)
libx264 (for encoding H264)
libfaac (for encoding AAC)
mkvtoolnix
ffmpeg
fuppes

I’m also going to assume that your input file is a .mkv containing an H264 video track and an AC-3 audio track.  Most of the time this is fair assumption however, it won’t be correct 100% of the time.

To start, you’re going to need a current build of FFmpeg. It’s been a while since I did the build but I think these were my configuration options.

#cd ~/ffmpeg #make distclean
#svn update #sudo ./configure \
--enable-gpl \
--enable-nonfree \
--enable-postproc \
--enable-pthreads \
--enable-x11grab \
--enable-runtime-cpudetect \
--enable-libdc1394 \
--enable-libfaac \
--enable-libfaad \
--enable-libgsm \
--enable-libmp3lame \
--enable-libtheora \
--enable-libvorbis \
--enable-libx264 \
--enable-libxvid \
--arch=x86_64
#make #sudo checkinstall \
--ftrans=no \
--install=yes \
--pkgname=ffmpeg \
--pkversion "4:0.5.svn'date + %Y%m%d'-12ubuntu3" \
--default

On to what you REALLY wanted to know, here’s my command sequence.

#mkvextract tracks {input-file}.mkv 1:video.h264
#mkvextract tracks {input-file}.mkv 2:audio.ac3
#ffmpeg -i video.h264 -i audio.ac3 \
-vcodec copy \
-acodec libfaac -ab 320k -ac 6 \
-threads 0 -f mp4 \
{output-file-name}.mp4

Let’s break it down line by line so that you can modify it to your needs:
mkvextract tracks {input-file}.mkv 1:video.h264

Extract track 1 to “video.h264″

mkvextract tracks {input-file}.mkv 2:audio.ac3

Extract track 2 to “audio.ac3″

ffmpeg -i video.h264 -i audio.ac3

Input video.h264
Input audio.ac3

-vcodec copy

Copy the video track as is.

-acodec libfaac -ab 320k -ac 6

Transform audio track to AAC using libfaac
Set Audio Bitrate to 320k
Set Audio Channels to 6 (5.1)

-threads 0 -f mp4

Let ffmpeg decide how many threads to use
Set the container format to mp4

{output-file-name}.mp4

Output the file as specified

Checkout the ffmpeg documentation for more information about general options.

I donno about you, but I got tired of typing out three commands for every file I wanted to encode, plus all those options… forget about it!  So I wrote a stupid little shell script to do it for me.

You can download it here: ps3encode.  Just plop it somewhere in your filesystem and then make sure it’s included in your PATH variable and that it has execute permissions.

Usage:

#ps3encode {input-file}.mkv {output-file}.mp4

Questions and comments welcome!