Do diferent encoder programs generate different quality?

[TheCreamCrackerBoy]

Hello to all!!!

Since different MPEG-2 encoder programs (ex: CCE, TMPGEnc, Canopus, HCEnc, QuEnc, etc) generates MPEG-2 with different quality between them, I would like to ask:

1) Does the same thing happens using different MPEG-4 encoder programs (ex: VirtualDub, Mencoder, Xvid Paralel Encoder, etc) regarding the same MPEG-4 codec used?

If the answer is affirmative, I got two more questions:

2) Are there any MPEG-4 encoder comparision pages (comparision, not "codec") or tests that have been done?

3) Since PFComparer can be used for comparing MPEG-2 files with the original one, is there any MPEG-4 comparer program so I could test myself the different MPEG-4 encoder programs avaliable?

Thank you very much,

TheCreamCrackerBoy.

[Sirber]

1) Yes. VDub = vfw, mencoder = builtin, xvid p-e = cli
2) Yes! http://www.doom9.org/index.html?/codecs-203-1.htm
3) Yes!!! :( http://www.downloadjunction.com/product/software/91325/

[dimzon]

1) Yes. VDub = vfw, mencoder = builtin, xvid p-e = cli
Yes And No. Quality will be very close one to another until you use same settings

[Doom9]

I think you're missing the important distinction between an encoder and a codec. An encoder contains a codec (well, at least the CO part because it enCOdes), it needs one in order to encode. So, CCE, TMPG, etc all use a different codec if you like, hence the output is different. But using the same parameters and the same codec core, it doesn't matter whether you use XviD via VirtualDub or via mencoder.. it's the same codec. The same goes for using x264 in x264.exe or x264 via mencoder or via VfW.. it's still the same codec. So, it's the codec that matters, not the encoder program itself. The only reason why you have different output from different MPEG-2 encoders is because they have different built-in codecs.

Virtualdub and mencoder are encoders without a codec.. they need an internal (libavcodec, xvid, libx264 compiled into mencoder) or external (VfW) codec in order to encode to a specific format.

So, same codec, same settings = same output (unless an encoder program has a bug of course) and your question number two becomes superfluous.

The XviD/x264 parallel encoder is a special case.. it won't return identical output because of the way it works. The same applies to comparing x264 with one or two threads, once again this is because of how mutliple threads are being handled. But using the same number of threads in mencoder, x264.exe or VfW yields the same output.

I have never heard of PFComparer, neither has google..

[Doom9]

uhh guys, I think you misread question one. same core, same settings = same output bitstream. Of course if one of the two varies, then the output varies as well.

[TheCreamCrackerBoy]

Oops, you've got me! How stupid of me... it's PF Comparer... not PFComparer. I've found it at http://forum.doom9.org/showthread.php?t=96752&page=1&pp=20

Thank you,

TheCreamCrackerBoy.

[TheCreamCrackerBoy]

2) Yes! http://www.doom9.org/index.html?/codecs-203-1.htm


Well... according to this link it's a codec comparision, not an encoder program comparision... besides, the link says that, except for RV9, all codecs were used in VirtualDub 1.5.10 for encoding.

What I am searching for is not a codec comparision, it's a program comparision. For example, using exactly the same Xvid settings with different programs, such as VirtualDub, Mencoder, Xvid Paralel Encoder and others.

So, same core, same settings = same output (unless an encoder program has a bug of course) and your question number two becomes superfluous.


Perhaps this answers me... :-)

Thank you,

TheCreamCrackerBoy.

[foxyshadis]

The only possible differences you'd get would be due to different containers, and encoding speed being very slightly faster/slower in some programs. And certain features not being exposed in some programs (whether by design or just not yet updated, like x264's vfw), of course.

[stephanV]

No... a container doesn't influence video quality at all. It is true that remuxing something might slightly alter the file size.

[bond]

well if a container causes a lot of overhead, you have to reduce the videobitrate to reach a target filesize which hurts quality (depending on how much overhead the container uses)
but thats nitpicking

[foxyshadis]

I meant frame order, null frames, and yes, overhead. Not actual video bytestream.

[Multimon]

I thought null frames are also part of the bitstream?
And that if you want to keep audio in sync you have to cut the first frames off because audio starts right away, if you don't cut frames off you will have a desync depending on how many null frames you have?
Or are you talking of something else and I mixed it up?

[bond]

define "null frame"

[Multimon]

I'd say it's basically an empty frame with (almost?) nothing in it, that would fit the usage of null I know so far, but I must admit I haven't heard it before in the context of video codecs.

[bond]

well an avi frame that doesnt carry a frame is a not existing frame and not existing frames are not part of any specs ;)

[Multimon]

Well, I mean no content, no usefull picture, not that it doesn't even exist. A not existing frame for sure doesn't make any sense^^*

[bond]

Well, I mean no content, not that it doesn't even exist. A not existing frame for sure doesn't make any sense^^*yeah, right. but when placing avc in avi you get such senseless frames