Dirac is an advanced royalty-free video compression format designed for a wide range of uses, from delivering low-resolution web content to broadcasting HD and beyond, to near-lossless studio editing. The v1.0.0 version was released yesterday, and the new VLC version supports playback of .ts/.drc Dirac files.My Take: Unfortunately, to encode Dirac videos is complicated, as it requires patching of specific versions of FFmpeg, while its Windows splitter files don’t work without additional compilation. To top all this, the sample files on their sourceforge site don’t work with VLC so I have no way to test this codec. As a videographer and as someone deep in all things video-editing, I personally find this whole experience very negative. Why can’t BBC provide us with a simple DLL decoder installer, sample .drc/.ts videos (instead of RGB) that actually work with VLC, a command line or a VfW encoder, or at least ask FFmpeg to include their patches by default since all these years that patches were available? I was waiting for this OSS codec very eagerly after the Theora fiasco, so I am disappointed by the user experience I got today out of it. For me, claiming that something is version 1.0.0 has a specific meaning — and in this case it’s more than just a specification. Update: Video files that work here.
Dirac 1.0.0 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Yes, the dirac research codec is awkward to use. Happily, there is another encoder called Schrodinger, which comes with GStreamer elements which allow all the things you’re after — command line encoding, muxing into Ogg etc. It’s also quite a lot faster than the Dirac research encoder, and is currently at version 1.0.5.
There’s even a (very basic) GUI to encode to the Dirac format using Schroedinger, and it’s been around for over a year. I know, I wrote it.
Edited 2008-09-17 23:47 UTC
Well, looking for this implementation I can only find source code. I don’t think that my Ubuntu’s Gstreamer comes with it, or the command line encoder, and I can’t find any info about your GUI either by searching online.
More over, there is no encoder for Video for Windows, so it’s impossible for me to edit something on Sony Vegas and export to Dirac. When a codec that’s supposed to be so important is released, it better have some Windows encoding support.
And you say that there’s an encoder somewhere. Where can I find docs about how to use it?
The package is gstreamer0.10-schroedinger, or something very similar to that. It’s definitely in Ubuntu Gutsy, though I can’t remember what version. Debian, Fedora, Gentoo etc have the latest version as far as I know.
After installing this, command-line encoding/transcoding can be done via GStreamer’s gst-launch syntax, though I appreciate that this is only “easy” if you already know how gst-launch works.
They do seem to be lacking Windows binaries, which is probably something they should fix. There do seem to be DirectShow filters available though, once you’ve got it compiled.
The wiki on diracvideo.org is the main source of info at the moment it seems. For example,
http://diracvideo.org/wiki/index.php/Schroedinger_Encoder_Parameter…
gives a list of all the different settings for the Schroedinger encoder. There’s also a (somewhat over-complicated IMHO) guide to encoding Big Buck Bunny into Dirac from the source PNGs, at
http://www.diracvideo.org/wiki/index.php/Encode_Big_Buck_Bunny
You did, and I apologise. I thought I’d changed it back quickly enough when I realised my mistake, but apparently not
EDIT: Ach. I meant Ubuntu Hardy, not Gutsy. Or 8.04, anyway. Stupid code names.
Edited 2008-09-18 00:27 UTC
GSt’s encoding syntax is a nightmare, it almost doesn’t make sense. I personally feel more at home with ffmpeg, but mencoder is manageable too if you are willing to spend the time to test stuff.
I have no compiler on Windows, and I have no compiler on ubuntu either (which is the reason why I moved from Arch and Gentoo to Ubuntu: so I won’t have to deal with that anymore.)
What I have, is a perfectly compatible Video for Windows-compliant $500 video editor that I want to use. BBC needs to decide if they want to stay researchers or to offer a production solution. I know that they might be waiting for Adobe or MainConcept or Sony to step up and create these tools, but honestly, with h.264 for delivery and Cineform for intermediate needs this is not realistic. BBC needs to offer the full solution to be relevant in today’s video world.
I saw that and it’s overkill. Plus, I don’t remember the last time Steven Spielberg used… PNGs to create a video. Anyways, there should have been a tutorial about how to use it in ffmpeg which is easier. And if possible, to also offer an ffmpeg binary with dirac compiled in.
He, and other professional cinematographers, probably uses TIFF, Cineon/DPX or OpenEXR sequence files… true standards instead of other formats usually more adopted by the television market… where speed and costs are more important than absolute quality…
Dirac may be useful in the TV market, but hardly on cinema…
But we are some years away from a (real) useful workflow and application compatibility… I hope Dirac will be delivered as a standard codec in desktops by then and maybe a good alternative too the h264 codec in the web.
…but I hope some good, and competitive, performance binaries are available soon… if so and Dirac gets popular soon, maybe hardware acceleration aren’t too far away…
>probably uses TIFF, Cineon/DPX or OpenEXR sequence files
In today’s workflows, unless you do VFX where frame-by-frame lossless images are read/generated by these tools, that is not needed. There are good digital intermediate formats for editing/archiving, like Cineform.
These are not that common in workflows for cinema… Not only to editing frame by frame (like VFX), but for standard color correction tools like Autodesk Lustre (quite popular), cleaning tools, and similar ones… this kind of application is necessary when you target projection quality and dynamic range… The industry usually uses sequence files (be it DPX/Cineon or OpenEXR or even TIFFs…) to these tasks… (with several limitations… TIFFs are usually uncompressed, metadata–like keycodes– is very important to keep, and several other limitation depending of your workflow, printing machine, delivery LUTs or even projector type.)
Also, there’s nothing wrong in generating standard video files from PNG sequences… it’s a well supported format, lossless (8bit per channel only, but lossless…) and easy to deliver to encoding facilities via internet or optical media… some other format or solution may depend proprietary software, incompatible versions or may limit who can encode your work to the delivery format… You may prefer your workflow, but there’s nothing wrong in this PNG one… it may have advantages depending of your needs…
Last time I checked, Spielberg was a producer and a director — not a cinematographer. Huge difference between those three positions.
Edited 2008-09-18 06:38 UTC
We are not new to the concept, thanks. My comment was sarcastic, so there was no reason for you to “explain” to us the differences. We know them.
In the indie world though, a director is usually the person for all jobs though. For example, my online friend Blake shoots, directs and edits his work by himself. And he’s using semi-known actors too, not completely unknowns, and has even two big films on his back. His latest project: http://www.hulu.com/watch/34577/pink-the-series-no-good-deed
Some people like to be involved in the process.
Edited 2008-09-18 06:57 UTC
JrezIN’s comment implies that Spielberg is a cinematographer. It appears that JrezIN didn’t know that there is a dramatic difference between the job of a cinematographer and that of a producer/director.
My response was to JrezIN’s comment.
I’ve been shooting independent films for about 16 years, and I have found that most productions (wisely) employ a separate DP.
It is very tough to direct and DP simultaneously — both positions have to carefully monitor different aspects of the take while the camera is rolling.
Would love to see it, but I don’t want to sit through the ad.
By the way, I enjoy reading your camera blogs. Very informative.
Since PNG is lossless and usually smaller than TGA or TIFF; PNG sequences are quite common when rending an animation sequence from a render farm when the destination format is a video codec that decodes to the standard 8 bit (per channel) color.
Edited 2008-09-18 16:13 UTC
Please be more careful of what you write [you edited that out now]. I DID include the link to Dirac’s site. It’s the first word in the article.
Edited 2008-09-17 23:48 UTC
Basically, as an editor, what I need is this to take the codec seriously:
1. Port the encoder/decoder under Gstreamer, FFmpeg, mencoder with the patches applied by default, and Video for Windows, Quicktime.
2. Support for AVI, MXF, OGG, MKV, TS, MOV, and DRC containers on all of the above apps/architectures (if their architecture allows).
3. A sane GUI for encoder options under VfW (e.g. bitrate, colorspace) and Quicktime (pixel aspect ratio, field order, res, fps, bitrate, etc).
4. A decoder for Quicktime/Windows with an easy installer (encoder’s installer should also include the decoder btw).
Then, this could be useful for me. But not otherwise. Having a 1.0.0 spec, and a third party encoder/decoder that plays with its own rules and doesn’t even provide binaries, doesn’t do it for me. I am not looking into playing with Dirac, I am looking into doing some work.
Dirac works with GStreamer ot of the box. At least on openSUSE. If your distro doesn’t support it, bug your distributor or change the distro.
Dirac has also been ported to DirectShow and/or VfW. Dirac for QT: http://diracvideo.org/wiki/index.php/SchroQT
Edited 2008-09-18 04:29 UTC
On Ubuntu you need to install the gstreamer package, that’s not big deal. But compiling from source ffmpeg or mencoder to get the encoder, is.
Regarding Windows, you don’t get what I am saying. The fact that they have a DirectShow codec means nothing, because they do NOT distribute an installer, they only give you the source code, which for me and 99.9% others is useless as I don’t have any dev tools on Windows.
As for VfW, no, it’s not developed as from what I see — or at least it’s not released.
>Dirac for QT:
No installer. And more importantly, these packages can not be found on their main “download” page. This is a major mistake. People are not into searching endlessly for that stuff. Additionally, there is no quicktime for windows lib.
Edited 2008-09-18 04:32 UTC
Gee, if only I didn’t have to install a different OS just to use a program. If only developers gave more thought to making things modular/pluggable and cross-OS/distro, this kind of crap wouldn’t exist.
if there weren’t a million different linux distributions you might had it your way.
the ability to choose leaves you ironically with nothing.
(to all linux fanboys, feel free to mod me down instead of making a unified packaging system)
Actually I use Novell openSuSE 11.0, with GNOME, and no the sample Dirac videos don’t work at all, GStreamer Schroedinger support needs to be installed and even then, the .ts format is not recognized by Totem, neither even VLC from the official VLC repo……
Oops, I’m sorry. I updated GStreamer from the PackMan repo <http://packman.links2linux.de/>. Use PackMan as well to install VLC. The official repo is updated too seldom.
I tried PackMan in the past but it replaces too many other packages, which got me scared… That was more than a year ago so I’ll try again…
Yes, PackMan replaces packages if you perform a dist-upgrade. PackMan has newer versions of many applications, eg. Brasero, Miro, also GStreamer (with full support for patented codecs), etc.
So far nothing from PackMan broke my installation.
Okay, I enabled the Packman repository, but it doesn’t include a newer version of VLC.
VLC repo has 0.9.2-1.1, Packman has 0.9.2-0.pm.2…
Wow, then after 3 months VLC catched up? The official VLC repo had no updates since June.
Version numbers after the dash sign don’t matter, btw. The last VLC update in PackMan was (in time of writing) 17 hours ago. VLC repo’s codec libraries also sometimes conflict with PackMan’s.
Hmm well, I can’t get VLC to play Dirac either way, however thanks for suggesting Packman, now that I installed some more gstreamer plugins from there Dirac finally works in Totem! (I think gstreamer-fluendo-mpegdemux made it possible to play .ts…)
Strange. I just watched Big Buck Bunny a few days ago with VLC.
You want support for the somewhat obscure AVI container while not caring about ASF, for which at least exists an official spec, and on which most WMV (and hence VC1) are based on? Why is keeping AVI around a desirable option?
Forgive my ignorance, and please correct me if I am mistaken, but there doesn’t appear to be many current codecs that comply with all your conditions (that notwithstanding,I do agree any serious codec should be easily usable)
AVI is pretty popular. ASF, not anymore. It used to.
Look, all I want, is to be able to export from my video editor to it, and know that there’s a decoder for my viewers. Currently, neither the exporting thing, or the decoding thing is taken care of properly.
According to Wikipedia WMV is ASF, so if true I would say it is rather used, if only typically tied to Windows Media codecs. Not that I actually know, though.
I know what you mean, and I do agree. It’s just that not actually all those many codecs were equally appropriate at one time. AVI (or more appropriately, DivX codec contained into it), for example, was a nightmare for Mac users pretty much until Perian, VLC or MPlayer for OS X came by, which is not that too long ago.
Edited 2008-09-18 06:25 UTC
ASF is a container (like AVI, MP4, QuickTime, Matroska, Ogg etc.) WMV is a video format. Those are two different categories.
AVI files do not contain the DivX codec or any other codec. Codec is a software library, while AVI (and ASF MP4 etc.) files contain audio and video streams (typically) compressed with audio and video codecs. That is, A/V streams in some formats, because codecs use formats, usually common standards developed by someone else (for example, the video format that the DivX codec uses is standard MPEG-4 ASP, which means that AVI files containing streams encoded with DivX contain MPEG-4 ASP video).
Furthermore, it’s not AVI’s (or MPEG-4’s or the codec makers’) fault that QuickTime sucks big time. Anyone who uses Apple software for video playback on Mac OS X gets what he/she deserves. It could never play MPEG-4 ASP video properly, and in 2008, it still cannot play H.264 video properly. That does not mean MPEG-4 ASP or H.264 is bad, it just means QuickTime is really impotent (and therefore should be ignored completely when it comes to discussions about A/V format decisions).
Uh… Yes and no. The format being called WMV too does not take out the fact that, obviously, .wmv files must be in a specific container format, and that is what I meant with WMV (files) purportedly being ASF despite their file extension.
OK, my bad. AVI files containing video streams encoded with the DivX codec.
Your answer makes me assume that you speak from technical knowledge of the container specs. I definitely am not versed to that level, so if you would care to elaborate…
It is AVI’s fault though that it has no publicly accessible official specification, and that it is an overly hacked file format, while QuickTime has had one for eons BTW. So spare me the “sucks big time” unless you switch on the pedagogic mode.
Edited 2008-09-19 00:23 UTC
.wmv is just a filename extension, but the container is ASF. That’s what makes people believe WMV and ASF is the same thing. But it isn’t.
The AVI specification has been available for many years. That’s why the format is so popular in so many applications, virtually any playback and editing software on earth supports it. The MPEG-4 video (that is, the thing you put into the AVI files) specification is available, too. Nothing stops Apple from supporting it, except for their own interests. When any single hobbyist can implement it in their software in a couple of weeks (the internet is full of examples), Apple can do it, too.
And what I mean is QuickTime – the Apple playback software (not the container), the player, sucks. It does. It cannot play MPEG-4 video with advanced MPEG-4 features, which makes its users believe that MPEG-4 video (either ASP or H.264) produced with popular video editing/encoding software is broken, or that the applications that created the video are broken. Or that the formats are “bad”, “problematic” etc. The users then demand that the applications should somehow be “fixed” in order for the video to be playable in the feeble QuickTime player, and when it does not happen, they think the software authors are jerks or that the software is unusable “in the real world”. But it’s just Apple’s fault. So until QuickTime can play things all decent (and even half-decent) players can play with no problems whatsoever, it is simply a useless player that should not be taken into account in any serious discussion about multimedia. There are good video players available for Mac OS X, just like for any other common operating system.
What I said, then.
URL, please.
And so then Apple does, natively, since years ago. MPEG-4 video, that is. They just don’t support the AVI container (or more precisely, they did not bother writing an AVI parser, so then 3rd parties did; QuickTime player -not related to QuickTime container- is perfectly compatble with those 3rd party parsers). The QuickTime container, also, can contain MPEG-4 with all its features just fine, without resorting to hacks
And this relates to the topic or my post just how? I thought it was about video formats, their encoders/decoders, and containers.
.
It can, provided you have an appropriate decoder. Apple’s is not an appropriate one for that. Neither is Microsoft’s, by the way, which cannot play MPEG-4 at all, with or without advanced features (since, well, it doesn’t actually even exist). I’d say partially is better than not at all.
Edited 2008-09-19 04:40 UTC
For example:
http://msdn.microsoft.com/en-us/library/ms779636.aspx
http://www.jmcgowan.com/avitech.html#Format (If you scroll down a bit, you can also see that “In addition to the Video for Windows header files, Chapter Four of the Video for Windows Programmer’s Guide, “AVI Files”, gives a detailed specification of the AVI file format.”)
OpenDML (the so called “AVI 2.0”) format specification is available as a PDF:
http://www.the-labs.com/Video/odmlff2-avidef.pdf
And poorly.
Then don’t complain about AVI being not supported. It’s just Apple’s decision to rely on 3rd parties.
So can other containers. The standard MPEG-4 container is MP4 anyway (which, although based on QuickTime, is slightly different, so using QuickTime for MPEG-4 is, in 2008, good only for advertising Apple’s products).
You said: “It’s just that not actually all those many codecs were equally appropriate at one time. AVI (or more appropriately, DivX codec contained into it), for example, was a nightmare for Mac users pretty much”. I say: the fact that Mac users are/were using crippled software does not make any format or codec “inappropriate”. It is their choice. Use crippled software if you wish, but then don’t~A‘^A complain. Good software is available.
Then again, users cannot complain that they use inappropriate software. It is only their decision, for which they have to pay the price.
Well, I’m not sure about that. No support is sometimes better than crippled support which makes users believe the product actually supports it, which in turn makes software that supports it properly look bad because it’s “incompatible” (Internet Explorer is a prime example showing the harmful effects of crippled support).
Red Hat now employs the mind behind theora, xiphmont who has been working on improving the implementation with some solid results.
http://lwn.net/Articles/293076/
Firefox is also adding support for it in Firefox 3.1.
http://lwn.net/Articles/292939/
With a few hundred million users for Firefox alone, this is not something you can write off easily.
It’s already in 3.1a2. I’m using it right now, and have tested the video tag support. It works, but is ‘unstable’ when put through some browser use. Hopefully this is fixed when 3.1 comes out.
The idea of a video tag controllable through JavaScript is absolutely brilliant though. I must agree.
Nobody will care about FF’s Theora support, because Theora is an inferior codec. Its quality is just too bad. Dirac is patent-free as well and beats Theora in every aspect. Xiph and Mozilla should embrace Dirac.
The quality is being improved as I already indicated in the earlier post. There is much room for improvement. Refer to the demonstrations that show that. I am pretty sure, Firefox implementing support for it *will* have a major impact. Let’s see. Additional support for Dirac might not be a bad thing either.
Please do not forget about the necessary CPU for these codecs. If I’m not mistaken, Theora is very light, while Dirac needs a bit more calculation power.
Therefore I don’t think one should discard Theora.
Dirac has been successfully demonstrated on mobile phones (of course not with Full HD resolution
) and even with Theora’s improvements, it’s still outdated technology. Theora can’t compete with any modern video codec. Just like plain MP3 can’t be used for really low-bitrate stuff like Speex.
The MPEG word accepted that MPEG-4 AVC is better than MPEG-1. Now it’s time to admit that Dirac is better than Theora.
Kugel is right, it seems that Theora will only be able to be improved to a point and that point will never be able to surpass Dirac, so if Dirac is fundamentally better and has the capability to far surpass Theora, the only reason why you’d want to not completely dump Theora and switch to Dirac is if Theora could play better quality video that was larger space-wise but less CPU-hungry, like was pointed out, for mobile devices for example. Otherwise, what point is there in Theora? At that point you should jump ship.
I agree with Eugenia 100%. Going to all the effort to create a codec and faltering on the last important step. Many have followed the same path…
What’s better: stable codec that 20% of typical users can get going OR
not-so-stable codec that 90% of typical users can use.
I know which one will die a quick death first.
been waiting for this for a long time.
heres hoping that opensuse 11.1 comes out with default support for dirac.
Here’s hoping that YouTube et al integrate some detection which will give Linux users a Theora or Dirac embedded video instead of FLSH.
Probably not Dirac though as they already seem to be having difficulties with CPU power needed to encode videos to MP4… And Dirac takes ten times more…
Just some updates and addons.
Final Dirac spec has been available 9 months or so. This is just a release of reference encoder. Schr~APdinger should be used for practical purposes.
Browsers and video element.
– the whole Gecko-family will support video element as og 1.9.1.x (Firefox 3.1, Seamonkey 2.0 etc)
https://bugzilla.mozilla.org/show_bug.cgi?id=382267
– Theora+Vorbis (in ogg container) rendering will be native, probably soon also Dirac+Vorbis
https://bugzilla.mozilla.org/show_bug.cgi?id=422538
– there also will be support for OS-native backends, i.e. what cannot be render by browser, will be done by backends (GStreamer on Linux, QT on Mac and DirectShow on Windows)
https://bugzilla.mozilla.org/show_bug.cgi?id=422540
Also next Opera will have native rendering of Theora+Vorbis (some nightlies available). And Safari will support the same though it QT backend (if patched correctly).
As mentioned earlier, then OggConvert is perfectly able to encode Dirac+Vorbis in ogg container and Totem plays it pretty fine (generating maybe too high load). And finally there is an updates release available.
http://oggconvert.tristanb.net/
VLC media player’s ogg demuxer is terrible (haven’t tested 0.9.2 yet, but at least in 0.9.2 nightlies and oldstable 0.8.6i it was). And doesn’t seem to play Dirac+Vorbis in ogg container (made by OggConvert).
Already motley video landscape will get a lot more colourful and that’s only good. Finally best solutions will stay.
Edited 2008-09-18 12:39 UTC
What are the experiences with Dirac Pro and VC-2?
Ask British people who watched the Olympics 2008. Dirac Pro was used to transmit HDTV signals from Beijing to the BBC.
Since I didn’t read any disparaging remarks over BBC Beijing coverage I should assume that it’s a success? I don’t value that much.
The stuff that I’ve mentioned is just for consumer level and I’ve not tried pro-stuff.
Just a few other things that haven’t been mentioned yet.
There are a few Dirac sample files at
http://dirac.kw.bbc.co.uk/download/video/maybefinal/
including a rather interesting promotional video presented by that bloke who does Click Online on BBC News. The videos are packed into an MPEG transport stream, and I had to change the extension to “.mpeg” to persuade Totem to play them. Amongst other things, the promotional video talks about how the BBC has already saved millions of pounds by using Dirac to transport HD video over their SD infrastructure (including at Beijing), and how the cinema industry is looking to Dirac for future high-bitrate digital distribution.
Also, something no-one has mentioned yet is Dirac’s ability to do lossless video encoding. As a test, I took the (640*360) source PNGs for Big Buck Bunny and converted them into a raw 4:2:0 YUV video file, which weighed in at 4.6GB. After losslessly encoding using Schroedinger, this was shrunk down to 2.0GB — just 43% of the original size. By comparison, Huffyuv produced a 3.3GB file. Of course, Schro required much more horsepower for both encoding and decoding than Huff, but as an archive format I think it has a lot of potential.
Eugenia, you should really be more clear in your criticisms.
Dirac is in production use at the BBC, one of the largest and most respected broadcasters in the world. By definition, that makes Dirac ready for professional use. And I’ve not seen any extensive marketing by the BBC of this format for use outside the professional broadcast market.
If it doesn’t suit your amateur mtv video productions of local garage bands, then say that rather then implying it isn’t suited for all amateur or especially professional use. And your backhander remarks about png usage also illustrate that fact you are commenting on your own limited usage and workflows rather then “…as someone deep in all things video-editing”.