ConvertToYUY2?

[Lev]

hey guys

what does this line in my .avs do?

ConvertToYUY2(interlaced=true)

i cant remember seeing that in the past..

this is my whole .avs:


import("D:\APPIEZ\_DVDR_APPIEZ\DoItFast4U\new.avs\addaudio.avs")
LoadPlugin("D:\APPIEZ\_DVDR_APPIEZ\DoItFast4U\new.avs\mpeg2dec3.dll")
Mpeg2Source("VTS__02_P01.4~3_1.d2v",idct=0)

AddAudio()
ConvertToYUY2(interlaced=true)


i'm encoding an interlaced pal source..

[MLS]

It converts the colorspace, as CCE will not accept native YV12 colorspace that most DVDs use.

/MLS

[Lev]

is that the reason why my encodes always have a slightly different color than the original?

i think i read somewhere that the part between the ()'s is optional.. can i just make it ConvertToYUY2()?

[D3s7]

If your questioning the settings I'd leave them alone... a lot of time/effort/testing went into those settings...

[Lev]

i understand but doesn't the values between the ()'s affect encoding?

for example what if i have an interlaced pal source that i can encode progressive? should i leave the ConvertToYUY2(interlaced=true) or should i make it ConvertToYUY2() or maybe something else?

[Sergei.Gradski]

I'm wondering about the same setting...

Following Doom9's guide, I added the specified two lines to the avs script of my interlaced source. However, after deinterlacing the source with FieldDeinterlace(blend=false) the source should NOT be interlaced anymore - doesn't this collide with the questioned line ConvertToYUY2(interlaced=true)?

What should I do now - delete the "interlaced=true" or leave it there?

sG

[Lev]

even when i'm encoding progressive i leave it there.. it doesn't seem to do any harm..

[Sergei.Gradski]

okay, thanks...

[Matthew]

Ummm, logic says that if the source is not interlaced (including de-interlaced) then it should be set as false...otherwise there would be no need for that setting in the first place.

[Trahald]

fortunately for us , logic does not apply when the eye is the beholder.

i read some thread where someone tested it and either it looked better or the at least the same. dont feel like searching now. but you can feel free to test it

[Matthew]

I just did a search

http://forum.doom9.org/showthread.php?s=&threadid=61079

sh0dan says

When using AviSynth 2.5.x be sure to end your script with

ConvertToYUY2(interlaced=true)

If your material is interlaced - otherwise "interlaced=false".

Given who sh0dan is, that's good enough for me ;)

[Trahald]

FMalibu
Junior Member

Registered: May 2003
Location:
Posts: 1

This is the 3rd version of this post. The first one was very long but got lost forever because of a login timeout (grr), and as a result the second post was very short. This should be a bit more elaborate.

The MPEG-2 standard has two types of 4:2:0 (YV12 in avisynth) coding modes, interlaced and progressive. The coding mode used depends on the contents of the progressive_frame flag, which can vary per frame. While upsampling your video to YUY2 in avisynth (4:2:2 in MPEG-2 terms), you have to specify one coding mode for the entire stream. The problem is that there are no guarantees that the stream will use the same coding mode throughout the whole of the stream, and secondly that avisynth cannot autodetect this coding mode for you, so you will have to set it manually.

This is all just fine if you're willing to set the interlaced flag of ConvertToYUY2() manually every time you backup a dvd, but let's face it many people are lazy, and not everyone edits the options from their defaults . So the default option should be one that minimizes the damage incurred on your video.

To assess this damage, I shall illustrate what exactly happens when you use the wrong coding mode while converting. But first I will illustrate what happens when you use the correct coding mode.

4:2:0 chroma contains colour information for a total of 4 luma pixels, 2 vertical and 2 horizontal. In 4:2:2 one chroma pixel contains information for only 2 horizontal luma pixels, making the total chroma resolution twice as big vertically. So to upsample avisynth has to fill in the missing vertical pixels. This is what happens during correct upsampling:


code:--------------------------------------------------------------------------------
Progressive coding:
C1,2 -> C1,2
P C1,2
C3,4 C3,4
C3,4

Interlaced coding:
C1,3 -> C1,3
I C2,4
C2,4 C1,3
C2,4
--------------------------------------------------------------------------------

You see that a progressive mode coded chroma sample contains information for 2 directly adjecent lines (e.g. C1,2), so to convert this to 4:2:2 properly, avisynth uses the colour information in that sample for these two lines. In the case of an interlaced mode coded sample, it will contain information for alternating lines (e.g. C1,3). This has the effect that one chroma sample can only have colour information of one field. If this were not the case, the chroma sample would contain an average of the colour information of both fields, and this does not work well with fast motion or scene changes.

So what happens if we use the wrong coding mode to upsample 4:2:0 video, in both cases:

code:--------------------------------------------------------------------------------
Progressive coding:
C1,2 -> C1,2
I C3,4 *
C3,4 C1,2 *
C3,4

Interlaced coding:
C1,3 -> C1,3
P C1,3 *
C2,4 C2,4 *
C2,4
--------------------------------------------------------------------------------

I have marked the misaligned fields with a *. So if we look at this we see that the same error gets introduced when we use an incorrect coding mode to upsample.

But let us consider what this implies for actual interlaced video. Because 2 out of 4 lines are switched around, half the colour information of a certain field actually belongs in the other field. This has the effect that on fast motion and scene changes, colour bleeding from one field to the other will be visible.

Progressive video where 2 out of 4 lines have the colour information misaligned does not exhibit this. The colour information will be slightly out of place, but thanks to the interpolation avisynth uses to upsample this will hardly be noticable.

In conclusion, if you do not know the nature of the video that will be processed, setting the interlaced=true option will minimize any damage caused by indicating the wrong coding mode while upsampling. If you do not agree with this line of reasoning, you are of course free to change this option any way you like.

Of course, when you are deinterlacing your video, the inherent interlacedness of any video (and arguably the very farbic of space-time itself) will be destroyed, thus making any interlaced=true option unneeded.

I hope this has clarified why I recommended Eyes`Only to use interlaced=true as a default option to ConvertToYUY2().

- FMalibu


Last edited by FMalibu


now we can paste stuff all day.. i do respect shodan a great deal.. but since he doesnt watch my dvds with me i think i'll just trust my eye like i said ;)

[Sergei.Gradski]

So basically it's just set to true because it's the correct setting for interlaced sources and doesn't harm non-interlaced sources, whereas setting it to false would be correct in case of non-interlaced sources but do harm to interlaced sources, right?

Good to know. Considering the FieldDeinterlace(blend=false) I will set it to false next time, but I definitely won't redo my current backup (which happens to be almost finished).

Maybe this could be added to the guide, just in case anybody else wonders?

[Beastie Boy]

What happens if I miss out ConvertToYUY2 altogether? I ask because I have just done and it seems to be working, or will the colours be off?

Cheers, Beastie.

[Matthew]

Umm, w00kie what FMalibu and sh0dan say in those quotes posts are perfectly consistent.

All FMalibu has said is that using the interlaced setting on progressive content is MUCH less harmful than the reverse, so it makes sense for safety's sake to set the default to interlaced.

FMalibu does not say that if your material is progressive you shouldn't change the setting to false, in fact he implies the precise opposite, even if he does say the damage is "hardly noticeable". He just recognises that most people won't be careful enough to do this.

But that doesn't mean you should wilfully ignore changing the setting when you are careful enough to consider doing that!!

Beastie Boy, I believe what happens when you do that is that the conversion is done by some other codec installed on your system, and it can result in an inferior outcome.

[Trahald]

levs post is essentially asking - why the heck is interlace=true in my avs if my output will be progressive. my reply was to defend doitfast4u using that. thats why i quoted fmalibus post (i read it a while ago) because it explains why its there. again... if it works better for you not to have it there, im not advicating changing, please go with 'false'. im just saying for me, and the author of doitfast4u, the setting works for us. so just understand it from that point. im just defending doitfast4u's logic. im not saying your 'wrong' persay , more that 'its in the eye of the beholder'.

[Matthew]

Originally posted by w00kiee
levs post is essentially asking - why the heck is interlace=true in my avs if my output will be progressive. my reply was to defend doitfast4u using that. thats why i quoted fmalibus post (i read it a while ago) because it explains why its there.

That's fair enough (I agree entirely with that bit) but rightly or wrongly I thought you were also implying that it's not definate that it's best to change the setting to false if the source is purely progressive. As far as I'm concerned that isn't a matter of "eye of the beholder", rather if it is progressive it's best to have it set to false, if it's interlaced it's best to have it set to true. Otherwise the avisynth developers wouldn't have bothered with the setting at all and instead just used the interlaced=true technique.

[Trahald]

Cool.. then we can agree to disagree ;)

[SiliconSoul]

argh... i just did a search for this because i noticed that doifast4u set interlaced=true on a progessive source and was hoping it would not destroy it... so should it be false when it is progressive.... we know that it must be true when it is interlaced... or can it be false :p

[SiliconSoul]

argh... i just did a search for this because i noticed that doifast4u set interlaced=true on a progessive source and was hoping it would not destroy it. so should it be false when it is progressive? we know that it must be true when it is interlaced, or can it be false? :p

[Trahald]

well.. i am happy with the output with the interlaced=true on. its easy to test.. run on of the scripts dif4u made in media player full screen. then close media player, change it to false and run it full screen. which ever you are happier with you use (although you would have to manually edit all your scripts from then on if you choose 'false')

[Eyes`Only]

