Pulldown of 25 fps to NTSC

[Guest]

Sure, put your idea forward. I've become attached to the pre-calculating idea because it makes the run-time code so simple, but I'm always open to ideas.

[daveidmx]

the model is based on a FSM, so the easiest implementation would be obviously be:

do()
-> put_next_frame_flags()

but as i understand it, you have to deal with the frames in the order they arrive, which is not in proper temporal order, correct?

tell me:
with your existing parsing code, do you need a function that will return a flags value based on an absolute coded frame number? It will be a bit of a trick, but its certainly do-able.

also: do you want to be able to handle input streams which already contain some other sort of pulldown, or only pure-progressive streams? A quick hack can handle it either way, but won't guarantee smooth cycles. To output smoothed cycles with arbitrary input is an order of magnitude more difficult.

[mrslacker]

neuron2,

I like the idea of 25fps@29.97fps via flags (if I understand this properly) and I'll let you know how my NTSC Sony handles it. If it works, I am curious about which progressive mode (FILM, VIDEO, AUTO) would produce the correct playback. Does the VIDEO_TS folder in guest/ contain output from your hybrid pulldown implementation? The Coded:Playback ratio isn't what I expected. If not, is that 25fps footage you generated handy? Thanks.

The success of this method will probably depend on whether the standalone being used attempts to read cadence or just reads the flags. I think better players will probably fail to playback, as they will be trying to detect improperly flagged content.

Sorry for interjecting where I have no expertise, but why can't the pattern files you included by generalized? I assume you generated them by repeating 3 0 1 2 2 x number of times, then 2 2 2 2 2, lather, rinse, and repeat. Is deciding the number of times to repeat an arbitrary sequence given another arbitrary 1000/1001 correction sequence the challenge at hand?

Good work!

[daveidmx]

Argh! OK so my Visual Studio installation is corrupt. This could take a bit.

[Guest]

Originally posted by daveidmx
but as i understand it, you have to deal with the frames in the order they arrive, which is not in proper temporal order, correct? Correct. You can use the temporal reference to determine the frame's number in display order. It just starts getting real tricky to implement that together with the 1000/1001 adjustment while not inadvertently changing the field order. I tried to write it a couple times, but I kept needing to look ahead in the stream and that is a nightmare. The way I did it keeps things clean and simple, and therefore more robust. I'm not saying it can't be done on the fly, but I don't see the point if it makes stuff hard to understand and maintain.

with your existing parsing code, do you need a function that will return a flags value based on an absolute coded frame number? It will be a bit of a trick, but its certainly do-able. I don't need anything; it's already coded and working. Anyway, I don't know what you mean by an "absolute coded frame number". There's encoded frame number and display frame number. See if you can generate output the same as tff25.pat on the fly. :)

also: do you want to be able to handle input streams which already contain some other sort of pulldown, or only pure-progressive streams? A quick hack can handle it either way, but won't guarantee smooth cycles. To output smoothed cycles with arbitrary input is an order of magnitude more difficult. Don't know yet. I want to see whether this works before planning further bells and whistles.

[Guest]

Originally posted by mrslacker
Does the VIDEO_TS folder in guest/ contain output from your hybrid pulldown implementation? The Coded:Playback ratio isn't what I expected. If not, is that 25fps footage you generated handy? No, that's something else. I'd rather not give you what I made, because I don't have matching audio for it. I'm hoping someone has a real 25fps VOB they can give us. Otherwise, why are we doing this? :confused: You can apply this to any VOB anyway; it just replaces the flags. So, without the matching audio, you have no reality check, so to speak. You can check that the playing time according to VDub remains the same, I suppose.

Sorry for interjecting where I have no expertise, but why can't the pattern files you included by generalized? You're right. If you generate a correct pattern file for your application, you can use it just fine with the existing EXE. I just meant I would include a tool for generating the pattern files based on the specified application.

Good work! We'll see. :p

