Curious about MPEG encoding original DV material...

[TRILIGHT]

I really don't want this to turn into a "cross post" so please provide your insight on THIS THREAD (http://forum.doom9.org/showthread.php?s=&postid=290665) in the DV forum. Thanks!

That being said, I am looking for some informed opinions from users of DV material. Since my experience in this field is rather limited, I am hoping to get some good information to help me in the buying process. Thanks!

[cupfart]

I used Spruce Maestro w/ tmpgenc & AC3machine.. so this would be a guide how to get .m2v and .ac3 file to import into Meastro. Maybe sometime I will make a larger guide with pictures, but for now it's only how to get the .avi into .m2v and .ac3 format.

--DV camera (hi8, dv, etc...) -> .m2v & .ac3 formt--

1) (Video Stream) Open TMPGENC.
- click LOAD and select "DVD (NTSC).mcf" (should be in the templates folder in the tmpengc program folder)
- Change stream type to "Video Only"
- Choose your "VIDEO source" (should be your edit or unedited .avi file)
- Choose where you want your output file to go to (make sure the ext is .m2v)
- click start

Once this is done, you have your .m2v file for Spruce Maestro.

2) (Audio Stream) Open TMPGENC.
- click LOAD and select "DVD (NTSC).mcf" (should be in the templates folder in the tmpengc program folder)
- Change stream type to "Audio Only"
- Choose your "AUDIO source" (should be your edit or unedited .avi file)
- Choose where you want your output file to go to (make sure the ext is .mpa)
- click start

Once this is done, you have your .mpa which will be converted into an .AC3 with AC3machine.

3) (Audio Stream - step #2) Open AC3machine.
- Select "Input (AC3)"
- Choose where you want your "Output (AC3)". (make sure it has ext of .ac3)
- Click go.

Once done you have your .ac3 file for Spruce Meastro.

4) Import your .ac3 file and your .m2v into the Spruce Maestro asset bin.

Your done.. but now you need to figure out how to work Maestro :) good luck.

[TRILIGHT]

Thank you for your input, cupfart, but I don't really need a guide of what to do. I am pretty familiar with the process already. ;) What I want detailed information on, and the reason I posted in the "DVD encoding" forum, is the best practices for encoding original DV material for DVD. I already know how to capture, how to split, and actually creating DVD's is more than just "second nature" for me now.

I've done a few encoding tests of my own using CCE and Procoder both with and without deinterlacing and trying different avisynth scripts. I'm interested in finding out what others do with their original DV material when it comes to MPEG2 encoding. Keep in mind that I am an NTSC user and I am only interested in encoding techniques (to MPEG2) for original DV material.

From my own tests, I've found CCE with the following AVIsynth script gives me the best results:


LoadPlugin("C:\WINDOWS\SYSTEM32\decomb.dll")
AVISource("Q:\DV_CAPTURE\TEST.AVI")
ConvertToYUY2()
FieldDeinterlace()
ResampleAudio(44100)


I'm interested in knowing if anyone else has a better solution though. Not that what I'm doing now sucks. It's great! I would just like to know if anyone has more experience when it comes to encoding original DV material.

[cupfart]

I was only talking about encoding.. you could take my guide to ways...

1) me telling you how to do it (which you don't want because you already know how)
2) me telling you how I do it (the way you want) :)

I have used both cce and tmpgenc and I have heard all the bashing cce people give tmpgenc, but I have really tried to see the difference between cce and tmpgenc from .avi (original dv format) and I could not.

I have made a couple full length dvd's for people using that method I am speaking about.. it's the simpliest part of course.

just used the template tmpgenc has for dvd and only encode the video and audio one at a time to get the right files.

[mrbass]

When I played with mini-DV material way back in May 2002 I was trying to put 60 mins on one SVCD. CCE 4pass didn't matter still looked like crap at around 1600Kbps. Well around 2500Kbps looked decent and even CBR looked good too. Other stuff I remember was since I set my camcoder (it's all in japanese) to do 12-bit audio instead of 16-bit I had to use canopus dv converter to convert it to canopus codec. I was using dvd2svcd to process it with cce.

Since getting a dvd burner I haven't had a chance to play with it but will sometime in the future as I have nearly 80 or so 60min home mini-dv tapes since 1996 that we've accumlated.

I dug up my old guide and threw it up for awhile (I know you don't need it..just so you get an idea of what I was trying to do).
http://www.mrbass.org/dvd2svcd/dv/

[TRILIGHT]

Thank you both for your time and input. As I mentioned, I worked with both Procoder and CCE and found that deinterlacing and using CCE at around 4000 on bitrate was giving me the best results. As for Tmpgenc, it's not really crap per se as far as quality goes but CCE is more versatile and is a magnitude faster than tmpgenc. I really don't see why the Canopus group sings the DV praises of Procoder so much. I really wasn't that impressed. Especially in the way it handles solid color areas when compared to CCE at the same bitrate.

Thanks for the site, Mrbass. Good info. I'm curious about something though. Looking at your scripts, it does not seem that you are deinterlacing anything. I found that in any scenes that the camera panned around and there was movement, I ended up with a lot of "jerky" problems that went away when deinterlacing. Did you find another way around this? I thought the DV material always had to be deinterlaced

[mrbass]

field bottom field first set would cure the jerky problem for me. Also 1600 seem a little jerky too but not much when I set bottom field first.

[SomeJoe]

Unless your destination for the video is playback on the computer screen, or if the transport codec for the material is a codec that doesn't support interlaced video (i.e. MPEG-1 on VCD), don't deinterlace your DV.

DV (and all other pure interlaced video) has a temporal difference between each field. This 1/60th of a second temporal resolution is what gives NTSC video it's really smooth motion as compared to film. It somewhat makes up for the lack of spatial resolution (every field is only 240 lines of information).

When you deinterlace, you manufacture additional spatial information using interpolation or line doubling at the expense of temporal resolution. So once the video is deinterlaced, you're now displaying faked 480 lines of resolution, and have thrown away half of the temporal resolution. It won't look as good. True, good deinterlacing algorithms can look great, but the resulting video is soft and lacks fine detail. (View your video on a calibrated broadcast-quality NTSC monitor and you'll see what I mean.) (By the way, this is a separate issue, but virtually all NTSC TVs have factory settings for contrast/brightness/color that are WAY off of what they're supposed to be. Get your TVs adjusted and you will see fine detail in NTSC video that you never thought was there.)

The best solution for encoding your DV is to use a great MPEG-2 encoder that fully supports all the interlacing options. For CCE, uncheck "Upper field first", "Progressive frames", and "Zigzag scanning order". Check "Drop frame". Set "Intra DC Precision" to 10. Set "Image Quality" to somewhere between 15 & 25, and turn on "Anti-Noise" to somewhere between 5-10 (more for lower light footage). After the .m2v is produced, you will have to run pulldown.exe with appropriate options to change the BFF flags to 1. Since I edit DV with Premiere, I have also used the Adobe MPEG Encoder built into Premiere 6.5 (made by Main Concept). It makes really good encoded MPEG-2 from DV as well when the correct options are set, and properly sets the BFF flags to begin with so the subsequent pulldown.exe step is not necessary.

For bitrate, I don't like going lower than 5000 VBR. Interlaced video takes more bitrate to encode because the motion vectors aren't as effective. (For every object in motion, there has to be 2 motion vectors instead of one because you need one for each field, and each motion vector can't specify as much motion for each object because the temporal resolution is higher for DV than film, so the objects aren't moving as much from frame to frame).

If you analyze an .m2v file with Bitrate Viewer, you typically see Q values for progressive film down in the 2.x to 4.x range. You won't get the Q values that low with DV. Values of 7.x to 9.x are common. But the resulting .m2v will still look good.

I'd be more than happy to answer any other questions you may have.

[TRILIGHT]

Awesome! Thanks for the detailed info, SomeJoe! Who knew that "Some Joe" would have all the answers I was looking for. hehehe :D Anyway, thanks for the great DV info.

[TRILIGHT]

For anyone curious, I've done some more testing and found that Procoder really does a much better job of handling detail on DV material than CCE does! I've run a lot of different clips through them both and I have to say that Procoder just does edge out CCE on DV material if you leave it interlaced and encode. If deinterlacing (losing at least a bit of quality) then CCE edges it out but with all the space available, I don't see any reason to deinterlace. Leaving it interlaced and encoding my Premiere timeline through Procoder produces the best results. I'm pretty pleased with the result! :)

