Really need some help on this weird interlaced issue

[waldok]

Hi all,

I've been making a reasonable amount of SVCDs thanks to the great DVD2SVCD.
Now I decided to give my old analog 8mm tapes a go and convert them to SVCD as well. Until DVD2SVCD provides AVI to SVCD conversion, I decided to use Ulead DVD Movie Factory.
I captured using MJPEG codec, system is PAL, captured to AVI 480x576.

OK, now to the problem : whatever field order I select when encoding to SVCD compliant MPEG, playback is always "choppy" in moving scenes on my Tokai (Raite, Yamakawa) standalone player.
If I select Ulead Frame mode (i.e deinterlace), everything is ok, but I find the picture to be a bit too "blurry" for my taste.

I don't understand this issue. How can both field order be wrong and exhibit the same well known "wrong field order" artefacts ?

I decided to try CCE as well and the results were the same.
I probably do wrong or misunderstand something here so I'd like some PAL expert to explain me what I should use as parameters.
By the way, it also happened when using DVD2SVCD on some particular DVDs (usually music clips or concerts, and also one specific movie called 'Ring').

ANy help will be more than appreciated cause I don't want to deinterlace on my old analog tapes !

thanx a lot for your help (and sorry if it has been asked before)

Waldok.:confused:

[PoKKeNoiSe]

Try VirtualDub you can open the captured avi with it(if the codec allows it, otherwise use another one to capture) Then you can add filters (deinterlaced, dynamic noise reduction, etc) For Deinterlaced use the "Blend Fields Together"option. If you must resize use the "Precise Bicubic (A=-1.00)" filter mode that gives the best quality/resize. Then select a codec and save the avi, process it with CCE and a perfect mpeg (it worked for me on my standalone)

ps. You also can capture with VirtualDub if your capture card allows it.

[waldok]

Well thank you for your answer, but maybe I was not clear in my explanation. My problem is not to obtain a good SVCD in deinterlaced mode (which I already have), but rather to obtain a good SVCD in interlaced mode. SVCD standard fully supports interlacing, so I'd rather not spend time deinterlacing my source (and thereby lose quality) but...

My problem is that no field order seems to work for me, be it Upper field first or lower field first, both give a SVCD that exhibits commonly known 'jumpy' artefacts on moving scenes.

THank you Pokkenoise for trying to help (and I mean it).

Any other idea from some 'non-deinterlacer' guy ?

Waldok

[PoKKeNoiSe]

Your welcome! ;)

For PAL/25fps you must use 12 Gop frames (instead of the standard in CCE of 15 gops (for NTSC/29,97fps))

For Pal set the gop to M=3, N/M=4 and a SEQ header every 1 gop(s).

I think this should do the trick, because everything else seems good to me.


good luck!

[mb1]

Uuhhh, PoKKeNoiSe, it hurts to read your answers.

For supported CCE GOP settings:
For NTSC max. GOP 12
and for PAL max. GOP 15 ...

The problem has nothing to do with the GOPs.

It´s a field order problem.
CCE has a field order bug with certain mpeg2 codecs in the system.
Then it will always encode "top field first" no matter if you select or deselect this option.

You can check that with bitrateviewer
http://www.tecoltd.com/bitratev.htm

If you have this cce field order bug you can quickly change field order without reencoding.
The tool is called "Easy Changer" from Darim (can be found in full version of DVMPEG, not in demo).
If you can´t find it, i´ll send it (only some KB).
Leave your mail cos board-email doesn´t support files.

And waldok, for your material, tmpeg with some tuning filters maybe would do a better job than relatively static cce (and of course without the field order bug ;)).

[waldok]

Thanks a lot for this information. I really appreciate it !

My only problem with TmpgEnc is...speed. It takes way too long on my poor Celeron 566@850 !

MB1, it's funny cause I came across your site while searching for Darim Easy Changer. Your site looks great but looks a bit too..german for my understanding, Ich verstehe nicht alles, gibt es kein Englisches version ? oder muss ich zu BabelFish gehen ?) :D

Ok, anyway here is my email waldok@hotmail.com, since I couldn't find the Darim tool by myself (shame on me). Would you send to send it to me please ?

