CCE FAQ Discussion [Archive]

Scipio

21st May 2003, 19:51

You could make the questions at the beginning clickable.
Example: http://forum.doom9.de/showthread.php?s=&postid=227

<a href="#Bitrate">Bitrate</a> <-- that's the link at the beginning
...
...

and then deep down in the FAQ you only have to add:
<a name="Bitrate"></a>Bitrate <-- that's the actual jump point (named anchor) where the link refers to

(this example doesn't work here, but on doom9.de it works of course)

21st May 2003, 20:03

Scipio, I would have done that in the first place, but as you said, HTML is not allowed here at all. Maybe this could be changed so it is at least allowed for Mods.

23rd May 2003, 13:51

Updated Q12 to include information for the CCE Premiere plugin. Thanks to tonyzhankaiyu.

snowbeach

2nd June 2003, 14:06

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 VirtualDub to see the error message and fix your script. A good starting point for fixing script errors is the AVISynth Troubleshooting Guide.

I am not sure, if this is 100% right?! After installing first GKnot RipPack 0.28.2 and then CCE 2.67.00.10. Everything worked fine. Then installing the current build of DVD2SVCD 1.1.3 Build 2 incl. AutoFitCD, D2Sroba201, D2sccd and FitCD112 and encoding with CCE 2.5, after installing it at last, I got my 2 .mpg files. BTW. The 1st was 800 MB big, the second was not, ~523 MB. :confused:
After this encoding session I could not open any .avs scripts without the error mentioned above. Deinstalling the previous installed software and reinstalling only GKnot and CCE 2.67.00.10 the avs script, which is 100% correct, works again.

2nd June 2003, 17:08

Well, just do as I suggested and open the failing AVS in VirtualDub or MediaPlayer. What is the error message?

snowbeach

2nd June 2003, 17:29

Did it, before reinstalling! And VirtualDubMod 1.5.1.1a build 1191 gave me the same error message as CCE! But the thing is that the .avs script,
LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec3.dll")
mpeg2source("E:\DVD\Projects\VIDEO_TS_VTS_13_PGC1\VIDEO_TS.d2v")
crop(6,68,710,440)
LanczosResize(640,272)
as you can see, has no error! Reinstalling and using the same script everything worked again, of course.
No idea, why I got this problem. Probably there are some incompatibilities with GKnot and DVD2SVCD - having them both installed. Because both try to install the avisynth.dll to the system32 folder. Probably I got this problem, because I was encoding a movie with GKnot and, while encoding, I tried to install DVD2SVCD. Then I got from the DVD2SVCD setup routine an error message that it could not write the avisynth.dll to the system32 folder, because it is used. That is true, of course. ;) But encoding afterwards with DVD2SVCD was no problem.

First I got the cannot write .ecl projectt error message, when using CCE 2.67.00.10, but if I had used your EclCCE instead of the original cce executable, I think I would not get this error message. ;)

Then I tried CCE 2.5 with AutoFitCD and it has done its jobe good (only thing the smaller second mpg file :( ). After this encoding session I could not load any avs script anymore...

Since everything works again, I am very lazy to reproduce this error. Maybe I am going to try it, to reproduce it...

The only thing I want to say is that you can get this error message, even if you have a well working/error free avs script! In my case, I suppose that it is an software problem between GKnot and DVD2SVCD or that I tried to install DVD2SVCD while GKnot was using the avisynth.dll from the system32 folder.

2nd June 2003, 18:17

Originally posted by snowbeach
The only thing I want to say is that you can get this error message, even if you have a well working/error free avs script!
No :). The script may be syntactically correct but there may still be a mismatch between the plugins and the AVISynth version, which is the case here IMHO.

It looks like GKnot installed AVISynth 2.5 (mpeg2dec3.dll is an AVISynth 2.5 plugin) and when installing DVD2SVCD, you opted for installing AVISynth 2.08. Now you have AVISynth 2.08 installed and mpeg2dec3.dll can't be used as it is an AVISynth 2.5 plugin.

