Avisynth video properties (was "Help me solve this YV12 mystery")

[Guest]

Either I'm doing something real stupid or it appears that we still do not have a reliable YV12 decoder for Avisynth 2.5. First let me show you the problem I am experiencing. The attached JPEG shows on the bottom correct decoding, and on the top messed up decoding. Zoom in to see correct interlacing on the bottom and messed up interlacing on the top.

My tools are DivX5, VirtualDubMod and the filters given in the script below. If you want to experiment, get the small VOB from http://neuron2.net/dgraft/misc/sample.vob

Here is the test script I have used. Any explanation or fix would be greatly appreciated, otherwise I'll have to resume my modification of dividee's mpeg2dec to output YV12.

-------
### Dividee's ported to 2.5 YUY2 WORKS!
#loadplugin("d:\avisynthplugins\mpeg2dec.dll")
#mpeg2source("sample.d2v")

### MarcFD's decoders YV12 BOTH FAIL!
#loadplugin("d:\avisynthplugins\mpeg2dec3_094.dll") # ported to 2.5
loadplugin("d:\avisynthplugins\mpeg2dec3.dll")
mpeg2source(d2v="sample.d2v")
#YV12ToYUY2() # BUT WORKS WITH THIS

### Nic's MPEGDecoder YV12 FAIL!
#loadplugin("d:\avisynthplugins\mpegdecoder.dll")
#mpegsource("sample.vob")

### It works when displaying the VOB in DVD2AVI
### and when opening the VOB directly in VirtualDubMod

## It seems we do not have a reliable YV12 decoder for Avisynth 2.5!
-------

[Guest]

Oh, both DivX and XviD do this.

Since it works correctly when using YV12ToYUY2(), I am wondering if the codecs suffer from the chroma upsampling bug.

One candy cigar to whoever figures it out. :-)

[onesoul]

Have you tried the FixBrokenChromaUpsampling() command? Dunno if this will help.

[angelyote]

FixBrokenChromaUpsampling() requires YUY2 input. Since the problem doesn't appear after converting to YUY2 it won't work.

In case anyone's interested converting back to YV12 after going to YUY2 gives the same bad output.

Dave

[Kurosu]