I really can't wait to try this and see if it solves my case !
(Oddly enough, I have the same field order problem when encoding with Ulead DVD Movie Studio, based on the Ligos LSX 3.5, so go figure...).

ANyway, thanks a lot guys for your answers, I'll let you know if things get any better (I'll probably try this tomorrow evening).

I can't tell you how much your help is appreciated :)

Waldok.

[Ruben]

Hi
I can not find this tool.
Please send it to me.
I have the same problem !

mail: L.Ruben@web.de

Thanks
Ruben

[Mozart]

from pulldown.exe readme file (thanks kedirekin to show me this):

To change the field order to odd on a stream that you accidentally encoded as even:

pulldown.exe source.m2v target.m2v -nopulldown -tff odd

I don't know if this will work, but worth a try. Pulldown.exe is freeware;) Please, give me some feedback.

[waldok]

THanx Mozart,

I'll give this a try too and I'll let you know what it does on my PAL files.

Waldok.

[mb1]

Works, but of course you have to demux your mpg first ...

[24hourloop]

Originally posted by mb1
Uuhhh, PoKKeNoiSe, it hurts to read your answers.

For supported CCE GOP settings:
For NTSC max. GOP 12
and for PAL max. GOP 15 ...

The problem has nothing to do with the GOPs.

It´s a field order problem.
CCE has a field order bug with certain mpeg2 codecs in the system.
Then it will always encode "top field first" no matter if you select or deselect this option.

You can check that with bitrateviewer
http://www.tecoltd.com/bitratev.htm

If you have this cce field order bug you can quickly change field order without reencoding.
The tool is called "Easy Changer" from Darim (can be found in full version of DVMPEG, not in demo).
If you can´t find it, i´ll send it (only some KB).
Leave your mail cos board-email doesn´t support files.

And waldok, for your material, tmpeg with some tuning filters maybe would do a better job than relatively static cce (and of course without the field order bug ;)).

The problem you see is not field-order related. The flag can be toggled with 'MPEG fixer' (free from Darim Vision and you can verify it works with Bitrate Viewer). The results are the same. The problem is related to the fact that the liens from the input file (the fields) must be positioned in the exact same location in the output file (i.e. there can't be any stretching or otherwise modification of the output). You are already pushing it when you resize the width from 720 to 480 as this throws the timing slightly off but *any* form of resize in the height, even a single pixel, is going to destroy your picture. The method generally chosen is deinterlacing to get around this.

This is for those that eventually give up.n I have spent countless days getting this to work with interlacing and have outlined the *only* working method I have discovered elsewhere in these halls:

a.) Use Premiere. I have been unable to make this work properly even using full LSX under MSP.
b.) Place your clips and do not do any resizing or any other modifications that might cause deinterlacing (obviously flying your clip around the screen will have to deinterlace it, certain filters do, transitions etc.).
c.) Use the Premiere Export filter (Video server).
d.) Fire up TMPGEnc and use the full NTSC template (I assume you are NTSC). Do not use the 704*480 one as this again will screw up your fields. There must be a one-to-one translation of the fields.
e.) Run.

This is the only way I have found to make it work in high quality, without deinterlacing, after days of changing field orders, encoders, formats - you name it. I have scoured newsgroup to no end only to find that hardly anybody knows how to do this right. Everybody winds up deinterlacing it without even knowing it.

Things to keep in mind:

a.) Know what your fielfd order is when capturing. Generally the capturing program will tell you or let you chose. When in doubt - use the good ol' TMPGEnc method with the Deinterlacing preview to find out what it is.
b.) When you pump your data through some kind of pre-processing (I used Dynapel's Motionperfect) make sure your field order stays the same.
c.) Specify the right field order on 'Keyframe Processing' in Premiere when exporting.
d.) Make sure you have the right setting in TMPGenc.