snowbeach

2nd June 2003, 18:40

Yes, I am using with GKnot 0.28.2 AviSynth Plugin 2.5. But I think that I was installing DVD2SVCD with the same AVS Plugin... Not sure... If I can reproduce the error I am going to post it here!

snowbeach

6th June 2003, 16:05

Reproduced the error. Used DVD2DVD-R and when I want to use GKnot for MPEG-4 encoding, I got this error message again. DVD2DVD-R is not using the AviSynth 2.5x Plugin, while GKnot does. So you have to change the AviSynth version in your .avs script to make it work again, or if you want to use the AviSynth 2.5x version you will have to reinstall it. Is there another solution to make AviSynth 2.5x work again, withour reinstalling it?

Tantabootsy

8th June 2003, 12:12

Cool FAQ!! This forum is getting better and better, the programs too ;-)

DDogg

13th June 2003, 14:14

Damn, RB, the work you have done on this faq is downright amazing. Superior in every way. Thanks, we sure needed it.

JimBryce

18th June 2003, 06:14

I agree RB, the FAQ is fantastic! :) Very well done indeed.

These next questions aren't meant to be a "but" to my first statement—I stand by what I said—instead they are just questions I have from reading the FAQ and my own experience with "CCE" and "eclCCE" (both of which are fine products as I've said before...):

1> In "Q14.1" you seem to indicate that "CCE v2.50" is the only version that needs the "AddAudio()" fix, then in "Q14.4" you indicate that the memory leaks in "CCE v2.66/2.67" are from the same problem and to use the "AddAudio()" fix. But from the "eclCCE.pdf" and this thread (http://forum.doom9.org/showthread.php?s=&threadid=46664&pagenumber=3) I thought the problem had something to do with the Chapter list, encode range and per-file audio options in the ecl and that the fix was adding "ChapterList=0" to the "eclCCE.ini"? Is it both? If I'm using "CCE v2.67" can I leave the "AddAudio()" off? Not that that's a big deal, but I'm curious...

2> In "Q14.2" you only mention the cause of that error as an avisynth script error but there is also a problem with one of the plugins (either "LoadPluginEx.dll" or "warpsharp.dll", I don't remember which and I don't have the time right now to find the thread-though I will if you want me to) that will cause that problem—it was in my case in particular—so perhaps you might want to include that solution as well.

Thanks again for all your help and good work. You've become one of the main people I can count on to have an answer when I've exhausted all other sources!

18th June 2003, 15:02

As for Q14.1, the thread you mention discusses only the problem with leaked memory when opening/closing the CCE Chapter List dialog. But it turns out that additionally, CCE leaks memory during the actual multipass encoding. AddAudio() fixes both issues and yes, you also need it for CCE 2.67. I think now that we know how to fix it, I could remove the support for the ChapterList=0 setting. But maybe not :)

And maybe Q14.2 should state more generally that this error message is the result of some AVISynth problem. I don't think we should discuss the specific possible reasons for it in the FAQ, because, well, it's an AVISynth and not a CCE problem.

JimBryce

18th June 2003, 15:56

Leaving the support for "ChapterList=0" setting is probably a good idea, especially since it doesn't have any negative impact (e.g. speed) other than what it's supposed to do and it does help with the problem.

Same for the "AddAudio()", especially since it might help to prevent problems and doesn't cost anything to use it.

As for "Q14.2" don't you think a little help should be given? Even if it's just a link to the part of the forum where those problems are discussed. When encountering that error, the first reaction is to think "CCE", so if someone goes to the "CCE FAQ" to look for an answer and all they get is "it's an avisynth problem", that seems rather cold. Maybe just a little hint? :D

