Doom9's "Codec shoot-out 2004" test results are out!

[SeeMoreDigital]

Yep,

True to his word Doom9 has been hard at work, and come up with the goods in the form of another comp test.

This one is the biggest yet, with 10 different codecs.... For more information look here: -

http://www.doom9.org/index.html?/codecs-104-1.htm



Cheers and many thanks Doom9


EDIT: Thread title changed to match Doom's.

[dvd_maniac]

Page Not Found Error...

[SeeMoreDigital]

Originally posted by dvd_maniac
Page Not Found Error... You're not wrong mate.... It's gone :eek:

A case of.... there it wasn't :D

It was there... coz I've still got it in my "temporary internet files" folder!


Cheers

[Doom9]

welcome to the effects of round robin.. not all the servers are updated at the same speed, and when we're talking about 43MB of image data (damn you PNG), it just takes a while. But by now all the servers are fully up-to-date.

[BoNz1]

Many thanks doom9, I haven't read it but your tests are always first rate. Maybe we could set up torrent for the ultra high bandwidth to help with bandwidth?

[nicco]

DivX Fusion 5.9
:confused:
What is it?

[dvd_maniac]

OK, There it "IS" again.

I just went through it and it is very informative. I am at the begining of encoding my entire dvd collection onto Hard drive. I want to create a media server using SageTV as a frontend. I have been trying to decide between Xvid and ND AVC for a while now and have done many tests. I do not seem to get good results using the AutoGK tool and giving the multitude of DVDs I am doing (1000+) I do not want a lot of steps. So I decided to do action, sci-fi movies in ND AVC. I still did not choose for slower paced, less scenic movies, either Xvid or ND ASP.

I was wondering (@Doom9), You were referring to ND Main Profile as giving you around 31 FPS?
Also, ateme's Main Profile encoder delivered a good 31.40 fps, which is very respectable for an AVC codec
It took me around 8+ hours to encode Matrix 3 in ND Standard AVC Profile. 1rst pass was quick around 70 minutes, the second pass was at around 6 FPS. What is the difference between Main & Standard?Should I be getting better FPS?

My machine is:
p4 3.0 800FSB
Asus P4C800-E Deluxe
ATI AIW 9800 Pro
2x512=1GB Cosair DDR500
2x120 Sata Raid-0 on-board raid controller
2x250 IDE Raid-0 Promise tx2 controller card
Sony DRU-530a & DRU-710 dvd-+rw drives.

[Doom9]

@dvd_maniac: I'm afraid I've never used AVC in Recode... I'm only familiar with the encavc application. But there's one thing.. in Recode you have the whole shebang, MPEG-2 decoding, resizing, audio encoding. And I'm not sure what kind of input preprocessing you had done.. all of that can have an influence. I used a very simple AviSynth script, and the encoding speed is obviously for the video only.

DivX Fusion 5.9It is a video codec by DivXNetworks that you cannot currently have. I suppose the official beta program will start shortly. And in the end.. what comes after 5.9? ;)

[krackato]

Looks like Nero Recode and their AVC codecs won this shootout. Congrats to the Nero team for their excellent codec.

[dvd_maniac]

Thanx Doom.

I want to thank you for all your hard work in helping me, and I'm sure many others, in deciding what codecs to use.

Thanx

[IgorC]

there are some words like

ºIf anybody claims any codec can deliver DVD quality at 700MB for a 2h movie, have him encode Matrix3 and compare it to the DVD. And if he still thinks so, send him to an eye doctor.º

i´ve ripped Matrix3 by Nero H.264 (714 Mb 1Cd rip). NTSC 720x304, 23.976 FILM fps, 760 kbit/s + HE-AAC 52 kbit/s. Of course it isn´t a DVD quality.
But quality is great and big part of details was preserved.

i think it will be (less or more) corect to conisder rip ´loseless´
2-3 movies per DVD.
Very interesting article. Great job. and of course NERO AVC is great winner. Waiting for new versions of XVID 1.1 Divx 5.9 and anothers.
Good luck to all and HAPPY NEW YEAR to all members of doom9!!!

[Emp3r0r]

Thanks Doom9 for the hard work you endured while putting together the new codec shootout. Great job!

I'm looking forward to testing some of those other codecs when they are released to the public. I'd like to see them perform with higher bitrates and HDTV resolutions. XviD works perfectly in this niche for now.

[KpeX]

Great job Doom9, especially previewing so many up-and-coming codecs.
If anybody claims any codec can deliver DVD quality at 700MB for a 2h movie, have him encode Matrix3 and compare it to the DVD. And if he still thinks so, send him to an eye doctor.Ditto.

many player makers specifically advertise XviD playback as a feature - which shows that an open source project, with no advertising budget whatsoever, can clearly make a significant impact in today's world).Good point. AFAIK this was never even a goal of the xvid developers - it has reached this popularity purely by providing excellent quality.

if I were a broadcaster or potential user of HD DVD/ Blu-Ray, seeing the result of WMV9 and ateme's AVC codecs, I'd definitely go for the AVC standard. In terms of current implementations, AVC definitely blows away WMV9 - hopefully HD-DVD producers will make decisions based on quality and not influenced by marketing/corporations.

[CruNcher]

Yep the outcome of the test is personaly not a suprise but it's well done nice work doom9 thx for it, it also confirms my own tests relating to the Speed/Quality Ratio of XviD vs ND AVC.
For me the HDX4 results are very interessting it doesn't look that bad for the start :)

@ KpeX HD-DVD uses very high bitrates you can't take the results from this shoot-out and apply them to HD-DVD.

[Leak]

Originally posted by Doom9
And in the end.. what comes after 5.9? ;)

5.10, as always.

Why do you ask? :D:D:D

[Latexxx]

I would have liked to see wmv 9 advanced aka vc-1 high profile. It comes with wmp10 and you encode it using wme 9. And another thing. If I'm not completely wrong, wmv9 vcm doesn't have b-frames whereas Windows Media Encoder does them.

[Latexxx]

Somebody should merge this thread and http://forum.doom9.org/showthread.php?s=&postid=586284 .

[darth rosenberg]

How can you actually "judge" some rate control mechanism of a codec that can be put into avi? What is to be used as "reference"?

Example:
"normal" AVI: 1,094,551 kB
remuxed with low overhead settings: 1,086,580 kB
(103min video, 1x mp3-vbr)

[Teegedeck]

Thanks for another great test, I'll have fun reading it back and forth for a day!

And congratulations to the guys at Ateme; as said before, you did a very good job!

[dragongodz]

Doom9 - thanks for another interesting read.

again if people want to start saying "i would like to see this" or "you should have done it this way" etc. please DONT.
that happens after every shootout and Doom9 has said many times if you think something should be different then you either come up with an amazingly convincing reason or you do the tests yourself.

[darth rosenberg]

again if people want to start saying "i would like to see this" or "you should have done it this way" etc. please DONT.In other words, suggestions are not welcome, unless you can read someone else's mind? Pointing out that some information could be misleading isn't supposed to be done either? Aha

[Doom9]

@Latexxx: The advanced profile contains two major improvements: interlaced encoding, and transport stream independence (they call it something else I think).. both are completely uninteresting for DVD backups (well, interlaced encoding might be but I only encode progressively). But that's basically it.. we're not talking about quality improvements and such. And, you can easily use B-frames in the VCM.. you can enable them by making an appropriate registry entry. same thing goes for the loop filter (which was activated for the encoding). I was told not to use B-frames. The subject of using VCM or WME also came up, it was the decision of the Microsoft rep I was talking with prior to the test to use the VCM rather than the WME.

For those interested, here's how you activate the LoopFilter and B-frames for the WMV9 VCM:

Loop Filter:

This can be enabled by creating the following DWORD reg key (HKEY_CURRENT_USER\Software\Microsoft\Scrunch\WMVideo\Force LoopFilter) and giving it a value of 1. It can be disabled by setting it to 0.



B Frames:

This can be enabled by creating the following DWORD reg key (HKEY_CURRENT_USER\Software\Microsoft\Scrunch\WMVideo\NumBFrames) and giving it a value from 1 to 7. I usually use 1-3. It can be disabled by setting it to 0.

[slavickas]

and using b frames u'll get delay as much b frames used, even in wme

[Doom9]

@dragongodz: I have a 16 question FAQ for just that purpose so I don't waste my time replying.

How can you actually "judge" some rate control mechanism of a codec that can be put into avi?That question makes no sense to me. What does the container have to do with anything? The container overhead can be calculated, so can the size of the audio file. As long as you use the same settings and tool, the overhead should be constant. And if you add video size + audio size + overhead you have your final size accurately regardless of the container. I could even argue that without ateme's exact overhead calculations for MP4, they'd have a considerable disadvantage because so far nobody came up with an accurate formula.

And, just to make you feel happy, I do have all my source files and I checked for Matrix3: video size + audio size + 7 MB (constant for all codecs) = final size.

Just because there is a low overhead mux mode in AVI Mux GUI (which can create problems as the author noted), doesn't mean using the same tool and settings gives a different overhead. Now I could get into KBs as well, but clearly when we're talking about the considerable oversize or undersize we've seen, that's the rate control. Same goes for extreme image degradation as the action rapidly picks up.. that's something I know from past experience with codecs.

Pointing out that some information could be misleading isn't supposed to be done either? Not when it is without merit.. then it's just trying to make me look bad.

[darth rosenberg]

The container overhead can be calculatedThat's the point. It can't, with the only exception being OGM. With AVI and MKV, there is a bunch of possible things you can do to get the overhead down to 1/3 or 1/4, compared to the "worst" settings.

Of course, in your comparision, some codecs have missed the desired size by more than 20 MB, which is a clear failure, but especially those which are off by not more than 5 MB are within the range the container and some settings can cause for a 1 CD rip.

1482000 kB instead of 1433000 kB is a complete failure (hell, that is even beyond what you could overburn on 2 normal CDs), full ack, but 1440000 imho isn't

[celtic_druid]

Doom9 did all the encoding himself though so he would know what settings and therefor the overhead. We aren't talking about some random files here. If you really wanted you could dump the video to raw streams. No overhead issues then.

[darth rosenberg]

That's exactly the point. The codec can impossibly know what container and with what settings the user is going to store the file. Thus, the codec should only be blamed for not hitting the desired size if it is off by far, like 1482000 instead of 1433000.

Another possible criterion would be if it is oversized by more than 1.2% (because 1.2% is the overhead of OGM and the highest one, compared to others). Then, it is clear that the codec produced an oversized file and that using other containers and/or setting wouldn't "fix" it

[Koepi]

Thank you for the great comparison, Doom9! Sure much work again.

DarthRosenberg:
Encoding has been done through vdub into avi for ages. This is a known procedure. It is the application with it's avimultiplexer which gets used most widely. So there many codecs can do their scaling stuff properly. It doesn't matter if you mux that into other containers (i.e. "low overhead avi"=new container). That wasn't asked in this test. It's about codecs. Not a container shootout. You're mixing things up there %)

I consider Doom9's observations valid.

Regards
Koepi

[celtic_druid]

Well no I think that you are missing the point. You enter a bitrate taking into account the overhead of the container and audio, then if the codec can't hit it your final size will be off due to the codecs rate control. The size would also be off if you expected the codec to take into account container overhead when inputting the bitrate.

The codec doesn't need to know the container/settings, the bitrate doesn't take that into account, that is upto the user.

[SeeMoreDigital]

dvd_maniac

Don't forget when it comes to "encoding speed", the fps rates increase as the encoded pixel frame size decreases!

As you may have read elsewhere on the forum, I recently encoded Terminator 3 to an 720x576 (1:1) 800MB file - using all of NeroDigital's maximum quality Mpeg4/AVC "bells and whistles", complete with 6Ch AAC-HE audio @ 128kbps VBR.

The second pass encoding time was very slow and never seemed to go above 4fps. But would have been significantly quicker if I had encoded to an 640x272 square pixel frame.

But there's no denying that the finished encode looks (and sounds) astonishing, even during the "Demolition Derby" chase scenes. Even when watching on a big screen it's virtually impossible to tell that you're not watching the DVD source!

I can't wait for Mpeg4/AVC hardware players arrive!


Cheers

[temporance]

First of all thanks doom9 for all your hard work. I intend to add my view to this thread, just as I did last time around. Hope that's OK ;)

I intend to replicate at least some of these encodes (meaning a trip to Blockbuster later today!). I remember that in the last comparison, the bit-spend in the movies' credits varied so much between codecs that the bitrate during the movie was affected significantly +-15% iirc.

I'd like to find out the actual bitrate of the segments that were scrutinized (will be different for each codec) and also the frame types and sizes in the region of the screenshots.

Anyway, thanks again for the comparison... I'll be working on some considered constructive feedback.

[darth rosenberg]

Koepi: muhahahahahahaha I knew you'd show up when mentioning OGM that way.

If you knew anything about containers, you'd know that for example MP3 CBR causes almost no overhead in AVI, whereas MP3-VBR causes a lot, at least with VDM/NanDub (you want to use VD(M)/NanDub-AVI as reference).

