Encoding progressive interlaced

[Master Yoda]

Now i have a video stream that seems to start progressive then goes interlaced.Now if i encode it interlaced would thise do any damage to the small progressive part??

[Matthew]

The progressive bits may be better encoded using zigzag, but if using alternate I doubt you'd notice the difference. Similar deal with using interlaced=true rather than interlaced=false in your avisynth script. I wouldn't worry about it...

[auenf]

Originally posted by Master Yoda
Now i have a video stream that seems to start progressive then goes interlaced.Now if i encode it interlaced would thise do any damage to the small progressive part??

90%+ of FILM based movies which are just sped up to 25fps are encoded as interlaced even tho they are really progressive frames.

the interlaced flag wont matter to playback, as long as you dont let CCE shift the video down a little.

Enf...

[unplugged]

Little note:
1) CCE accepts/threats only YUY2 for input
2) MPEG2 and DVDs are effectively coded in YV12 (even by CCE)

90%+ of FILM based movies which are just sped up to 25fps are encoded as interlaced even tho they are really progressive frames.
Indeed, I confirm too this is a common problem.
the interlaced flag wont matter to playback, as long as you dont let CCE shift the video down a little.
But careful, because using the progressive route the UV chroma channels gets rearranged in a different way...

One may think in this case he can add a simple "ConvertToYUY2(interlaced=true)" to his Avisynth script and than config CCE for progressive encoding, since the material is progressive itself.

Ok the avisynth addition is right,
but since original stream is (by unknown reason) stored in interlaced structure the chroma lines have indipendent values for odd and even lines.
My advise in this scenario (very common) is to configure CCE for interlaced material otherwise the chroma will result overall blurred or blocky, with a 4x2 pixel pattern. (!)

now MY QUESTION IS, when encode "false-interlaced material" with CCE using interlaced mode too (progressive flag off) is it advised to use zigzag or alternate block scanning ?

[Matthew]

@unplugged, for progressive content marked as interlaced, I've always used interlaced=false in avisynth and checked progressive in CCE.

I was of the opinion that the interlaced flag means absolutely nothing for progressive content...are you sure about it being best to mark the content as interlaced?

[unplugged]

Originally posted by Matthew
@unplugged, for progressive content marked as interlaced, I've always used interlaced=false in avisynth and checked progressive in CCE.
The problem is that it's not a matter of marking, it is *stored* as interlaced.
The chroma lines are combed (interlaced), I have made a simple test and VirtualDub shows that when encoding as progressive the lines get blurred together.

YV12 interlaced ---> YV12 progressive conv. is a disaster for chroma dynamics whether the content is combed or not!

In few words there is a total loss in vertical chroma resolution.

[Matthew]

Could you tell me how to replicate this test please?

I just tried encoding a chapter from one of these DVDs (source interlaced and zigzag) with interlaced=true in avisynth and CCE and then repeated with interlaced=false. Used zigzag both times.

Used 1 pass Q20 and couldn't see any obvious differences (of course that is not exactly reliable, to say the least). The "interlaced" encoded file is 1.2 percent larger.

[Eki]

Originally posted by unplugged
The problem is that it's not a matter of marking, it is *stored* as interlaced.
The chroma lines are combed (interlaced), I have made a simple test and VirtualDub shows that when encoding as progressive the lines get blurred together.

YV12 interlaced ---> YV12 progressive conv. is a disaster for chroma dynamics whether the content is combed or not!

In few words there is a total loss in vertical chroma resolution.
How can you distinguish if video has been flagged as interlaced or progressive encoded in interlaced mode?

[unplugged]

