My Encoder Comparison Results

[Edmund Blackadder]

Again, this is not to bash but rather find a way to address the issue. Keep this in mind.



Source is on the left, Procoder on the right. Notice loss of detail in the middle (white clipping).

Again, this never happens with DV codecs, at least it never happened to me. I tried both Canopus DV codec and MainConcept DV codec files encoding into MPEG2 in ProCoder and it never clipped the values, or in other words it never expanded color space to 0-255.

The expansion randomly happens when you convert DV files to Huffyuv in any program. In fact Canopus DV codec will not expand to 0-255 when converting to Huffyuv, but MainConcept will. As you can see, the clipping happens way before you even import into ProCoder. I'd recommend converting MainConcept DV AVI to Huffyuv AVI in ProCoder with 601 shrink color space filter before importing into After Effects. Don't ever put DV codec AVI files into After Effects if you plan to save them to some other AVI type, because the results will always be unpredictable. Same goes for Premiere.

Speaking of other encoders, it actually was TMPGEnc that was crushing my colorspace of MainConcept DV files when converting to MPEG2, with its default settings! While CCE SP 2.50 was doing some crazy sharpening if I used MainConcept DV codec as input. Only if I convert a file DV header to Canopus DV (easy to do with Baobab DV File Converter), CCE was doing OK. ProCoder never had any of such issues.

So the point is, most of your color space problems happen because of the wrong codec settings, and before you even touch ProCoder. And Canopus went one step further for you by giving a 601 correction filter, so you can fix any of your pre-ProCoder color space mistakes.

Therefore I disagree with those of you who think that Canopus products have problems with color space. On the contrary, it puts out exactly what you put in, while still providing ways to correct what's been wrong with the original file.

Dipstick, if you encode your original DV file in ProCoder, you'll see that there is no color space change. Unless of course you ticked one of the checkmarks in your DV codec properties incorrectly. Also, how do we know that you decoded your MPEG2 files into still images correctly? They tend to vary, depending on software you use to capture MPEG2 to BMP, JPEG or whatever. That's of course just one slim possibility, but still, anything's possible. Please show us the tests done with the same encoders, using the same settings, but from your original DV file and not Huffyuv.

[proxyx99]

The other tester had it converted from Xvid:
https://www.videohelp.com/forum/viewtopic.php?t=255200&highlight=.

This is where I got above images from (!). Although your explanation is quite compelling these variations seem not limited to Huffyuv only.
Once again I wonder if PCExpress does the same and if so are these issues explained in a manual (you just cannot expect anyone who buys Canopus products to start with studying colorspace issues be4 they use them).

Ther has to be some common ground for all encoders regardless of the siource and if there are some individual issues I'm trying to identify them.

It is also unlikely (and has to be dismissed) that their jpeg conversion is at fault. All of them make the same mistake only with Canopus images ? (C'mon?!)

[Edmund Blackadder]

The other tester had it converted from Xvid

I had the same issue with one of the DivX files, while converting in ProCoder. Once I applied 601 shrink filter, the resulting MPEG2 looks colorspace-wise exactly like the original DivX file. I don't think it's that difficult to add one little filter to correct the situation.

I'm thinking that ProCoder presumes that all the non-DV AVI files are 0-255 RGB (and why shouldn't they be?), and converts them accordingly. That's when you have to apply the filter. However for DV files there is no such issue.

[dipstick]

Ok, this is the last time I'm going to upload frame grabs. I'm on dail-up and it's a pain in the a$$.

To keep everybody happy, I did as Vhelp sugested and cut a small section using "Stream Copy" in Vdub. The source is a stock DV-Avi as it came from a 5 year-old DV-Camcorder. Low quality compared to my current camera.

I encoded using as exact as possible settings for all encoders. VBR 1-pass - 9000 high - 6500 avg - Intra DC @ 10.