[jzaman]

I render all of my HBO/VHS/DVD captures through a Canopus ADVC-100 via firewire or DV movies by camera via firewire into Ulead DVD Toolbox 1.3 for avi/mpeg creation and/or DVD authoring. The Ulead DSW MPEG capture plug-in performs a very fast mpeg render and the Ulead directshow capture plug-in does a slower avi only render. If the vobs generated are too big then I can pass them through CCE or DVD2one, etc. This is a lower budget version of more expensive professional systems but the output quality has been scutinized by others who thought I had a higher end system.

[TRILIGHT]

Originally posted by jzaman
If the vobs generated are too big then I can pass them through CCE or DVD2one, etc. This is a lower budget version of more expensive professional systems but the output quality has been scutinized by others who thought I had a higher end system.

No offense, jzaman, but doing that is a recompression of video that has already been compressed to MPEG once already. Everytime you do this you are losing a lot of quality. You will get better results if you do all your editing work and such and make sure you only do one encode as your final step.

[jzaman]

TRILIGHT:
The raw avi capture is 13 gigabytes per hour and the render to mpeg or vob is not initiated until after any editing especially with DV input. Capturing lesser quality stuff I'm less fussy about (HBO,VHS).
If you capture a DV stream as a raw AVI via a firewire port and then do a cbr at 8000 or vbr at 6000-9000 what loss do you have? For example, if I captured 2hrs which is 26 gigabytes then I render an mpeg at 9 gigabytes at the highest cbr or vbr and then re-encode with cce, will there be a noticeable loss? If you are at the top end of the DVD standard I assume that you've reached your peak in that medium. My reasoning is that if you render the mpeg at the highest bit rate and re-encode with cce to fit a DVD you minimize loss. Even if you run the 26 gb stream through cce won't it be throttling it down to the same cbr or vbr? Would my final DVD product be any better? Hey...I don't do this professionally so please correct me if I'm way off.

[TRILIGHT]

Like I said, I'm not trying to give you hell about your process. hehe ;) It would not matter if you did an MPEG encode to even something higher than DVD spec...say 15Mbps...and then did another down to 6 or 7Mbps. It would not change the fact that the material would be passed through two MPEG encoding processes which would ultimately lead to worse quality. You have to think about the parts of the video that were not handled so well in the first encode. During a second code, those section would become even more "muddled up" by the additional "interpretation" of the second MPEG encoder.

Now you might be saying "isn't this what we do with our DVD backups?" Well, yes, it is. However, there are two points to remember here. 1) Hollywood has access to MPEG encoders that do a much better job than the one your capture card is doing. 2) With DVD backups, we don't have a choice because we do not have access to the original video footage. When working with our DV material, we do have the choice to only pass our material through one MPEG encoding process directly to our target bitrate. As such, we will get the maximum quality from our video.

Considering miniDV is at a bitrate of 3.5MBps (that's mega BYTES per second), you will be hard pressed to come anywhere near the original quality when MPEG encoding for DVD. The max bitrate of DVD does not come anywhere close to that. That being the case, you want to try to retain the original quality for as long as possible before the final (and only) encode to MPEG video for DVD. It is exactly for this reason that I think Sony's MicroMV format is crap! MicroMV records in MPEG format. That's how they're able to fit that much on such a very small tape. Of course, even passing this through ONE step of MPEG encoding is really a SECOND step through considering how the recorder puts the video on tape. This is why I went with miniDV instead of microMV when I bought my camcorder.

[jzaman]

TRILIGHT:

I now see your point. Thanks for the feedback.

P.S. I also work with miniDV for the same reason.

[Arky]

Re' MicroMV, I couldn't agree more:

http://forum.doom9.org/showthread.php?s=&threadid=38468&highlight=MPEG+editing+Arky

http://forum.doom9.org/showthread.php?s=&threadid=39527&highlight=Arky+microMV


Arky ;o)

[TRILIGHT]

Ah...you are ever so wise, Mr. Arky. ;) I've been very pleased with my decision on the Sony TRV-38. I'm encoding using Procoder at an average of 5000kbps and the results look great.

[ulfschack]

I discovered long ago (2 years) that TmpgEnc handles DV better than CCE ... and I've made follow-ups too. I've never tried Procorder but I hear a lot of good about. I'll certainly compare asap. Have you?

Some tips:

Don't deinterlace ... don't. If you found deinteralced CCE encodes to have the highest quality you haven't explored the options fully yet.