(I'd probably ought to write a guide on this and stick it somewhere because there definitely is none to be found that is accurate).

[24hourloop]

Originally posted by Mozart
from pulldown.exe readme file (thanks kedirekin to show me this):



I don't know if this will work, but worth a try. Pulldown.exe is freeware;) Please, give me some feedback.

Don't use Pulldown for this. Go here: http://www.darvision.com/download/mpegenc.html and download DVMPEG 6.0. It includes a nifty tool called MPEG fixer. It will allow you to change a few things in the MPEG file that are otherwise hard to modify such tas the TFF (Top Field First) flag.

MPEG Fixer has no restrictions and will not expire.

[Mozart]

Originally posted by 24hourloop

Don't use Pulldown for this. Go here: http://www.darvision.com/download/mpegenc.html and download DVMPEG 6.0. It includes a nifty tool called MPEG fixer. It will allow you to change a few things in the MPEG file that are otherwise hard to modify such tas the TFF (Top Field First) flag.

MPEG Fixer has no restrictions and will not expire.

hummm... it seems that (a) you don't like freewares, (b) you don't like command line tools, (c) you love to fill up a registration board just to get a small piece of a unusefull demo version. Well, this can be your business, but doesn't need to be our business.

[PoKKeNoiSe]

Originally posted by mb1
Uuhhh, PoKKeNoiSe, it hurts to read your answers.

For supported CCE GOP settings:
For NTSC max. GOP 12 30fps / 2 = 15 gop
and for PAL max. GOP 15 ...25fps / 2 = 12,5 becomes 12 gop

This seems more realistic too me, I know for certain that PAL = 12 gops and NTSC = 15 gop, this is how i can simply explain as far as i know, because gop is attachted to frames(gop is sort of code for frames(sort of order, i heard/readed)

and a lot more

Here it hurts too! ;-)

I have never heard of that CCE problem so that i didn't now, for me it seemed logical that the gop was/is wrong.

Tonight i will try to make myself a capture (interlaced) and with the good gop, i have one with the wrong gop and that one only playes good on a computer.

[waldok]

24hloop : I don't use any resize of any kind, since I capture in 480x576 AVI (PAL standard).
So there should be no "field mismatch' in the process until the MPEG2 encoding starts.

Or am I wrong ?

Waldok.

[mb1]

@waldok
you will get better quality if you capture with full resolution (768x576) and then do correct (interlaced) resizing to 480x576.

Correct interlaced resizing means to separate the fields (f.e. 768x288, 50fps), then resize and then combine the fields together again.
Then there is no problem at all with resizing.

part of a avs-script would be like that:

AssumeFrameBased.SeparateFields
BicubicResize(insert all your values ;)).Weave

That´s correct interlaced resizing. Tmpeg and Virtual Dub support also correct interlaced resizing. So this is not a real problem ...

waldok, did you try now changing field order ?

[mb1]

@PoKKeNoiSe

30fps / 2 = 15 gop
25fps / 2 = 12,5 becomes 12 gop

:eek: :eek: :eek: :eek: :eek: :eek:

Do you know what GOP is and what it stands for ? Surely not !

Read cce´s documentation on it or better some faq in the net ...


Don´t hurt me more as I´m going to die ;)

[waldok]

@Poke
Yep, Poke, GOP stands for Group of Pictures in the MPEG standard. It defines a combination of pictures between (I)ntra, (P)redicted and (B)ilinear.

