Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-2 Encoding

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 19th May 2003, 23:46   #1  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
CCE FAQ (Updated)

Welcome to the CCE FAQ! Please make sure you have read this and the CCE manual before posting in this forum.

Please post questions, suggestions, additions and anything else related to this FAQ in the open CCE FAQ Discussion thread.


Q1: What is CCE?

Q2: What are the differences between the versions of CCE?

Q3. Where can I download trial versions of CCE?

Q4: What are the limitations of the trial versions?

Q5: How do I get rid of the trial version limitations?

Q6: What version should I use?

Q7: What are the best settings?

Q8: Why does CCE crash, freeze or generate a checksum error during encoding?

Q9: Can I work in other programs while CCE encodes?

Q10: What's the deal with the "Upper Field First" option? I heard it has a bug?

Q11: Where is the "Upper Field First" option in CCE-SP 2.67 and CCE-Basic?
  1. Q11.1 Does CCE-SP 2.70 Support a true field dominance setting?
Q12: How do I set the "Luminance Level" option correctly?

Q13: Why does the manual say I should not set the timecode to 00:00:00:00?

Q14: Questions related to frameserving video into CCE via AVISynth
  1. Q14.1: Why does CCE-SP 2.50 crash when I try to load or encode an AVISynth script?

    Q14.2: Why do I get a "Frame size XXXxYYY is not supported. Supported frame size is up to 720x576" error message or only a 10 seconds clip when I try to load an AVISynth script?

    Q14.3: CCE-SP 2.66/2.67/CCE-Basic leaks memory when encoding from an AVISynth script. How can I fix this?

    Q14.4 AVISynth 2.5.x and (interlaced) conversion from YV12 to YUY2
Q15: Links and essential reading

Last edited by Trahald; 1st August 2005 at 14:08.
RB is offline  
Old 19th May 2003, 23:48   #2  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
Q1: What is CCE?

CCE stands for Cinema Craft Encoder, manufactured by Custom Technology, and can be used to refer to any one of four products; CCE-Pro, CCE-SP, CCE-SP2 and CCE-Basic. As this forum almost exclusively deals with CCE SP/SP2 and CCE Basic, so does this document. CCE SP/SP2 and CCE Basic are software MPEG1/2 encoders of exceptional speed, quality, and flexibility. They take input from AVI and QuickTime files, as well as frame served AVIs from VirtualDub or AVISynth. Processing is CBR, one pass VBR, or multi-pass VBR. Output is MPEG1 or MPEG2, with the option of being fully VCD/SVCD/DVD compliant.


Q2: What are the differences between the various versions of CCE?

There is a detailed feature comparison at the Cinemacraft web site. Basically, CCE-Pro is a hardware MPEG encoder intended for professional applications and outside of the scope of this forum. CCE-Basic is CCE SP with several advanced features removed and multi-pass VBR encoding limited to 2 passes.


Q3. Where can I download trial versions of CCE?

The latest CCE-SP/SP2 trial version is available at the japanese Cinemacraft web site. Note that the current CCE-SP 2.70 is still a beta version. CCE-SP2 1.00.00.01 is the newest SP2 version available. A trial version of CCE-Basic can be downloaded at Visible Light. Trial versions of some previous versions of CCE-SP can be downloaded directly from the Doom9 download section:Q4: What are the limitations of the trial versions?

All trial versions are limited to 30 days of operation and display a Cinemacraft logo in the encoded video. Starting with CCE-SP 2.66 and ending with 2.67, trial versions also cannot save or load Encoder Control List (.ECL) files, command line support and the ability to selectively apply filters to individual ranges of video is removed (new in CCE-SP 2.66, see CCE manual for more information on these features). Note CCE-Basic trial versions can save/load ECL files and do have command line support, advanced filters are not available in CCE-Basic anyway. The latest Limitations listing for CCE-SP 2.70 and SP2 1.00 states only the 30 day limitation and the Cinemacraft Logo in the encodes.


Q5: How do I get rid of the trial version limitations?

Originally posted by Doom9 and slightly edited by RB