Add borders. TV overscan consumes a lot of the picture area (in my case close to 20%). Adding borders has two edges to it: 1) the obvious reason of saving bits per viewable pixel. 2) The narrow angle of most DV cams becomes lesser yet. (you know ... having to stand in the hallway in order to get all relatives in the same shot :))

You'll have to resize if you add borders (obviously). Make sure you do proper deinterlaced resising. I do it by splitting the fields, resising and weaving them back together again in avisynth, but there are apps that'll do it for you as well. If you're into temporal filtering you'll have to split the fields anyways due to the odd scanline displacement. (Yes handling interlaced material is a bitch, but worth it if you do it right.)

Frameserve from your editing program. Intermediate DV files are of course compressed a second time. There are free frameservers for both Vegas Video and Premiere.

Spend a lot of bits on the average. DV is much tougher to compress than Hollywood movies.


Eh ... that's about it. I think you know most about the other stuff.

[Arky]

Yes, it's true, TMPGEnc is very good for encoding DV material, but it is just so PAINFULLY slow (which is the main reason I shifted over to CCE-SP). Also, as I've mentioned a few times before, TMPGEnc's motion searching is a little lacking at times of rapid movement / fast action. That said, if Hori San could somehow increase the speed of the encoder by, say 300 percent, then I'd happily give it a second chance. My personal view on ProCoder is that I suspect (although I must make it clear that I only have subjective grounds on which to base this suspicion) that, at least in Mastering Quality, it invokes some image filtering prior to encoding. This would explain the very fine loss of detail I have observed in comparison to CCE encodes of DV footage. It is negligible, but to my eyes, it is there. Obviously if there is such filtering, it would improve the efficiency of the MPEG encoding process, and yield cleaner results for a given bitrate.


Arky ;o)

[ulfschack]

I'm keeping my fotage for (hopefully) decades, so overnight encodes really are of no consequence to me. It's funny what you say about bad motion detection in very "violent" action clips is suffering in TmpgEnc because that's excactly the opposite of what I found. CCE simply couldn't handle those handheld shaky home DVs.

I heard a lotta good about (the expensive) ProCoder but, like you, I get the impression that there's some preprocessing (hearsay only), and that's plain cheating to score some cheap points whith "quality newbies". I'm sure that q-values are probably better than for TmpgEnc, but so would an overly blurred clip from a lesser encoder be.

The extra bits spent on unfiltered DV is well worth it IMO. There'll soon enough be RT filters to take care of those things upon playback. I also think it's likely that they will be sample-based which will probably not work well with heavily filtered clips.

I encode my invaluable home DVs at top quality unfiltered to get as close to what the camera sees as possible. I still get 1 1/2 h's worth for the price of $3-4 (and it'll of course get cheaper still). Couldn't care less about H-wood movies. It's fine by me to blur a little in order to get grainy port of "Grease" on to on disc w/out the blocking.

Hope I make some sense :)

cheers

[TRILIGHT]

Originally posted by Arky
This would explain the very fine loss of detail I have observed in comparison to CCE encodes of DV footage. It is negligible, but to my eyes, it is there.

Must be what you are testing with, Arky. I've used a few different clips and have always found that Procoder does much better on detail than CCE did. My biggest complaint was that it seemed to handle large solid colored areas a bit worse than CCE. Overall, I still feel it provides a better image although they are pretty damn close. You have to pause and look for stuff. In normal day to day watching, I doubt a layman would notice.

[Arky]

mmmm...well the footage that I particularly noticed the very slight smoothing/blurring on was a total of about an hours' worth of footage of a day out gliding, with the grass on the airfield showing quite clearly (to a critical eye) that CCE was being more 'honest' in it's detailing than ProCoder was.

I think it is very important to re-iterate that I was only using Mastering Quality (which takes so long to complete that most people choose to use a faster setting, such as HQ). I strongly believe that the reason MQ takes so long is not solely due to more thorough motion-search routines, but rather to the introduction of filtering into the process. Therefore, when people make comparisons between ProCoder and CCE or TMPGEnc, I feel they should always state what quality setting they were using with ProCoder.

Perhaps this is why we are drawing different conclusions. Over and above all other considerations, though, let us not forget that (picture) 'Quality' is by it's very nature a subjective thing, so maybe we're all getting identical results but just interpreting them differently!

And while I don't dispute your feelings about TMPGEnc with fast-action footage, ulfschack, I do stand by my own findings on this point. Again, perhaps this is purely subjective. To be honest, my ideal encoder ( for DV ) would be either:

#ProCoder speeded up, and with the VBR tweaking (including visual stream analysis between passes) that CCE-SP offers, along with less of the filtering that I believe is being employed behind the scenes.

OR

#CCE with the absurd field-order issue dealt with properly, once and for all, so that deinterlacing would no longer be necessary for DV encoding, along with more powerful filtering options invokable only if and when I felt they were necessary.

It's such a pity that Canopus are charging too much for ProCoder. £300 yes, £600 - err, "no, I don't think so!". Just because Discreet are charging over the odds for Media Cleaner (which has always been overpriced and overrated, a fact illustrated by the way it has been passed around like a hot potato by so many software vendors in such a short space of time), does not mean that Canopus need to do the same for their competing (and admittedly superior) product. Personally, I wish they'd release a version of ProCoder which would have all the existing capabilities but would only be able to output to MPEG1 and MPEG2. It'd sell by the bucket load in that format, for £250 or so.


Arky ;o)

[jopereira]

This is an interesting thread.

I found myself encoding with Vegas (MainConcept) codec as I think quality is near ("equal" ?) to CCE.

I recently have a "pixelation" effect applied to a home video and MC was better, by far, than CCE. That really surprised me as MC @ 6Mbps was better than CCE @ 9Mbps!!
The big, solid color squares were really good looking (solid) in MC, were CCE (v2.50) gave me "dirty" squares (noise imposed by high frequency square edges). This was perceptible in normal video motion, but I confirmed it with paused images as well.

Perhaps CCE is better @ 5000Mbps or less, and using more than 3-passes, but at higher rates MC seems to be better.
I didn't compare small details in image. I was only comparing images as a normal "spectator". We often go beyond that in our tests, but I really don't think comparing paused pictures is a valid way to make comparisons. After all this is a video codec, not a still picture codec. The same is valid with video test patterns that could lead to some mistakes, as 'real' video is not like that...

Since Vegas has a recent (free) plugin to provide frameserving, I'll try trial versions of both CCE and TMPGEnc soon, and I'll post here my findings.

