Blogging Theora
May. 7th, 2009 12:32 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
xiphmontIt'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.
Re: Problem with older ffmpeg, not ffmpeg2theora
Date: 2009-05-12 08:27 am (UTC)Re: Problem with older ffmpeg, not ffmpeg2theora
Date: 2009-05-12 06:49 pm (UTC)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: Problem with older ffmpeg, not ffmpeg2theora
Date: 2009-06-30 04:00 pm (UTC)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)...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-07-01 12:52 pm (UTC)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 09:02 pm (UTC)Re: Problem with older ffmpeg, not ffmpeg2theora
Date: 2009-06-18 05:49 am (UTC)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 08:42 pm (UTC)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 05:44 pm (UTC)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.