Removing Even/Odd Lines

[ArgoZero]

My requirement is to remove all odd (or even) lines from HD 1920x1080 video and in so doing halve the height of the video footage.

This seems easy enough for AVIsynth with:

AssumeFrameBased
SeparateFields
SelectEven

In theory I think this should produce 1920x540 output of just the even lines - and if the output is played (say via WMP) then that's exactly what you get.

The next step of actually encoding the finished video might seem easy enough but that's when everything goes wrong for me as I end up with a complete mess. What I get is what looks like an interlaced video which is still in 1920x1080 :mad:

I assumed it must be an encoder issue but I've now tried both MeGUI and StaxRIP with more or less similar results.

Can anyone suggest what I'm doing wrong or know of a solution that really works ?

[Didée]

AssumeFrameBased
SeparateFields
SelectEven
AssumeFrameBased

[ArgoZero]

Well, all I can say is genius!

I've been struggling with this for over a week now and that just never occurred to me :o

I guess the encoder 'saw' it as an interlaced video and yet WMP for some reason didn't and therefore played it normally.

Many thanks :thanks:

[Didée]

The encoder saw it as a "field separated" video, because that's what you have after SeparateFields, and that "flag" does not change after SelectEven/Odd.

When feeding a video that is flagged as being field separated, then the decoder is assumed to weave them back together during playback.

[Wilbert]

The encoder saw it as a "field separated" video, because that's what you have after SeparateFields, and that "flag" does not change after SelectEven/Odd.

Just for clarity. Only MeGUI treats field separated video that way right?

[tebasuna51]

Just for clarity. Only MeGUI treats field separated video that way right?

Not MeGUI, is the encoder x264 when read the .avs.
The same behaviour using only a command line encode:

x264 'parameters' input.avs

[ArgoZero]

When feeding a video that is flagged as being field separated, then the decoder is assumed to weave them back together during playback.
Thanks for that insight :cool:

At the risk of going off-topic slightly, what would you say good (x264) encoder options should be to maintain the integrity of the even line structure within the frame. I'd imagine many encoders would attempt to interpolate the 'missing' lines but this is certainly not wanted.

In case you're wondering what this is about then the idea is to merge the two sets of odd and even lines but at a later date (hence the importance of maintaining the integrity of both sets)

[ajp_anton]

What about using pointresize to remove lines?
pointresize(width,height/2, 0, 0/1, width, height) #like this I think

[ArgoZero]

What about using pointresize to remove lines?
pointresize(width,height/2, 0, 0/1, width, height) #like this I thinkBefore Didée's answer I did indeed try PointResize.

The problem was I couldn't work out a definitive way of selecting BOTH even and odd lines without using a convoluted method of changing colorspace (I think that's the right term) using the PointResize line selection bug - all in all very messy indeed - compared to the far more elegant:

SeparateFields.SelectEven

All the same if anyone knows another elegant solution.....

[Gavino]

The problem was I couldn't work out a definitive way of selecting BOTH even and odd lines without using a convoluted method of changing colorspace (I think that's the right term) using the PointResize line selection bug - all in all very messy indeed

???

All you need is basically what ajp_anton said:
pointresize(width, height/2, 0, 0) # select even lines
or
pointresize(width, height/2, 0, 1) # select odd lines

Only subtlety is that for RGB clips you need to use instead:
pointresize(width, height/2, 0, -1) # select even lines
or
pointresize(width, height/2, 0, 0) # select odd lines

[ArgoZero]

pointresize(width,height/2, 0, 0/1, width, height)
Sorry for not following your answer the first time :o
All you need is basically what ajp_anton said:
pointresize(width, height/2, 0, 0) # select even lines
or
pointresize(width, height/2, 0, 1) # select odd lines

Only subtlety is that for RGB clips you need to use instead:
pointresize(width, height/2, 0, -1) # select even lines
or
pointresize(width, height/2, 0, 0) # select odd lines
....and thanks for putting me right.

I suspected from the outset that a solution might exist using the parameters supplied to PointResize but unfortunately couldn't track down the documentation to make sense of them.

:thanks: to both

[ArgoZero]

Only subtlety is that for RGB clips you need to use...
Would I be correct in thinking that the use of the IsRGB conditional would cover this situation fully ?

...since in the application I'm thinking of using this scrip it would be disastrous if the odd and even line selections became transposed.

[Gavino]

Would I be correct in thinking that the use of the IsRGB conditional would cover this situation fully ?
Yes.
For example, to select even lines:

offset = IsRGB() ? -1 : 0
PointResize(width, height/2, 0, offset)

[ArgoZero]

Yes.
For example, to select even lines:

offset = IsRGB() ? -1 : 0
PointResize(width, height/2, 0, offset)
Many thanks again - that works superbly :)

The only peculiarity I've noticed is that 'even' lines so selected don't match those from SeparateFields.SelectEven :confused:

I'm guessing here but is that due to SelectEven being offset if used with an RGB clip or is it simply due to general confusion over what really rates as an even line (counting from 0 or 1 etc) ?

[Gavino]

I think the confusion is over your initial script:
AssumeFrameBased
SeparateFields
SelectEven

Since AssumeFrameBased also sets the assumed field parity to BFF, SeparateFields will put bottom fields in frames 0, 2, 4, ... and top fields in frames 1, 3, 5, etc. So SelectEven selects the bottom fields, ie the odd-numbered lines, counting from 0 as the first line of the original frame.

[ArgoZero]

Thanks for a very full explanation.