BTW, for those who use TMPGEnc and CCE: Settings, please?

[jopereira]

I tried MainConcept (Vegas 4.0b), TMPGenc 2.510.49.157 and CCE SP 2.67.0.9.
Bitrate: VBR 6000Mbps, max 9000, min. 1000
Audio: AC-3 stream
Mux: I used TMPGEnc to mux video and audio streams

Scene: I must say the stream is not very dificult to encode but there was some details that can reveal a good/bad encoder.

The winner is ... MC codec!

Since I don't want to go the into encoder parameters too much, I used standard settings. I know that we can optimize encoders taken a given video, but I really want to how they were "as is".

The only one I didn't liked was CCE: this version doesn't have UPPER/LOWER field selection... the image was jerky. More, the AC-3 stream didn't work with CCE video stream. That could be sorted out, I think.

Image detail is the same in both CCE and MC, but seemed a little blured in TMPGEnc.

Color wise, MC and CCE gave me the same after I selected 0-255 output level in CCE - standard is 16-235 (brighter image).

TMPGEnc adds little black bars (both lelf and right) once I selected Source : 4:3 625 line (PAL).
I think I must select "4:3 Display" to have TMPGEnc not to resize image - could be that the origin of "blured" image?

In that "pixalation" effect TMPGEnc seems to be the best and CCE the worst with too much noise around the edges - showing that the encoder doesn't like sharp edges too much. Althought, that is only visible in paused mode - not very important in normal video since this is a very fast scene change (we cannot see small details that appear in 1/25th of a second...)

CCE image always seemed to be noisier than the other encoders. I think that could be an advantage in low bitrate modes. I remenber using CCE when encoding SVCD, where TMPGenc showed macro-blocks. Noise is better accepted than those blocks.
CCE also produced a not so stable image. Part of the scene was recording using a tripod and parts of it are "moving" (not stable).

At least for me, CCE is no longer on the top, and TMPGenc seems to be at least as good as CCE in DVD modes (particulary with interlaced DV picture - not sure about progressive Hollywood movies...).

[TRILIGHT]

Originally posted by jopereira
At least for me, CCE is no longer on the top, and TMPGenc seems to be at least as good as CCE in DVD modes (particulary with interlaced DV picture - not sure about progressive Hollywood movies...).

I could comment on a lot of other things said but I'm not sure I want this thread to turn into an opinionated "I think this is better than that" when none of us have the same original DV material to compare with. As for CCE being "no longer on the top", I must say its still rather good. I still have to put Canopus Procoder slightly above it though for interlaced DV material. I'd like to try the Main Concept encoder as I have not yet had a chance to.

As for progressive material, I've yet to see anything come anywhere close to CCE's quality and speed combination. Though tmpgenc comes close on the quality, it still falls short from time to time and the excrutiatingly slow speed makes it all but useless in comparison.

[jopereira]

Originally posted by TRILIGHT
I could comment on a lot of other things said but I'm not sure I want this thread to turn into an opinionated "I think this is better than that" when none of us have the same original DV material to compare with. As for CCE being "no longer on the top", I must say its still rather good. I still have to put Canopus Procoder slightly above it though for interlaced DV material. I'd like to try the Main Concept encoder as I have not yet had a chance to.

As for progressive material, I've yet to see anything come anywhere close to CCE's quality and speed combination. Though tmpgenc comes close on the quality, it still falls short from time to time and the excrutiatingly slow speed makes it all but useless in comparison.

As long as we stay constructived in our opinions, this is always a good discussion - that's why these forums exist in first place.
I always try to find details that others spoke about. I could not be aware of it, but once someone says "in X details, Y endoder is best" I always try to see it for myself. That's why I was particulary observant about detail lost in my tests. I was always concentrated in artifacts and macro-block.
We could always give more importance to a subject than another, but that's our own choice.

You almost confirmed what I thought about progressive material. CCE is probably the best - at least the last time I checked! I can hardly seem differences between an original DVD and a SVCD made by CCE. And the differences I see are all about lower resolution and not related with artifacts or bad encoding.

Please try MC codec and give us your opinion.
For me, I'm yet to see a point where CCE is better than MC in DV encoding - not even in speed (althought CCE is REALLY fast making 3-pass in no time...).

[Arky]

Originally posted by jopereira
I tried MainConcept (Vegas 4.0b), TMPGenc 2.510.49.157 and CCE SP 2.67.0.9.
Bitrate: VBR 6000Mbps, max 9000, min. 1000
Audio: AC-3 stream
Mux: I used TMPGEnc to mux video and audio streams

Scene: I must say the stream is not very dificult to encode but there was some details that can reveal a good/bad encoder.

The winner is ... MC codec!

Since I don't want to go the into encoder parameters too much, I used standard settings. I know that we can optimize encoders taken a given video, but I really want to how they were "as is".

The only one I didn't liked was CCE: this version doesn't have UPPER/LOWER field selection... the image was jerky. More, the AC-3 stream didn't work with CCE video stream. That could be sorted out, I think.

Image detail is the same in both CCE and MC, but seemed a little blured in TMPGEnc.

Color wise, MC and CCE gave me the same after I selected 0-255 output level in CCE - standard is 16-235 (brighter image).

TMPGEnc adds little black bars (both lelf and right) once I selected Source : 4:3 625 line (PAL).
I think I must select "4:3 Display" to have TMPGEnc not to resize image - could be that the origin of "blured" image?

In that "pixalation" effect TMPGEnc seems to be the best and CCE the worst with too much noise around the edges - showing that the encoder doesn't like sharp edges too much. Althought, that is only visible in paused mode - not very important in normal video since this is a very fast scene change (we cannot see small details that appear in 1/25th of a second...)

CCE image always seemed to be noisier than the other encoders. I think that could be an advantage in low bitrate modes. I remenber using CCE when encoding SVCD, where TMPGenc showed macro-blocks. Noise is better accepted than those blocks.
CCE also produced a not so stable image. Part of the scene was recording using a tripod and parts of it are "moving" (not stable).

At least for me, CCE is no longer on the top, and TMPGenc seems to be at least as good as CCE in DVD modes (particulary with interlaced DV picture - not sure about progressive Hollywood movies...).



Keeping things constructive( ;) ), when I got home from work this morning, I ran some quick encoding tests with a 3 minute clip of a darkened room with flashing coloured lights and people jumping around - those of you who were born in the 70s or earlier will recall that these used to be referred to as "discoteques" (damn, I feel old!). Sarcasm over...