[Guest]

It just occurred to me that my EXE could have generated the patterns to memory just before starting parsing, and then there would be no need for the file system. On the other hand, this allows for the user to experiment with creating his own pulldown patterns.

I'm going to try to make a correct 25fps stream from a 23.976 one by speeding up the audio as well.

[Inwards]

Originally posted by neuron2

Regarding the issue of 24fps vs. 25fps, if your stream is validly encoded at 25fps it has audio to match. If you just arbitrarily slow it down by changing the frame rate field, you're gonna end up out of sync. You said you just change it back to 24fps. But how can you do that without changing the audio as well? And what if you have real PAL content that is not just sped up film?


I suppose I did a poor job of explaining what I had attempted. Basically, I had a 25fps PAL movie which I resized to 720x480, but didn't bother to change FPS on. Then I used CoolEdit to stretch the audio by the appropriate amount. Finally, I ran pulldown.exe on the 25fps stream and converted it to 29.97fps with 3:2 pulldown. The authored DVD played just fine on the PC, but once I burned it, it acted weird on standalones. Sometimes the audio would break up, other times the video would pause. This was a few years ago, but I remember digging through the headers and coming to the conclusion that this was probably a problem with the VBV buffers no longer being correct.

I never tried your particular solution, but it's probably even money whether or not it would work. The base framerate is still the same, so who knows?

[Guest]

You're saying you did 3:2, which brought it to 31.25fps, and then you set it back to 29.97 in the frame rate fields of the MPEG stream, and then changed the audio to match? With all due respect, that seems bizarre. That *will* break the VBV buffer model.

With my approach, the VBV level is not an issue. Yes, there are more frames to display, but the frame rate is exactly correspondingly higher, so the buffer model is still satisfied. The encoded frames are still consumed at exactly 25fps. In your case, you are generating 31.5fps, and then forcing the display process to throttle it to 29.97. Not a good idea.

And besides, the whole point of the exercise is to avoid having to modify the audio.

[Guest]

I see now why we need to support elementary streams! I'll add that tomorrow and release an update.

[tyee]

I just tried the new version on my Sony and it works great. I synced up the audio at the beginning and it was still in sync after the clip ended (10 minute clip). Great work Donald!!

tyee

[Guest]

That's great! Please describe your complete work flow. How did you create the VOB that you applied DGPulldown to?

[Jeffster]

neuron2,

Do you still need a 25fps VOB for testing?
As I live in a PAL country I could probably find something to upload if you do, just not sure if it needs to be anything special of just from a genuine PAL DVD?

[Guest]

Thanks, Jeffster, but I've got a few now.

[Jeffster]

No problem :)

[Guest]

Of course, Jeffster, if you wanted to put one on my server, it would be useful. :)

I just completed my own experiment. The resulting DVD played just dandy on both of my standalones. I guess I'll go ahead and polish up the tool as described earlier.

[Jeffster]

OK, there should be something there in about an hour. Hope you find it useful for something. :)

[tyee]

neuron2

1. started with PAL 720x576 25p .vob clip
2. loaded clip in DGIndex to create project and demux .ac3 audio
3. loaded project into avisynth, along with 720x480 resizing
4. loaded avisynth to CCE to give .m2v elementary stream of 720x480 25p
5. muxed .m2v and .ac3 with ImagoMuxer to get .vob
6. ran dgpulldown on this .vob to get ntsc 720x480 29.97fps
7. authored this .vob with TMPEGAuthor to create DVD

tyee

PS. elementary stream support is really needed, I'll second that!

[Guest]

@tyee

Thank you for the description. I suppose the old adage about great minds thinking alike must be true, because I did it just like that too (except that I used TMPGEnc).

ES support will be released tonight.

[jptheripper]

thanks so much for all your work guys, this is gonna make things so much easier for me, and i find myself transferring alot of material from pal to ntsc.

congrats.