Well, that's my couple of minutes worth—all I could think of that might be useful for the "CCE FAQ" after thinking about it for a while. Since I'm still relatively new to "CCE" if I come across a problem and can't get the answer from the "CCE FAQ", I'll try and find the answer then show you both and see what you think about adding them. You've done a great job! :)

ps. I'm not opposed to doing some of the "finger-work" (searching the forum to see if an answer already exists or similar) for you if it will help. You've always been very good at helping everyone, not just me, and I don't mind some payback. Let me know.

tonyzhankaiyu

20th June 2003, 08:12

Quote start:
Q7: if the interlaced material is "bff" (bottom field first) like most DV camera footage is, check "Upper Field First" in Video settings (CCE-SP 2.50/CCE-SP 2.66), set "Offset Line" to 1 (CCE-SP 2.67/CCE-Basic). If you are encoding progressive or tff interlaced material, always deactivate "Upper Field First"/set "Offset Line" to 0. We'll talk more about this in Q10.

Q10: Always uncheck "Upper Field First" unless your video is interlaced AND bottom field first. Progressive material is always top field first.

Q10: 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: 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.

Quote end.

RB,
Above quote from your CCE FAQ. For interlaced source I have different points from yours.
I personally uncheck "Upper field First" (2.66) and set "Offset Line" to 0 (2.67) for my DV AVI(interlaced, Bottom field first). After encode it to M2V, I use Changer.exe(Free, by Darim Vision co.) to replace tff with bff. Changer.exe just change the M2V not write a new file to save lots of disk space.

I am a PAL user, I did few test to prove it: use BMP with only one pixel-high line at the top to create a MS DV AVI, let CCE SP encode it with different tff setting. I got above conclusion.

Would you please re-confirm this setting?

tonyzhankaiyu

25th June 2003, 13:33

Well, Changer appears to do the same thing as Restream as suggested in Q10. So you should be fine.

Black Hole

14th December 2003, 18:54

While answering an user question in the Spanish Doom9 forum, about the old CRC error in CCE 2.50, I took a time to read the FAQ again. I though that the Spanish translator of the FAQ (TuCo) missed the point, but now I realize that your new updated version of the FAQ has removed the reference to the CRC Patch in Q8.

I have read about people commenting it was just an AMD failure, but it happened to me in my old Intel Celeron. Now it seems that every time you get a CRC error you should start to get worried about the quality of your memory modules. I think this is wrong.

We should remember that when we started using CCE 2.50, we used old DivX codecs to feed frames. These codecs were far from perfect and they didn't decode the MPEG4 frame exactly the same way. Furthermore, if we used DirectShowSource() instead of an AVISource() approach, the postprocessing effects such as deblocking, deringing and noise generator were randomly generated ... so the frames could never be the same again.

I realized this when I converted a clip to HuffYUV and an unpatched original CCE 2.50 stopped complaining about CRC error ... obviously I didn't have memory errors. For example, if we configure ffdshow to decode DivX content and force it to apply postprocessing, we would also find that the second pass frames are different from the first pass ones.

So I think the link to CCE CRC Patch (I am NOT talking about a crack) should be inserted again in the FAQ. I didn't have the time myself to test that patch, so I don't know if it cracked the program. I think that an illegal patch wouldn't have been included in the old FAQ itself, would it?

So ... what do you think about this? Anyway, the patch is still listed in Q27 of the official DVD2SVCD Doom9 FAQ ;)

JazzySOB

29th December 2003, 17:29

Hi,

I'm a bit confused about Q11 of the CCE Faq:

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.
I see that Progressive material is always "top field first", but doesn't that have the same meaning as "Upper Field First"? And thus should I check "Upper Field First" when I want to encode a progressive DVD? Simply because I think "up" is the same as "top"..

But my english is not that well so maybe that's the cause of the misunderstanding ;)

Thanks

tonyzhankaiyu

30th December 2003, 01:48

If you CHECK "upper field first" in the CCE, it just shift one line up for each frame(or field). That means that the contents of your encoded result is different from your source.

