Problem: HDTV TS 59.97 Fps to DVD 23.97 Fps

[peterson28]

hi,
first, yeah i know about the search function and yeah i read every hdtv 2 dvd related article not only on this board but on the net...
ok, perhaps not all but many...
heres my problem: i wanted (and still want) to convert hdtv ts 720p to a dvd...
i used hdtv2dvd but the output file is 29.97 Fps and not 23.97 Fps, so there are a few same frames every second...
this looks strange on my tv...
so i tried some other programmes:
- hdtvtompeg2: when i convert the ts to mpeg2, the output file is still in hdtv resolution and 59.97 Fps...
- TMPGEnc Pro: output file is 23.97 Fps when i choose Film movie...
of course i choose 16:9 ascept ratio but in MPEG settings where i can ajust bitrate, etc. aspect ratio is 4:3 and i can not change that...
so the output file is 4:3 which is also not good...
-CCE: in that programm i cant even open the hdtv mpeg2-files...

would be great, if someone can help me...

[edDV]

You need to reverse the 3 frame 2 frame repeat process. This is easy to do if the frame cadence is constant but as others have told you, ABC seems to mix the cadence either by accident or on purpose to make this difficult for you.

I would think that if you performed the decimate on a segment by segment basis, you would have good probability of picking the right frames, but a quality control review would be required.

See this thread.
https://forum.videohelp.com/viewtopic.php?t=302112&postdays=0&postorder=asc&start=0


PS: I'll repeat what I said in that post here.

720p as broadcast on ABC is 59.94 frames per second. The original 23.976 film frames are repeated in a 3:2 pattern to build up to 59.94*.

You can't use normal IVTC or decimate by 2. You need to detect and remove the 3:2 repeat frames.

Simple decimate by 2 will get you a studder

AAABBCCCDD
A_A_B_C_D_
or
AABBBCCDDD
A_B_B_C_D_

What you want is
A__B_C__D_
@23.976

Live 720p is 59.94 frames per second from the camera. If you need to compress and will accept 29.97 fps progressive flicker on a good TV, then you can decimate by 2 to 720/29.97 progressive or do a reverse bob to make true 720/29.97i without flicker.


* this is the preferred format used by ABC but they do accept 1080i material for conversion. This is often the case for commercials which are almost always shot on film and distributed 1080i. HDCAM VTR's can interpolate 720p/59.94 from a 1080i tape but reversing this for film can get complicated.

1080i is normally telecined just like 480i. Conversion to 720p is most likely accomplished by a bob (line double) to 1080p/59.94 followed by a downscale to 1280x720. Or it could be done by IVTC to 1080p/23.976 followed by a downscale to 1280x720/23.976 and then 3:2 frame repeated.

When local HDTV origination starts, expect alot of this cross conversion.

[peterson28]

thanks very much for your quick answer...
but to which program do u refer?
because in hdtv2dvd i cant adjust the settings at all...

source is fox, so it shouldnt be a problem...

[edDV]

thanks very much for your quick answer...
but to which program do u refer?
because in hdtv2dvd i cant adjust the settings at all...

source is fox, so it shouldnt be a problem...

See the thread for the AVISynth decimate scripts.

FOX uses the same 720p format as ABC, as does ESPN-HD.

[peterson28]

See the thread for the AVISynth decimate scripts.

FOX uses the same 720p format as ABC, as does ESPN-HD.

ok, thanks for making this clear...
well, i hoped to avoid avisynth, but it is mentioned here so often, so i guess its the easiest thing just to get familiar with it...

[peterson28]

hey,
well i made an *.avs file with notepad and DirectShowSource("***.ts")...
but when i now what to open it with vdub, theres an error "you must use the "fps" parameter (C:\1.avs, line 1)"
so, what do i have to change now?

[jagabo]

DirectShowSource("***.ts", fps=59.94)

[peterson28]

man,
this doesnt seem to be so complicated at all...
thx very much...
but does anyone know the script for this 3 frame 2 frame repeat process?
and which app do u suggest for converting to mpeg2?
im only used to vdub and gordian knot for xvid-convertion...

[edDV]

Warning: You are ignoring the reports of cadence variability. If you loose sync, the picture goes to crap.

[jagabo]

You could try using the Decimate() function to remove duplicate frames:

DirectShowSource("***.ts", fps=59.94)
Decimate(5) #remove one of every 5 frames
Decimate(4) #remove one of every 4 frames
Decimate(3) #remove one of every 3 frames

Decimate(N) will remove 1 out of every N frames, throwing away a duplicate whenever possible. The above script will reduce 59.94 progressive fps to 23.976 and should work pretty well even with occasional cadence breaks.

[peterson28]

well, i made a proper avs-file which i can now open with vdub and gordian knot...
but when i try to open it with cce, it says frame size 1280x720 is not supported...
does anyone know how to solve this, code, plug-in, whatever?

[jagabo]