Basically, it's been a while since I can recall a good discussion on the status quo of the current crop of MPEG encoders, so I was inspired to do the above (admittedly very brief, and far from exhaustive, or, indeed, scientific) tests. I deliberately chose an extremely difficult piece of footage to encode. Along with the darkened room and flashing lighting (this really is any MPEG encoder's worst nightmare), I chose a segment where there is bad camera shake at the beginning of the shot, with the zoom being simultaneously adjusted. Thus, there are massive sweeps of colour flying across the screen (especially one person who is wearing a bright red T-shirt), prior to the zoom being reduced to a sensible level. On top of all this, the darkness made the picture extremely grainy too, with my poor 900E struggling to find enough gain to cope. Obviously this would never make it into a final cut, but its a perfect opportunity to really punish an encoder.

I tried to make as many settings identical between encoders as I possibly could, and my results have not been viewed on an interlaced screen, since they weren't worth writing to DVD-R. Therefore, they've only been played back on my TFT, which is, of course, progressive, but very capable of highlighting bad encoding anomalies and artifacts, such as macroblock distortions.

Parameters used:

# 2-Pass VBR

# Interlaced (yes, I know that CCE will have the fields the wrong way round, but I took a little liberty by ignoring this, since my viewing of the results of all encoders was only to be on a progressive screen - I know this is a bit cheeky. I also didn't want to be accused of feeding CCE with Progressive, which is its favourite source format. In this test, therefore, I am deliberately giving CCE a hard time). I also chose not to introduce AVIsynth into the equation (for deinterlacing the source) because I wanted to avoid any accusations of meddling with the source.

# Average bitrate = 4650kbps (deliberately not too high, in order to highlight differences)

# Minimum bitrate = 1000kbps

# Max bitrate = 8500kbps (I always like to play it safe to avoid any issues with incompatibility).

# DC precision = 10

# ProCoder was not allowed to use Adaptive Deinterlace.

# Owing to past discussion (by mb1, amongst others), I did not use ProCoder's own DVD template. This was in order to give ProCoder the best possible opportunity to shine, because previous discussions have pointed to the DVD template yielding lower quality results than manually keying in the parameters on a basic MPEG2 substrate.

# I used the 'moderately difficult' image complexity setting in both CCEs.

# Any more parameters, I'll be more than happy to provide if anyone wants to know.


Encoders tested:

CCE-SP (2.67.00.08 ) (using mb1's interlaced DV matrices)
CCE-Basic (demo) (using mb1's interlaced DV matrices)

ProCoder 1.0 (demo - the retail version has now been tweaked by Canopus but I don't know if that would have made any difference in this particular test). Both "Highest Quality" and "Mastering Quality" modes were tested.

*********************************************************************

Results (which, of course, are subjective):

At the very worst portion of the tape, described above, where an over-zoomed, screen filling sweep of red T-shirt (so fast that it's a little blurred, even in a paused frame) goes across the screen, immediately preceded, and followed, by relative darkness, save for the flashing coloured lights, I examined the encodes in a paused state.

The results were shocking to me. I had not expected to see any large differences, but here, clear as day, were some very glaring differences (I can provide stills if anyone wants to see them and I assure you that there is no 'tampering' with bitrates between encoders, to amplify the differences). Both ProCoder and CCE had difficulty with the spotlights at the rear of the shot, with both of them taking a different (and not entirely accurate) approach to dealing with them. ProCoder encoded them as larger blobs of white than CCE-SP did, although I had no real preference as to which interpretation I preferred - I was simply surprised at the difference. More worryingly, though, I witnessed very obvious (but only in a paused state) macroblock distortions with ProCoder's HstQ attempt, and less so, but still obvious, with ProCoder MQ. Both CCE encodes, on the other hand, were almost entirely absent of such distortions.

Interestingly, when played back in motion, it was difficult to see any differences between any of the encodes. All clips had seemingly identical levels of detail (and graininess), with ProCoder not seeming to be any 'cleaner' than CCE. CCE basic seemed to produce an image, though, which was subtly (and I mean almost imperceptibly so) brighter than CCE-SP, although broadly speaking, colour fidelity remained identical between the two sibling encoders. Interestingly, I observed no significant differences (this time around) in detail levels between ProCoder or CCE.

I haven't yet run TMPGEnc through the test, simply 'cos I was too tired and I've only just woken up again. I'll edit this post later, to add TMPGEnc results.


So, in summary, nothing scientifically conclusive, but a shock to me that, subjectively, ProCoder performed significantly worse, in terms of the macroblock distortions I witnessed, than either of Custom Technology's offerings. I was so affected by my (brief) findings, that I was galvanised to finally splash the $58 for CCE Basic. The quality of output, matched by the awesome speed (I don't care what anyone says - this IS an important issue if you are editing DV and authoring to DVD. Only if you were ripping a Hollywood backup would it be irrelevant), means it is a no-brainer as a fully-licensed encoding solution. I cannot currently afford ProCoder, and I must say that I'm not sure now that I would wish to spend so much on it, even if I could afford it (unless I was encoding from, and to, multiple formats, and possibly also converting back and forth between PAL & NTSC). Don't forget that in my short test, ProCoder's best output (Mastering Quality mode) took 1hr & 57 minutes to encode, whereas both CCE-SP and CCE Basic took a little under 6 minutes (2.26ghz P4 533FSB; 1Gb RAM; seperate source and destination HDDs; no overclocking). In an editing/authoring environment (as opposed to RE-authoring/backing-up), it is often necessary to alter the final result if it proves dissatisfactory on final viewing. In such instances, it is absolutely vital that one is able to re-edit the project (from the original DV files), and then re-encode to MPEG2 again. An encoder which takes all day, all night, or both, to encode a 90minute project simply demonstrates that the "I don't care how long it takes so long as I get good quality" argument cannot stack up.

Temporal de-interlacing distortions notwithstanding, I currently use AVIsynth to deinterlace my source before feeding it to CCE (Basic, as of today :) ). I feel that despite the temporal issues, I still get, in terms of license price, encoding quality, and encoding speed, the best solution available. It is also possible for me to use Edition to render my projects progressively, which would skip the AVIsynth step, but I tend not to do this where I am only doing fast cut editing, simply because it's way quicker to use Edition's 'Fuse' feature, rather than doing a complete render. I only wish I could find a working solution to frameserve from Edition to CCE (anyone got any ideas on this point?).

I will continue to watch the "ProCoder is best for DV" debate with interest. I particularly remain interested in ProCoder as a DV encoding solution because I have massive respect for mb1 and he favours ProCoder over CCE for DV encoding. For the time being, however, I must follow my own findings and suffer the indignity of having to deinterlace before feeding CCE. I pray that Custom Tech will wake from their slumber and sort this issue out in the near future. It won't be a minute too soon.

I welcome constructive criticism of my findings - even if they totally refute them.


Arky ;o)

[TRILIGHT]

Originally posted by Arky
For the time being, however, I must follow my own findings and suffer the indignity of having to deinterlace before feeding CCE. I pray that Custom Tech will wake from their slumber and sort this issue out in the near future. It won't be a minute too soon.

Hey Arky! Thanks for taking the time to look at this and post your findings. Very interesting information. I am not sure that I am clear on your statement hear about having to deinterlace before feeding to CCE. I have encoded, leaving the material as interlaced, in CCE and have found it to be just fine. I use the appropriate settings for interlaced material, of course. (non-linear quant., alternate scanning, etc.) The one problem I have is that I have to run the resulting encode through pulldown.exe to change the field order so the playback is smooth once again. Interestingly enough, I seem to have to do the same thing with Procoder! I don't know what the hell the problem is there but regardless of my choice of TFF or BFF in Procoder, I have to make the same field order adjustment with pulldown.exe for things to look right.

I guess I wouldn't be so worried about this whole encoder thing if it wasn't for me wanting to start doing things as a side business for people here in town. I obviously want the best encoder and the one that will save me the most time given the editing and re-encoding involved. (quite a valid point indeed, Arky!) I do not know what version of Procoder I have. I must admit it is not mine. I borrowed it from a friend to test. Ultimately, I'll need to make an encoder purchase though and I want to make sure I have the right thing given the cost involved. Incidentally, I am curious if anyone knows if the same "encoding of DV material" considerations apply to video run through the digitial camera's "pass through" option? I would think so as (from what I understand), it turns the incoming video into DV format. Please correct me if I am wrong here though.

[Arky]

Originally posted by TRILIGHT
I am not sure that I am clear on your statement hear about having to deinterlace before feeding to CCE. I have encoded, leaving the material as interlaced, in CCE and have found it to be just fine. I use the appropriate settings for interlaced material, of course. (non-linear quant., alternate scanning, etc.) The one problem I have is that I have to run the resulting encode through pulldown.exe to change the field order so the playback is smooth once again. Interestingly enough, I seem to have to do the same thing with Procoder! I don't know what the hell the problem is there but regardless of my choice of TFF or BFF in Procoder, I have to make the same field order adjustment with pulldown.exe for things to look right.

OK - confession time:- I've never used Pulldown.exe (ever!). Methinks I should try this. I always assumed the easiest option would be simply to use AVIsynth to deinterlace the input. I shall get back to you with the results of my findings, re' playback smoothness on an interlaced screen with this method. Thanks for the 'heads-up' on that. Does this definitely work ok for PAL?

Originally posted by TRILIGHT

Ultimately, I'll need to make an encoder purchase though and I want to make sure I have the right thing given the cost involved.

As I said, in my personal opinion (and the previous posts demonstrate that others have different opinions), the cost-/-performance-/-quality ratio of CCE Basic is just streets ahead of anything else on the market, notwithstanding the remaining bugbear of the 'upper field first' issue with CCE.

Originally posted by TRILIGHT

Incidentally, I am curious if anyone knows if the same "encoding of DV material" considerations apply to video run through the digitial camera's "pass through" option? I would think so as (from what I understand), it turns the incoming video into DV format. Please correct me if I am wrong here though.

Yeah, I would imagine it get's 'DV'd when you run this operation. My TRV900e doesn't allow pass through - one has to dump the analogue input to tape nefore exporting as DV as a seperate procedure, so I can't test this for you I'm afraid.

Anyway, gotta go cos I'm on my mum's computer and she needs it back for work!

Cya :D


Arky ;o)

