Log in

View Full Version : Doom9's "Codec shoot-out 2004" test results are out!


Pages : 1 2 [3] 4

stephanV
30th December 2004, 12:20
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
30th December 2004, 12:29
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
30th December 2004, 12:51
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
30th December 2004, 13:10
I have a new question for the FAQ: :cool:
Why use VirtualDub and then Nandub instead of VirtualDubMod ?

Doom9
30th December 2004, 13:17
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
30th December 2004, 13:19
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
30th December 2004, 14:00
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
30th December 2004, 14:04
"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
30th December 2004, 14:56
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
30th December 2004, 15:01
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
30th December 2004, 15:14
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
30th December 2004, 15:19
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
30th December 2004, 15:37
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
30th December 2004, 17:10
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
30th December 2004, 19:10
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
30th December 2004, 20:13
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
30th December 2004, 20:31
Well shock-horror....

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


Cheers

babayaga
30th December 2004, 20:37
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
30th December 2004, 20:51
OMG!

niamh
30th December 2004, 21:13
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
30th December 2004, 21:14
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
30th December 2004, 21:21
But the evaluation isn't of screenshots -- Doom9 evaluates scenes. The screenshots are just representative examples.

niamh
30th December 2004, 21:26
Yes, I know that jggimi, I thought it would be interesting anyway.

Tommy Carrot
30th December 2004, 21:29
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
30th December 2004, 21:38
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
30th December 2004, 21:46
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
30th December 2004, 22:15
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
31st December 2004, 00:01
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
31st December 2004, 00:03
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
31st December 2004, 00:08
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
31st December 2004, 01:11
Originally posted by DeathTheSheep
But vfw still shouldn't die

oh, yes it should

Tommy Carrot
31st December 2004, 01:34
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
31st December 2004, 01:50
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
31st December 2004, 02:00
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
31st December 2004, 02:35
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
31st December 2004, 08:22
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
31st December 2004, 08:45
[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
31st December 2004, 15:01
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
31st December 2004, 15:52
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
31st December 2004, 16:08
Directshow. It could be buggy but it works.

SeeMoreDigital
31st December 2004, 16:22
What we want is a nice GUI offering all the familiar options we like using but runs GraphEdit in the background ;)


Cheers

Manao
31st December 2004, 16:25
Look at the issues of encoding solutions based on directshow. Frankly, I don't think it's a good solution.

Sharktooth
31st December 2004, 16:38
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
31st December 2004, 17:52
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
31st December 2004, 18:44
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
31st December 2004, 19:28
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
31st December 2004, 21:48
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
1st January 2005, 08:39
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
1st January 2005, 14:12
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
1st January 2005, 15:55
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.