Can CCE encode top field first interlaced video?

[atreides93]

Right now I have to use TMPGenc for interlaced video, while I can use CCE for progressive stuff.
The reason is, CCE 2.50 didn't encode an interlaced DVD I had which was top field first even though I had top field checked on it. The result was jerky video on playback in a standalone player.

I encoded the same thing in TMPEG and it works fine.

But I'd really like to use CCE instead for interlaced...just don't understand why it doesn't work right.

[69Mws]

as far as i know cce encodes always upper first, no matter what you check....so it was told to me regarding to version 2.66.01.07....

Further on i think you have to use the setting "Alternate" instead of "ZigZag Scanning Order" for interlaced material.

Don't know if this is all correct what i wrote, because i don't belong to the mega-professinals here :)

[smoof]

Interlaced can be tricky in CCE due to the top field first bug in CCE. However, you can still use CCE and change the field order using pulldown. (ex: pulldown src.mpv dst.mpv -nopulldown -tff even).

Whenever I do a interlaced material with CCE, I always make a test clip on a DVD-RW and try it on the standalone so I can verify that it is playing smoothly.

[atreides93]

thanks for the suggestions.
I think i'll just stick to using tmpegenc for interlaced stuff and avoid the hassle!!

[Tsui]

for tff-source :
deactivate 'upper field first'
deactivate 'progressive frames'
deactivate 'zigzag scanning order'

for bff-source :
deactivate 'upper field first'
deactivate 'progressive frames'
deactivate 'zigzag scanning order'
correct the field-order flag with darims easy changer or pulldown.exe or restream

for progressive-source :
deactivate 'upper field first'
activate 'progressive frames'
activate 'zigzag scanning order'

there is no field-order bug in the cce, it only handles it different than you think (no joke).

[atreides93]

Thanks. I'm going to try that with CCE next time I get some interlaced video.

[atreides93]

Tsui,
Thanks for your suggestions. I tried it with a top field interlaced movie and the results were perfect!! I used CCE 2.50

[Ntsita]

Originally posted by Tsui
for tff-source :
deactivate 'upper field first'
deactivate 'progressive frames'
deactivate 'zigzag scanning order'

for bff-source :
deactivate 'upper field first'
deactivate 'progressive frames'
deactivate 'zigzag scanning order'
correct the field-order flag with darims easy changer or pulldown.exe or restream

for progressive-source :
deactivate 'upper field first'
activate 'progressive frames'
activate 'zigzag scanning order'

there is no field-order bug in the cce, it only handles it different than you think (no joke).

synthesis with interlaced video for CCE:
deactivate 'progressive frames' (in any case)
deactivate 'zigzag scanning order' (in any case)
deactivate 'upper field first' -for tff-source
activate 'upper field first' -for bff-source

No need to correct any field-order flag with other program.
CCE means 'upper field first' flag therefore:
-flag unselected (for tff): no swap field, set only the flag tff in video encoded (for compatibility with standard format DVD or old DVD player, one of the two, i don't remember)
-flag selected (for bff): swap field and set the flag tff in video encoded (for reason above)
However the tff flag will be set on video encoded by CCE.
I use it a lot and never had any problem.

[SomeJoe]

How can any program actually swap the display order of fields and get a correct result? All fields are both spatially and temporally different.

For instance, say I capture and encode an NTSC DV source. DV is lower/bottom field first, temporally. (Meaning that the bottom field was actually recorded 1/60th of a second before the top field).

The correct way to encode this is to store the upper and lower fields in the MPEG stream, and clear the top field first flag for that frame. Thus the MPEG-2 playback device will decode the frame, see that TFF=0, and should then first convert the bottom field to analog and display it in the bottom field of the display device. Following this, it would convert the top field to analog and display it in the top field of the display device.

CCE seems to assume that reversing the stored order of the field data and then setting the TFF flag to 1 is equivalent. But how can this be?

This would mean that the MPEG-2 playback device would decode the frame, see that TFF=1, and would then convert the top field data to analog and display it in the top field of the display device. This is temporally correct, as the now-swapped data in the top field of the MPEG-2 frame was indeed captured first, but this data was originally captured out of the bottom field, and is now being displayed in the top field of the display. The two fields will be displayed spatially incorrectly, as if every two lines of the frame were swapped top for bottom.

The crux of the matter is that the MPEG-2 to analog conversion process has no facility for flagging whether the data from the first encoded field of a frame is supposed to be displayed in the top field or the bottom field of the display device. The analog conversion must simply assume that the first encoded field of the frame is supposed to be displayed in the top field, and the second in the bottom. The TFF flag can control the temporal order, but not the spatial order.

Please correct me here if there is something I have missed ... technical data on the MPEG-2 playback process is somewhat slim.

[Ntsita]

I Remember you that CCE creates another file and don't change the input file.
Therefore it can manipulate the output video as it wants.
CCE don't only know if input interlaced file is tff or bff (as old tmpgenc version).
It's up to you indicate this (selecting or not the 'Upper field first' flag).
(said in other words):p