Buy the software!!! Available at www.visiblelight.com is CCE-SP for $1950 and CCE-Basic for $58.

However, the inability to save and load ECL files in CCE-SP 2.66/2.67 trials can be worked around by using the EclCCE utility. Note that this is NOT a crack or something else violating the CCE-SP license agreement, it basically simulates user input using common Windows programming techniques to examine/modify the CCE-SP GUI options and manages the ECL based on these. CCE-SP 2.70 and SP2 1.00 Trial allows saving of ECL Files.

If you intend to get either of those softwares for free at this place I suggest you leave now before you put the very existence of this forum in jeopardy. It is not permitted to ask where to get a "free" version, how to turn the demo into a full version, ask for a crack to be sent to you or anything that could be construed as asking for illegal means to get the full version of the software by illegal means. If you still do so know this: First we'll apply the forum rules, which you signed when you got your account here, to the fullest extent possible which means two strikes and you're 2/3 on your way to a one month suspension and second you are doing this community a huge disservice. I have seen forums shut down because they tolerated cracks and the likes and I'm not going to let this happen to my forum. Don't just think "it's just a little violation, nobody will bother" because it's just the little things that will eventually get you busted. You are not taking a personal risk, but the server administrator and the people operating this forum are taking the risk for you. And there's a very real possibility that some day when you'll post links to illegal content the copyright holder will notice it and send their lawyers to shut the site down. It has happened before and it can happen to this place if we're not careful. Do you want to be the guy who is personally responsible for shutting down this forum? Imagine thousands of very pissed people coming after you, starting with this one.


Q6: What version should I use?

Well, first you'll have to choose between CCE-SP/SP2 and CCE-Basic obviously depending on how deep your pockets are. Generally, I think that considering CCE-Basic uses the CCE-SP encoding engine, $58 is a really great deal. DVD-Rebuilder and Big-4 fully support CCE-Basic for high-quality full DVD backups.

As for CCE-SP, many people around here are still using the older 2.50 version. Generally speaking, at least to my eyes, there is no difference in quality between the 2.50 and 2.66/2.67/2.70 versions when using corresponding encoder settings. CCE-SP 2.50 is still the fastest choice for AMD processors while v2.66/2.67 (*I have not seen tests with 2.70) will run fastest (and a little faster than 2.50) on Intel P4 systems. As with any software, the newer versions have bugs removed and new features added (see the CCE-SP history.txt file). Apart from that I like the revamped GUI in CCE-SP 2.66/2.67/2.70 much better, all I can say is that if you have CCE-SP 2.50 and are happy with it, then you can stick with it, but you should possibly give the newer versions a try as well. Note that CCE-SP 2.50 will happily coexist with CCE-SP 2.66/2.67/2.70 so you can have installed both at the same time. SP2 is in its infancy and some may want to wait to dive into it.

Note that between CCE-SP 2.50 and CCE-SP 2.66, Custom Technology also released CCE-SP 2.62 and CCE-SP 2.64. I have never used any of these versions but the general opinion seems to be that v2.62 is to be avoided because it cannot import AVISynth scripts and that v2.64 is generally less stable than v2.50.


Q7: What are the best settings?

Oops, you'd be be about to violate Forum Rule #12 if you were to post this question

First, there is of course no such thing as "the best settings". It depends on your input material and what you think looks best. Read the CCE manual to learn about the available options and if still in doubt, play with the settings and encode short test clips (hint: rename the *.MPV file generated by CCE to *.MPG and you can play it in most software DVD players like WinDVD and PowerDVD).

