CCE refuses to change Field Order ??

[FranckV]

I am encoding an 29.97 fps interlaced video on SVCD (Mpeg2). Result is jerky when playing on TV due to the wrong field order. I tried to change the field order by unchecking the "upper field first" box in the video settings in CCE, but, selected or unselected does not change anything, bitrate viewer reports the result mpg file with Top field first: Yes.

Encoding the same AVI file with TMPG with Bottom field first works fine when playing on TV.

CCE seems to refuse to change the field order. Is this a know CCE bug or am I missing something ?


Thanks for any help.

[homerpez]

Wish I knew...

Basically, everything I've done lately happens to be "Upper Field First"... I don't know if that's because it's Huffy material or what...

I frameserve from a TMPGEnc project file to CCE, so I have the field selected in TMPGEnc. I leave that box unchecked in CCE, and it has the effect of leaving it alone (still upper field first).

Is there any way to select the field order in whatever you're frameserving from? (I assume that's the only way to use CCE without problems)... I suspect the CCE box is merely a way to "Force A" or "Leave alone", instead of toggling "A" and "B". So it looks like you have to choose field order in the frameserve program.

Please, someone, correct me if I'm wrong because I want to understand this is how it goes for sure...

[KoalaBear]

CCE seems to refuse to change the field order. Is this a know CCE bug or am I missing something ?

CCE is an industrial-grade MPEG encoder designed primarily for production of commercial DVDs. It's not a suitable product for beginners because it assumes you know exactly what you're doing and why; the more you understand about the mechanics of MPEG, the easier the program will be to use -- and vice versa.

I tried to change the field order by unchecking the "upper field first" box in the video settings in CCE, but, selected or unselected does not change anything

MPEG has two picture scanning modes: zigzag (progressive) and alternate (interlaced). If you have zigzag scan selected, the "upper field first" flag is meaningless and therefore ignored.

If you want CCE to encode interlaced video, uncheck all the boxes on the MPEG-2 video settings group except "Add sequence end code" (default) and "Upper field first" (optional).

-----------------------

I suspect the CCE box is merely a way to "Force A" or "Leave alone", instead of toggling "A" and "B". So it looks like you have to choose field order in the frameserve program.

Regardless of the method you choose, pictures are presented to the encoder as a single frame rather than a pair of fields. The encoder interprets the frame as progressive or interlaced according to the scanning method selected. Field B (lower) is coded first by default.

Please, someone, correct me if I'm wrong because I want to understand this is how it goes for sure...

In all honesty, Homerpez, you need to get at least some of your information from sources other than VCDHELP. Try entering the question How does MPEG-2 handle interlaced frames? into Google or AltaVista and see what you come up with.

[stanwebber]

ignore koala's condescending comments as he is explaining something that wasn't even asked about merely to prop himself up. yes, there is a bug associated with the top-field checkbox in cce, but this would confuse the issue right now & it's nothing to worry about unless you are diehard to get your letterboxing on 16x16 macroblock boundaries. the top-field checkbox sets flags in the video stream to instruct the decoder on the order to display the fields, but does not impact the encoding algorithm in any significant way. (you can swap the fields manually in a video editor, but there's really no reason to do this). if it looks wrong on your pc that is no indication, you need to check it on a standalone player. in order to check on your pc you'd need to decode the stream & feed it to a video editor to seperate the fields(60fps). if by chance you do get the order wrong you can fix the video without re-encoding by demuxing & running it though pulldown.exe -nopulldown -tff [odd, even]. koala, all your posts are ******* useless sniping

#avisynth check field order example
AVISource("[...path...\VFAPIoutput.avi]") #or loadvfapiplugin
AssumeFrameBased( )
ComplementParity( ) #if it looks ok with this argument field order should be top-first
SeperateFields( )

[homerpez]

Man! You must all think I'm an imbecile! (The feeling is often mutual)...

All I'm talking about is when you have the problem in your standalone, you should encode again, but switching fields. With me so far?

OK. The problem at hand is that CCE doesn't appear to change the field order to "lower" by leaving the "Upper Field First" box unchecked.

My point is nothing more than IT ONLY APPEARS TO BE A FORCE SWITCH, NOT A TOGGLE.

What I mean is, if the source material is Bottom field first, uncheck the box and it stays that way in encoding. Check the box, and you force the upper field to be encoded first (for whatever reason). It works as a force to upper, rather than a toggle (ala TMPGEnc). So, if you wanted bottom field first in CCE, it might be a program bug that doesn't allow you to swich to that (the frameserve program needs to specify).

koala, koala, koala... you missed the only point I was making! Typical. Go do whatever it is people like you do on a Saturday.

FrankV, assuming you're frameserving... try specifying the field order to "Bottom First" (try the TMPGEnc --> VFAPI method) and then uncheck the CCE boxes... see what happens for you...

[KoalaBear]

yes, there is a big associated with the top-field checkbox in cce

What's a "big"?