[TRILIGHT]

Originally posted by Arky
OK - confession time:- I've never used Pulldown.exe (ever!). Methinks I should try this. I always assumed the easiest option would be simply to use AVIsynth to deinterlace the input. I shall get back to you with the results of my findings, re' playback smoothness on an interlaced screen with this method. Thanks for the 'heads-up' on that. Does this definitely work ok for PAL?
I would imagine that it would be just fine. Afterall, you won't actually be doing any sort of "pulldown" of the material or changing the FPS. All you're doing is using its ability to change the field order. Now I'm not totally sure but you will probably have to specify your FPS as I believe pulldown.exe defaults to 29.97. So, (and I'm going on memory here), I believe the setting you would use would be as follows:
pulldown.exe <source> <destination> -nopulldown -framerate 25 -tff even
Where, "<source>" and "<destination>" are your filenames, of course.

[Arky]

Yeah, I had a play with it on my own PC as soon as I logged off the net on my mum's. I worked out to do exactly as I see you have since written. I began to author a Maestro project with three different streams - the same encode, but:

# untouched by pulldown.exe

# even field 'modified' by pulldown.exe

# odd field 'modified' by pulldown.exe

I used my new licence for DVD Menu Studio (MediaChance), and had three buttons on the menu, one for each variuant of the CCE-encoded stream, as described above, but was rushing to meet my mate down the pub, so I didn't have time to import it into Maestro and finish the quick authoring job. I'll report back with my findings once I finish writing the job to DVD-R and playing it back on my standalone.

I'm off to bed now. Got to get my body clock back to normal after a week of nightshifts! (Y-A-W-N-!-!)

Oh, I decided to use the WoofSoft GUI version of pulldown, BTW. Incidentally, you are correct that it automatically assumes 29.97 fps, unless you specifically tell it otherwise!


Arky ;o)

[ulfschack]

Nice and relevant comparison, Arky!

I'm about to dump a DV tape for editing in the following days, so I'll try to contribute my findings regarding these three Encoders. Over the last couple of months I've felt that it was high time to make up my mind yet again ... which one to use.

I have to agree with Trilight on the field issue. Even if I mostly use Tsunami for DV I certainly also made succesful encode with CCE keeping the interlacing. Maybe ran it through pulldown or maybe i solved it by ComplementParity in avisynth, I dont really remember. But I do remember it not being a real problem.

good thread

Cheers

[TRILIGHT]

I've updated the title of this post to something I feel is more appropriate. I used poor wording in the original post.

[Arky]