Anyway, some general recommendations:
  • disable the Anti Noise Filter (CCE-SP 2.50) and all filters in Quality Settings in CCE-SP 2.66+, uncheck "Quality setting" in CCE-Basic. Play with the filters only if you think that the result could be improved when compared to the original. Note that the "Effect restricted vertical filter" in CCE-SP 2.66/2.67 replaces the "Anti Noise" filter in CCE-SP 2.50.
  • for interlaced material, deactivate "Progressive frames" and "ZigZag scanning order" (CCE-SP 2.50), uncheck "Progressive Frame" and set Block Scanning Order to "Alternate" (CCE-SP 2.66+/CCE-Basic). Choose opposite settings for progressive material.
  • for questions regaurding "BFF" (Bottom Field First) and "TFF" (Top Field First) interlaced material, see Q10.
  • if fade-in from black looks "blocky" or there is banding/blocking in dark/evenly coloured flat image areas, try increasing "Image Quality Priority" in CCE-SP 2.50 and "Quantizer characteristics" in CCE-SP 2.66/2.67 (not available in CCE-Basic). Generally, you should use a higher value at higher bitrates. With CCE 2.66/2.67 and bitrates above 3000 kbps, 25-30 is my preferred choice. Note that in CCE-SP 2.50, the range for this option is 0-100 whereas in CCE-SP 2.66/2.67 it is 0-64.
And a few words about the number of passes for a multipass VBR encode in CCE-SP. The CCE-SP 2.50 manual says
Quote:
Image quality slightly improves each time encoding is repeated, but quality improvement reaches its limit at 3 ~ 4 times of encoding
and you can trust it on that even for the later versions. Remember that in multipass VBR mode you have a fixed average bitrate and all that CCE-SP can do is try to find an optimal distribution of the available bits between easy and difficult to encode scenes. More passes will not make up more bitrate from air. You are free to use up to 9 passes, but, and this is strictly IMHO, anything more than 3 passes is just a waste of time at any given bitrate. 2 passes will be enough most of the time.


Q8: Why does CCE crash, freeze or generate a checksum error during encoding?

Note that the encoding process is a very CPU intensive task, placing a 100% load on your CPU for possibly several hours and transfering several gigabytes of data, depending on encoding mode and length of the video. It absolutely requires a stable computer. If you're overclocking you're asking for trouble. You should be able to run Prime95 for 24 hours, and a decent memory test for 24 hours without error. If you are encoding in multipass VBR mode, you should also pay attention that average and max. bitrate aren't set too close to each other. Especially CCE-SP 2.50 seems to freeze occasionally when the difference between avg. and mix. bitrate is less than 300 kbps.

If you are getting the "checksum is different from that of previous pass" error, that means that when CCE tried to read a frame from the source video, it was different from that very frame read in the previous pass. IOW, data corruption is going on somewhere in your machine or there are (bad) frames that the codec responsible for decoding the video format does not handle "the same way" every time. In this case, make sure your machine is stable according to the criterias outlined above and if not, eliminate the source of the problem (overclocking, bad memory, install latest VIA drivers if applicable etc.). If it still fails, try re-saving the video in VirtualDub using "Direct Stream Copy" for both video and audio to eliminate the bad frames. You could also try to save to another format using "Fast Recompress" for which I'd recommend the lossless HUFFYUV codec, though that requires a lot of disk space.


Q9: Can I work in other programs while CCE encodes?

Most certainly yes! The only thing you want to make sure in this case is that your system is stable and that CCE doesn't use so much CPU time so reasonable processing power is still available to other applications. To do this, run CCE with a lower process priority via the following batch file:
Code:
@echo off
start "CCE" /LOW <path to CCE executable>
Replace <path to CCE executable> with the full path to the CCE executable (and remember to put it in quotes if it contains spaces) and create a link to the batch file on your desktop, run CCE via that link.

Last edited by Trahald; 21st August 2006 at 00:49.
RB is offline  
Old 19th May 2003, 23:49   #3  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
Q10: What's the deal with the "Upper Field First" option? I heard it has a bug?

The confusion about this option arises from that it works different from what you think. Naturally, you'd think that you set this option according to the field order of the video to be encoded, that is, deactivate it if source is bff (bottom field first) and activate it if source is tff (top field first). However, when you do this the encoded video plays back jerky with artifacts typical for incorrect field order.

