xiphmont: (Default)
[personal profile] xiphmont

It's time for the latest Thusnelda encoder project update summary!

Although I haven't gotten much time to dive back into Thusnelda coding myself, Tim Terriberry, Greg Maxwell and others have continued the work along at a merry pace. In the past few weeks, they've finally replaced the leaky fDCT from the original VP3 and begun work on adjusting the main quantization matrices and, hopefully soon, adaptive quantization. These improvements all improve fine detail rendering and, somewhat unexpectedly, improve gradient rendering as well:

The screen caps above were produced by Theora 1.0 on the left and an experimental version of Thusnelda with early quant matrix optimization work in addition to the new fDCT on the right. Both clips were encoded in constant-quantizer mode and equal bitrates.

Other improvements, more details and the full update report here.

Date: 2009-05-07 06:48 pm (UTC)
From: (Anonymous)
Awesome!

Date: 2009-05-07 09:54 pm (UTC)
From: [identity profile] zkzkz.livejournal.com
like night and day. hardly even looks like the same movie

Date: 2009-05-08 12:14 am (UTC)
From: (Anonymous)
Something really must be done with ffmpeg2theora, that doesn't show the work theora has the format has progressed in xiph. And as you noted, it tends to be the one of the encoders/decoders that is reviewed... it doesn't show the full potential of the format.

Problem with older ffmpeg, not ffmpeg2theora

Date: 2009-05-08 09:54 am (UTC)
From: (Anonymous)
According to the linked article, it's not ffmpeg2theora that's the problem. It's only when it's linked to an older version of ffmpeg that the problem exists. So using an up-to-date ffmpeg2theora should be fine, and using any frontend that relies on an old version of ffmpeg will exhibit this same poor quality. Exactly how old does a version of ffmpeg have to be to cause trouble? Well that's a good question.

Vorbis ?

Date: 2009-05-12 08:23 am (UTC)
From: (Anonymous)
What about the vorbis improvements made by aoTuV http://www.geocities.jp/aoyoume/aotuv/ ?

Will they be included in Xiph.org vorbis? It's sad that most wikipedia audio/video use the standard libvorbis wich has lower quality than aoTuV, which it's used only by few people (most linux distributions ship official Xiph.org libvorbis).

Re: Problem with older ffmpeg, not ffmpeg2theora

Date: 2009-05-12 08:27 am (UTC)
From: (Anonymous)
Another bad things is that ffmpeg has its own vorbis encoder, which has a lower quality than xiph.org encoder (not to speak the aoTuV encoder). Would be nice if ffmpeg drops its encoder if favour of the xiph.org (or aoTuV) one, the license is also compatible.

Re: Problem with older ffmpeg, not ffmpeg2theora

Date: 2009-05-12 06:49 pm (UTC)
From: [identity profile] xiphmont.livejournal.com
...and their own Ogg implementation, also broken in a few ways.

Ffmpeg wants to have genetically independent implementations of the various codecs/containers so that they're not beholden to other projects whims or bugs. That a noble goal. But given the trouble they're having producing independent versions of any great quality.... yeah.

Re: Vorbis ?

Date: 2009-05-12 06:50 pm (UTC)
From: [identity profile] xiphmont.livejournal.com
Eventually. We're finishing a bugfix release of libvorbis now, and improvements will be the release after.

Re: Vorbis ?

Date: 2009-05-13 10:03 pm (UTC)
From: [identity profile] nullc.livejournal.com
FWIW— Virtually none of the audio/video on Wikipedia has a low enough audio bitrate for the AoTUV improvements to shine.