Gop defines a sequence of these different kinds of picture, defining how pictures will be encoded.
'I' pictures are encoded as 'standalone', without any reference to previous or following picture in the incoming video stream (more or less JPEG-like), P are predicted from previous 'I' image in the incoming video stream and bilinear are calculated from both a previous I or P picture and from the next I or P image (that's why you have to decode a full GOP before being able to reconstruct all the pictures inside this Gop).

So there is no relation of any sort between the video standard you use (PAL or NTSC) and the structure of the GOPS in the MPEG file.
You could either have IIIIIII in a GOP, or IPPIPPIPP... or IBPBPBPBP or IBBPBBPBBP or any other kind of combination, no matter what the source is.

These were my 2 cents about MPEG encoding.

I certainly don't mean to play the teacher here at all, this is just for information. Correct me if I'm wrong !

@MB1

I tried using the Darim tool to invert fields without success. Same results. I checked with Bitrate Viewer on the original and the "field reverted' file, and it reported first file being upper field first and second file being lower field first.
So one of them should play fine...
Still, both play incorrectly on the player. :confused:

More and more confusing...


I had an idea, maybe it's the MJPEG codec that I use at capturing time, since there is an option about separating fields if there are more than 240 lines in the picture.
I'll try capturing to uncompressed AVI and see if it makes any difference.

In the meantime, please Heeeeeeeeeeeeeeeeeeeeeeelp
:rolleyes:

Waldok.D

[PoKKeNoiSe]

GOP Group Of Pictures:

In an MPEG signal the GOP is a group of pictures or frames between successive I-frames, the others being P and/or B-frames. In the widest application, television transmission, the GOP is typically from 12 frames in a 25 fps signal and 15 frames in a 30 fps signal (ie about half a second) but this can vary - a new sequence starting with an I-frame may be forced if there is a big change at the input, such as a cut.

The length of a GOP represents the editability of that MPEG signal. Additional processing, possibly requiring an MPEG decode/recode, will be needed to successfully cut within a GOP. This is one of the reasons that MPEG is not generally regarded as editable (see Cut edit) - some work is being done on this subject.

Inter-frame (compression):

Compression that involves more than one frame. Inter-frame compression compares consecutive frames to remove common elements and arrive at "difference" information. MPEG-2 uses two types of inter-frame processed pictures - the 'P' (predictive) and 'B' (bi-directional) frames. As 'B' and 'P' frames are not complete in themselves, but relate to other adjacent frames, they cannot be edited independently. I-frames Contain data to construct a whole picture as their compression is intra-frame, very similar to JPEG.

B-frames:

Bi-directional predictive frames composed by assessing the difference between the previous and the next frames in a television picture sequence. As they contain only predictive information they do not make up a complete picture and so have the advantage of taking up much less data than the I-frames. However, to see that original picture requires a whole sequence of MPEG frames to be decoded which must include an I-frame.

P-frames:

Used from Main Profile upwards, these contain only predictive information (not a whole picture) generated by looking at the difference between the present frame and the previous one. As with B-frames they hold less data than I- frames and a whole GOP must be decoded to see the picture.


quoted it from this site : Extract from, The Digital Fact Book, published by Quantel (http://www.365broadcast.com/dtv_resources/factbook.htm)

I hope you believe it now!

[waldok]

Yes,

"In the widest application, television transmission, the GOP is typically from 12 frames in a 25 fps signal and 15 frames in a 30 fps signal (ie about half a second)...but this can vary

There is no information of any sort anywhere in the MPEG standard that forces Gops to be half a second. It is just a commonly used pattern, quite convenient for editing accuracy needs.
But, but, but, no decoder or encoder should ever assume that GOPs are 12 frames long in PAL and 25 frames long in NTSC.
So it shouldn't be the cause of a problem like mine, unless encoders/decoders are not really MPEG compliant (but, hey, you never know what's inside these little proggies...)

Anyway, I think this thread is really nice, confronting opinions is OK and I hope you don't take my arguments bad. Of course no offense intended, just sharing thoughts and trying to find a solution.

By the way, my explanations about I, B P frames were directly from my head, so forgive me if there were some mistakes and thanks for bringing out some more 'official' text :)

Waldok:cool:

[PoKKeNoiSe]

Originally posted by waldok
Yes,

Anyway, I think this thread is really nice, confronting opinions is OK and I hope you don't take my arguments bad. Of course no offense intended, just sharing thoughts and trying to find a solution.


Same here :), I would like to know if i'm wrong so i can do it good from that moment on.


By the way, my explanations about I, B P frames were directly from my head, so forgive me if there were some mistakes and thanks for bringing out some more 'official' text :)

Waldok:cool:

your welcome!

[24hourloop]

Originally posted by Mozart


hummm... it seems that (a) you don't like freewares, (b) you don't like command line tools, (c) you love to fill up a registration board just to get a small piece of a unusefull demo version. Well, this can be your business, but doesn't need to be our business.

a.) MPEG Fixer is freeware
b.) I don't necessarily like command line tools

So you know what it *our* business?

Gee, get a life.

BTW, MPEG fixer is a lot faster than two pulldown passes.

But I am sure you don't like that easier but prefer to flame.

I am afraid you will find poeple like you everywhere. You are the first guy I have run into on this board (which I have been on for longer than you can count but I had to switch names when the board switched) that lacks etiquette.

