Snow, Dirac, Tarkin, and the future of video codecs

[Tab.]

Also known as happy New Year's motherfuckers.

There's been an increasing trend towards new and different things in the field of video compression as of late, probably because you can only do so much with essentially the same goddamned compression engine for like 15 years, and everyone is getting fucking bored. One of the most well-known of these up-and-comers is WAVELET COMPRESSION. Actually, that term on its own is almost useless. Don't memorize it. The reason it's useless is that there are about fifty million ways of using wavelets, and by the way, all of them have been patented. Seven times.
You may or may not be familiar with JPEG2000, which, if you're not, you haven't necessarily been living under a rock for the last five years, you just haven't been paying attention to obscure and poorly-supported formats created by once-revered standards bodies. That's okay. I forgive you. Either way, JPEG2000 is a relatively new image compression standard, not unlike JPEG (in case the reasoning skill required to deduce that was way beyond your abilities), which uses the DISCRETE WAVELET TRANSFORM with like a 97/53WZQ wavelet to do frequency decorrelation (see: image compression) rather than the DCT that you're all so lovingly familiar with. I think it's the DWT anyway, and I have no fucking clue what those numbers mean. Like I said, there are about a million of those bastards. The point is, wavelets are much better suited for whole-image compression. So, rather than having to break up the image into 8x8 blocks that will result in beatifully not-at-all-suited-for-the-HUMAN-VISUAL-SYSTEM blocking artifacts, it simply uses the whole picture as its "block". Wavelets are actually not as proficient as the DCT at decorellation. Nothing is. The DCT fucking rocks. It is fucking sweet. But really, it sucks. It takes forever to perform on large sets, and its output is always so god damned irrational (literally). It is because of this that the incredible physicists/biologists/scientologists/whoever the fuck actually works on this stuff have brought us the wonderful thing that is known as the integer transform. Oh shit, I mean: the wavelet transform.

Wavelets are cool for a few reasons. Besides the whole not-blocking thing, they also have this nice inherent ability to scale indiscriminately, making them very attractive for streaming over networks where speed tends to vary more heavily than Kerry's foreign policy. Just kidding, Republicans are fucktards. Let's not get off topic.

While being much more suited for streaming and your eyes than block-based transforms, wavelets have other problems to deal with. Those problems are history. We've been building video compression on the same basic engine since MPEG-1 was introduced to the world in all its terrible quality. Ha ha. 1980's. Anyway, wavelet (and any other full-image) transforms don't really lend themselves to the traditional model of block-based motion compensation that makes up the majority of compression with video. This is probably because they are not block-based transforms. With that small dilemma in place, nobody really knows how to apply them to video without rewriting how we think of temporal compression. Nobody has succeeded in rewriting how we think of temporal compression, either. So basically, we're fucked.

Not really. Most wavelet codecs so far have just been using a hybrid wavelet image compression/block-based motion compensation approach. Hey, it's not perfect, but nothing is except God or some rhetorical bullshit like that. Update: God does not exist. The earth is not 6000 years old. We're off subject.

With that said, I'll tell you a secret. A few decent/rising wavelet codecs already exist. Are you excited?


Snow is a freelance wavelet codec engineered primarily by FFMPEG lead developer Michael Niederemasdjkjdkajs. It's still highly developmental, has no guarantees of future compatibility in its current state, and is not really by any means prepared for widespread use. Naturally, it's been added to FFDSHOW. So if you want to try out this gem, grab a recent build from celtic_druid's site, open up VirtualDub, and have at it.

In my experience Snow sucks really badly with anime, but maybe that's just me. If nothing else, it's gotten incredible reviews when used with live-action content. It sucked just as badly with my DV captures, so I guess I just have bad luck. Regardless of this, it sure is a cool codec to play around with. I've been able to get a video composed of like... three blotches of moving color at the lowest quality setting, and that was pretty fucking trippy. Snow has two encoding modes: LOSSLESS, and LOSSY. Those are bold because I'm sure you've never seen them before, and you should become familiar with them because they'll be important later in life. In FFDSHOW, set the quality slider to 100 to enable lossless mode. Some have gotten the best lossless compression of their lives using Snow in this way. In my experience, FFV1 is better. But hey.
Below 100, it's anyone's game. Pick a number you like and see what VDub pukes out. Playing with the Q slider is a good way to get a feel for how different levels of wavelet compression look, in case you love wasting time and don't want to just look up a JPEG/JPEG2000 comparison. Actually, I'll do you a favor. Here's one. Don't let the fact that it sucks discourage you. You'll never know until you try.