So if the codec wants to hit the desired size of the final file accurately with an offset of less than 2 MB, it would have to know if the user is going to use VBR or CBR for MP3. All that happens totally indepentant from some muxing settings... those only would make it even worse

[Tommy Carrot]

Darth, please create a separate thread for your problem in the containers forum, it has really nothing to do with Doom9's codec test and it's largely uninteresting.

[darth rosenberg]

Read before replying, and you'll see that it does. It addresses the problem of target file sizes with codecs, especially the 2.5 MB limit Doom9 has chosen because a 700 MB disc has 702,83 MB of space without overburning, and the problem that variations in size within that limit (or even not within that limit) can be caused by influences the codec can't know about or even control, like if the user is going to use vbr or cbr mp3 (unless it asks, of course)

[Koepi]

Read again: the codecs were asked to hit a certain video size. Without any audio.

-> Troll <°|)^))<

[darth rosenberg]

I used a 128kbit/s ABR audio track created in lame 3.93 (using --alt-preset 128 setting) for all movies ... As you may know, not every rate control mechanism is perfect so here are the final movie sizes I got: .... <= exactly there. Yellow / Red "cards" were given if the final file size was off by too much, not for the plain video sizes.

-> Troll <°|)^))<Nice moderators :) Will i be striked if I call you a troll? You obviously have not even read the first page and seriously try to discuss it :oo

I'm saying that the limit of 2.5 MB for getting a "red" in the intro is too strict, because it can still be "fixed" without reencoding to some extent, and all you can say is "troll" :)

[Koepi]

If you quote, quote correctly. The sentence following your quote is the important one:

The size of the audio track was 117'263 KB, 157'455 KB and 20'582 KB respectively. This resulted in an effective video bitrate of 621kbit/s for Matrix, 1016kbit/s for SPR and 987kbit/s for Futurama (here kbit = 1000bit).

There you have the bitrate. The bitrate isn't hit by the marked codecs. Simple as that.

Maybe we can turn over to "real issues" concerning the codec comparison?

Thank you.

Cheers,
Koepi

[Doom9]

actually, I love if people give me an opportunity to beat them with their own facts. dart rosenberg suggested my size findings were irrelevant because the AVI overhead could not be accurately calculated. Well, I present to you the full stats of the entire codec comparison, wherever the AVI container was used:

Codec Final Size Vid size Audio size Overhead

Matrix3

3ivX: 735'541'248 607'709'184 120'077'312 7'754'752
DivX: 734'840'832 607'008'768 120'077'312 7'754'752
HDX4: 734'300'160 606'468'096 120'077'312 7'754'752
VP62: 760'213'504 632'379'392 120'077'312 7'756'800
VSS : 746'326'016 618'491'904 120'077'312 7'756'800
WMV9: 719'798'272 591'966'208 120'077'312 7'754'752
XviD: 733'988'864 606'156'800 120'077'312 7'754'752

delta overhead: 2048 bytes

SPR


3ivX: 1'467'699'200 1'296'295'936 161'233'640 10'169'624
DivX: 1'469'247'488 1'297'844'224 161'233'640 10'169'624
HDX4: 1'468'522'496 1'297'119'232 161'233'640 10'169'624
VP62: 1'518'467'072 1'347'063'808 161'233'640 10'169'624
VSS : 1'487'163'392 1'315'762'176 161'233'640 10'167'576
WMV9: 1'474'691'072 1'303'289'856 161'233'640 10'167'567
XviD: 1'468'395'520 1'296'994'304 161'233'640 10'167'567

delta overhead: 2057 bytes

Futurama

3ivX: 182'532'096 160'155'648 21'075'704 1'300'744
DivX: 183'488'512 161'112'064 21'075'704 1'300'744
HDX4: 183'347'200 160'970'752 21'075'704 1'300'744
VP62: 183'177'216 160'800'768 21'075'704 1'300'744
VSS : 169'793'536 147'417'088 21'075'704 1'300'755
WMV9: 172'410'880 150'034'432 21'075'704 1'300'744
XviD: 183'416'832 161'040'384 21'075'704 1'300'744

delta overhead: 0 bytes

As you can see, we have a whopping overhead difference of 2KB for Matrix3, 2KB plus 3 bytes for SPR, and 0 bytes for Futurama. So that ends this argument once and for all. The numbers clearly speak for themselves and they allow to draw only one conclusion: Knowing audio size and the final size, Gordian Knot allows to derive an exact video bitrate and final video size, and the only reason for an over/undersize of the final video is if the video bitrate is not kept (and thus the size of the video without audio is off).

can be caused by influences the codec can't know about or even control, like if the user is going to use vbr or cbr mp3 (unless it asks, of course)But you can configure that in Gordian Knot.. do you really think I'm that stupid not to take that into account? GKnot can not only accurately calculate the overhead for CBR MP3, VBR MP3, anc AC3, but also a two audio stream combination thereof. Sure, if people do not properly calculate their bitrate, then you have a problem, but being in the business for 5 years now you should give me a little more credit than to commit one of the most basic newbie mistakes.

[darth rosenberg]

As you can seeTo be more precise: As I can see now ;)

OK, now something more interesting: Did you test which of the codecs allow to be run on 2 instances at once, e.g. on a HT or DualCPU system? I remember some old xvid alpha version having issues with that (issues = crash)
But you can configure that in Gordian Knot.. do you really think I'm that stupid not to take that into account?Do you know how many people out there actually would in your place? I can't smell things you didn't write down....

[Doom9]

I'd like to find out the actual bitrate of the segments that were scrutinized (will be different for each codec) and also the frame types and sizes in the region of the screenshots. I can tell you that the frames were all non I-frames but that's about it.. not every codec even offers the facility to find out the frame type. And, in the end it should not matter and you don't really have an influence on whether a frame is a P-frame or a B-frame (I-frame as well.. but at least there's a good change with I-frames that you have one at a scene change). I'm afraid cutting out the reviewed scenes would be too much work and I don't really see the reason behind that.. the point of taking scenes throughout the movie is to ensure that if rate control for a codec give significantly less bits in a scene, this would be compensated for in another scene and on the average you should catch that.. of course, only a small sample was taken, but I doubt that we'd see huge variations.

I see the merit in those findings but IMHO it's way to little to justify the significant additional effort. In the end, as long as the rate control hits the size target, the user should not worry about where the rate control attributes the bits but assume the rate control knows what it does.. and if there are significant problems (like in VSS), my samples should include it at some point.

To be more precise: As I can see nowWell, but you had to first accuse me of delivering improper results, without so much as any proof whatsoever. To put it midly, that's not very nice.

Do you know how many people out there actually would in your place? I can't smell things you didn't write down....Let me answer that with a quote from the articleI used GordianKnot for the bitrate calculations (it can calculate the effective overhead of using VBR MP3 audio).
So there you have it.. it can effectively calculate the overhead of using VBR MP3 audio. Do I have to use 20pt fonts in bold red? And GKnot also considers the raw AVI overhead even if you don't add any audio, not just the audio muxing overhead.

[Koepi]

You need to ask the codec coders for getting that information, it is hard to test a codec for beeing thread safe if you don't know the internals.
The test for that will be huge: you'd need to start 2 encoding instances with _all different_ settings. Then you need to use the same settings on encodes with only one instance at a time. Then you can do a diff on the results.
There you'd see if the encodes were affected by global variables or shred memory usage. But you couldn't tell _where exactly_ the error is (well, this part wasn't really your question though).

Those errors culd sneak into every codec at any stage (and be solved the next update) without anyone even noticing this (I mean the developers here).

I suggest you do such tests and report the results?

Cheers
Koepi

[darth rosenberg]

I can only say that it appears to work flawlessly with xvid 1.0.1. One problem: It doesn't lock the video.pass files for write access. You can use the same filename in both instances and get 2 bad files (that's of course an error only the user is responsible for, but nevertheless one the codec could catch) :D Though i'd have to retest with the latest build

[babayaga]

Originally posted by SeeMoreDigital
The second pass encoding time was very slow and never seemed to go above 4fps. But would have been significantly quicker if I had encoded to an 640x272 square pixel frame.
Doom9 was given a faster version than the one currently in Recode (about 20% faster) and we did not choose the settings that give the absolute best quality but a tradeoff between speed and quality like Xvid for instance.

Regarding the quality settings (in-loop deblocking set to -2 and psycho-visual enhancements set to 2), it is a tradeoff between blocs and detail preservation. Unfortunately, I did not realize that Doom9 was going to watch the movies on an LCD screen where blocs are much more annoying (I would not trade my old CRT :)

[Doom9]

I would not trade my old CRTAgainst a 23" 16ms 16:10 TFT with a native HDTV resolution? Come on. Everybody who ever comes into my room gets really jealous.

As far as HyperThreading goes, the Athlon can't do it, and my P4 is too old to offer Hyperthreading , and those are all the machines I have. Now that I think about it, I have a W2K3 server at work with a 3.2 GHz HT CPU that I could've taken home over the holidays and get the encoding done even quicker.. but it's too late now. But there'll be dual core Athlon64 next year, so..

[bond]

doom9, thanks a lot for this great comparison!

i hope next time we will see a ready to rumble x264 in there too, its already very good imho and already doesnt need to hide itself :)

[SeeMoreDigital]

Hi babayaga,

20% faster for the new release!

Before the new release comes out, what settings do these equate to in the current existing release?


Cheers

And I'll stick with my current plasma!

http://img134.exs.cx/img134/1847/smdbigscreen6to.jpg

[Doom9]

i hope next time we will see a ready to rumble x264 in there too, its already very good imho and already doesnt need to hide itselfI made an addendum to Q6 that I consider very important, but that's probably often missed.

[neo75903]

@doom:
Thanx for the great codec shootout.

@seemoredigital:
wow nice plasma, you are probably the one who can clearly see the differences between the codecs :)

[Doom9]

wow nice plasma, you are probably the one who can clearly see the differences between the codecsActually, LCD screens offer a better picture than Plasma (and I think they're supposed to last longer as well).. hence the price difference between a plasma and an LCD TV of the same size. And for that kind of diagonal, I'd like a higher than HDTV resolution ;)

[babayaga]

Originally posted by SeeMoreDigital
Before the new release comes out, what settings do these equate to in the current existing release?

It's the same since we've not shown new features for this comparison.

BTW it's unclear to me that 2 references are so usefull on the 2 movies.
Originally posted by SeeMoreDigital
And I'll stick with my current plasma!

For watching movies, I'm not sure yet but i'm old fashioned :) Anyway, flat screens are for sure the trend ...

[SeeMoreDigital]

Actually one of the reasons why I bought this particular plasma was it's panel life... which is supposed to equal/exceed most CRT's!

It offers a vertical resolution of 1024 pixels which should be more than good for most HD content... There's no doubt though that a good quality LCD screen (such as Doom9's) will offer better contrast and deeper blacks ;)


Cheers

[SeeMoreDigital]

Originally posted by babayaga
Anyway, flat screens are for sure the trend ... Happily they're not just a trend... they are the future. And once everything becomes fully digitized.... There will be no need to mention the ITU specs again ;)

[robUx4]

Originally posted by celtic_druid
The codec doesn't need to know the container/settings, the bitrate doesn't take that into account, that is upto the user.

Well, you could have made the test with a container that supports all the codec in this comparison. This way the audio and overhead would be the same. Only the codec and the frames it produces would differ... So in the end here you compare pears and apples. The container and the audio differs (in size and quality). It's not just a codec comparison. Maybe the title should be changed.

edit: BTW using the proper container could also solve that "frame finding" problem. Since when seeking to a frame in DShow, it would seek to the previous I frame and decode all the needed frames up to the point.

[Doom9]

Well, you could have made the test with a container that supports all the codec in this comparison. And the fact that the only container that would be a viable solution would be MKV and you're a member of the Matroska team did have nothing to do with that comment, right? :devil: But can you mux raw AVC streams, or transmux files created with WME into Matroska? And then, you cannot directly put RV into Matroska either, you need an RMVB file to transmux if I'm not mistaken.. and in order to find the proper video bitrate, you first have to encode RV once, transmux to Matroska, then extract the AAC audio track, and from that do the bitrate calculations again taking into account the actual audio size and finally encode again. And RV is slow.

It's a simple fact that it is simply not possible to use one input, one tool and have one type of output and it never will be possible. These times have passed.

And when talking about audio sizes, the lower overhead of the MP4 using containers was compensated with larger audio files, so you cannot say they had an unfair advantage. And if anybody actually had the right to complain, it would be the representatives from the various contestants. Yet, I'm not hearing anything negative from them regarding the matter in which this comparison was conducted.

edit: BTW using the proper container could also solve that "frame finding" problem. Since when seeking to a frame in DShow, it would seek to the previous I frame and decode all the needed frames up to the point.That I'm not going to try out until I have your personal assurances that it'll actually work. RV10 and WMV9 are freely available.. so go ahead, try and report back. And one thing I can tell you for sure: the codecs that caused the most problems don't act the way you described. they start decoding from the keyframe AFTER the frame that I'm looking for. I very much doubt the container has anything to do with that.. imho it's the playback filter that determines that behaviour. The fact that seeking wise DivX5 and XviD behave exactly the same when decoded by ffdshow seems to confirm that.