Just a guess (haven't tested yet)...

Maybe the UV planes are stored as interlaced (see avisynth.org about YV12 interlacing or what was discussed in Turn thread to see what I mean) and both YV12 decoders assume to always have data 'progressively' stored. Or the data is badly reported or...

I'm far from understanding the field manipulation filters in avisynth but that may give an evidence to what is really happening...

[EDIT]
I think it's almost a problem of how the chroma interlacing is reported:
Please try those both scripts using YV12toYUY2() from MarFD's mpeg2dec3.dll

mpeg2source("sample.d2v")
YV12toYUY2(interlaced=false)

and

mpeg2source("sample.d2v")
YV12toYUY2(interlaced=true)


Replacing mpeg2source("sample.d2v") by mpegsource("sample.vob",-2) of course still works

[EDIT2]
Therefore, it's either the stream's chroma storage that is considered and reported to XviD/DivX5 filter as not interlaced, or their colorspace converting functions that always assume it's progressive.

[EDIT3]
Using ATI's YV12 codec, the result are exactly the same, so such a general error lies at the avisynth level (or the mpeg decoders badly report to avisynth that the chroma is stored interlaced).

[onesoul]

Originally posted by angelyote
FixBrokenChromaUpsampling() requires YUY2 input. Since the problem doesn't appear after converting to YUY2 it won't work.
Didn't know it required yuy2 input. Sorry...

[fisix]

at least when i used it last there was a check box in divx5.2or3 to assume progressive frames or interlaced frames when encoding, it was right near the place where you can have the encoder deinterlace your stream (doom9 says their deinterlacer isn't very good). this check box seems to be greyed out if it detects a progressive input. load the yv12 avs into virtualdub and see if the check box is greyed out etc etc, it might be a quick test to see if the frames are detected correctly.

shrug. sorry i cant be of any real help, no time to do the yv12 tests

[sh0dan]

The problem you are seeing is broken chroma-upsampling, but not necessarily in AviSynth. The problem is: When-ever an YV12-> RGB/YUY2 conversion has to be made, the conversion routine needs to know if the material is interlaced.

YV12ToYUY2() knows if each frame is interlaced because it can get the information from mpeg2dec. But when you get your information from an AVI source, there is no way for AviSynth to know if the source is interlaced or not - so it assumes the frame is not interlaced, and therefore upsamples chroma is if it is a progressive image.

The problem when displaying things in Vdub is, that DivX or XviD does not have access to the frame/fieldbased information, so they also assume frame-based, when decoding YV12->RGB/YUY2. YV12 fast recompress however will not give the problem if the recieving codec knows that the material it recieves is field-based. The only way to correct this for display is to do the conversion inside AviSynth for previews.

IIRC the converttoyuy2 reacts correctly if you put in an Assumefieldbased() before the conversion.

For the conversion to be accurate at all times with an AVI source, there needs to be a per-frame interlace-detection - probably mostly like the one in Telecide.
Converttoyuy2 should probably also react to the parity bit, but that's not easy to do right now, since the field->frame->field conversions are done at filter creation time (by automatically inserting separatefields/weave).

[Kurosu]

@Sh0dan

You're almost right... But AssumeFieldBased() does this for the whole sequence. On the sample.vob provided by neuron2, you clearly see a difference between:
- AssumeFieldBased().ConvertToYUY2()
- YV12toYUY2(interlaced=true)
- YV12toYUY2()

I think that at least at the avisynth filter level, it's an important matter: what members of vi / PClip / ... have to be modifed so that other filters have the right information at the frame level (I fear that the VideoInfo can't be changed on the fly).

Anyway, such a sequence is just what I needed to test the Turn() in interlaced YV12... (which make me see that a SeparateFields can't be used before Turn, as the field has been rotated after Turn).

[Guest]

Yes, I had concluded that the chroma upsampling is involved. The scary thing is that all my software players (BSPlayer, FMV, etc.) show the same artifacts when fed the AVS.

Is there not a way to tell DivX that the source is interlaced? Seems like a serious omission if there isn't.

We need to really think things through very carefully for Avisynth 3.0 in regards to proper per-stream and per-frame flags and their handling.

Thank you for your responses, gentlemen.

[trbarry]

What happens if you just deinterlace it and they use an AssumeFrameBased() statement?

- Tom

[Guest]

Originally posted by trbarry
What happens if you just deinterlace it and then use an AssumeFrameBased() statement? If I use Decomb, I don't need the AssumeFrameBased(), because it sets that correctly. Things look OK then. What concerns me now is that all the players seem to suffer from the CUE.

[sh0dan]

Is there not a way to tell DivX that the source is interlaced? Seems like a serious omission if there isn't.

Since VFW was not designed to handle interlaced material from design, there is no way that we can communicate that a source is interlaced. So DivX (as the converter) cannot know that the YV12 material it's decoding is interlaced.

The players basicply acts the same way = assuming framebased.

Both DivX and Xvid assumes that what they are decoding is frame-based, and therefore upsamples chroma as such.
It's another issue when they are encoding, since they both have interlaced mode, where they are given the information that they will recieve interlaced YV12 -> no problem. Decoding MPEG4 they of course know how it was encoded (interlace mode is stored in the MPEG).

[Guest]

I meant telling DivX through its user interface that the source is interlaced.

[sh0dan]

That isn't very easy.

When VdubMod opens the file it does it through the VFW interface. So in essense it opens it as an AVI.
When it does so, and recieves YV12 data it requests the currently installed VFW-codecs to decode the YV12 to RGB. This is where XviD or DivX kicks in. They decode the image for vdub, so vdub can display it in it's windows.

So the DivX conversion part is out of AviSynth control - it is handled AFTER the data is delivered from AviSynth. Thus we have no way to tell it about interlacing, etc.

When "Fast Recompress" is enabled, vdub ACCEPTS YV12, and does NOT request any filters to decode it -> speedup, and YV12 data is passed directly through the VFW from AviSynth->codec.

[Guest]

Yeah. And anyway it just seems to be a display/preview issue.

[trbarry]

Yeah. And anyway it just seems to be a display/preview issue.

That does seem to be the bottom line, and then only for interlaced content.

We had discussions of the chroma conversion problem when starting YV12 support and it was known that you couldn't reliably tell on a frame by frame basis in Avisynth (or after) whether a frame was interlaced.

But when we deinterlace or IVTC it then it becomes properly progressive and frame based. And if we don't convert anything but use fast recompress and tell Divx or Xvid to use interlace then that apparently works okay also.

And I basically deinterlace everything anyway so I guess it hasn't bothered me much. ;)

- Tom

[kilg0r3]

i don't know much about the problem. but, this is not only a preview problem please look at my posts here (http://forum.doom9.org/showthread.php?s=&postid=259519#post259519)

i get these steps / lines whenever ther are pure red or blue components in a picture. please take this problem seriously. its been three months now that i have been thinking it's just my eyes, it's just my eyes, it's just my eyes.

the last two sources (2001, spiderman) were both progressive, so it does not only pertain to interlaced content.

[Prosper]

I dunno what kind of video card you are using, but some of the beta versions of nvidia's detonator drivers do not dispay yv12 overlays correctly. Try using ffdshow alpha to render the video, and in the configuration, turn off yv12 output so it forces the overlay to YUY2 mode: that threw me for quite a loop for a while.

[kilg0r3]

overlay is not the problem. the screen shots are taken without overlay.

[Guest]

Originally posted by kilg0r3
i don't know much about the problem. but, this is not only a preview problem please look at my posts here (http://forum.doom9.org/showthread.php?s=&postid=259519#post259519)I only really see the issue on your pic of the guy in the ski mask. But I don't follow your reasoning of why it is not only a display/preview issue. If the upsampling is being done always progressive and the source was YV12 sampled as if interlaced, you'll have the problem. Seems to me the issue is the mismatch between the choice made during YV12 sampling and that done during upsampling. Just because the frame appears not to be combed you can't be sure it wasn't sampled using an interlaced chroma algorithm.

i get these steps / lines whenever ther are pure red or blue components in a picture. please take this problem seriously. its been three months now that i have been thinking it's just my eyes, it's just my eyes, it's just my eyes.

the last two sources (2001, spiderman) were both progressive, so it does not only pertain to interlaced content. See above. Can you make available a few frames of the source which is like the ski mask guy (not the other stuff which is not as clearly the same issue)? Thank you.

[kilg0r3]

hi neuron2.

i just thought when i get in the encoded file it can't be a preview thing only. my bad.

another problem is that i am not so familiar with the technical details of the, e.g., don't even know what upsampling means :blush:
kind of material do you need to identify the problem? screen shots, avis or vobs (how can i cut a vob :blush even more:?

btw. have you read my last post in the above mentioned thread? The strange thing is that the preview image of dvd2avi, when captured, does not seem to produce these artifacts.

[IanB]

The confusion evident in this thread looks like another example of the misuse of Framebased vs FieldBased in the YV12 codebase. See my ravings (http://forum.doom9.org/showthread.php?s=&threadid=45550) about this problem.

Perhaps there is a need for new filters YV12InterlacedToYV12Progressive() and
YV12ProgressiveToYV12Interlaced() that remap the chroma subsampling in the
YV12 colour space.

IanB

[Guest]

Originally posted by kilg0r3
another problem is that i am not so familiar with the technical details of the, e.g., don't even know what upsampling means :blush:YV12 has chroma samples only every other line. YUY2 and RGB have them every line. So, when the YV12 gets converted to RGB for display/preview, the extra lines of chroma must be created. That is called upsampling. There are two ways to do the upsampling, depending on whether the source material was sampled as interlaced, or sampled as progressive. That is not the same as saying whether it is interlaced or not, though it should be. You can sample wrongly or you can upsample wrongly. A mismatch between the two is what causes the artifacts. It's like this:

sample interlaced + upsample interlaced -> OK
sample interlaced + upsample progressive -> BAD
sample progressive + upsample progressive -> OK
sample progressive + upsample interlaced -> BAD

What kind of material do you need to identify the problem? screen shots, avis or vobs (how can i cut a vob :blush even more:?A VOB fragment you can make by using a VOB splitter tool that you can find on the doom9 downloads page!
btw. have you read my last post in the above mentioned thread? The strange thing is that the preview image of dvd2avi, when captured, does not seem to produce these artifacts. That's because it performs the upsampling correctly! And so does VirtualDubMod if you drop the VOB on directly.

[Guest]

Originally posted by IanB
The confusion evident in this thread looks like another example of the misuse of Framebased vs FieldBased in the YV12 codebase. See my ravings (http://forum.doom9.org/showthread.php?s=&threadid=45550) about this problem.

Perhaps there is a need for new filters YV12InterlacedToYV12Progressive() and
YV12ProgressiveToYV12Interlaced() that remap the chroma subsampling in the
YV12 colour space.

IanB I'll review your ravings later. :)

But for now, your proposal for these remapping tools is an excellent one. I plan to do it. Thank you for thinking of it.

EDIT: It could be done with a general color space conversion suite, e.g., YV12InterlacedToYV12Progressive() would be:

YV12ToYUY2(interlaced=true)
YUY2ToYV12(interlaced=false)

We have the YV12ToYUY2() filters in mpeg2dec3, but the inverses are not there. I haven't looked at the internal ConvertXXX() filters to see if they can do the job. They don't have an interlaced parameter but maybe they observe the frame/field-based status???

[kilg0r3]

@neuron
a 'small' vob fragment is here (http://kilg0r3.cjb.net/downloads/yyy.vob). it is 10 mb. hope you've got a broadband connection. my isdn line moaned for half an hour.

[sh0dan]

I would like to have the time for a proper direction on this, but unfortunately too many external factors are pressing me now for having the time to properly deal with this.

- Handling of interlaced material in 2.5.0 is not very good (at best) - and AviSynth 2.5.0 is not very reliable on this area. :(

- IMO AviSynth should not have so many problems dealing with interlaced material, so this must be fixed!

- Your solutions are good enough for standard operation, but should not be necessary. They are patches over bigger problems, that should be solved gracefully by AviSynth.

- Some problems cannot be solved - as "wrong" YV12 chroma upsampling by external filters for display - those are however not a big problem as it will not have any influence on the final result.

- We (I for instance) should take the time, and get all conversion filters handle interlaced material as it should be handled.

[trbarry]

- Handling of interlaced material in 2.5.0 is not very good (at best) - and AviSynth 2.5.0 is not very reliable on this area.

Sh0dan -

Where do the problems lie? Is it just converting interlaced material YV12 <-> YUY2?

Does ConvertToYUY2 now do a properly different conversion depending upon the IsFrameBased flag?

If not can Marc FD's convert to YUY2 (whatever it's called) be manually specified instead to do it properly?

Are there any known problems in handling progressive (or deinterlaced) material still?

- Tom

[sh0dan]

Framebased processing is ok!

But as I work with interlaced video a lot of problems arise. Mostly because of the deeply mysterious GetParity.
I looked through field.h, and saw that it is mostly used for showing TFF or BFF.

Problems I encountered:

ConvertToYUY2 has problems with some pitches - making it impossible to use after "separatefields". This is probably a bug that never surfaced in XviD development.

Framebased/Fieldbased settings are switched (or at least illogical) in Separatefields / Weave. It seems it would have been so for a long time - but since it is affection other parts of AviSynth this is now getting problematic.

We need color conversion routines that are capable of converting interlaced YV12->YUY2 (and everything else) without breaking upsampling - MPEG2DEC seems like a logical place to start.

It needs testing, testing, testing.. Mostly on my part - that's the time-hog.

Currently AviSynth is in a non-compileable state in CVS - until that get's fixed, testing will not be that easy.

[kilg0r3]

the thing i don't understand is why i get the same artefacts with the old mpeg2dec and avisynth 2 and with nic's mpegdecoder.

@neuron2
have you downloaded the vob? i'd like to delete it from the server.
how could i use decomb to correct the problem?

[Guest]

Originally posted by kilg0r3
the thing i don't understand is why i get the same artefacts with the old mpeg2dec and avisynth 2 and with nic's mpegdecoder.

@neuron2
have you downloaded the vob? i'd like to delete it from the server.
how could i use decomb to correct the problem? I have it so go ahead and delete it. I am still investigating so please standby. Got distracted by MarcFD's new codec. :)

[Guest]

Originally posted by sh0dan
- IMO AviSynth should not have so many problems dealing with interlaced material, so this must be fixed!I've made a radical proposal at the avisynth.org forum. Let's follow it up there.

[sh0dan]

I agree very much with you on this issue actually.

Filters acting differently if the video is set to be fieldbased or framebased is not a working solution in real-life, so I actually agree that this paramter should be removed from the core.

Parity should probably remain, since it is needed to pass pairty when doing trims & splices of material that doesn't have the same parity (Parity is a per frame bool that shows if a frame is top-field or bottom field when separated, or TFF or BFF when interlaced video).

So I would definately go for removing the frame/fieldbased property.

[Guest]

@sh0dan

I see you prefer the followup here. :)

I've had a look at the source for Splice in edit.cpp and although there is a special method Splice::GetParity(), I don't see it being called anywhere. Ditto for Trim.

Please explain in detail in functional terms, why we need parity (other than possibly as a configurable default for functions that require an order parameter).

[trbarry]

I think I never properly understood how Avisynth was using FieldBased, etc.

However most (not all) clips are one or the other all the way through and also maintain the same parity. That does allow a codec to return that info and have it be automatically used for things like ConvertToYUY2, deinterlace, etc.

I did put in code in a recent version of TomsMoComp to use the parity setting though I never recommended anyone using it since it didn't seem very reliable.

Not sure what the answer is. I think I sort of like having this info associated with a clip if it could be made consistant and more or less reliable.

- Tom

PS-pls don't send me off to Avisynth.org again. I just got back from the round trip. ;)

edit: Parity is per-frame? I didn't know that either.

[scmccarthy]

@neuron2&sh0dan

GetFrame isn't always called by the plugin either is it? I think the five virtual functions are also callbacks. So providing a version of the callback functions changes the default behavior of the functions when AviSynth calls it.

Stephen

[sh0dan]

Originally posted by neuron2
[BI've had a look at the source for Splice in edit.cpp and although there is a special method Splice::GetParity(), I don't see it being called anywhere. Ditto for Trim.

Please explain in detail in functional terms, why we need parity (other than possibly as a configurable default for functions that require an order parameter). [/B]

Splice contains this code: bool Splice::GetParity(int n)
{
if (n < video_switchover_point)
return child->GetParity(n);
else
return child2->GetParity(n - video_switchover_point);
}

GetParity is used for maintaining TFF and BFF in advanced edits.

It works like this:

Every filter contains a GetParity call, that will return true or false based on the frame number requested.

If a frame contains interlaced material (with both fields in the same frame), GetParity(int f) will return true if the top field is the first first (TFF). It will return false if the clip is BFF.

When a video is separated, GetParity is used to determine which of two frames is the first. This is used to produce the same (BFF or TFF) parity when a frame is weaved from to separated fields.

The reason GetParity is a good thing to maintain is that it will ensure correct parity if multiple separated sequences are spliced, trimmed or similar. In mpeg2dec parity is derived from the MPEG2 headers.

IsBFF() and isTFF() is merely a supplement to the parity code (as I didn't know what it did).

(this is what I've been able to gather from looking through the current code).

The changes I propose will not break the current API, since it will not change any calls, but it is merely a matter of ignoring the function of SetFieldBased.

[IanB]

Okay we are back here again :sly: (other forum) (http://www.avisynth.org/forum/viewtopic.php?p=94)

My original problem is that in Avisynth 2.5 there are inconvieniences to using the
SeparateFields()/Weave() functionality in my standard Avisynth 2.0 scripts. i.e.
forwards compatibility is broken in the new version.

I did some research, read some code, compared the CVS history and reached the
conclusion my problem was caused by the usurping of the IsFieldBased() internal
method to provide IsInterlaced() functionality in the new YV12 code base.

I have offered some suggestions about how to unbreak the original SeparateFields()
Weave() functionality and provide the obviously needed IsInterlaced() resource
the YV12 codebase needs. I offer any help I can.

@neuron2 (Donald Graft)
...Remove all notion of parity!...
Unfortunately this would destroy any hope for forwards compatibility and make
me quite sad :(

My current plea is :-

Resolve that IsFieldBased() has nothing to do with Interlaced/Progressive:devil:

Leave the current SeparateFields()/Weave()/AssumeFrameBased()/AssumeFieldBased()
parity stuff alone. i.e. as per 2.0

Use some new way of determining Interlaced/Progressive that does not interfere with
any current functionality.

I await the next 2.5beta with baited breath.

IanB

[sh0dan]

The point is not to remove any functionality - just making is consistent.

As it were:

If framebased material (images with both fields in it) is served to separatefields, it separates it. It also marks the video as fieldbased.

If material marked fieldbased is handed to separatefields(), nothing is done.

If material that is has fieldbased property is handed to weave, it is put together again. If it doesn't, material is weaved with every second line from each frame.

I propose:

Separatefield always split material - no matter what it's marked. Weave always weaves frames together, halfens the framerate and doubles the size. We create switches for weave to make it throw away every second line. This way we don't have to deal with the dreaded properties.

[IanB]

Don't forget about Bob(), etc, if you really must do this.

IanB

[Bidoche]

@sh0dan

I am not sure whether changing behavior is a good idea, after all it's this kind of adaptive polymorphim which makes avisynth power.


Anyway, here are my two cents about all this FB stuff :

Maybe all the mess comes from a confusion between clip and frames properties.
FieldBased/Framebased is obviously a clip property.
But TFF/BFF are not, it's fields who should be marked as top or bottom.
Same for Interlaced/Progressive this should be a frame property.

So if we move the props at their good place, everything should be alright.

[trbarry]

I propose:

Separatefield always split material - no matter what it's marked. Weave always weaves frames together, halfens the framerate and doubles the size. We create switches for weave to make it throw away every second line. This way we don't have to deal with the dreaded properties.

What would be the property that determines which sort of color conversion would be done? My deinterlacers assume 2 fields in a frame, regardless of flags, and output 1 field in a frame, currently not setting any flags.

But I was previously suggesting setting AssumeFrameBased after the deinterlace step, which was probably backwards.

So let me get this straight. If I have a progressive clip it should be called FieldBased in order to have a correct color conversion done. Right?

I'll have to think about this one for a bit. I'm not sure a progressive clip and a field based clip created by SeparateFields should both get the same color conversion. Maybe we also need a progressive flag? Dunno.

Are any of these attributes passed along to Xvid or Vdub?

- Tom

[Guest]

Tom,

Progressive/interlaced is a per-frame property. It is a serious mistake to make it per-clip. Since we don't currently have per-frame properties, that is the source of your dilemma.

I'm supporting Bidoche's position now. :) My first intuition was to get rid of properties that aren't per-clip (because they caused these kinds of unnecessary dilemmas), but Bidoche is right that it's better to keep them but put them where they belong.

In this new scheme, to answer your question: A frame would have a per-frame property marking it as progressive or interlaced. For YV12, you could use that to do correct chroma sampling. It may be that the progressive/interlaced status is not known and is so marked. In that case, you'd fall back to a filter parameter. Also, a progressive frame can be separated, so field-based/frame-based would not be relevant to the color work. Note that after separation, an interlaced frame becomes two progressive frames, and the clip becomes frame-based. Anyway, field-based/frame-based is per-clip, so you wouldn't want to use that anyway.

After deinterlacing *a frame*, you would mark *the frame* as progressive.

[trbarry]

I'm supporting Bidoche's position now.

So am I, mostly, I think. ;)

But his last post crossed with my last one above. Anyway, is there currently a progressive flag passed along with each frame? MPEG2DEC has all this information but is it being passed along like (apparently) TFF & BFF?

And I am still not convinced that doing a SeparateFields creates a frame that needs either progressive or interlaced color conversion. Maybe I just didn't have enough coffee yet but I think that creates sort of a third possibility, an interlaced field with half the pitch. The chroma samples still don't represent points half way between the 2 lines.

One thing we definititely need is an agreed and rigorous definition of where these flags are and what the darn things mean. ;)

(but still keeping compatibility even with the counterintuitive ones)

- Tom

edit: I'm willing to change one or both of the MPEG2DEC's if we need more info from them.

[Guest]

Originally posted by trbarry
Anyway, is there currently a progressive flag passed along with each frame? MPEG2DEC has all this information but is it being passed along like (apparently) TFF & BFF? No. At least not in the D2V files from DVD2AVI 1.76. I've not looked at later versions. I think all available per-clip and per-frame flags should be put in the D2V file and then mpeg2dec* should put them into the corresponding (new) Avisynth properties.

And I am still not convinced that doing a SeparateFields creates a frame that needs either progressive or interlaced color conversion. Maybe I just didn't have enough coffee yet but I think that creates sort of a third possibility, an interlaced field with half the pitch. The chroma samples still don't represent points half way between the 2 lines. It depends on the algorithm used for the sampling. For example, if you have a 50-50 average, then separating makes a progressive-sampled with 50-50 average. If 75-25, you get a progressive with 75-25, which is not fully correct, but that results from the separation. The invariant is that after separation, each chroma sample applies to two adjacent lines, which is not the case for interlaced. The problem with separating YV12 comes from the nature of YV12, not from the property scheme.

While on the subject... Not everything uses the same sampling scheme and so that too can cause incorrect results. For example, if I take a 50-50 sampled frame and upconvert it using 75-25.

One thing we definititely need is an agreed and rigorous definition of where these flags are and what the darn things mean. ;) For sure. We should base it on the MPEG2 syntax, because that has all the needed properties in the right places. I will shortly post a proposed mapping from MPEG2 syntax to Avisynth properties. An advantage of basing it on MPEG2 syntax is that it is already very well known and understood.

[Guest]

Now I'm convinced that even field-based/frame-based should be per-frame. Here's why: MPEG2 has picture_structure, which codes a picture as either a field or a frame. In our world, our atoms are frames and not pictures, so we need to denote whether a frame contains a single picture or two field pictures. So, we need a per-frame property.

To further underline this, one can join a non-separated clip to a separated one as long as the sizes, etc., match. Also, a separated clip can have SelectEven() run on it. And a separated clip can be separated again. What is it then!? These show how problematic a per-clip property is, and how the dilemmas dissolve when the property is per-frame.

Field-based/frame-based is per-frame!

EDIT: It seems that field-based/frame based collapses into progressive/interlaced. Since our atom is always a frame, there is no need for a flag that is equivalent to picture_structure. Refer to the following post.

[Guest]

Tentative proposed properties:

Per-Clip
--------
size
aspect ratio
type (RGB32, YUY2, etc.)
frame rate
user-defined

Per-Frame
---------
progressive/interlaced
tff/bff
rff
user-defined

A properly written mpeg2dec can fully populate these. The information can be very useful to many filters.

A tool can be written that will scan an arbitrary AVI and populate the properties, as well as save the results to a file that filters could use. For example, combing detection as in FD could be used to determine progressive/interlaced. It wouldn't be perfect but could be useful.

But the first step is to agree on the properties and their meanings. Then we can talk about what Avisynth and filters do with them.

@IanB

Will this scheme resolve the difficulties you described? If not, why not?

[sh0dan]

Well, all I can say is, that I see no way of frame-based properties being integrated inti 2.5 - 3.0 is another matter.
Of course we should not change anything in 2.5 that will be changed in 3.0.

But as I see it we have two choices:

1) Make filters behave the same way - always.
2) Have intelligent filters that acts based on user-given properties.

The line is a fine one to draw. 1) Gives consistency, but will most likely add more properties to each filter. 2) May help filters produce more correct results without user intervention, but it also adds the risk of giving unexpected results.

From a programmer point of view, 2) is the most elegant - it will make AviSynth behave more intelligent.
From a user point of view 1) is actually what I see as the best way.

In my experience the best things about working with AviSynth is always knowing what the result will be, and being able to combine filters in strange ways. I find it very annoying, when weave() doesn't perform as I expected and I have to look through documentation to see why it isn't performing right.

IMO ConvertToYUY2(interlaced=true) is more logical than AssumeFieldBased().ConvertToYUY2(). It took me some time getting used to this, but now it actually makes more sense to me. Furthermore we don't risk filters not properly supporting these featues, ie. another deinterlacer than decomb may not set the frame/fieldbased property as it should. Should FieldDeinterlace skip, if the clip was set to framebased?

We might be creating more complexity, both code-wise and user-wise, without getting the payoff that should come from it. The Assume-things haven't been much more that annoyment for me user-wise - and seeing how little they actually matter I would be happy to get rid of them.

(of course I support custom perframe/perclip flags for filters, but that's entirely another matter).

[Guest]

@sh0dan

Yes, what I am saying is for 3.0. Are your remarks directed at 2.5 or 3.0?

I'm not so bothered about 2.5 but I'm curious what you think about the proposal for 3.0 properties.

[sh0dan]

2.5 (and subsequent 3.0 - as I wrote - I don't think we should change stuff in 2.5 just to be changed back in 3.0).

- So the question remains: Should the properties (Framebased/Fieldbased) be retained or removed from 2.5?

Either way I'll code the changes. But it would be a nice thing for me to be able to remove them - IMO making usability of AviSynth better.

Another thought - the properties could become parameters for the source filter - that would be a compromise I'd be happy to make.