Archive
FFmbc v0.5 Available
It has been announced as available for a while now, but only recently was the download made publically available again for FFmbc 0.5. Lead developer Baptiste is doing a super job moving this project forward, but really needs the support from more media professionals to fully realise the early promise of this open source, broadcast media focused, transcoding solution.
FFmbc 0.5 download available here.
FFmbc 0.5 feature updates include:
- Sync on FFmpeg svn r25202.
- Yadif video deinterlacing filter.
- Overlay video filter.
- Fade video filter.
- HQDn3d video filter.
- Rename ffmpeg binary to ffmbc.
- FFmbc is now GPL only.
- Disable shared libraries.
- Remove -s resizing output cli option, use -vf scale.
- 23.98 and 24 fps support in MXF muxer.
- Mpeg-2 aspect ratio bitstream filter, to change aspect ratio without reencoding.
- Fix an issue with -async and audiomerge.
- Fix an issue with the fade filter.
- Write interlacing information in mov files, fix deinterlacing with quicktime player.
- Correctly support interlaced in yuv4mpeg and quicktime.
- Display interlacing when printing information.
- Fix an issue with resampling and audiomerge.
WebM – The New Open Source Codec on the Block
In August 2009, Google acquired codec developer On2 Technologies for a rumoured $106 million. The flagship On2 codec was VP8 and it was also rumoured at the time that Google may open source this technology in the future, although a number of challenges lay ahead.
Possible Formation of FFmpeg Foundation NGO
Recently posted on the FFmpeg Developers mailing list was a request for comment from Ronald Bultje regarding the intention to form an FFmpeg Foundation (although not using that name).
H264 Video Encoding on Amazon’s EC2
in effect from November 1st 2009.
AWS Debian Squeeze AMI with FFmpeg and X264
Stream #0 has now made available our first Amazon Web Services (AWS) AMI. This is based on Eric Hammond’s 64-bit Squeeze AMI: ami-fcf61595.
The first Stream #0 AMI can be found by looking for the following AMI ID in the AWS Management Console: ami-b535d6dc
The following additions have been made over the base Squeeze build:
- Added Debian Multimedia Repository
- Updated and Upgraded to October 22nd 2009 latest packages
- Build x264 from source. r1301
- Build FFmpeg from source. r20350
FFmpeg has been configured as per the options noted in the How-To here
Ultimately we’re planning to build a few different AMI variations. e.g. Lenny with FFmpeg 0.5 build and x264 from Debian Multimedia Repo as a slightly more stable version of the “Squeeze build everything from source” AMI approach.
The AMI has been made public and Stream0 would really appreciate feedback on this, our first time AMI build.
Everything you need to know about Amazon’s Web Services:
Amazon Web Services
AWS Elastic Compute Cloud (EC2)
AWS Developer Guide
Alestic – listing Debian and Ubuntu AMIs
ec2debian Google Group
How-To Build FFmpeg on Debian Squeeze
It’s been a long time now since I wrote my original How-To for building FFmpeg on Debian. A lot has changed since then, in both the Debian and FFmpeg world, so it’s definitely time for an update.
This tutorial describes how to build x264 and FFmpeg from scratch, on a base Debian Squeeze system. Throughout this tutorial I will be assuming that you are operating as either root or su, or aware of how to use sudo (make sure you’ve added yourself to the /etc/sudoers list).
First, we need to update the sources list. I use pico as my text editor, as I was a long time Pine mail user way back when. Feel free to use vi or emacs if you prefer.
Go to the Debian Multimedia repository site and download the keyring package. Follow the instructions for unpackaging it about half-way down the front page. Now update your sources list:
>pico /etc/apt/sources.list
Add deb http://www.debian-multimedia.org squeeze main on a new line and save the file.
>aptitude update
>aptitude full-upgrade
Now you’re using the latest sources and packages.
Next, install all the additional libraries we’ll need:
>aptitude install install build-essential subversion git-core yasm libgpac-dev libdirac-dev libgsm1-dev libschroedinger-dev libspeex-dev libvorbis-dev libopenjpeg-dev libdc1394-dev libsdl1.2-dev zlib1g-dev texi2html libfaac-dev libfaad-dev libmp3lame-dev libtheora-dev libxvidcore4-dev libopencore-amrnb-dev libopencore-amrwb-dev
Once that has successfully completed, it’s time to grab the latest x264 code:
>git clone git://git.videolan.org/x264.git
>cd x264
>./configure –enable-shared
>make
>make install
Hopefully all is still going well and you encountered no errors so far. Great, let’s grab FFmpeg from Subversion:
>svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
>cd ffmpeg
Now to configure FFmpeg. There’s so many options, it’s sometimes hard to know which ones to choose. The list below is my personal preference, but do try ./configure –help to assist in choosing your own.
>./configure –enable-gpl –enable-postproc –enable-pthreads –enable-libfaac –enable-libfaad –enable-libmp3lame –enable-libtheora –enable-libx264 –enable-shared –enable-nonfree –enable-libvorbis –enable-libgsm –enable-libspeex –enable-libschroedinger –enable-libdirac –enable-avfilter –enable-avfilter-lavf –enable-libdc1394 –enable-libopenjpeg –enable-libopencore-amrnb –enable-libopencore-amrwb –enable-version3
After a successful configuration, all the enabled decoders, encoders and muxers will be displayed. There are some configuration dependencies here. If you don’t –enable-gpl things like postproc will fail at build time. Next….
>make
>make install
“Make” will probably take quite a long time.
Optionally you may like to build qt-faststart as well. If you don’t know what this does, use Google, but in short it arranges atoms in QuickTime header files to allow for progressive download delivery.
>make tools/qt-faststart
If you try to use FFmpeg now, by simply typing “ffmpeg” you are likely to encounter an error regarding shared libraries (we did build FFmpeg with –enable-shared). To fix this we do the following:
>pico /etc/ls.so.conf
Add the line “/usr/local/lib” (without quotes) to this file and then save it. Read more about dynamically linked libraries here, specifically the fourth paragraph to explain what we just did.
>ldconfig
That’s it! Finished. Pretty easy, right? Now you just need to learn how to use FFmpeg, but that’s a topic for another day. Very briefly though, here’s a command line for creating a 2-pass H264 file, at 750kbps and 480×360 resolution, in a mov container, with progressive download enabled.
>ffmpeg -y -i inputfile.mpg -pass 1 -vcodec libx264 -vpre fastfirstpass -s 480×360 -b 750k -bt 750k -threads 0 -f mov -an /dev/null && ffmpeg -deinterlace -y -i inputfile.mpg -pass 2 -acodec libfaac -ab 128k -ac 2 -vcodec libx264 -vpre hq -s 480×360 -b 750k -bt 750k -threads 0 -f mov outputfile.mov
>/tools/qt-faststart outputfile.mov outputfilefast.mov
Applying the HandBrake – Stopping Short of Video Transcoding
Finding a full featured open source video transcoding solution is no easy task. There is of course FFmpeg, which is fantastic and powerful, but one does need to spend a serious amount of time learning the syntax and various options. This is fine if you’re taking one type of input file and creating one type of output file. Easy to script and I’ve seen some really good results, especially using the x264 library. However, trying to find a nice GUI to do the same thing, so far no joy.
I had really hoped HandBrake might be the right tool for the job. It’s been around for a long time now, it’s not just for Mac anymore and there seems to be an active community around it.
The last stable release was almost 10 months ago, but recently an SVN snapshot build was supplied, with some pre-compiled packages to go with it. The usual caveats apply, but the change log provided some tantalising updates, so I decided to try it out.
My home laptop is running Debian Squeeze, but I decided to try the Ubuntu 9.04 GUI package, as I was lazy and didn’t feel like compiling from source. Maybe this was a mistake….. The installation of the deb package went fine. No errors to speak of and a nice little HandBrake icon appeared in my Sound & Video menu. Starting the application also worked flawlessly.
I hadn’t used HandBrake before, so I didn’t know what to expect. On first glance the software appears to be mainly geared towards H.264 transcoding. While this is currently an important video codec, I was hoping for a much wider range of output options. I couldn’t find any.
Fine, let’s stick with H.264. My source file for testing was 4.2GB of DNxHD – a little over 3 minutes of content at 185Mbps. HandBrake uses FFmpeg in the backend to do the transcode heavy lifting. I know FFmpeg supports DNxHD, so I was not expecting any real problems. Unfortunately, my assumption proved to be incorrect.
Selecting the DNxHD file as source, HandBrake scanned the file for a couple of minutes, then stopped. No error message, no warning, just the UI sitting there waiting for the next input. Fortunately, there’s an Activity Window to select and view the command line output. Here’s what I saw…..
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘/home/phillc/Media/South Pacific Avid DNxHD.mov’:
Duration: 00:03:11.12, start: 0.000000, bitrate: 189668 kb/s
Stream #0.0(eng): Video: dnxhd, 1920×1080, PAR 1:1 DAR 16:9, 25 tbr, 25 tbn, 25 tbc
Stream #0.1(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.2(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.3(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.4(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.5(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.6(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.7(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.8(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
[10:14:27] scan: decoding previews for title 1
[10:14:45] scan: could not get a decoded picture
[10:14:58] scan: could not get a decoded picture
[10:15:12] scan: could not get a decoded picture
[10:15:26] scan: could not get a decoded picture
[10:15:40] scan: could not get a decoded picture
[10:15:54] scan: could not get a decoded picture
[10:16:08] scan: could not get a decoded picture
[10:16:23] scan: could not get a decoded picture
[10:16:35] scan: could not get a decoded picture
[10:16:49] scan: could not get a decoded picture
[10:16:49] libhb: scan thread found 0 valid title(s)
What’s it all mean?
It would seem that FFmpeg recognised a valid DNxHD file. It found the video track and 8 tracks of audio, but after this, who knows! Not being able to get a decoded picture is not an error I’ve come across using FFmpeg from the command line before.
EDIT: The root of this problem is actually FFmpeg and not Handbrake. The DNxHD file was 10-bit, but FFmpeg currently only supports 8-bit files of this codec.
That’s as far as I’ve managed to travel in the HandBrake world. I had a look at some of the H.264 file output options, which are comprehensive, but don’t at first glance seem to support the general x264 preset options. HandBrake presets are more geared towards devices – iPod and Apple TV. It appears to be possible to queue multiple jobs using HandBrake, but not set watch folders nor apply rules for output files. E.g Once transcoding is finished, move file to folder X.
HandBrake is probably a good tool for those looking to create web media, from DVD or Camcorder source, but it’s not powerful enough to deal with high end media from the post-production or broadcast domain.
FFmpeg Watermark.c Alpha Channel Patch
Finally, something actually useful on this blog……
This patch means watermark.c now obeys the alpha channel in a PNG file. The -m option is the mode, this must be 2 for alpha blending. The watermark image is applied to the input video and then scaled with the input video to the output video’s dimensions. So best to make an image the same dimensions as the input video, otherwise you’ll get horrible scaling effects.
Usage:
ffmpeg … -vhook ‘/usr/local/lib/vhook/watermark.so -m 2 path/to/image.png’ …
(replace /usr/local/lib/vhook with wherever your watermark.so is.)
Patch is available here – watermark.patch
(Maybe see links below for files on Github instead)
Example screen grab: View image
We’ve also posted back to the FFmpeg Devel mailing list.
Actual credit for this patch goes to my colleague Tim MacFarlane - http://refractalize.blogspot.com/
Tim has also now added the files to Github:
Just the patch here.
The whole of watermark.c with patch applied here.
BBC R&DTV – Creative Commons Tech TV
In an interesting, and to be applauded, move from the BBC, they are now releasing a technology based television programme under a Creative Commons non-commercial attribution licence. R&DTV’s first episode is now available for free download in a number of file formats. There is a full 30 minute version available, a shorter 5 minute highlight version, as well as a complete Asset Bundle, which includes rushes that may not have made it into the final programme versions.
The BBC’s RAD blog has a launch announcement about this, followed up by another post 24 hours later outlining some small fixes.
The programme is PAL 720×576. The aspect appears to be 14:9 anamorphic. The little person inside me who wants the greatest and the best all the time, wonders why the filming wasn’t done in HD, even HDV would do.
I thought the “formats” described on the R&DTV website were a bit vague. What does QuickTime format and Matroska format really mean? Sure, I know about QuickTime and Matroska containers, but this doesn’t say anything about the video and audio essence contained therein. The best way to find out about this is to download each video and let FFmpeg take a look.
QuickTime Format (461.3MB):
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘RDTV_ep1_5mins.mov’:
Duration: 00:05:59.08, start: 0.000000, bitrate: 10777 kb/s
Stream #0.0(eng): Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Stream #0.1(eng): Video: h264, yuv420p, 720×576, 25 tbr, 25 tbn, 50 tbc
That’s H.264 video with PCM audio. Strange they didn’t use AAC audio in a QuickTime file. Looking at that 10Mbps bitrate though, I’m guessing perhaps the BBC is expecting people to use this version for editing. But then why use H.264, rather than something that’s I-Frame only like IMX50? There’s also an Uncompressed version and another QuickTime version, which we’ll come to later.
Matroska Format (28.4MB):
Input #0, matroska, from ‘RDTV_ep1_5mins.mkv’:
Duration: 00:05:59.04, start: 0.000000, bitrate: N/A
Stream #0.0(eng): Video: mpeg4, yuv420p, 720×576 [PAR 1:1 DAR 5:4], 25 tbr, 1k tbn, 25 tbc
Stream #0.1(eng): Audio: aac, 48000 Hz, stereo, s16
Generic mpeg4 video this time (Xvid perhaps) and here’s our AAC audio!
MP4 Format (65.4MB):
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘RDTV_ep1_5mins.mp4′:
Duration: 00:05:59.10, start: 0.000000, bitrate: 1526 kb/s
Stream #0.0(eng): Video: h264, yuv420p, 720×576 [PAR 1:1 DAR 5:4], 25 tbr, 48k tbn, 50 tbc
Stream #0.1(eng): Audio: aac, 48000 Hz, stereo, s16
H.264 video again and AAC audio again. When opening this file with Totem to view, the Comments section says “HandBrake 0.9.3 2008121800″. Nice to know the BBC is using Open Source software for at least some of their video transcoding.
AVI Format (63MB):
Input #0, avi, from ‘RDTV_ep1_5mins.avi’:
Duration: 00:05:59.04, start: 0.000000, bitrate: 1470 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720×576 [PAR 1:1 DAR 5:4], 25 tbr, 25 tbn, 25 tbc
Stream #0.1: Audio: mp3, 48000 Hz, stereo, s16, 160 kb/s
Generic mpeg4 video again, but this time with mp3 audio.
FLV Format (37.4MB)
Input #0, flv, from ‘RDTV_ep1_5mins.flv’:
Duration: 00:05:59.07, start: 0.000000, bitrate: 844 kb/s
Stream #0.0: Video: vp6f, yuv420p, 1024×576, 716 kb/s, 25 tbr, 1k tbn, 1k tbc
Stream #0.1: Audio: mp3, 44100 Hz, stereo, s16, 128 kb/s
VP6 for the video codec and mp3 for the audio. No surprises there then. The bitrate is quite low though for VP6 content, quality will suffer.
Ogg Format:
Input #0, ogg, from ‘RDTV_ep1_5mins.ogg’:
Duration: 00:05:59.08, start: 0.000000, bitrate: 683 kb/s
Stream #0.0: Video: theora, yuv420p, 720×576, PAR 1:1 DAR 5:4, 25 tbr, 25 tbn, 25 tbc
Stream #0.1: Audio: vorbis, 48000 Hz, 5.1, s16, 516 kb/s
Theora for the video and vorbis for the audio, again no surprises there. 5.1 audio is a nice touch though. However, again, the bitrate is very low. Why would the BBC do this? The MP4 version, with H.264 video at a higher bitrate, is going to look far superior.
QuickTime 2 Format (155MB):
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘RDTV_ep1_5mins_2.mov’:
Duration: 00:05:59.08, start: 0.000000, bitrate: 3627 kb/s
Stream #0.0(eng): Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Stream #0.1(eng): Video: h264, yuv420p, 720×576, 25 tbr, 25 tbn, 50 tbc
H.264 video and PCM audio. This second QuickTime file is found only on the FTP site and not linked to directly from the main page. The bitrate is much lower than the previous QuickTime file.
QuickTime Uncompressed Format (7GB):
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘RDTV_ep1_5mins_uncompressed.mov’:
Duration: 00:05:59.08, start: 0.000000, bitrate: 167428 kb/s
Stream #0.0(eng): Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Stream #0.1(eng): Video: rawvideo, uyvy422, 720×576, 25 tbr, 25 tbn, 25 tbc
There we go, raw video in the 4:2:2 colour space at 165Mbps, with PCM audio again. I wonder whether the content was filmed at anywhere near this resolution. Given that the programme is only SD, I’m guessing that the highest quality recording would have been done direct to Digital Betacam, which is only the equivalent of 90Mbps, unless of course the whole thing was done tapeless, which I must admit to doubting.
One last puzzlement is why a Dirac version wasn’t supplied, given that this is the BBC’s own R&D developed codec.
Interview with FFmpeg Developers
Two posts in two days after such a long silence, who’d have thought it…… And again it’s about FFmpeg.
This time Phoronix has posted an interesting interview summary with Diego Biurrun,
Baptiste Coudurier, and Robert Swain, three of the many, but very key, developers working on the FFmpeg project. The interview covers some interesting topics about the future of FFmpeg, the difficulties of maintaining such a large project, managing developer motivation for writing codecs and the limited corporate sponsorship the project has so far received.
I’ve known Baptiste for a year or so, having met at the National Association of Broadcasters (NAB) convention in Las Vegas in April 2008. I’d like to personally thank him for the work he has done on implementing DNxHD in FFmpeg.
Anyway, read the interview and learn something about behind the scenes at FFmpeg.
Also worth a read, which I just found today, is the Phoronix tests on NVIDIAs VDPAU drivers on a cheap chipset and graphics card.