Originally posted by Arky
...I didn't have time to import it into Maestro and finish the quick authoring job. I'll report back with my findings once I finish writing the job to DVD-R and playing it back on my standalone.

Arky ;o)


Apologies, lads, but I've decided to visit my mate for a few days, now it's my week off, so I won't have time to finish the above test before I get back. I will, however, be able to keep in contact on the forums, to see what tests you lot are doing, and see what conclusions you draw. When I get back home on Tuesday or Wednesday, I'll finish the authoring/burning of my test and report back with my findings. I had hoped to repost the results, but going to see my mate has been a last minute decision, so I'm rushed off my feet! ;)

I look forward to reading your conclusions, even if they are completely at odds with my own :)


Arky ;o)

[ulfschack]

Yes, I wont make any promises about deadlines either, but during the weekend seems very likely for me.

On another note. Wouldn't it be nice to get rid of subjectiveness :) I'm thinking in terms of letting a progam measure the quality for us. Atleast that way it'll get the same treatment every time. Is it all all possible I wonder. Using Avisynth's Compare will yield SNR in relation to the original (or really what we choose to compare it to). Programs like Bitrate Viewer makes judgements of quality (atleast Quantifier factors ... which probably is by no means directly related to quality anyways) without the need for a reference clip. I suspect though that a very blurred picture will favor the quantifier, which is not what we want, especially since it seems as Procoder has such "features" built-in. Maybe a combination SNR and Q-value would be interesting?

Does anyone know what the Authoring houses use for quality measurements? They have to have to have some form of it. Why else would they otherwise not fill up both layers for every production? Do they author GOP-wise and just see where they end up? ... seems unproffesional somehow. But ... I'm babbling. This is a little OT.

Should this thread not be moved to the DV forum?

cheers

[TRILIGHT]

Originally posted by ulfschack
Should this thread not be moved to the DV forum?

It's a hard call to make, really. Considering I am specifically interested in DVD encoding information and the material itself just happens to be DV, I feel it should be here. There could be many users in the DV forum who never encode to MPEG2 for DVD at all and this discussion would be lost on them.

As for what you said about measuring with some software, I am unsure of a piece of software that does this effectively and accurately. Not to mention that people's eyes see things differently. I've always felt that r3mix.net was a great site for testing the different MP3 encoders out there and different settings and showing the facts of the results. While people hear things differently also, it's easier to do with music. Afterall, things start becoming much more transparent at a much lower bitrate with audio. Most main 6-ch tracks on DVD are encoded at 448kbps.

With MPEG2 video, the bitrate can be as high as 9000-something kbps and it's much more difficult to make things transparent to the eye given the bandwidth involved. Afterall, ask yourself how far you can see as opposed to how far you can hear. ;) At any rate, I have not personally seen accurate software for measuring MPEG2 video quality in an unbiased fashion. I would imagine this is best done via broadcast hardware devices but since I don't work in the industry, I really don't know.

[Arky]

I'm satisfied with this thread being where it is - it's as good a place as any, considering what Trilight said, and it's running quite healthily here.

Regarding objective quality measurement, I'm really not sure what they do in the industry, but to be quite honest, it wouldn't surprise me in the least if it's done subjectively by the guy whose task it is to encode the footage for projects! As with wine-tasting, if you experience something often enough, you become very acutely aware of differences in quality, and the human eye, properly trained, is as good a measure as any. I've seen some pretty ropey encoding jobs (and poor menus) on Hollywood blockbusters, so perhaps these people are not always quite as quality conscious as we presume.

The only measurement tools that I am aware of are those from Manzanita systems, but they are not what ulfschack was describing:

www.manzanitasystems.com



Arky ;o)

[ulfschack]

Actually I asked before even checking it out myself :rolleyes: .There seem to be some papers on the subject as well as hardware (expensive as hell). After some browsing it was pretty apparant that it indeed is signal to noise comparison with the original that is often used for mpeg quality assesment. I'll use "compare" from Avisynth and see if it makes any sense at all to bring it in. Even so you're surely not gonna escape my personal judgement :p.

Enough talk allready ... I'm hearing a whole quire of impatiant voices in my head yelling "get on with!" in a pythonesque fashon ... (or am I being paranoid):D. As soon as my wife'll let me I'll put some heart into it. Hopefully tonight.

cheers

[ulfschack]

I ran three encodes:

1) CCE 2.50 SP., 3+1 pass
2) Procoder 1.01.08.0, 2-pass
3) TmpgEnc 2.59 plus, 2-pass

The clip was 2 1/2 minute clip of a woman playing with a child in sunlit snow. Lots of action, edges and contrasts.

I'd like to post som Gifs I made on some graphs, so I'll post the second picture in a following post. I haven't figured out how to attach more than one at a time, see :)

Bitrate: 5000 (files came out 85,1, 84.9 and 85 MB)
NO filtering. Interlaced.

I actually agree with the "Psnr.gif" allthough there's no way in hell that Procoder is that much better than the two others. It's really hard to make out the differences between these three fabulous encoders, but this would probably be the order I'd choose (higer PSNR = Better). This was the script:

a=directshowsource("c:\clip.avi").converttoYUY2()
b=mpeg2source("c:\tsu.d2v").converttoYUY2()
compare(b,a, "","c:\logyuy2_tsu.txt")


... in case someone wants to know.


TmpgEnc did have blocking in high motion areas. CCE blurred it a little so it wasn't that apparent. Procoder managed to keep it fairly sharp while not showing blocking.

There's one thing that bothers me though. CCE and Procoder seemed a little more "washed out" in the colers/lighting/contrast than did Tmpgenc ... sort of the reason you do an autolevel in Photoshop, to fill out the spectrum. I think it's just a missed setting somewhere, so I decided not to let that influence my desicion. If it had ... TmpgEnc would've come out on top.

[ulfschack]

And here's that Q-levels and bitrate for the three encodes according to Bitrate Viewer

Again the visual does not confirm this to the letter, i can tell you. I mean look at the q for Tmpgenc, it's way up there! One would think one would notice, no?

Anyways for what it's worth im posting it.

[jopereira]

Originally posted by ulfschack
TmpgEnc did have blocking in high motion areas. CCE blurred it a little so it wasn't that apparent. Procoder managed to keep it fairly sharp while not showing blocking.

There's one thing that bothers me though. CCE and Procoder seemed a little more "washed out" in the colers/lighting/contrast than did Tmpgenc ... sort of the reason you do an autolevel in Photoshop, to fill out the spectrum. I think it's just a missed setting somewhere, so I decided not to let that influence my desicion. If it had ... TmpgEnc would've come out on top.