CCE won't go higher than standard definition resolutions, 720x480 NTSC, 720x576 PAL. You need to downsize to that anyway for DVD. Since you're in Germany I assume you want PAL:

LanczosResize(720, 576)

Then encode as 16:9 MPEG2 for DVD.

Also note that the Decimate() sequence I gave earlier is for NTSC 23.976 fps frame rates. The best way to convert that to PAL is to add

AssumeFPS(25)

To the end of your script:

DirectShowSource("***.ts", fps=59.94)
LanczosResize(720, 576)
Decimate(5) #remove one of every 5 frames
Decimate(4) #remove one of every 4 frames
Decimate(3) #remove one of every 3 frames
#at this point your video is 23.976 fps
AssumeFPS(25) #lie and say it's 25 fps for PAL

Then you have to speed up the audio to go along with it.

The other alternative is to leave the video at 23.976 fps and use DGPulldown to convert to 25 fps. This way you don't have to adjust the audio.

Not so simple anymore, eh?!

[manono]

And that script is going to be pretty slow, with the 3 decimates in there. I wouldn't do it that way unless the cadence gets broken all the time. And even if it does, I'd use other, better, and faster ways to achieve the desired fps. A simple:

SelectEven()
Deimate(5)

will work in most cases. Otherwise I'd try TIVTC's:

TDecimate(Mode=7,Rate=23.976)

or possibly Mode2 with a tweaked maxndl.

Before these other choices were available, I sometimes used 3 decimates, but it's just too slow now, especially when several passes are involved. Besides, there's no guarantee that script will catch all the dupes, or not remove unique frames, when the cadence is broken.

[peterson28]

thx, will try the above mentioned now...
easy? not really... lol

[peterson28]

man,
i added TDecimate(Mode=7,Rate=23.976) to the script, but now a strange error appears...
DirectShowSource("***.ts", fps=59.94)

LanczosResize(720, 480)

TDecimate(Mode=7,Rate=23.976)

frame size 1248x56 is not supported...
till now, all the error masseges made sense, but this is really strange...

[manono]

A strange error appears where? In CCE? Open the script in VDubMod for a real error message. Did you load the TIVTC plugin?

And since this is a TS file, much better would be to create a D2V project file using DGIndex, and then use MPEG2Source, rather than DirectShowSource. Read the QuickStart Guide that comes included in the DGMPGDec package that includes DGIndex and the DGDecode.dll for more information. A typical script might go:

LoadPlugin("C:\Path\To\DGDecode.dll")
LoadPlugin("C:\Path\To\TIVTC.dll")
MPEG2Source("C:\Path\To\Video.d2v")
TDecimate(Mode=7,Rate=23.976)
ConvertToYUY2()#for CCE

But like I said earlier, unless you find evidence of broken cadences (sometimes something other than 3 2 3 2 3 2), I'd stick with SelectEven().Decimate(5).

There's nothing really wrong with jagabo's script, by the way. It will do some things right, in a few cases where a simple SelectEven().Decimate(5) might fail. Like in the unusual case of 2 unique frames in a row. But his can easily fail as well, as it pulls out 3 dupes in a sequence of 5 frames, no more and no less. It can fail also in cases of broken cadences. And it is slow. TIVTC is slow also, but although I haven't compared the 2 scripts in action, I think it's probably quite a bit faster than is running 3 decimates. I expect that SelectEven().Decimate(5) is by far the fastest.

[peterson28]

thx very much...
it works now, and quality is good...
but the audio (i added the original ac3-file) is out of sync...
guess that because original was 59.40 Fps...
i tried besweet, but output file is 1:47 instead of 43secs...
how do i solve that?

[manono]

No, the length doesn't change when you decimate. If the audio is out of synch, it should be a constant asynch (off by the same amount all the way through), and adjusting the delay should fix it.

If you're in Germany, did you make a PAL DVD out of it and alter the length somehow? If you have progressive asynch (the audio gets more and more off as the video goes along), that would explain it. I don't know what you did, but if you speeded it up from 23.976fps to 25fps, then you'll have to speed up the audio by the same amount (BeSweet has a preset for that).

[peterson28]

well,
i want to make a 23.97 Fps NTSC DVD from a 720p 59.94 Fps HDTV-TS-file...
the picture quality after encoding with cce is pretty decent, but theres still the problem that when i mux the audio it gets out of sync although both the video and the audio file are same lenght...
so should i uncheck progressive frame in cce?

[manono]

so should i uncheck progressive frame in cce?

Why would you do that? Your source is progressive. To apply pulldown, the 23.976fps output has to be progressive. Checking or unchecking the box has no effect on the length of the file, and hence, no effect on whether or not the audio is out of synch.

Is the asynch constant? That is, is it off by the same amount at the end as it is at the beginning? If so, then just add in the correct delay when authoring. If your authoring app doesn't allow for delays, then get rid of it permanently using DelayCut.

If the asynch is progressive, if it gets worse as the video goes along, then something else is at work. But you said both the audio and video files are the same length, so that shouldn't be the case.