So how do we set it right? First, you have to know that CCE (SP as well as Basic) always outputs video that is flagged "top field first" (there is a flag in the MPEG header that tells the player which field of the decoded frame to display first on a TV screen). There is no way in CCE to change this. According to Custom Technology, this is not a bug but a feature of CCE... Actually what happens if you check "Upper Field First" is that CCE assumes that source is bff and converts it to tff so it complies with the always set tff flag. It does so by shifting each frame up by one line, ensuring that the previously bottom fields are now top fields and the video is played back correctly. This is not the most sophisticated way to handle the situation, but it works and you won't notice the missing line at the top.

So here is the rule of thumb: Always uncheck "Upper Field First" unless your video is interlaced AND bottom field first. Progressive material is always top field first. To check whether your interlaced video is bottom field first, use the following AVISynth script:
Code:
#Use Mpeg2Source() for MPEG2 video
AVISource("E:\Video\holiday.avi")
AssumeBFF()
SeparateFields()
Now open this script in Windows Media Player. If all movements and horizontal pans look smooth, it's definitely bottom field first, but if you notice stuttery/jerkiness, it's top field first.

If for some reason you want to encode bff video without that line shift, there are two ways to do this:
  1. Frameserve bff video into CCE via AVISynth and convert it to tff "the right way". Here is a basic AVISynth script that does this:
    Code:
    AVISource("E:\Video\holiday.avi")
    DoubleWeave().SelectOdd()
    Uncheck "Upper Field First" in CCE and encode.
  2. Uncheck "Upper Field First" and encode bff video directly. Then use ReStream to clear the top field first flag in the MPV file CCE generated. Load the MPV into ReStream, uncheck "top field first" and click "Write!".


Q11: Where is the "Upper Field First" option in CCE-SP 2.67 and CCE-Basic?

In CCE-SP 2.67 and CCE-Basic, this option has been replaced by "Offset Line" (a text input control in Video Settings you can type a line number into). It works exactly like "Upper Field First" in that it tells CCE by how many lines to shift up the video.

Again here is the rule of thumb: Always set "Offset Line" to 0 unless your video is interlaced AND bottom field first in which case you set it to 1. Progressive material is always top field first.

While possible, it makes no sense to set this option to anything other than 0 and 1. I wonder why they are implementing it that way, now it's possibly even more confusing than before

Q11.1: Does CCE-SP 2.70 Support a true field dominance setting?

Funny you should ask. It sure does. It uses a "top_first" setting to allow changing the actual Top Field First flag. "top_first" set to 1 will set the Top Field First setting for all frames. "top_first" set to 0 will give you a Bottom Field First setting for all frames. CCE-SP 2.70 also still supports the "offset line" setting and works as before but you may want to leave it alone (ie always at 0) as not to confuse things with top_first.


Q12: How do I set the "Luminance Level" option correctly?

To make it short: it doesn't matter unless your video is in RGB format. I know some people will argue about that but I'll prove it below *).

MPEG1/2 (and that's what CCE encodes to) uses a color format called YCbCr which is vastly different from RGB. So CCE needs to convert RGB to YCbCr if the input clip uses RGB colors and does so by applying a conversion formula described in the CCE manual. The "Luminance Level" setting specifies a factor in this formula that controls whether the luminance range of the conversion complies with the ITU-R BT.601-5 standard (16-235, applicable for display on TV) or is more applicable for viewing on a computer screen (0-255). You decide what's best for your viewing application. But basically, if you want to retain the original luminance level of the RGB video, set it to 0-255 as 16-235 compresses down luminance.

So, how do you know if your video uses RGB colors? I know of only the two following scenarios where this can happen:
  • You are frame serving a DVD2AVI project into CCE via VFAPI. VFAPI always converts to RGB. And this is also the only time where the YUV -> RGB Scale setting in DVD2AVI matters. Because DVDs usually already comply to the ITU-R BT.601-5 (16-235) standard, you will want to use "PC Scale" in DVD2AVI and "0-255" in CCE in this case to avoid any luminance compression.
  • You are using the CCE Adobe Premiere plugin. Premiere feeds RGB video to the plugin and it depends on the DV codec used whether it performs any luminance scaling during the conversion. For instance, the Canopus DV codec has an option "Expand RGB range to 150%" for the YUV-RGB conversion which means luminance would be stretched to 0-255 during conversion. Again, you generally want to avoid any luminance scaling and set Luminance Level to 0-255 in the CCE plugin.
DVD2AVI projects frame served into CCE via AVISynth/mpeg2decX.dll do not use RGB but the YUV color space which is basically just another name for YCbCr. So no conversion takes place and you can ignore both the YUV -> RGB Scale setting in DVD2AVI and the Luminance Level setting in CCE.

*) Here is the proof: take any short clip you know is in YUV color format. For instance, the following short AVISynth script ensures you get a YUV colors clip:
Code:
ColorBars(720,480)
ConvertToYUY2
Trim(0, 299)
Now encode that clip in CCE into two different files, use "0-255" for the first and "16-235" for the second encode. Perform a binary comparison of both MPV files (use a command line fc /b clip0_255.mpv clip16_235.mpv). They will be identical.