(Not that merging it isn't good…)

Re: Vorbis ?

Date: 2009-05-14 10:43 am (UTC)
From: (Anonymous)
According to many listening tests (see this page for a summary: http://wiki.xiph.org/index.php/VorbisEncoders ) the aoTuV libvorbis has a better quality than official libvorbis with most audio rates.

Re: Problem with older ffmpeg, not ffmpeg2theora

Date: 2009-06-18 05:49 am (UTC)
From: (Anonymous)
The source for libavcodec, with support for hundreds of audio and video codecs, is about 25MBs. libvorbis, and theora are each ~6MBs on their own.

Fat chance ffmpeg is going to accept a 50% increase in their code-size for one nominally popular set of codecs. Let alone all the maintenance issues. And how about performance?

Re: Problem with older ffmpeg, not ffmpeg2theora

Date: 2009-06-30 04:00 pm (UTC)
From: (Anonymous)
> But given the trouble they're having producing independent versions of any great quality

Nice trolling you've got there. ffmpeg's Vorbis decoding implementation is spec-compliant (less than 1 stddev compared to libvorbis, over 98 PSNR - in fact, it helped detect some floor0 regressions introduced in libvorbis) and significantly faster and smaller. I've already seen several projects (who could afford the LGPL license) switch to it.

ffmpeg's video decoders for formats that are actually used (MPEG4 ASP & AVC for example) are quite world-class too, with exact decoding (in the case of ASP it even tries to use the same DTC as the encoder to avoid drift) and excellent speed (the ASP decoder is the fastest bar none, trashing XviD's, the AVC one is within 5% of the fastest ones).

Its code quality speaks for itself too. So yeah. The audio encoders for modern formats aren't really good, and the encoders in general don't get much attention (yet several of them still defeat Thusnelda in PSNR, and no, it doesn't have an AVC encoder, so there.)

Now, the thing I really wanted to ask. Doesn't changing the DCT change the Theora spec? IIRC the transform was explicitly specified, and if I understand this change correctly, this is not something that is specified in the bitstream headers or anything.

Re: Problem with older ffmpeg, not ffmpeg2theora

Date: 2009-06-30 08:26 pm (UTC)
From: [identity profile] xiphmont.livejournal.com

...then why do we have so much trouble with it? Why does the demuxing have sync issues? Why can't it seek? Why can't it chain? Why does the muxing produce invalid files? Why is the built in vid output broken half the time? Why is the clipping rectangle wrong? The list goes on. And when we report problems, submit patches, we're told that there's nothing wrong (just like you've done). I trust ffmpeg about as far as I can throw it (despite using it practically every day, along with mplayer).

Frankly, I don't care about your 'world class' h264 support here. We're talking about Ogg, Vorbis and Theora. Great h264 doesn't fix bugs in Ogg.

As for the DCT, there's more information on the demo7 page (http://web.mit.edu/xiphmont/Public/theora/demo7.html).

Re: Problem with older ffmpeg, not ffmpeg2theora

Date: 2009-06-30 08:42 pm (UTC)
From: [identity profile] xiphmont.livejournal.com
uhhh... if you're counting the configure scripts, I can't take the argument seriously. They're most of the size of any project that uses autofoo.

Compiled size would be a more accurate judge of what actually is 'getting used'. libvorbis: 210kB (AMD64). libtheora: 320kB.

Secondly, just like I said, the philosophical decision to implement their own is fine. The problem is they've done it haphazardly and show no interest in fixing bugs or maintaining the result.

I just came back from OVC where the ffmpeg people are growing a sizable body of users who would like to lynch them because they thought ffmpeg was official Ogg support and they've never gotten good results from it. Most of our advocacy at shows in the past year has been 'Oh, you're using ffmpeg. Let us show you some other tools that work properly'. ffmpeg has done as much to sabotage Ogg's reputation as Apple + Nokia combined. I'm betting that a few ffmpeg devs will read that and cheer--- and that's just indescribably sad.

Re: Problem with older ffmpeg, not ffmpeg2theora

Date: 2009-07-01 12:52 pm (UTC)
From: (Anonymous)
Well, sorry about the imflamatory tone, but "the trouble they're having producing independent versions of any great quality" is going a bit overboard. The ogg de/muxers might be in bad shape, I wouldn't know (but I do know a few Ogg+Vorvis+Theora files I tested tend to play just fine.)

The inability to chain is a feature though :)

I've read the demo7 thing before but it doesn't answer my question. In the spec, section 7.9.3, the iDCT is specified, and it says "A compliant decoder MUST use the exact implementation of the inverse DCT defined in this specification."

So my question is whether improving the DCT implies changing the format, having to update the spec, and causing old files to play sightly differently (unless the decoder detects the encoder version and uses the same DCT).

It's not a big deal, I'm just curious.

Re: Problem with older ffmpeg, not ffmpeg2theora

Date: 2009-07-01 05:44 pm (UTC)
From: (Anonymous)
By that metric, ffmpeg is also sabotaging MPEG4: the defaults are terrible and it's difficult to configure it well (this is both for its own internal ASP encoder, and for libx264 for AVC). Most videos I've seen encoded in these formats suffer quite a bit quality-wise.

OTOH, that "terrible ogg support" is probably the reason Google Chrome supports Theora+Vorbis (in addition to h.264+AAC), and I can tell you both work as well/bad as each other - for instance seeking and A/V sync do work (albeit seeking is a bit slower, it's probably suffering from the "binary search over the network" syndrome, just as Firefox did...)

Frankly this mutual hate seems overblown.

Re: Problem with older ffmpeg, not ffmpeg2theora

Date: 2009-07-01 09:02 pm (UTC)
From: (Anonymous)
Sorry for the spam, I got this wrong. The iDCT the decoder uses is unchanged, the one the encoder uses (the forward one) is the one that has been changed - in fact, to match more closely the inverse one.

Profile

xiphmont: (Default)
xiphmont

Most Popular Tags