[darth rosenberg]

And when talking about audio sizes, the lower overhead of the MP4 using containers was compensated with larger audio files, so you cannot say they had an unfair advantage. Nope, but you still can say that there is some uncertainty as to where the difference to the desired file size came from
they start decoding from the keyframe AFTER the frame that I'm looking for. Scroll back a bit :p Though you should contact the "creators" of such bugs when you find them...

[robUx4]

Originally posted by Doom9
And the fact that the only container that would be a viable solution would be MKV and you're a member of the Matroska team did have nothing to do with that comment, right? :devil:

The fact that you are running this site has nothing to do with the fact that you publish comparisons ? Now instead of talking about the one word I won't pronounce, why don't you tell me how wrong is my statement ?

Originally posted by Doom9
But can you mux raw AVC streams, or transmux files created with WME into Matroska?

Yes.

Originally posted by Doom9
And then, you cannot directly put RV into Matroska either, you need an RMVB file to transmux if I'm not mistaken..

I think you used AutoRV which can output Matroska direclty (but I never tried any such program). There are tools that could do that in one pass. Maybe you should spend more time searching for what is happening out of here.

Also the target bitrate and possible try and test doesn't matter to me. In the end what any user wants is something that fits on 1 or 2 CDs. In the end you compare encodings that have different bitrates just because you didn't want to run another encoding.

Originally posted by Doom9
And when talking about audio sizes, the lower overhead of the MP4 using containers was compensated with larger audio files, so you cannot say they had an unfair advantage.

So you mean making 2 mistakes (using different audio and different container) equals 0 mistake just because luckily the size fits on a CD ?

edit: I lost at my own game, I used the word Matroska once.

[darth rosenberg]

A new point: Doom9, you say if the user does the bitrate calculations wrongly, it's his fault, and you don't care. So far so good :)

Well, if the user cannot handle his burning app or is using a bad one, it's his fault as well, and you shouldn't care either. CDs don't really need the leadout, and every drive supporting RAW writing (in other words: every CD writer besides very few very old ones) can overburn at least 12 MB. In other words, if you don't take stupid users into account, the "tolerance" before giving the red card should be 12 MB

[celtic_druid]

The fact is though that if you are encoding to fit a given filesize then you would obviously want a codec with acurate rate control, therefor codecs that aren't acurate should be penalised, whether it be under or oversized, because who knows how it will turn out next encode?

Do the video stream overheads with mkv vary much between say VFW, RV, native AVC/ASP, etc.?

I don't really see that it matters much though about containers and overhead. If you are purely comparing video codecs then surely the only important thing is to make sure that the video bitrate is the same (all raw video streams the same size). For instance if RV stored in MKV has a lower overhead then does that mean that it gets to use a higher bitrate? Or instead you use the same bitrate as the others and have an undersized file?

Then again the purpose of the test is really more about the practical use isn't it? So if you can get away with a higher bitrate for the video of one codec and still have the actual output fit on a CD then that is what you would do.

Here's another one. Wouldn't XviD without packed bitstream have an advantage over say DivX with packed bitstream?

[Doom9]

Though you should contact the "creators" of such bugs when you find them...What makes you think I didn't? And what makes you think I was not eventually going to find out about your double registration? 14) Multiple registrations are prohibited and are grounds for immediate account deletion.

Now instead of talking about the one word I won't pronounce, why don't you tell me how wrong is my statement ?It's a perfect example of using whatever chance comes along to promote Matroska. I admit, using it for a comparison would be a major PR boost for you. But then, any over or undersize could be conveniently blamed on the container by codec makers. If I stick to the container they use by default, they have no such recourse.

I think you used AutoRV which can output Matroska direcltyI don't find that option.. perhaps it was only in AutoRV9? I saw there's a producer plugin though that allows MKV output from producer.

Maybe you should spend more time searching for what is happening out of here.You just gotta love that, you spend countless of hours and nightshifts and that's what you have to listen to? Inconsiderate is not even a strong enough word for that. I don't ask that you like what you do, but I don't go around dissing Matroska, do I?

So you mean making 2 mistakes (using different audio and different container) equals 0 mistake just because luckily the size fits on a CD ?One strike away from permanent ban.. what can I say.

[babayaga]

Originally posted by Doom9
And if anybody actually had the right to complain, it would be the representatives from the various contestants. Yet, I'm not hearing anything negative from them regarding the matter in which this comparison was conducted.

My breaking point toward VP6 for starting thinking of a complain was at about 753MB on Revolutions, my first try when encoding :) and only if a small set of scenes were reviewed.

Since a representative set of scenes were reviewed and the oversize is smaller, from ATEME point of view, the test is as fair as it can be (as it was last year).

I'm not saying that all remarks are pleasing (some of them are ;), but since I don't have the same eyes/taste than Doom9 there is nothing I have to complain about.

Pierre Larbier (aka babayaga)
ATEME

[Doom9]

My breaking point toward VP6 for starting thinking of a complain was at about 753MB on Revolutions, my first try when encoding Well.. they got theirs already on the first page (the recommendation not to use it for DVD backup purposes weights rather strongly imho), and if I had gotten a build with a rate control that doesn't oversize, I'd have definitely used it.

Well, if the user cannot handle his burning app or is using a bad one, it's his fault as well, and you shouldn't care either. CDs don't really need the leadout, and every drive supporting RAW writing (in other words: every CD writer besides very few very old ones) can overburn at least 12 MB. In other words, if you don't take stupid users into account, the "tolerance" before giving the red card should be 12 MBWrong, when we consider that, I'd have to set the target size to 712MB with no headroom. Or say 710MB with 2 MB headroom. It's just a matter what you're aiming for. And overburning is dangerous and tends to produce that CDs that cannot be read everywhere and are more error prone. And I'd like to invoke my r16 right and end the container and size discussion right now.

[Manao]

darth rosenberg : your new point is unvalid : what if the user wants a final size of 708 MB, because he knows its CD burner can do overburning ?

Robux4 : AVC into MKV wasn't possible when the test was done.

[SeeMoreDigital]

Oh well,

Maybe it would have been fairer to have had all the Mpeg4 codecs output their content into MP4 container. And all the other video codecs stream types into their generic containers ;)

Personally I can't see why this "container overhead issue" is being made into "such an issue".

As mentioned earlier, this kind of discussion should really be confined to another thread. Especially as such discussions seem to involve the "usual suspects" and detracts from the spirit of Doom9's tests!


Cheers

[Doom9]

@Manao: thank you, beat him with his own weapons :) And according to the latest posts in the mkvtoolnix thread in the container forum there are still playback issues and an mkvtoolnix build that would support AVC muxing will only be released in January, at the earliest.

[Sharktooth]

Originally posted by Doom9
Well.. they got theirs already on the first page (the recommendation not to use it for DVD backup purposes weights rather strongly imho), and if I had gotten a build with a rate control that doesn't oversize, I'd have definitely used it.

Well VP7 is on the way and from what i heard it will be "astonishing". But we kwow how those things are influenced by marketing... However i like the VP6.2 (or 6.4) codec, expecially the fact it has a VFW interface and i can use it inside virtualdub. Sure now im playing with AVC but i dont like Recode at all.
I wish ateme had released the commandline encoder with a separate GUI.
Seriously, that's the worst encoding app i've ever seen (buggy and stuff...) and doesnt unleash the true potential of the codec.
Unfortunately i think it wont happen for commercial reasons but i hope there will be other AVC codecs (comparable in quality with NeroDigital) with DS, VFW or commandline interfaces that could be used in other encoding apps.

[Tommy Carrot]

Originally posted by Sharktooth
Seriously, that's the worst encoding app i've ever seen (buggy and stuff...) and doesnt unleash the true potential of the codec.
Unfortunately i think it wont happen for commercial reasons but i hope there will be other AVC codecs (comparable in quality with NeroDigital) with DS, VFW or commandline interfaces that could be used in other encoding apps.
Yep, i have the same opinion about nero, the codec is awesome, but i don't like recode (and the whole "the codec is only usable with our own encoder app" concept), so i'm reluctant to encode any important stuff with it, although the quality is superior.

[jggimi]

Once again, Doom9, you've done an admirable job of trying to produce a fair comparison of different scenes with equivalent bpp values.

Nice job!

Your container detractors should have read FAQ Q7 (http://www.doom9.org/codecs-203-6.htm) before posting.

[The Edge]

Just finished reading the whole shoot-out. Nice work Doom9! ;)
Cheers for all the effort put in.

[DeathTheSheep]

Mmm... so ND AVC wins here too. Wow, it must truly be the best codec ever. However, because it is only usable with recode and MP4, I simply ... well, can't use it, especially with VDub(mod), because, as Tommy Carrot pointed out:

"i don't like recode (and the whole "the codec is only usable with our own encoder app" concept)"

VFW? That would be Absolutely Perfect, but might rely on "hacks" to use B-frames and will "never utilize the true potential of AVC." Maybe some sort of controllable filter-based encoder (like in graphedit maybe?)...
I wish ateme had released the commandline encoder with a separate GUI.

Mmm...NICE...
Well, just a thought. A... request, if you will.

Cheers, baa

[babayaga]

Originally posted by DeathTheSheep
Mmm... so ND AVC wins here too. Wow, it must truly be the best codec ever. However, because it is only usable with recode and MP4, I simply ... well, can't use it, especially with VDub(mod), because, as Tommy Carrot pointed out:

"i don't like recode (and the whole "the codec is only usable with our own encoder app" concept)"

Ok guys, we get the message :p

[DeathTheSheep]

Eh, sorry for the bluntness -- I dont wanna anger anyone... baa, baa...

[PlazzTT]

Great job, Doom9!

Always a great read!

[Atamido]

Good review for the most part. There were a few things that I was a little disappointed on.

1. The codecs that missed their marks by a long shot should have been reencoded. Granted, there should definately be notes to the effect, but why would you compare two clips with different bitrates?

2. What is up with the credits? Maybe I missed the segment where it was talked about? Were they encoded seperately? If not, why not? How much bitrate was devoted to the credits for the different codecs?

3. There should be a listing of exact bitrates for the different video formats. The information for the video in the AVIs is available within this thread, but still not on the shootout. The RV9 can be put into Matroska to determine the exact size of the video data. I guess the AVC could also be determined the same way, although I would imagine there is another way to do it.

4. Not a flaw, but a nice touch would have been to know how close to the previous I frame the image was for each codec.

Other than that, good job. The layout of the images is superb and the option to view the lossless PNGs is an excellent option.

[SeeMoreDigital]

There's no denying that "arguably" Nero's Mpeg4/AVC codec sets a new benchmark for other codecs to follow...

But for me, what I would have liked to have had confirmed was how well Nero's Mpeg4/ASP codec performed against other Mpeg4/ASP codecs such as, XviD, DivX and 3ivx!


Cheers

[niamh]

2. What is up with the credits? Maybe I missed the segment where it was talked about? Were they encoded seperately? If not, why not? How much bitrate was devoted to the credits for the different codecs?
Though I can see the point of this Pamel,and somehow agree with it, my opinion is that in practical life, credits will be encoded with the movie, and if a codec is going to waste bits on credits, well then it should be penalized in the test, because it will penalize itself in a real encoding.
A codec should know where to apply more bits and where to save some IMO, otherwise tests would eventually be reduced to encoding stills at a fixed bitrate, and is there a sense in that? :)

I think there are 2 trends of people here, (as there are in every single codec test that appears).... the ones who want a totally scientific codec test, precisely precise (and in theoretical theory, they are in the right ;)), but quite removed from encoding reality IMO, and the others who just want something that's immediately applicable to real encoding and DVD back-ups ... I lean in the others camp, so I'm fine with the test, and it seems fair to me ; besides, it looks like no matter how one will redo that test, the winner will be the same regardless.... and yes, we still love Xvid to bits ;)

[Neo Neko]

I think the reason the credits were done as they were was simply because not all codecs offer such features as zones. Which are less of a codec improvement and more of a user end tool since the user must decide how to use them. Also it is more than likely the way most people will encode. Thereby giving the most indicative results for most people. You or I may use Zones or EKG etc but alot of people don't. What doom did was a base standardised test using only general codec options. Not sitting for a few hours tweeking a single source as I have been known to do in the past. ;)

[temporance]

Originally posted by niamh
Though I can see the point of this Pamel,and somehow agree with it, my opinion is that in practical life, credits will be encoded with the movie, and if a codec is going to waste bits on credits, well then it should be penalized in the test, because it will penalize itself in a real encoding.
Credits can make a BIG difference to the rest of the movie. I replicated one of the encodes from the previous codec shootout and found that the % filesize occupied by the credits was disproportionately high. And codecs (DivX and xvid) were so different in their treatment of credits that the effective bitrate available for the remainder of the movie was different between codecs. The average bitrate of doom9's scrutinised scenes also varied. (see my original post at http://forum.doom9.org/showthread.php?s=&postid=423390)