[24hourloop]

Originally posted by waldok
24hloop : I don't use any resize of any kind, since I capture in 480x576 AVI (PAL standard).
So there should be no "field mismatch' in the process until the MPEG2 encoding starts.

Or am I wrong ?

Waldok.

No, you are not wrong. I was under the impression you captured at 720x480 (720x576). My mistake.

[24hourloop]

GOPs are completely unrelated to fields. Wether you have x or y GOPs (within allowed constraints) your fields should be ok.

What you wrote about the deinterlacing setting during your capture sounds to me that you might be onto something.

Have you tried TMPGenc and specifying under 'Advanced Settings' that the source is non-interlaced?

[waldok]

Hi 24hloop,

There might be some issue around this "separate fields" stuff in Ulead DVD movie factory. I didn't try to play with it yet (no time !).

In the meantime, I tried capturing to uncompressed AVI, but results are the same,
Damn, this is really getting on my nerves. I can't understand this. How can both movies be wrong when one is top field first and second is bottom field first ????
I really can't understand this.
You know, the strangest thing is that this also happened once when using DVD2SVCD to convert the movie 'Ring', where I finally had to deinterlace (whining...).

I would really appreciate any idea you (or others) might have about this issue.

After all, I have a interlaced source, I just want to make a SVCD out of it, this should not be that complicated !
:rolleyes:

Waldok.

[Kedirekin]

Perhaps the source footage has changing field order. This is fairly common with anime (like ~5% of titles), and I'm sure it's not unheard of elsewhere. In my opinion, changing field order is perhaps the hardest single problem to deal with.

If I were you, I'd load the source into TMPG and perform the field order test using the deinterlace window. If preview is choppy with both field orders, your source is probably swapping field order (for whatever reason) and you may have no choice but to deinterlace it.

[24hourloop]

Originally posted by waldok
Hi 24hloop,

How can both movies be wrong when one is top field first and second is bottom field first ????

Waldok.

The most obvious thing that comes to my mind is that somehow you get some sort of resizing. I know you already told me you didn't. When you take your captured movie, don't use any editor and feed it straight into TMPGenc - do you still see this problem?

Have you played with the different source aspect ratio settings under 'Advanced'? That's pretty much the last idea I have on the matter...

[waldok]

Well, thanks for helping :)

Concerning resize, I can swear before the Supreme Court that there was no resize involved in the process ;)

Yesterday I tried using DVD2SVCD 1.6 pre7, which includes AVI2SVCD and it seemed to work OK. Now, I'm not sure there was no deinterlacing involved (didn't have the time to check), but I sure unchecked 'Progressive frames' in CCE settings and also unchecked 'Upper field first".

