MAJOR BUG in Procoder 2,3,rhozet. Dont Use.

[jamieg-au]

I have been hitting my head against the wall for the last 6 months with regard to talking to rhozet support. Trying to get them at address a MAJOR issue with there MPEG2 encoding.

I have spent some time talking and finally creating an example set of images to show them. Largely it has been ignored.

Its time to let the information be free, and at the same time make Procoder sales dive. As, I would never have purchased it if knew this was happening. I use it in a Post Production facility. We have grade one Monitors on most edit suites.

Basically, Procoder does a IRE safe levels adjustment on ALL video it encodes. Ie brings up the blacks, and down the whites.
This is fine for traditional usage of MPEG2 and TUBE based viewing. (YOU CANNOT DISABLE THIS.)
That is if you can FIND a tube these days. And as we usually are using superior quality Projection for my files. It really destroys the gamma.

In any case, follow this link. Look at the 24 bit BMP files.
The comparisons makes it stand out like dogs balls. (Crass Australian saying.. ;)

http://www2.digitall.net.au/CanopusTests/

Comments welcome.
Thanks,
James

[kumi]

Is it possible to post Canopus' responses? Or at least paraphrase them?

Also, just to clarify: does this problem occur in ProCoder 2 as well?

[enantiomer]

Yes, I too discovered the loss of blacker-than-black with ProCoder (2.04), and it appears there is no way to disable it. I have since abandoned ProCoder and now use a freeware program called HC Encoder. Amazingly, this free tool competes very favorably with ProCoder and doesn't adjust black or white levels at all (not does it punch up the colors as ProCoder does by default). It can encode SD or HD. I know it's not "professional" software but it acts like it. :)

[scharfis_brain]

You need to feed ProCoder with YUY2 and no Procoder-internal-filters applied. Then it won't touch the colors!

I experienced this with procoder too, but when I appied an converttoyuy2() at the end of my AVISynth script, everything seemed fine.

[Fishman0919]

Are you talking about Luminance levels settings (16-235 , 0-255)

You may be, and most likely are, feeding Procoder 0-255 Luminance levels. And on my PC monitor you will be able to see the diff between the two. Procoder is going to encoder at 16-235. Thru a Standalone DVD Player, which will only display 16-235, you will not see a diff.

Here a screenshot for CCE SP2...

EDIT: Maybe thats the price diff between a $500-$600 encoder and a $2000 one :)

[jamieg-au]

Are you talking about Luminance levels settings (16-235 , 0-255)

You may be, and most likely are, feeding Procoder 0-255 Luminance levels. And on my PC monitor you will be able to see the diff between the two. Procoder is going to encoder at 16-235. Thru a Standalone DVD Player, which will only display 16-235, you will not see a diff.



Yes I know this, however, my point being here is that many people have display devices that CAN utilise the full 0-255. As such, not being able to TURN this off is a major BUG.

James

[jamieg-au]

You need to feed ProCoder with YUY2 and no Procoder-internal-filters applied. Then it won't touch the colors!

I experienced this with procoder too, but when I appied an converttoyuy2() at the end of my AVISynth script, everything seemed fine.

Your the man,
Will give this a go this week some time.
James

[jamieg-au]

Is it possible to post Canopus' responses? Or at least paraphrase them?

Also, just to clarify: does this problem occur in ProCoder 2 as well?

This happens in Procoder 2 and 3 and rhozet Carbon coder.
Have tried them all.

James

[Fishman0919]

Originally Posted by scharfis_brain View Post
You need to feed ProCoder with YUY2 and no Procoder-internal-filters applied. Then it won't touch the colors!

I experienced this with procoder too, but when I appied an converttoyuy2() at the end of my AVISynth script, everything seemed fine.
Your the man,
Will give this a go this week some time.
James


This is not going to solve your problem, Procoder like to see YUY2 and will convert all video to YUY2 before encoding. In some of the earlier ver of Procoder 1/1.# did not do a really great job at this.
The fact is that Canopus ProCoder/Grass Valley ProCoder 3 has decided not to add this switch for whatever reason. You can't get an output from Procoder that is not Luminance levels 16-235.

Seeing that standalone players do not pass thru 0-255 Luminance levels may be a major reason why.