Originally posted by Matthew
Could you tell me how to replicate this test please?
Make 2 avisynth scripts, one with ConvertToRGB(interlaced=true) and the other with ConvertToRGB(interlaced=false), this is intended for testing.
Load the scripts using 2 VirtualDub sessions and set 300% zoom, search a colorful or red part in your test movie and see which has better luma-chroma matching, especially on edges.
Original movies stored as interlaced should have the right luma-chroma matching with the parameter set to true.
Sadly, there are movies encoded as interlaced but without chroma channels originally rearranged for interlaced encoding (not RGB/YUY2, but YV12 need this!), these appears better with interlaced set to false.
Originally posted by Eki
How can you distinguish if video has been flagged as interlaced or progressive encoded in interlaced mode?
Use DVD2AVI, load the movie, shift cursor inside the movie (to skip initial screens that maybe saved differently) press the left bracket button to select from that position, than press 'F5' and look at the preview panel on the right: it can give "progressive" or "interlaced".
You can also use Bitrate Viewer program.

[Matthew]

I know this is stupid but i can't figure out how to zoom in virtualdub :o

That aside, why use the convert to RGB - we are not using it for DVD backups.

I believe what Eki was asking was how to determine whether for progressive content reported as interlaced by BV or DVD2AVI:
A) The movie has been encoded in an interlaced fashion; or
B) Whether the movie has been encoded in a progressive fashion, but has just been marked as interlaced (the flag can be set in pulldown, for example, without re-encoding - not that authoring houses would do that, obviously).

[unplugged]

Originally posted by Matthew
I know this is stupid but i can't figure out how to zoom in virtualdub :o
Use recent VirtualDub(Mod) version and right-click over video.
(but before, please uncheck DirectX accel. in preferences, set 24-bit output, save options and restart VirtualDub)
Originally posted by Matthew
That aside, why use the convert to RGB - we are not using it for DVD backups.
As I have said, that ConvertToRGB it's just for visual testing, the VDub screen image and only the screen image would be converted *anyway* in RGB (whatever is the input: YUY2, YV12...), it's not for encoding of course.
Originally posted by Matthew
I believe what Eki was asking was how to determine whether for progressive content reported as interlaced by BV or DVD2AVI:
A) The movie has been encoded in an interlaced fashion; or
B) Whether the movie has been encoded in a progressive fashion, but has just been marked as interlaced (the flag can be set in pulldown, for example, without re-encoding - not that authoring houses would do that, obviously).
I think this can be checked visually with the 2 scripts mentioned in my post.
But I *guess* that if a movie is encoded in interlaced way, it's internally divided in 2 fields per frame (encoded indipendetly), in this case "interlaced" can't be only a flag (can't be not considered for correct playback, because it's part of structure).

[Eki]

Originally posted by unplugged
I think this can be checked visually with the 2 scripts mentioned in my post.
But I *guess* that if a movie is encoded in interlaced way, it's internally divided in 2 fields per frame (encoded indipendetly), in this case "interlaced" can't be only a flag (can't be not considered for correct playback, because it's part of structure). [/B]
So if Bitrate viewer reports Pic. structure: Frame and Frame type: Interlaced then it's actually progressive flagged as interlaced?:confused:

[unplugged]

Yes
Interesting, I have just tryed Bitrate Viewer (I mosty use DVD2AVI) and I found (as you) two infos: "picture structure" and "frame type". The first info can be "frame" or (?)"field", the second, and I am sure of this, can be "interlaced" or "progressive".
Now I would say that picture structure is the parameter to take with care!
Doh, I have never noticed it before, thus maybe the other called "frame type" is only player related but now expert is needed here.
DVD2AVI surely reports only this last flag (it seems to match with Bitrate Viewer "frame type").

[unplugged]

My apologies Matthew, that you have referred as flag was right because the property commonly called "interlaced" or "progressive" it's NOT struture related.
"Picture structure" should be the trusted value:
for "frame" --> YV12 progressive --> ConvertToYUY2(interlaced=false) --> CCE set to progressive
for "field" --> YV12 interlaced --> ConvertToYUY2(interlaced=true) --> CCE set to interlaced

[Matthew]

mmmm...I'm as perplexed as ever...a few things:
-CCE only outputs as picture structure = frame
-I've had a commercial DVD which is mixed content and picture structure is frame
-Procoder says following in regards to its picture structure settings:
"This determines how the field data is stored in the MPEG stream,
possibly optimizing compression.
This does NOT determine whether the output is interlaced or
progressive.
Automatic Selection will have the encoder will handle still and
low-motion frames as full frames, and handle motion frames as
interlaced. Some players may have problems with this method, in
which case you should use one of the other options.
Always Frame Structure will have the encoder store as full frames
and tends to be the most compatible mode.
Always Field Structure will have the encoder store as fields."

