HDTV 60 fps guide ?

[Dark-Cracker]

Hi,

is there a guide on how to deal with HDTV 59.94/60 fps input file ? is it better to always encode them in 60 fps or down them at 29.97 or 23.96fps keep them in progressive or interlaced ?
i have try to made some search on the forum but the result is not very accurate because the keyword 60fps seems bogus.

with my lame knowledge i will try to explain the 3 cases i have see.

- first case is : the frame seems double you have repetition of each frames. so perhaps a simple selecteven/odd should do the trick (to obtain a 29.97fps) ?

- second case : 1 frame on 3 is interlaced, 2 different frames followed by an interlaced frame. perhaps a selecteven/odd followed by a stadard ivtc should work (to obtain a 23.97fps)?

- third case : each frame are different so i suppose we can encode it in progressive at 60fps or perhaps use a assumefieldbased followed by a weave and encode it in 29.97fps interlaced. ?

- forth case : 2 duplicate frames, 3 duplicate frames, 2 duplicate....etc (a real 3:2 pulldown on the full frame not on the filed)


i am not very friendly with these material if anyone have some tip to encode them correctly , or how to detect which case is it fell free to post an answer.

EDIT : little edit on the second case, the previous word "doubled" could be misunderstanding, or interpreted like a duplicate. And i have add the forth case.

Bye.

[*.mp4 guy]

For the second case senario you should use telecide or tfm then tdecimate, heres an example script.

Mpeg2source("C:\Capture.d2v")
tfm(d2v="C:\Capture.d2v")

Crop()#crop if you need to crop

Tdecimate(CycleR=3, Cycle=5)# This will decimate from a 59.94 fps source to 23.976 fps

[laserfan]

...with my lame knowledge i will try to explain the 3 cases i have see.

- first case is : the frame seems double you have repetition of each frames. so perhaps a simple selecteven/odd should do the trick (to obtain a 29.97fps) ?

- second case : the frame are doubled with a repetition but 1 frame on 3 is interlaced. perhaps a selecteven/odd followed by a stadard ivtc should work (to obtain a 23.97fps)?...
In the "first case" yes, I have seen these too, and I use exactly SelectEven only e.g.:
MPEG2Source("HD720psource.d2v")
SelectEven()
Crop(0,2,-4,-2)
BilinearResize(656,368)

I don't know is this is exactly your second case, but I have seen 1080i sources which have been oddly doubled, so that I have to do e.g.:
MPEG2Source("HD1080isource.d2v")
AssumeBFF() #or TFF as needed
SeparateFields().SelectEven()
Decimate(5)
Crop(2,4,-2,-10)
BicubicResize(1280,720,0,0.5)

I do not think your knowledge is "lame" at all--it took me forever to figure-out the above! ;)

Good luck!

p.s. The first result is 29.971 (having been clearly shot in video) and the 2nd is 23.976 (having its origin in film).

[*.mp4 guy]

I don't know is this is exactly your second case, but I have seen 1080i sources which have been oddly doubled, so that I have to do e.g.:
MPEG2Source("HD1080isource.d2v")
AssumeBFF() #or TFF as needed
SeparateFields().SelectEven()
Decimate(5)
Crop(2,4,-2,-10)
BicubicResize(1280,720,0,0.5)

When you do this you discard half of your vertical resolution, If you use telecide/tfm and tdecimate you can keep all of the vertical resolution.

[laserfan]

When you do this you discard half of your vertical resolution, If you use telecide/tfm and tdecimate you can keep all of the vertical resolution.Thanks, it seems to me that when I tried telecide it didn't work for some reason. I dunno if I've ever used TIVTC but I will give that pkg a try.

[neuron2]

it seems to me that when I tried telecide it didn't work for some reason For some reason? That doesn't sound like a very organized approach. I'll be happy to help you with it, if you care to provide a little more information.

[laserfan]

For some reason? That doesn't sound like a very organized approach. I'll be happy to help you with it, if you care to provide a little more information.Sorry, I was just dead tired and probably shouldn't have responded at all. It was a long time ago and I'd been trying lots of stuff--when "throwing away half the vertical resolution" as above worked to my satisfaction, I just declared victory and stopped trying...

[Daodan]

I also agree tdecimate (cycleR=3) is the simplest and probably fastest method (not to mention good).
*.mp4 guy, why did you throw that tfm there? Wouldn't that just slow things for nothing? Since there is not interlacing in 60 fps.

[laserfan]

why did you throw that tfm there? Wouldn't that just slow things for nothing?I would also ask, I wonder why some people & tools do Crop before decimating--wouldn't it be faster if you reduced the number of frames first, then applied crop to the fewer frames?

[Daodan]

Hum, I don't think it matters actually, since avisynth won't process the frames that are not requested. Either way would be the same from this point of view.

[foxyshadis]

In fact, crop before is always faster (taking into account that you may change the field order) because it's extremely fast no matter how large a frame, whereas IVTC gets exponentially slower the larger the frame size, because it has to analyse each pixel several times even if you'd later crop them away. (But yeah, tfm is just wasted on progressive video.)

