Curious about MPEG encoding original DV material...

[jopereira]

Originally posted by 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.


Yes, the Satish's FrameServer Plugin is a big plus in Vegas. If you haven't tested it yet, I confirm a good workflow with CCE, Procoder and TMPGEnc.

[ulfschack]

Good to know.

Let me ask you if you see a differense in the hue/color/contrast of Procoder in comparison to CCE and TmpgEnc. Make sure you use 0-255 in CCE. In TmpgEnc the equivalent is the checking of the box "Output YUV data as Basic YCbCr not CCIR601". Please make this adjustment for either CCE or TmpgEnc and compare to an encode from Procoder.

Do you see what I'm talking about? For me it's very significant. I'm also sure that it isn't a screwed up DS filter or a computer "bug" causing this since the difference is equally apparent when playing on a stand-alone.

Cheers


Also, if you feel like it try using the "mb1 interlaced DV" quantization matrix found here (http://forum.doom9.org/showthread.php?s=&threadid=27528&highlight=matrix). Just edit the ini-file appropriatly. For getting this matrix into CCE you could use the "tsunami CCE patcher" (don't have link here, but I'm sure you'll search and find as efficiantly).

[jopereira]

In my small tests I haven't noticed any difference in colors, but then I was not looking at it. I must say that when I tested CCE with standard settings (16-235) I was not looking for color differences but they were VERY visible.
Yesterday I only tested MC and Procoder (since I'm using MC after MC-CCE-TMPGenc comparisions) and didn't noticed a big difference.

I always compare encoders in my PIONEER 535 and my Philips TV. I don't make comparisions in my PC (with a 17" LCD @ less than 1m even DV is bad quality :)). Also, I compare encoders with the settings and equipement I will use to see my final DVD's. That's why I compare encoders at more than 6000Kbps as I don't want to put more than 90 minutes in a single DVD. At this bitrate the differences are very few between encoders, but since MC looks very good, is integrated in my NLE aplication (Vegas) and it's fast, it'll be very difficult to use another application, although I do like to make comparisions as they may became handy in a particular situation.

Right now, I'll be inclined to use MC or Procoder.

[Arky]

Originally posted by ulfschack
I dont think that TmpgEnc makes Coca Cola colors without you requesting it. I have to much respect for that guy and simply refuse to believe it :)


Fair enough, it's simply a subjective thing to me, never meant in any way as a disrespectful remark to Hori San. As I said, I actually rather like the 'full-bodied' colour I have witnessed in my TMPGEnc encodes :)

jopereira, with an ABR of 6000kbps, I think you will generally be very happy with any of the 4 encoders discussed in this thread. I think most of us would agree that broadly-speaking it's only really at the lower bitrates that the differences become very obvious.


Arky ;o

[ulfschack]

. As I said, I actually rather like the 'full-bodied' colour I have witnessed in my TMPGEnc encodes :)

Yes, but with the color range set to 0-255 in CCE it looks the same as in TmpgEnc. However I'll be damned before I manage to get rid of the outwashed look in Procoder. I can't find anything saying stuff about color range in there.

Btw. Would you know the difference of adding filters (in procoder) under the "source" tab as opposed to doing it under the "target" tab? The filter selection is the same and I can't really think of a way that they could be implemented differently depending if you apply them to source or target.

cheers

[jopereira]

Originally posted by Arky
jopereira, with an ABR of 6000kbps, I think you will generally be very happy with any of the 4 encoders discussed in this thread. I think most of us would agree that broadly-speaking it's only really at the lower bitrates that the differences become very obvious.

Arky ;o

I should remember that CCE @ 9000 KBps was worst than MC @ 6000Kbps and with yesterday tests I can say CCE is worst than MC and Procoder at 4000Kbps! That really suprised me as I used CCE for a long time as been "the best"...
I don't really think CCE is that bad, but in that condition it is. I didn't expected CCE to have such a difference in any situation.
Another situation where CCE is really bad, and is a test that everyone can reproduced (with any source video), is fading from/to black - no other encoder gives a so bad result.
ps- I haven't tested this recently, only when I had CCE 2.5 installed (could be that recent version have cured that). I use 2.67 now.

@ulfschack
A color comparision between Procoder and MC didn't find any differences. I remember MC-TMPGEnc-CCE (with 0-255) gave the "same" color results.

[ulfschack]

Ok, jopereira, thanks for you're efforts. I'm kinda dissaponted that you didn't find that same problems as I did, because now I have before me something that I can't explain :) There's no logic to it anymore. The only thing that could make our findings differ is another version of Procoder, but we both use 1.01.08.0, so ...