I absolutely cannot see a difference. As for the comment about avisynth developers, there are several of their 'switches' that I can see no need for, nor noticeable difference with use/non-use of. And if you're going to remark about avisynth developers, how can they be infinitely wise if I still have to incorporate 'workaround' addaudio scripts just to keep my users from crashing their CCE? ;)

[Matthew]

Originally posted by Eyes`Only
how can they be infinitely wise if I still have to incorporate 'workaround' addaudio scripts just to keep my users from crashing their CCE? ;)

I don't think it valid to compare a bug associated with using one of many programs that accepts avisynth input, and a true/false setting that the developers specifically designed to treat a certain type of content better.

I'm not denying that as a matter of practice the difference may be generally unnoticeable (and don't dispute the default setting), but I think it makes sense to defer to the developer(s) on an issue like this (and FMalibu's analysis confirms that there is a difference, even if only the purists care). Just as you wrote DoItFast4U, so you know what the internal settings do and do not do ;)

[Eyes`Only]

Hmm I do? hehe :P

Hey I think if you look at my track record I'm a firm believer in incorporating workarounds in my app to help with flaws in other's apps, just wish other developers were the same. Not saying the developers are bad, obviously it's one of the most useful apps in our universe! But too bad the same ideals about making things easier for the end-user aren't shared. At least I do have a workaround to offer users, it would really suck if I didn't at least have that.

[Matthew]

Well, the avisynth "audience" is much broader in scope than yours...the MPEG-4 crowd for instance. And not unrelated to that, they have to consider all the issues with plans for internal filters/features. So they may have more pressing issues to deal with :) Prioritisation is the word =)

Now, on the other hand, if you want to get annoyed about vsrip not properly supporting a single-angle set of vobs sourced from a multi-angle DVD, then go ahead :D

[Eyes`Only]

Thought I had the sub demux of angles with my app working correctly with vsrip

[Matthew]

I wouldn't know as I don't use DoItFast4U, with the occasional exception of DVD structure analysis :/

All I know is that when I made a movie-only backup of shrek recently I found that the subs weren't correct. I used vsrip after ripping angle 1 with dvd decrypter. I wasn't keeping the alternative angles as they were just the intro storybook in a couple of other languages.

[Eyes`Only]

vsrip was developed to assist me with my app, and I worked with the author throughout it's lifespan. If you use it externally, dunno what to tell ya, especially for a butchershop project. Works for me though. If you had used DoItFast4U to demux and not selected 'all angles' you would have gotten angle 1 only and in perfect shape :P

Interesting that you're using it for DVD structure analysis :D

[Matthew]

mmmm...maybe it wasn't vsrip's fault then...although I thought I'd read something here about the problem.

I prefer to butcher the DVD structure rather than the movie video stream. I don't find pleasant the thought of encoding a movie at 2700 kbit/sec for the joy of having to sit though logos/menus and the priviledge of crappy extras. It's all about having a toppest-quality copy of the movie.

I'm actually rather anal, just in a different way from yourself. Hell, I wrote an excel spreadsheet just so I could fix the constant 2 frame delay introduced by vsrip on movies with the atypical opening GOP structure (the same movies that caused 2 frames at the beginning to be lost with the standard version of DVD2AVI). How pathetic is that.

In regard to DVD structure analysis, I'll let one of my checklist txts do the talking:
"If retaining DVD structure then for each PGC check audio stream IDs using DoItFast4U!...they start at 0x80 so may have to use dummy tracks to retain stream ID...e.g. for PGC 2 if there only one track and it has ID of 0x84...then 4 dummy tracks will be required for that PGC."

[Eyes`Only]

how sad. I would have thought that someone that knows as much as you seem to would know how to remove PUOPs and keep everything and still have excellent main movie quality. :(

don't bother replying, I won't reply back. Unless you just have to reply, in which case have fun. It'll be as pointless as the act of destroying DVD art though.

[Matthew]

How can I not reply to that...and have the last word :P Nice baiting btw =)

I think it's sadder, and I am being semi-serious in saying this, that you seem unwilling to recognise that different people have different preferences, and that those preferences are not better or worse, just different.

I understand that some people find it important to retain all features on a DVD - even though I'm not interested in that. You get annoyed at the idea of having to leave out an estonian subtitle track you won't ever use. I get annoyed at the idea of having artifacts in my movie that will be there at 3000 kbit but not 4000+ kbit, even if I can't see them on a standard TV (sometimes I can though). But meh, it's only the backing up of DVDs after all.

Except, when all is said and done, blonde is better than brunette, there is no debate about that :sly:

PS: Using MenuEdit to blank logos, rather than remove PUOPs, is perhaps preferable...those things drive me up the wall at first site.