The results are a little interesting. This time Procoder didn't mess up nearly as much. Although there is still some detail loss (spot misssing on sidewalk just below collar) it's not nearly as bad as with the Huffyuv source.



I can upload the small avi if someone want's it.

[dipstick]

Again I ask:

I have a question for all you Procoder Gurus. How can you manually set the Block scanning order in Procoder? For instance, I want the finnished m2v to have either Alternate scan order or Zig Zag scan order that I choose. It's easy to do with CCE or MainConcept, but I can't seem to find any setting that will do it in Procoder. I can set the DCT to Field or Frame, but it doesn't have any effect on the Scan order used. Even if I feed it interlaced dv and choose Field based picture encoding, it will usually encode it with Zig Zag scanning order. Sometimes it will encode it with Alternate scanning order. It basically does what it wants with no regard to the source. I scan all my encoded videos in Bitrate Viewer for verification.

If it can't be done, please post as such.

Thanks.

[BJ_M]

dvd has to be frame based encoding ..

the scanning order and matrix is based on the profile and target type - cant be changed..

BUT it can change throughout -- bitrate viewer only reports the first gop ... you would need a much better mpeg analyzer ..
(bitrate viewer still a great program)

[dipstick]

Thanks BJ_M.

I didn't think it could be changed in Procoder, but I just wanted to make sure incase there was a setting that I couldn't find.

[proxyx99]

The other tester had it converted from Xvid

I had the same issue with one of the DivX files, while converting in ProCoder. Once I applied 601 shrink filter, the resulting MPEG2 looks colorspace-wise exactly like the original DivX file. I don't think it's that difficult to add one little filter to correct the situation.

I'm thinking that ProCoder presumes that all the non-DV AVI files are 0-255 RGB (and why shouldn't they be?), and converts them accordingly. That's when you have to apply the filter. However for DV files there is no such issue.

Of course it is not difficult, but you have to know that first. Obviously if ppl don't apply the filter it is not that they don't want to but because that they don't know.

On the other hand that also means that Procode, unlike other encoders does not detect color space and warn users that it is going to apply changes to it. In that sense it is no wonder that there is some confusion about it.

We have some progress at least that the problem was recognized and not tossed away.

It would have been a different story if Procoder after detecting a color space "out of bounds" warned about it and offered a filter option. That is a disappointment. When you indicated that it "assumes" a specific range it indicates that no detection takes place, if you are correct, and then the outcome is a toss up in the hands of a user who does not know about this limitation.

It is a bit disappointing especially in the light of other encoders clearly having no problem with this issue properly recognizing and applying detected color space whether dealing with DV or other sources. You would think that product of that class and price (!) would have all safeguards built in.

I repeat myself now but if similar action takes place in its Express version targeting general public than this would be a major defect/annoyance and huge oversight on Canopus part.

[BJ_M]

proxyx99 - encoders do not detect color space , none of them do ..


There is no defect you seem to fail to grasp somehow - I dont think you understand what a smpte chart is, or a pluge chart or how to read a video scope .... I dont know how to make to more clear to you... therefore - i give up and keep working at what i do (for a long time and very well i might add) ..

Canopus is by no means a perfect company - they certainly have had their share of software issues - but I can speak from first hand knowledge on the encoders and as well - several other companies products in which i worked on and also use on a professional level..

[ronnylov]

dvd has to be frame based encoding ..

the scanning order and matrix is based on the profile and target type - cant be changed..

BUT it can change throughout -- bitrate viewer only reports the first gop ... you would need a much better mpeg analyzer ..
(bitrate viewer still a great program)

I have made a DVD with field based encoding in Procoder without a problem. Why has it to be frame based on DVD?

I encoded it as field based with resolution 720x576 and with top field first and it worked without a problem in my Pioneer standalone DVD-player.

[BJ_M]

DVD compliant video has to be frame based. That is the spec.

Some players will play field based - many will not, in a test we did of about 12 players - about 3/4 would not .. this was almost two years ago ..


