Pulldown of 25 fps to NTSC

[Guest]

But we have seen that at least one app required a freely chosen input rate, i.e., 23.97544. Do you want me to add an infinite number of checkboxes?

Anyway, GUI coding bores me.

Speaking of which, scharfi, with your fertile brain, I suggest that you should graduate from script writing to native coding. Think of the great things you could accomplish!

[scharfis_brain]

, i.e., 23.97544.

uh? what?

I thought one can only use mpeg-valid framerates?!?

*scharfi_becomes_hurry_to_test_out_some_things*

Speaking of which, scharfi, with your fertile brain, I suggest that you should graduate from script writing to native coding. Think of the great things you could accomplish!
I always deal (dealt) with this thought but was afraid of its learning process

EDIT:
wow! again!

I tried a 16.66667 -> 25fps conversion.
and it worked! I cannot believe that
now, I only have to test, whether it works in my DVD-player.

yeah. finally super-8 with progressive encoding on DVD

[Guest]

Originally posted by scharfis_brain
yeah. finally super-8 with progressive encoding on DVD

Hey, Mikey, he gets it!

Only the output frame rate needs to be legal.

Actually that should have been rejected, because 25 > 1.5 * 16.667. Hmmm.

[digidragon]

Well I sorted out the jerky playback in VLC and MPC.

Using mainconcept, although I specified progressive output, gspot reports that the re-encoded m2v is I/L TFF. However, it reports that TMPGEnc's re-encoded m2v is progressive.

So I did another re-encoding using TMPGEnc, but this time specified an interlaced output, and gspot reported it as I/L TFF. After running this through DGPulldown, VLC and MPC both played it without any jerkiness.

[Guest]

Originally posted by digidragon
Using mainconcept, although I specified progressive output, gspot reports that the re-encoded m2v is I/L TFF. However, it reports that TMPGEnc's re-encoded m2v is progressive.

So I did another re-encoding using TMPGEnc, but this time specified an interlaced output, and gspot reported it as I/L TFF. After running this through DGPulldown, VLC and MPC both played it without any jerkiness.

That's very important and I'm glad you pointed it out. The RFF flag is interpreted differently depending on the value of progressive_sequence and progressive frame, according to ISO. DGPulldown needs to set progressive_sequence to 0 and progressive frame to 1. This may explain why a few players got confused. I'll crank a new version right away.

[Guest]

Here's beta 8. This one clears progressive_sequence and sets progressive frame, so that the RFFs can be correctly interpreted. I want to see if this fixes the issue with the one balky player.

Now it shouldn't matter how you set your MPEG2 encoder, although it would be sensible to encode progressive.

http://neuron2.net/dgpulldown/dgpulldown100b8.zip

This one also corrects the 1.5 frame rate ratio test. Sorry scharfi, no 16.667 -> 25! But you can go to 24.

[JetlagMk2]

Um, 25 / 16.667 < 1.5.

[scharfis_brain]

This one also corrects the 1.5 frame rate ratio test. Sorry scharfi, no 16.667 -> 25! But you can go to 24.

I don't understand.

16.666667 -> 25 seems to work.
dgpulldown doesn't complain about anything.

[digidragon]

Thanks for beta 8. The progressive converted m2v files now play fine.

[Guest]

Originally posted by scharfis_brain
This one also corrects the 1.5 frame rate ratio test. Sorry scharfi, no 16.667 -> 25! But you can go to 24.

I don't understand.

16.666667 -> 25 seems to work.
dgpulldown doesn't complain about anything.

Darn those floating point comparisons! I'll fix it once and for all.

The most speedup you can get with flags is 1.5 times:

a a b
a b b

Two frames maps to three. You can keep repeating that but you can't generate more frames than 1.5 times the input count.

So, you've maxed out on flags such that your real rate is 16.67 * 1.5, but you've set the rate to 25. You'll get audio desync, won't you?

[Guest]

@scharfi

I'm not getting enough sleep. Forgive me.

25 / 16.666667 = 1.5, so it is OK.

[Guest]

Originally posted by JetlagMk2
Um, 25 / 16.667 < 1.5.

Like I said, it's a sleep thing.

My calculation went like this. Well, 16.667 is close to 16. 16 plus half of 16 is 24. Too bad.

[Guest]

Originally posted by digidragon
Thanks for beta 8. The progressive converted m2v files now play fine.

Like I said before, you're the man!

[scharfis_brain]

@donald:
maybe you could add a numerator/denominator (in float) functionality to your gui?

so one can easily set up some weird ratios without bothering with looooooong floats.

[Guest]

First you didn't like edit boxes, now you want two more!

[mrslacker]

Originally posted by scharfis_brain
maybe you could add a numerator/denominator (in float) functionality to your gui?

so one can easily set up some weird ratios without bothering with looooooong floats.

That's not a bad idea. A triple text box dialog like:

24 * 1000 / 1001

would make sense. Then again, you'd need and extra level of precision to hit the famous 23.9754 with this approach. Although, confusion would ensue if it weren't hidden behind a clearly "custom" selection box.

[manono]

Can someone please explain to me where 23.9754 came from? It sure isn't from 24 * (1000/1001).

Is there something wrong with the traditional 23.976fps and 29.97fps?

[mrslacker]

JetlagMk2 lied to DGPulldown with that particular frame rate as the source to achieve the desired result, if I follow. This thread has revealed more than a couple instances in which a non standard input has some use. I don't see myself using any flagging pattern other than 23.976->29.97 and the occasional 25p source, but I can see why user specified frame rates could be useful.

[Paulcat]

Originally posted by neuron2
@Paulcat

Assuming you did everything correctly, which I cannot verify without watching over your shoulder, and that TMPGEnc is not doing anything untoward, we'd have to conclude that your player cannot play this flagging properly. You don't have any kind of 3:2 processing, automatic film mode, or progressive output enabled on it, I hope.
The fact that not all standalones can play this properly limits its value for any kind of mass distribution of a DVD authored this way.

Before concluding that your player is at fault, however, I strongly recommend that you process it with the deinterlacing and resizing done by Avisynth and not TMPGEnc. That way, you can examine the intermediate result to ensure that it is correct.

I'd have to learn how to use avisynth first! Actually, the file I made from the source material with tmpgenc at 25 fps plays just fine thanks, the file I made from the source at 29.976 fps with tmpgenc plays badly (duplicated frames are noticable), and the file I made with your pulldown plays badly as well. I did not even burn a dvd to try, they played badly on the PC (I only encoded 60 seconds of material to test). I see you are up to beta8, I will try this and see what the result is....

Man this thread is busy!

[Guest]

Originally posted by manono
Can someone please explain to me where 23.9754 came from? It sure isn't from 24 * (1000/1001).

Is there something wrong with the traditional 23.976fps and 29.97fps?

He was combining video from one DVD with audio from another. They were slightly different in length and the frame rate deviation corrected for that by forcing some extra fields to be inserted.