Hmm... I'm using Sony DV Codec. Maybe there are missunderstandings of YUY2, YUV, YUY12, RGB24, RGB32, CMYK (and all that crap of which I know absolutely nothing) between the DV renderer and the procoder that aren't issues for the other encoders(?)

[jopereira]

That could be something to do with DV decoder been used by Procoder...
Since we have several instaled (I really hate automatic instalations because we really don't know what's up) could be that Procoder is using another DV decoder (different from CCE and TMPGEnc for instance.

I don't recall messing up with any Procoder parameters, but try to see if you could find something. Since I'm not at the my home computer, I cannot see encoders options right now but if I find something I'll tell you.

[Arky]

Originally posted by jopereira
I should remember that CCE @ 9000 KBps was worst than MC @ 6000Kbps and with yesterday tests I can say CCE is worst than MC and Procoder at 4000Kbps!

This is a real surprise to me, considering the findings I made at 4650kbps. It really is so difficult to get consistent findings between us all (but that's not to say we shouldn't try to do so!)


Originally posted by jopereira
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 that noise (meaning high frequencies are 'converted' to lower frequencies - edges not very well defined).

I find this interpretation of CCE very interesting and insightful. If it's really what CCE does then it's an ingeniuous (although not perfect) tactic.


Arky ;o)

[jopereira]

Originally posted by Arky
I find this interpretation of CCE very interesting and insightful. If it's really what CCE does then it's an ingeniuous (although not perfect) tactic.


Arky ;o)

That's MY interpretation, which may not be true. :)

Knowing something about the way MPEG is encoding I must say this is not a tactic. The "noise" is not imposed but is a result of a very good algorithm that "disperse" the few bits available to recreate a image as close as possible to original one. They should not restrict the algorithm to a macro-block but they must work with several together not to have the macro-block.
I haven't tested MC or Procoder at SVCD resolutions and bitrate, but CCE does a very good job at those settings.

Just like MP3 encoding, CCE produces an image that rejects small details in benefit of larger (most visible) details.
One thing is for sure: I cannot see those effects at 25fps... only in pause mode (which is not a real disadvantage). The macro-block effect is visible at 25fps as one frame has one macroblock and the next frame could have "another macroblock" giving a very visible affect. Worst, the image seems to be a letter from a serial killer with small pieces of images that jointed together to create a larger one. :D

BTW, does anyone reproduced the fade-in or fade-out effect in CCE (the picture seems to jump from one 'black level' to another, not giving a smooth effect - like other encoders do)?

[Arky]

Well I'm finally going back home tomorrow, so I'll have a trial run of the 'fade-to-black' scenario, with CCE, and I'll let you know. I'll also run TMPGEnc through my piece of disco footage, and I'll let you know how that pull-down.exe worked for my CCE PAL field order when played back on my standalone.


Arky ;o)

[sync]

I'm using Procoder because it's supposed to be good at handling interlaced material. When I add the source file it automatically recognizes it as interlaced, or perhaps that's just the default. I'm encoding for SVCD and it does a terrible job of handling motion. But if I deinterlace the file first it encodes much better.

I keep reading in this thread that you shouldn't deinterlace. There aren't very many settings in this encoder so I don't see what else I can tweak.

Everyone here is encoding at DVD bitrates. Is is possible that for SVCD bitrates you do need to deinterlace?

[Arky]

Sorry Sync, although I appreciate that we are comparing output quality of various encoders here, I think your particular question would be better answered if you post it in the VCD/SVCD encoding & authoring (http://forum.doom9.org/forumdisplay.php?s=&forumid=35) forum. This discussion is specifically concerned with the encoding of miniDV material.


Arky ;o)

[sync]

Arky,

My post is about encoding MiniDV material.

[Arky]

Oops, apologies, what I meant to say was that the thread is about encoding miniDV material to DVD. This is, after all, in the "DVD encoding" forum.


Arky ;o)

[s_kound]

Hi to all.....
First of all please axcuse my poor english as i am from Greece.

I own a dv camcorder (sony pc101e) and quality is a BIG (the biggest) issue for me...

My steps are so far...
1) capturing in dv avi (type 2-premiere comp.) with scenalyzer.
2) editing with vegas and rendering as dv avi
3) encoding with canopus procoder

I used ulead, cce, mainconcept's (vegas), tmpeg and other encoders.

