View Full Version : Getting Theora competitive
nakTT
27th July 2009, 15:27
By the way, the free version of Expression Encoder 3 incldues all the WMV features. I probably should have mentioned that earlier :).
http://blogs.msdn.com/expressionencoder/archive/2009/07/22/9845044.aspx
I have been trying the Expression Encoder 3 ever since it was available for download. The question is where can I find the info like this (the link is for the version 2 SP1) for the Version 3?
http://www.microsoft.com/expression/products/expression2/Encoder2_SP1_ReleaseNotes.aspx
Any advice for optimum quality setting for VC-1 encoding at 256kbps (bitrate for video only)? So far as a lay man (my eyes perceived quality) I found out that x264 is considerably ahead of the curve. Or is it just me who don't know the optimum setting?
benwaggoner
27th July 2009, 18:07
I have been trying the Expression Encoder 3 ever since it was available for download. The question is where can I find the info like this (the link is for the version 2 SP1) for the Version 3?
http://www.microsoft.com/expression/products/expression2/Encoder2_SP1_ReleaseNotes.aspx
It should be up soon. The Team Blog link has lots of other details.
Any advice for optimum quality setting for VC-1 encoding at 256kbps (bitrate for video only)? So far as a lay man (my eyes perceived quality) I found out that x264 is considerably ahead of the curve. Or is it just me who don't know the optimum setting?
Well, in-loop deblocking and CABAC are powerful tools, and x264 is a great implementation. I would expect x264 High Profile to outperform that VC-1 implementation at 256 Kbps.
If you can tell me about your content and how you're using the file, I can make some tuning recommendations. But I woudln't anticipate it beating a well tuned x264 implementation doing the same scenario.
easyfab
27th July 2009, 18:24
Don't know if it can help the testers but here you can find the nightly build of ffmpeg2theora (as mentined on http://wiki.xiph.org/index.php/TheoraSoftwareEncoders )
the site :
http://firefogg.org/nightly/
nakTT
28th July 2009, 03:41
It should be up soon. The Team Blog link has lots of other details.
Well, in-loop deblocking and CABAC are powerful tools, and x264 is a great implementation. I would expect x264 High Profile to outperform that VC-1 implementation at 256 Kbps.
If you can tell me about your content and how you're using the file, I can make some tuning recommendations. But I woudln't anticipate it beating a well tuned x264 implementation doing the same scenario.
Thanks for the reply.
Actually I use it to backup my old VCD movies. But since you kind of help me to confirm that VC-1 is not as good as x264, I think I will stop experimenting with it and stick with x264. Thanks again for giving some confirmation regarding the matter as it really help me in term of time saving.
:thanks:
nakTT
28th July 2009, 03:51
Don't know if it can help the testers but here you can find the nightly build of ffmpeg2theora (as mentined on http://wiki.xiph.org/index.php/TheoraSoftwareEncoders )
the site :
http://firefogg.org/nightly/
It seems that after an update to its firefox plugins a few weeks ago, the http://firefogg.org/ is no longer accepting .avi files as source file. Any idea?
benwaggoner
28th July 2009, 03:58
Actually I use it to backup my old VCD movies. But since you kind of help me to confirm that VC-1 is not as good as x264, I think I will stop experimenting with it and stick with x264. Thanks again for giving some confirmation regarding the matter as it really help me in term of time saving.
That said, why back up VCD at 256 Kbps? Wouldn't you be better off using constant quality so that you get the quality you can out of it?
I hope you're using a deblocking MPEG-2 decoder :).
nakTT
28th July 2009, 04:18
That said, why back up VCD at 256 Kbps? Wouldn't you be better off using constant quality so that you get the quality you can out of it?
I hope you're using a deblocking MPEG-2 decoder :).
The resolution is something like 329*288. I figure 256kbps is good enough but any better idea are welcomed.
I'm not quite sure how to set a "deblocking MPEG-2 decoder". Care to elaborate?
:thanks:
hellfred
28th July 2009, 07:36
Getting rate control modes beyond fixed quant and 1-pass CBR with GOP duration=buffer duration is the other big thing needed. Most of the proposed uses of Theora are progressive download, so a good old-fashioned peak limited 2-pass VBR would be a big help as well to keep those QP spikes down.
And here we go: two-pass rate controll for the theora thusnelda encoder. (https://trac.xiph.org/changeset/16340)
I do hope that the theora developer read this thread and pick up your valueable input.
Hellfred
Blue_MiSfit
28th July 2009, 10:34
The resolution is something like 329*288. I figure 256kbps is good enough but any better idea are welcomed.
I'm not quite sure how to set a "deblocking MPEG-2 decoder". Care to elaborate?
:thanks:
256kbps might not be enough, especially if you're doing a 1 pass VBR encode!
I'd just use x264, and use CRF encoding, maybe set to 19 or 20 depending on your eyes. This will ensure fairly constant quality while not ballooning filesize too much :)
Regarding deblocking, you will probably want to deblock a VCD, since it's probably got blocks all over the place :). Using something like DGIndex's CPU parameter will suffice. CPU=6 is strong deblocking, and should be appropriate.
If you want to get adventurous, try using any of the neat-o avisynth filters like DFTTest to deblock. It's VERY powerful, especially when motion compensated!
~MiSfit
nakTT
28th July 2009, 18:40
256kbps might not be enough, especially if you're doing a 1 pass VBR encode!
I'd just use x264, and use CRF encoding, maybe set to 19 or 20 depending on your eyes. This will ensure fairly constant quality while not ballooning filesize too much :)
Regarding deblocking, you will probably want to deblock a VCD, since it's probably got blocks all over the place :). Using something like DGIndex's CPU parameter will suffice. CPU=6 is strong deblocking, and should be appropriate.
If you want to get adventurous, try using any of the neat-o avisynth filters like DFTTest to deblock. It's VERY powerful, especially when motion compensated!
~MiSfit
Thanks for the input. Will give it a try. BTW, my current setting is
program --profile high --pass 2 --bitrate 256 --stats ".stats" --ref 8 --b-adapt 2 --b-pyramid --direct auto --subme 9 --trellis 2 --partitions all --vbv-maxrate 2500 --me umh --thread-input --output "output" "input"
Feel free to comment on my current setting.
:thanks:
benwaggoner
28th July 2009, 18:48
And here we go: two-pass rate controll for the theora thusnelda encoder. (https://trac.xiph.org/changeset/16340)
I do hope that the theora developer read this thread and pick up your valueable input.
Well, that's cool! I can't tell if this is an enhanced CBR mode or part of a full VBR mode. But definitely a welcome step. The Theora encoder is already pretty fast, so I think lots of people would be happy to double encode time for a reduced file size or improved quality.
It's been fun to follow Xiph's development process with all that info out in the open.
I don't know if I'm saying anything they haven't heard a thousand times already, but they're welcome to any help it can provide. Theora is clearly going to be used to some degree, so all of us with eyeballs benefit if it's as good as it can be.
nakTT
28th July 2009, 18:55
Well, that's cool! I can't tell if this is an enhanced CBR mode or part of a full VBR mode. But definitely a welcome step. The Theora encoder is already pretty fast, so I think lots of people would be happy to double encode time for a reduced file size or improved quality.
It's been fun to follow Xiph's development process with all that info out in the open.
I don't know if I'm saying anything they haven't heard a thousand times already, but they're welcome to any help it can provide. Theora is clearly going to be used to some degree, so all of us with eyeballs benefit if it's as good as it can be.
Since you are one of the person here who seems to know quite a lot about Theora, I would like to ask a question. (I did ask it before to others actually :D)
Do you noticed that after an update to its firefox plugins a few weeks ago, the http://firefogg.org/ is no longer accepting .avi files as source file. Any idea?
benwaggoner
28th July 2009, 19:15
Since you are one of the person here who seems to know quite a lot about Theora, I would like to ask a question. (I did ask it before to others actually :D)
Well, just as a compression nerd.
Do you noticed that after an update to its firefox plugins a few weeks ago, the http://firefogg.org/ is no longer accepting .avi files as source file. Any idea?
This is the first I've heard of firefogg, so no, I've got no idea.
Some ffmpeg issue I'd guess. But failing with all AVI files seems like a pretty severe problem!
nakTT
28th July 2009, 19:26
This is the first I've heard of firefogg, so no, I've got no idea.
Some ffmpeg issue I'd guess. But failing with all AVI files seems like a pretty severe problem!
I see, no problem.
As an info for all of us, with the last plugins the firefogg did accept this very same AVI file. I just wonder is it because of technical issue or some license dispute or something.
benwaggoner
28th July 2009, 19:36
Thanks for the input. Will give it a try. BTW, my current setting is
program --profile high --pass 2 --bitrate 256 --stats ".stats" --ref 8 --b-adapt 2 --b-pyramid --direct auto --subme 9 --trellis 2 --partitions all --vbv-maxrate 2500 --me umh --thread-input --output "output" "input"
Feel free to comment on my current setting.
:thanks:
If you're looking for x264 tuning for this, you probably should start a new thread over at:
http://forum.doom9.org/forumdisplay.php?f=77
However, for this kind of backup application, using a fixed bitrate doesn't seem ideal, unless you care about the size of each file a bunch. So CRF mode would be a better choice; just find the CRF value that loosk good enough while offering good file size.
As for deblocking decoding, DGDecode is your friend:
http://neuron2.net/dgmpgdec/DGDecodeManual.html
It'll smooth out blocking artifacts in the MPEG-1. It'll thus lower the bitrate required to encode (none of those erronous blocking artifacts), and can result in your archive looking better than your source.
Given the typical VCD, it'll probably be more useful there than anywhere!
Lastly, you should make sure you're flagging the aspect ratio correctly, so that your VCD-derived files will play back at their correct aspect ratio.
nakTT
28th July 2009, 20:21
Thanks for the input. I will start another thread to avoid deviating this thread.
Midzuki
28th July 2009, 21:05
I think to make Theora competitive, there would be video editors like VirtualDub, Avidemux and others that have supported it.
Now the only usable application to make Theora files is ffmpeg2theora (http://v2v.cc/~j/ffmpeg2theora) and is command line.
Well, some builds of ffdshow (revision 3008, for example) contain the libtheora compression module, which can be called by VirtualDub.
benwaggoner
28th July 2009, 21:11
Now the only usable application to make Theora files is ffmpeg2theora (http://v2v.cc/~j/ffmpeg2theora) and is command line.
There is this:
http://forum.doom9.org/showpost.php?p=1296998&postcount=41
Although it presumably would need to be updated for the new 2-pass mode.
hellfred
28th July 2009, 21:16
Latest ffmpeg2theora builds should now include an option for performing a two-pass encoding: commit (https://trac.xiph.org/changeset/16353).
buzzqw
28th July 2009, 21:17
i will gladly update it when 2 pass become avaiable
BHH
iwod
29th July 2009, 19:45
Any new update Demo page coming for Theora then?
buzzqw
29th July 2009, 20:06
here the link to update ffmpeg2theora gui for LINUX with support for 2 pass encode -> http://www.64k.it/andres/data/autofftheora/autoffmpegtheora.tar.gz
download here the nightly build -> http://firefogg.org/nightly/
EDIT: update also the windows gui -> http://www.64k.it/andres/data/autofftheora/autoffmpeg2theora.exe
BHH
clsid
29th July 2009, 22:16
Well, some builds of ffdshow (revision 3008, for example) contain the libtheora compression module, which can be called by VirtualDub.
That is an ancient version of libtheora. It should not be used. It is no longer included with official builds of ffdshow.
Leak
31st July 2009, 11:49
Do we know if it's the decoder per se, or the media pipeline integration? Having media playback sharing the same threading model as a mult-tabbed browser each of which could have multple videos playing back, and also with Javascript and other processing. Plus making sure the networking stack is keeping the video buffers full while allowing other things to come down...
I'm pretty sure that's it - in media player terms it's like complaining about some codec's performance when it's actually the video renderer that's acting up.
np: Nine Inch Nails - Ruiner (Version) (Further Down The Spiral)
benwaggoner
31st July 2009, 21:20
I'm pretty sure that's it - in media player terms it's like complaining about some codec's performance when it's actually the video renderer that's acting up.
And it's probably not just a matter of "acting up" but of "insufficiently refined."
Looking at the history of VLC, WMP, Media Foundation, etcetera, it seems like it takes a good 3-5 years of development for media players to become sufficiently robust under load.
And doing media in the browser environment is a lot more challenging than running as a full-screen exclusdive app with GPU or hardware overlay controol.
There's a crazy amount of thread management and pipeline buffer heuristics even in something as simple as Silverlight, and we're still always at the risk of a Flash ad in another frame sucking up all the CPU.
Theora being a relatively simple decoder helps here in terms of overall perf, but lacking B-frames is a challenge, since there's no non-reference frames to drop.
Were Xiph to look at changing the bitstream, B-frames would be an obvoius addition. They could probably be done without breaking backwards compatibility; B-frames are essentially a temporal enhancement layer. So, the the B-frame stream could be muxed alongside the current I/P stream, ignored by old decoders, but used by new encoders. Thus a 30p encode would play at 15p in an old decoder, but would still play.
nakTT
1st August 2009, 15:45
Received auto update for plugins Firefogg Version 0.9.9.4 today. Support for 2-pass has been added but it still won't accept ".avi" files as input. This happened after an update quite a few weeks ago where ".avi" support has been remove (or is it just me?). If anyone know why this happen, please share the info here.
buzzqw
1st August 2009, 15:55
Received auto update for plugins Firefogg Version 0.9.9.4 today. Support for 2-pass has been added but it still won't accept ".avi" files as input. This happened after an update quite a few weeks ago where ".avi" support has been remove (or is it just me?). If anyone know why this happen, please share the info here.
i can only say that on linux the latest ffmpeg2theora builds support avi
BHH
nakTT
1st August 2009, 17:00
i can only say that on linux the latest ffmpeg2theora builds support avi
BHH
Its not about ffmpeg2theora. Its the one at the firefogg website. The last few updates for the plugins seems to have come without ".avi" input support.
benwaggoner
1st August 2009, 18:44
Received auto update for plugins Firefogg Version 0.9.9.4 today. Support for 2-pass has been added but it still won't accept ".avi" files as input. This happened after an update quite a few weeks ago where ".avi" support has been remove (or is it just me?). If anyone know why this happen, please share the info here.
Since it's working in the current ffmpeg2theora builds, it's probably a bug or other limitation of Firefogg's service unrealated to Theora itself.
nakTT
2nd August 2009, 07:16
Since it's working in the current ffmpeg2theora builds, it's probably a bug or other limitation of Firefogg's service unrealated to Theora itself.
How foolish of me not to realize things that even a layman should realize. I can't believe I missed that one, its so obvious.
:thanks:
ricardo.santos
12th August 2009, 10:17
Hi everyone
Anyone knows how to get hold of the build used here?:
http://web.mit.edu/xiphmont/Public/theora/demo7.html
Also what is the relation between the theora site builds (0.24) and the firefogg builds, 2 teams working on the same thing?
http://www.v2v.cc/~j/ffmpeg2theora/
http://firefogg.org/nightly/
Final question...when using the builds on firefogg website that allow 2 pass encodings i'm getting worse results than with 1 pass conversions and the 2 pass conversions are oversized ... im using the following for 1 pass:
ffmpeg2theora -V 510 -A 64 -c 2 -H 22050 123.mp4
and this for 2 pass:
ffmpeg2theora --first-pass -V 510 -A 64 -c 2 -H 22050 123.mp4
ffmpeg2theora --second-pass -V 510 -A 64 -c 2 -H 22050 123.mp4
is this the correct syntax?
I know x264 produces better quality and we can also stream it... im only testing theora
Dark Shikari
12th August 2009, 17:54
The ratecontrol is currently very buggy, even in two-pass, so you may want to wait until the issues are resolved (or stay with the last released version before the ratecontrol overhaul).
tuqueque
12th August 2009, 19:34
Hello Ricardo...
Your 2-pass syntax is a little too much fiddle...
Go with something easier :)... if you simply put "--two-pass", ffmpeg2theora handle the first and second pass automatically... So I recommend you to go with a simpler syntax like:
ffmpeg2theora --two-pass -V 510 -A 64 -c 2 -H 22050 123.mp4
Good luck!
ricardo.santos
12th August 2009, 23:36
thanks tuqueque,i searched for the sintax over at theora but i just saw my example....the example you gave is the same autoffmpeg2theora uses, should have inspected the command line it uses before.....
Thanks
hellfred
13th August 2009, 09:43
Hi everyone
Anyone knows how to get hold of the build used here?:
http://web.mit.edu/xiphmont/Public/theora/demo7.html
AFAIK the flatened/improved quant matrices where not released. It was just an quick and dirty test done by Gregory Maxwell. Proper optimization of the quant matrices is still to come. I have read about the quant matrices on the theora mailing list, but I am too lazy to look up the post.
Also what is the relation between the theora site builds (0.24) and the firefogg builds, 2 teams working on the same thing?
http://www.v2v.cc/~j/ffmpeg2theora/
http://firefogg.org/nightly/
AFAIK, the firefogg nightly builds use the latest theora code straight from the subversion repository of that day.
J is the one developing ffmpeg2theora, but he is not doing regular builds with the most up to date libtheora code and whenever he adds new parameters to ffmpeg2theora, when new theora functionality becomes available.
Final question...when using the builds on firefogg website that allow 2 pass encodings i'm getting worse results than with 1 pass conversions and the 2 pass conversions are oversized ... im using the following for 1 pass:
and this for 2 pass:
is this the correct syntax?
I know x264 produces better quality and we can also stream it... im only testing theora
Please submit the source video clips with poor encoding performance to the theora developers, so that they can tweak the rate control algorithms. They explicitely requested those streams: "We're particularly interested in sequences it does poorly on" (http://www.theora.org/news/) (news entry related to theora 1.1 beta 1 release)
Yours
Hellfred
Sample request: http://lists.xiph.org/pipermail/theora/2009-August/002629.html
tuqueque
24th August 2009, 19:37
Demo 8 of the Theora - Thusnelda development is out :)
http://web.mit.edu/xiphmont/Public/theora/demo8.html
PatchWorKs
25th August 2009, 07:34
Demo 8 of the Theora - Thusnelda development is out :)
http://web.mit.edu/xiphmont/Public/theora/demo8.html
Cool ! I'm really excited !
Now we do need HW support (into media boxes, for example) !
nakTT
25th August 2009, 08:12
Demo 8 of the Theora - Thusnelda development is out :)
http://web.mit.edu/xiphmont/Public/theora/demo8.html
I have tried the latest version at firefogg. All I can say is that even at 1000kbps, it can't even match x264 at 500kbps. Very sad since I have a high hope before performing the test.
But since its an open source, I will always support this encoder and wish it all the best. Looking forward to really test it in another 3 month and see what improvement they have made.
iwod
27th August 2009, 04:11
Some nice improvement indeed. I think i will stop comparing it to x264 since i guess in the short life time of an human being we will never see it. But if it continue to improve may be it could match some extremely poor H.264 implementation.
Dark Shikari
27th August 2009, 04:33
Some nice improvement indeed. I think i will stop comparing it to x264 since i guess in the short life time of an human being we will never see it. But if it continue to improve may be it could match some extremely poor H.264 implementation.Unquestionably; as shown by my recent comparison (http://x264dev.multimedia.cx/?p=102) some H.264 implementations (Apple, Badaboom) are so bad that they are definitely within range of competition by Theora.
But that shouldn't really be the goal or expectation; the goal should be to compete with other H.263-like formats. Theora is very similar to H.263+, so with a good encoder one should expect H.263+-like results from it.
juGGaKNot
25th September 2009, 15:44
I got the Theora 1.1.0 (http://forum.doom9.org/showthread.php?p=1328838#post1328838) and i tried to build it
$ cd /d/theora
$ ./configure
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking whether gcc and cc understand -c and -o together... yes
checking for as... as
checking for dlltool... dlltool
checking for objdump... objdump
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... d:/min/i686-pc-mingw32/bin/ld.exe
checking if the linker (d:/min/i686-pc-mingw32/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /mingw/bin/nm
checking the name lister (/mingw/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for d:/min/i686-pc-mingw32/bin/ld.exe option to reload object files...
-r
checking for objdump... (cached) objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|
^x86 DLL
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /mingw/bin/nm output from gcc object... ok
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... no
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (d:/min/i686-pc-mingw32/bin/ld.exe) supports sha
red libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for doxygen... false
configure: WARNING: *** doxygen not found, API documentation will not be built
checking for pdflatex... no
checking for bibtex... no
checking for fig2dev... no
configure: WARNING: *** Format Specification will not built.
checking for ld used by gcc... (cached) d:/min/i686-pc-mingw32/bin/ld.exe
checking if the linker (d:/min/i686-pc-mingw32/bin/ld.exe) is GNU ld... (cached)
yes
checking how to control symbol export... -export-symbols
checking for pkg-config... no
checking for Ogg... no
*** Could not run Ogg test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means Ogg was incorrectly installed
*** or that you have moved Ogg since it was installed.
configure: error:
libogg is required to build this package!
please see http://www.xiph.org/ for how to
obtain a copy.
So is there a tutorial on compiling for windows ?
Has ffmpeg2theora been updated to 1.1 ?
Kurtnoise
25th September 2009, 15:45
libogg & libvorbis are required...rtm
>> Here is a win32 fresh build (http://kurtnoise.free.fr/misc/theoraenc-1.1.0.zip) <<
avs2yuv.exe -i input.avs - | encoder_example.exe -V 850 - -o output.ogv
or
avs2yuv.exe -i input.avs - | encoder_example.exe -V 400 -v 8 --first-pass fake - -o output.ogv
avs2yuv.exe -i input.avs - | encoder_example.exe -V 400 -v 8 --second-pass fake - -o output.ogv
nakTT
25th September 2009, 19:10
libogg & libvorbis are required...rtm
>> Here is a win32 fresh build (http://kurtnoise.free.fr/misc/theoraenc-1.1.0.zip) <<
avs2yuv.exe -i input.avs - | encoder_example.exe -V 850 - -o output.ogv
or
avs2yuv.exe -i input.avs - | encoder_example.exe -V 400 -v 8 --first-pass fake - -o output.ogv
avs2yuv.exe -i input.avs - | encoder_example.exe -V 400 -v 8 --second-pass fake - -o output.ogv
Any chance MeGUI to support this encoder? I know x264 is currently the best, just for comparison sake perhaps?
Kurtnoise
25th September 2009, 19:58
the few tests (most 2 passes encodings) I've done with it, doesn't seem to be accurate to reach my target bitrates...and we are in 2009 !!!
So, no, sorry...not competitive yet. :sly:
nakTT
26th September 2009, 06:52
the few tests (most 2 passes encodings) I've done with it, doesn't seem to be accurate to reach my target bitrates...and we are in 2009 !!!
So, no, sorry...not competitive yet. :sly:
I see. If its not competitive yet (from their bombastic words, I thought its already competitive), then I also don't want to waste my time on it. I would rather run the test only when it become competitive. Thanks for the info bro.
:thanks:
Kurtnoise
26th September 2009, 07:41
Keep in mind that my tests were specific to multipasses. It may be competitive in other scenarios...
thewebchat
27th September 2009, 01:26
http://img30.imageshack.us/img30/9900/theora2.png
In general, Theora 1.1 seems to be comparable to Xvid 1.2.2, sometimes with significantly less mosquito noise and blocks. However, you get sequences like the one above every now and then where the frame seems to have completely fallen apart. Is this because of a loop filter? RDO problems? Inherent to the format?
Dark Shikari
27th September 2009, 01:36
http://img30.imageshack.us/img30/9900/theora2.png
In general, Theora 1.1 seems to be comparable than Xvid 1.2.2, sometimes with significantly less mosquito noise and blocks. However, you get sequences like the one above every now and then where the frame seems to have completely fallen apart. Is this because of a loop filter? RDO problems? Inherent to the format?The ratecontrol is current extremely broken and will randomly fall apart when you least expect it. Constant quant mode is of course fine, it's only bitrate mode that has issues.
Also of course note that if some parts look as good as Xvid and others look very bad, that's because the parts that look good are stealing bits from those that look bad ;)
Also, encoding at 1500kbps for SD doesn't really make for an interesting test. Even MPEG-2 can do that with reasonable quality if you use a long GOP.
benwaggoner
27th September 2009, 04:24
I made a few samples using the latest of x264, VC-1, and Theora, testing both offline VBR and real-time CBR encoding.
http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/Theora%5E_1.1
Theora is defintely improved, but I see a lot of basis pattern throughout these samples. Theora would be well-served by a postprocessing filter.
Dark Shikari
27th September 2009, 05:12
Theora is defintely improved, but I see a lot of basis pattern throughout these samples. Theora would be well-served by a postprocessing filter.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.
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.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.