Codecs do not know that a user is not interested in the quality of his credits unless they are told about them. If credits are encoded along with the rest of the movie then, IMHO, a segment should be take from the credits for comparison ;)

Btw, it seems QPel's forte is scrolling credits.

[SeeMoreDigital]

Personally, I can't see the point of encoding the credits at all.

With most movies, it's quite a straight forward task setting say, DVDdecrypter to rip a movie without the chapter that contains the credits!

Jeez, if you want to know who's made the film, either rip and encode "that chapter" as a totally separate file, look on imdb.com, or wait for the movie to appear on TV :)


Cheers

[niamh]

Credits can make a BIG difference to the rest of the movie.
I don´t disagree with that in the least. Personally I encode credits though, so if a codec test was made without credit encoding, and gives such and such results, and it turns out that in effect, codec x has a good result in that case, but uses up a lot of bitrate on credit encoding (which is basically black stuff), making a BIG;) difference to the total encode, well then,I´d feel cheated.

If credits are encoded along with the rest of the movie then, IMHO, a segment should be take from the credits for comparison
Very good sweat-effective solution :) I would be interested to know,actually.
Btw, it seems QPel's forte is scrolling credits.
Well the settings were given by the respective devs of the codecs, you can´t blame them for giving relevant settings,can you? :)

[Ark]

Originally posted by SeeMoreDigital
Personally, I can't see the point of encoding the credits at all.

With most movies, it's quite a straight forward task setting say, DVDdecrypter to rip a movie without the chapter that contains the credits!

Jeez, if you want to know who's made the film, either rip and encode "that chapter" as a totally separate file, look on imdb.com, or wait for the movie to appear on TV :)


Cheers

Well, i like to hear the music that plays in the end credits, so i try to maintain them, and i don't like very much to suddently cut the audio right after the last scene, it destroys all the atmosphere :p

[niamh]

Maybe we should make a poll " do you encode credits or not?" ;) this way we´d know who´s in the majority....I agree with you Ark.......nothing worse than a movie going PloP suddenly.

[aaar9800]

Originally posted by Ark
Well, i like to hear the music that plays in the end credits, so i try to maintain them, and i don't like very much to suddently cut the audio right after the last scene, it destroys all the atmosphere :p

Couldn't have said it better

[SeeMoreDigital]

Originally posted by aaar9800
Couldn't have said it better Oh well.... Each to their own!

[Doom9]

@DeathTheSheep: You should be able to use the ND filters in graphedit.. just rename graphedit.exe to recode.exe (at last that's how it worked with the asp filters).. I just never really figured out the PAR flag so I'd be grateful if somebody could eventually explain that to me.. I get DAR but PAR seems weird.. they use really weird numbers that I cannot put in any relation to the encoded and playback resolution.

I'm sure we'll find plenty of people who fit into one of the three end credit categories:
1) credits are cut
2) credits are encoded as part of the movie
3) credits are encoded separately, normally using special curve scaling features.

I fully understand the reason for the use of a lower bitrate for end credits (though personally I don't care much to see them at all), and I would use end credit treatment, if it were not for this: end credits bitrate is not a feature of many codecs. This can be compensated for with special tools (like in case of DivX5 encoding in GKnot), but in most of the cases, this would required a special encoding session, and thus basically a lot of extra work and a whole can of worms that can bit you at the wrong moment and give me even more to do. I hope some of you read the last point of my FAQ.. making a codec comparison is a huge effort, and my resources are scarce. Hence, encoding credits separately is off my list for now until I can get this done automatically and have the tools that take care of bitrate calculations and such for this special occasion.

But, in the absence of use of any special end credits treatment, I think it's reasonable to assume that no codec will cut the bitrate by 50% and use it someplace else. If it did that, it would also do the same for the intro with the scrolling letters, would it not? And I'd not miss that because the intro is a scene I review.

1. The codecs that missed their marks by a long shot should have been reencoded. Granted, there should definately be notes to the effect, but why would you compare two clips with different bitrates?This mostly concerns VP6. I agree that it's not quite fair, that's why even on page one, just after presenting the sizes, I clearly state I cannot recommend VP6 for DVD backups. Though, your comment does raise an interesting question: What is the point at which I cannot accept an entry because it gets an unfair advantage or disadvantage over the others? I did that with the Moonlight codec. So, I think that's one point we can go on discussing: How much oversize is allowed? I tend to rather disqualify a codec, than take a blind shot and encode again (especially VP6 was slow as hell), it could potentially waste a lot of time. But, next time I will ask if I can use the standard bitrate calculations provided by GKnot (for codecs using the AVI container), to reach the size target. And there needs to be some cutoff. Where would you place that? 10 MB? 15MB? 20MB? And, should the same apply for undersize, or should undersized entries be allowed as long as the quality isn't abysmal?

3. There should be a listing of exact bitrates for the different video formats. The information for the video in the AVIs is available within this thread, but still not on the shootout. The RV9 can be put into Matroska to determine the exact size of the video data. I guess the AVC could also be determined the same way, although I would imagine there is another way to do it.There is another way. Here are the exact video bitrates for the two NeroDigital codecs:

ND Main Profile: (bitrate asked for, bitrate received)
SPR: 1025091 bits/s - 1025.08 kbit/s
Matrix3: 627266 bits/s - 627.25 kbit/s
Futurama: 1000094 bits/s - 1000.03 kbit/s

ND High Profile
SPR: Forgot to save them, but you can derive them knowing the overhead per frame (final size and audio size are known).
Matrix3: 627266 bits/s - 627.27 kbit/s
Futurama: 1000094 bits/s 1000.00 kbit/s

The problem with this is the following: It serves very few people, and it can actually be derived on your own given the info in the comparison (okay, I need to add the exact number of frames each source has). Knowing full video size, number of frames, framerate and audio file size you can derive all those values (GKnot can calculate the overhead for you). But the derivation is time consuming. Page one of the comparison already takes more than 3 hours as it is, and is probably already overloaded. The more info I add there, especially info that you can derive by yourself, takes my own time away, and since I tend to think it's not something most people are interested in, I prefer not to spend that additional time. And, being given all the info you need to duplicate an encoding session with RV10, you can derive those values as well.. just takes you an encoding session.

4. Not a flaw, but a nice touch would have been to know how close to the previous I frame the image was for each codec.Here also I have to question how many people actually are interested in that info. And, I do not know how to find this out for all codecs. The ones that have a VFW interface are no problem, that's what VDUB is for, and even if there's only a DS interface, as long as the filter supports all forms of seeking (there's a seek to the next/previous keyframe), it could be done, but what do you do if the DS filter doesn't support that kind of seeking and if there's no VFW interface?

[babayaga]

Originally posted by temporance
Credits can make a BIG difference to the rest of the movie.
On Revolutions, end credits represent about 7% of all movie duration (~13 000 frames out of ~186 000).

And 7% more bitrate makes a big difference on the quality of the video : something like the difference between VHQ1 and VHQ4 in Xvid and more than the difference between our Main Profile and our experimental High profile.

[SeeMoreDigital]

Originally posted by Doom9
... I just never really figured out the PAR flag so I'd be grateful if somebody could eventually explain that to me.. I get DAR but PAR seems weird.. they use really weird numbers that I cannot put in any relation to the encoded and playback resolution. In my opinion, when it comes to generating encodes from 4:3 or 16:9 Mpeg2/DVD sources, PAR calculations are less important than DAR calculations!

For those interested, this is why I wrote this: -

http://www.SeeMoreDigital.net/03_Video_Only_Info/Why_I_don't_follow_ITU601_specification.html


Cheers

[Doom9]

I'm just uploading a few FAQ addendums picking up some of the issues discussed this time. But I guess I'll have to keep adding things for every new comparison. I have also added the number of frames, as well as the framerate of each source. That way you should be able to derive stats on your own. I'm also looking for ways to determine RMVB overhead and if it's possible to encode only video and add an AAC stream to it (and how to figure out what kind of overhead that would add)

ut for me, what I would have liked to have had confirmed was how well Nero's Mpeg4/ASP codec performed against other Mpeg4/ASP codecs such as, XviD, DivX and 3ivx!you're not the only one. I'd also have liked to know how HDX4 performs with the film grain reconstruction on (so that the grain would be encoded normally and not filtered out)... but the number of codecs...

I've been thinking, that beside a new animated source (we'll get to that in 2005), there needs to be another way to conduct a test more locally, and so that it'll take less time (so it can be done more often).. throwing in all codecs will get excessively hard and that much free time I spent this time is a rarity for me. So I was thinking what if I separate the codecs in categories like ASP, AVC and proprietary, face them off against each other all in their own category, then face off the winners? Or perhaps you have other ideas as well?

[babayaga]

Originally posted by Doom9
I've been thinking, that beside a new animated source (we'll get to that in 2005), there needs to be another way to conduct a test more locally, and so that it'll take less time (so it can be done more often).. throwing in all codecs will get excessively hard and that much free time I spent this time is a rarity for me. So I was thinking what if I separate the codecs in categories like ASP, AVC and proprietary, face them off against each other all in their own category, then face off the winners? Or perhaps you have other ideas as well?
Another way is to have a pool of reviewers, not just you.
Assuming there are 3 reviewers and 3 movies :
- each reviewer encodes one movie with all codecs
- he extract let's say 7 2mn video samples out of its encoded movies (this requiers a tool to extract a sample out of an encoded movie but i'm sure all companies have this kind of tool).
- then all reviewers swap their samples and vote.

As a result, each reviewer is only responsible for extracting representative samples out of his movie (and taking the pictures). The work load is divided by the number of reviewers and the final word is still yours.

BTW, is it possible to have the extra-old codec comparisons you made in 2001 ?

[Doom9]

BTW, is it possible to have the extra-old codec comparisons you made in 2001 ?I'm not sure but I'll check.

[krackato]

I'm just a little confused about the Nero AVC codecs. In the shootout they were referred to as Main Profile and High Profile (MP and HP)

But all I see in NeroRecode 2.2 is the following:

Maximum Definition AVC
Mobile AVC
Portable AVC
Standard AVC
Cinema AVC
HDTV AVC

So which on of those did Doom9 use? Also, I'm a little confused as to which supposedly offers the best quality between Maximum Definition, Cinema and HDTV.

Or is everyone using a totally different version of Recode than I am?

[Doom9]

in Recode, you have an older version of the Main Profile codec. All those profiles in Recode are Nero's own invention.. if you switch between them and look at the settings, you'll notice that certain features are activated / deactivated, and certain settings differ... for instance, the number of reference frames, the number of b-frames, etc.

And, as it says on page one, I got a special commandline encoder that you cannot get.

[babayaga]

Originally posted by krackato
I'm just a little confused about the Nero AVC codecs. In the shootout they were referred to as Main Profile and High Profile (MP and HP)

But all I see in NeroRecode 2.2 is the following:

Maximum Definition AVC
Mobile AVC
Portable AVC
Standard AVC
Cinema AVC
HDTV AVC

So which on of those did Doom9 use? Also, I'm a little confused as to which supposedly offers the best quality between Maximum Definition, Cinema and HDTV.

Or is everyone using a totally different version of Recode than I am?
Doom9 did review the video codecs. This is not related to NeroDigital profiles which are designed for compatibility with standalones. Besides, he did not use Recode but beta internal versions of the codecs.

So AVC Main Profile (a generic MPEG-4 AVC definition) is the basically Recode codec with the same tools. The settings we did provide would fit in all NeroDigital profiles starting and above "Standard AVC".

The High profile codec (also a generic MPEG-4 AVC definition) is an early beta and the first High profile codec ever able to encode a full movie in a reasonnable time. Besides us at Ateme, Doom9 is the first in the world being able to write about the "High Profile experience" :)

[dvd_maniac]

@babayaga & Doom9

So when you say "We can not get"... You mean we will never get? Is this a tool that is designed for the next version of Recode? Does that mean that Recode will be noticably faster encoding AVC?

[slavickas]

Originally posted by dvd_maniac
@babayaga & Doom9

So when you say "We can not get"... You mean we will never get? Is this a tool that is designed for the next version of Recode? Does that mean that Recode will be noticably faster encoding AVC?

although i'm not babayaga || Doom9 :D

command line programs usefull for codec developers (easier to make things automated), while for end users there fancy one-click guis,

it's very unlikely to see cmdln version of codec for us "standart" users

[babayaga]

Originally posted by dvd_maniac
Is this a tool that is designed for the next version of Recode? Does that mean that Recode will be noticably faster encoding AVC?
Doom9 did receive command-line encoders in the form of the beta package .
Those encoders are beta versions scheduled to be integrated in Recode.
The Main Profile encoder will be integrated shortly, the High Profile is an early beta that will need some polish.
The Main Profile is faster and better than the current Recode version but share the same features.

You mean we will never get?
I honestly don't know.

[Joe Fenton]