All the other options are bullshit. I encourage you to select them at random, and see how long it takes you to produce a garbage video stream.

If you like Snow and want to have a little more fun with it, you may want to try encoding with mencoder, as it offers a bit more control over the settings. Quant(/quality) here can go from something like 0.01 to 255.00, 0.01 being ridiculous, but fun.

For playback, FFDSHOW can handle Snow relatively well in directshow players, though for maximum speed (and you'll need it with Snow) MPlayer can't be beat. Snow has no real intended container, except maybe Nut, but that's not even close to usable. AVI works.


Behind curtain two is the BBC-backed codec of the future, DIRAC. Last I tried, this codec took about ten hours to encode a thirty second clip, was difficult-to-impossible to set up, and was of inferior to Snow in just about every way imaginable. But don't fret, it's destined for greatness. So the BBC hopes, anyway. To encode with it grab a compile, again, from celtic_druid. Follow the instructions carefully, because it's a ridiculously complicated encoding method and there's no fucking way I'm going to try to explain it. You may want to wait until they simplify this before you attempt to use Dirac. Or, if you're cool, you'll fix it yourself. Dirac, like Snow, is opensource.

Playing back Dirac is actually possible, though you may not believe this. Gabest has already written a directshow decoder for raw .drc streams. WHAT A GUY. Be sure to give him a blowjob and five dollars next time you see him on the street.

In the end though I don't really understand Dirac at all, and neither do you. It's cool, nobody gives a shit.


TARKIN is actually useless, but maybe some day it won't be. It's possible that at some point Xiph will actually do something again, but probably not.

HOPE YOU ENJOYED & HAVE FUN KIDS!!!

Also, I thoroughly approve of the new guides.

[Tab.]

Here are the Doom9 discussion threads on Snow and Dirac. They contain useful information, at times.

[Tab.]

Doom9 has updated his mencoder GUI to support Snow. It has an advantage over ffdshow in that the quant range is a full 0.01-255, rather than 0-100. Get it here.

From the readme:

You'll have to copy the latest version of avs2yuv (http://students.washington.edu/lorenm/s ... h/avs2yuv/)
and mencoder (http://celticdruid.no-ip.com/xvid/mplayer/) to the same directory as the GUI.

It's kind of shoddily designed IMO, but I might fix that when he releases the sourcecode.

[Torchlight]

your strange language frightens and confuses me - but i like it!

i have no idea about half the stuff you just said, but it sounds like we can expect some cool stuff in the future thanks for the info!

[sysKin]

I am ... sure (?) .. everyone.. (how do I say that) appreciates (????) this ... informative (omg) thread.

Thanks

Radek

[Zero1]

Just love it when someone who knows what he's talking about takes the time to share the information. Thanks Tab, good job.

Unfortunately the technical stuff is way out of the scope of things for about 95% of the people who visit the forums, but it isn't wasted.


Going back to a more well known codec, XviD. As you may or may not be aware, v1.1 beta is out, and it pretty much rawks apart from the odd bug (as to be expected of beta software)

Give it a go, run into any bugs or ugly bits in the encode, let the team know about it so we can get it fixed quicker.


Now I may just be overanalysing things, but I read this on www.xvid.org

This is XviD 1.1.0-beta1 (let's release before h264 encoders are good enough) release.

So, does this mean that h.264 encoders are now becoming capable enough to do as good a job and/or better than XviD and the XviD development will slow down or stop?


I love XviD, really I do, and I can appreciate the work that's gone into it also.

It would be nice to see XviD evolve into a h.264 codec.



Second thoughts, what do we reckon the life expectancy left on XviD is?

The reason I ask, I was considering getting and
Cheers

[sysKin]

So, does this mean that h.264 encoders are now becoming capable enough to do as good a job and/or better than XviD and the XviD development will slow down or stop?

Yes. Current Ateme's h264 codec is already beter than xvid, and a very early x264 project gives very impressing results as well. H264 is a much more advanced standard and it will beat mpeg-4 asp easly.

As for the second part, XviD was mostly pushed forward by two people (in the last ~2 years). Both of us decided it's pointless to continue - so unless you'll find some new developers, or new interesting ideas for me to explore - yeah, development will stop.

I don't think speed or quality can go much further - and even if it will, x264 can go *much* further with the same effort.

Radek

[Tab.]

There've been plenty of discussions about the practicality of XviD in the face of AVC, and the outcome has continually been that it will always have its place. AVC is a wholly different part of the standard than ASP and its Part 2 kin, developed with different intent. P2 was created with a much broader scope, something that MPEG admits probably doomed it to its slow and shortspread adoption. Hell, we only have a full implementation of two of the nineteen profiles defined for MPEG-4 video. AVC is more concise, intended soley for traditional, low-moderate rate, rectangular video*. Initially, it had only three profiles (extended profiles have been added recently).
XviD is still more than competitive with AVC codecs today, and there is always room for improvement. Outside of that, as I mentioned, XviD doesn't even scratch the surface of MPEG-4 P2. Object-based/arbitrary shape coding, one of the flagships of MPEG-4, hasn't been implemented anywhere yet.
Here is a list of profiles, of which XviD only covers Simple and Advanced Simple. Core, Main, and ACE specifically look like they may be worth looking at. If indeed more developers become interested in XviD, there's plenty for them to experiment with. AVC, on the other hand, is rather clean-cut. I can't imagine it'll be too long before the entirety of the standard finds itself in a good implementation (x264, nero's, or whatever). This alone is enough to conclude that XviD has life in it yet, IMO. And aside from that, ASP will always be much simpler to encode and decode than AVC, and there are a multitude of cases where that's going to be a factor.
In short, don't write off XviD just yet. AVC may be better for the kind of thing we're doing, but it's really a whole different animal.

*AVC is straying more and more from its original purpose, and starting to vaguely resemble P2 in its ridiculous expansiveness.


@sysKin, what ever became of the proposed HVS plugins for XviD 1.x? I still think there's some merit to the region of interest idea. Sorry to hear that there's such a shortage of developers, the only thing that's been keeping me from contributing is a definite lack of knowledge of C and a definite lack of time. Should have enough of the latter to satisfy the former once graduation rolls around at the end of this semester, so we'll see what happens after that.

[Zero1]

Tab raised an interesting point, the adoption of the .mp4 container (not sure if others would be useable) and H.264 together.

Now it's all well and good for people like us who have half a clue about these things, but your normal person (particularly noobs) moving on to new codecs is troublesome enough.

We've all seen it, posts on forums saying that they've downloaded a video and they get sound and no video, then someone will reply (and for simplicity's sake mention the most easilly available) ie, download DivX and/or XviD. Generally the reply to that would be, 'what is an XviD?". So ends another pointless thread on the internet.

But moving to .mp4 at the same time, well I can imagine all the distressed noobs already. "I downloaded this fansub, but it's .mp4, does this mean it's only the sound? How do I play it?"

You still get threads about how to play .mkv and .ogg. I swear people need to google.

Well to be honest, I don't even know what I'd use for mp4 playback, I'd like something that would allow .mp4 playback in Windows Media Player 9 (yeah, I know there is better and the such, but I like it and it does the job)

AVI is a damn stubborn format, it's been around bloody ages, and many people including myself are pleased at the support for avi such as great apps like VirtualDub.

I was thinking a while ago, when Microsoft releases an OS with out of the box .mp4 playback instead of people having to go searching for splitters and codecs etc. that is when H.264 will take over.

I'd gladly move to H.264 now if as you guys tell me is already better than XviD, but I'd like for people to play back my AMVs with relatively no hassle, at the most having to install 1 video codec.

Heck, I encoded one of my videos with a feature that wasn't supported in the older DivX versions (I think it might have been GMC) and a lot of people reported back saying my file was corrupt etc. because DivX wasn't decoding it correctly.

Getting them to uninstall old XviD versions through the add/remove programs app and installing a new version was a huge hassle for some people, someone once said something along the lines of, "If people are so stupid not to be able to install XviD, then they don't deserve to see my videos"

In fact, I think it may have been Tab.


I'll bet there are a great many users like me who want a standalone splitter and codecs. I like control over what I install and I can't stand intrusive software like 3ivx which installs a whole array of crap and messes with the filetype associations. God that really pisses me off.

[Zero1]

We've all seen it, posts on forums saying that they've downloaded a video and they get sound and no video, then someone will reply (and for simplicity's sake mention the most easilly available) ie, download DivX and/or XviD. Generally the reply to that would be, 'what is an XviD?". So ends another pointless thread on the internet.

Oh fucking snap