Field based WILL look better with a DV source - it's just not compliant is all ..

[proxyx99]

BJ_M, have you noticed that all you talk about is me and your CV?

I'm not interested, not for a bit, in the above but rather why ALL but Procoder output original-like images. That is undisputable (see above picsa and histograms again). I'm talking real life applications not charts. You fail to understand that there has to be reason for that and all I'm after is to name it. Instead of that, all you seem to offer is your credentials and off subject remarks. Speak to the matter. will you? As a reminder, the question is why is Procoder's output different and why does clipping occur?
Remember, I have not posted any results. I just point out what is obvious to a naked eye.

...I give up and keep working at what i do (for a long time and very well i might add) ...

Good luck and don't flatter yourself too often, it's kind of ...empty...(?)

[dipstick]

For the hell of it, I tried the 601 "Reduce Colorspace" filter with the Huffyuv source. I can confirm that it does work.

I also tried to sneak the Huffyuv into Procoder by frameserving it with Avisynth. Procoder did not detect it as Huffyuv, but it didn't make any difference. It still messed up the colors, since I didn't apply the 601 filter.

You would think that by selecting a DVD Template, it would use the propper colorspace regardless of the source, but obviously that's not so.

Oh well, a lesson learned here. Maybe someone may want to put up a sticky for encoding anything other than DV-AVI in Procoder to apply the 601 filter.

[troyvcd1]

I get high contrasty pictures in procoder.

I also got these same high contrasty images when using cce and the cdvc codec.

Yes I tried the color corrections in avisynth with no avail. When I switched to the dvsd codec and used cce the images lost the high contrast and appeared as the original source.

I have not tried the "601" thing in procoder though.

No matter what codec I used for procoder I still got the high contrasty images.

These were not proceced just take right from a minidv tape to the computer, cut and outputed with adobe premiere.

I dont know what all this means or how to fix it but for now I am just sticking with CCE.

[peter_pan]

bla bla bla ...
oh come on
can someone reach a conclusion
based on

loss of detail, color, artifacts

WHICH ONE IS the GOOD MPEG2 compressor??
and what settings to use

otherwise it never ends...

[BJ_M]

dipstick

well not exactly -- DVD's should be at 0 pedestal level (0 IRE) , as the dvd players add (supposed to anyway) setup levels (very few acually do hit the mark) .. If you have a 16-235 source than the last thing you want to do is instruct the encoder to encode to CCIR601 (add filter) This will compress the luminence ranges further than they need to be, and you have just lost dynamic range to your colors. By adding nothing - it will simply leave the values the way they are... I have shown this to be the case with all values from -10 to 265.

Procoder also has a reverse 601 setup (think of it as undo)

Now these setups would be for standard dvd's - but for your own personal use on some dvd players (or tv's) , you might think this may need to be adjusted. Most devices are going for a "red push" as it has been found that people perceive the image to look better this way. I have been doing color correction to film and film to dvd also this way per some requests.

HD is not the same btw --

[dipstick]

Update:

If you use Frameserver by Debugmode (latest version), it will let you select RGB24 - RGB32 and YUY2. If you use YUY2, it should encode correctly. In fact, if you have a DV-AVI in the timeline and frameserve out with RGB24 to Procoder, it will mess up colors.

I just experimented with the Huffyuv source in Premiere. I frameserved out using YUY2 to Procoder and the results were great. The colors looked normal.

Get the latest version of the Frameserver by Debugmode, and make sure you select YUY2.

[adam]

You people are blowing this "bug" way out of proportion. For some sources you need to compress the luminance scale to CCIR601, for others its already compliant and needs to be left alone. There is no way any mpeg encoder make this decision for you; you've got to set the encoder according to your source. NO default setting in ANY encoder handles this any better than Procoder. This is a completely moot discussion as far as I'm concerned. You've always got to account for colorspace conversions when you encode whether you are a newbie or you do this for a living.