question with ES support, you would have to run it on both the m2v and ac3 files, correct?

[Guest]

Originally posted by jptheripper
question with ES support, you would have to run it on both the m2v and ac3 files, correct? No, just the video. You don't have to touch the audio at all. That is the entire point of the exercise!

[Guest]

Originally posted by Jeffster
OK, there should be something there in about an hour. Hope you find it useful for something. :) Thanks, got it.

[jptheripper]

ahh.. hence my ignorance on stream encoding.

ill stop bothering you so you can go back to work!

thanx again.

[jptheripper]

okay i am obviously not up to speed with you guys, but how do i run this program? is it use with the pulldown gui? or is there a way to commandline it that i am not seeing?

sorry to waste your time, but i would like to try to get this to work.

[Paulcat]

Coming from someone who has spent hours upon hours pissing about with converting PAL dvds to NTSC dvd's, this is MOST WELCOME NEWS!

So basically all I need to do now is demux the video (PAL, 720x576, 25 fps), resize it to 720x480, and use your program to alter the framerate to 29.976?

Now my question is can I use your program FIRST, to take a PAL (720x576, 25fps) elementary stream and change it to a 720x576, 29.976 elementary stream and THEN resize it?

I'm surprised no one has done this in a COMMERCIAL piece of software, maybe YOU should!!

I am unable to get to your ftp site from work, is there somewhere else I can get your program to try?

[jptheripper]

i think this is actually in procoder (commercial). Not sure if they use the same method

[jptheripper]

(yes im bored)

what would be really nice is if this, in the end, could be a

adjustfps25_29.97 type command in avisynth so it could all be done in the encoding stage, unless the entire video is needed (which i dont think because neuron has stated it goes frame by frame)

then when cce is run to resize out pops a 29.97 stream :)

the reason i say this is:

using rebuilder, if you added the resize and this line to the filters section, you could do pal2ntsc in 1 click!

[manono]

Hi-

i think this is actually in procoder.

No it's not.

then when cce is run to resize out pops a 29.97 stream

You don't want a 29.97fps stream. You want to keep it at 25fps, and then use DGPulldown to set flags to output 29.97fps. Big difference.

It'll be awhile before DVD Rebuilder gets around to implementing this, as it doesn't yet even allow IVTC of hard telecined NTSC DVD sources

And then sometime down the road (not too far down the road, I hope), I think it will become possible for people with home movies at framerates lower than 24fps (18fps is common) to use it to do the same thing, rather than jumping through all the hoops they do now by adding duplicate fields and frames to achieve 29.97fps. And silent film enthusiasts (me) will be able to take the original framerate, either from the DVD, or the original film source, and use DGPulldown. This will aid the compression tremendously.

[jptheripper]

i could have sworn it was in procoder, as i said, it may use a different method http://forum.doom9.org/showthread.php?s=&threadid=45459

as for ivtc, jdobbs has said many times why he hasnt implemented, i doubt he ever will.

and you are right, i dont want 29.97, i wasnt 25 flagged to 29.97, my question, poorly stated, was incoherent at best.

i am still learning

I guess i was asking if flags can be set on the fly thru avisynth with a filter as opposed to after with an exe.

[JetlagMk2]

I understand from reading this thread that if I use this program to reduce the number of encoded frames consumed per second that I will break the VBV buffer model. Taking into account I am unsure of exactly what that means my question is: can it be repaired?

My purpose is to slow down a "sped up" PAL movie. I have no desire to convert to NTSC or molest the beautifully encoded frames in any way. I have already taken care of the audio.

Any help would be greatly appreciated by this random-internet-person. :)

[jptheripper]

my understanding is that the only way to slow without changing the frames is to change the framerate. To do that would no longer produce a pal compliant stream

[Guest]

I have a version now that works on ES streams and doesn't need pattern files. I'll upload that tonight and link it at my web site for the FTP-challenged people.

Now, I'll have lunch and then answer the questions I see have been posted.

