Getting Theora competitive

[benwaggoner]

Considering what the background areas look like in VC-1 in this sample (e.g. frame 2120), I don't think you should be complaining about Theora's basis patterns ;). This is what happens if you do adaptive deadzone without adaptive quantization.
Well, VC-1 does have a postprocessing filter in most implementations :). It's part of the standard, albeit optional.

Are you thinking of 2126? 2120 looks pretty good in my viewer; it's the flash where things get blocky.

Anyway, I'd agree that low-bitrate differential quantization is the weakest point of the current VC-1 Encoder SDK implementations. I should do a Win7 version as well for comparison, which has a better low bitrate DQuant and motion vector cost mode for grainy regions, but somewhat weaker rate control.

Also, I think a test with fewer scenecuts and less action would be more "real-world"; this test probably has the majority of coded bits in the form of intra blocks, which tends to flatten the difference between encoders somewhat.
Fair enough. It may be too good a stress test in some ways, but it's served me well for years as a good way to flush out codec limitaitons, particularly in rate control.

[Dark Shikari]

Well, VC-1 does have a postprocessing filter in most implementations :). It's part of the standard, albeit optional.

Are you thinking of 2126? 2120 looks pretty good in my viewer; it's the flash where things get blocky.

Anyway, I'd agree that low-bitrate differential quantization is the weakest point of the current VC-1 Encoder SDK implementations. I should do a Win7 version as well for comparison, which has a better low bitrate DQuant and motion vector cost mode for grainy regions, but somewhat weaker rate control.Look at the background in 2120; it's covered with DCT coeffs that were rounded up way too much because the quantizer was too high to represent the fine background detail.

[benwaggoner]

Look at the background in 2120; it's covered with DCT coeffs that were rounded up way too much because the quantizer was too high to represent the fine background detail.
Yeah, it's compressed, but I don't see much basis pattern until six frames later.

...unless we're using tools that count frames differently. IIRC, I encoded as muxed elementary stream, so it should have skip frames and not VFR.

[juGGaKNot]

--first-pass xxx -V 2000 -v 8 -A 192 -o output.ogv x.wav x.
y4m
File x.wav is 16 bit 2 channel 44100 Hz RIFF WAV audio.
File x.y4m is 1184x656 30.00 fps 420 video.
Scanning first pass....
0:00:10.00 audio: 0kbps video: 0kbps
done.


C:\theora>theora.exe --second-pass xxx -V 2000 -v 8 -A 192 -o output.ogv x.wav x
.y4m
File x.wav is 16 bit 2 channel 44100 Hz RIFF WAV audio.
File x.y4m is 1184x656 30.00 fps 420 video.
Compressing....
0:00:10.03 audio: 194kbps video: 7785kbps
done.

The -v overrides -V right ?

Anyway the y4m is 1184x656 30.00 but the output is bad ( only blocks of color )

avs2yuv x.avs -o x.y4m

AVIsource("C:\theora\x.avi")
ConvertToYV12(matrix="PC.601")
LoadPlugin("C:\x264\bin\autocrop.dll")
AutoCrop(0, 16, 16, threshold=0)

Where did i go wrong ?

[benwaggoner]

update the ffmpeg2theora gui

http://www.64k.it/andres/data/autofftheora/AutoFFmpegTheora-v1.4.exe

fixed some audio detection issue
other minor bug fix

Any plans to update this for Theora 1.1?

[buzzqw]

Any plans to update this for Theora 1.1?

yes :)

http://www.64k.it/andres/data/autofftheora/AutoFFmpegTheora-v1.5.exe

BHH

[juGGaKNot]

Any plans to update this for Theora 1.1?

yes :)

http://www.64k.it/andres/data/autofftheora/AutoFFmpegTheora-v1.5.exe

BHH

But did ffmpeg2theora get updated to 1.1 ?

[buzzqw]

i used these builds http://firefogg.org/nightly/

are update very often

BHH

[Midzuki]

But did ffmpeg2theora get updated to 1.1 ?

Apparently the answer is "yes":

ffmpeg2theora 0.24+svn16574 - Xiph.Org libtheora 1.1 20090822 (Thusnelda)

Usage: ffmpeg2theora [options] input

etc

etc

etc

[juGGaKNot]

I see, testing.

autoffmpeg does not seem to "like"

http://firefogg.org/nightly/ffmpeg2theora.exe 25-Sep-2009 13:36 2.0M

LE : had to reload the program, also some check boxes are getting invisible when i move the mouse.

and detect crop crashes it

[buzzqw]

