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.

[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.

[FredThompson]

How about intentionally re-mapping the color scale from NTSC <-> PAL? Any ideas? I'm shooting in NTSC and can easily use MotionPerfect to get a proper smooth motion but color is another thing. PAL looks garish to my eyes and, as you say, NTSC looks washed-out to yours.