So if picture structure was the guide, would that not mean truely interlaced content with picture structure = frame should have interlaced=false in avisynth script? That doesn't seem to make sense.

[RB]

Matthew is right, field pictures don't necessarily mean interlaced video. So far I think Procoder is the only encoder that supports this and I have rarely seen it on DVDs. I have exactly one DVD that is encoded with field picture structure.

Anyway unplugged, you are making a good point. I think you are right in that if the source MPEG2 stream was encoded as frame_type interlaced (DVD2AVI or BitrateViewer are good to check this), then it should be converted to YUY2 with interlaced=true. Also check out this post: http://forum.doom9.org/showthread.php?s=&threadid=58800#post354127 which further explains this. Looks like always using ConvertToYUY2(Interlaced=True) is the best compromise.

Now as for how to set up CCE. Thinking about it, it should really be set according to the encoding parameters of the source MPEG. That is, 'progressive frame off/alternate' if that's what the source is according to BitrateViewer, no matter whether the source actually "looks" interlaced or not.

However, if the source is not "truly" interlaced (no interlacing artifacts visible), I would at least set block scanning order to ZigZag as this only effects motion search and storing of the DCT coefficients but not the croma.

I just did a short test with a DVD source that according to BV was interlaced/alternate but really loked progressive (like most DVDs), setting CCE to interlaced/alternate, interlaced/zigzag and progressive/zigzag. It did not make any difference in the Q factor levels, just the alternate setting slowed CCE down by about 0.2 RT. Looking at the output, I honestly can't tell any difference, but anyway interlaced is the "more accurate" setting as we now know.

This begs for a new FAQ item I think...

[Eki]

Bitrate viewer also reports DCT type which can be frame or field. So what does this mean? :confused:I did quick test with few DVD's and it seems that all video's encoded as progressive have DCT type frame.

[Matthew]

Originally posted by RB
Now as for how to set up CCE. Thinking about it, it should really be set according to the encoding parameters of the source MPEG. That is, 'progressive frame off/alternate' if that's what the source is according to BitrateViewer, no matter whether the source actually "looks" interlaced or not.

But is it possible that in some cases at least, the interlaced flag is just that - a flag, and the video stream has actually been encoded in a progressive manner? Because we do know that the interlaced flag can be losslessly inserted, and we don't know (well I don't anyway) how the expensive commercial hardware encoders operate.

I'm hoping (perhaps unrealistically) that this is possible and a regular occurance, because I've encoded all of these types of DVDs (and they are extremely common) using progressive settings. At least it seems I was right to use zigzag even when alternate was used on the original DVD, though.

[RB]

@Eki: http://www.bretl.com/mpeghtml/fldfrm.HTM

However, if the source is not "truly" interlaced (no interlacing artifacts visible), I would at least set block scanning order to ZigZag as this only effects motion search and storing of the DCT coefficients but not the croma.
Oops, looks like I was wrong. Reading http://www.bretl.com/mpeghtml/zigzag.HTM, it appears that ZigZag really should be used only for progressive (that is, not encoded as alternate) sources.

[Matthew]

So what if a progressive source is marked interlaced/zigzag, as that's quite common? Should we use interlaced/alternate?

*sigh*, I want my mummy.

[RB]

No, in this case I would use the exact same settings. I think it really comes down to that we should replicate the original encode settings in CCE.

[Matthew]

Thanks RB, that makes me feel better. Well, at least it did.

I (finally) replicated unplugged's experiment on an interlaced/zigzag PAL DVD and skipped to a red area. The results, to my eyes, appeared better with interlaced=false.

Specifically, in the top left corner of the picture where the red met the black border, there are clear lines showing in the transition area when interlaced=true is used. [This is with 300 percent zoom, obviously]. The same problem is there as the red moves along the top edge (it's a person's hat).

