FFe: Please sync libtheora 1.1.1-1 from debian (unstable)

I think it's a great idea, this should be done. New release brings much improved quality to encoder and huge speed up to decoder.

Karmic is in FeatureFreeze, so this requires a FFe - see https://wiki.ubuntu.com/FeatureFreeze .

I'd really love to see this in Karmic too. Even though it's a major upgrade it shouldn't be that problematic as the new features are something the applications using the library can but don't have to support. I'm quoting from the release announcement:

"This release is API and ABI compatible with the 1.0 stable release and can be used as a drop in replacement, although some changes are needed to take advantage of new encoder features like two-pass. We recommend upgrading to all our users."

http://www.theora.org/news/

Obviously the old version of the encoder has serious bugs that may cause very poor picture quality or unnecessary double space consumption for all encoded videos.

If someone want to test it a PPA is available here:
https://launchpad.net/~theora/+archive/ppa

I am left dumbfounded. I did some visual quality benchmarks using ffmpeg2theora, and in every case, theora 1.0 *DESTROYED* theora 1.1 in terms of resulting quality. Something is going way wrong here, and I don't know what it is.

I have outputted the results of my benchmarks here for you to see: http://jeff.ecchi.ca/public/theora/

My methodology:
- run ffmpeg2theora 0.23 (with the libtheora0 1.0 package also installed) on various settings
- run it again with the same settings, but with ffmpeg2theora 0.25 and libtheora0 1.1
- compare the look of the image

Results: with the default settings (quality 5), there is no visible difference. But as soon as you get a bit more aggressive by lowering the quality setting to 1 or by using a bitrate encoding method at 1000 or 500 kbps, the results with theora 1.1 are *horrible* compared to what theora 1.0 produces.

Example commands I used:
ffmpeg2theora -v 1 --optimize MVI_0442.MOV
ffmpeg2theora -V 500 --optimize MVI_0442.MOV

Disclaimer: the source clip (MVI_0442.MOV) is sample footage shot by Eugenia for her Canon SX200 IS review on OSNews. I used it simply because it was the best quality clip I had around for doing benchmarks on aesthetics.

I would be glad to be proven wrong, because I still haven't found a way to make theora thusnelda live to the expectations. Among the things I noticed is that the newer ffmpeg2theora/theora produces smaller files *even though I specified the bitrate*, which makes no sense to me, and could explain *part* of the phenomenon. I would be glad to have a *reliable* way of testing.

Hi Jean-François, thanks for the test. You should note at least two things:

1) theora 1.0 was not able to meet the selected birate when using -v option. From http://www.theora.org/news/#libtheora-1.1.0:
"The new rate control module hits its target much more accurately and obeys strict buffer constraints, including dropping frames if necessary. The latter is needed to enable live streaming without disconnecting users or pausing to buffer during sudden motion. Obeying these constraints can yield substantially worse quality than the 1.0 encoder, whose rate control did not obey any such constraints, and often landed only in the vague neighborhood of the desired rate target. The new --soft-target option can relax a few of these constraints, ..."

This mean the the worse quality with 1.1 and -v option is a "feature" and not a "bug". Indeed with 1.0 when you selected -v 500 or -v 1000 the bitrate was almost the same: the encoder was not able to use the 500Kbps bitrate.

You can check the real bitrate with "ogginfo". Of your encoding:
1.0 -v500 is using a 1344,850909 kb/s Average bitrate --> much higher that the 500 requested
1.1 -v500 is using a 561,485643 kb/s Average bitrate --> very similar to the 500 requested

1.0 -v1000 is using a 1411,508464 kb/s Average bitrate --> much higher that the 1000 requested
1.1 -v1000 is using a 997,679248 kb/s Average bitrate --> very similar to the 1000 requested

2) When using the 1.1 theora the -V meaning has changed. You can't compare two files encoded with the same -V value, but you should change the -V value up to getting similar bitrate (or you could use the --two-pass option).

Also remember that the -v option should only be used when you want to get a file with a constant bitrate (e.g. for video streaming over Internet). For best quality you should use -V.

So it would be nice if you can redo the -V test changing the -V value up to getting a similar size.

At least part of the problem is that 1.0 does not respect the bitrate settings at all, and also the quality setting varies wildly. So when you encoded with 1.0, you had double/triple bitrates to what you specified. For 1.1, the new two-pass thing is what really gets the best results. Finally, the test clip is not maybe the best as it's relatively soft and 1.0 had the hardest time with anything crisp.

As you can see from your files sizes, there are really no comparable clips. Ca. 1000 kbps is probably too low for 720p30 video, and all the 1.0 clips use at least 1500kbps instead. I've also understood constant/average bitrate has problems in one-pass mode especially with theora so that it's better to use the quality setting, or the two-pass method only available in 1.1.