[proxyx99]

Really? I have yet to see that behavior in MC or TMPEG for example. Can you post source and after file to prove it?

...and how do you determine before encoding which approach is OK with procoder: with filter or without, expand or shrink? You got some suggestions here...? Measuring tape?

[BJ_M]

ok - here is a complete run through on every permutation using procoder and the 3 different filters (skipping HD for now) ...

I spent several hours on this and confirmed all findings ..

I can send the source file and uncompressed screen shots if you doubt any thing ...


My findings were exactly what I said ..


I can let you go through this and then I will offer up a conclusion ..

since the files and stuff are to big for here - i set it up on one of my websites

http://www.zzx2.com/canopus/


The measuring tape - so to speak - is a industry standard check on a scope - though you can use photoshop even in a pinch ..

[adam]

proxyx99 there are literally hundreds of such threads on this forum regarding this exact problem with just about any encoder you can think of. Check out all the TMPGenc threads that mention the "output yuv data as basic YCbCr not CCIRC601" setting. Same exact thing.

This is an extremely common issue that always comes up when encoding mpeg.

Once again, there is NO problem with Procoder in this regard.

[Skynet107]

BJ_M what is your facination with Procoder? I could be wrong, but you champion Procoder over and over again as the reference standard for software encoders. Yet so many others are unable to produce the mind blowing results you seem to be getting. I have nothing againsts Procoder, but overall it it just not up to the task IMO.

I have produced over 100 DVD's so far (promotional and training video's) and for my money CCE has been for me the best solution. It is fast, HIGHLY configurable, and produces consistent results with just about any type of input. CCE is especially good for very low bitrates, below 3000 kbits/sec for example. A few DVD's I did ended up being below 2600 but CCE did a stellar job even at this bitrate. I did some tests using Procoder at this bitrate and the results were unwatchable.

I am not a video expert. But I know exactly what looks good in motion and what does not. I guess the vast majority of us just can't grasp how to use Procoder "properly." As for the still shots, they are a very poor way to evaluate an encoder. Only watching the final encode for at least a few minutes will give you an overall sense of the how well the material looks. Encoded material is highly perceptual.

[proxyx99]

Interesting, good job indeed!
Can you proceed to your conclusions, test explanation?

Few years ago I came across this site:
http://www.tecoltd.com/enctest/enctest.htm

That was when I still owned DVStorm and Amber (not anymore). Unfortunately, test results are not available (...?) but I recall Amber test clearly. Even though they were praising Canopus I did my own test then to confirm what I did not like at all. Swimming pools scene has some plants inside that almost entirely lost their definition after Amber "treatment" as compared to CCE or TMPEG.

In the first scene building colors were very bright (too much) (yellow tone). Since I've had some issues with Amber output being too Canopussy I eventually sold it. I dug this site up today (luckily still alive) although encoded files are unavailable.

Their original AVI is still there and I will try to duplicate the results using Procoder and some other apps for comparison.
Needles to say I completely disagreed with their conclusion based on my assessment of encoded file and my tests. Clipping and colorspace issues were too much for my eye (overblown bright tones, loss of middle definition and overall too contrasty). Some ppl may still like it especially if they don't see the source.

I never used CCE (just few tries) but always regarded this encoder as very close to ideal. MC has its issues with sharpening (in my view) but overall not far from it. So is TMPEG. Never had a good grip on Procoder due to inconsistent results from a variety of sources. DV output was OK though and all my DV files ended up being done with it.

As indicated I'm not a particular fan of "hard" looking video and because of that Canopus was not high on my list (prefer Edition). It came clearly across these tests that similar issues I've had have surfaced in encoder tests and shedding some light onto them would benefit everyone.

Don't understand why some are so appalled with an attempt to have deeper look into this problem. What, you belong to Procoder church? It's just a tool like any other...