I have 2 psd screenshots (1.7 MB compressed) that I can provide on request (I have webspace). Just open in photoshop and zoom in :/

edit: just tried it with an interlaced/alternate source (Chicago R4), and noticed the same phenomenon, this time with blue against the black border, as well as red against the black border.

Also, noticed for the "main" picture that blue edges against a black background and red edges against black backround clearly looked better with interlaced=false.

[RB]

Interesting... what did BitrateViewer report for DCT and frame type? "Frame" or "Field"?

[Kika]

The Scan order (ZigZag or Alternate) has nothing to do with the colors itself. It is only the methode, how to read the Data in an Block. Y- Cb- and Cr-Blocks are stored separated in a MPEG-File, so the Scan order can't have any influence of the Colors.

[RB]

Hi Kika :)

So, is http://www.bretl.com/mpeghtml/zigzag.HTM wrong then?
The zig-zag scanning pattern for run-length coding of the quantized DCT coefficients was established in the original MPEG standard. The same pattern is used for luminance and for chrominance.

[Kika]

No, that's correct. But the Blocks are separated. One Macroblock = 4 Luma- and 2 Chroma-Blocks.

Lu Lu Lu Lu
Cb Cr

[RB]

Ok, I'm getting a little lost here, too...

Kika, I know you are good at this, so what's your opinion on the whole picture here? Is there any way to tell exactly whether the source should be converted to YUY2 with interlaced=false or true, whithout having to visually inspect the result beforehand every time? Logic suggests that when the source is encoded as interlaced/alternate, we really should be using ConvertToYUY2(interlaced=true), but Matthew obviously proved this wrong...

@Matthew:
What did you use to play the AVS and take the screenshots? Maybe to eliminate the influence of any external video codecs, it would be best to use AVISynth's ImageWriter() function to take the "screenshots".

[Kika]

@RB

I'm not good on explanations in english...

OK, let's try. Scan order and Macroblock are belonging to the Compression part itself. In YUV4:2:0, that's the Format for MPEG2, you have 4 Blocks of Y, one Block of Cb and one Block of Cr. The Scan order descripes only in which order the Datas should be readed. For each Block, the same Scan order is used, but the blocks are handled one after each other.
On a progressive Picture, the Scan order does not matter for reading the informations. Only if you try to use ZigZag to decode a Alternate encodet Video (or vice versa) you will have a big mess.

After decoding a Picture, things are changing. After that, you a Picture in YUV Colorspace, which must be handled the right way.
No mater, if a progressive Video is encodet in interlaced or progressive Mode, after Decoding to a Picture, it should be a progressive one and be handled as a progressive Picture.
So, in this special case, Interlace=true is the wrong way.

[RB]

Your English is just fine :) But feel free to PM me in German any time, I'll post the translated reply.