The ulead encoder was the worst encoder i ever used but i was still a newbie and didn't know that there was others out there.

I now have to say that in my eyes the encoder that produces the smoothest video and without blocks etc is the procoder.

This is my opinion....

[Arky]

You can frameserve directly from Vegas to ProCoder now. Read this: (http://forum.doom9.org/showthread.php?s=&threadid=51815)

Arky ;o)

[s_kound]

thanx.... i didn't know that there was such a plugin for vegas

:) thanx again :)

[taudule]

However I'll be damned before I manage to get rid of the outwashed look in Procoder. I can't find anything saying stuff about color range in there. andHmm... I'm using Sony DV Codec. Maybe there are missunderstandings of YUY2, YUV, YUY12, RGB24, RGB32, CMYK (and all that crap of which I know absolutely nothing) between the DV renderer and the procoder that aren't issues for the other encoders(?)


Sorry if my answer is a bit late, but i didn't see this thread before as it is not in the DV forum :rolleyes:.

ulfschack,
Hopefully you wont be damned :)
Try the canopus codec (CDVC) to encode DV with procoder.

If not done already, read this frame :
http://forum.doom9.org/showthread.php?s=&threadid=33526
It tells that the canopus codec has a luminance bug, but when using this codec with procoder, the result is perfect.
I made some tests about luminance pb, and found this :

CDVC -> premiere -> tmpgenc = too light.

dvsd (mainconcept) -> premiere -> procoder = too dark.

CDVC -> premiere -> procoder = Perfect.

BTW, some time ago, i used to make a lot of DV-> mpeg2 encoding comparison, and ended by deinterlacing my DV and encoding it with tmpGenc, until i tried Procoder... well... I don't deinterlace anymore.;)

OD.

[jopereira]

Originally posted by taudule
BTW, some time ago, i used to make a lot of DV-> mpeg2 encoding comparison, and ended by deinterlacing my DV and encoding it with tmpGenc, until i tried Procoder... well... I don't deinterlace anymore.;)

OD.

Have you tried MainConcept too?
Using it with Vegas seems to have a real nice result...

[taudule]

@jopereira
No. When i made my tests, it didn't exist (neither did procoder).
But i already spent too much time testing... I add it to my "to do" list.

OD...

[zeus163]

I'm sure glad that this post was linked over in the DV forum. I've been going batty trying to find out the best method for my DV to DVD encodes.

I kept reading that ProCoder produced fantastic results and I was never seeing that. I had to use the de-interlace filter to get results I felt were great, but I was also using my digital8 camera as a pass through and recording things off the televsion. I have now found my best results for straight DV and pass through DV footage.

For pass through DV footage I've found that CCE with FieldDeinterlace() gives outstanding results better than anything I was getting with ProCoder (and I had to apply the deinterlace filter or the files played with weird motions on the computers--even if I applied pulldown/restream on them).
Yesterday I tested a straight DV file with ProCoder (MQ) and no filter and was shocked. It has some weird movements on the computer (which I've read would happen), but when I watched it on TV I was amazed at the results. My wife will now be much happier with her mother's day DVD.

Thanks to the people who started this post and kept it up. I truly have now found my methods. I just wish that ProCoder wouldn't take so long.
Is everyone using Mastering Quality with ProCoder?
Can ProCoder resize? I know it can crop, but I was wondering about resizing.

Cheers!

[sync]

zeus163,

You're doing the same thing I am, using DV to capture TV. Based on the few samples I've tried, I found that the material is not truly interlaced but is telecined. Although deinterlacing works, inverse telecine works better.

[zeus163]

sync,

are you doing Telecide() then? When I mentioned that I was doing that, most replied that this type of material wasn't telecined. In fact, there was a Telecide() in my test footage and my friend, wife, and I felt the FieldDeinterlace() produced the best results.

Isn't encoding a blast?

[sync]

There's only one way to know if material is telecined, study the frames. Check out this link: http://www.lukesvideo.com/telecining1.html#identifying

I've only done inverse telecine in VirtualDub so far. But my next step is to look at Telecide.

The bottom line is getting the results that you're satisfied with. So if you prefer deinterlacing, I guess that's what really counts.

[ulfschack]

@taudule

Thanks for the tip. That sent me out searching (again) on dv codecs and their workings.

I dont think that this is the problem concerning the "paler" encodes in Procoder, though. When I "add" a source it clealy states that it's using "DV video Decoder" as Video CODEC. Unless this wraps the Canopus decoder (which is also installed on my system) it can't be the problem because it's not used.

I've also tried forcing the default CODEC to change between SoftDV (adaptec), Sony DV Codec and Canopus (disgusting name really ... can-o-pus) by installing/uninstalling and changing FourCC. And while VirtualDub shows that different decoders are used the Procoder stubbornly maintains that old DV Video Decoder.

But wait a sec! ... I just now see that Canopus has a Luminance bug as well as the chroma bug that I thought you refered to. But ... on second thought that wouldn't explain why the other encodes (TmpgEnc and CCE) were just fine. Yes I'm rambling ... and kinda fed up with Procoder too.

cheers

[taudule]

If you see "DV video Decoder" in the Video codec field, you are using the MS DV codec (wrong).

You must edit your AVI, and change the two fourCC strings at the beginning of the file from "dvsd" to "CDVC" (hex edit or fourCC changer).
When loading in procoder, you should then see "Canopus DV" in video codec field.
Then Try to encode.

BTW, in my previous post i meant to say that the lum/chrom. bug does not apear when you use canopus DV codec AND procoder.

OD.

[ulfschack]

Online eh ? :)