Also the encoded result is alwasy upper field first, whether you check it or not.

So DO NOT CHECK the "upper filed first" or SET "OFFSET" to "0"(Version 2.67) in CCE.

After the encoding ends:
1. For interlace source, process the resulted M2V file with Easy Changer to get "bottom field up";
2. For progressive source, do nothing.

11th January 2004, 16:46

Originally posted by Black Hole
So I think the link to CCE CRC Patch (I am NOT talking about a crack) should be inserted again in the FAQ. I didn't have the time myself to test that patch, so I don't know if it cracked the program. I think that an illegal patch wouldn't have been included in the old FAQ itself, would it?

I removed the link for a reason. The CCE license agreement very clearly states:

1. DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS
You may not reverse engineer, decompile, or disassemble the SOFTWARE
PRODUCT.

And being a programmer myself, I know that to create a "patch" or whatever that modifies an executable you absolutely need to disassemble it. I know I may sound a little picky here but I'd rather be on the safe side and I leave it to the mods of the other forums how to deal with this.

Wilbert

8th April 2004, 17:12

So if you are frameserving interlaced video, use

code:

ConvertToYUY2(interlaced=true)

to get better chroma upsampling.

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 that case assumes DivX and XviD progressive input. So, if you let them do the YV12->YUY2 conversion they will mess up the chroma (if the source is interlaced).

8th April 2004, 19:52

Thanks Wilbert. Hmm, I should really update the FAQ in various places... after all AVISynth 2.5 is no longer beta and not officially released :)

14th April 2004, 14:05

I made some updates to the CCE FAQ, especially concerning ConvertToYUY2(interlaced=true/false).

Logiqx

15th September 2004, 10:27

I have just upgraded my CCE Basic to v2.69.01.10 and noticed a change that relates to questions 10 and 11 of the FAQ. I don't know exactly when this was implemented though as I can't see it in the release notes.

An 'Output top field first stream' option has been added to the advanced settings and is in addition to the 'Offset line' that is already discussed in Q10+Q11 of the FAQ.

The FAQ currently states:

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...
The new option now allows you to decide whether you want top field first or bottom field first flagged in your output. If you encode unaltered DV (i.e. BFF) then you can leave the 'Output top field first stream' option unticked and use an offset line of 0. This results in your footage being left as BFF.

Of course, you can still use the old methods to change the DV footage to TFF:

- Set the offset line to 1 and tick the 'Output top field first stream' option.

or

- Use the DoubleWave.SelectOdd trick in AviSynth plus an offset line of 0 and the 'Output top field first stream' option ticked.

However, we now have the choice of leaving our footage BFF if we wish and that's proably what I'll do from now on. IIRC, I only changed my footage to TFF (using the DoubleWeave.SelectOdd method) for the benefit of CCE because it insisted on setting the TFF flag. I never was keen on having something alter the MPEG afterwards to try to retain BFF (e.g. ReStream). ;)

Logiqx

Volred

7th January 2005, 16:15

A quick question from a real noob regarding this CCE mpeg1/2:

- What container does it go into? .avi? .mpeg? .wmv?

lgcbmb

12th July 2006, 09:15

I was the original poster of the FAQ. Its great to see people ran with it

klipsil

20th January 2008, 09:58

Hi,
i have been using DGIndex/DGdecode with the VFAPI plugin frameserving into CCE SP 2.70 .
i cant really figure out reading through the forum if i must enable ConvertYUY2 in the avs script.
currently i am not .
my source is an interlaced NTSC material and in dgindex i use Tv scale whereases in cce i use luminance 0-255 and streaming through STB it look good on a TV screen.
using luminance 16-235 in CCE shows a too bright output.
so i cant figure it out do i need to add the convertYUY2 in the avs script or not.
Thanks.

harshi

9th March 2010, 07:59

mp3dom

10th March 2010, 22:23

