View Full Version : NTSC DVD with originally PAL content to 25fps video
Zanthra
30th August 2008, 00:53
Okay, here is the deal. The content I have was originally recorded as 24fps video, but then turned into PAL, then converted to NTSC for this DVD. I think I need to decimate every 6th frame, then deinterlace to 25fps, but how do I make sure it only drops the duplicate fields, especially due to the dropped frame in NTSC?
I can live with the 4% higher speed, but none of the deinterlacing options in MeGUI's avisynth script creator worked to preserve the original quality.
Thanks.
Comatose
30th August 2008, 02:00
We'll probably need a sample to help you with this one :P
You can cut a short part of the DVD using DGIndex (use the [ and ] buttons to mark the starting and ending point, respectively)
Zanthra
30th August 2008, 02:48
How big a sample do you need? I have a 33 frame sample if that's enough. At the file sizes of DVD I don't really have the bandwidth to effectively transfer long clips fast.
http://winegarden.homeip.net/NTSC_to_PAL.demuxed.m2v
also http://winegarden.homeip.net/NTSC_to_PAL.d2v
I have a longer one, but I don't want a link on the internet to a 40MB file when I only have 60Kb/s upload here.
thetoof
30th August 2008, 04:16
#load your clip
mpeg2source("NTSC_to_PAL.demuxed.d2v")
#separate the fields and unblend them
separatefields()
cdeblend()
#put them back together after
weave()
#bob to 59.94fps
tempgaussmc_beta2()
#You'll have a 2 3 2 2 3 pattern (2 duplicates, followed by 3 others, followed by 2 others......), so you have 2 choices for decimation (uncomment only one at a time)
##If the pattern is constant use selectevery
#selectevery(12,0,2,5,7,9)
##You'll have to change the numbers to keep the 1st frame of the dups sequence (1st of 2, 1st of 3, 1st of 2 and so on)
##If the pattern is not constant (i.e. you tried selectevery and saw dups somewhere in the full stream), use an adaptative decimation method
#tdecimate(1,7,12)
##This will remove the 7 duplicates out of 12 frames to get back to 24.975fps
#You can then get back to the NTSC film rate and ajust audio accordingly
assumefps(24000,1001,true)
Comatose
30th August 2008, 07:47
I just wanted to clarify - that last true in assumefps is for sync_audio - it tells assumefps to "adjust audio accordingly"
thetoof
30th August 2008, 08:18
The AssumeFPS filter changes the frame rate without changing the frame count (causing the video to play faster or slower). It only sets the framerate-parameter. If sync_audio (which is false by default) is true, it also changes the audio sample rate to match the duration of the video, the pitch of the resulting audio gets shifted.
Meaning that you undo the 4% PAL speedup and restore the audio + fps as they should be (if, of course, your source was originally NTSC film)
Zanthra
30th August 2008, 08:43
Is there a difference between NTSC film and PAL film?
I see now how they upped the frame rate though. I did not notice the blending, and I guess there is probably no easy way to get rid of that without losing something. Cdeblend does not detect all blended frames, and even when cdeblend works, then the bob deinterlacer makes the picture jump up and down due to it trying to prevent the bobbing that is not present when you have several of the same parity fields in a row.
Is there a way to seperate the clip into two clips, one of top field, one of bottom field, then processes them and put them back together?
Thanks for all your help.
PS: It seems there are a lot of filters for 59.97fps interlaced -> 24fps progressive, but nothing from 59.97fps interlaced -> 25fps progressive.
PPS: Are there ever any sources where 24fps film is split into fields, then blended to get 59.97, if so would the same method be used?
Didée
30th August 2008, 12:26
@ Zanthra : This is a "fieldblended normconversion". If you search (http://forum.doom9.org/search.php) for "blended fields" / "fieldblending" and "normconversion", you'll get LOTS of information.
You'll be interested in threads talking about "unblend", "Restore24" and "MRestore" (in chronological order of filter's birth).
a = last
b = a .bob() .reduceflicker(strength=1)
c = a .YourBobFilterOfChoice() # render clip.
c.MRestore(dclip=b)
@ thetoof : I never tried it that way actually, but most likely you're giving cdeblend a hard time when you feed it with separated fields. There's a reason why MRestore and Restore24 work on (smart-) bobbed input, not on separated fields.
thetoof
30th August 2008, 18:30
Cdeblend does not detect all blended frames
I can't reproduce that issue... the rendering pass is fully deblended.
then the bob deinterlacer makes the picture jump up and down That, I can reproduce and it's the big flaw of the unusual approach I used. As you said, Didée, the filters were not chained the usual (and proper) way. However, it made me think of something. Read below for the suggestion/question/help request.
PPS: Are there ever any sources where 24fps film is split into fields, then blended to get 59.97, if so would the same method be used?
It's basically the same process, the only thing that changes is your target framerate in mrestore.
Now, about what I thought:
What if, instead of bobbing all the stream and removing the blends and dups afterwards, we used a method to replace the blended field by what it should be.
After separate fields, instead of simply copying the last or next field after declaring the current one as a blend, couldn't we recreate the missing field?
A dumb spatial-only way could be something like this:
#Unless I'm mistaken, if the clip is TFF, the even frames after separate fields are the top fields and the odd ones are the bottom ones.
a=current_frame (blended)
b=previous_frame
c=next_frame
#If current is odd
d=b.nnedi(1,dh=true).separatefields().selectodd()
#What I'm trying to do here is to use nnedi to interpolate the odd field and take it to replace the original blended one...
start until b ++ d ++ c till the end
I'm a conditional environment noob, so...
Ô mighty masters of avisynth, I'm calling for your help! :p
Maybe it'd work by simply replacing something at the end of cdeblend, but I just can't figure out what. It's the reason why I made this (http://forum.doom9.org/showthread.php?p=1177175#post1177175) post...
Processing speed is the first advantage that comes to my mind with this since we wouldn't need to bob the whole clip.
Adub
30th August 2008, 23:19
#Unless I'm mistaken, if the clip is TFF, the even frames after separate fields are the top fields and the odd ones are the bottom ones.
Hmm...I think you are right. If I remember correctly, the count is zero-based, so, yes, in TFF.separatefields(), the top fields would be frame 0, 2, 4, etc.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.