feature request: interlacedinterleaving

[scharfis_brain]

I want to interleave 3 (or more, it should be arbitary) clips in the following way:

frame of clip 1 :

XXXXXXXXXX
XXXXXXXXXX
XXXXXXXXXX

frame of clip 2 :

YYYYYYYYYY
YYYYYYYYYY
YYYYYYYYYY

frame of clip 3 :

ZZZZZZZZZZ
ZZZZZZZZZZ
ZZZZZZZZZZ

result of interlacedinterleave

XXXXXXXXXX
YYYYYYYYYY
ZZZZZZZZZZ
XXXXXXXXXX
YYYYYYYYYY
ZZZZZZZZZZ
XXXXXXXXXX
YYYYYYYYYY
ZZZZZZZZZZ

i don't know any instructions to achive that in avisynth...

[MfA]

This is way too esotheric, this belongs in a plugin :)

[kassandro]

Scharfi,
If you would have a serious application for such a plugin, I could easily make one. Actually I would divide the job into two filters. The first one, like the builtin Interleave, interleaves an arbitrary number of clips sequentially (i.e. the number of frames is multiplied). This is zero cost filter. The second, a generalisation of the classical weave, weaves a fixed number of frames vertically, like the classical weave with two frames. This filter is no more zero cost, but very fast (bitblt speed).

[stickboy]

Interleave already handles an arbitrary number of clips.

All you really need is a generalized version of Weave.

[scharfis_brain]

okay, then I will precise my request:

I need:

an arbitary weave()
and an arbitary separatefields()

so, I could select, for example, every fifth line starting with the seconde one of the picture...
meaning lines 1,6,11,16,17

this would be really really great, if someone could do such a filter.

[vion11]

Assuming no general solution is needed you could
achieve the result when preparing some bmps masking
out (un)wanted lines and combine output with overlay.

And it is possible to create these bmps/masks with
avisynth. Simply verticalstack some alternating
white/black blankclips to desired height.

[scharfis_brain]

vion11, that wont work.

I need to:

- cut out every 4th line of a clip, so the resulting clip is 3/4 height.

- reinsert after some processing that missing line.

[kassandro]