but this would confuse the issue right now & it's nothing to worry about unless you are diehard to get your letterboxing on 16x16 macroblock boundaries.

Phrases like "letterboxing on 16x16 macroblock boundaries" only sound impressive when they're used in an appropriate context. Interlaced encoding unfortunately isn't one of them.

the checkbox in cce sets flags in the video stream to instruct the decoder on the order to display the fields, but does not impact the encoding algorithm in any significant way.

CLUE ALERT (your cue to pay attention, stanwebber. Don't miss out):

Field precedence is meaningless unless you're coding interlaced frames. Do you have any idea what this means? Unless and until you uncheck the little box labelled "Zigzag scanning," CCE doesn't care if the "Upper field first" box is checked or not.

koala, all your posts are ******* useless sniping

You must try harder, stanwebber. It is not easy to become something other than a fool.

--------------------------

Man! You must all think I'm an imbecile! (The feeling is often mutual)...

I don't think you're an imbecile, Homerpez, I think you've been struggling with the concept of interlacing for something like six months now and you just don't seem to get it. Part of the reason is that you don't want to learn about the concept in general, you want answers tailored to your particular question; part of the reason is that you tend to discard any answer if it's not what you want to hear.

This very thread is a perfect example. Watch:

OK. The problem at hand is that CCE doesn't appear to change the field order to "lower" by leaving the "Upper Field First" box unchecked. My point is nothing more than IT ONLY APPEARS TO BE A FORCE SWITCH, NOT A TOGGLE.

There are two explanations that can account for this:

(1) You're using inappropriate encoder settings.
(2) You're processing the video inappropriately prior to encoding.

If the problem is the encoder settings, that's an easy problem to fix. Just deselect everything except "Add sequence end code" and the "Upper field first" box will become a toggle that works the way you expect it to.

If the problem is inappropriate processing, nothing you check or uncheck on the encoder is going to fix the problem because the video is already compromised. You have to go back to square 1 and figure out what it is that you're doing wrong.

What say you in light of these two possibilities?

[stanwebber]

that is it you ******* petty little irritating shit. you just cant stop yourself can you? tell my how the cce bug that shifts the image 1 scanline when the top-field box is checked is not germain to the discussion when the topic is the top-field box & someone asked if a bug is associated with it? BTW, WHO SAID ANYTHING ABOUT ZIGZAG SCANNING IN THIS ENTIRE POST EXCEPT YOU? stick to the goddamn topic or shut the **** up. how has any of my information contradicted your's or impinged upon it in any way? you just cant ******* let anyone else be right to share the spotlight because you know & understand everything so much more intensly than us mere humans. you have to tear down anything, everything someone has to offer no matter what. i'd like to see 1 ******* post of yours where you dont have someone else quoted tearing them down. god, you must love that quote button. you wont be able to let this post go by unchallenged either. you simply dont have the self-control. i swear if this post gets past you unchallenged i will publicly declare i'm full of shit & never post another message on this forum EVER, NOT ******* EVER

[homerpez]

What say you in light of these two possibilities?

I say, without question, Baldrick will be notified.

[FranckV]

Wow, it seems my original post generated quite a few interesting points.

Anyway, here is what I found out encoding a 29.97 fps interlaced movie captured using a PCTV board at 640 x 480 resolution in VirtualDub.

CCE always creates the mpg video file (mpv) with the Top FIeld First flag set regardless of what the reality is.
If one does not check the "Upper Field First", then CCE leaves the field order as it is in the AVI file. If checked it reverses the field order.

So, before you encode using CCE, you have to know what the field order is (can easily be check by either using TMPGEnc and the preview of the Deinterlace Even-Odd field filter or in VirtualDub by using the Deinterlace Unfold Side by Side option and looking at which field moves first in the right window.

The above can easily be tested by coding a top field first avi file using CCE with Upper Field Firts checked and then use DVD2AVI to converte the file back to AVI = Field Order in new AVI is opposite of what it was in original AVI.

I do not think it really is a bug in CCE, I believe it is a misinterpretation of the function. The CCE guys should change the text in the dialog.


To be practical, if AVI file is Top Field First, then do not check the Upper Field Box in CCE and if it is Bottom Field First, then check the box.


Hope this helps other CCE user as it took me quite a while to figure this one out.

[KoalaBear]

i swear if this post gets past you unchallenged i will publicly declare i'm full of shit & never post another message on this forum EVER, NOT ******* EVER

If you "never post another message on this forum EVER," how can you "publicly declare [you're] full of shit" afterwards? CLUE ALERT: the offer automatically renegs itself. Pardon me if I decline.

tell my how the cce bug that shifts the image 1 scanline when the top-field box is checked is not germain to the discussion when the topic is the top-field box & someone asked if a bug is associated with it?

The question was "why checking the 'Upper field first' flag in CCE doesn't change the field order." The answer is that you have to be coding interlaced frames in order for that checkbox to have any effect.

The "cce bug that shifts the image 1 scanline when the top-field box is checked" is not germane to the discussion because it's something you pulled out of your ass along with the "letterboxing on 16x16 macroblock boundaries" nonsense.

BTW, WHO SAID ANYTHING ABOUT ZIGZAG SCANNING IN THIS ENTIRE POST EXCEPT YOU? stick to the goddamn topic or shut the **** up.

Once again, MPEG-2 has two ways of handling the macroblocks that form an image: zigzag scan (progressive), and alternate scan (interlaced). If you have "zigzag" scanning checked, the "Upper field first" flag is ignored because it has no meaning in the context of encoding a progressive macroblock.

Why is that simple fact so hard to understand?

================================

What say you in light of these two possibilities?

I say, without question, Baldrick will be notified.

Notified of what? Baldrick may be a busy man, but I'm sure he reads the forum himself.

[FranckV]

By the way, as the first sentence of my question stated, I am encoding a 29.97 fps interlaced video so I did not check the Zig Zag scanning order box.

[LavaJockey]

This interlaced/progressive stuff is easy to understand. The only difficult part is figuring out what each application does with respect to it.

I know about interlace and progressive input. What about the interlaced vs progresive output setting in CCE (or TMPGEnc)? What does that do?

My input video is interlaced, 480x480. When I select interlaced output in CCE (or TMPGEnc), my output MPEG2 file has streaks when I play it back to the television. There are no such streaks if I convert the MPEG file to AVI and play the AVI file. If I select progressive output, my MPEGs play back fine, no streaks.

So, what the hell does this setting do? Is it causing the decoder to do something funky?

[FranckV]

What do you mean by streaks ?

[LavaJockey]

The streaks are horizontal. They are more than a single pixel wide (these are not the comb-like effects one see when playing interlaced source on a progressive display). And they occur in areas of high-motion.

The streaks are very apparent when the MPEG2 file is paused. Yet if I convert the MPEG2 to AVI, play that back, and pause it, there are no streaks in the exact same frames. So, the effect must be coming from something the encoder is doing.

So what does the progressive/interlaced output option (in CCE, or TMPGEnc)? Does it simply set a bit in the MPEG2 file which caused MPEG decoders to do something based on that setting?

[m204310]

I had the same problem with CCE 2.50 encoding an interlaced NTSC 29.97 fps video source into MPEG2. Changing the field order doesn't change the reported field order in the bitrate viewer. However, the order does change (it's just not reported right). I suggest you to encode a very small portion of your video, burn it ot a CD-RW and to test it on your standalone player. If it's jumpy on your TV, just change the field order in CCE. Don't rely on the bitrate viewer, trust your own eyes.

[Vulcan]

I encode PAL DV streams with CCE. I have been told that PAL DV is always lower fields first and that it should be encoded with that setting. I'm still not satisfied with my CCE encodes and it might be that some of my problems is due to a "low performing" system (I'll get a new "high end" machine delivered Tuesday) and not field order.