1. That's what makes CCE look much better in some situations: I haven't see macro-blocks in CCE output so far. What it does is making some kind of noise if the bitrate is too low. That noise is perceptable in picture overall quality (lack of picture definition), but is much better than macro-blocks.
MC seems to leave both noise and blocks out where CCE makes taht noise (meaning high frequencies are 'converted' to lower frequencies - egdes not very well defined).

2. The CCE output is washed out if you leave colour range from 16-235. Make it 0-255 and everything goes back in trails...

[Arky]

IMHO, TMPGENc has always produced rather 'rich' colours. I think it actually produces richer colours than the source material, in many instances, but the effect it still rather pleasing to the eye. Again, this is subjective!

http://forum.doom9.org/showthread.php?s=&threadid=13033&highlight=tmpgenc+colour+arky N.B. please note that some of the remarks on this thread are now a little out of date, so read the thread with it's date in mind! ;)


Arky ;o)

[jopereira]

I found this (russian) page. I cannot read it but the pictures are in portuguese... :)

There you can see what I'm talking about CCE. See the bike front wheel: both CCE and TMPGenc have artifacts around it (and around the drivers and bike bodies). Canopus seems to be better in this point.

http://www.spline.ru/DigitalVideo/MPEG2EncodersComparison.htm

[ulfschack]

Strangly, I am using 16-235 in both TmpgEnc and CCE (for procoder I haven't noticed this setting. But I'll play around since you seem pretty certain.

About 1) above. Blur isn't always better than blocks. For me probably the threshold is lower than for most (i really hate blur :)). Now I'm not saying that CCE blurs and TnpgEnc are crisp and blocky. The levels we're talking about here are so subtle, that it takes some very close looking and zooming. So subtle as a matter of fact that I would really like to encode at SVCD settings instead ... to more clearly show the differences. But since I'm not gonna use the encoders for anything other than High bitrate DVD I feel it's pointless since behaviour can be radicadly different depending which end of the (bitrate) scale we're looking at.

Wonder when my gifs are gonna show up(?)

[Arky]

Originally posted by ulfschack


Wonder when my gifs are gonna show up(?)

I just validated them for you :)

Hmmm.. just looking at your BitRate Viewer graphs and I think you perhaps made an error? Graphs 1 and 2 look identical...


With reference to the SNR graph, I must say that I am still suspicious that ProCoder MQ introduces filtering, so such a comparison would not necessarily show what it, at first, appears to.


Arky ;o)

[ulfschack]

Indeed there is an error. Procoder is represented twice. I have attached the correct on from CCE. Sorry and thanks.

Incidentally Arky, all these movies where done with the default settings for field order. And all played brilliantly from a DVD that I authored in Maestro. I did have the "upper field first" box checked in CCE, eventhough bitviewer, Procoder and TmpgEnc say and use the opposite order.

I later ran a second encode of Procoder to see if I missed anything and found that I could set it to force "field based" encoding. Don't really know the meaning of that, but it seems not to be 100% comatible. WMP (using a DS filter called vobmpeg2.ax, which I think was installed by InstantCopy) produces crap (sharp blocks of miscolorations that sort of makes it look like a mosaic). Using mpeg2dec after running it trough dvd2avi went a lot better, but there were still crap frames every now an then. Finally authoring and burning on DVD got rid of all playback errors and I could enjoy the best encode yet.

To my eyes it looked identical to the frame based encoding except when i zoomed reeeal close on heavy action areas, where it was an iota better. But running it through "subtract" in avisynth it was probably more than just a little different since I actually by viewing that gray difference area could make out where in the clip I was looking (as in seeing silhouettes and mosquitoes). So it does get better with field based and my Phillips 622 can handle it, but I'm still not sure I'll make it the future of my DV encodes.

cheers

[ulfschack]

With reference to the SNR graph, I must say that I am still suspicious that ProCoder MQ introduces filtering, so such a comparison would not necessarily show what it, at first, appears to.

Absolutely a possibility. I also make sure to mention that
I actually agree with the "Psnr.gif" allthough there's no way in hell that Procoder is that much better than the two others.

If I just could get this "autolevel" effect of the colors that TmpgEnc has I think I'll have a new champion in ProCoder. I dont think that TmpgEnc makes Coca Cola colors whithout you requesting it. I have to much respect for that guy and simply refuse to believe it :)


Well, jopereira it would seem you know your stuff. putting the color range to 0 - 255 fixes CCE to have the same Hue/contrast/colors as TmpgEnc. I simply can't seem to find anything for the ProCoder, and I certainly wont degrade myself to make a filter chain simulating that effect. Plus seeing as it doesn't accept Avisynth either it probably has to step down for TmpgEnc ... These encoders are top of the line and the difference in quality isn't that great that I'd sacrifice even a simple addBorders for it.


cheers

[SomeJoe]

Nice work, ulfschack. The graphs and PSNR graph are nice quantitative comparisons between the encoders.

I'm curious if you have Premiere 6.5 with the built-in Main Concept MPEG encoder plug-in, or access to the Main Concept stand-alone encoder. I'd like to see how the Main Concept encoder stacks up to the other 3, using your source material and test methods. The compressed footage I've been getting from the MC encoder has, at least visually, been on-par with CCE from a subjective standpoint. I'd like to see the quantitative measurements to confirm.

[ulfschack]

Actually I was about to install P 6.5 when I got word (well now it's on the frontpage of Dooms) that there's a free frameserver application that takes care of a bunch of other NLEs than Premiere. The inability to frameserve was really the main reason for me not to use Vegas Video. So I don't know if I wanna install it.

Is there no other pack wher MC is integrated?

BTW thanks for your appreciation. However I'm not sure that the graphs are really a good measure of quality. Well it seems as if PSNR might be, but according to the Quantifier in bitviewer CCE is by several horselengths the better encoder, something that I have a hard time confirming visually. (Wait for Arky to validate the latest graph that shows CCE and you'll see)

cheers

[jopereira]

I finnaly tested Procoder too (1.01.8 I think). It seems to be on pair with MC encoder or even better.

Since I always tested at high bitrates (6000 and 9000Kbps) I made a test using 4000Kbps (VBR).
Those two encoder are definitively better than CCE in that "squares thing". Even at 4000Kbps, the squares are very well defined and sigle colored, unlike CCE that produces a dirty color pattern.