Great comparison. I appreciate all the time you spent on it. Personally, I almost went nuts just flipping back and forth between the finished frames in the article. I don't see how you stayed sane while putting it all together. :D

The only real question I have is - who suggested that Futurama be encoded without b-frames in xvid? I've never seen a good encode of cartoons or anime with b-frames off. The difference is night and day on all my encodes. Sure, a b-frame tends to be lower quality, but it gives you a BIG savings on bits which can be reused elsewhere where they are actually needed. So some frames look worse, but overall the quality is TREMENDOUSLY better. I ask who told you not to use b-frames so I can complain to the right person. ;)

I usually encode credits the same as the rest of the movie. It's easier than trying to separate out the credits and process them differently. I would guess more people encode the credits the same as the movie than don't. What I wish for in the next year or two is proper variable frame rates. Right now, if you inverse telecine a movie, the credits are jerky because they were done via computer at 30Hz instead of 24 like the rest of the movie. Or worse, you get a mix of 24 and 30 Hz all through the movie due to special effects. This is becoming a particular problem in anime where more of the anime is being done by computer than ever before while the hand drawn sections are STILL shot on film at 24 Hz.

When you get to the point where VFR becomes part of the shootout, I suggest you use Cowboy Bebop as a test source. It has a good mix of hand drawn 24 Hz material and 30 Hz computer sequences throughout all episodes. Add in lots of pan and tilt shots, fight and chase sequences, and a wide dynamic range on the lighting and Cowboy Bebop will put any codec to the ultimate test.

[dragongodz]

@dragongodz: I have a 16 question FAQ for just that purpose so I don't waste my time replying.
and how many do you think actually read it ? not many by the looks of things. :)

infact that is why i put that bit, to try and get the message through. with the amount of B.S. and nonsense suggestions that followed from some its obvious they dont want to understand and have no intention of doing there own comparison so we can pick the crap out of it. :sly:

[SeeMoreDigital]

Originally posted by Doom9
So I was thinking what if I separate the codecs in categories like ASP, AVC and proprietary, face them off against each other all in their own category, then face off the winners? Or perhaps you have other ideas as well? I like this idea!

This would make it easier for us to determine which codec manufacturer has made the most progress from year to year, or from release to another release.

Speaking from personal experience, as I play most of my encodes in hardware I tend to generate them in Mpeg4 'Simple Profile' mode only (due to compatibility issues). And even in SP, the difference between say, NeroDigital, DivX, XviD, FFmpeg, Sorenson, 3ivx etc, at the same bit-rate, is quite staggering!

Yep... I'm all for this idea :)

EDIT: Also, once you've established your sources, generating encodes from (alpha, beta, pre-release) codecs as they appear throughout the year should save time... meaning only a "summing-up" is required at the end of the year.... Just a thought!


Cheers

[Mr_Schizo]

Thanks for this great comparison!

[lamer_de]

@Joe Fenton: First, you mixed up the terms Hertz (http://en.wikipedia.org/wiki/Hertz) and frames per second. Hz has nothing to do with framerates.

Second, variable framerate is pretty much codec independent and an issue of the container that is used. If you want vfr, you can already use matroska and Divx/xvid (probably any MPEG-4 codec will work, but I don't do DVD-"backups", so I don't care much for it. Another downside for me is that you can't edit the outcome (you can load it via directshowsource into vdub, but it's a major pain in the butt)). I think I read something that RV10 in rmvb supports it as well, but I don't use RV10. So this has nothing to do with the abilities of a codec.
CU,
lamer_de

[stephanV]

Originally posted by lamer_de
@Joe Fenton: First, you mixed up the terms Hertz (http://en.wikipedia.org/wiki/Hertz) and frames per second. Hz has nothing to do with framerates.
Its not unusual to call a frame a sample and Hz is quite commonly used for for sample rates. While fps is a more used and known unit, the use of Hz is not wrong. As stated in the wiki Hz is used for periodic events, which includes the displaying of frames at a regular interval. Hz = 1/s and there for has everything to do with rates.


Second, variable framerate is pretty much codec independent and an issue of the container that is used.
Not completely. Many standards (MPEG4 ASP, AVC, RV) include the capability of outputting VFR by dropping duplicate frames. While this is not exaclty what Joe Fenton was talking about it does excist. It would however complicate making screenshots... oh well.

[Valeron]

Thanks,Doom9!
Another great codec shoot-out.:D
But just a little confuse about the setting throw by the companies.
And I just read here first time that the VCM can use B frames,In-loop filter as well as the advanced profile. These features reference the say reg key! But MS always kept this information so privates. I never read them from any document.
So, some words about WMV9:
VCM&WME are the same encoder, but WME comes up with a ASF muxer(probably not a DShow filter,cause I can't found it in graphedit).
They both don't encode with B-frames by default.
My unconsciously exprience of encoding WMV9 with B-frames(I want to check the features in advanced profile, so set the reg key on.though the document from MS doesn't )with main profile(I didn't know it also work with main profile at that time!Because MS never tell!),found the seeking of output is really back, frame drops for nearly 3s till the decoder find the exactly I-frame I think.
This is why they suggested Doom9 not to use B-frames,maybe.

The final conclusion:even MS themselves do not have an encoder that can handle all the features of VC-1, they even can't do B-frames now.
It's probably the advanced features like Variable transform and etc is not available.

[Manao]

stephanV : VFR has nothing to do with the codec, and even less with dropped frames, but with the container. However, some codecs can take into account the fact that the video isn't CFR to gain a little efficiency ( for example, b-frame's direct mode in MPEG-4 ).

[KoVaR]

I have a new question for the FAQ: :cool:
Why use VirtualDub and then Nandub instead of VirtualDubMod ?

[Doom9]

I ask who told you not to use b-frames so I can complain to the right person.It's Isibaar, leader of the XviD team. So you'll have to go right to the top ;)

@ Joe Fenton: Due to my inheritent dislike of Anime (all I've seen so far was boring beyond reason), chances are about 0.1% that an Anime source will ever be included. Most likely, I'll replace Futurama with an animated Feature like Shrek, The Incredibles, or something similar (some of the less childish animated features from a major Hollywood studio). So VFR will never be an issue.

@babayaga: separating sources to testers sounds like a good idea to me, but you've been burned with betas yourself so it would raise the question of finding other reliable testers that can be trusted with a bunch of pre-release codecs. And, in the end even if I don't have to encode and make screenshots, I'd still have to spend all the time reviewing clips, and with 10 different codecs, that's still a chore. The lower the number of entries, the easier it getsto really compare all the codecs against each other.. the higher the number, the more I tend to only do a one on one until I have a feeling where to place the codecs, and then only compare them in their own category (for instance, the two ND codecs vs XviD vs VP6, 3ivX vs DivX vs HDX4 vs RV10, etc.).

@everyone interested in the commandline ND encoder: I suppose it's a political question, and there's little ateme can do.. it's up to Nero to decide if they ever make their codec available outside of Recode (except for NeroVision Express). But, isn't it still possible to use it in graphedit? Perhaps a tool could be written that connects the filters and gets you a nice MP4. Moonlight's AVC encoder for instance just connects the graphs, configures the filters in the graph and then plays it.

[Doom9]

Why use VirtualDub and then Nandub instead of VirtualDubMod ?For the kind of work I'm doing (encoding), VirtualDub works just fine, and it's the tool I have the most experience with. And when it comes to muxing (that's when I use Nandub), once again it's experience that makes me default to the tool I know. It should not matter if I switched out VirtualDub and Nandub for VDubMod but that's just a personal preference. Since I do not use OGM and MKV, the only advantage VDubMod would have is that it's just one software, but since Nandub still comes with GKnot, that point is kinda moot for me as well.

[techz]

After reading the extensive new Codec Shootout, and wanting to stay with divx, i think im missing out on alot. I want to start using Xvid, but its so much more complex, and with so many options, im a bit wary of it, it gave me issues with Animation DVD's and since Divx didnt, i stuck with it. But from what see of some XVID rips, its very good, but it still shows a few scenes with problems on Live Capture. And it tends to have a kind of ghosting, or retaining old frames then it after a few secs it becomes ok.

I was wondering if the new XVID 1.0 has a one click sort of auto setting or a simple XVID guide for beginners. And these custom Matrices thing is even more confusing. I use GKNOT btw and most of my XVID use will be there.

[Koepi]

"Ghosts" are definatly an effect of pre-processing (you mentioned captured source). Also, the degradations you see will be caused by that.

Don't compare apples and eggs ;)

XviD will work very well with defaults. Look at the xvid forum, there are several threads on which options could/should be changed (mainly: trellis on, vhq higher level, maybe a different matrix, maybe adaptive quantisation).

I hope this helps.

Regards
Koepi

[SeeMoreDigital]

Originally posted by techz
I was wondering if the new XVID 1.0 has a one click sort of auto setting or a simple XVID guide for beginners. And these custom Matrices thing is even more confusing. I use GKNOT btw and most of my XVID use will be there. I don't think you are alone in your thoughts techz.

I reckon there could be quite a few DivX users who are nervous at the thought of moving over to XviD, even though it clearly offers superior looking encodes!

Hey Koepi... It might be time for a new style GUI after all. I wonder whether the XviD team will agree too? ;)


Cheers

[stephanV]

Originally posted by Manao
stephanV : VFR has nothing to do with the codec, and even less with dropped frames, but with the container. However, some codecs can take into account the fact that the video isn't CFR to gain a little efficiency ( for example, b-frame's direct mode in MPEG-4 ).
I'm sorry but it does. It's a codec decission to drop a frame or not (e.g. in XviD and WM9). I'm not a big fan of that mode though. I'm not sure if XviD's mode is completely MPEG4 ASP compliant. I do know that the 3ivx muxer can remove the n-vops.

[Manao]

VFR isn't dropping frame ( at least not for me ), it's handling an input which has a variable framerate.

All modern codecs encode very well the second frame of two successive identical frames, so i don't see the point of dropping frames, except at very low bitrate.

[stephanV]

i dont see the point either, but you can create VFR streams this way with XviD and 3ivx. I guess RV and WMV do something similar.

VFR for hybrid material (24/30) makes much more sense, i totally agree with you there. :)

[bond]

actually xvid's frame drop option doesnt really drop frames, but instead outputs n-vops (if there are duplicate frames, which detection threshold can be adjusted with the frame drop option in xvid)

so to say xvid will never output a vfr stream, but cfr with n-vops. its the container muxer's decision to really drop these n-vops and create a vfr stream instead (as its possible with the 3ivx dshow muxer and mp4box)

to my knowledge the same goes for the 3ivx encoder, with the difference that you cant adjust the duplicate frame detection threshold in 3ivx as its possible in xvid

that goes for both: vfw and dshow

[Mug Funky]

thanks for the comparison, doom9!

i've read the bits without images, but until i get my bandwidth back (my cable account chokes off to 20kbps when i reach my monthly limit of the 1000 MB annoyingly mislabeled as "1GB") i wont be looking at the images :)

good to see Xvid still on top of the ASP ladder, and it's heartening to observe AVC's potential. i hope this time next year x264 is a contender (but i can do without a VfW encoder for it, as it really does cripple AVC's beauty to some extent).

one thing to note - i think joe fenton said that there's an increasing number of hybrid animations out there... well, all i can say is "HDTV to the rescue!!!1!11!". anime is now being made in 24p HD, and it then downconverted for DVD - GitS SAC, Saikano and Dead Leaves are 3 examples (the only 3 i've seen...), and they seem to have set the benchmark for others to follow. of course, this doesn't mean an end to field-blends for PAL people (the R4 version of Saikano is field-blended, but GitS SAC is a progressive speedup). hopefully by the time VFR is perfected, it won't be needed anymore :)

@ doom9: sorry to hear you've only seen boring anime :( i'm trying to think of one to recommend to you, but then some people just don't like it (my brother thinks i'm a tosser for collecting all this stuff... thinks it's nothing but highschool girls and robots. how right he is :)).

[Leak]

Originally posted by Mug Funky
anime is now being made in 24p HD, and it then downconverted for DVD - GitS SAC

...which of course has a 30FPS rendered intro... :D

np: Ulf Lohmann - Audrey (Pop Ambient 2004)

[LordRPI]

Originally posted by Mug Funky

@ doom9: sorry to hear you've only seen boring anime :( i'm trying to think of one to recommend to you, but then some people just don't like it (my brother thinks i'm a tosser for collecting all this stuff... thinks it's nothing but highschool girls and robots. how right he is :)).

There's this anime that's really funny, but overall it's pretty poor.

Just take a look at lamer_de's avatar. Ebichu!

[SeeMoreDigital]

Well shock-horror....

I have to admit I don't like Anime either - although I understand the fascination!


Cheers

[babayaga]

Originally posted by Doom9
separating sources to testers sounds like a good idea to me, but you've been burned with betas yourself so it would raise the question of finding other reliable testers that can be trusted with a bunch of pre-release codecs.
To keep the validity of the review, you have to encode full movies because encoding just short sequences like trailers might not be representative of the codec capabilities.
For instance, VP6.2 has a very high coding efficiency but their rate-control over a full movie kinda lower the native performance of the codec. I think it's just the opposite for Xvid.