Scharfi,
here (http://home.pages.at/kassandro/weave.zip) you can download the multi line weave. Usage: Weave(int "frames"). frames=2 is the default. It then behaves like the builtin weave. The number of frames and the frame rate is adjusted. Strangely, the builtin weave works only with field based video. It should be just the opposite: input frame based and output field based, but who cares?
I have added the filter Extract(clip, start,period) to the plugin.
Extract(1,5) just extracts a clip with lines 1, 6, 11, 16, 21, ....
By obvious reasons Extract does not work with yv12 clips.

[MfA]

It takes fields and it outputs frames, why should it go from framebased to fieldbased?

[kassandro]

It takes fields and it outputs frames, why should it go from framebased to fieldbased?

For me field based clip has a field structure, i.e. has to be regarded as a composition of two fields (interlaced, telecined, ...). A frame based clip on the other hand has no field structure. Now you usually don't want to weave a field based clip, because it consists already of two fields. On the other hand, if I weave a frame based clip it becomes a field based clip, essentially it is now an interlaced clip with half the frame rate.

[stickboy]

Originally posted by kassandro:
On the other hand, if I weave a frame based clip it becomes a field based clipField-based really means "field-separated" (the video resulted from SeparateFields). Frame-based means "not field-separated". The semantic contents of the frame isn't relevant. (The original naming is poor.)

Weave is the opposite of SeparateFields; takes field-based input and produces frame-based output. Weave currently does nothing on frame-based input.but who cares?It's important that all AviSynth filters get the terminology straight.

[kassandro]

Originally posted by stickboy
Field-based really means "field-separated" (the video resulted from SeparateFields). Frame-based means "not field-separated". The semantic contents of the frame isn't relevant. (The original naming is poor.)

Weave takes field-based input and produced frame-based output. Weave currently does nothing on frame-based input.
If "field based" really means that the clip must originate from an output of SeparateFields, then there is a lot of confusion going on in this forum. So let's clarify this. Experts, what is field based?

[MfA]

Kassandro, it is very simple ... if you have a sequence of fields it is field based, if you have a sequence of frames it is frame based.

I think naming is spot on, the practice of processing interlaced content as weaved frames ... now that is silly and inefficient. Given the fact that the community has decided to be stupid about this issue and is unlikely to reform avisynth could give it its own type I guess, and avoid things like the ugly interlaced=true options for functions, but we would need three types then and not two.

fieldbased framebased weaved

[stickboy]

Originally posted by kassandro
If "field based" really means that the clip must originate from an output of SeparateFields, then there is a lot of confusion going on in this forum.Yes, there is. This is why Info() specifically uses the "field separated" terminology.So let's clarify this. Experts, what is field based?See this thread (and the threads it links to):
Frame/Field Based vs Interlaced/Progressive (http://www.avisynth.org/forum/viewtopic.php?p=94)

[stickboy]

Additionally, although the AviSynth documentation doesn't explicitly state it, it's implied:(from AssumeFrameBased/AssumeFieldBased)
AviSynth keeps track of whether a given clip is field-based or frame-based. If the clip is field-based is also keeps track of the parity of each field (that is, whether it's the top or the bottom field of a frame).The above wouldn't make any sense if "field-based" meant "interlaced".

(Nevertheless, the documentation ought to make this clearer, and I'm all for renaming them.)

[Si]

stickboy is just telling it the way it is (and doing a good job of it) :)

In my experience, Avisynth always evolves.

Calling the current developers is (IMO) not the best way to get changes made :cool:

regards

Simon

[tritical]

Maybe there should be, in big huge 30 point font, "These do not correspond to interlaced/progressive" in the documentation :). Though even among the original definitions there are inconsistencies since using:

assumeframebased()
weave()

does nothing, as weave() only accepts field based input. Yet, using

assumefieldbased()
separatefields()

still does something!! No wonder there is confusion :D.

[MfA]

How do you seperate a sequence of fields into fields?

Weaved frames are neither interlaced nor field based, they are just really badly deinterlaced :)

[kassandro]

If I correctly understand the discussion here, then all video sources are frame based from the beginning. They only get field based through avisynth filters like SeparateFields (in fact, the only one I know). That makes the distinction frame/field based a rather useless one, because the script writer knows this anyway. It should be very clear to him, that that the output of SeparateFields is not a normal clip and at some point he will either separate the fields into separate clips or will weave the fields together again.
On the other hand, it would be important to know for the script writer, whether a clip is weaved or not (I follow MfA's terminology here), i.e. whether the clip was encoded with the interlaced source flag turned on or not. Unfortunately, digital tv is always weaved no matter whether the video is progressive, interlaced or telecined.

[MfA]

If the video is true progressive (ie. not telecined) then no it isnt weaved, it is just plain progressive. Progressive video doesnt really have fields, and interlaced video doesnt really have frames.

From the thread above 3.0 seems to go the way you want though, it will indicate wether the sequence consists of frames or fields ... and give additional flags to understand if/how fields are combined into frames. BTW DTV never encodes in interlaced mode? That would suck, because coding everything as frames is really really bad for compression (ffmpeg for instance doesnt even support that mode).

[kassandro]

Originally posted by MfA
If the video is true progressive (ie. not telecined) then no it isnt weaved, it is just plain progressive. Progressive video doesnt really have fields, and interlaced video doesnt really have frames.

If you encode progressive video with the interlaced flag turned on, the video remains progressive. There is absolutely no doubt. There are, however, two drawbacks, firstly compression is inferior and secondly instead yv12 you get interlaced yv12 as your color space, which results in lower chroma accuracy.

Originally posted by MfA

BTW DTV never encodes in interlaced mode? That would suck, because coding everything as frames is really really bad for compression (ffmpeg for instance doesnt even support that mode).
You are dead wrong. DTV always encodes in interlaced mode. Why? Because they have mixed content. On one hand they have plain cinema film, which is of course progressive (in the US cinema films must be telecined and therefore also encoded as interlaced, they have no choice at all). On the other hand, the material filmed with electronic cameras like sports is always interlaced and must be encoded as interlaced. Thus, to be on save side they always encode as if all the material were interlaced. And as you rightly say, they waste transmission bandwidth through inferior compression and they waste color quality through interlaced yv12. In Germany it is even worse. Instead of caring about interlace these idiots care very strongly about mono and stereo and sometimes they realise in the middle of a film that this film is too old to be stereo and then they switch to mono causing all kinds of problems. I made the utility mp2chextm (http://www.mp2chextm.de.tf) to cope with these idiots. Yes, you are right, digital tv sucks. It is much better than analog tv, but it could be even better, if there would not be such technical idots at work.

[MfA]

There is no reason to use interlaced yv12 for progressive frames. If you do the yv12 color conversion in progressive and then simply seperate the fields it will look better whether you display it on an interlaced or a progressive display. To do it any other way is foolhardy (and please noone mention bleeding of chroma between fields again, both fields are from the exact same moment in time ... idiocy makes baby jesus cry, so please noone bring that up again).

So basically the downside of interlaced coding as far as chroma precision is concerned is that most people are idiots, not that you have to loose precision :)

About DTV, I misinterpreted you ... mea culpa.

[vion11]

This thread makes me unsure if after reading I've learned something,
have to forget something or better ignore it.

Nor I don't know either if scharfis_brains problem
is solved or not and if its solvable at all.

On the other hand there might some good tipps for other
user hidden between the lines here.

Is it possible to make a 90% lossless compression
on this thread to achieve an easy to read -

'Guide to the universe of conversion of fields to mono' :confused:

[Wilbert]

Maybe there should be, in big huge 30 point font, "These do not correspond to interlaced/progressive" in the documentation :) .
I added something in the docs about this:

http://www.avisynth.org/FieldbasedVideo

I still have to add something about fieldbased + YV12 conversions, and about avs 3.0.

What do you think about it? Is it clear, should I add/change anything?

[scharfis_brain]

DV-Video is always BFF (bottom first) no matter whether NTSC or PAL
(external Anlogue to DV-Video converter boxes produce BFF, too!)

ANalogue TV-Cards produce TFF Video

DVB and DVD commonly are TFF, but they *might* also contain BFF (which isn't used in common)

[Wilbert]

I switched them :D I will change it.

[scharfis_brain]

Kassandro, I digged out your weave.dll again in the hope to create a function that is able to restore pseudo anamorphic videos.
But unfortunately I cannot get it loaded into AVS.
It always throws "unable to load..."

[kassandro]

Scharfi,
a dll was missing. I did compile it again. There have now included also a bigger staticly linked version weaveS.dll. Put onyl one of the dlls into your plugin directory. Use the old link for downloading.

[scharfis_brain]

many thanks!