[Guest]

Originally posted by jptheripper
okay i am obviously not up to speed with you guys, but how do i run this program? is it use with the pulldown gui? or is there a way to commandline it that i am not seeing? It's a DOS command line program (though it will soon be GUI). So you open a DOS window and run it as described in the text file. Here is an example:

dgpulldown robot_1.vob e0 tff25.bat

Of course, you need full path names if everything isn't in the same directory.

You'll probably want to wait for the ES version tonight, otherwise you'll probably have to mux your own VOBs prior to authoring.

[Guest]

Originally posted by Paulcat
Now my question is can I use your program FIRST, to take a PAL (720x576, 25fps) elementary stream and change it to a 720x576, 29.976 elementary stream and THEN resize it? The version going up tonight can work on elementary streams. But to resize you need to decode the MPEG2, resize, and then reencode to MPEG2. DGPulldown should be run only on the final MPEG2 file.

I am unable to get to your ftp site from work, is there somewhere else I can get your program to try? You don't need FTP. Just click on the link I gave here. Here it is again:

http://neuron2.net/guest/dgpulldown001.zip

If I were you, I'd wait for the ES version. This one was just intended to test the concept. It's not fully practical without the ES support.

[Guest]

Originally posted by jptheripper
I guess i was asking if flags can be set on the fly thru avisynth with a filter as opposed to after with an exe. The tool processes compressed MPEG2 files. Such data does not flow through Avisynth. Your answer is no.

[Guest]

Originally posted by JetlagMk2
I understand from reading this thread that if I use this program to reduce the number of encoded frames consumed per second that I will break the VBV buffer model. This program simply adds flags to bring up the encoded frame rate to a new display rate. It does not reduce (or increase) the number of encoded frames consumed per second. The whole point is to keep that the same, so that the MPEG decoder remains happy.

My purpose is to slow down a "sped up" PAL movie. I have no desire to convert to NTSC or molest the beautifully encoded frames in any way. I have already taken care of the audio. You can't do that with flags. You have to decode the MPEG2 and then reencode it at the lower frame rate. If you simply changed the frame rate in the MPEG2 sequence header, your video would eventually overflow its buffer because you are consuming the data at a rate slower than the encoder intended.

An area for research would be to investigate whether games can be played with the stream's VBV buffering fields to overcome this problem. It may well be possible.

[Sir Didymus]

About the symmetry of the approach [very nice approach indeed :) ]:

It seems whatever PAL content [both truly interlaced and progressive] can be "DGpulldowned" to NTSC; but what about the reversal ?

I mean if you have a 24 fps source, properly telecined with TFF & RFF flags for display at 29.97 fps, you may apply by sure some specular approach [very interestingly it seems also in this case flags shouldn't be simply reset to a 1 0 1 0 1 0 ... sequence]; on the other hand, for truly interlaced NTSC material, with the TFF & RFF flags set to 1 0 1 0 1 0 1 0 ... in the whole sequence, it seems there is no hope... Am I missing something ?

Cheers
SD

[scharfis_brain]

Originally posted by Sir Didymus
It seems whatever PAL content truly interlaced and progressive] can be "DGpulldowned" to NTSC

I doubt that one can pulldown 50i contents to 60i.
It will result in a terrible field-mess on the TV (extreme periodic stutters)

[daveidmx]

@neuron2

I see you've beaten me again. But if you're interested, I have this extensible solution you can use.

Should handle any FPS pair for which its possible (FPS_IN < FPS_OUT < 3/2*FPS_IN) along with drop frame correction on a frame or field basis. and its set up to handle pulldown on incoming frames, though that hasn't yet been tuned and will be jerky. Will handle out-of-order frames.

[Guest]

Originally posted by daveidmx
@neuron2

I see you've beaten me again. But if you're interested, I have this extensible solution you can use.