detect crop requires mplayer.exe in the same folder as autoffmpeg2theora

update the build, now you got a tooltip about this

BHH

[hellfred]

But did ffmpeg2theora get updated to 1.1 ?
See here (http://v2v.cc/~j/ffmpeg2theora/):
2009-09-28 new version released - 0.25

* fix input from codecs where width/height is not encoded width/height
* fix a/v sync issues with some mov/mp4 files with strange framerates
* add new option --info outputs json info about source
* frontend mode outputs one json dict per line now
* select video stream if input has more than one video(--videostream N)
* update to ffmpeg trunk and new ffmepg api
* use new libtheora 1.1
* use new libtheora encoding api add new encoding options --soft-target, --buf-delay
* two pass encoding, --two-pass or in two calls with --first-pass and --second-pass

[Kurtnoise]

For those who are interested, here is (http://kurtnoise.free.fr/index.php?dir=misc/&file=ffmpeg2theora-0.25-svn_20090930.7z) a fresh ffmpeg2theora win32 build with avisynth support...

[juGGaKNot]

For those who are interested, here is (http://kurtnoise.free.fr/index.php?dir=misc/&file=ffmpeg2theora-0.25-svn_20090930.7z) a fresh ffmpeg2theora win32 build with avisynth support...

converttoyv24 works ?

le :

ffmpeg2theora.exe -o "Movie.ogv" --first-pass dummy -v 8 -V 5000 --optimize --framerate 30 --keyint 300 --no-oshash --title "asd" --contact "asd" --noaudio "Movie.avs"
[avs @ 0x3ec470]MAX_READ_SIZE:5000000 reached
Input #0, avs, from 'Movie.avs':
Duration: 00:00:16.66, start: 0.000000, bitrate: 0 kb/s
Stream #0.0: Video: YV24 / 0x34325659, 1184x666, 567751 kb/s, 30 tbr, 30 tbn
, 30 tbc
[audio disabled].
swScaler: Unknown format is not supported as input pixel format

No video or audio stream found.

[Kurtnoise]

swScaler: Unknown format is not supported as input pixel format
I think it's pretty clear...seems like libswscale (part of FFmpeg) doesn't support YV24 conversion yet.

[juGGaKNot]

I see, so any way to convert 4:4:4 avi to yuv for theora ? or feed 4:4:4 to theora ?

avs2yuv also does not support it.

[LigH]

For those who are interested, here is (http://kurtnoise.free.fr/index.php?dir=misc/&file=ffmpeg2theora-0.25-svn_20090930.7z) a fresh ffmpeg2theora win32 build with avisynth support...

:thanks:

LigH goes blowing a whistle about that in the german forums...

[Kurtnoise]

I see, so any way to convert 4:4:4 avi to yuv for theora ? or feed 4:4:4 to theora ?
Are you sure that Theora supports this colorspace ?

[PatlaborForce]

9. Support for 4:2:2 and 4:4:4 video

As with adaptive quantization, the specification has always supported the less common 4:2:2 and 4:4:4 chroma subsamplings, useful for high contrast material like screencasts and special effects precursors. The 1.0 decoder supported these subsamplings properly. However, the 1.0 encoder couldn't produce streams in these formats. They are now supported in the 1.1 encoder.

From here (http://www.theora.org/news/).

[juGGaKNot]

9. Support for 4:2:2 and 4:4:4 video
As with adaptive quantization, the specification has always
supported the less common 4:2:2 and 4:4:4 chroma subsamplings, useful for high quality intermediate work in video production. The 1.0 decoder supported these subsamplings properly. However, the 1.0 encoder couldn't produce streams in these formats. They are now supported in the 1.1 encoder.

I don't now for real but they say they do.

[Midzuki]

.EXE from firefogg.org : 2.01 MB

.EXE by Kurtnoise: 20.6 MB

What is the purpose of those extra 18 MB ? :confused:

[juGGaKNot]

ffmpeg, avs.

i guess

[Kurtnoise]

what's the problem w/ file size ? you can compress exe files if you want...personally, I don't care.

I use static libs (vorbisenc, vorbis, theoraenc, theoradec, avdevice, avformat, avcodec, zlib, bz2, pthreads, faad, ws2_32, vfw32, postproc, swscale, avutil, oggkate, kate, ogg, iconv) instead of dynamic ones (dlls in short). That's why you have a such size...

[Kurtnoise]

you're off-topic...:rolleyes:

[PatchWorKs]

you're off-topic...:rolleyes:
Supporting/promoting freedom is never offtopic, IMHO.

[benwaggoner]

Supporting/promoting freedom is never offtopic, IMHO.
...in a thread about either MP3 or freedom, perhaps.

Ogg doesn't even support MP3 as an audio codec.

If I may offer a return to on topic, what does anyone know about Theora's multithreading?

[thewebchat]

There is none.

[benwaggoner]

There is none.
Yet it's still pretty fast. I wonder if it's not using very complex encoder modes, or that there's not all that much room to do tricky stuff with the bitstream. I imagine you can save a lot of time not having to sweat doing optimal B-frame placement.

[Dark Shikari]

Yet it's still pretty fast.Pretty fast?

For an encoder that does only a diamond motion search and no RDO, it is about 10 times slower than it should be.

[benwaggoner]

Pretty fast?

For an encoder that does only a diamond motion search and no RDO, it is about 10 times slower than it should be.
Well, we'll put it in Category 1, then :).

But that does suggest there's quite a lot of room for quality opitimization within the current bitstream spec (which was rather blindingly obvious by my 1-pass CBR live sample as well).

Who's going to port MBTree over :)?

[iwod]

This is like asking the question,
Is is faster to solve the Patents and pricing issues with H.264 decoder and Encoder. And to allow x264 inside commercial closed source products.

or

Improve Theora's quality to AT LEAST xvid standard.

[PatchWorKs]

...in a thread about either MP3 or freedom, perhaps.

Ogg doesn't even support MP3 as an audio codec.

If I may offer a return to on topic, what does anyone know about Theora's multithreading?

Cool, if someone tries to stimulate a Theora adoption (in this case by someone that shows some interest to it) the result is censoring.

No more information sharing by me here.

[nurbs]

You have to admit that trying to stimulate Theora adoption in a thread about MP3 encoding is off-topic. It's not even an audio codec.

[PatlaborForce]

Cool, if someone tries to stimulate a Theora adoption (in this case by someone that shows some interest to it) the result is censoring.

No more information sharing by me here.

If you want to talk about a multithreading library for LAME, do it in the audio encoding section and in a thread of it's own. Secondly, how would linking that discussion in this thread help stimulate adoption of theora when it had nothing to do with theora?

[Kurtnoise]

There is none.
http://wiki.xiph.org/TheoraEncoders
case closed...

[Tagert]

Any comparative quality graph between Theora 1.0 vs Theora 1.1?
Are a few comparisons available here:

http://hacks.mozilla.org/2009/09/theora-1-1-released/

Quite a quality gain from 1.0 to 1.1 :)

[Max of S2D]

Who's going to port MBTree over :)?

I wonder how much it would gain at the quality level if it gained optimizations similar to x264

[benwaggoner]

I wonder how much it would gain at the quality level if it gained optimizations similar to x264
A bunch, but not enough :)? There's certainly a lot of techniques that would offer definite improvements over what Theora's encoder can do today. But then there are the fundamental 90's limits of the bitstream and decoder, like no B-frames.

I doubt it could ever get to be as good as xvid ASP is today, but perhaps could match and even surpass in some areas xvid SP. The adaptive quant table stuff could prove interesting with a really advanced implementation.

[dapperdan]

But then there are the fundamental 90's limits of the bitstream and decoder, like no B-frames.


You mentioned B-frames earlier as something Theora should adopt when they broke backwards compatibility for new a version.

I was under the impression that B-frames were avoided by On2, and now Xiph, because they are patented. In that case it doesn't really make sense for Xiph to adopt them. Nor does it seem fair to call it a "fundamental 90's limit" as if technology has moved on and they've simply not noticed. After all if B-frames are patented then even a brand new codec invented today would need to either licence or avoid that technology.

Clearly not being able to implement these patented ideas reduces Theora's options, but stating the actual reason for them not using a technique seems less like an accusation of incompetence, and indeed highlights the fundamental reasons for creating a codec like Theora.

[benwaggoner]

You mentioned B-frames earlier as something Theora should adopt when they broke backwards compatibility for new a version.

I was under the impression that B-frames were avoided by On2, and now Xiph, because they are patented. In that case it doesn't really make sense for Xiph to adopt them. Nor does it seem fair to call it a "fundamental 90's limit" as if technology has moved on and they've simply not noticed. After all if B-frames are patented then even a brand new codec invented today would need to either licence or avoid that technology.
Well, the limitations of Theora are a mix of patent workarounds from the 90's and the fundamental design of the codec. I'm no IP expert in this space, certainly. But I imagine there were techniques that were patented when VP3 was created that have since expired. And there are certainly other approaches that could be used in a ground-up new "IP free" codec that aren't possible in Theora.

Clearly not being able to implement these patented ideas reduces Theora's options, but stating the actual reason for them not using a technique seems less like an accusation of incompetence, and indeed highlights the fundamental reasons for creating a codec like Theora.
We'd need a per-feature breakdown of the patent story. Also, if the VP3 bitstream was the best IP mix possible when it was created, that's no reason to think that it's the best IP mix possible today.

[dapperdan]

For the specific example of B-frames, other VP3 derived codecs such as On2's VP4,6,7 & 8 (announced a year ago) don't use B-frames either. On2 have text on their site about why this is a good thing but reading between the lines and particularly noting that, as with Xiph, not relying on external patents was one of the selling points of their codecs I think it's clear that it was patents that prevented them from adding this feature, which as you said earlier, is an obvious addition to such a codec.

[Dark Shikari]

For the specific example of B-frames, other VP3 derived codecs such as On2's VP4,6,7 & 8 (announced a year ago) don't use B-frames either. On2 have text on their site about why this is a good thing but reading between the lines and particularly noting that, as with Xiph, not relying on external patents was one of the selling points of their codecs I think it's clear that it was patents that prevented them from adding this feature, which as you said earlier, is an obvious addition to such a codec.Of course, given that MPEG-1 was the first format to include B-frames and is now old enough to be out of patent period, the entire discussion is completely moot.

[dapperdan]

Actually MPEG-1 (or a subset) was recently proposed as the baseline codec for HTML5 and though some people claimed that it was old enough to be entirely patent free others objected:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/020015.html

> Since the near complete MPEG-1 committee draft was publicly available in December 1991,
[snip]

You keep repeating this particular piece of misinformation, so I'm
worried that people are going to take your word for it and get into
trouble.

What you are claiming with respect to the inventors disclosure and
patent duration is correct for patents filed and granted today but it
not true for patents from the mid-1990s.

Prior to mid-1995 was possible to use application extensions to defer
the grant date of a patent indefinitely. You could begin an
application in 1988, publicly expose your invention in 1991, all the
while filing extensions only to have the patent granted in 1995.

I am somewhat surprised that you are unaware of this issue,
considering that you mentioned it specifically by name (submarine
patent).


It's also worth noting that even the MPEG-1 subset (as proposed by the person being replied to above) dropped B-frames giving the reason that they lacked suitable prior art.

[donaldtone]

what's the problem w/ file size ? you can compress exe files if you want...personally, I don't care.

I use static libs (vorbisenc, vorbis, theoraenc, theoradec, avdevice, avformat, avcodec, zlib, bz2, pthreads, faad, ws2_32, vfw32, postproc, swscale, avutil, oggkate, kate, ogg, iconv) instead of dynamic ones (dlls in short). That's why you have a such size...
Your version with avs support is very useful. It is also supposed to support subtitle since it has kate built in. However, it does not support subtitles.

Following is the error message:

C:\AutoFFmpegTheora\ffmpeg2theora-0.25-svn_20090930>ffmpeg2theora --subtitles-language en --subtitles input.srt 0373.avi
WARNING - Kate support not compiled in, subtitles will not be output
- install libkate and rebuild ffmpeg2theora for subtitle support

[donaldtone]

Embedding Subtitles or lyric is a rather important function of a video container.

However, I can not find any tool in windows could easily remux or demux subtitles inside ogv container.
There is also only one player VLC can support subtitles in ogv format.

I just wonder if somebody can build kate tool package in windows (including kateenc, etc.).
It will be very appreciate.

This page is for reference how to build them
http://www.finetyping.com/kate/win32/vc2008/readme.txt

[Astrophizz]

AFAIK the Haali splitter supports .ogv and subtitles therein - but I might be wrong. I don't know about muxers but I think there are plans to add it to Avidemux at some point in the future.

[donaldtone]

AFAIK the Haali splitter supports .ogv and subtitles therein - but I might be wrong. I don't know about muxers but I think there are plans to add it to Avidemux at some point in the future.
right now the only support player is VLC(with video, audio and subtitle).
mpc hometheatre with Haali splitter only support video and audio, no subtitle (kate format subtitle) support.

[nurbs]

Could somebody please upload a copy of the ffmpeg2theora build with avs support for me. Kurtnoises site seems to be down unfortunately, so I can't get that.

[Midzuki]

@ nurbs: the "official" builds of ffmpeg2theora do accept piping from avs2yuv.exe (even though you may need to kill the process manually, after the encoding is finished. :) )

[nurbs]

Didn't think about that solution, thanks.

edit: Thanks Kurtnoise!