Since long encodes have to be done, there is still the issue of the encoding time.
There are only two way to reduce a single man workload :
1. use several workers
2. automate the job
Since the second option is impossible, you'll have to find guys you can trust. It should not be so difficult :)


Originally posted by Doom9
And, in the end even if I don't have to encode and make screenshots, I'd still have to spend all the time reviewing clips, and with 10 different codecs, that's still a chore.
I assume in the following you want to sort all the codecs based on a subjective quality test made by a single reviewer.

In sports, they use 2 basic systems :
- tennis : direct elimination until there is a winner. It gives the minimum number of individual matches but it does not permit to sort the complete set of players.
- football championship : every team meets every other team and points are gathered for each match. The number of matches is very high but at the end, the set of teams is perfectly sorted.

An there are mixtures of the 2 techniques :
- football world-cup : start with groups and end with direct elimination between the winners of each group. The team set is not completly sorted but it's more fair than tennis.
- sumo : like the football championships but with a reduced set of opponents choosen basically on their rank. There are individual matches at the end in case of ties. The set of player is well sorted but not perfectly though. It further permit to a badly ranked player to finish first in a much more fair way than in tennis.

I prefer the sumo way since it gives a sorted set with a reduced number of individual matches : for 10 codecs, this leads to about 25 individual comparisons, 4h for a single reviewer needing 10mn for each match. This method relies on transitivity (if A is better than B and B better than C then A is better than C) which is highly desirable.

The opponents could be choosen on the basis of their rank in an objective test, for instance the coding efficiency on a trailer like Sagittaire's test.

Let's do a simulation with imaginary results.

Initial rank based on coding efficiency (PSNR overall on a trailer) :
1. ND HP
2. ND MP
3. VP 6.2
4. RV10
5. WM9
6. VSS
7. DivX
8. XviD
9. HDX4
10. 3ivx

Then the reduced number of individual matches based on the initial rank (4 matches per codec). I give 4 points for the winner, 2 point for a tie and 0 for the looser :
1. NDHP vs VP6.2 : 4/0
2. NDHP vs WM9 : 4/0
3. NDHP vs DivX : 4/0
4. NDHP vs HDX4 : 4/0
5. NDMP vs RV10 : 4/0
6. NDMP vs VSS : 4/0
7. NDMP vs XviD : 4/0
8. NDMP vs 3ivx : 4/0
9. VP6.2 vs WM9 : 4/0
10. VP6.2 vs DivX : 4/0
11. VP6.2 vs HDX4 : 4/0
12. RV10 vs VSS : 4/0
13. RV10 vs XviD : 2/2
14. RV10 vs 3ivx : 4/0
15. WM9 vs DivX : 2/2
16. WM9 vs HDX4 : 4/0
17. VSS vs XviD : 0/4
18. VSS vs 3ivx : 0/4
19. DivX vs HDX4 : 2/2
20. XviD vs 3ivx : 4/0

After the initial round, we have the following table :
1. NDHP : 16 points
2. NDMP : 16 points
3. VP6.2 : 12 points
4. RV10 : 10 points
5. XviD : 10 points
6. WM9 : 6 points
7. 3ivx : 4 points
8. DivX : 4 points
9. HDX4 : 2 points
10. VSS : 0 points

Then to solve ties issues, I add the following matches but this time I give 2 points for the winner, 1 for a tie and 0 for the looser :
21. NDHP vs NDMP : 2/0
22. RV10 vs XviD : 0/2
23. 3ivx vs DivX : 1/1

The the final results (the complete set is sorted with 23 individual matches) :
1. NDHP : 18 points
2. NDMP : 16 points
3. VP6.2 : 12 points
4. XviD : 12 points
5. RV10 : 10 points
6. WM9 : 6 points
7. 3ivx : 5 points
8. DivX : 5 points
9. HDX4 : 2 points
10. VSS : 0 points

ok, ok, it's too complex, but I love the idea :D

[Sharktooth]

OMG!

[niamh]

Great ! a codec Eurovision :D

Seriously, I would think a codec blind test poll would be interesting. As in, have all these great screenshots unnamed (as a,b,c,d,e,f etc), and have us public rank them , according to, detail preserved, blocking, colours,overall pleasing visual output or whatever (1st codec gets 4 points, 2nd 2 points, 3rd 1 point, others 0)...At 3 or 4 votes per screenshot, and 7 or 8 screenshots per movie, and 3 movies, it should give a pretty fair and interesting result.The fact that we do not know which is what would help greatly towards unbiasedness(that english?) :). Of course it doesn´t solve in the least who will do the donkey work ;)

[Doom9]

i hope this time next year x264 is a contender (but i can do without a VfW encoder for it, as it really does cripple AVC's beauty to some extent).Well, me too, but I could very much do with an official GUI, or encoding app. Let's face it, mencoder and ffvfw isn't going to make that codec, or Snow, popular. Both are just frontends and if there's a problem you never know what caused it.. compilation of the build you're using, the frontend? After the problems I've had the the libavcodec MPEG-4 codec last time I've had more than enough with non official and supported applications and I simply cannot include anything where I cannot turn to one person, get help and explanations.

It doesn't have to be a VFW codec, but something official and preferably something that takes AviSynth input ;)

[jggimi]

But the evaluation isn't of screenshots -- Doom9 evaluates scenes. The screenshots are just representative examples.

[niamh]

Yes, I know that jggimi, I thought it would be interesting anyway.

[Tommy Carrot]

Originally posted by Doom9
Well, me too, but I could very much do with an official GUI, or encoding app. Let's face it, mencoder and ffvfw isn't going to make that codec, or Snow, popular. Both are just frontends and if there's a problem you never know what caused it.. compilation of the build you're using, the frontend? After the problems I've had the the libavcodec MPEG-4 codec last time I've had more than enough with non official and supported applications and I simply cannot include anything where I cannot turn to one person, get help and explanations.

I don't think the situation is that bad with ffdshow. Sure, it has a lot of things stuffed inside of it, and that can confuse a lot of people first, but i think after you get used to it, it's quite simple to use, just don't mess too much with the settings if you don't know what they do. And Snow and x264 doesn't even have so many options, the only codec which can be really confusing is the lavc mpeg4 codec.

[bond]

Originally posted by Doom9
Well, me too, but I could very much do with an official GUI, or encoding app. Let's face it, mencoder and ffvfw isn't going to make that codec, or Snow, popular. Both are just frontends and if there's a problem you never know what caused it.. compilation of the build you're using, the frontend? After the problems I've had the the libavcodec MPEG-4 codec last time I've had more than enough with non official and supported applications and I simply cannot include anything where I cannot turn to one person, get help and explanations.

It doesn't have to be a VFW codec, but something official and preferably something that takes AviSynth input ;) actually akupenguin, the dev of x264, sees mencoder as the tool to use x264 with and its the tool he uses

imho i really like the commandline solution:
- its portable to other platforms,
- all the commandline options might be frightening at first sight, but with a nice gui no problem to use for newbies, maybe even easier than virtualdub ("one click" solutions easier possible). real does it the same way with its helixproducer,
- also mencoder supports a whole bunch of input formats (afaik all that ffmpeg supports) including dvds of course
- lots of advanced filtering options already available via commandline (lanczosresize and cropping being basic)
- .avs support is already possible!!! actually there are even two options existing already: milan's makeavis tool or aku's avs2yuv tool
- direct output to mpeg spec compatible .mpg is possible, supported already by commercial implementations, like moonlight and mainconcept (and something tells me .mpg will be used for hd-dvd too)...

anyways it will not be me to decide about how x264 will evolve :)

[DeathTheSheep]

So, this is what it comes down to--gui toting a commandline... I like it. But vfw still shouldn't die. Perhaps it should merely be ... the second priority...

[Doom9]

actually akupenguin, the dev of x264, sees mencoder as the tool to use x264 with and its the tool he usesI guess we'll see next time how much he's willing to take responsability for the w32 build I'll need for a comparison. And using external tools are always problematic.. Real is always a problem when it comes to encoding.. just look at the AutoRV10 thread.. I had to solve quite a few problems before I could even get started with RV10.. other than the settings themselves.
And that's not an exclusive to x264, it'll just as much apply to snow and the libavcodec mpeg4 codec.

Take besweet as an example.. it is an extremely powerful audio tool, and widely used.. but only part of automated solutions.. the official BeSweet GUI still scares people away, and who uses it via commandline only, honestly? Sure, a CLI tool works, and encavc was no problem so I doubt mencoder would be, either, but when it comes to ownership and taking responsability for problems, that's the point when you need somebody to setup up to the plate and offer his head for a bashing if something goes wrong. It cannot be that there are 10 different people you need to talk to and everybody blames somebody else.

[Joe Fenton]

Originally posted by Mug Funky
i've read the bits without images, but until i get my bandwidth back (my cable account chokes off to 20kbps when i reach my monthly limit of the 1000 MB annoyingly mislabeled as "1GB") i wont be looking at the images :)

Holy cow! I go through at least 1G a day! I'd die if I got limited to 1G a month. :)

hopefully by the time VFR is perfected, it won't be needed anymore :)

I think that's why it's not being worked on in any serious manner.

@ doom9: sorry to hear you've only seen boring anime :( i'm trying to think of one to recommend to you, but then some people just don't like it (my brother thinks i'm a tosser for collecting all this stuff... thinks it's nothing but highschool girls and robots. how right he is :)).

There's considerably more to anime than highschool girls and robots. One of the best animes currently airing (Monster) has neither. It's a psychological thriller. One of the funniest and most adult animes out (Ebichu as mentioned by someone else) has neither.

Unfortunately, when people think of anime, they think of Pokemon and Sailor Moon. It's the same as saying the only thing you get with American live action TV is "Saved by the Bell" and "Gilmore Girls". It grossly misrepresents the range and variety of shows available. Japanese anime is the same way. You have everything from educational shows meant for toddlers all the way to hardcore pornography.

The Japanese take anime more seriously than live action TV. If you've ever watched Japanese dorama, you've probably thought that Japanese live action is about 20 years behind American live action TV. Well, Japanese anime is about 20 years AHEAD of American animation.

[Morbo]

Great read as usual,but am still waiting for a mpeg2 shootout of some kind....

Since thats something everyone can watch,use now..:rolleyes:

Hope you all have a happy New Year!

[Doom9]

Since thats something everyone can watch,use now..Uhh.. and you can't with an MPEG-4 ASP or AVC codec? If you have a computer to post here and it's not a piece of crap, there's no problem playing MPEG-4 ;)

[aaar9800]

Originally posted by DeathTheSheep
But vfw still shouldn't die

oh, yes it should

[Tommy Carrot]

Originally posted by aaar9800
oh, yes it should
As long as there is no widely accepted API which could take its place (and i don't think directshow can), it shouldn't.

[bond]

Originally posted by Tommy Carrot
As long as there is no widely accepted API which could take its place (and i don't think directshow can), it shouldn't. who says that there has to be one big api that everyone uses?
if some opensource tools, with own apis able to handle the technology correctly, wrap the different codec cores and if thats supported by the codec devs (as its the case with x264 and mencoder atm), i dont see why this would be a downside :)

[Doom9]

if some opensource tools, with own apis able to handle the technology correctly, wrap the different codec cores and if thats supported by the codec devs (as its the case with x264 and mencoder atm), i dont see why this would be a downside I dare say that of XviD didn't have its own VFW interface when it started, we'd still all be using DivX. I still recall codec comparisons where XviD did not do well, but the many VirtualDub savy users out there made for an impressive collection of beta testers driving the codec ahead (of course, it's the developers who really made it possible.. but having a large audience helps to keep you motivated, does it not?)

- .avs support is already possible!!! actually there are even two options existing already: milan's makeavis tool or aku's avs2yuv toolWell.. that's not really AviSynth input support is it? That's trickery into getting a non cooperative program to accept one of the most important video tools in the Windows world ;)

[bond]

Originally posted by Doom9
Well.. that's not really AviSynth input support is it? That's trickery into getting a non cooperative program to accept one of the most important video tools in the Windows world ;)of course thats support for avisynth (actually mencoder and ffmpeg explicitly support getting piped streams). also the output will not be different (no quality lost), its just that you have to use a little bit longer commandline (no problem for newbies, if there is a nice gui doing this in the background ;) )

[KpeX]

Originally posted by Doom9
who uses it [besweet] via commandline only, honestly? I do - I think GUIs are pretty messy for an app like BeSweet (although BeLight looks pretty promising - but I haven't tried it yet). And I use mencoder lately almost exclusively for encoding. But I understand I'm not normal ;).

And mencoder definitely has its limitations. The major one right now (IMHO) is lack of alternative container support. mencoder doesn't support OGM, MKV, or MP4 (all easily supportable in an open-source tool) which limit its ability to support modern audio formats like AAC or vorbis. If mencoder had better container support and a really nice GUI that walked the line between powerful options and user friendliness (including support for AVS input) mencoder could really take off as a useful tool.