In CCE 2.50/2.66 the option "Upper Field First" is used to 'revert the current field dominance'. So if you have a TFF you would uncheck that option to preserve the Top field dominance. For DV sources (they are generally Bottom Field) you would check the "Upper field first" option to change the field dominance to TFF.

Starting from CCE 2.67/2.70/SP2 there are 2 parameters: 'Output Top Field First' and 'Offset Line'. The first parameter is used to set the field dominance of the output stream. This flags the output mpeg stream and tells how to reproduce it. The Offset Line tells the encoder the field of the source stream. If the value is 0, then it keeps the current field dominance of the source. If the Offset value is 1 it will switch the field dominance of the source.
If your source is TFF:
- Check "Output Top Field First" and set Offset to 0 (for a TFF output)
- Uncheck "Output Top Field First" and set Offset to 1 (for a BFF output)
If your source is BFF:
- Uncheck "Output Top Field First" and set Offset to 0 (for a BFF output)
- Check "Output Top Field First" and set Offset to 1 (for a TFF output)

Butcher Wing

28th February 2011, 18:25

Hi,

I hope someone can advise me on this...

I have been able to successfully encode an uncompressed AVI movie to mpg2 using CCE SP and I'm totally happy with the outcome apart from one thing which I don't understand. During scenes in the movie which I have, for instance.. wooden fences with lots of lines on them, or buildings with intricate carved details in the design or windows with bars on them... I get a kind of crazy flicker effect going on on those particular parts of the image. This weird effect is most commonly seen on people wearing "black and white striped shirts" I think. You know how they create a kind of crazy flickering effect on the stripes?

Well, what causes this, does it have a name and what settings can I play with in CCE to reduce this weird effect?

Thanks alot. :)

P.S - I'm encoding progressive AVI to progressive mpg2 - a high VBR like (max 9000/ avg 8500/min 2000) and 2 pass. All filters were disabled.

Note: This crazy effect is present slightly on the original source dvd video but not as bad or in as many places as the mpg2 CCE produced for me.

neil wilkes

26th February 2012, 13:08

Hi Guys.
Quick question about Q10 in the FAQ - the whole UFF thing.
Does this still apply to CCE-SP3? (latest build on CinemaCraft servers)
Source files are UFF

(I ask as the manual seems to say different, and I have been having problems with this lately, as we normally use Progressive source files)
Output top field first stream
Specifies the field order of output stream. If it is selected, the
output stream is top field first. Otherwise bottom field first. This
setting works only on MPEG-2 output.
It is important to set correct field order, because incorrect field
order causes stuttered motion. To set field order correctly, you have
to care about Offset line setting.
• If the field order is same between the source and the output,
Offset line should be 0 or even number.
• If the field order is different between the source and the output,
Offset line should be 1 or odd number.

mp3dom

26th February 2012, 13:22

The TFF/BFF options in SP3 works exactly as SP 2.67/2.70/SP2.
If your source is TFF, check "Output Top Field first" and set the Offset line to 0. The output will be TFF.
If the source is progressive, you also need to check "Progressive" in the Window->Picture->Picture Type.

neil wilkes

26th February 2012, 14:09

Thanks to all you guys for this essential guide, as well as the clarification above.
The word "Phew" comes to mind.....

One more question on FAQ 7 - the "best" settings, particularly the number of passes in VBR.
Why is the option for 9 pass there is it is not helping matters smewhere along the line? (just curious, really)

EDIT.
Re the original query on FAQ 10, might it not be a good idea to update the FAQ to contain this information?
It definitely seems to say (as it currently stands) that for UFF source the flag needs to be unchecked.
So here is the rule of thumb: Always uncheck "Upper Field First" unless your video is interlaced AND bottom field first.

Is there a definitive list anywhere detailing the changes between the FAQ as written and CCE-SP3?

mp3dom

26th February 2012, 14:30

