Convert PAL DV to Standard PAL

[Gabrielgoc]

I´ve to convert files PAL lower field first (DV) to Standard PAL, upper field first. Any suggestion about scritp? Avisynth 2.0x or 2.5x? I´m compressing later the file using TMPGEnc Plus.

Thanks

[Guest]

One trick for reversing the field dominance is to crop one line off the top and then use BorderControl() to duplicate the bottom line.

Note: Swapping fields is not the same as reversing field dominance.

[Si]

I've only ever played with a DV file once and just did it "by hand" as the saying goes, but I think a dedicated plugin would be quite useful.

I'll knock one up unless you want to Don?

regards
Simon

[Guest]

Go for it, Simon!

Why don't you post the functional spec here before you start coding?

[Si]

erm...

Version 1
Shift all lines up one except the top one.
Copy 2nd bottom line to bottom line.

Version 1.1
Maybe let use decide whether to shift down instead of up?

regards
Simon

[Guest]

erm... Color spaces supported? Name of plugin?

[Si]

what a task master

name: ReverseFieldDominance
Version 1 will support RGB and YUY2
It'll be compiled for Avisynth 2.5

Once you big boys have sorted out the YV12 chroma interlacing issues it might do YV12 in a later version. I'm just keeping out of the way for now

[Guest]

Sounds good to me. Thank you for your response.

[morsa]

Please, make a Vdub version at a near future.
Vdub users will be by your side!!

[Tsui]

insert this line into an avisynth-script to change bff to tff :

DoubleWeave().SelectOdd()


Greetings
Tsunami

[Guest]

Originally posted by Tsui
insert this line into an avisynth-script to change bff to tff :

DoubleWeave().SelectOdd()
Ingenius, but strictly, it is not fully correct as a general method, because it makes new frames with different field combinations. E.g., if we had originally:

1 3 5
2 4 6

Your method would make:

3 5 7
2 4 6

The dominance has been changed, yes, but the fields have been recombined. Probably in most applications (where reversing dominance is required) that is acceptable. But to maintain the original field combinations, you'd need the shifting method. Also, your method is a bit trickier to implement in a standalone filter.

Trivia point: Your method can also be done by:

SeparateFields().Trim(1,0).Weave()

[Guest]

Originally posted by morsa
Please, make a Vdub version at a near future.
Vdub users will be by your side!! Please see the attachment.

[Si]

Avisynth version 1.0 (as per functional spec :) ) available via my site or here (http://www.avisynth.org/FileHosting/users/siwalters/files/reversefielddominance10.zip) .

[Edit: URL corrected]

regards
Simon

[morsa]

Thank you Neuron!!

[vidiot]

...and thankyou Simon!
Have to try ASAP by myself.

One thing:
Why "bordercontrol"(?) and not something like PAL_DVbordercontrol,
or KTPDVBR (KeepThePalDvBorderRight) ;)

Harald

[hanfrunz]

Hello everybody,

>Version 1
>Shift all lines up one except the top one.
>Copy 2nd bottom line to bottom line.
>Version 1.1
>Maybe let use decide whether to shift down instead of up?
>regards
>Simon

mmmh, would'nt it be better to swap the even and odd lines like this?

Line 001 ---> Line 002
Line 002 ---> Line 001
Line 003 ---> Line 004
Line 004 ---> Line 003
...
Line 575 ---> Line 006
Line 576 ---> Line 005

So the first line of field1 is still the first line, but of field2. I Think this method is a little slower, but it is more correct. Or am i wrong? Maybe you you could let the user select the method?

hanfrunz

[Si]

@hanfrunz
Well, that corrects the temporal order but at the expense of the spatial field order.

Moving everything up by 1 line corrects temporal but keeps spatial order as well.

regards

Simon

[hanfrunz]

ahhh of course, i see! never thought about this.

thanks
hanfrunz

[Guest]

Originally posted by hanfrunz
ahhh of course, i see! never thought about this.
You must have missed this bit earlier in the thread:

"Note: Swapping fields is not the same as reversing field dominance."

:)

[McQuaid]

Note: Swapping fields is not the same as reversing field dominance.


Just curious, what exactly is the diffenece between the two? For example my capture card gets the field wrong and I always use field swap. Is field dominance also a hardware/driver issue or is it in some sources and not in others?

[Guest]

Field dominance simply refers to which field is displayed first in time, i.e., temporal order. Swapping fields means interchanging the fields of a frame. Swapping fields will reverse the temporal order, but it will also interchange each pair of lines, putting them spatially in the wrong position.

There are methods of reversing the temporal order without reversing the spatial order. Two of them were discussed in this thread.

Your capture card is simply putting each field in the "wrong" field of the output frame. That creates incorrect temporal and spatial order that can be corrected by swapping fields.

[Si]