Funny thing AVI2SVCD told me is that my AVI was not 25.000 fps, but 25.008...DO you think this might explain a few thing here about my shaky-choppy interlaced SVCDS ? I manually changed fps to 25.000, encoded with AVI2SVCD, and it worked !! ABsoluletly smooth playback on my TV ! (but sound was about 10x real-time (mickey mouse stuff).

Might be this weird fps...who knows ? I'll check this evening if there was any deinterlacing of any kind during the AVI2SVCD process.

Damn, now I understand even less...

Waldok:rolleyes:

[Excal]

Waldok

Just for information.

I too have been sharing your experiences of AVI DV to poor SVCD conversion.

I have tried all permutations of field order, all yielding the same poor SVCD output.

I did try the "De-Interlacing" thing which proved to be 100% better than that of interlaced. I know you (and I) don't want to go down this route.

This is what I did:

1. Edit the captured DV AVI (720x576 Lower Field Order) in Editing Software (Matters not) I use Premiere.
2. Export the Timeline to a DV AVI (720x576 Lower Field Order).
3. Use VirtualDub to process the audio, 4100KHz, Saved as WAV.
4. Use VirtualDub to FrameServe to CCE using the following filters:
Resize 480 x 576 PAL
De-Interlance (Using Best Option)

5. Use CCE 2.50 to Encode to Mpeg using the following with Upper Field Un-Checked.

6. Lametool to covert WAV file to MP3 224kb/s Data Rate.

7. Tmpeg to Multix to MPEG Video and MP3 Audio to SVCD format.

The above procedure (for me) gave near DV quality.

Let me know how you find the AVI2SVCD conversion, and whether it applies some kind of de-interlacing filter.

Good Luck.

Excal

[Radioman]

:confused:

Is there anyone else that use mp3 as SVCD audio or is it just a misspelling from Excal ?

[Excal]

Oooops Sorry there Radionan it was a typo, I meant MP2.

Excal

[waldok]

Thanks Excal for your explanations.

I think I'll try a few things today about this issue. I'll let you know about what DVD2SVCD does when using AVI2SVCD mode.

I'm afraid I'll finally have to go to deinterlace if nothing else works (after all, it's only family tapes :p

Ciao

Waldok

[24hourloop]

Originally posted by Excal
Waldok
2. Export the Timeline to a DV AVI (720x576 Lower Field Order).
Excal

You don't really want to go to another format, especially upsize and then downsize again. I am sure that'll give you poorer quality than possible.

As for CCE settings:

CCE doesn't give a damn whether you check 'Upper field first' or not. (Maybe it doesn when you give it a profile). Otherwise you will always get topfile first (Use a tool to verify).

Progressive frames merely sets a flag in the output file but you should uncheck it.

You should be able to check with TMPGenc whether you got interlaced or non-interlaced output. Here's what I do:

Load your clip into TMPGenc. Go to Settings - Advanced and make sure Interlaced is set. Leave field order as is. Double-click on 'Deinterlace'. Select 'Even-Odd field'. UNCHECK THE DEINTERLACE BOX. Then find a motion scene in your clip. Using the cursor keys play through it. If it plays jerky you already know it hasn't been deinterlaced. Let's assume it doesn't play jerky. In that case exit the dialog and check the other field order (Top field first). Then do the described thing again. If it still doesn't jerk I am afraid it was deinterlaced along the way.

So you want it to jerk one way or another and play fine on your TV.

One more comment: My player (APEX) really doesn't care whether the resulting output file is upper or lower field first. It always picks lower field when it recognizes SVCD. But other players may react differently.

Hope this helps.

[Excal]

Originally posted by 24hourloop


You should be able to check with TMPGenc whether you got interlaced or non-interlaced output. Here's what I do:

Load your clip into TMPGenc. Go to Settings - Advanced and make sure Interlaced is set. Leave field order as is. Double-click on 'Deinterlace'. Select 'Even-Odd field'. UNCHECK THE DEINTERLACE BOX. Then find a motion scene in your clip. Using the cursor keys play through it. If it plays jerky you already know it hasn't been deinterlaced. Let's assume it doesn't play jerky. In that case exit the dialog and check the other field order (Top field first). Then do the described thing again. If it still doesn't jerk I am afraid it was deinterlaced along the way.


Hope this helps.

24hourloop

You are absolutely right, I tried your prescribed tests and it they seem to work.

I still get poor playback, but I have a much better knowledge of Interlacing, De-Interlacing and Feild Orders.

I will keep trying with different settings etc.

One thing is for sure, and that is if the Interlaced clip is de-interlaced prior to MPEG encoding, the Quality almost excellent.

Thanks for your help..

Excal

[waldok]

24hourloop,

I didn't know players would do such a thing as deciding by themselves which field to use first...

However, here is the result of my experiment : it seems DVD2SVCD 1.0.6 solved my case, since SVCD produced through the AVI2SVCD option play fine on my standalone. I checked the resulting MPEGs and Bitrate Viewer confirmed they are interlaced, with upper field first.

Damn, now I fell dumb cause I still don't understand anything, don't know why it works now although I can't see any difference in settings (same source file, same AVS script, same CCE settings,...).

Anyway, let's face cruel reality, I'll be a dumb guy with working SVCDs :D (could be worse)

:stupid:

PS : But I'll still investigate things more to get the final word out of it...

[poplar]

Hi, every one. Just found this thread. Could someone email this Easy Fixer utility to me : john_yang@yahoo.com ? I have the same problem with CCE. I believe it's a field order problem. No matter how I fiddled with field order setting, encoded stream always plays choppy on TV. Hope this utility fixes it.

TIA!