The FAQ refers to the versions < 2.67 (versions that doesn't have the Offset option but only the "Output TFF" checkbox).
About the multipass, I've seen that the quantization graph subtle changes for 5-6 passes. From 7 to 9 the graph stays pretty much the same. With modern PC (i7) SP3 can encode at more than 100fps (SP1/SP2 is even faster), so to stay on the safe side (even if it's insane) I prefer to encode at 9 pass (+analysis). There are other options anyway that can increase the perceived quality rather than high number of multipass (for example quantizer characteristics, the use of lowpass filter, the encoding type (still, normal, activity) and so on...)

neil wilkes

26th February 2012, 14:38

Thanks for this, it really is appreciated. I also have been using 9-pass as I swear it makes a difference.

Back to the FAQ, there is still ambiguity there for me though. Here's the one that bothers me:
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.

What does this mean? It seems to be saying that from 2.70 setting to top first set to 0 gives BFF for all frames.....very confused.
for a file with UFF source, I need UFF set to 0, yes?

mp3dom

26th February 2012, 15:22

You need to pay more attention to the Offset setting.
Offset = 0 means "keep the current field dominance of the source file"
Offset = 1 means "change the field dominance"

The "Output TFF" doesn't change anything regarding the Field dominance, it only tells which flag the encoder should put inside the mpeg2.
As a general rule:

If your source is TFF:
- Check "Output Top Field First" and set Offset to 0 (for a TFF output)
- Uncheck "Output Top Field First" and set Offset to 1 (for a BFF output)
If your source is BFF:
- Uncheck "Output Top Field First" and set Offset to 0 (for a BFF output)
- Check "Output Top Field First" and set Offset to 1 (for a TFF output)

neil wilkes

26th February 2012, 17:01

Thank you for the clarifications - it was all getting somewhat confusing there for a while.
It did not help that the source files were messed up by the client either - it was a right mess.

Maxiuca

12th June 2012, 18:54

I've got another question I never was able to find an answer to and recently I found this interesting post here:

http://forum.doom9.org/showthread.php?p=1575896#post1575896

TheSkiller wrote: If you used Restream you should make very sure that "top field first" is unchecked if you check both "Frametype progressive" and "Progressive sequence" because otherwise it would be an illegal combination of flags that is known to get refused by some DVD-Players.

So TFF with "Frametype progressive" and "Progressive sequence" is illegal? Is this valid for both NTSC and PAL?

I'm wondering what to do when dealing with a progressive PAL film. I've usually encoded it using default CCE settings (so TFF) and then ran it through ReStream to set the progressive flags (CCE for some reason does not set them).

So should I uncheck TFF and leave the BFF flag?

Another CCE related question:

I had to encode a movie that was shot with 1.37:1 AR and reframed to 16:9, apart from the opening titles that had to be left with original AR and pillarboxed.
The problem is that after encoding, strange vertical artifacts (lines) appear at the border of the pillarbox and the actual image.

It looks like this (a bit like sharpening artifacts):

https://dl.dropbox.com/u/39919356/vet_artifact.jpg

On the left side CCE, on the right side TMPEG. M2Vs decoded with dgindex (cpu=6 and IEEE ref iDCT)

Any ideas what may be causing this?

mp3dom

13th June 2012, 09:01

I'm wondering what to do when dealing with a progressive PAL film. I've usually encoded it using default CCE settings (so TFF) and then ran it through ReStream to set the progressive flags (CCE for some reason does not set them).

CCE supports progressive frametype just fine, as long as you set it to encode in a progressive way. It does not flag the progressive sequence, but it flags the progressive frametype. This means that you can still switch (if you need) some frames from progressive to interlaced (and vice-versa) between the stream. Progressive sequence does not allows this.

So should I uncheck TFF and leave the BFF flag?