Yes, like I said, this is what I've done - Changed the FourCC, but ProCoder doesn't seem to care. VD reflects the changes though. I might have to do a serious reinstall sometimes soon ... way overdue anyways :)

cheers

[jopereira]

Just trying to learn something: exactly, what are those "bugs"?

[ulfschack]

Just follow the link in Taudule's post (some ways back on this page)

[sync]

Originally posted by zeus163
sync,

are you doing Telecide() then? When I mentioned that I was doing that, most replied that this type of material wasn't telecined. In fact, there was a Telecide() in my test footage and my friend, wife, and I felt the FieldDeinterlace() produced the best results.

If you use Telecide alone you won't get inverse telecine. You also need Decimate for that.

[jfcarbel]

Been following this thread and just want to clarify the statements made on Luminance.

Here is what I had in my notes from research on the forums:

If your are encoding material originates on a digital format, such as DV or D8, then you want to use the 0-255 scale.

If your original source material is from a DVD, set the luminance value to 0-255 (that is set DVD2AVI to TV Scale)

If the signal originated on analog systems (i.e. a capture from analog/VHS using a DV codec), then you should use the 16-235 scale to accurately reproduce the brightness/contrast range.

My question: so for an analog VHS capture in DV, I should use 16-235 - correct?

[tonyzhankaiyu]

Just test TMPGEnc and CCESP to encode a MiniDV

1. TMPGEnc (Check: Output YUV data as basic YCbCr....)
2. TMPGenc (Do not Check: Output YUV data as basic YCbcr...)
3. CCESP (Check: 0-255)
4. CCESP (Check: 16-235)

Result:

1. Brighter than original DV
2. OK
3/4. OK. No difference between them.

Somebody can tell the reason? Thanks.

[zeus163]

