DVD2SVCD 1.1.0 B1: Problem with interlaced PAL

[Deltis]

Hi everyone!

I'm testing the new DVD2SVCD 1.1.0 build 1 at the moment and I've encountered the following problem (Windows XP with CCE 2.50.01.00 set to "Automatic" field-order):

After having encoded Buffy (interlaced PAL) with the new "Keep interlaced" and "Interlaced Resizing" options I get a MPEG-file with an apparently wrong field-order. The SVCD shows stuttering motion during interlaced scenes which can be clearly identified by looking at the MPV-file by the help of a field-separated AVS-file on a 50 fps-field-basis and VirtualDub.

Unfortunately Buffy seems to be a bad NTSC->PAL conversion. Therefore a telecide-process is not an option :(

The AVS-file seems to have the field-order right (checked with VirtualDub).

The mentioned problem does not occur with the older 1.0.9 build 3 (including the older avisynth-version) and my own "interlaced resizing/filtering"-script (tested on the same movie-scene as above):

----------------------------------------------------------------------
[...]
---AVS Begin---
LoadPlugin("C:\PROGRA~1\DVD2SVCD\MPEG2Dec\mpeg2dec.dll")
Buffy=mpeg2source("E:\SVCD\DVD\DVD2AV~1.D2V").SeparateFields()
Even=Buffy.SelectEven().BicubicResize(480,288,0,0.5)
Odd=Buffy.SelectOdd().BicubicResize(480,288,0,0.5)
Interleave(Even,Odd).Weave
ResampleAudio(44100)
----AVS End----
[...]
----------------------------------------------------------------------

After some testing I think that it may be related to the new AVISYNTH.DLL bundled with DVD2SVCD 1.1.0 build1 :confused:

-> Perhaps a general bug within the new AVISYNTH-version?
-> Perhaps a problem in the frame-serving section of the new avisynth-version (and appearing just in combination with CCE 2.50?)?
-> Perhaps a problem related to Windows XP in combination with the new avisynth-version?

-> Does anyone have the same experience/problem?

[EDIT] Avisynth doesn't seem to be the problem (see posting below) :(

Please post your solutions and/or comments :cool:
Thanks!
Thomas

[ux-3]

Two things that may help - test on an obviewouosly bugged chapter:

Turn field order to B and do not use interlaced resize if its full screen anyway. I do PAL TNG and use Field B & bicubic 0/0.65.

Just check it out. Did you recover this encode by any chance?

[Deltis]

Hi ux-3

Thanks for your help. I tried some of your ideas...

1. I encoded everything from the very beginning.
2. I changed from "Automatic" to "Top" and "Bottom
3. I did't change resizing, as my AVS-file handles the field-order right and I need resizing for a standard SVCD ;)
4. I used different avisynth-versions (1.05 and 2.06; properly installed and rebootet)

My results are:

Add 1. No difference between recovery-encodings and from the beginning ones

Add 2. No changes in the behaviour of CCE and the encoding result no matter what I choose. CCE always writes TFF (as other mails already stated in this forum). How does DVD2SVCD handle TFF- and BFF-flags in combination with the "Field order"-setting?

Add 3. :)

Add 4. Unfortunately no change. I first thought it is the avisynth-installation. But perhaps I'm missing something here :confused:

5. I found out, that DVD2SVCD 1.1.0 b1 is just changing CCE-settings from "progressive" to "interlaced" but does not change "zigzag" to "alternate" when you select "Keep interlaced"!

Anybody else with the same problems (and perhaps a solution)?
Thanks!
Deltis

PS: I'm not the only one -> http://forum.doom9.org/showthread.php?s=&threadid=37719

[Deltis]

Hi dvd2svcd!

This whole day I tried everyhing to solve the mystery - without success :(

Fact is: DVD2SVCD 1.0.9 b3 does everything as it should be!

When I use DVD2SVCD 1.1.0 b1, the field order seems to be swapped:

-> When I use SeparateFields() in combination with the encoded MPV-file and have a look at it with VirtualDub, it shows the typical "one-step-back -> two-step-forward -> one-step-back" motion.

-> Using ReStream to deactivate the TFF-flag solves the problem of shaky motion but does not explain the reason for it (as the source is TFF and DVD2SVCD 1.0.9 b3 produces working TFF, too).

Perhaps you are able to solve this - with your knowledge of internals ;)

Thanks!
deltis

PS: I did an experiment -> I copied the new DVD2SVCD 1.1.0-EXE- and -INI-File into the DVD2SVCD 1.0.9-folder and run a complete transcoding-session. The result - shaky motion! :confused:

[Deltis]

@dvd2svcd
After a whole day of testing I know more:

The fields are not shifted. Avisynth doesn't produce the problem. It seems to be a rather "old" and known problem:

When DVD2SVCD 1.1.0 b1 is set to "Automatic" field-order it configures CCE with "Upper Field First" activated (in ECL-file) -> this is wrong (according to several posts in the forum). My source is TFF -> therefore "Upper Field First" must be deactivated.

Explanation: CCE always(!) sets the TFF-flag in it's encoded video-streams. To encode a BFF-source correctly it shifts the whole frame/fields of the input-(BFF-)video up one line. This seems to be activated by the CCE-switch "Upper Field First" :scared:

To sum it up: The "UFF"-switch should be renamed to "Edit the input-video to enable TFF-encoding with a BFF-source" :D

DVD2SVCD 1.0.9 b3 handles this situation correctly when set to "Automatic" -> it deselects the "UFF"-switch within CCE.

@ux-3:
When I checked the three possibilities "Automatic/TFF/BFF" during my tests within the DVD2SVCD 1.1.0b1-GUI I didn't burn a SVCD of every complete run. I just checked the MPEG-files by looking at the field-flag with BitrateViewer. I didn't know that CCE only encodes TFF and uses a IMHO really bad method of handling BFF-sources.
This resulted in a wrong conclusion and a lot more test-sessions ;)