I concur with Skynet's post that images are not everything but they give you an idea what to expect. Btw. BJ_M images posted do not allow for any comparison... not good, not good at all. I admire the amount of work that he has put in the page (I know the pain, believe me).
What Skynet said about consistency is 100 % what I see from other users experience, it's not there. There's a missing link...

[BJ_M]

BJ_M what is your facination with Procoder? I could be wrong, but you champion Procoder over and over again as the reference standard for software encoders. Yet so many others are unable to produce the mind blowing results you seem to be getting. I have nothing againsts Procoder, but overall it it just not up to the task IMO.

I have produced over 100 DVD's so far (promotional and training video's) and for my money CCE has been for me the best solution. It is fast, HIGHLY configurable, and produces consistent results with just about any type of input. CCE is especially good for very low bitrates, below 3000 kbits/sec for example. A few DVD's I did ended up being below 2600 but CCE did a stellar job even at this bitrate. I did some tests using Procoder at this bitrate and the results were unwatchable.

I am not a video expert. But I know exactly what looks good in motion and what does not. I guess the vast majority of us just can't grasp how to use Procoder "properly." As for the still shots, they are a very poor way to evaluate an encoder. Only watching the final encode for at least a few minutes will give you an overall sense of the how well the material looks. Encoded material is highly perceptual.

please do a search on this forum (and others), that is not an accurate
statement what-so-ever, I have no "fascination" with Procoder above all others - I also promote the use of Cinema Craft, tmpgenc, MC and even the the sonic hardware encoders in addtion to Procoder (plus even a few other software encoders at times I have brought up) ... What I am simply saying is there us no problem with procoder as some would want you to believe. When in fact, it is their in-ability to understand the mechanics of encoding and proper source file configuration, and/or encoder settings.. then blame it on the encoders ..

[proxyx99]

What I am simply saying is there us no problem with procoder as some would want you to believe...

Are you suggesting that someone has fraudulently misrepresented the results of tests, swapped pics... If so, gotta find out who?

What I am simply saying is there us no problem with procoder as some would want you to believe. When in fact, it is their in-ability to understand the mechanics of encoding and proper source file configuration, and/or encoder settings.. then blame it on the encoders ..

With MC encoder you don't have to:
- understand mechanics
- proper source file configuration
- encoder settings

I spent several hours on this and confirmed all findings ..

My findings were exactly what I said ..

Yep, this is what I call a scientific proof

Now, you can do this or this

[troyvcd1]

Ok so when I capture miniDV from my camcorder to my pc how do I check what levels are my video files. What should they be. Is there a variation among camcorders where the levels are different.

When I capture using premiere my avi files have a fourcc of dvsd. If I change the fourcc to cdvc will this change my levels.

[SatStorm]

Procoder is like CCE
MC is like TMPGenc

Nothing really changed over the years... It is the same thing all over again...
Only the names changed to protect the innocent...

proxyx99, would you like a card? A nice yellow one? Oh, please, say yes.... I'll be glad to make you happy!

[troyvcd1]

Ok so I ask a simple question and get no reply. Well BJm is just professing how good he does things he does not really help anyone out. We all know your a video engineer but can not take one minute to answer a simple question. If your just want to lurk and say what a good video engineer you are then you shouldnt be a moderator.

[proxyx99]

Satstorm, so you're just browsing slowly and thinking how to constructively contribute and then suddenly you came up with that...
Brilliant, what else can I say, but my answer is NO.

[BJ_M]

Ok so I ask a simple question and get no reply. Well BJm is just professing how good he does things he does not really help anyone out. We all know your a video engineer but can not take one minute to answer a simple question. If your just want to lurk and say what a good video engineer you are then you shouldnt be a moderator.

sorry - didnt see your question ... i apologize
(i hardly lurk here though - you can also get hold of me on the sony vegas forum at DMN where i am one of the hosts)

see below