Q13: Why does the manual say I should not set the timecode to 00:00:00:00?

The manual says that you should not do this because "00:00:00:00 has a special meaning to CCE-SP". I honestly do not know what that special meaning is and I never had any problem using the 00:00:00:00 time code.

The only time where you must not set it to 00:00:00:00 is when you are encoding hybrid NTSC material and want to utilize the inverse 3:2 pulldown feature in CCE-SP 2.66/2.67 and CCE-Basic ("3:2 Pulldown Detection" option). Apparently 3:2 pulldown detection does not work correctly when time code is set to 00:00:00:00, see this thread.


Q14: Questions related to frameserving video into CCE via AVISynth

AVISynth is a powerful frameserver that in conjunction with CCE is mostly used to feed MPEG2 video into CCE because CCE cannot natively decode MPEG streams. It's true power however is in the endless possibilities of preprocessing video, like cropping, resizing, trimming and applying filters. You can learn more about it at the AVISynth web site and in the AVISynth Usage Forum at Doom9. Doom9 also hosts a basic guide for setting up an AVISynth script that will serve your decrypted DVD VOBs into CCE for re-encoding.

You get the latest AVISynth version here. Note AVISynth 2.0x is no longer being developed, please use the currently released AVISynth 2.5.x version.

Last edited by Trahald; 1st August 2005 at 17:20.
RB is offline  
Old 19th May 2003, 23:53   #4  |  Link
RB
Retired
 
Join Date: Nov 2002
Posts: 1,349
Q14.1: Why does CCE-SP 2.50 crash when I try to load or encode an AVISynth script?

This is probably a bug in CCE-SP 2.50 and happens when the AVISynth "stream" does not contain audio. The way to fix this is to add "fake" audio. Depending of your version of AVISynth, you can do this as follows:
  • For AVISynth up to version 2.07, add a simple
    Code:
    ResampleAudio(44100)
    at the end of your script.
  • For AVISynth 2.08 and 2.5.x, create a text file in your AVISynth Plugins directory (usually the 'Plugins' directory in the AVISynth installation directory) named AddAudio.avsi, then paste the following into the file
    Code:
    function AddAudio(clip v1) {
    v2 = Blankclip()
    v1 = AudioDub(v1,v2)
    return v1
    }
    Add the line
    Code:
    AddAudio()
    at the end of your script.
Alternatively, make sure that in the currently active CCE-SP 2.50 template (see "Template" menu item), the "Audio File" option is not checked before loading an AVS file into CCE. In that case you don't need the fake audio trick.

Well, now that you did that you can load the Script into CCE-SP 2.50 but it may still crash when you start encoding. This will happen on AMD Athlon "Thunderbird" CPUs because CCE-SP 2.50 uses SSE commands to process audio. SSE is not supported by the Thunderbird line of CPUs, that takes at least an Athlon XP. You'll have to uncheck the "Audio File" option in Encode Settings, process audio in another program and later multiplex it with the CCE encoded video file (which is recommended anyway because CCE's audio encoder is generally not considered to be top of the line).


Q14.2: Why do I get a "Frame size XXXxYYY is not supported. Supported frame size is up to 720x576" error message or only a 10 seconds clip when I try to load an AVISynth script?