I just discovered (and I don't know if this is the same for others) that if I export to ProCoder from within Premiere that the encode quality is worse then if I frameserve to Premiere using the plug-in by Satish or exporting the movie to .avi and then opening the finished .avi file in ProCoder.

Of course, it was agoninzing to discover this after a 15 hour encode. I couldn't believe it. Oh well. Does this happen to anyone else?

@sync
I looked at that telecine site and then examined my footage and it appears that it does not fit the parameters discussed on that site. I even tried some of the .avisynth script files mentioned on this site and I thought the quality of the encodes was not as good as with simple fielddeinterlace().

wow.

[xly]

As it is difficult to base these comparisons only on "subjective impressions" I have extensively used the Compare() avisynth to compare DV source end Mpeg2 destination.

This function gives an objective way of what I name "fidelity" instead of a subjective "quality".The fidelity measures the average differences between all source and destination pixels.

I have compared TmpgEnc, CCE and Mainconcept by this way. No doubt that MC gives the better fidelity.

An additionnal result is that the more the bitrate is high, the closer are the encoders fidelity !

In addition to this I would focus to an important aspect totally ignored in this discussion and which probably IS the explanation of the largely contradictory conclusions of this forum "supporters".

What about the Mpeg2 decoders used ? If you have a good encoder and a poor decoder how will be the result ? And what about the "matching" between encoding and decoding options ?

If you are looking to the Dvd Players for example, the "quality" and the "fidelity" are very different according to the model. This means that the same Hollywood film will look nice on a Dvd Player A and awful with the DVD Player B. These differences are still greater with interlaced materials. Nothing to do with the encoder. The same !!

So pleae gentlemen , when you compare encoding qualities, please specify which decoder you are using.

I have still other comments on the same subjects, but I have to leave. See you tomorrow.

xly

It's more fun to compete

[xly]

To achieve a fruitful and objective comparison of the quality of DV2Mpeg2 Encoders, one should equalize or normalize all other external conditions, for example :

- same type of scene ( I generally use a typical DV scene with children playing in a garden)
- same light conditions ( preferably sunny conditions)
- same bitrate ( 4000-4500 for example which is a good average number)
- same quantization matrix (ITU-R or any DV recommended matrix)
- same DV codec (Microsoft ? Canopus ? Sony ? Mainconcept ?)
- same noise reduction ( as low as possible)
- same number of passes (typically One)
- same Mpeg2 Dvd Player and TV set ( DV has not been designed to be displayed on PC screens)
- etc

The extensive comparisons of "fidelity" I have done show that at the end of the day, the results of main Encoders are very near. Then it is a matter of personal appreciation : price ( Tmpgenc is the winner), computing time ( Mainconcept is the winner), flexibility ( CCE ) etc

One of the main interest of the Compare() method is that it gives a different number for each slight changing of these conditions, where the eyes can't notice any difference.

The "matching" aspect between Encoder and Decoder options is still an interesting issue. Just to give an example : Mpeg2 Encoder standard stipulates that the Encoder may pass to the Decoder the quantization matrix coefficients it has used. What if the Encoder does not pass this matrix? And what if the Decoder does not used the matrix gently provided by the Encoder, but its standard one ? In both cases the results will not be optimum.

In the opposite way, one could assess (or better test) that Mpeg2 VCR - largely available now - give a good fidelity as both its Encoder and its Decoder use the same functionalities and options which obviously gives a perfect matching of the couple Encoder-Decoder.

There are a lot of possible options for the Decoder to handle correctly the coming Mpeg2. Many cheap Dvd players do not use these options.

We could imagine that in a far future, the DVD Players could propose extensive possibilities of Decoder settings as to match with the Encoder (or type of film) settings.

An additional finding of my comparisons, is that the lower the birate is the larger are the fidelity differences. It seems that some encoders have a better capability to work in low bitrate conditions (like Svcd)


xly

It's more fun to compete !!

[sync]

Is the MainConcept encoder in Premiere as good as the standalone version?

[Arky]

Originally posted by zeus163
I just discovered (and I don't know if this is the same for others) that if I export to ProCoder from within Premiere that the encode quality is worse then if I frameserve to Premiere using the plug-in by Satish or exporting the movie to .avi and then opening the finished .avi file in ProCoder.

Of course, it was agoninzing to discover this after a 15 hour encode. I couldn't believe it. Oh well. Does this happen to anyone else?



As I said previously, encoding time does matter. Had you used CCE, it would have only taken you 4hrs or less to see your end result (I am assuming 2-pass VBR).


Arky ;o)

[zeus163]

Arky

I totally agree that CCE would have been faster, but I feel that ProCoder provides the best overall quality on my DV footage. Of course, the time it takes is slower than snot, but perhaps I'll finally upgrade this summer and encoding time will go down to 14 hours!

Encoding time should be taken into consideration, but I don't mind encoding overnight and while I'm at work.

[Arky]

Hey, anyone care to comment on this related thread, please?

http://forum.doom9.org/showthread.php?s=&postid=314278#post314278

All the best, everyone.


Arky ;o)

[xly]

Reminding the original issue of this thread "Encoding original DV material" I just have to add that some Mpeg2 encoders could give better results with DV materials and worse with general materials like avi, divx,avs etc.

