Field Order Encoder Output (can anyone else verify?)

[DJRumpy]

I had a PM sent to me with questions regarding field order. During the course of our conversation, I was asked to do some tests to determine the output types (regarding field order) of CCE. As a comparison, I also looked at the output of TMPgenc.

For the test, I used AVISynth, CCE version 2.67, and TMPGenc Plus version 2.56. The contents of the avi were generated by the VERSION command in AVISynth (basically it displays 10 seconds of the version information of AVISynth). I used the SwapFields command to change the field order of the input, and generated two mpeg clips from each encoder. One with top field, and the other with bottom field first.

Here is the script that was used:

version()
#swapfields()
BicubicResize(480,480)

The swapfields line was commented (# added) to create the top field first mpeg's, and then the # was removed (uncommented) to create the bottom field first mpegs.

The results are rather bizarre.

CCE, regardless of input type, and field order setting, would output a top field first MPEG. This was the case when the input type was top or bottom, or when the setting in the advanced section was set to top or bottom.

TMPGenc would properly detect the AVISynth AVS as top field or bottom field, but all content generated by TMPGenc appeared to be bottom field first, also regardless of setting.

Results were verified with Bitrate Viewer 1.5.054

Can someone else verify these results? The clips take only a few seconds to encode (it is only 10 seconds after all). 8)

[wwaag]

dj

I use CCE Basic and have observed the same thing--always reported as top field first.

I just encoded 2 short clips--one with offset line=1 (presumably, bottom first) and one with offset line=0 (top field first).

Using both Bitrate Viewer and Restream, they both indicate top field first. regardless of the offset line setting.

Perhaps CCE ALWAYS writes "top field first to the header" regardless. I know that for 2-pass VBR encoding it always writes 9800 as the bitrate, regardless of the actual bit rate, which causes problems for some apps.

I also looked at the output of the two encodes using a DirectShow out to a TV monitor and could tell no difference in quality. Confusing at best.

wwaag

[vhelp]

TGIF all..

@ DJ..

How about another test ??

Do TWO test clips like this:

* forget the AVS script alltogether, then..
* open your source inside TMPG directly (or frameserve from vdub)
* set test 1 w/ topField and test 2 w/ botField
* save as .TPR (project file)
* now, out of these .TPR files (each) create an psuedo .avi file, and..
* frameserve each test clip (one project each) and note the difference

Does any version of CCE matter, as I have the much older version for testing purposes still laying around somewheres, though I don't use it at
all other than for testing things out cause TMPG is my prefered encoder :P
.
.
if you have a DV cam, perhaps you can do some further extensive testing
(from a DV point of view (POV)) maybe

See what you get from this.. otherwise, any other suggestion, and i'm all ears

Enjoy the weekend all,
-vhelp

[FOO]

DJ,
I remember reading over a year ago about CCE settings
being peculiar.
First was that the field setting did nothing, either way
and then it toggled what was. It was on Doom9.
They had an explanation but I can't remember it.

There was a test also , like yours but they always
added a "assume top field first" statement or the opposite.

Also note that top and bottom is an opinion. If a capture device
get fields, the order is indistuguishable unless they record
the even/odd signal from the sync separator correctly.
That is, some store the bottom first in the stream , and others
don't . Apparently DV comes Bottom first and you have to know it
and tell the encoder.


Here is a script to make things obvious



frate = 30
time = 100

frames = frate * time

x = 100
y = 100

BlankClip(length=frames, width=720, height=480, fps=frate, color=$000000) # Generate blank clip
ShowFrameNumber() # with frame number

SeparateFields()

top = SelectOdd() # top fields
bot = SelectEven() # bottom fields

top = Subtitle(top, "TOP_FIELD",x, 100, 0, frames-1,"arial", 64, $800000, $0, 1,0) # Label top fields

bot = Subtitle(bot, "BOTTOM_FIELD",x, 100, 0, frames-1,"arial", 64, $008000, $0, 1,0) # label bottom fields

# stackvertical( top , bot )

Interleave(top,bot) # Mix fields

weave( ) # de-interlace


That didn't answer the question but I will encode some and see.
later

[adam]

DjRumpy I think I know why you got those strange results. Version produces a 24fps progressive video. You have to add the separate fields command in order to make it field based.

As for CCE, the CCE faq on Doom9 sums it up quite well.

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.

[FOO]

Adam you're my hero
That's exactly the text i was referring to .
I have CRS
(can't remember shit)

[DJRumpy]

vhelp, I use AVISynth because with it, I can generate a known upper field first, or lower field first. In this case, there was no 'source' file. It was generated on the fly by AVISynth using the Version() command. This output was then resized to a standard frame size (480x480 in this case), and then dropped onto the encoder.

By using the Version() command, the swapped fields are immediately obvious. Give it a try

Did anyone test the output from TMPGenc?

[ronnylov]

The field order flag in the output of tmpgenc depends on what you set it to. If you set top field first (advanced tab and field order) on your output then it will be flagged as top field first or vice versa. You have to set it correctly to the same as your source otherwise you'll get jumpy playback on TV.

To switch field order from bottom field first to top field first (or vice versa)in avisynth you can use following script:

DoubleWeave().SelectOdd()

If you have got it wrong you can change the field order flag in your video stream without reencodingn by using ReStream or Darim easychanger (a tool included in the demo of Darim DVMPEG)

When encoding with CCE I recommend always disable the top field first option in CCE and feed it with top field first video only (change field order with avisynth if needed) or change the flag afterwards with Restream if needed.

(Swapfields in avisynth does not change the field order, it only swap upper and lower filed in the current frame, but you want to take the upper field from prevoius frame and combine with lower field of current frame to switch from lower field first to upper field first)

[DJRumpy]

ronnylov, you must not have read the post.

[ronnylov]

ronnylov, you must not have read the post.

Which post have I not read?