If you really want to have a progressive sequence flag, the only in-specs way I'm aware of is to (looking inside ReStream):
- have picture structure set to frame (no field)
- (probably) scanning mode set to zig-zag
- have frametype progressive checked
- have top field first unchecked
- have progressive sequence checked

The problem is that after encoding, strange vertical artifacts (lines) appear at the border of the pillarbox and the actual image.
Any ideas what may be causing this?

Which CCE version are you using? SP2 or SP3? You should tells how you've setup the encoder and/or how the source was made. TMPGEnc works (in the past, don't know now if something has changed) in RGB colorspace, while CCE works in YUY2. If the source is not in YUY2 some conversion is applied. Also, have you disabled the various lowpass filters (enabled by default in all CCE versions)?

neil wilkes

13th June 2012, 09:11

Also, have you disabled the various lowpass filters (enabled by default in all CCE versions)?

What circumstances should these filters be disabled under, just for information?

mp3dom

13th June 2012, 09:39

With all filters disabled, the encoder gets the same "input" as the source. With filters enabled (by default), prior of the encoding process, the source is filtered in some way. Lowpass filters are used to remove some "spike" frequencies, limits the flickering effect and allows the encoder to compress 'better' (with less bitrate, since there are less high frequencies) the image. Those filters can be useful by some extent when you're downscaling from HD source to SD. On a standard defs source image, probably the image is already lowpassed and so the filters are less useful (also, since the lowpass filters 'truncates' high frequencies, the side-effect is to have a sort of "localized blur" onto the image or something similar to an 'edge-enhancement' filter).

Maxiuca

13th June 2012, 09:58

CCE supports progressive frametype just fine, as long as you set it to encode in a progressive way. It does not flag the progressive sequence, but it flags the progressive frametype.

CCE SP2 did flag progressive frametype, but CCE SP3 does not for some reason. Neither of them flags progressive sequence.

If you really want to have a progressive sequence flag, the only in-specs way I'm aware of is to (looking inside ReStream):
- have picture structure set to frame (no field)
- (probably) scanning mode set to zig-zag
- have frametype progressive checked
- have top field first unchecked
- have progressive sequence checked

I've been using all those settings (both CCE and ReStream ones) for a long time now I was just unsure about the TFF/BFF (since TFF is always checked by default).

Which CCE version are you using? SP2 or SP3? You should tells how you've setup the encoder and/or how the source was made. TMPGEnc works (in the past, don't know now if something has changed) in RGB colorspace, while CCE works in YUY2. If the source is not in YUY2 some conversion is applied. Also, have you disabled the various lowpass filters (enabled by default in all CCE versions)?