EDIT: From page 43 of the Rhozet Carbon Coder guide...

Included Video filters
601 Correction - Expand Color Space – This video filter expands the RGB range of the video from 16-235 to 0-255. Use this filter to create output for a system that uses the full 0-255 range from input that uses 16-235.
601 Correction - Shrink Color Space – This video filter shrinks the RGB range of the video from 0-255 to 16-235. Use this filter when create output for a system that uses the 16-235 range from input that uses the full 0-255 range.
709 Correction - SD/HD Color Space – This video filter is used to convert video in the SD (601) colorspace to the HD (709) colorspace. Broadcast HD video uses YCbCr colors following Rec. ITU-R BT 709-5 where as broadcast SD video follows ITU-R BT 601.
Bitmap Keying – Superimpose a bitmap logo or graphic on the video. This is often used to watermark video so it can be personalized.
Black/White Correction – This filter lets you adjust and control the levels of black and white pixels in your video. By adjusting the sliders, you can specify at which point a pixel will become black and/or white. The higher the setting, the more nearly black pixels will be converted to true black and vice versa. This works best if you are encoding video for the Web and need to adjust the black and/or white levels of broadcast video so that they are truly black or white. It’s also useful for making white titles on a black background more legible when viewing on a computer monitor.

[mp3dom]

Procoder acts in a strange manner. It's true that this encoder works in YUY2 but If i feed an AVI HuffYUV (in YUY2 colorspace), the resulting file will have a color change. If I "encapsulate" the same AVI HuffYUV in an Avisynth file (with Avisource(), and without Converttoyuy2, since it's already in yuy2) then the resulting file will have the correct color (no change)

[45tripp]

I wouldn't say it's Procoder really.

There are hints of this problem scattered all over.
One would think that a well documented solution would arise.

I don't have the knowledge to provide one, but i do have a few thoughts.


http://www2.digitall.net.au/CanopusTests/

1.2 gig samples?
Have a heart...

Yes, I too discovered the loss of blacker-than-black with ProCoder (2.04),
Procoder is going to encoder at 16-235.
You can't get an output from Procoder that is not Luminance levels 16-235.

Untrue.
the 'problem' with procoder is you may end up with an expanded luma range when you don't want one.
Most encoders default to (or offer no other option) 16-235 range encodes.


In any case, follow this link. Look at the 24 bit BMP files.

Procoder std result has a full luma range 0-255,
Mainconcept has a 16-235 luma range.
Why does the full range rgb original look different to the full range yv12 but the same as the clamped yv12?
I don't know, but it has to do with what is displaying them.

You see how with 601 shrink you get similar to mainconcept.
601 Correction - Shrink Color Space – This video filter shrinks the RGB range of the video from 0-255 to 16-235. Use this filter when create output for a system that uses the 16-235 range from input that uses the full 0-255 range.
Feeding procoder with an avisynth script like scharfis_brain said, is a better way.

I experienced this with procoder too, but when I appied an converttoyuy2() at the end of my AVISynth script, everything seemed fine.
converttoyuy() Uses Rec.601 coefficients, scaled to TV range [16,235] (rgb->[16-235] yuy2)
You need converttoyuy2(matrix="pc.601") for the full range.

Here a screenshot for CCE SP2...

encoding with cce using [0-255] should garner the same result as procoder std.

So full range stays full range in procoder unless you scale.
What I've noticed, and perhaps what scharfis noticed, is you may feed tv luma range clips to procoder and end up having luma expanded to full range.
Procoder like to see YUY2 and will convert all video to YUY2 before encoding.

Procoder doesn't convert. The codec or a colour space converter does.
I'm not sure of things here.
I recently tried feeding with avisynth and switching yv12 decoders. With both xvid and helix, luma range was expanded. Do they both expand to full luma range when going to from yv12 to yuy2? Or is procoder requesting full range?
I know at one time I didn't need to use converttoyuy2(). I think it was a colour space converter making the difference. I don't have a stable system to do the testing now. A bit lost.

I recently read something about ATI cards. I've got one,
also going to look into that posibility at some point.