This indicates that there is an error in your AVISynth script. In this case AVISynth outputs not actual video but just a short clip displaying an error message. Depending on the length of the error message, the clip may also have a "non-standard" resolution like 852x52 and that's what CCE complains about. Open the script in Windows Media Player to see the error message and fix your script. A good starting point for fixing script errors is the AVISynth Troubleshooting Guide.


Q14.3: CCE-SP 2.66/2.67/CCE-Basic leaks memory when encoding from an AVISynth script. How can I fix this?

Yes, there is a bug in CCE-SP 2.66 throughout 2.67.00.23. When you are monitoring memory usage in task manager during encoding and AVISynth script in these versions, you'll notice that for each file and for each encoding pass (be that one pass VBR, CBR or multipass VBR) the program grabs another large chunk of memory and never releases it until the program is closed. Depending on the number of files and passes, you can eventually run out of memory.

The fix for this again is to add a fake audio track to the AVISynth script as outlined in Q14.1, above. However, another memory leak with AVISynth scripts that cannot be worked around this way occurs every time you open the "File Settings" dialog in CCE (where you specify chapters and encode range etc.).

Both issues are finally fixed in CCE-SP 2.67.00.27, not fake audio tracks necessary anymore


Q14.4 AVISynth 2.5.x and (interlaced) conversion from YV12 to YUY2

An important difference between AVISynth 2.0x and 2.5 is that naturally AVISynth 2.5 operates in the YV12 colorspace whereas AVISynth 2.0x operates in YUY2 (mandatory read: AVISynth YV12 FAQ). YV12 happens to be the native format used on DVD so one can expect a significant increase in speed when frame serving video originating from DVD VOBs because theoretically no color space conversion needs to be performed. Unfortunately for CCE users this is only half the truth because no version of CCE can currently natively read YV12 input, CCE itself can only decode RGB and YUY2. You'll have to add a
Code:
ConvertToYUY2(interlaced=true/false)
at the end of your script which unfortunately destroys most of the speed advantage. At least, even when using simple filters like Resizing, things are going to be faster than with AVISynth 2.0x, just make sure you put them before the color space conversion. The filters can obviously work simply faster in YV12 mode.

Note also that as shown above, ConvertToYUY2 in AVISynth 2.5.x has an optional 'interlaced=true/false' (default false) parameter used to ensure that interlaced coded video is converted correctly. It is important that you set this parameter right especially for interlaced coded video (example of incorrectly using ConvertToYUY2() for interlaced coded video, note the green stripes). I'm stressing the word coded here because that's what counts for ConvertToYUY2(), not what the video looks like in a software player. For instance, many DVDs are encoded interlaced although you can clearly see that the source material is progressive, i.e. no interlacing artifacts visible in DVD2AVI preview. So in case you are frameserving MPEG2 video, open the source MPEG/VOB in DVD2AVI and start the preview (F5). Watch the status window, if it mostly reports "Progressive", use ConvertToYUY2(), else if it's mostly "Interlaced", use ConvertToYUY2(interlaced=true). If in doubt, use ConvertToYUY2(interlaced=true) because it ensures interlaced coded material is handled correctly and the negative impact on progressive coded material is negligible.

However, one possibility to feed YV12 directly into CCE is some external codec that decodes YV12 data for it. This seems to work reliably only with CCE-SP 2.67.00.10 and newer, both DivX and XviD should do the job, as well as the lite version of the ffvfw codec included in the latest AVISynth 2.5 installers. In my tests however (using the ffvfw codec) and others, there seems to be not any difference in speed or even decreased speed compared to a ConvertToYUY2() in AVISynth. Also, the externals codecs may assume progressive video (at least DivX and XviD do) and mess up chroma for interlaced video for reasons outlined above. So for the time being, my advice is to stick to the conversion in AVISynth, eliminating another source for possible problems by minimizing the number of video processors involved.


Q15: Links and essential reading

Last edited by RB; 16th April 2004 at 12:32.
RB is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 14:58.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.