As far as MainConcept encoder is concerned this software company provides DV encoder/decoders and one could assume that DV material captured by MC DV encoder and re-encoded by MC Mpeg2 encoder would give better results as the "matching" between DV encoding and Mpeg2 encoding is better (see above my comments on matching issue.

xly

It's more fun to challenge !!

[FredThompson]

Originally posted by jfcarbel
Been following this thread and just want to clarify the statements made on Luminance.

Here is what I had in my notes from research on the forums:

If your are encoding material originates on a digital format, such as DV or D8, then you want to use the 0-255 scale.

If your original source material is from a DVD, set the luminance value to 0-255 (that is set DVD2AVI to TV Scale)

If the signal originated on analog systems (i.e. a capture from analog/VHS using a DV codec), then you should use the 16-235 scale to accurately reproduce the brightness/contrast range.

My question: so for an analog VHS capture in DV, I should use 16-235 - correct?
Yes. Putting something on a more capable medium doesn't change the original signal. Well, ok, it's converted from analog to digital but you know what I mean.

Having said that, the Canopus ADVC device is reported as "enhancing" video played through it. Maybe they remap. Dunno, haven't seen one.

[tonyzhankaiyu]

I have different points about the luma setting when we encode DV to MPEG-2 only:

RGB is the color spacein computer use 0-255. YUV color space used in video domain contains one most important format: YCbCr color space (spcified in Rec. ITU-R BT.601-4, or Rec.601). YCbCr is used by standard Television singal and compressed material such as DV, MPEB, and MJPEG. YCbCR color space has:

Y: 16 to 235 (which is the recommended range)
Cb: 16-240
Cr: 16-240

But, please keep in mind, many (not all) Digital Video(DV) camcorders record values out of recommended range. For example my personal DV camcorder (Panasonic DS15) record vedio with Y from 1-254.

To prove above, use TMPGEnc's histgram (and lots of other application, such as Photoshop, has this chart), you will see there are pixel with Y=1-15 and Y=236-254. Of course most pixels has Y value between 16-235.

Lots of people encode DV into MPEG-2 for DVD+(-)R(W). You may ask how to config the encoder's Luma settings. So Just for DV input, MPEG-2 output and avoiding luma clamping (Input and output has the same luma), I use:
In TMPGenc, DO NOT check "Output YUV data as basic CCIR601".
In CCE SP, DO check "16-235".

Otherwise you will get luma changed after encoding.

To prove above, I did a test:
1. create a bmp with 4 area, with each area's color (RGB) = 1,1,1; 16,16,16; 235,235,235; and 254,254,254.
2. use the bmp to create a MS DV video clip, say 10 seconds, in premiere.
3. use TMPGenc or CCE SP to encode this clip with luma settings as mine.
4. re-do step 3 but DO NOT use the luma settings as mine.
5. Output the frame from the encoded MPEG-2 file in step 3 and 4.
6. Result from step 3 is what you want.

Note: I did all the tests on my PC, not compare the two results on TV.

Tony

[RB]

Originally posted by tonyzhankaiyu
In CCE SP, DO check "16-235".

Actually, the Luminance Level setting in CCE is ignored unless you are feeding it RGB data. See the CCE FAQ (http://forum.doom9.org/showthread.php?s=&threadid=53770), Q12.

[tonyzhankaiyu]

RB,

That's because you use standalone CCE SP (so you are right), but I use Premiere's CCE SP plugin, and you use standalone CCE SP (so i am right too). Premiere convert DV first into RGB, the CCE SP plugin take the RGB. We can draw a conclusion:

When we encode DV to MPEG-2 useing CCE SP's Premiere plugin, DO check "16-235", when using CCE SP standalone version, DO check "0-255".

[RB]

tonyzhankaiyu, thanks for pointing this out. However, for this case we'd also have to know what "YUV -> RGB Scale" luminance level Premiere (like VFAPI) uses when converting to RGB. Then we'd have to use the opposite setting in the CCE Premiere plugin. See what I mean?

[RB]

tonyzhankaiyu, do you happen to know what Premiere does when it converts to RGB?

[tonyzhankaiyu]

I did not look into it, frankly. But we can refer to Mainconcept's DV codec which has a few options: "RGB 16-235" and "Clam YUV to CCIR 601" for both encoder and decoder. My understanding is Premiere must convert clips into RGB data with full range of 0-255. This can be proved by clips with pure colors, so I believe in it.

[JoeB]

I found ProCoder to give me better quality than TMPGEnc.. but with many problems!

Read about it here:

http://forum.doom9.org/showthread.php?s=&threadid=54440

[Ookami]

@Arky and the TMPGEnc colours :)

Duh... A few days ago, I've first time heard of an old bug in TMPGEnc (Kika's posting on a german board).

It seems that TMPEnc uses, even with PAL, the NTSC scale, so the colours look washed out. You can, eg, fight against that with the internal Descale CCIR (if this was a german board I could've just copy and pasted a certain PM comment... ;-)

Because I've only noticed this phenomenon sometimes (and always discarded it for the lossy encoding), I'm not going to comment anymore on encoder qualities :p .

BTW, mb1 has some nice optimisations for DV material on TMPGEnc, do a forum search and you'll find many good postings related to MPEG2 encoders from him.

Cheers,

Mijo.