Procoder acts in a strange manner. It's true that this encoder works in YUY2 but If i feed an AVI HuffYUV (in YUY2 colorspace), the resulting file will have a color change. If I "encapsulate" the same AVI HuffYUV in an Avisynth file (with Avisource(), and without Converttoyuy2, since it's already in yuy2) then the resulting file will have the correct color (no change)
You could have 3 different displays.
I'd guess, huff full range to procoder to full range yv12.
huff to avisynth, luma scale, procoder, yv12 16-235.
With display of original huff using 601 coefficients and mpeg2 using 709.


anyway,
if anybody has any further knowledge,
it's all welcome.

gl

[Fishman0919]

After talk to Grass Valley and reading thru the Procoder2/3 guide
Procoder does have the 16-235/0-255 switch... By default it is set to 16-235. Tested, worked fine.


Quote:
Procoder doesn't convert. The codec or a colour space converter does.

Not True, according to the teched I talk to... You can convert the video to anything and feed it to Procoder 2/3 or Rhozet Carbon Coder but internally it will be converted to YUY2 before encoding.

You can easily test this... Feed Procoder a YUY2 and note the speed. Do the same with YV12 or RGB24 and you will see the speed drop.

[45tripp]

Procoder does have the 16-235/0-255 switch...

So, where is it?

[45tripp]

You can easily test this... Feed Procoder a YUY2 and note the speed. Do the same with YV12 or RGB24 and you will see the speed drop.

That's no indication. Only of preferred input maybe.
you can see what's decoding in the source screen, "video codec"
Things go through directshow.

I set up FFdshow.
I set it as raw yv12 decoder.
Fed an avisynth script of an avi.
Got back 16-235 istead of expanded luma. (good)

Set up FFdshow
entered picture properties, set up luminance gain on right half.
fed same script to procoder.
split screen result:
(http://img373.imageshack.us/my.php?image=splitlp0.png)

Set up ffdshow,
left picture properties with right side lumigain,
set output to YV12 only.
fed same script to procoder.
got no split screen effect, had luma expanded.
noticed this in procoder:
[img=http://img299.imageshack.us/img299/4268/procoderce9.th.png] (http://img299.imageshack.us/my.php?image=procoderce9.png)

Without ffdshow, it's "avi decompressor (yv12)" like the graph in graphedit.
I don't know what "0001 (yv12)" is, [I]perhaps a procoder internal, but more likely directshow colour space converter.
Anyway it's a fallback not first in line.

gl

[Fishman0919]

So, where is it?


After you add your source, on the source screen click on the "Advanced..." button, then the Video Filter tab, then add button... pick you filter.

That's no indication. Only of preferred input maybe.
you can see what's decoding in the source screen, "video codec"
Things go through directshow.

preferred, yes because it's not being converted

just like CCE, internally it's being converted. You can feed an .AVI YV12 into both but both will convert it internally to YUY2 for encoding.

[45tripp]

After you add your source, on the source screen click on the "Advanced..." button, then the Video Filter tab, then add button... pick you filter.

There's been mention of shrink already.
It's not the same thing. not a switch, you need to know what range you have.
If you shrink 16-235, you won't get 16-235 back. It'll be shrinked.

Procoder doesn't default to anything.
I'm fairly confident it'll output the luma range served up to it.

CCE's switch isn't that impressive either...
It's for RGB only and to keep full range or clamp.
Although I'm not sure if you gave it 16-235 RGB and selected 0-255 what would happen, I'd guess it would stay 16-235.
If you feed full luma range yuv it'll output full range.

Funilly Mainconcepty probably has the most inteligent luma range function, although you'd never guess from documentation.


preferred, yes because it's not being converted
just like CCE, internally it's being converted. You can feed an .AVI YV12 into both but both will convert it internally to YUY2 for encoding.

Decoders do the work.
Some apps may come with a decoder set up here or there but it's mostly external.
Procoder is directshow based.

I'm fairly confident procoder "trouble" comes from feeding it yv12
and having default directshow behaviour, which seems to expand the luma. Fixed by setting up better directshow yv12 decoding, or by using converttoyuy2() in avisynth.

What the OP got is what he wanted. Full RGB to full YUV.
If he wanted what other encoders do (usually automatically clamp to 16-235 yuv) he could have used the shrink filter or probably better avisynth.

Display is different because as I unnderstand you can't get full luma yuv display from players, they assume 16-235.

gl