If you crop mod8 on all sides, it will be fastest, otherwise you should use align=true to copy fresh so other filters can use sse properly (sse is very sensitive to mod8 and sometimes mod16 alignment).

Just a little trick if you need every drop of speed. ;)

[laserfan]

In fact, crop before is always faster (taking into account that you may change the field order) because it's extremely fast no matter how large a frame, whereas IVTC gets exponentially slower the larger the frame size, because it has to analyse each pixel several times even if you'd later crop them away.

If you crop mod8 on all sides, it will be fastest, otherwise you should use align=true to copy fresh so other filters can use sse properly (sse is very sensitive to mod8 and sometimes mod16 alignment).

Just a little trick if you need every drop of speed. ;)This is very interesting, good information, thanks! I'd been encountering some wierd color ghosting in my conversions, and found that it went away if I cropped *after* the field operation. Intuitively then it seemed I should do that every time. Clearly "intuition" is trumped by "understanding" every time, and I have a lot to learn yet about this stuff.

"mod8" means simply, evenly divisible by 8 correct?

[foxyshadis]

Which filter caused the weird chroma? Using crop without align=true can sometimes expose bugs like that, unfortunately. Old versions of MipSmooth did the same thing.

[Dark-Cracker]

hi,

i have see another 2 strange paterns for 59.94fps :

2 duplicate frames, 3 duplicate frames, 2 duplicate....etc (a real 3:2 pulldown on the full frame not on the filed)

does someone know how to retieve the correct framerate ? (perhaps neuron2 have an idear on the subject, if my question is not too silly :) ).

PS : i have correct the second case patern in my first post, it was : 2 different frames, 1 frame interlaced, 2 different frames...etc

i suppose the tdecimate(cycleR=3) should still work for the corrected second case ?

Bye.

[Dark-Cracker]

for the forth case , (AABBBCCDDD... pattern) perhaps a pulldown(0,3) should work ? but is there a better way using decomb or tivtc ?

Bye.

[neuron2]

Try this:

Decimate(5) # changes AABBB to AABB
Decimate(2) # changes AABB to AB

[Dark-Cracker]

hi,

i have made some test on the second case (cf my first post) and the decimatation of frame 3 doesn't work :( (tdecimate(cycleR=3) or decimate(3)) the video seems played very fast and the decimate seems to skip the wrong frames.

i have also try with a tfm() before the decimatation to change the 1 frame interlaced out of 3, in progressive, once it's do, this frame is changed in duplicate frame, but the result is choppy :(

the best result i could obtain is using tfm() to change my interlaced frame in progressive and don't remove it (even if it's a duplicate) and encode it at 59.94 fps :(.

if someone have another idear on how to handle this pattern feel free to post it.

Ps : i have made a quick try with FDecimate and the result is not really convenceid.

Bye.

[Daodan]

I think providing a sample would be the shortest way to get someone to give you 100% working results.+

[neuron2]

I think providing a sample would be the shortest way to get someone to give you 100% working results.+ Yes, exactly. If you post a sample, I'll be happy to look at it.

[Dark-Cracker]

hi,

yes it's what i have wanted to do but i was away of my home (where the sample is) i have add a sample here :

http://dark.pluridis.org/incoming/

post a msg once you get the file i don't have a lot of space/badwith so i will remove it asap.

thank u for you help.

++

[Alain2]

So this corresponds to your 2nd case ; strange indeed.. I had a look, it's like you described, a telecine over 3 frames pattern instead of the usual 3:2 pulldown. To deinterlace, the following script does it well on your sample:

mpeg2source("poc2.d2v")
tfm(d2v="poc2.d2v")
tdecimate(cycle=3)
assumefps(24000,1001)

[neuron2]

I have it but maybe you want to leave it for others to examine. After I say what I've seen, maybe Mug Funky or someone can comment further.

First I did a project with Honor Pulldown Flags and Decode AC3 to WAV. Then I served this script into VirtualDub:

vid=mpeg2source("poc2.d2v")
aud=wavsource("poc2 T01 3_2ch 448Kbps 48KHz.wav")
audiodub(vid,aud)

Looking at File Information I see video is 2.97 seconds and audio is 4.38 seconds. That is really strange.

Then I looked at the pulldown. The pulldown is 1 3 1 3 1 3 ... throughout. So I did "Ignore Pulldown Flags" and stepped through the video. It is smooth at the implied frame rate of 39.96 (2/3 * 59.94 is what you would get when ignoring pulldown). Then I thought what frame rate is needed to get the audio and video to match in length. We have now:

# Project made with Ignore Pulldown Flags
vid=mpeg2source("poc2.d2v").assumefps(27.096)
aud=wavsource("poc2 T01 3_2ch 448Kbps 48KHz.wav")
audiodub(vid,aud)

Now the audio and video lengths match but we have a strange base frame rate.

So, I have showed how to get a smooth video result that matches the audio, but I don't know why the audio and video lengths don't match.

It should all be repeated with a longer clip. Also, maybe a longer clip would show some duplicates after ignoring pulldown flags.

Where did you get this stream? Is it TIVO derived or something weird like that?

[neuron2]

So this corresponds to your 2nd case ; strange indeed.. I had a look, it's like you described, a telecine over 3 frames pattern instead of the usual 3:2 pulldown. To deinterlace, the following script does it well on your sample:

mpeg2source("poc2.d2v")
tfm(d2v="poc2.d2v")
tdecimate(cycle=3)
assumefps(24000,1001) Did you test whether the audio and video match? Maybe my calculated rate of 27.096 versus your 23.976 is just an artifact of cutting a short clip.

Also, no need for TFM when you can Ignore Pulldown Flags. Of course that assumes it is 1 3 1 3 1 3 ... throughout.

[Dark-Cracker]

i was working on the handle of 59.94 fps and a friend have send me a .ts trailer of poc2, i will try to have more info on the hdtv source, for the audio problem it's perhaps a problem occured during the cut (i have used HDTV2mpeg2) i will try the two script and check the audio synchro on the full sample (unhappyly i don't have enought space to upload it).
i will let u know the result.