However, in my experience interlaced streams encoded with CCE is always reported to be Top Field first regardsless of whether the Upper Field check box is checked or not. I get the best result if I leave the box unchecked and then have the encoded stream run thru "EasyChanger" (a small program that can change certain settings without re-encoding). Hope this helps.

[FranckV]

CCE always encodes with the TOP FIELD FIRST flag in the Mpeg stream so:

- if the source is Top Field First (like VHS in most of the case), then do not check the upper field first box in CCE

- if the source is Bottom Field First (like DV in most case), then since CCE sets the Top Field Flag you have to check the Upper Field First box in CCE, this will invert the field order.

To check the field order, you do not need to burn a small portion on a CD.

Take the original AVI, open in TMPGEnc, Select Top Field First in the advance settings, open the deinterlace filter, select the Even-Odd option, play the movie by holding the mouse down on the slider, in you selected the wrong field order, you will see it is quite obvious (make sure you check the Enable Filter box).

[piper180]

Frank, I tried that, and I still got the flutter in high motion video when played back on a set top dvd player. However the same video that was rendered in slow motion at 50% did not flutter. What am I doing wrong?

[FranckV]

I wish I knew !

How about the bitrate, when encoding in CCE (VBR 3 passes), I use:
Avg: 2000, Min: 300, Max 2498
Sound set at 224 kb/s Stereo.

Because 2498 + 224 = 2722 total and SVCD requires 2723 max.

You can check the nominal bitrate and the max, min, avg using bitrate viewer (available in the tools section of this site.

Some DVD player require lower bitrate that standard for SVCD.

So first, let's check the bitrate settings you are using.

[piper180]

I am encoding for dvd and my bitrates are high. 9000 max 8000 ave. and 4000 min. My video's are usually high motion (athletic events). My guess is that with 50% speed, the fields are identical, so it doesn't matter what field is first. I am frustrated because I think I am very close to understanding the whole encoding concept, but I am obviously missing something.