A good guide (as pointed out to me a long long time ago by Donald ) can be found here (http://www.lurkertech.com/lg/dominance.html)

regards
Simon

[Si]

via my site or here (http://www.avisynth.org/FileHosting/users/siwalters/files/reversefielddominance11.zip) .

Now has optional parameter
shiftup (true/false, default=true)

regards
Simon
PS @vidiot et al - sorry for the wrong URL in the Version 1 post - I now know why you were confused by the name :o
Note to self - must test more often :o

[Guest]

>Now has optional parameter
>shiftup (true/false, default=true)

Good one, Simon. I agonized for about 10 seconds over it. :)
Then I decided to shift up because I thought the duplicated line would be less noticeable at the bottom.

[SomeJoe]

Originally posted by neuron2 Originally posted by Tsui
insert this line into an avisynth-script to change bff to tff :

DoubleWeave().SelectOdd()
Ingenius, but strictly, it is not fully correct as a general method, because it makes new frames with different field combinations. E.g., if we had originally:

1 3 5
2 4 6

Your method would make:

3 5 7
2 4 6

The dominance has been changed, yes, but the fields have been recombined.

A true statement, but the differing field combinations shouldn't matter. Interlaced video, in the strictest sense, is a stream of fields. There is no such thing as a frame in the analog domain.

We use the concept of a frame in the digital domain because our codecs and progressive displays work with frames, not the fields of interlaced video.

As long as each field is drawn in the space where it was originally filmed, and the fields are played back in the order that they were filmed, how they are grouped into "frames" is irrelevant, since they exist in that state only when packed inside the codec. Through whatever method they eventually get turned into an analog signal again, the grouping into "frames" disappears, and they are once again a stream of fields.

The only disadvantage I see to the DoubleWeave().SelectOdd() is that the first field of video is lost, which could result in audio sync difficulties, etc. But otherwise, it properly regroups fields to allow the opposite field dominance to be used, without changing either temporal order or spatial order of the fields.

[Guest]

@SomeJoe

Did you miss the part where I said this:

"The dominance has been changed, yes, but the fields have been
recombined. Probably in most applications (where reversing
dominance is required) that is acceptable."

But thank you for pointing out the sync problem.

[mf]

So what about stretching instead of duplicating a line ?

[Si]

@mf
Could you define what you want/mean by stretch?

regards
Simon

[mf]

Originally posted by siwalters
@mf
Could you define what you want/mean by stretch?

regards
Simon

Etou.... Uhrm. I wonder if it's even possible myself :rolleyes:. I was thinking about something with SeperateFields(), but if you do that anyway you won't have to drop one scanline, or am I completely being moronic on the subject now ? :p

[Guest]

Originally posted by mf
Etou.... Uhrm. I wonder if it's even possible myself :rolleyes:. I was thinking about something with SeperateFields(), but if you do that anyway you won't have to drop one scanline, or am I completely being moronic on the subject now ? :p It's not moronic because you could resize the frame vertically by one line after deleting one. The problem is that it will degrade the video, be very slow, and destroy interlaced material. Other than that...

It's so fun to resurrect old threads. :)

[bb]

Originally posted by neuron2
[...]It's so fun to resurrect old threads. :)
And this one is really worth it :)

bb

[Wilbert]

@Si,

I was looking at your filter. It seems that ReverseFieldDominance(shiftup=true) actually shifts down one line :)

[Si]

Test Source (do a right-click to download) RedGreen5.avi (http://www.geocities.com/siwalters_uk/RedGreen5.avi)

LoadPlugin("c:\av\avisynth\myplugins\reversefielddominance.dll")
AVISource("D:\VTest\RedGreen5.avi")
ReverseFieldDominance(shiftup=true)
return last

Seems to move the green lines up on my system.

However, looking at the code - I think it'll get it wrong with RGB inputs :o

Are you using RGB?

regards
Simon

[Wilbert]

Your example works fine.

I used the following RGB32 clip.


c = blankclip.AssumeFieldBased
v = c.blankclip(color=$ffffff).AssumeFieldBased
Interleave(c,v)
Weave
# first line is white


c = blankclip.AssumeFieldBased
v = c.blankclip(color=$ffffff).AssumeFieldBased
Interleave(c,v)
Weave
ReverseFieldDominance
# the first two lines are white

[Si]

Version 1.2 can be found here (http://www.geocities.com/siwalters_uk/reversefielddominance.html).

It should correct the mistake with RGB material.

regards

Simon

[WorBry]

Sorry for the extreme necromancy, but I wonder if the author, or an interested filter developer, might consider adding native YV12 support to this extremely useful filter, assuming this is possible. Just a thought :o

[Gavino]

An alternative that works for all color spaces is stickboy's JDL_ReverseFieldDominance function, found in his jdl-interlace.avsi (http://avisynth.org/stickboy/jdl-interlace.avsi).

[Mug Funky]

you can also abuse a resizer (this will also dupe the lines at the edges, which may or may not be a good thing depending on whether you have the dreaded "halfline" in your video or not).