PS : does this hdtv pattern occur often ? or it's a rare case ? (perhaps a bad conversion).

thank u for your help :)

++

[Dark-Cracker]

i think the problem was due to the cut, apparently there is no audio synch problem using alain2 way.

so with no bad cut and using the 27.096 fps i have a progressive audio out of synchro.

thank u for you help :)

PS : does someone have already see this pattern ?

Bye.

[*.mp4 guy]

You can get some really wierd dupe patterns with hdtv caps, I had one that went. 5 5 2 5 5 2 5 5 7 5 7 5 7 5 7 5 7 5 7 5 7 5 7...

[Alain2]

Did you test whether the audio and video match? Maybe my calculated rate of 27.096 versus your 23.976 is just an artifact of cutting a short clip.

Also, no need for TFM when you can Ignore Pulldown Flags. Of course that assumes it is 1 3 1 3 1 3 ... throughout.
I must say I never really looking into dgindex readme, I always honor the flags and deal with the fields in the avs script (mainly because I don't know what the pulldown flags are exactely; I will dive into the readme someday to better understand all that ^^). It seems safer to me to use something like tfm+tdecimate, just in case the stream is not consistent throughout.

For the assume(24000,1001), it seemed in synch with the very short sample we had, and as the video once ivtc was progressive and nice (no blend) but slow, I thought that the video had been accelerated for this weird telecine, but the sound was intact

[neuron2]

i think the problem was due to the cut, apparently there is no audio synch problem using alain2 way. Sure but still there's no need for TFM as "Ignore Pulldown Flags" will do it better and faster.

[Dark-Cracker]

@all
thanks for the advices, i will continu my tests :) have a good night.

++

[Dark-Cracker]

Hi,

just another question to know if i do the right thing.

for a 59.94fps clip with all the frame different (the third case in my first post) do i lost some information if i use :

#--- 59.94fps progressive to 29.97 fps interlaced
AssumeFieldBased()
AssumeTFF() # AssumeBFF() for BFF
Weave()
#--- deinterlace
Any stardard deinterlacer
#---

the result seems correct, but a bit choppy, i am not really friendly with no PAL material so does i lost some informations with the previous avisynth script ? or is it the right way to handle this sort of video ?

Thanks again for the help.
Bye.

[neuron2]

Won't that double the height?

Why not just do Decimate(2)?

[Alain2]

I agree with neuron2, and this will give you a 30fps clip with <=1/60th shutter speed ; if high motion doesn't look nice then it's possible to lower the equiv shutter speed tu 1/30th by addind merge(last,last.trim(1,0)) before the Decimate(2)

(if I understand well the explanations here (http://forum.doom9.org/showthread.php?p=814547))

[Dark-Cracker]

[sorry for the late answer, i have some internet problem]
oups silly me, i have post the wrong avisynth script.

i was speaking about this script :

#--- 59.94p to 29.97i
v = v.separatefields()
v = v.selectevery(4,0,3)
v = v.weave()
#---
#-- deinterlace
add a deinterlacer (Kernel or TDeint ...)
#--

but the result is choppy and the quality is average.

i have add a sample of original source here :
http://dark.pluridis.org/incoming/

Perhaps there is no way to encode it at a lower fps, Decimate(2) give a more choppy result.
If you have an idea on how to handle such material, feel free to post it.

Bye.

[Alain2]

Interesting to see 60fps progressive :) Anyway the decimate(2) should works nice on your sample, but actually just do a mpeg2source("your.d2v").selectodd(), and you'll have 30fps progressive, which already looks nice to me motion blur wise, and it's faster.
No need to separatefields / weave / deinterlace, it's all progressive and as you only want to divide the fps by 2, no need to play with fields...

[edit] Oups, no, I was confused because it was playing badly on my computer at this resolution ; the first part is 60fps progressive, the second is some kind of frame duplications, probably upconverting from a pulldown ; I can't look on it before tomorrow, but neuron2 will probably have given you a script to convert it properly by then ^^ btw it's already jerky on the source because of this pulldown.. so if it didn't bother you on the source, then the selectodd() method should be enough