OK, but have you read this post (http://forum.doom9.org/showthread.php?s=&threadid=58800#post354127) that I referenced earlier in this thread? This guy seems to know what he's talking about. What I get from this post is: assume the studio took the really progressive film material and for some reason (as on many DVDs) encoded it as interlaced/alternate. Now to quote FMalibu:... a progressive mode coded chroma sample contains information for 2 directly adjecent lines (e.g. C1,2) ... In the case of an interlaced mode coded sample, it will contain information for alternating lines (e.g. C1,3) So in this case the croma is indeed stored differently, it doesn't matter that the original source was progressive. Ergo we should use interlaced=true, and we should also reencode as interlaced/alternate although progressive/zigzag probably wouldn't make much difference. Don't you agree with this?

[Kika]

Oops, you'r right and FMalibu too. Sorry, my fault, i messed up some things (this may have happend in german too ;) ).

Although the source video was progressive, it will be handled as interlaced while decoding if you use interlaced Mode while encoding.
So my first statement is wrong. We have to use Interlace=true to get the correct decodet Video.

However, what i wrote about the Scan order was correct. It does not have a direct influence to the Colors.

If the source is an interlaced encodet progressive Video, you should use interlaced=true on any colorspace conversion.

[Matthew]

Originally posted by RB
Interesting... what did BitrateViewer report for DCT and frame type? "Frame" or "Field"?

interlaced/zizag:

Pic. structure: Frame
DCT type: Field
Quantscale: Nonlinear
Scan type: ZigZag
Frame type: Interlaced

interlaced/alternate:

Pic. structure: Frame
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced


Originally posted by RB
@Matthew:
What did you use to play the AVS and take the screenshots? Maybe to eliminate the influence of any external video codecs, it would be best to use AVISynth's ImageWriter() function to take the "screenshots".

Here's my script for true:

LoadPlugin("H:\brit07\MPEG2Dec3dg.dll")
MPEG2source("E:\test\test.d2v")
ConvertToRGB(interlaced=true)

I used VirtulDubMod and its "copy source frame to clipboard" feature.

The theory seems to be against what I've noticed. Anyway, I don't understand all this technical stuff, all I can say is that perhaps the video is marked as interlaced but not encoded in an interlaced fashion (if that's possible).

[U977]

Gents,

I'm popping up in this discussion from nowhere, but your posts answere questions I had since a long time but never really took time to ask...

I have two computers, and the older one still uses VF-API instead of AVISYNTH for importing the video in CCE prior to encoding.

Now, you guessed mpy question already... What happens when we use VFAPI instead of AVISYNTH? What should I do, then? (except than switch in avisynth? :-) ). I know I would gain from using avisynth, but I'm too lazy to update or change anything on this older computer. Enough work with the new one already. Yet, I'm interested to know what happens with VFAPI.

[RB]

@Matthew:
I looked at your screenshots and verified this in my own tests. The interlaced=true parameter seems to introduce a slight "gradient" effect. Interestingly enough, this gradient disappears in the CCE encoded video when encoding as progressive/zigzag and then using interlaced=false in the AVS for the CCE encoded video.

I think it comes down to this:

If original stream is DCT Type: Field and Frame Type: Interlaced, use interlaced=true.

Then to decide whether to reencode as interlaced or progressive, check the video for combing artifacts. If it really looks progressive, we can happily encode as such (Progressive Frames: on, Scan Order: ZigZag). This is because we are reencoding in YUY2 colorspace where chroma samples are stored the same way for both interlaced and progressive video. If CCE supported YV12 so we could leave out the ConvertToYUY2() in the AVS, we indeed should replicate the original stream settings in CCE because chroma is stored differently for interlaced video in YV12.

@U977:
VFAPI converts to RGB as you may know and I really don't know whether it does the conversion differently for interlaced/progressive. Upgrade to AVIsynth :)

[Kika]

If a Video is progressive but encodet in interlaced mode, we have to treat the colors as interlaced. That's because the progressive Frame is splittet up into 2 Fields. All DVD-Players are treating such a Video as interlaced.
So the big Question is: What is MPEG2DEC doing in such a case?

Combing the Fields to a true progressive Picture with a continuos Color-Coding? I guess not.

SeparateFields().ConvertToRGB24().Weave()
ConvertToYV12()

Guees this Script-Snipplet is not a bad Idea to be sure to handle the colors correctly all the times.

[RB]

Kika, I don't think MPEG2DEC3 (the AVISynth 2.5 version) does anything wrong with respect to the colors because it does no color conversion by itself, it decodes in YV12, you know.

Now I'm not sure whether you agree to my advice on progressive encoding or not. Again, I believe that once you converted interlaced YV12 to YUY2 correctly (interlaced=true) but the video really looks progressive, you can now also encode as such. Because unlike YV12, YUY2 doesn't store chroma differently for interlaced or progressive, no?

About your snippet, I'm not sure what this intended for :).

SeparateFields().ConvertToRGB24().Weave()

will always upsample chroma incorrectly for YV12 input, this is why the interlaced=true/false parameter was introduced in AVISynth 2.5 after all.

[Kika]

@RB

That's why i wrote "i guess" - i don't know how MPEG2DEC3/AVIsynth exactly acts in this case.
If it is working like descriped by you, i agree: After a conversion to YUY2 all should be correct.

About your snippet, I'm not sure what this intended for

It's just for beeing absolutly sure. But..., um..., OK, after thinking again about that..., let's forget it, OK? ;)