Should handle any FPS pair for which its possible (FPS_IN < FPS_OUT < 3/2*FPS_IN) along with drop frame correction on a frame or field basis. and its set up to handle pulldown on incoming frames, though that hasn't yet been tuned and will be jerky. Will handle out-of-order frames. Sure, I'm interested. Where do I get it to have a look at it?

[Guest]

Originally posted by Sir Didymus
It seems whatever PAL content [both truly interlaced and progressive] can be "DGpulldowned" to NTSC; but what about the reversal? scharfis_brain is correct. You cannot usefully apply pulldown to interlaced source. You can deinterlace it first to make it progressive, however.

I mean if you have a 24 fps source, properly telecined with TFF & RFF flags for display at 29.97 fps, you may apply by sure some specular approach [very interestingly it seems also in this case flags shouldn't be simply reset to a 1 0 1 0 1 0 ... sequence]; on the other hand, for truly interlaced NTSC material, with the TFF & RFF flags set to 1 0 1 0 1 0 1 0 ... in the whole sequence, it seems there is no hope... Am I missing something ? You totally lost me. What is a "specular approach"?

[mrslacker]

Originally posted by daveidmx
Should handle any FPS pair for which its possible (FPS_IN < FPS_OUT < 3/2*FPS_IN) along with drop frame correction ...

So what other useful conversions fall into this category? It sounds like 23.976->29.97 and 25->29.97 are covered, along with their non drop_frame'd counterparts. Just curious where you are going with this.

[Guest]

For one example, as manono pointed out, lots of silent films have strange base frame rates, like 20fps. It would be useful to be able to pull them down to 29.97. But there's a limit. Flagging can increase the display rate by a maximum of 1.5 times, corresponding to this pattern:

13131313...

That maps 2 frames to 3 frames.

[mrslacker]

Originally posted by neuron2
For one example, as manono pointed out, lots of silent films have strange base frame rates, like 18fps. It would be useful to be able to pull them down to 29.97.
I see what you are saying. Not to be a pain, but 29.97 > 1.5*18. :)

You caught that too!

[Guest]

Great minds think alike!

[scharfis_brain]

uhm?!?

the MPEG-2 spec. says, that we have only those framerate to choose of:

23.976
24
25
29.97
30
50
59.94
60



how could 18fps, 20fps or any other arbitrary progressive framerate be encoded then?

who is carrying the framerate flag?
the 'unpulldowned', progressive raw MPEG
or the pulldowned result?

[Paulcat]

Originally posted by neuron2
...to resize you need to decode the MPEG2, resize, and then reencode to MPEG2. DGPulldown should be run only on the final MPEG2 file.


What would the difference be then if I used TMPGENc to resize to 720x480 and re-encode at 29.976 fps AS OPPOSED TO using TMPGEnc to resize and DGPulldown to alter the flags at the end? If I am resizing anyway, why do two steps when I can do it in one? Or does your method result in more stable picture?

[mrslacker]

Originally posted by scharfis_brain
how could 18fps, 20fps or any other arbitrary progressive framerate be encoded then?

It sounds like these 18/20fps silent films were telecined to 29.97. Read this (http://www.doom9.org/ivtc-tut.htm#IVTCForNTSC) little explaination though.

[mrslacker]

Originally posted by Paulcat
What would the difference be then if I used TMPGENc to resize to 720x480 and re-encode at 29.976 fps AS OPPOSED TO using TMPGEnc to resize and DGPulldown to alter the flags at the end? If I am resizing anyway, why do two steps when I can do it in one? Or does your method result in more stable picture?

TMPEGEnc would change the coded frame count. By setting flags, you would presumably optimize storage efficiency by retaining the same number of coded frames.

[Paulcat]

Originally posted by mrslacker
TMPEGEnc would change the coded frame count. By setting flags, you would presumably optimize storage efficiency by retaining the same number of coded frames.

Basically then I would have a smaller VOB at the end of it all, but is that the only difference?