[buzzqw]

[START OT] I also pray for a Mencoder fuctional gui.
There are some (DprEnc, iirc) but almost outdated and with some bugs.
Some software, those with over 100k :D of man page, NEED a gui; this gui must also be developed within (or near) mencoder group. [END OT]

Thanks Doom9 !!
i think you have more sparetime then i

BHH

P.S. I use, as base, MKV, but for a codec shoot-out container isn't much important. So Thanks again :)

[eb]

What is possibility to get HDX4 1.4 codec for tests with live recording from sattv?

From above tests it is clear indication for codecs to be used for live recording to .avi from sattv digital DVB cards.

eb

[DeathTheSheep]

By Doom9 himself:
I dare say that of XviD didn't have its own VFW interface when it started, we'd still all be using DivX.

Wow. I've never heard a better example.

Indeed, with all of the commandline interfaces out there--while they may be useable to many a dos-savvy harcore encoder dude--get more complex constantly, and a GUI is eventually needed (according to many people).

This GUI, however, still may not be compatible with many specific "file attributes." I agree with whoever says that there should be a centralized means of incorporating every codec. That is, when a codec is made, people can boot up their encoding app, pick the codec from a list of every codec installed, configure its options, and fly, never requiring the user to adopt steep learning curves with new apps and new settings and new layout and wierd options, etc. An all purpose encoding app.

This used to be virtualDub and its VFW list.

But now, NO MORE! With clunky yet "cool" MP4, with vfw "problems" like inability to encorporate "true AVC," and fvw's own rigidity regarding file/processing specs, companies like Real, WMV, Nero, etc have all moved away from it, leaving it in the dark, never to be truly an all-purpose encoding app ever again.

We need a centralized solution. While it may seem that seperate GUIs are okay for a time, an oversaturation of them on your computer will lead to chaos, and they will keep getting more radical until there is NO cooperation... Truth to be told, we need a centralized solution. If not vfw, something less rigid but still centralized would easily suffice.

DTS

[Sharktooth]

Directshow. It could be buggy but it works.

[SeeMoreDigital]

What we want is a nice GUI offering all the familiar options we like using but runs GraphEdit in the background ;)


Cheers

[Manao]

Look at the issues of encoding solutions based on directshow. Frankly, I don't think it's a good solution.

[Sharktooth]

The issues are due to poor DS encoder implementations.
Graphedit is already an optimal solution but until codec developers does not add the encoder DS filters with all the bells and whistles (they have no settings "page" or they are "crippled" like the ones that come with nero) there are few chanches to seriously encode something with graphedit...

[Manao]

It's not just that. The issues I'm speaking of are more profound that a mere lack of proper interface : recode is plagued with bugs, and i'd bet that half of them are due to Directshow. And look at moonlight and the interactions between their filters and other's filters.

You'll say it's the fault of the programmers. I think it's not.

And, in both cases ( nero's and moonlight's ), they rewrote completly all the filters ( splitter / muxer / encoders ). That denotes that something is wrong.

Finally, Directshow is meant for realtime stuff, and is, imho, inefficient when doing something which isn't realtime.

[stephanV]

Maybe Avery Lee will add support for it eventually though. He's already working on DS capping and it is not unlikely MS will drop VFW completely sometime. He doesnt really like it though.

[Doom9]

to use the words of one of the programmers involved in the last codec comparison: DirectShow is a messJust look at all the playback, and more importantly, screenshot issues I've had. DS filters are supposed to be able to jump to any frame, go forward/backward frame by frame and by keyframe.. many filters couldn't do that. Then there's the color conversion thing (I had to install a 300MB SDK to get screenshots without discoloration), etc.

[neo75903]

Originally posted by KpeX
I do - I think GUIs are pretty messy for an app like BeSweet ...
Agree, but I also learned most of the command line options thanks to the GUI command line box.

[*.mp4 guy]

I dare say that of XviD didn't have its own VFW interface when it started, we'd still all be using DivX.

I cannot say just how correct this is imo, the only encoding ap I can actually say I truly enjoy using and understand fully is VirtualDub. Furthermore despite that many people on the forums here may think (and rightfully so when it aplies to them) that guis are clunky or dumbed down. However they are absulutely necessary for widespread adoption of a container format or coding tool!

Indeed, with all of the commandline interfaces out there--while they may be useable to many a dos-savvy harcore encoder dude--get more complex constantly, and a GUI is eventually needed (according to many people).

It sadens me just how fractured the media editing world has become, what with linux tools, vfw directshow and the odd orphaned .exe out there its just becoming to much of a chore. Many times I spend hours just trying to figure out how to get something to work (the first time i tried avisynth and besweet comes to mind). Unless opensource solutions want there userbase to dwindle instead of grow some better frameworking is badly needed imo.

[sbp]

Thanks for your very informative codec comparison.

After reading the "shoot-out" and this thread, I have a few comments:

1. We all have different interests, and therefore, the discussion about direct show versus VFW versus "own GUI" is dependent upon the intended usage.
As I want to do direct capture from a TV-card, I think that all the codecs should show up inside the capturing program (a drop down list) - I'm not quite sure which format the of the codecs do that (VFW?? or DS?) - but that will be important for me.
Unfortunately it seems that the fastest codec; Nero ASP only can be used from inside Recode.

2. That brings me to my number two comment. I noticed that you have changed computer between the 2003 and the 2004 shoot-out. In 2003 you used a AMD Athlon XP 2800+ CPU in 2004 it was a AMD Athlon 64 3500+. This makes it impossibel to compare the speed development from 2003-2004. As I'm interested in speed (real time one pass encoding) I would like to ask if you have any information on the speed of the different codecs? Is the new DIVX codec faster than the one used in 2003 and also how is XVID 1.1 compared to that of 2003?

Thanks
Steen

[Doom9]

As I'm interested in speed (real time one pass encoding) I would like to ask if you have any information on the speed of the different codecs? Is the new DIVX codec faster than the one used in 2003 and also how is XVID 1.1 compared to that of 2003?XviD is supposed to be faster, but I just don't have the old box again, and neither do I still have the XviD build used for the old codec comparison. But you can take the latest XviD 1.0x release and compare it with the latest XviD 1.1 build.. that should give you an idea.

I've also managed to dig up some very old codec comparisons from the year 2001. here's the link: http://forum.doom9.org/old-site.rar. I also thought I would have the very first codec comparison (DivX3 vs. WMV7) along with my site at the state before I made the design change, but unfortunately I cannot find that anymore. Anyway, the comparisons above include OpenDivX and other really old codecs, so you can clearly see how far we've come since then.

[sbp]

Thanks for the reply.

I'm sure that the codecs have come a long way since 2001. But it seems from your shoot-out in 2003 that the codecs got slower in 2003 compared to 2002?
I quote you here from the 2003 comparison:
"The slowest codec last time (WMV9, 17.43 fps) would now be in the faster half. RV9 obviously got slower because of the EHQ mode, but DivX5's speed drop is beyond me. I even tested it twice because I wouldn't believe my results. I'm waiting to hear from DXN on the speed subject (encoding was faster on my 2.8 GHz P4 notebook, but still slower than every other codec). I was positively surprised by XviD, which once again is very presentable in the speed area. ND blew everything else out of the water."

So it seems that the codecs didn't get faster - at least in 2003.

So how is your feeling this year, are they faster now - and especially Divx, which last year were pretty slow (5.1.1)?

I haven't been able to read anything about the speed differences between XVID 1.0 and 1.1 in one pass encoding - does anybody have information on this issue?

Steen

[babayaga]

Originally posted by Doom9
I've also managed to dig up some very old codec comparisons from the year 2001. here's the link: http://forum.doom9.org/old-site.rar
Thanks !!
Your comparisons are consistant for almost 4 years (I guess the 1st shoot-out was done in march or april 2001) : same kind of movies and same protocol. This gives a pretty clear idea of the fast codec evolution :)

[Doom9]

So how is your feeling this year, are they faster now - and especially Divx, which last year were pretty slow (5.1.1)?Look at the DivX settings for the last two years now.. slowest mode and insane mode.. they just can't be fast that way. But it's really a matter of settings.

[babayaga]

Originally posted by sbp
So it seems that the codecs didn't get faster - at least in 2003.

It went almost unnoticed but we did release an impoved version of our MPEG-4 ASP codec in in june 2004.
This version did add the new 1st pass concept that make a 2 passes encoding almost as fast as a one pass encoding on a whole movie.

Unfortunately, the idea came during the christmas season just when Doom9 was making its review and I was testing it when the shoot-out results were published :(

Besides, this version also adds quality improvements that makes it on par with XviD on the detail level, which was the goal.

[Doom9]

Besides, this version also adds quality improvements that makes it on par with XviD on the detail level, which was the goal.Let's look at that in a future codec comparison, shall we? :devil:

[babayaga]

Originally posted by Doom9
Let's look at that in a future codec comparison, shall we? :devil:

With great pleasure :D

[Daniel_HDX4]

Originally posted by eb
What is possibility to get HDX4 1.4 codec for tests with live recording from sattv?


Hi,

we hope to release HDX4 in two or three weeks. Currently we are working on solutions for hardware devices (player) and we have to complete this first...

-Daniel

[bond]

Welcome to doom9!
its always nice to see representatives of a/v implementations on the board :)

Originally posted by Daniel_HDX4
Currently we are working on solutions for hardware devices (player) and we have to complete this first...what exactly does this mean? i saw that on your webpage you seem to offer both .avi and .mp4 output options for your mpeg-4 encoder? is that true?

[SeeMoreDigital]

Hi Daniel and welcome ;)

I hope you've prepared yourself to answer some tough questions?


Cheers

[708145]

Originally posted by babayaga


- sumo : like the football championships but with a reduced set of opponents choosen basically on their rank. There are individual matches at the end in case of ties. The set of player is well sorted but not perfectly though. It further permit to a badly ranked player to finish first in a much more fair way than in tennis.

I prefer the sumo way since it gives a sorted set with a reduced number of individual matches : for 10 codecs, this leads to about 25 individual comparisons, 4h for a single reviewer needing 10mn for each match. This method relies on transitivity (if A is better than B and B better than C then A is better than C) which is highly desirable.

[long explanation skipped]

ok, it's too complex, but I love the idea :D

I prefer the sumo method as well. I don't think it's too complex, maybe it's even simpler than the current scheme doom9 used to compare all codecs. (I boldly assume he compared every codec with every other which might not be the case.)

bis besser,
Tobias

[Fl0ppy]

Thanks for the test, of course xvid r00lez :-D
But i miss the mpeg4 of libavcodec (ffmpeg project) :rolleyes:

[Daniel_HDX4]

Originally posted by bond
i saw that on your webpage you seem to offer both .avi and .mp4 output options for your mpeg-4 encoder? is that true?

Hi,

thanks for your warm welcome. :)

Well, our homepage is not online yet. If you have already a deep link, it's very old and hasn't changed since several weeks (or even months?)... The homepage we will release is completly different. The one you know at the moment is only for the costumers we have already...

Regarding your question: We plan to offer several output formats. .avi and .mp4 are two of them...

-Daniel

[Daniel_HDX4]

Originally posted by SeeMoreDigital
I hope you've prepared yourself to answer some tough questions?

Hi,

yep, I am. ;-) What do you want to know?

-Daniel

[bond]

Originally posted by Daniel_HDX4
What do you want to know?when will we be able to test hdx4 ourselves? :)

[Daniel_HDX4]

Originally posted by bond
when will we be able to test hdx4 ourselves? :)

Hi,

hopefully in a few weeks (still this month!). It depends on one other project we have to finish at first... But it's great to know that the codec seems to be intersting for you...

-Daniel

[CruNcher]

What is Skals position @ Jomigo ?
and is the codebase of hdx4 based on tmp4 + snr (Skals Codec) ?
and of course what's your position ;)

[Daniel_HDX4]

Originally posted by CruNcher
What is Skals position @ Jomigo ?
and is the codebase of hdx4 based on tmp4 + snr (Skals Codec) ?
and of course what's your position ;)

Hi,

Skal is not the lead programmer at Jomigo. In fact, he isn't even working for Jomigo at all. If you look at the "Codec shoot-out" introduction, Doom9 has removed already the information about the relationship of Skal and Jomigo. To be honest, all people at Jomigo were wondering about this information published there...

Anyway, I haven't thought that it's that interesting to know who is behind HDX4. ;-)

HDX4 is developed by a larger team of programmers. And I am sorry, but I haven't heard of tmp4 before...

Addendum on 01.02.2005:

I have looked meanhwile at tmp4. As far as I can see tmp4 can be used as bitstream reader/writer for compatibility tests. But is it a complete codec?

And what do you mean with SNR? Normally this means "Signal-to-Noise-Ratio" - but what has this to do with HDX4 and/or TMP4?

-Daniel

[sbp]