YV12 in AVISynth still drives my crazy sometimes.

[RB]

OK ;)

[Matthew]

Thanks for that RB, you've made me feel all warm and fuzzy =)

At least I've been doing the encoding half-right (the CCE side) :)

[biggy7]

just doing a a NTSC film

bitrate veiwer reports:
Num. of picture read: 31
Stream type: MPEG-2 MP@ML VBR
Resolution: 720*480
Aspect ratio: 16:9 Generic
Framerate: 29.97
Nom. bitrate: 7000000 Bit/Sec
VBV buffer size: 112
Constrained param. flag: No
Chroma format: 4:2:0
DCT precision: 10
Pic. structure: Frame
Field topfirst: Yes
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced

when i set the options in dvd2dvd-r, according to bitrate viewer, which is leaving the boxes unchecked (prog frames, linear quant etc), when the encoding has finished and when playing back, lines appear in the movie.

now what am i doing wrong?

[U977]

RB,

Continuing our discussion from the DVD Rebuilder topic, and K-19...

AS reminder, for ease, I copy the info here again:
-----------------------------------------
logfile for K-19:

T01=AC3 0x80 3_2 448 0
T02=AC3 0x81 3_2 448 0
T03=AC3 0x82 2_0 192 0
GOPWarn=0
MPVBytes=4623620882
MPVMegaBytes=4409
AudioTracks=3
D2VFrames=198628
FramePictures=198628
FrameRate=25000
Width=720
Height=576
Bitrate=4655
Progressive=191470
FrameDCT=191482
TFF=198628
ZigZag=191470
PercentFilm=0


As a test, I encoded this one as progressive, with ConvertToYUY2() (thus interlaced=false).

I examined the resulting stream closely, did not find any artifact nor colour problems.
-----------------------------------------

Regarding your question about the structure, all the main movie is in a single PGC, but it was multiangle (only for some cell-ids, not for all the content). The different angles correspond to text in the video stream, in different languages. So, depending on what audio stream you select in the menu, you also get that text in the video in the proper language.
So you were still right: those text parts are the interlaced parts (confirmed during preview using the DVD2AVI version you asked me to use yesterday)

As I was too lazy to fully handle with this (I don't feel a need to support such features in my back-ups), I just extracted the angle I wanted (using DVD Shrink, without any compression) and the result was what looks like the typicall movie, with a single angle. That's what I worked on further with CCE, then.
And honestly, even if that text part of the video was encoded as progressive, I could not notice any bad effect (should it be interlaced artifacts, or colour problems).


You have shown that picture to me, with effects of bad colour conversion when using ConvertToYUY2:
http://forum.gleitz.info/attachment.php?attachmentid=66315

It was very very interesting!

As I told you, I encoded several PAL movies as Interlaced (but ConvertToYUY2(), hence interlaced=false !), thinking that since they were flagged as Interlaced, I should have done this way.
I guess that they were progressive though, like the usual cases, but looking at the results with VirtualDubMod, and zooming, I can't find any of such effect. I can't find interlaced artifacts either.
I wonder if it means that there is a problem in the video, but the effect is harder to notice than the picture you've shown to me.

The only artifacts I could spot were found in Spirited Away. But in this case, I first encoded as progressive by mistake (forgot to flag as interlaced...) and the result was clearly showing interlaced artifacts on a standalone player. So I re-encoded the whole as Interlaced, and got new artifacts, just to realize I also forgot to use the proper TFF setting... (blushing) At least, Alternate scan was right! :D HEnce, I was facing real interlaced content, and I encoded it so too.
I ended with something that plays really nicely on a standalone and on a computer, without any noticeable bad effect. But when watching it in VirtualDubMod, and zooming, I can distingish some "interlaced-like" artifacts. But on an "Anime", they looks different than expected, if I compare with with filmed video Well, at least to my own eyes. Now I wonder if they are really Interlaced artifacts, or colour problems due to bad setting in ConvertToYuY2. Those artifacts do not look like what I could see on the example you gave me. I could take a screenshot tonight.

To be honest, I can't tell if I was lucky, or if there is something bad in my encodes that can be automatically fixed on-the-fly by standalone players and software players on computers.

If you have an opinion on this, I'm very interested to hear it too. I'd like to understand what I did, and what happens.

RB, a last question: what's the best tool/way to examine video, if I want to check if there were any colour conversion problem like the one shown on that picture you mentionned to me?

[U977]

Note: I looked for artifacts using VirtualDubMob, but without using AVS script: I directly opened VOB files. Maybe it was a newbie mistake: I know almost nothing of VirtualDub and VirtualDubMod. It could decode MPEG2 without AVS scripts.

I also used DVD21AVI, as you know already.

As last note: I will check the originals when I've time. It's just that I'm not at home, and I can't prevent myself to post here during my moments of pause :-)