Therefore I tried the lowest quality setting with 1.0 which still took relatively a lot, 1325kbps, for video. I then made comparable but theora 1.1 one-pass (-v 4) and two-pass (-V xxx - here bitrate is used since it's target for two-pass encoding). I also made a higher bitrate theora 1.0 encoding, still using a quality mode so that quality wouldn't suffer (not that 1.0 would give much respect to the bitrate setting anyway). And a comparable 1.1 two-pass encoding with lower bitrate:

http://users.tkk.fi/~tajyrink/theora/clips/ (won't be there forever)

I think the biggest difference is between MVI_0442_theora10_2534kbps.ogv and MVI_0442_theora11_2348kbps_twopass.ogv - the latter has much less blockiness/noise and more detail at the same time, quite close to the original. The 1.0 version with higher bitrate is much worse Also, look at the gradients with theora10_1325kbps.ogv compared to MVI_0442_theora11_1279kbps_twopass.ogv and MVI_0442_theora11_1457kbps.ogv. The 1.1 versions have more detail as well, though somewhat more luminance noise since the 1.0 is very smoothed out.

There is something that still eludes me: not only are the video
artifacts insanely more apparent when using the naïve bitrate method,
but some of my benchmarks were also done with the quality encoding
method (-v instead of -V). And when you compare "quality 1 --optimize",
theora 1.0 still destroys 1.1. I understand (and expect) the filesize
should go down when using the same "quality" setting value, but the
visual quality should stay the same, no? And there's those huge
macroblocks and random colors, that doesn't feel normal.

I also added "MVI_0442 theora 1.1 -V 1400 --optimize (match theora 1.0
-V 1000)" to the benchmarks; as the name implies, I wanted to compare to
the "-V 1000" from theora 1.0. The output indeed starts to be similar,
but it still seems as if 1.1 is more block and has weird color noise.

Like Fabio already said quality (-v) setting doesn't compare with theora 1.0 and theora 1.1. You should compare "quality 1 --optimized" with Theora 1.0 to something like "quality 4 (--optimized?) with Theora 1.1, get a file size relatively similar (but higher quality with 1.1).

So in other words, you cannot order 1.0 to produce something like 1.1 does with -v 1 or -v 2, so you should start 1.1 comparison from a -v N value where you get similar filesize to -v 0 or -v 1 with 1.0.

The "1.1 -V 1400 --optimize" is again wrong, as CBR is the wrong choice for anything else than streaming, and you don't get a real CBR with Theora 1.0 -V 1000 (the bitrate varies wildly, similar to using -v setting, but averages eventually on a random value of ca. 1400 in this case). So again you don't have anything produced out of Theora 1.0 you could compare 1.1's "-V xxxx" against.

In summary, Theora 1.0 is broken in many ways and does not do what you order it to do - instead it always varies the bitrate, and gives big file sizes even on the lowest quality settings.

Please force inclusion of Theora 1.1 in Karmic.

Whoops, in all my previous post I swapped -v with -V :\
The recommended method is -v, not -V.

To be honest it doesn't appear to me as something which we need to squeeze into karmic now, we have still quite some number of release critical bugs to fix and the last thing we need now are more regressions. 10.04 will be an LTS and get 1.1, while Karmic is more like a tech preview anyway :-)

How many people tested the packages from the PPA in current karmic? (Just to get a sense of how well this was tested)

I've been using 1.1 from the PPA and testing it in Fedora 12 which flipped the switch very early on. While I only tested playback that is very likely what 99% of people will use it for, for this I have yet to see any issue.

I am also using ffmpeg2theora and libtheora from the PPA and noticed no issues.

Note that 1.1.1 was also released, it only fixes some build issue:
http://www.theora.org/news/

To be able to use the new features (two pass coding, ecc...) ffmpeg2theora 0.25 is also needed (currently 0.24 in karmic).

Setting back to new. Only members of core-dev should confirm sync bugs for main, only members of the release team should confirm FFe bugs.

I tend to agree with Martin that this doesn't seem like something we should push this late. The point that comparisons need to be done based on comparable output file size rather than comparable commandline options is well taken, but what other packages in the archive need to be changed to use correct options? (If we don't know the answer to this already, then yes, this is quite late to be making a change to.)

Generally I think the other packages just start working now that they actually produce something somewhat predictable - in case of using the video quality setting, Theora now produces something more sensible for every kind of content. In case of using the video bitrate setting, Theora now produces what it's asked to provide. Eg. oggconvert simply provides better quality / file size since it uses the quality setting. Pitivi allows either. And I think Thoggen used the quality setting again. But I do understand the concern as well, so however you decide. Also, the programs do not take the full advantage of Theora 1.1 yet since they don't offer the dual-pass option.

Is there any chance that theora developers would eventually join the great cadence of Shuttleworth, and stop delivering one huge improvement every a few years.

Theora 1.1.1 need to be pushed in Karmic because is the open source video codec everyone can use.

We need free formats that can be used with free tools (Ubuntu), and these formats need to be high quality so the people using it don't simply said "it sucks"...

This change "in the last minute", is not going to break the applications quoting something already posted:

"This release is API and ABI compatible with the 1.0 stable release and can be used as a drop in replacement, although some changes are needed to take advantage of new encoder features like two-pass. We recommend upgrading to all our users."

Please sync libtheora 1.1.1

Give my +1

By this point, it's too late to sync for karmic even if we were entirely confident that it wouldn't cause problems for the reverse-dependencies. We are now in critical-bugfix-only mode. Closing this FFe request; 1.1.1 can be pulled into lucid as soon as it opens.