@babayaga
You wrote:
It went almost unnoticed but we did release an impoved version of our MPEG-4 ASP codec in in june 2004.
This version did add the new 1st pass concept that make a 2 passes encoding almost as fast as a one pass encoding on a whole movie."

Thats interesting, is it possible to use this codec for my purpose = real time encoding from my TV-card, or is it also only possible to use this codec from inside Recode?

Thanks
Steen

[Episode]

Heh. It looks like Doom9's 'codec shoot-out 2004' results have been posted to slashdot. I'm not surprised that almost everyone in that thread complains because Doom9 didn't test Ogg Theora and how there weren't any open source codecs included in comparsion. Only one person pointed out that Xvid is also licensed under GPL. I really don't understand those OSS-fanatics. In their opinion Theora is the ultimate codec since it free and doesn't have any licensing issues, no matter how bad image quality it produces.

[Doom9]

I really don't understand those OSS-fanatics. In their opinion Theora is the ultimate codec since it free and doesn't have any licensing issues, no matter how bad image quality it produces.I guess as long as they don't have to watch the content ;) Perhaps next time I should do a more extensive codec research, encode one movie per codec, then throw out codecs that really can't keep up with ND AVC and XviD.

[bond]

lol, again its fun reading slashdot :D

anyways, i consider myself as a fan of theora too and i am not really angry about that it hasnt been included. i think there is no doubt about how it compares to advanced codecs like xvid and nd avc qualitywise (still, quality is not everything), an inclusion might have done more harm than good for theora atm

and also: why is it so hard to differentiate that not "nero digital" was used in the test, nor won it... such an inconcreteness has the potential to confuse newbies i think. it has to be pointed out that nero digital avc was used in the comparison and not the asp version, which is supported on standalone players and wasnt even used in that comparison...
of course doom9 made that clear, but people tend to rush over such important details far too easily :rolleyes:

[CruNcher]

@Daniel_HDX4
Sorry i meant SNS not SNR

[Leak]

Originally posted by Episode
Heh. It looks like Doom9's 'codec shoot-out 2004' results have been posted to slashdot.

Hooo boy, there go my 5 /. moderator points... ;)

How's the site handling the slashdotting? It's up, obviously - but how hard is it being hit? :D

np: Gescom - Keynell 3 (Keynell EP)

[Doom9]

How's the site handling the slashdotting? It's up, obviously - but how hard is it being hit? I'm afraid I don't have more than just the webalizer stats, and it takes at least 24h to see something in those. Yet, I've been talking to an admin of one of the mirrors and the load was virtually zero. I've also not heard anything about a performance impact, and the forum took todays user record with a smile.

[Selur]

@Doom9: thx for another nice comparison :D

[babayaga]

Originally posted by sbp
Thats interesting, is it possible to use this codec for my purpose = real time encoding from my TV-card, or is it also only possible to use this codec from inside Recode?
As far as I know it is only possible to use it from Recode. It may change rapidely (or maybe it's done yet :)).

Besides, there is still the interlaced issue : the current release is about as good as XviD or DivX in the case.

[neo75903]

i did used to used chris-tv to record live tv with Xvid, but the results arent satisfying as using mpeg2 at 2000kbps.
cpu use was high, and also had a out of sync all the time.

i also have a pvr server which uses 3 150mce's to record from 3 different channels, cpu use on a 2500+ hardly over 10 percent.

[fatso485]

very good work doom9

i think it would be very usufull to know the bitrate of the actual clip as appose to the whole movie. this will greatly help us to determine how good a codec is in determine how efficient a codec really is.

also, isn't there something that you can do to make us download the clips.

sorry about my english and if any of these points are address in the extreamly long thread

[Doom9]

i think it would be very usufull to know the bitrate of the actual clip as appose to the whole movie. this will greatly help us to determine how good a codec is in determine how efficient a codec really is.Please think about the effort for a moment.. cutting MP4, RMVB, AVI, then demux? Lots of work. There's a reason why clips are taken throughout the movie.. with a large sample size you can assure that on the average your impression is correct.

also, isn't there something that you can do to make us download the clips.Absolutely not.. think about it.. the comparison itself is 43 MB. The entire 3 movies rate about 40 GB.. so the total clip size would be say 1 GB. Times 10'000 downloads = 10 TB of traffic. And then there's the copyright question.

[Sharktooth]

Originally posted by babayaga
As far as I know it is only possible to use it from Recode. It may change rapidely (or maybe it's done yet :)).
Finally! Thank you.

[sbp]

Originally posted by babayaga
As far as I know it is only possible to use it from Recode. It may change rapidely (or maybe it's done yet :)).

Besides, there is still the interlaced issue : the current release is about as good as XviD or DivX in the case.


That is good news.

If you want someone to help with the testing for real-time capturing from a TV-card (phillips 7134 chip) I will be veryy happy to help you with that :-)

Steen

[SpaceV]

First, thanks Doom9 for the great comparison.
One thing that would it even make better (for me at least),
would be to have 2 differently coded frames on top of each other.
This way you could have the original and ND or ND and VP6 on top
of each other and compare more easily. I know you could do it with
2 explorer windows as well, but its "nicer" on the same page.

Now for the file sizes. I have not read the whole thread, but it seems that some people are still trying to fit a movie onto a CD.

Why is that? DVD burners cost 70$ and DVDs 20 cents. CDs cost about 8 cents. But I can fit 6 CDs onto a DVD. So isnt it more expensive to record onto a CD??? And besides, I rather have a 800-900MB encode with great quality and I can still fit 5 of those on a DVD.

I think the 700MB compression days are over.

What do u guys think?

[Tommy Carrot]

Originally posted by SpaceV
Now for the file sizes. I have not read the whole thread, but it seems that some people are still trying to fit a movie onto a CD.

Why is that? DVD burners cost 70$ and DVDs 20 cents. CDs cost about 8 cents. But I can fit 6 CDs onto a DVD. So isnt it more expensive to record onto a CD??? And besides, I rather have a 800-900MB encode with great quality and I can still fit 5 of those on a DVD.

I think the 700MB compression days are over.

What do u guys think?
It's probably because i like to keep all my movies on my HDD, and larger sizes would take up too much space. 1 or 2 cd-size is a good balance between size and quality. You're right they shouldn't need to be strictly 700 or 1400 MB, but it's like an old habit to me, i don't really like the arbitrary-sized movies. :D

[SeeMoreDigital]

Originally posted by SpaceV

I think the 700MB compression days are over.

What do u guys think? Nowadays, I only buy 800MB CD~R media.

But like a lot of people, I store my encodes on hard-drives so I can view them over a network!


Cheers

[Doom9]

why CD size? I have my doubts that even on this board, with all the people that are into what we do, you'd find a majority to use DVDs for their backups. And if you go to a larger sample of people, like my colleagues at work, or my friends, hardly anybody has ever burned a DVD.

So, from a global perspective, CD sizes are still very much applicable, and 700MB CDs are the most common.

And, regardless of the number of users, CD sizes seem kinda fitting for movies, 800MB CDs would make the test too easy, wouldn't you think?

[SpaceV]

Hm, I am using DVD as backup since about 2 years.
And now with a dual layer 16x burner @ 22MB/s, I see no reason to use CDs unless u want to create an audio CD.
Btw, I was burning @16x on a 8x media over a 100 Mbit LAN.
The recording had to stop and continue many times bc the network could not keep up. Amazingly the DVD works perfectly. (Need to get
a gigabit switch.)

And as I said before burning CDs is more expensive !!

If people still use CDs then they should wake up, it's 2005 !!

I cant wait to use BluRay for back ups, hope the new protection coating is as good as the PRs.

As far as 800MB being to easy, yeah for movies under 90 minnutes. For movies 120min and up, even 900MB can be quite challenging.

[RyFish]

Originally posted by SpaceV

And as I said before burning CDs is more expensive !!

If people still use CDs then they should wake up, it's 2005 !!


Maybe if you'd like to buy me one I could try it out! :) Seriousy , not everyone can afford a DVD burner just like that - especially just after Xmas and when your kids needs new shoes etc!

[SeeMoreDigital]

Originally posted by RyFish
Maybe if you'd like to buy me one I could try it out! :) Seriousy , not everyone can afford a DVD burner just like that - especially just after Xmas and when your kids needs new shoes etc! And by the time you've bought a DVD burner and loads of blank media... you might as well have bought yourself a gigantic hard-drive!


Cheers

[SpaceV]

C'mon you can get them for $70, that cant be much for
anyone on this board. For compressing movies with the new
codecs you need a fairly new machine anyway and a lot of
them even come with DVD burners nowadays.

I agree with the hard drive but: Its tough to carry it around
and go to a friends house to watch the movie there and If
your head crashes then all is lost. I have my stuff on HD but I back it up on DVD.


Off topic: XM Satellite Radio just announced to use On2 VP6.2 for video streaming in cars. Nice !! Congrats ON2, I just wonder why its not VP7??

[gircobain]

Originally posted by SpaceV
Now for the file sizes. I have not read the whole thread, but it seems that some people are still trying to fit a movie onto a CD.

Why is that? DVD burners cost 70$ and DVDs 20 cents. CDs cost about 8 cents. But I can fit 6 CDs onto a DVD. So isnt it more expensive to record onto a CD??? And besides, I rather have a 800-900MB encode with great quality and I can still fit 5 of those on a DVD.

I think the 700MB compression days are over.
Sorry to be off topic, but I think you should perhaps take a trip around the world and realize that these prices in no way apply to everywhere world wide.

[ObiKenobi]

Originally posted by SpaceV
C'mon you can get them for $70, that cant be much for
anyone on this board.

I don't know what brand drive you can find for 70 bucks, but I'd be really concerned about the quality/longevity of such a drive. Any quality brand of drive I've found at Best Buy/CompUSA has always been at least 120 dollars or more. Secondly, not all of us have an endless supply of money to spend on hardware and media so for some of us that is quite a bit.

[SteMa]

Not everybody lives in the US, I have myself a burner, and a few of my friends, but mostly they still have a cd-rw, or a combo drive. a pio 108d costs about $90 here, but a better average monthly paycheck is about $500. 700mb is ok for everybody, U can fit 6 of those on a dvd if you have a dvd burner, and if U have a cd-burner U can still write those on cds (dvd media prices about 70cent illegaly, and legally $1.5 minimum! cd-s are 28cent illegaly, and about 85 legally)

[Sergei_Esenin]

Originally posted by SteMa
700mb is ok for everybody,

Don't generalize in the other direction though--just as it's not accurate to say everyone should do high bitrate 2-4 CD size encodes and burn to DVD, it's not accurate to say 700MB is enough for everyone. I'm lucky enough to view on a 100" SVGA projector system, which makes 700MB rips look like garbage next to non-downsized high-bitrate encodes.

Low bitrate CD encodes are still "mainstream" thanks to media, bandwidth, and installed base, but the near future is high bitrate unresized or processed and upscaled video. It's already the present for many of us quality-loving AVSForum types, and HDTV is accelerating appreciation for high image quality.

[SteMa]

Sorry, you didn't understand me:
What I meant with 700mb was 700mb, 1400mb, 2100mb, etc... meaning, if groups would start releasing 1 gig movies then it whould be ok for ones with dvd-burners, but dividing to cd sizes is a great compromise.

[kieljan]

there are some words like

ºIf anybody claims any codec can deliver DVD quality at 700MB for a 2h movie, have him encode Matrix3 and compare it to the DVD. And if he still thinks so, send him to an eye doctor.º

i´ve ripped Matrix3 by Nero H.264 (714 Mb 1Cd rip). NTSC 720x304, 23.976 FILM fps, 760 kbit/s + HE-AAC 52 kbit/s. Of course it isn´t a DVD quality.
But quality is great and big part of details was preserved.


Ripping material from a DVD(or from any other delivery source for that matter) will never be DVD quality for a simple reason - you are using source material which has already been compressed, in the case of dvd using the mpeg-2 codec, and thus the quality will ALWAYS be lower than the source. And Mpreg2 already introduces compression artifacts (since it is a delivery codec which uses key-frames) so the secondary compression in the ripping stage suffers even more because it doesn't have all the information in terms of original full frames...
So, what i'm getting at - if one wants to compare with "DVD" quality, one would need source material in uncompressed format/intermediate format (such as motion jpg) which doesn't have any keyframes.
I personally encoded some material which was compiled from tiff sequences, and then converted to avi(using the lossless huffyuv codec) and i can tell you that mpeg2 aka DVD quality is miles behind codecs such as wmv 9, avc, and the other newer codecs. Which is why it won't be used as the standard for the emerging HD formats - the codecs of choice will be based upon AVC (h.264) and VC-1 (wmv 9)

If one wants to compare by way of DVD quality

[Doom9]

there's an unwritten rule that you don't pick up a topic after it's been resting for a while. 4 months definitely qualifies...

[kieljan]

sorry, i'm new to this forum, and have been browsing interesting articles - when coming across this whole issue i reckoned that this particular point was quite important, so just wanted to shed some light on it - especially cos it might not be the last time that anyone reads this thread, and are thus misguided...k