RB, I'd like to show a screenshot of what I saw in VirtualDubMod for Spirited Away. Is there another way than putting it on a web site? (I have no web space).

[RB]

Originally posted by U977

RB, a last question: what's the best tool/way to examine video, if I want to check if there were any colour conversion problem like the one shown on that picture you mentionned to me?
What about a good software player lile WinDVD that can save screenshots? Or create an AVS for your reencoded video, use Trim() to cut out a problematic part and then ImageWriter() to save a sequence of frames as bitmaps (it's all in the AVISynth docs). Before ImageWriter, you must put a ConvertToRGB24(interlaced=true/false) statement.

About that screenshot you want to share: just attach the image to your reply and I'll make it visible :)

And I have just seen the combination of Progressive and DCT Type = Field you mentioned earlier for the first time myself. Really, all frames were marked as progressive, but scan order was alternate and DCT type was field. But it was really actually interlaced stuff with typical interlacing artifacts in DVD2AVI preview.

Nonetheless, I encoded it with ConvertToYUY2() but set up CCE for interlaced of course. I couldn't spot any problems in the encoded video.

So I would again say yes, trust the DVD2AVI preview or the log file that my butchered version creates for your color space conversions. If in doubt because there's a mixture of progressive/interlaced, use ConvertToYUY2(interlaced=true) because it causes almost no harm to progressive frames.

[U977]

RB,

Many many thanks for sharing your experience, and helping.

I checked the originals, and for most of them, it's like what you said:teh content looks like progressive, frames are flagged as progressive, but DCT type is field, and alternate scan is used.

So, by luck, I used the proper settings (ConvertToYUY2(), and encoding as Interlaced with alternate scan), and that's why I did not get any problem.

So, I'm reassured, and my curiosity is now satisfied lol

However, as last remark, I can tell you that most of the time my content looked progressive in DVD2AVI too, and I couldn't spot interlaced artifacts in the original.

Just very very few had interlaced artifacts (I can only recall one.. I did not check all of them, and those that I checked didn't have them), and encoding as interlaced allows all players to play it correctly.

Thanks again!

[burnout]

just to check things i was wondering it this is correct:


AVISynth Script (look for interlacing artifacts with DVD2AVI or VDubMod)

Progressive - ConvertToYUY2()
Interlaced - ConvertToYUY2(interlaced=true)
If in doubt or int & prog - ConvertToYUY2(interlaced=true)


CCE Settings

Progressive - Progressive Frames: On, Scan Order: ZigZag
Interlaced - Progressive Frames: Off, Scan Order: Alternate


That seems to keep the picture fine for both types, but i was wondering what options should be used when deinterlacing (i use kerneldeint.dll)? i'm guessing that the progressive options in CCE should be chosen, but interlaced=true for the avs script, could some1 please confirm this?

also while i'm asking questions...

From CCE (Robshot method AKA "Getting the best out of CCE") Guide
Quantscale is actually nonlinear which would lead us to believe to not check Linear quantizer scale but the original author of this method told me that linear quantizer scale yields better quality.

The source was nonlinear, but using linear put the average Q.factor down by 0.1 (and the video seemed to move when flicking between images at 300% zoom as there were some differences, but i'm not sure which was better), so is this still considered a good idea? or would selecting whatever the source was originally be a better idea (not exactly sure what the quantizer scale is)?

Edit: also, how would the using a deinterlacer on progressive material affect its quality, as i have some extras which are interlaced, but have progressive video clips in them.

Thanks, burnout

[RB]

Originally posted by burnout
AVISynth Script (look for interlacing artifacts with DVD2AVI or VDubMod)

Progressive - ConvertToYUY2()
Interlaced - ConvertToYUY2(interlaced=true)
If in doubt or int & prog - ConvertToYUY2(interlaced=true)


CCE Settings

Progressive - Progressive Frames: On, Scan Order: ZigZag
Interlaced - Progressive Frames: Off, Scan Order: Alternate

That seems to keep the picture fine for both types, but i was wondering what options should be used when deinterlacing (i use kerneldeint.dll)? i'm guessing that the progressive options in CCE should be chosen, but interlaced=true for the avs script, could some1 please confirm this?

Confirmed and your settings are fine.

About linear/nonlinear: MPEG2 AFAIK specifies only nonlinear, IMHO it's a quirk of CCE 2.5 lettings you specify linear for MPEG2 at all.

About deinterlacing: my advice is to just not deinterlace. It just introduces different artifacts. Honestly, I tried a few deinterlacers and the results always looked horrible to me. Just keep it interlaced.

[burnout]

ok thanks for the info :)

about deinterlacing, i have heard people say that interlaced video needs a higher bitrate to have the same quality as progressive. if this is true then what type of bitrate increase would be needed for the same quality? thinking about it now i don't see how as it's still the same resolution, just split into 2 fields, maybe i will stop using one...

[RB]

Interlaced video requires higher bitrate, correct. That's because an interlaced frame isn't "smooth" like a progressive frame. It's made up of two fields that were shot at different points in time hence the typical "interlacing jagged lines" which makes it more difficult to encode. I wouldn't go below 3000 kbps for full res interlaced video.

[burnout]

ok thanks for clearing that up (and sorry for going slightly off topic on this thread :rolleyes: )

sometimes i need to reduce the interlaced extras to lower than that on a DVD, but if a bitrate of 3000 is available then i will leave them interlaced. thanks again ;)

[dplaton]

I encoded an analog interlaced RAW capture as interlaced
via VitualDubMPEG2.
CCE interlaced.
The resulted DVD played on a cheap standalone was jumping foreward and
backward.
Any ideea:confused:

[dplaton]

I encoded an analog interlaced RAW capture as interlaced
via VitualDubMPEG2.
CCE interlaced.
The resulted DVD played on a cheap standalone was jumping foreward and
backward.
Any ideea:confused:

The jumping was due to the inapropriate field order

[subair37]

90%+ of FILM based movies which are just sped up to 25fps are encoded as interlaced even tho they are really progressive frames.

Hi

Please look at the statement above, reason is i have all Central dvds when i analyze i get source as Film field order as Top Field First and TIVTC ,but when i change source order as progressive i can see preview as horizontal lines even though central says all their dvds are progressive,so i change it back to interlaced filter as yadiff i get clear and smooth picture with no horizontal lines so please look at my script which i made to feed it in to CCE SP2 to do MCCE.


LoadPlugin("C:\Program Files (x86)\megui\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\DemuxedPappi\PappiAppacha.d2v", info=3)
LoadPlugin("C:\Program Files (x86)\megui\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, interlaced=true, threads=0)
Load_Stdcall_Plugin("C:\Program Files (x86)\megui\tools\yadif\yadif.dll")
Yadif(Mode=1)
RePal()
crop( 2, 58, -2, -58)
Tweak(Sat=1.15,Bright=2,Cont=0.93,Coring=False)
AddBorders(2,58,2,60)
ConvertToYUY2()
AddAudio()



Please shed some light on this...........

[manono]

The statement at the top is correct for PAL movies speeded up to 25fps, except in my experience it might be closer to 99%. Your South Indian movies are NTSC so the statement has nothing at all to do with your DVDs. If you want advice about something, please post a 10 second long sample, one showing steady movement.