As mentioned before, I'm using SP3.
In picture settings: all filters are disabled, quant characteristics set to 32, Zigzag scan order, picture type progressive.
In segment settigs: intra block DC precision set to 10-bit, quant scale to no linear and quant matrix to adaptive. I use the default (Natural 1) quant matrix instead of MPEG standard one (changing it didn't help).
The source is RGB, quicktime with no compression (I've tried AVI with no compression as well) that is exported directly from Nucoda Fuse grading/finishing system when it has been scaled to PAL from a 2K source (that underwent restoration process) and and prepared for encoding so degrained/denoised/sharpened.

I've made a lot of DVD streams and most of them for retail DVD and newer had problems until now.

I'll try converting the source to YUV2 prior to encoding and see the result.

mp3dom

13th June 2012, 10:17

CCE SP2 did flag progressive frametype, but CCE SP3 does not for some reason. Neither of them flags progressive sequence.

Uhmm, I'm using SP3 too, and it works the same as SP2. It flags progressive frametype without problems.

I've been using all those settings (both CCE and ReStream ones) for a long time now I was just unsure about the TFF/BFF (since TFF is always checked by default).

With Progressive Sequence On then you should set TFF off.

In picture settings: all filters are disabled, quant characteristics set to 32, Zigzag scan order, picture type progressive.

If you 'edit' the presets (all presets are setup as interlaced with LPF ON with different strength) you also need to save it using another name and then apply your preset to the source (double click on the first frame, check the "picture" box and choose your previously saved preset). If you don't apply your preset, the default one will be used (which is "Natural 3").

Maxiuca

13th June 2012, 11:47

Uhmm, I'm using SP3 too, and it works the same as SP2. It flags progressive frametype without problems.

Strange, SP2 had a setting called "Progressive frame" in "Picture quality" and as far as I remember it was responsible for the progressive frametype flag (probably it was responsible for other things as well, but that's not the issue).

SP3 has "Picture Type" setting that allows to choose between Interlaced, Progressive and Auto Detect (with threshold that you can specify) but it does not affect the flag or am I missing something?

With Progressive Sequence On then you should set TFF off.

Thanks for confirming that. I had no problems with TFF flag in the past but it's always best to stick to specs as closely as possible. I will set TFF off from this time on.

I know that trick with saving settings (or loading from an XML file) to avoid reverting to default (Natural 3) settings.

I've tried YUV2 source (fed CCE SP3 with simple AVIsynth script AVISource.ConvertToYUV2) but the vertical artifact is still there.

Funny thing is that CCE SP2 does not have this problem.

TheSkiller

13th June 2012, 12:20

I can confirm what mp3dom says.

SP3 has "Picture Type" setting that allows to choose between Interlaced, Progressive and Auto Detect (with threshold that you can specify) but it does not affect the flag or am I missing something?It does work, at least for me.
If you select "Progressive" the flag "Frametype progressive" is set (but not "progressive_sequence"), if you choose Interlaced it is not. I never use Auto.
By the way, if you encode something that is entirely progressive it is not a bad idea to select "Zigzag" block scan order for improved encoding efficacy. But I see you're doing just that. :) For interlaced encoding never ever use Zigzag, only Alternate or Auto.

I've tried YUV2 source (fed CCE SP3 with simple AVIsynth script AVISource.ConvertToYUV2) but the vertical artifact is still there.Please see this post (http://forum.doom9.org/showthread.php?p=1576553#post1576553) by me explaining how to avoid any chroma smearing when serving YUY2 to CCE (any version) from a YV12 script. It's very important to have "Offset line" set to 0 for this to work.

Edit: Maybe you are simply not telling CCE SP3 to actually use your settings. It should look like this for example:
http://img7.imagebanana.com/img/1p6078aw/ccesp3settings.PNG

Maxiuca

13th June 2012, 12:53

It does work, at least for me.

Ok, thanks for you post. Now it works for me as well. It seems SP3 is following the DVD specs more carefully and will not add "Frametype progressive" flag if TFF is checked. With TFF unchecked and "Picture Type" set to Progressive (I never use Auto either, cause I deal with progressive material like 95% of the time) the "Frametype progressive" flag is in fact added.
And yes I use ZigZag.

Please see this post (http://forum.doom9.org/showthread.php?p=1576553#post1576553) by me explaining how to avoid any chroma smearing when serving YUY2 to CCE (any version) from a YV12 script.
Thanks, will remember that trick. Fortunately most of my sources are pure RGB.

It's very important to have "Offset line" set to 0 for this to work.
Yeah, offset line was giving me a headache some time ago when I was told that my encodes have strange some bugs in bottom lines... Solved that though (thanks to forum archives).

I also found the solution to my other problem and it's rather simple and silly (kinda embarrassing in a way as well... :)) It seems that I wasn't applying the "Picture settings" to the segment and I was encoding with the default (infamous "Natural 3") setting.
In SP2 the interface was somehow much more obvious and intuitive, but I've switched to SP3 recently for better scene detection (and therefore I-frame insertion, especially for B/W movies) and the interface has beaten me...

But now it's all good, thanks!!

EDIT: Funny thing, I found the solution to my problem, starting writing that post and after I've submitted it I saw your edit with the same solution ;)