Pulldown of 25 fps to NTSC [Archive]

scharfis_brain

12th February 2005, 19:27

And a one field stutter is usually tolerable. That's why 3:2 looks OK.

one field stutter is sadly very common with some broadcasters here in germany.

they do weird things with their movies :
sqeezing movie to show more ads using a speedup to 26fps
(using fieldblending)
hiding censoring with slowdown to 24 fps.
(fieldrepetition without blending)

both conversions are being made using a stupid bobber before, of course. It looks very 'nice' on TV, when the image details are jumping every other half second *grrrrrr*

Because of this I think, some (most?!?) persons would never notice the one field stutter.
(Our audiophiles probably will ignore it ;) )

but I personally would never make usage of a 24p telecine on PAL, because it is far more off-standard and shows this stutter.

Musical Films often were made using 24p telecine in past.
I've seen it on some older PAL-VHS cassetes (eg: Koyaanisqatsi)

Also I do not like 3:2 telecine. The fluidity of the movies is somehow different from the cinema-look.
PAL with speedup looks better to me.

recapitulating, I want to say, that I just was interested whether it is possible to do such pulldown with MPEG.

Maybe I'll give it a try on some musical movies, when you finished programming.

Guest

13th February 2005, 06:07

I'm ready for testing of Pulldown25. Can somebody stick a 25fps progressive MPEG on my server and notify me here? Thank you.

Guest

13th February 2005, 20:59

Well, no files showed up, so I made one by using FF on a 3:2 VOB and then AssumeFPS(25), reencode with TMPGEnc, and remux to a VOB. You gotta be creative!

I got Pulldown25 working and here it is:

http://neuron2.net/misc/pulldown25.zip

Please let me know if the resulting VOBs play OK on your players.

tyee

13th February 2005, 21:17

Thanks Donald. I was just about to upload but I'll give the program a try.

tyee

tyee

13th February 2005, 22:00

neuron2

I tried it with a .vob, but I don't get any output file in the same directory. I get the scrolling line starting with 'display frame ...' in the command window but that's it. What do you get.

tyee

Guest

14th February 2005, 04:45

Sorry, accidentally put up an interim debug output only build. Stand by...

Guest

14th February 2005, 06:12

OK, the download link points to the correct ZIP now.

Please read the text file carefully. I would appreciate hearing the results. Thank you.

tyee

14th February 2005, 06:23

Thanks Donald. Works much better. Plays OK in windvd and info says 29.97. I'll have to change res to 720x480 tomorrow before I can author. Let you know then.

Will this program work with .m2v files and .vob files??
tyee

Guest

14th February 2005, 06:37

>Will this program work with .m2v files and .vob files??

As it says in the text file, which you were supposed to read carefully (:)), it says any program stream. Vobs are program streams. If the M2V is a program stream, it will work. I can add support for elementary and transport streams if this works out OK. So please try it on the VOBs you want to author to a DVD and see if the DVD plays OK in the standalone players.

To identify a program stream, open the file in a hex editor and see if you see this pattern occurring in the file (in hex):

00 00 01 BA

That is a pack start code. All VOBs are program streams with fixed 2048-byte packs.

Guest

14th February 2005, 15:17

I just discovered it is generating illegal transitions. Please stand by for a corrected version.

Guest

14th February 2005, 17:20

Allowing for the 1000/1001 factor is turning out to be very tricky. It sounds easy but it's greatly complicated by several factors: the frames are encountered out of display order during parsing, you can't just count the parsed frames because that is not the correct count after pulldown, you have to suppress the pulldown temporarily without making illegal transitions that change the field order. I want to find a good solution that can be generalized later to other patterns. This will take some time. I can give you a version that doesn't allow for 1000/1001 if you want that right away for testing.

tyee

14th February 2005, 17:41

I was just looking at a sketch I made and how this all works. I can see that for every 5 PAL film frames we generate 6 video frames with a result of 5 progressive and 1 interlaced video frame. This would give 30fps. From here I'm trying to get my head around making it 29.97fps.

Would this version without the 1000/1001 factor generate 30fps instead of 29.97fps?

tyee

Guest

14th February 2005, 18:16

Actually, you get 4 progressives and 2 interlaced:

A A B C D E
A B C C D E

I could set the frame rate to 29.97 or 30. But if I set it to 29.97 without the 1000/1001 adjustment, the AV sync would drift out slowly because there would be too many frames.

I don't really have any doubt that the players can play these streams. But if you wanted to test without the adjustment, I can give it to you. Better to wait until I code the correct solution. As I said, it's pretty tricky and that's probably why no one has done it yet. To do it in a general way is even trickier. But, hey, I love challenges. :)

scharfis_brain

14th February 2005, 18:46

what does a Standalone-DVD-player do with a 30fps stream?

- slowdown to 29.97 fps ?
- drop to 29.97fps (dropping every 1000th frame)
- deny playback

tyee

14th February 2005, 19:02

Good question Scharfis_brain, that's what we'll find out.

neuron2
I think I'm going to have trouble authoring when using program streams. I always author with elementary streams (up until now anyway).

What I have just done is run the PAL 25p through DGIndex, fed this project (.d2v via avisynth, with NTSC resizing), to Mpeg2 encoder which gives me my elementary stream at 720x480 25p.

My authoring s/w will not accept this when set to author NTSC or PAL. (Illegal picture resolution it says!)

Will TMPEGenc accept this half NTSC and half PAL .m2v file or am I just doing it the hard way?

edit --
Well I muxed the .m2v with the .ac3 with ImagoMuxer to get a .vob of 720x480 25p. Ran pulldown25p on it then authored with TMPEGauthor, burning right now. Will update after viewing.

edit --
Good work Donald. Works good on my Sony NS700P. Where is this transition problem I'm supposed to see. What should I look for?

edit --
When I watched the clip, it started out with out of sync audio (which is ok because I didn't do anything to fix it), but after a few minutes it looks like it gets back in very close sync again. I don't know why this happens. Maybe someone else can try it too.

tyee

Guest

14th February 2005, 23:48

That version is not doing 1000/1001 correctly, so the audio will drift. Also, you may get field reversals. Please wait for the correct version.

Regarding program streams, just run it on the final VOBs!

Alcacia

15th February 2005, 02:59

Many of the better standalone DVD players out there have the feature "3:2 Pulldown". Presumably that means that they will ignore flags and output 24p as long as you are using the component video outputs, and your TV is an HDTV. I know, for example, that my Philips 727 has this feature.

Now, my Philips will also play both NTSC and PAL....but there may be players out there that have "3:2 Pulldown" feature, but don't support PAL output.

I wonder if there would be problems with this odd telecined 25p stream when played on standalones with "3:2 pulldown"...

manono

15th February 2005, 08:58

Hi-

Just saw mention of this in the Doom9 News. It looks as if he may have been a bit premature with the announcement.

what does a Standalone-DVD-player do with a 30fps stream?

It sets the drop_frame flag to slow it down to 29.97fps. No frames are actually dropped. The time codes are manipulated. Robshot has a readable explanation here:

http://www.doom9.org/synch.htm

where he says:

Well, to put it in simple term, DROP_FRAME here is in essence EQUAL a SLOWED_DOWN playback from a pure 30fps into the correct NTSC 29.97fps SPEED. In an MPEG-2 domain, this means that the 00 and 01 frames are dropped or SKIPPED from time code, at the start of each minute except minutes which are even multiples of 10.

If the drop frame problem is a temporary holdup, then you might try testing "telecining" off of 24.975fps (such as you'll get from RePAL or Decimate(6)), which will then output 29.97fps.

No player will give you back all progressive frames I don't think. They'll all deinterlace, but it doesn't really matter, because storing 25fps will still be a big improvement over the current solution of storing the full 29.97fps (or 30fps). In addition to which, there will be no blending. Just as neuron2 has seen some MPEG2 streams where a hard telecine was done on a 25fps source, so have I. I don't think I've ever seen an NTSC DVD where 25fps progressive images were stored, though.

Guest

15th February 2005, 15:27

I thought of a super elegant way to solve the problem in a robust, general manner. It's really simple, I make a prepared pulldown pattern file that is just read into memory and applied. The tff25.pat file would be:

2 2 2 2 2 3 0 1 2 2 3 0 1 2 2 3 0 1 2 2 .....2 2 2 2 2 3 0 1 2 2 3 0 1 2 2 ...

The "2 2 2 2 2" runs are inserted to implement the 1000/1001 adjustment and are aligned so as to not change the field order. The beauty is that it is easy to generate these pattern files in display order in advance, then read them into memory, and apply them in encoding order using the temporal_reference picture field. I allow for 1000000 frames, but could easily allow for more. Heck, a 1Mbyte file is nothing these days!

We can also do field dropping instead of frame dropping, but I'll try with frame dropping first because it is slightly cleaner.

I'll have a working release for you this evening. We can make a pattern file for any pulldown you can imagine.

Guest

15th February 2005, 18:01

Here is the revamped version:

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

Please advise on your results. If the whole idea works, I'll add elementary and transport stream support, full generalization of the pulldown, field dropping, ability to specify the output frame rate, and a GUI.

Inwards

15th February 2005, 20:04

Forgive me for being dense, but I don't understand quite what this program is trying to do. Does it actually re-encode the video stream or is it just playing with the the flags in the headers? I ask this because you will encounter numerous problems with trying to massage a 25fps PAL MPEG-2 into something that will play correctly on most standalones.

The last time I tried this I ran into hopeless sync problems. Even after re-encoding the audio stream to match, I found that I still had to perform tricks with the PAL video stream. At first I just resized it to 720x480 and encoded away at 25fps. Then I used pulldown.exe to convert it to 29.97fps with pulldown. What I hadn't counted on was that the VBV values were now hopelessly wrong, causing all kinds of audio breakup on every standalone I tried.

As I recall, I ran into enough other problems that I gave up on encoding tricks and just used AVISynth to convert to NTSC size and framerates (AssumeFPS(23.976), I think) and just encoded the whole thing properly.

Oh yeah, drop_frame and all other timing information stored in the headers are ignored during playback, so if you want this to work, you'll need to physically drop the frames in question.

Inwards

15th February 2005, 20:50

Originally posted by neuron2
I thought of a super elegant way to solve the problem in a robust, general manner. It's really simple, I make a prepared pulldown pattern file that is just read into memory and applied. The tff25.pat file would be:

2 2 2 2 2 3 0 1 2 2 3 0 1 2 2 3 0 1 2 2 .....2 2 2 2 2 3 0 1 2 2 3 0 1 2 2 ...

The "2 2 2 2 2" runs are inserted to implement the 1000/1001 adjustment and are aligned so as to not change the field order. The beauty is that it is easy to generate these pattern files in display order in advance, then read them into memory, and apply them in encoding order using the temporal_reference picture field. I allow for 1000000 frames, but could easily allow for more. Heck, a 1Mbyte file is nothing these days!

You could save yourself a lot of trouble if you did this the same way that pulldown.exe does. Calculate the modulus of the current real frame number using your pattern legnth and then apply the position of the result to your pattern. That way, you could just pass custom patterns via a switch like ---pattern=2222230122301223012.

Eg; using the above 19 character pattern, physical frame 2312 would have a modulus of 13, meaning that code "1" would need to be applied.

Guest

15th February 2005, 21:01

Applying pulldown.exe to a 25fps stream will generate a 31.25fps output stream (because pulldown.exe does only 3:2 pulldown). I assume that is why you ran into problems with sync.

Guest

15th February 2005, 21:03

Originally posted by Inwards
You could save yourself a lot of trouble if you did this the same way that pulldown.exe does. That's exactly what I did at first. As I said in this thread, it starts getting very complicated to allow for the 1000/1001 adjustment with that approach. Remember, pulldown.exe doesn't need to do that adjustment!

My new approach is not "a lot of trouble" in any case.

Inwards

15th February 2005, 21:13

Originally posted by neuron2
Applying pulldown.exe to a 25fps stream will generate a 31.25fps output stream (because pulldown.exe does only 3:2 pulldown). I assume that is why you ran into problems with sync.

No it won't. A 25fps progressive PAL stream is usually just a 24fps FILM stream sped up. If you run pulldown.exe on such a stream, it moves the framerate back to 24fps and adds the appropriate flags to get to 29.97fps. In my tests, the audio was still synched perfectly with the video, it just broke up ever few seconds on standalones. It worked perfectly on a PC.

Inwards

15th February 2005, 21:15

Originally posted by neuron2
That's exactly what I did at first. As I said in this thread, it starts getting very complicated to allow for the 1000/1001 adjustment with that approach. Remember, pulldown.exe doesn't need to do that adjustment!

My new approach is not "a lot of trouble" in any case.

I'm curious; given that the drop_frame flag is ignored on playback, how are you going to drop frames? You can't really cut single frames out of the middle of a GOP without re-encoding...

Guest

15th February 2005, 21:21

I'm not interested in arguing MPEG2 theory with you. The drop frame method is described earlier in the thread.

Inwards

15th February 2005, 21:33

Originally posted by neuron2
I'm not interested in arguing MPEG2 theory with you. The drop frame method is described earlier in the thread.

Sorry, Donald. I don't mean to get your dander up. I was merely trying to understand how you were trying to to achieve the end result. As far as theory vs. practice goes...

I am the author of pulldown.exe. Originally, pulldown.exe was a proof-of-concept prototype that I developed as a first step in creating a suite of three other programs: Anicide, Hybridizer and FieldOrder. After numerous experiments, similar to the ones that you are conducting now, I came to the conclusion that either I was not smart enough to create the first two, or that it was outright impossible. The last program, FieldOrder, was eventually included as part of the DoItFast4U package.

Anyway, unless I am misunderstanding what has been stated in this thread so far, what you are attempting (dropping frames based on the timecode flags) will almost certainly not work. I know, because I tested it myself three years ago. Then again, perhaps I am misreading this thread, or as I said previously, perhaps I just wasn't smart enough.

Best of luck.

daveidmx

15th February 2005, 21:45

whoa, since you guys are both online and posting right now, i better give you a heads up.

I'm putting together a quick model that should handle the conversion in a generalizable fashion. give me an hour or so and I should have something posted.

wheee!

Guest

15th February 2005, 22:12

@Inwards

Oh. Sorry. If you're a developer, you get instant respect. Forgive me.

OK, about the dropping... I don't drop anything. Instead I just don't do any repeats for a cycle so that there is one less display frame. So normally, I do (for TFF):

3 0 1 2 2

Where bit 0 is RFF and bit 1 is TFF. That makes 6 frames out of 5. Then every 1001 display frames, I use:

2 2 2 2 2

So once every 1001 I generate one less display frame.

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 we'll just have to see if this approach runs into the standalone player problems that you mentioned.

@daveidmx

I've posted a working utility. What do you mean by a "model"?

daveidmx

15th February 2005, 22:51

@neuron2
you said it was super-complicated to do the 1000/1001 adjustment, that your solution involved a pre-calculated file, and that it wasn't generalizable.

i figured out a solution that might help you. i'm just working out the details.

let me know if you don't think you need it.

Guest

15th February 2005, 22:55

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

15th February 2005, 23:16

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

15th February 2005, 23:19

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

16th February 2005, 00:19

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

Guest

16th February 2005, 00:33

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

16th February 2005, 00:40

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

16th February 2005, 01:15

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

16th February 2005, 02:38

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

16th February 2005, 05:35

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

16th February 2005, 06:15

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

tyee

16th February 2005, 06:20

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

16th February 2005, 06:30

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

Jeffster

16th February 2005, 06:35

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

16th February 2005, 06:54

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

Jeffster

16th February 2005, 06:58

No problem :)

Guest

16th February 2005, 07:04

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

16th February 2005, 07:43

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

tyee

16th February 2005, 07:44

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

16th February 2005, 14:48

@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

16th February 2005, 15:06

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

16th February 2005, 15:16

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

16th February 2005, 15:16

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

16th February 2005, 15:18

ahh.. hence my ignorance on stream encoding.

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

thanx again.

jptheripper

16th February 2005, 15:30

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

16th February 2005, 15:34

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

16th February 2005, 15:37

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

jptheripper

16th February 2005, 15:41

(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

16th February 2005, 16:26

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

16th February 2005, 16:39

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

16th February 2005, 17:58

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

16th February 2005, 18:24

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

16th February 2005, 18:38

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

16th February 2005, 18:51

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

16th February 2005, 18:55

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

16th February 2005, 19:00

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

16th February 2005, 19:09

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

16th February 2005, 19:57

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

16th February 2005, 20:02

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

16th February 2005, 20:04

@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

16th February 2005, 20:08

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

16th February 2005, 20:13

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

16th February 2005, 20:13

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

16th February 2005, 20:15

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

16th February 2005, 20:18

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

16th February 2005, 20:20

Great minds think alike!

scharfis_brain

16th February 2005, 20:20

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

16th February 2005, 20:27

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

16th February 2005, 20:29

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

16th February 2005, 20:30

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

16th February 2005, 20:33

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?

mrslacker

16th February 2005, 20:37

Originally posted by Paulcat
Basically then I would have a smaller VOB at the end of it all, but is that the only difference?
http://forum.doom9.org/showthread.php?s=&postid=603872#post603872

Also check the last couple pages of the thread referenced at the beginning of this thread.

daveidmx

16th February 2005, 20:46

@neuron2

Sent you a link via PM.

I'm still working on it, so i'll send you some updates as they come.

In the test module, you can change the calling parameters for pdf_init().

You can also switch the two lines just inside that for() loop:

//frame = i;
frame = i + order_table[i % 13];

to test out-of-order frame arrival.

Right now its set for 24->29.97, and fix drop cycle by field.

Also, for testing, in the .H I have the drop cycle set to 30 instead of 1000. (So I suppose its 24->29 then.)

I haven't yet adjusted the leading or implimented the auto-leading, but that's what i'm working on now.

And I have to tweak the initial conditions a bit.

Could I get ahold of one of your test samples?

Crap. OK, fixed that syntax error.

jptheripper

16th February 2005, 20:48

thanx for answering the questions.

so steps are

1. resize video to 720x480 25fps
2. run dgpulldown on m2v
3. remux
4. author new dvd.

nice little program you got there

Sir Didymus

16th February 2005, 20:58

Originally posted by neuron2
scharfis_brain is correct. You cannot usefully apply pulldown to interlaced source. You can deinterlace it first to make it progressive, however.

You totally lost me. What is a "specular approach"?

I see. Didn't want to talk about silly things; I was referring to the possibility of doing the reversal, for producing a PAL title, starting from a NTSC one...

scharfis_brain

16th February 2005, 21:00

Originally posted by mrslacker
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.

This is a joke, isn't it?

actually I do know, what telecining is.
It is one of my time killers to find out strange telecining patterns to re-progressivize them (eg. 24.45 fps into 59.94 fps).

Talking about telecing here is nonsense,
cause we want to try to AVOID telecining in the video itself.
the telecine will be made by the pulldownflags which neuron2's tool is putting into the stream!
the video itself is stroed progressive without any telecine!

But ontopic again:

neuron2 and I mean:
encode a video at 20fps without telecining.
so you'll end up with a progressive 20fps mpeg.
then add the pulldown flags.
they ensure the telecine for TV.
(the Standalone DVD-Player is actually doing the telecine)

so my question again.
is it allowed to store a progressive stream with
arbitrary (non-valid) framerate into a
container with pulldownflags to reach a
valid framerate (23.976, 24, 25, 29.97, 30, 50, 59.94, 60) ?

daveidmx

16th February 2005, 21:04

right now i can chose any input and output frame rate from the list:

1,2,3,4,5,6,8,10,12,15,20,24,25,30

any of which can be X*0.999 also.

so long as (FPS_IN < FPS_OUT < 3/2*FPS_IN)

In about a half an hour i should be able to handle other odd framerates other than those for input.

PS Is it necessary to output frame rates greater than 30?

scharfis_brain

16th February 2005, 21:08

right now i can chose any input and output frame rate from the list:

1,2,3,4,5,6,8,10,12,15,20,24,25,30

you've got that from TMPEGenc? right?

TMPEGenc internally does frame repetition (duplication, three, four, ..., and x-times) to reach a valid framrate of
either 24 or 30 or ... fps.

I think, this is NOT what neuron2 wants to achieve.

daveidmx

16th February 2005, 21:18

Not from TMPEG, they are the framerates that are factors of the LCM of 24, 25, and 30. Which is the time interval over which I calculate dropping or extending fields. But that will soon change to allow for more free setting of input frame rate.

Guest

16th February 2005, 21:34

Originally posted by 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? I agree with scharfis_brain's observation. The idea of my tool is to just flag existing MPEG2. If the encoded frame rate without pulldown is not one of the above rates, then re-encoding is necessary.

If you are close to one of these rates, you can use traditional ways to bring it to that rate, and then use flags to increase it further.

Guest

16th February 2005, 21:38

Originally posted by Paulcat
Basically then I would have a smaller VOB at the end of it all, but is that the only difference? It means that with the same bit budget, you can achieve better quality, as well as being able to encode progressively. And you retain the original progressive frames so that they are available again if you ever need them (DGIndex field operation RAW). And you don't have to muck with the audio.

mrslacker

16th February 2005, 21:44

Originally posted by scharfis_brain
This is a joke, isn't it?
...
Talking about telecing here is nonsense,
cause we want to try to AVOID telecining in the video itself.
the telecine will be made by the pulldownflags which neuron2's tool is putting into the stream!
the video itself is stroed progressive without any telecine!
...
neuron2 and I mean:
encode a video at 20fps without telecining.
so you'll end up with a progressive 20fps mpeg.
then add the pulldown flags.
they ensure the telecine for TV.

That's what I said (or meant) - stored progressive 20fps and do the telecine with flags. I'm not sure what I was joking about. I pointed to that particular part in the page by manono to get on the same page. I didn't intend to patronize.

Guest

16th February 2005, 21:45

Originally posted by Sir Didymus
I see. Didn't want to talk about silly things; I was referring to the possibility of doing the reversal, for producing a PAL title, starting from a NTSC one... That would be possible only if it were encoded at 25fps and flagged by DGPulldown. If so, you could use DGIndex field operation RAW. :)

daveidmx

16th February 2005, 21:49

@neuron2

So should I not worry about source frame rates other than standard?

My feeling was to be universal so whatever input frame rate could be flagged to the desired (standard) output rate.

But that may not be necessary if no encoder would produce, say, 20.5 fps.

So: universal input FPS, or factors-of-600 only?

Guest

16th February 2005, 21:50

Originally posted by daveidmx
Not from TMPEG, they are the framerates that are factors of the LCM of 24, 25, and 30. Which is the time interval over which I calculate dropping or extending fields. But that will soon change to allow for more free setting of input frame rate. scharfis_brain is correct. The input frame rate must be one of the legal MPEG2 rates. The output rate must also be one of them. The idea is to map the input frame rate to a new output frame rate by manipulating the flags.

Why would you bother trying to support any input or output rates that are not legal MPEG2 values?

Guest

16th February 2005, 21:55

Originally posted by daveidmx
@neuron2

So should I not worry about source frame rates other than standard?

My feeling was to be universal so whatever input frame rate could be flagged to the desired (standard) output rate.

But that may not be necessary if no encoder would produce, say, 20.5 fps.

So: universal input FPS, or factors-of-600 only? Legal rates only of course.

You have to very careful if you are thinking of accepting already flagged streams. They may not have constant base rates (hybrid content), i.e., the flagging may not be consistent throughout. So you can't just strip away the old flagging an replace it with new flagging. You'd have to track the base frame rate. Very difficult.

ANyway, the idea here was to start with a progressive unflagged stream and make it 29.97 via flagging. We should discuss the other possible applications before beginning general designs. IMHO.

These are the conversions that could be supported:

23.976 -> 24, 25, 29.97, or 30
24 -> 25, 29.97, or 30
25 -> 29.97, or 30
50 -> 59.94, or 60
59.94 -> 60

For any weird source files, they would have to first be massaged to one of these input rates.

daveidmx

16th February 2005, 22:00

@neuron2

Actually it can still be useful exactly because those other rates aren't compliant, in the same way that 25 FPS is not a valid rate for an NTSC DVD.

If, say, someone has captured a home movie as an AVI at, oh, say 22 FPS. They can encode it with 1:1 progressive frames. But of course that's not a valid rate, so then you can signal the bitstream to play back at 29.97 FPS in order to make a legal DVD.

mrslacker

16th February 2005, 22:04

Originally posted by daveidmx
@neuron2If, say, someone has captured a home movie as an AVI at, oh, say 22 FPS. They can encode it with 1:1 progressive frames. But of course that's not a valid rate, so then you can signal the bitstream to play back at 29.97 FPS in order to make a legal DVD.

What encoders let you produce a progressive 22fps mpeg? I know CCE is picky. Besides, why not just convertfps(23.976) on that AVI before encoding?

Guest

16th February 2005, 22:09

You cannot encode MPEG2 with a frame rate of 22fps. Are you at all familiar with the MPEG2 specification?

daveidmx

16th February 2005, 22:09

Originally posted by neuron2
You have to very careful if you are thinking of accepting already flagged streams. They may not have constant base rates (hybrid content), i.e., the flagging may not be consistent throughout. So you can't just strip away the old flagging an replace it with new flagging. You'd have to track the base frame rate. Very difficult.
Already got that part figured out (implementing it now). The tradeoff is that since we have to parse in file in-order and not in temporal order, the only way to do it suffers a subtle generational loss in synchronization. Therefore it should only be used if the source can't be made pure-progressive.
Originally posted by neuron2
ANyway, the idea here was to start with a progressive unflagged stream and make it 29.97 via flagging. We should discuss the other possible applications before beginning general designs. IMHO.
Sorry if i'm jumping ahead, it just seemed like the logical extension of the code i'd already written.

Obviously, the output rate should always be standard. But I figure the input rate may as well be free, to cover cases like in my last post, since it's not really more complicated.

@mrslacker
Originally posted by mrslacker
What encoders let you produce a progressive 22fps mpeg? I know CCE is picky. Besides, why not just convertfps(23.976) on that AVI before encoding?
Maybe not any will let you. But instead of convertfps(), using assumefps() will let you encode it with 1:1 frames while pretending its a valid rate, and then you re-flag that stream to play properly. Remember, convertfps() basically does exactly what we're trying to avoid.

mrslacker

16th February 2005, 22:15

Maybe not any will let you. But instead of convertfps(), using assumefps() will let you encode it with 1:1 frames while pretending its a valid rate, and then you re-flag that stream to play properly. Remember, convertfps() basically does exactly what we're trying to avoid. [/B]

As neuron2 said in a more direct manner than I, none will. However, Your nearest unflagged progressive frame rate would be 23.976. I guess you could encode a fast video and change the frame_rate flag to achieve what you suggest, but I would prefer to "massage" into a standard rate through a small frame rate conversion with avisynth. In that case standard pulldown would follow.

daveidmx

16th February 2005, 22:20

Originally posted by neuron2
You cannot encode MPEG2 with a frame rate of 22fps. Are you at all familiar with the MPEG2 specification?

Yes I am. And I'm by no means trying to imply that you or anyone else doesn't. Forgive me.

But remember that only the output must be compliant. Temporary files and in-between steps can pretty much be whatever you need in order to make something work.

Again, I'm certainly not trying to pick a fight. I know it's difficult to converse over a thread like this where you never quite get the intonation of the words, and can't deliver a thought face-to-face. Please be a little patient as we try to discuss this.

@mrslacker
Originally posted by mrslacker
I guess you could encode a fast video and change the frame_rate flag to achieve what you suggest,
Exactly. I'm just suggesting that, for the same reasons some people might want to flag a 25fps stream instead of convertfps()ing it, some might like to do the same with their 22 FPS home movie. No-one _has_ to do it, it's simply an option for those who wish to.

mrslacker

16th February 2005, 22:31

Originally posted by daveidmx
Exactly. I'm just suggesting that, for the same reasons some people might want to flag a 25fps stream instead of convertfps()ing it, some might like to do the same with their 22 FPS home movie. No-one _has_ to do it, it's simply an option for those who wish to.

OK. I don't have a copy of the MPEG2 specs on my desk at the moment ;), but wouldn't a change in the frame_rate flag break buffering at the least if no fields were repeated? A change in the opposite direction (speed up) being the more obvious example? Just a thought.

Guest

16th February 2005, 22:32

@daveidmx

OK, that will work. We are still limited to an original frame rate [before assumefps()]of 2/3 of the target rate.

EDIT: I'm not so sure. Now I think the VBV will get screwed up, as mrslacker observed. You won't be consuming encoded frames at the correct rate. You're trying to throttle during the display process, which is exactly what caused Inwards's experiment to fail.

daveidmx

16th February 2005, 22:40

@neuron2
Yeah, haven't totally thought through the VBV thing yet. Obviously in one direction it will get broke, but maybe the other way will work? I really don't know. Maybe I'll just play around later.

Say, do you have a 25 FPS VOB I can play with over here?

Guest

16th February 2005, 22:41

mrslacker pointed out the gotcha first. :)

I'll put up a VOB for you tonight.

scharfis_brain

16th February 2005, 22:45

is it possible to DROP a field with the rff-flags?
to make the explantation more simple, I only used integers instead of the 1000/1001 - framerates

goal: telecine 18fps to 60fps
(4:3:3 pattern, combed)

input stream 18 fps progressive (super8)

A B C D E F G H I J K L M N O P Q R

hard progressive (non-combed) telecine to 24 fps (2:1:1 pattern)
(use changefps(24) or selectevery(3,0,0,1,2) then encode with 24fps)

AA B C DD E F GG H I JJ K L MM N O PP Q R

then use the rff-flags to build s 60fields per second interlaced stream out of our progressive telecined 24fps mpeg:

this will work, as I assume:

A A B B C D D E E F G G H H I J J K K ...
a a b c c d d e f f g g h i i j j k l ...

but this is questionable (drops a field from the dupe of the 24fps mpeg)
shifted the pattern by one frame in time, as it WILL be the case on 1000/1001 correction:

A A B B C D D E E F G G H H I J J K K ...
a b b c c d e e f f g H h i i j K k l ...

or is the possible though?

if yes, it should be possible to telecine nearly all arbitrary framerates without a need to encode interlaced.

Guest

16th February 2005, 23:21

That appears to be just an instance of massaging to a legal MPEG2 rate first, as we discussed.

daveidmx

17th February 2005, 02:26

@neuron2
Posted a new version fixing some bugs.
Renamed leading to tracking.
Should now track sync on streams which already have PD flags, though it'll be jerky and will probably break VBV and is not reccommended for the time being. I'll work on optimizing that tomorrow along with the auto-tracking. Still only valid MPEG frame rates handled.
Yippee!

Guest

17th February 2005, 02:52

I've just completed a preliminary GUI version. I'm heading home now to test it a little and then upload it for y'all. Of course, it has ES support.

jptheripper

17th February 2005, 03:15

wow, such service

quick question,

once the stream is demuxed to m2v and ac3, reencoded to 720x480, then dgpulldown applieed to new m2v, do you have a prefered remuxing engine?

can the ac3 and dgpulldown'd m2v just be dropped into dvdlab pro?

tyee

17th February 2005, 04:06

can the ac3 and dgpulldown'd m2v just be dropped into dvdlab pro?

Sure, I would think so if it handles elementary streams.

tyee

Guest

17th February 2005, 04:22

OK, here's the GUI version with ES support. Please let me know if you find any problems. Thank you.

http://neuron2.net/misc/dgpulldown100b1.zip

Yes, I know I need a browse button for the input file entry. And a progress bar. :)

Guest

17th February 2005, 04:24

Originally posted by jptheripper
once the stream is demuxed to m2v and ac3, reencoded to 720x480, then dgpulldown applieed to new m2v, do you have a prefered remuxing engine? I use TMPGEnc DVD Author. I prefer it because it is all I have. :)

can the ac3 and dgpulldown'd m2v just be dropped into dvdlab pro? As the ever perceptive tyee points out, of course!

And as our friend daveidmx says...wheee!

jptheripper

17th February 2005, 04:33

was just curious ..

as for muxing i recommend muxman, cause its free!

mrslacker

17th February 2005, 06:24

I took this opportunity to convert a PAL disc that I have stashed, and... success!

disc->DGIndex->avs(resize)->CCE->DGPulldown->MuxMan

The resulting disc plays perfectly (so far) on my Sony NC665P. Hurray! This is a spectacular solution.

tyee

17th February 2005, 06:26

neuron2
Just redid my 10 minute clip (with the .m2v file) and perfection again!! Well done!!

tyee

Guest

17th February 2005, 07:54

Great. Thanks for the feedback. As a reward, here's a version with a browse button for the input filename:

http://neuron2.net/misc/dgpulldown100b2.zip

Guest

17th February 2005, 08:11

@daveidmx

I'm uploading a test file right now. Give it a few hours or so to complete. It will be on the FTP server named:

25fps_long_sample_for_dgpulldown_test.vob

Paulcat

17th February 2005, 14:44

Nice job Don! Shame TMPGEnc doesn't use this method...

How far are you from a program that demuxes, resizes AND does your pulldown?
("It's a JOKE, son")

You know, if only manufacturers of players and dvd's realized that the most money could be made by eliminating regions and playing all formats, we wouldn't have to deal with this bollocks.

p.s. Anyone in the UK know when Green Wing will be out on DVD?

digidragon

17th February 2005, 15:14

If the MPEG is progressive, but has an interlaced flag, does the flag have to be set to interlaced using Restream, for example?

I'm thinking of many UK TV programmes, which are shot on video, but are either deinterlaced before broadcast to give them a filmic look, or are shot on progressive video. The broadcast MPEGs, although they look progressive, are flagged as interlaced.

tyee

17th February 2005, 16:24

neuron2
Just one question on how the pulldown was chosen. Earlier we talked about your method like this --

AABCDE
ABCCDE

This gave 4 progressive and 2 interlaced, and is how you are currently doing it? Yes?

I asked about doing it this way --

ABBCDE
ABCCDE

which gives one interlaced and 5 progressive frames.
I guess I'm trying to understand why you chose the first method. Isn't it better to have the fewest number of interlaced frames?

I'm probably missing something important but I'm still learning.

tyee

Xesdeeni

17th February 2005, 16:24

Originally posted by Paulcat
You know, if only manufacturers of players and dvd's realized that the most money could be made by eliminating regions and playing all formats, we wouldn't have to deal with this bollocks.I don't understand this either. Any progressively encoded stream (24, 25, or 30) should be playable on any player. I've never understood why the flags were necessary. If you know the input rate and the output rate, it seems trivial. It's the lack of this ability that finally got me thinking about this flag gymnastics in the first place.

BTW, cudos to DG!

Xesdeeni

mrslacker

17th February 2005, 17:36

At this point, It seems almost trivial to implement the 23.976->29.97 conversion. It would be very nice to have DGPulldown assume the roll as the conventional NTSC pulldown tool as well. You did the challenging 25fps source without a hitch as far as I can tell. I'll test my converted disc on some other players to be sure they all respect the flags. Can I say it now? Good Work!

Xesdeeni

17th February 2005, 18:05

So what will progressive DVD players do with this? Will they be able to create the right 60 fps cadence?

Xesdeeni

Guest

17th February 2005, 18:08

Originally posted by digidragon
If the MPEG is progressive, but has an interlaced flag, does the flag have to be set to interlaced using Restream, for example? What do you mean by "has an interlaced flag"? You have to be precise if I am to understand you. Are you referring to the progressive_sequence field of the sequence extension, the progressive_frame_bit of the picture coding extension, or what? And what is Restream?

My understanding is that both of the aforementioned syntax elements refer to coded pictures, and not display frames.

I'm thinking of many UK TV programmes, which are shot on video, but are either deinterlaced before broadcast to give them a filmic look, or are shot on progressive video. The broadcast MPEGs, although they look progressive, are flagged as interlaced. I guess I just don't see what you are asking me. Sorry.

Guest

17th February 2005, 18:14

Originally posted by tyee
ABBCDE
ABCCDE

which gives one interlaced and 5 progressive frames.
I guess I'm trying to understand why you chose the first method. Isn't it better to have the fewest number of interlaced frames? Why do you think that 3:2 is not done like this:

A A B C D
A B B C D

That would give 4P+1I instead of 3P+2I. It's all about smoothness of the resulting video. Your pattern would stutter much more. The idea is to distribute the extra fields, not bunch them up. There's no point to trying to keep the display frames progressive when you are playing to an interlaced display.

Wilbert

17th February 2005, 18:14

@digidragon,

Sometimes progressive content is encoded as interlaced (for no reason). That's probably why they are flagged as interlaced.

@neuron2,

And what is Restream?
:search: :)

With this tool you can change many options of a MPEG2 Elementary Stream without re-encoding.
You can change options like the Sequence Header, matrices, tff-flags, User Data, GOP-flags, pan-scan-info ...
http://shh.sysh.de/restream.html

Guest

17th February 2005, 18:18

Originally posted by Xesdeeni
I don't understand this either. Any progressively encoded stream (24, 25, or 30) should be playable on any player. I've never understood why the flags were necessary. It's there to handle hybrid material. The 30fps sections are not flagged and the 24fps sections are flagged. Without some flagging, how would your player know what to do with the different sections?

Guest

17th February 2005, 18:22

Originally posted by mrslacker
At this point, It seems almost trivial to implement the 23.976->29.97 conversion. It would be very nice to have DGPulldown assume the roll as the conventional NTSC pulldown tool as well. Yes, the other trivial conversions will be implemented.

I'm going to remove program stream support because it is not that useful anyway and it requires me to redo all the PTS stamps, which I have neglected thus far.

digidragon

17th February 2005, 18:55

Originally posted by neuron2
What do you mean by "has an interlaced flag"? You have to be precise if I am to understand you. Are you referring to the progressive_sequence field of the sequence extension, the progressive_frame_bit of the picture coding extension, or what?

I guess I just don't see what you are asking me. Sorry.

I mean that the picture coding extension of the broadcast MPEG is TFF. The progressive sequence extension is not set.

I knocked off the TFF flag, and set the progressive sequence extension using ReStream, re-encoded it to 720x480 25fps, and ran it through pulldown. It authored fine as an NTSC DVD, but on my player it froze several times, and stopped playing prematurely.

So, does the source have to be a true progressive source (i.e. film) to use this method?

Guest

17th February 2005, 19:47

Originally posted by digidragon
I knocked off the TFF flag Huh? You can't do that because it destroys the valid flagging that the utility creates. Do you mean something else?

Why are you doing this? You shouldn't have to do anything.

So, does the source have to be a true progressive source (i.e. film) to use this method? Yes, unless you enjoy watching fields out of order.

digidragon

17th February 2005, 19:55

Originally posted by neuron2
Huh? You can't do that because it destroys the valid flagging that the utility creates. Do you mean something else?

Why are you doing this. You shouldn't have to do anything.
The main answer to that is that I'm trying to make the MPEG progressive (because it looks progressive).

Yes, unless you enjoy watching fields out of order.
It looked fine, apart from the occasional freezing.

I'm trying to find out if a broadcast MPEG, which was originally shot on progressive video, but broadcast as interlaced, can be treated the same as an MPEG sourced from film? Do I need to change any interlace flags on this MPEG to have it work correctly with your pulldown tool?

Paulcat

17th February 2005, 20:06

Paulcat

17th February 2005, 20:10

Originally posted by neuron2
Yes, unless you enjoy watching fields out of order.

What if you cannot determine if the source is progressive? Would playing back a short test encode be obvious? I assume that TMPGEnc and other mpeg encoders can produce progressive video but they have to know if what they are re-encoding is interlaced or not, correct?

mrslacker

17th February 2005, 20:25

Originally posted by digidragon
I'm trying to find out if a broadcast MPEG, which was originally shot on progressive video, but broadcast as interlaced, can be treated the same as an MPEG sourced from film? Do I need to change any interlace flags on this MPEG to have it work correctly with your pulldown tool?

I would preview in DGIndex with Field Operation set to None to make this determination. A source that I was recently working on was reported as Interlaced by DGIndex, but each and every frame showed no signs of interlacing. Maybe it was flagged wrong. I guess DGIndex just reported the frame type as it was flagged. I don't know enough about it to say why it says what it does, but since the preview looked progressive, I didn't bother deinterlacing. Besides, FieldDeinterlace(show=true) seemed to indicate that there was nothing to do. Maybe this approach can help you.

digidragon

17th February 2005, 20:33

I know that the video shows no interlacing artifacts either in DGIndex or vdubmod, even though it has its interlaced flag set. I was trying to find out if this type of non-interlaced video would work with the DGPulldown tool.

mrslacker

17th February 2005, 21:16

Originally posted by digidragon
I know that the video shows no interlacing artifacts either in DGIndex or vdubmod, even though it has its interlaced flag set. I was trying to find out if this type of non-interlaced video would work with the DGPulldown tool.

It seems to me the question is irrelevant. You mentioned you are reencoding to achieve a 720x480 resolution. If the encoder's output is set to produce a progressive stream, then there should be no issue. Maybe I'm missing your point.

Guest

17th February 2005, 21:16

Originally posted by digidragon
The main answer to that is that I'm trying to make the MPEG progressive (because it looks progressive). OK, but you don't do that by stripping the TFF flag!. You would set the progressive_frame flag in the picture display extension and the progressive_sequence flag in the sequence extension. But it is not necessary.

It looked fine, apart from the occasional freezing. The cure worked but the patient died.

I'm trying to find out if a broadcast MPEG, which was originally shot on progressive video, but broadcast as interlaced, can be treated the same as an MPEG sourced from film? Do I need to change any interlace flags on this MPEG to have it work correctly with your pulldown tool? Those flags don't matter. If the content is "really" progressive, in the sense that the fields of a frame come from a single picture, then the tool will work fine, regardless of the MPEG progressive_frame and progressive_sequence fields.

mrslacker is right again: Just reencode progressively and finesse the issue. But as I said it is not an issue anyway.

digidragon

17th February 2005, 23:11

Originally posted by mrslacker
It seems to me the question is irrelevant. You mentioned you are reencoding to achieve a 720x480 resolution. If the encoder's output is set to produce a progressive stream, then there should be no issue. Maybe I'm missing your point.
Well it wasn't irrelevant to me. I wouldn't have asked otherwise. I realise that I don't have the same level of knowledge as others here, but I don't ask irrelevant (to me) questions.

All the talk here seems to be about progressive FILM. I was trying to find out if (apparently) progressive VIDEO would work the same.

FWIW, I didn't process the MPEG in question this time through Restream, and just left the flags as they were. After encoding it to 720x480 in TMPGEnc, running it through DGPulldown, and authoring it onto a DVD using TDA, it played fine on my player. The panning looked much smoother than other methods of PAL->NTSC conversion that I've used.

mrslacker

17th February 2005, 23:43

Originally posted by digidragon
Well it wasn't irrelevant to me. I wouldn't have asked otherwise. I realise that I don't have the same level of knowledge as others here, but I don't ask irrelevant (to me) questions.

All the talk here seems to be about progressive FILM. I was trying to find out if (apparently) progressive VIDEO would work the same.
I don't think that your question wasn't deserving of consideration, just that the answer incidentally required no action. Poor word choice on my part perhaps. Ask away, I know I do!

I don't know the first thing about PAL (I'm in NTSC land), but my understanding is that progressive 25fps is "film", and interlaced 25fps is "video". "PAL progressive video" that you're referring to is a confusing concept for me. Someone like xesdeeni or neuron2 could clear that up.

digidragon

18th February 2005, 00:54

Originally posted by mrslacker
I don't know the first thing about PAL (I'm in NTSC land), but my understanding is that progressive 25fps is "film", and interlaced 25fps is "video". "PAL progressive video" that you're referring to is a confusing concept for me. Someone like xesdeeni or neuron2 could clear that up.

A lot of TV programmes made in the UK are shot on interlaced video. But during post-processing they are de-interlaced before broadcast. One example is the BBC comedy series The Office. When broadcast, or when viewed on DVD, it looks progressive. But out-takes on the DVD, or shown on blooper-type TV programmes, reveal that the original source is interlaced video, i.e. it looks like video, whereas the broadcast programme looks like "film", and when looked at in DGIndex doesn't display any interlacing artifacts at all.

scharfis_brain

18th February 2005, 01:39

PAL progressive means 25p contents.
(two fields carry the same temporal infromation, so they show a non-comend frame)

This is a great advantage of PAL.
movies are mostly progressive, when they are aired.
Even VHS-Tapes with movies are progressive (no matter, that they store the information in a interlaced way).

mrslacker

18th February 2005, 03:21

Originally posted by scharfis_brain
PAL progressive means 25p contents.
(two fields carry the same temporal infromation, so they show a non-comend frame)

This is a great advantage of PAL.
movies are mostly progressive, when they are aired.

OK, that was my understanding. I thought most PAL was coded progressive (pairs of fields from the same time).

digidragon cleared up my big misunderstanding: referring to VIDEO type content in the PAL domain as progressive seemed wrong to me. I thought 25p = FILM & 25i = VIDEO. Thus, how could you refer to something as 25fps progressive VIDEO? digidragon, you are talking about originally interlaced, then deinterlaced material... if I understand you correctly. I think I'm clear now.

digidragon

18th February 2005, 04:34

Originally posted by mrslacker
digidragon, you are talking about originally interlaced, then deinterlaced material... if I understand you correctly.
Yes, you do... :)

scharfis_brain

18th February 2005, 06:49

The broacasters mainly use those methodes to 'deinterlace' their videos:

blur(0,1)

or

bob().selecteven()

or

separatefields().selecteven()
interleave(last,last).weave()

Paulcat

18th February 2005, 13:47

The waters are starting to close over my head again...

I am trying to convert Black Books from PAL to NTSC, since I don't know SFA about scripting, I am using TMPGEnc to do my re-sizing. I noticed some of you are as well, so could you tell me if you use the PAL dvd template and simply resize to 720x480 or the NTSC dvd template with 25 frames per second (or do it all from scratch)? I also noted that there is a pulldown option in tmpgenc as well but I assume that it's for 23.976 to 29.976 and not what Don was doing.

It appears the dvd is interlaced, I tried a short clip assuming progressive and it looked awful. Now I also know that I have to make my output from tmpgenc progressive in order to use Don's pulldown tool, and I have another dumb question: is the difference between a "progressive scan" dvd player and a regular one mean only that it can output progressively to progressive scan television and NOT that a regular dvd can not read a progressive dvd? (holy &^%&, where's the acronym for "progressive"!!)

Bleah!

Guest

18th February 2005, 14:02

Originally posted by Paulcat
I am trying to convert Black Books from PAL to NTSC, since I don't know SFA about scripting, I am using TMPGEnc to do my re-sizing. I noticed some of you are as well, so could you tell me if you use the PAL dvd template and simply resize to 720x480 or the NTSC dvd template with 25 frames per second (or do it all from scratch)? I also noted that there is a pulldown option in tmpgenc as well but I assume that it's for 23.976 to 29.976 and not what Don was doing. I don't use any template. I resize the video in Avisynth and serve the AVS file to TMPGEnc. It will come up with 720x480 and 25fps, so nothing to change there. Then just set non-interlace for encode mode on the video tab, and video source type non-interlace on the advanced tab. Use Center (keep aspect ratio) for arrange method.

It appears the dvd is interlaced, I tried a short clip assuming progressive and it looked awful. Then you must deinterlace it. Use KernelDeint() in Avisynth, for example.

Now I also know that I have to make my output from tmpgenc progressive in order to use Don's pulldown tool, See above. Deinterlace before TMPGEnc and then use the non-interlace settings.

and I have another dumb question: is the difference between a "progressive scan" dvd player and a regular one mean only that it can output progressively to progressive scan television and NOT that a regular dvd can not read a progressive dvd? (holy &^%&, where's the acronym for "progressive"!!) Yes.

While you can use this method on interlaced material by deinterlacing first, you will lose some temporal information.

Inwards

18th February 2005, 15:32

Donald,

Any chance that you can add drop frames to the timecodes? I'm trying to test this with a PAL movie that needs subtitles and of course they're hopelessly out-of-sync...

Also, CCESP seems to refeuse to create a 25fps 720x480 MPEG-2. Instead, it insists on resizing it PAL. TMPGEnc seems to work fine, though.

Guest

18th February 2005, 15:37

Originally posted by Inwards
Any chance that you can add drop frames to the timecodes? I'm trying to test this with a PAL movie that needs subtitles and of course they're hopelessly out-of-sync... If I knew what you meant there would be a good chance of it. :) If you explain it to me, I'll be happy to do it.

Also, CCESP seems to refuse to create a 25fps 720x480 MPEG-2. Instead, it insists on resizing it PAL. TMPGEnc seems to work fine, though. Interesting.

digidragon

18th February 2005, 15:46

It seems I get different results with two different encoders.

After running the re-encoded m2v files through DGPulldown, gspot tells me this:

Mainconcept-:
pics/sec: 23.976
frms/sec: 29.970
flds/sec: 59.939
prog

TMPGEnc-:
pics/sec: 29.970
frms/sec: 29.970
flds/sec: -
interlaced 3:2

In both the encoders I set the output to be progressive. Which one is correct?

tyee

18th February 2005, 16:00

neuron2
Here's a link to one of the best explanations of drop-frame timecode I've found on the net. It's from Adobe Premier but it's general theory also.

http://teched.vt.edu/gcc/HTML/VirtualTextbook/PDFs/AdobeTutorialsPDFs/Premiere/PremiereTimecode.pdf

Pictoral summary -
http://www.sfu.ca/sca/Manuals/ZAAPf/d/drop_frame.html

Word Summary -

You skip the first two frame numbers (0,1) at the start of each minute, except minutes 0, 10, 20, 30, 40, and 50. No video data is dropped: you merely assign timecodes that sometimes increment by more than one frame to subsequent frames of video data.

Drop-frame 525/29.97 timecode gives you an average of 29.97 frames per second. This is imperfect (29.97 is not equal to 30000/1001), but it is a lot closer than 30. Drop-frame 525/29.97 timecode will give you an error of two frames per day, compared to 24 for non-drop-frame timecode.

tyee

Guest

18th February 2005, 16:04

Originally posted by digidragon
In both the encoders I set the output to be progressive. Which one is correct? Neither one. MainConcept is wrong about the picture rate (assuming you did feed it 25fps as required). TMPGEnc is wrong because it is not 3:2 pulldown. I wouldn't agonize about this; existing tools have been written without anticipating this kind of pulldown.

Inwards

18th February 2005, 16:19

Originally posted by neuron2
If I knew what you meant there would be a good chance of it. :) If you explain it to me, I'll be happy to do it.

Maestro and Scenarist need the drop_frame flag set in the mpeg stream in order to properly sync the subtitles. The drop_frame flag is part of the frame timecode. You can write a fancy algorithm to insert the drop_frames in the correct places, or, since timecodes are ignored during playback and only mpeg authoring tools seem to care about them, you can just mark every frame with the drop_frame flag. This is enough to convince Maestro and Scenarist that the clip uses drop_frame.

Guest

18th February 2005, 16:19

@tyee

I'm asking what you expect the tool to do, stated in terms that I can code from. I assume you want me to change the GOP timecodes, is that correct? How am I to change them?

Maybe we should let Inwards answer this, because he knows what is needed from the MPEG2 point of view.

Xesdeeni

18th February 2005, 16:37

Originally posted by neuron2
It's there to handle hybrid material. The 30fps sections are not flagged and the 24fps sections are flagged. Without some flagging, how would your player know what to do with the different sections? I admit to not being an expert on the MPEG-2 specification, although I've read most of it. However, I haven't read the specs on PS or TS.

However, based on information I've tried to understand, it seems if your encoder was decent, you could encode a hybrid as 30i, but still get the benefit of the flags without using them. Whenever progressive frames were encountered, the encoder would encode them as such (and in fact, some interlaced frames could be encoded as progressive, if there was little or no movement--in fact, can't you encode each macroblock as either progressive or interlaced?). And if they were 24p (needed telecine), the encoder could indicate the repeated field in the MPEG encoding itself, by indicating no change in the associated P or B frame (the only caveat being that if you were at an I frame, you'd need to redundantly re-encode it). I believe this is different than the flags we are dealing with, but I'm not absolutely positive.

Please let me know what I misunderstand here.

Xesdeeni

mrslacker

18th February 2005, 16:43

Originally posted by Inwards
Also, CCESP seems to refeuse to create a 25fps 720x480 MPEG-2. Instead, it insists on resizing it PAL. TMPGEnc seems to work fine, though.
That is interesting. With my worthless (logo'd) demo, It had no problem with this configuration. I didn't know it could resize. Does it show PAL size or does it actually spit out a PAL sized m2v? Also, I used BatchCCEWS to do an RoBa OPV encode. It wrote the ecl for CCE, so maybe that's a workaround.

jptheripper

18th February 2005, 16:51

just did my first test, m2v and ac3 audio only (no subtitles)

authored with dvd lab pro, which actually reported as pulldown 2:3

plays beautifully in windvd and bsplayer, reported as 29.97fps

will burn and test on standalones tonite

Inwards

18th February 2005, 17:03

Originally posted by mrslacker
That is interesting. With my worthless (logo'd) demo, It had no problem with this configuration. I didn't know it could resize. Does it show PAL size or does it actually spit out a PAL sized m2v? Also, I used BatchCCEWS to do an RoBa OPV encode. It wrote the ecl for CCE, so maybe that's a workaround.

I was using v2.7. Basically, it letterboxes the 480 NTSC image in the center. v2.5 refused to accept the stream outright.

Inwards

18th February 2005, 17:15

Originally posted by neuron2
@tyee

I'm asking what you expect the tool to do, stated in terms that I can code from. I assume you want me to change the GOP timecodes, is that correct? How am I to change them?

Maybe we should let Inwards answer this, because he knows what is needed from the MPEG2 point of view.

Although you can get away with just changing the TFF & RFF & framerate flags and end up with something that will play in standalones, you actually need to fiddle with a few other parts of the stream in order to get a something that won't confuse the heck out of authoring tools. One of these things is the timecode stored in the GOP.

The timecode gives you the current hours, minutes, seconds, frame number and drop frame of the first temporal frame in a given GOP. Obviously, changing the framrate of a clip by inserting RFF/TFF frames will change the timecodes somewhat. This is also where authoring tools look for the drop_frame information.

Here is the function that pulldown uses to calculate the current timecode:

double new_timecode (int ThisFrame, double fr, bool drop_frame) {
int fps, pict, sec, minute, hour, tc;
/* convert 23.976/24fps frame number to 29.97/30fps frame number */
if (fr==29.97) { fps = 30; }
if (fr==23.976) { fps = 24; }
if (fr==25) { fps = 25; }
ThisFrame = (((ThisFrame / 2) * 2 + (ThisFrame / 2) * 3) >> 1);

pict = ThisFrame%fps;
ThisFrame = (ThisFrame-pict)/fps;
sec = ThisFrame%60;
ThisFrame = (ThisFrame-sec)/60;
minute = ThisFrame%60;
ThisFrame = (ThisFrame-minute)/60;
hour = ThisFrame%24;
tc = (drop_frame<<24 | hour<<19) | (minute<<13) | (1<<12) | (sec<<6) | pict;
return tc;
}

Note that I don't properly calculate the drop frame; if the user has set that flag, I just mark every GOP as drop frame. This is not correct behavoir, but it saves a pile of code and it satisfies the authoring programs.

Hope this helps.

digidragon

18th February 2005, 17:49

Originally posted by neuron2
MainConcept is wrong about the picture rate (assuming you did feed it 25fps as required). TMPGEnc is wrong because it is not 3:2 pulldown. I wouldn't agonize about this; existing tools have been written without anticipating this kind of pulldown.
Which encoding is most likely to behave better on a true NTSC DVD player and TV? I only have a PAL TV and PAL DVD player with which to test the NTSC DVDs...

daveidmx

18th February 2005, 18:17

@Inwards
What is the "correct" behavior? I'll need to be writing the drop-frame thing soon.

Also, did you get my PM regarding the source? When I compiled pulldown.exe the result exits abnormally after a a few GOPs on this source I have. Well I suppose it doesn't matter at this point, I've already set about writing a new stream parsing architecture.

Guest

18th February 2005, 18:25

Here is beta 4. It has normal 3:2 pulldown, a progress bar, and source code.

http://neuron2.net/dgpulldown/dgpulldown.html

Now I'll catch up on the recent posts...

EDIT: Duh, I don't need stream ID anymore. I'll get rid of it.

EDIT2: Modified the link to beta 4.

Guest

18th February 2005, 18:49

Originally posted by digidragon
Which encoding is most likely to behave better on a true NTSC DVD player and TV? I only have a PAL TV and PAL DVD player with which to test the NTSC DVDs... You encode at 25fps progressive as we've said. It's irrelevant what GSpot thinks of the resulting file. Is there some specific setting that you are in doubt about?

Guest

18th February 2005, 18:50

Thank you, Inwards, for the explanation. The next version will support timecodes and drop frames.

digidragon

18th February 2005, 19:58

Originally posted by neuron2
You encode at 25fps progressive as we've said. It's irrelevant what GSpot thinks of the resulting file. Is there some specific setting that you are in doubt about?
Well, just the fact that when I play the pulled down mpv files in media player classic (using its own filters) or vlc player, the TMPGEnc one plays jerkily, whereas the mainconcept one plays fine.

Paulcat

18th February 2005, 22:42

n2,

I appreciate the work you are doing on this, but I have a complete lack of understanding of avisynth and scripting (assuming I have some free time before I die, I might have to remedy that, but I'm pushing 40 this year and it's pushing back!!).

All I need to use your pulldown program is a progressive, 720x480, 25 frame per second MPEG2 stream, correct?

Tmpgenc can give me a progressive, 25fps, 720x480 mpeg2 video stream, so basically I shouldn't have to use avisynth (which I don't understand) correct? I'm not terribly concerned about a small loss in quality (or menus!).

I'll try this tonight with a few short clips and see what happens. By the way, how fast is DGPulldown?

Jeffster

18th February 2005, 22:47

Originally posted by Inwards

Also, CCESP seems to refeuse to create a 25fps 720x480 MPEG-2. Instead, it insists on resizing it PAL. TMPGEnc seems to work fine, though.

Disable the DVD compliant option in CCE or it will, er... force it to DVD specs (in your case padding to 576).

mrslacker

18th February 2005, 22:57

Originally posted by Paulcat
Tmpgenc can give me a progressive, 25fps, 720x480 mpeg2 video stream, so basically I shouldn't have to use avisynth (which I don't understand) correct? I'm not terribly concerned about a small loss in quality (or menus!).

I'll try this tonight with a few short clips and see what happens. By the way, how fast is DGPulldown?

Tmpgenc should handle the resizing properly if you give it the right options. I haven't tried it yet.

DGPulldown is just about as fast as your hard drive. The frames themselves are not processed.

Originally posted by Jeffster
Disable the DVD compliant option in CCE or it will, er... force it to DVD specs (in your case padding to 576).
Good call!

Inwards

19th February 2005, 01:21

Originally posted by Jeffster
Disable the DVD compliant option in CCE or it will, er... force it to DVD specs (in your case padding to 576).

Tried that. Still no joy.

Guest

19th February 2005, 03:25

Originally posted by Paulcat
All I need to use your pulldown program is a progressive, 720x480, 25 frame per second MPEG2 stream, correct? It doesn't have to be 720x480, unless you want to author a DVD.

Tmpgenc can give me a progressive, 25fps, 720x480 mpeg2 video stream, so basically I shouldn't have to use avisynth (which I don't understand) correct? The input to TMPGEnc should be 25fps progressive. You don't want it to convert frame rates.

By the way, how fast is DGPulldown? Fast enough, I hope.

Paulcat

19th February 2005, 05:47

I have been messing about tonight trying a few things.

I started with a PAL video stream, 720x576 (16:9), 25 fps, interlaced, and using tmpgenc ended up with an 'ntsc' video stream at 720x480, 25 fps, and progressive. I also created a second file the same as above with a framerate of 29.976 using tmpgenc.

The file with the 25 fps framerate ran nice and smooth on the computer, while the file with the 29.976 framerate showed some jerkiness (tmpgenc would appear to duplicate every 5th frame or so to bump 25 fps up to 29.976 fps rather than alter the flags).

I then took the 25 fps file and used DGPulldown (beta 4) and ended up with a third file, with a framerate of 29.976, and lo and behold it showed the same jerkiness as the one made with tmpgenc!

Granted, using DGPulldown will give me a smaller file, and allow me a higher bitrate when encoding for a new ntsc dvd, but it does not appear to alter the look of the video itself, it still does not play smoothly.

( I have attached the tmpgenc profile that I used in case anyone is interested, it will have to be cleared by Mr. Moderator...)

Guest

19th February 2005, 06:20

Did you enable TMPGEnc's deinterlacer? I said the video has to be progressive. Just because you set progressive encoding, that doesn't make the video "really" progressive.

digidragon

19th February 2005, 07:19

As you seem familiar with TMPGEnc, can you comment on the jerkiness of that encoder's mpv file when run through DGPulldown?

As I said, the mainconcept file has no jerkiness, but I'd prefer to use TMPGEnc as the quality looks slightly better to me.

Guest

19th February 2005, 07:29

Originally posted by digidragon
As you seem familiar with TMPGEnc, can you comment on the jerkiness of that encoder's mpv file when run through DGPulldown?

As I said, the mainconcept file has no jerkiness, but I'd prefer to use TMPGEnc as the quality looks slightly better to me. I'm not having any problems with jerkiness with TMPGEnc. Can you post your video settings?

digidragon

19th February 2005, 07:45

These are the settings that I used. Maybe jerkiness is the wrong word, it looks more like a low frame rate (say 12fps) when played in MPC or VLC.

http://img.photobucket.com/albums/v258/digidragon/tmpgenc1.png

http://img.photobucket.com/albums/v258/digidragon/tmpgenc2.png

EDIT: the previous list wasn't very easy to follow, so I replaced it with screenshots...

jptheripper

19th February 2005, 15:18

inwards.

for me at least cce makes 720x480 25fps movies fine.

generate your d2v file

in your avs script
load d2v
lanzcosresize or bicubicresize to 720x480

make no adjustments to framerate

process

all done.

scharfis_brain

19th February 2005, 15:40

I cannot test DGPulldown here, because my TV is not able to display 60 Hertz.

Is DGPulldown fixed to a width of 720 pixels or are the other DVD-conform widths of 704 & 352 pixels possible, too?

Can a SVCD contain rff-flags, too? (like DVD)
And what about VCD? (certainly impossible)

Guest

19th February 2005, 16:14

@digidragon

I don't see any obvious problem. I can try with your source if you like. If it works smooth I'll give you my template that does it.

@scharfis_brain

DGPulldown doesn't care a wit about width, nor does he change it in any way. You can use anything you like as long as your authoring program is happy. SVCD is MPEG2 so it should theoretically be possible.

mean

19th February 2005, 16:14

SVCD : yes
VCD: no, mpeg1 does only progressive encoding

digidragon

19th February 2005, 16:41

Originally posted by neuron2
@digidragon

I don't see any obvious problem. I can try with your source if you like. If it works smooth I'll give you my template that does it.
Thanks. I'm uploading the mpeg, called digidragon.mpg, at the moment.

Inwards

19th February 2005, 16:56

Originally posted by jptheripper
inwards.

for me at least cce makes 720x480 25fps movies fine.

generate your d2v file

in your avs script
load d2v
lanzcosresize or bicubicresize to 720x480

make no adjustments to framerate

process

all done.

I went back to 2.66 and it seems to work now. The best I was able to get out of the latest version was a 720x480 stream with the original clip letterboxed inside it. Odd.

Paulcat

19th February 2005, 18:00

Originally posted by neuron2
Did you enable TMPGEnc's deinterlacer? I said the video has to be progressive. Just because you set progressive encoding, that doesn't make the video "really" progressive.

Yes I did. There was an option to filter odd, even or both fields to remove the lines and I chose double. In the preview it worked with all 3, I chose double on the recommendation in the help file.

I know that enabling the sharpness filter makes the mpg less fluid during playback, but it was disabled in my testing.

Paulcat

19th February 2005, 18:03

Originally posted by digidragon
As you seem familiar with TMPGEnc, can you comment on the jerkiness of that encoder's mpv file when run through DGPulldown?

As I said, the mainconcept file has no jerkiness, but I'd prefer to use TMPGEnc as the quality looks slightly better to me.

I can comment all right, but the language might be considered offensive...

I am still unsure as to how to fix it, but if I do, I will sure let everyone know!

}:-)

Guest

19th February 2005, 19:16

@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. I have found one standalone that doesn't play my test DVD smoothly. It's a Panasonic DVD recorder unit. All others that I tried have been fine. You might try different standalones.

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.

danpos

19th February 2005, 21:50

@neuron2

Hi! I've tested your new toy (DGPulldown). I've feed it up with 25 fps progressive ES. The time lenght of ES was 54:56 min. After DGPulldown application, the new ES pulled down to 29.97 presents time lenght of 54:59, i.e., 3 seconds more long. My question: Is this a normal behaviour? BTW, it's a great utility.

Keep up the good work!

Cheers,

JetlagMk2

19th February 2005, 22:00

I inquired earlier about using a pulldown that slowed down the rate at which the encoded frames are consumed by the decoder. Specifically to slow down a sped up PAL movie. Well, I did it and it worked fine. It played perfectly in MPC and on my $30 standalone.

I have both an NTSC and a PAL version of the movie. I took the video and chapter points from the PAL source. I took two audio tracks and subtitles from the NTSC version. I modified dgpulldown so I could set the pulldown and fps to whatever I wanted. I ran the video through it and then muxed it all and burned it.

Guest

19th February 2005, 22:05

@danpos

How are you counting the frames, or measuring the time? I have an M2V that is 8088 frames and 5:23.52 long as reported by VirtualDub when serving as a D2V. After DGPulldown, it should be the same length and have a number of frames equal to (29.97/25) * 8088 = 9696 frames. When I serve the flagged file the same way I get 5:23.52 long and 9696 frames.

Guest

19th February 2005, 22:08

Originally posted by JetlagMk2
I inquired earlier about using a pulldown that slowed down the rate at which the encoded frames are consumed by the decoder. Specifically to slow down a sped up PAL movie. Well, I did it and it worked fine. It played perfectly in MPC and on my $30 standalone.

I have both an NTSC and a PAL version of the movie. I took the video and chapter points from the PAL source. I took two audio tracks and subtitles from the NTSC version. I modified dgpulldown so I could set the pulldown and fps to whatever I wanted. I ran the video through it and then muxed it all and burned it. Are you saying you used it to do inverse 3:2 by removing the flags and changing the rate back to 23.976fps? If so, I said already that I didn't do that because DGIndex already does force film.

Your method naively applied will not work with hybrid material. If it is not naively applied, it is equivalent to force film, which I suppose is useful. If you have done that, please contribute your code so that I may add it.

Am I misunderstanding what you did? If so, please explain what you did to the flags and the framerate.

Guest

19th February 2005, 22:23

@digidragon

Did you try resizing in Avisynth and not in TMPGEnc?

EDIT: The file you gave me is a program stream. How are you demuxing? I need to duplicate your process and you're throwing curve balls at me without explanation. :confused:

I hope you are not using the old version that flags program streams. I pointed out that the PTS stamps would be wrong.

Please describe your exact process in full detail. Thank you.

danpos

19th February 2005, 22:55

@neuron2

Forget my last report. I got a wrong information from MPC. After I did multiplex audio and video with mplex, I got a PS that presents the correct time lenght. I got a perfect playback in both MPC and WinDVD. Now, I'm gonna to author a DVD and test it on my SAP. DGPulldow seems really awesome!:)

Congrats,

Trahald

19th February 2005, 23:59

Originally posted by daveidmx
@Inwards
What is the "correct" behavior? I'll need to be writing the drop-frame thing soon.

Also, did you get my PM regarding the source? When I compiled pulldown.exe the result exits abnormally after a a few GOPs on this source I have. Well I suppose it doesn't matter at this point, I've already set about writing a new stream parsing architecture. I dont know if this applies to your case, daveidmx, but pulldown has an issue with files that do not have a sequence end code and will exit(1) if it hits endoffile before hitting one. unfortunately that leaves the last buffer full of data unwritten. this change to next start code fixes thatvoid next_start_code()
{
if (seek_sync(START_CODE_PREFIX, 24))
return;
else {
zprintf( 1, "\n Could not find next_start_code! Emptying buffer and exiting\n", 0 );
finish_getbits();
exit(1);
}
} this issue would generally only cause maybe 1-4 or so gops to be lost at the end (the buffer is ~32k).. if much more or lost its a different issue

digidragon

20th February 2005, 01:17

Originally posted by neuron2
@digidragon

Did you try resizing in Avisynth and not in TMPGEnc?

EDIT: The file you gave me is a program stream. How are you demuxing? I need to duplicate your process and you're throwing curve balls at me without explanation. :confused:

I hope you are not using the old version that flags program streams. I pointed out that the PTS stamps would be wrong.

Please describe your exact process in full detail. Thank you.
No curved balls intended. The mpg was my source, which is what I sent you. I thought it better to send my original source, rather than one that I'd already processed.

But to answer your question, I have tried several ways, such as demuxing it using VideoRedo, Womble MPEG-VCR and TMPGEnc, and feeding the raw m2v to TMPGEnc.

I also tried using DGIndex to create a d2v file and serving that through AVISynth to TMPGEnc:

LoadPlugin("C:\Program Files\GordianKnot\AviSynthPlugins\dgdecode.dll")
mpeg2source("office_clip.d2v")
LanczosResize(720,480)

Using all of these methods, the resulting TMPGEnc-encoded m2v, after running through DGPulldown, played jerkily in VLC and MPC.

Guest

20th February 2005, 01:22

OK, thank you for the clarification. I'll try it my way and see what happens.

JetlagMk2

20th February 2005, 01:22

Originally posted by neuron2
Am I misunderstanding what you did? If so, please explain what you did to the flags and the framerate.

Basically I ran a 23.97544444 -> 25 pulldown on a PAL video (and leaving the framerate at 25fps) to return it to the correct run time so I could mux it with the audio tracks of the same movie from an NTSC DVD. Inwards described something similar, but I had no problems playing the result on my standalone.

void generate_flags(void)
{
int i;
unsigned char *p;
double dfl,tfl;
int trfp;

dfl = 2*(tfps - cfps)/cfps;
tfl = 1/2;

// Generate BFF flags.
p = bff_flags;
trfp = 0;
for (i = 0; i < MAX_PATTERN_LENGTH; i++)
{
tfl += dfl;
if (tfl > 1.0) {
tfl -= 1.0;
*p++ = trfp + 1;
trfp ^= 2;
} else {
*p++ = trfp;
}
}
// Generate TFF flags.
p = tff_flags;
trfp = 2;
for (i = 0; i < MAX_PATTERN_LENGTH; i++)
{
tfl += dfl;
if (tfl > 1.0) {
tfl -= 1.0;
*p++ = trfp + 1;
trfp ^= 2;
} else {
*p++ = trfp;
}
}
} current fps (cfps) and target fps (tfps) are defined globally before calling.

Guest

20th February 2005, 02:10

I still have no idea what you're talking about. If you left it at 25 fps display rate, as you stated, how could that match up with NTSC audio, which matches up with 29.97?

Is this what you did?

1. Start with non-flagged 25fp PAL.
2. Pretend it is 23.976 and flag it as for 23.976 -> 25.
3. Leave frame rate at 25 in stream.

I can't see how that would produce a video length that would match up with audio from 29.97 NTSC.

coby

20th February 2005, 02:26

My disks are playing perfectly on my Sampo DVE612N (which admittedly plays most anything) and also on my Toshiba SD-HD40 (which tends to be quite fussy).

I'm using CCE267 and TMPGEnc DVDAuthor for the encode and authoring.

Awesome job!

JetlagMk2

20th February 2005, 02:36

Your list is correct (except I actually did 23.97544~ -> 25 because that's what I came up with when calculating the difference between the two videos). It matches up because the folks who transfer films in PAL-land simply speed up the film when going from 24 to 25 fps. The PAL version runs about 5 minutes shorter than the NTSC version on this particular film, it just happened to have a really nice anamorphic video that the NTSC version lacked.

Guest

20th February 2005, 02:48

OK, I see now. Theoretically, you'll eventually overflow the video bit buffer. But if it is specified big enough in the stream, you might not overflow before the movie is over. It would be interesting to see a bit of your stream to see how big your buffers are specified to be, and to calculate the time it would take to overflow them.

Guest

20th February 2005, 02:55

Originally posted by coby
My disks are playing perfectly on my Sampo DVE612N (which admittedly plays most anything) and also on my Toshiba SD-HD40 (which tends to be quite fussy). Thanks for the report on your results. Fortunately, it looks like it is just the occasional odd player that can't handle this pulldown.

Guest

20th February 2005, 08:41

Here is beta 5:

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

It now uses field dropping and supports generalized rate specifications. Thank you, JetlagMk2, for the generate_flags() modification.

Timecodes and drop frames are next.

digidragon

20th February 2005, 14:08

Using beta 5 on both the TMPGEnc and mainconcept m2v files, VLC throws up a division by zero error, and MPC fails to find a connectable filter:

Media Type 0:
--------------------------
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: MEDIASUBTYPE_MPEG1Video {E436EB86-524F-11CE-9F53-0020AF0BA770}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0

Media Type 1:
--------------------------
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0

However, PowerDVD seems okay with them, and they play fine.

Guest

20th February 2005, 15:17

@digidragon

What were your DGPulldown settings? If you open the converted M2V in DGIndex and then hit F5, is the frame rate correct?

I can't think of any way the beta 5 changes could cause this.

digidragon

20th February 2005, 15:46

The framerate of the converted file is 29.970 fps.

One thing that I've noticed in DGIndex is that when playing the converted (29.970fps) m2v it looks interlaced, whereas the unconverted (25fps) looks progressive. This was the case with the previous beta too, so it's probably not realted to the errors I got.

Guest

20th February 2005, 15:52

digi, I ask again. What were your settings? Which radio box ticked and what edit box entries. Thank you.

Guest

20th February 2005, 15:55

Originally posted by digidragon
One thing that I've noticed in DGIndex is that when playing the converted (29.970fps) m2v it looks interlaced, whereas the unconverted (25fps) looks progressive. This was the case with the previous beta too, so it's probably not realted to the errors I got. Pulldown obviously creates some interlaced frames!

A A B C D
A B C C D

Guest

20th February 2005, 15:58

I duplicated the problem. I'll post a fix shortly. Thank you for pointing it out.

digidragon

20th February 2005, 16:02

Originally posted by neuron2
digi, I ask again. What were your settings? Which radio box ticked and what edit box entries. Thank you.
Apologies. The 25-->29.97 radio button was selected. The only entry in the edit boxes was the source file name, there was nothing entered in the frame rate edit boxes.

Guest

20th February 2005, 16:06

Here's beta 6. I wasn't setting the frame rate for the non-custom radio box choices. Silly me.

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

Thanks, digi, you're the man.

digidragon

20th February 2005, 16:37

That fixed the errors in MPC and VLC - thanks.

Going back to my other points...

1. Does the fact that the TMPGEnc m2v still plays back jerkily in MPC and VLC matter?

2. Will the interlaced frames that DGPulldown creates cause any problems?

Thanks for your continued efforts with this :cool:

scharfis_brain

20th February 2005, 17:03

wow.
even 23.976p to 25i pulldown seems to work (at least when I load the d2v with dgdecode)

LOL dgindex says
Framerate 25.000
Video type 9x% NTSC
Frame type Progressive

shouldn't video type be NTSC-FILM?

btw.: Virtualdubmod crashes (it closes without notification)
when I try to access the info-dialogue:
FIle -> File INformation.

any thoughts about that?

Guest

20th February 2005, 17:13

Originally posted by digidragon
1. Does the fact that the TMPGEnc m2v still plays back jerkily in MPC and VLC matter? Still trying to duplicate your result...

2. Will the interlaced frames that DGPulldown creates cause any problems? Do they cause any problems for normal 3:2 pulldown? Of course not. There's no difference. The output is intended for an interlaced device; why would interlacing cause a problem?

digidragon

20th February 2005, 17:18

Originally posted by neuron2
Do they cause any problems for normal 3:2 pulldown? Of course not. There's no difference. The output is intended for an interlaced device; why would interlacing cause a problem?
I've no idea. This is the only time I've used pulldown. Like I said earlier in the thread, my technical knowledge of MPEG and video is fairly limited (but improving), so you you'll have to forgive the occasional "dumb" question...

Guest

20th February 2005, 17:22

Originally posted by scharfis_brain
LOL dgindex says
Framerate 25.000
Video type 9x% NTSC
Frame type Progressive The calculation is designed with 3:2 in mind.

btw.: Virtualdubmod crashes (it closes without notification)
when I try to access the info-dialogue:
FIle -> File Information.

any thoughts about that? No, but VirtualDub MPEG2 works. My guess is that the file counting calculation is dividing by zero or something. Don't forget that none of these VDub clones that accept MPEG2 honor the RFF flags. The result is totally undefined if you load a clip with any RFF flags.

scharfis_brain

20th February 2005, 17:27

using vdubmod with mpeg2 results in the same like when I use
Field operation -> raw encoded frames
in dgindex.
I like that behaviour.
nevertheless it is useless for transcoding actions.
(exept, one is very sure that the pulldown pattern is absolutely constant over the whole file)

Guest

20th February 2005, 17:37

Sure. That's OK.

I did a quick build of VirtualDubMod 1.5.4.1 and it doesn't fail. But the source for 1.5.10.1 is not on the project page, so I can't help you.

scharfis_brain

20th February 2005, 17:39

you're right.
vdubmod 1.5.4.1 doesn't crash on the info-dialogue.

Guest

20th February 2005, 17:49

Originally posted by scharfis_brain
you're right.
vdubmod 1.5.4.1 doesn't crash on the info-dialogue. Looking at the 1.5.10.1 Doom9 thread, you can see there are many crashing bugs reported and then they stopped development. :confused:

scharfis_brain

20th February 2005, 18:04

sh**!
then i really hope that 1.5.10.x won't crash my three-days (estimated) encode *grrrrr*
(its a big pain to test my nevest conversion script with didée-speed-(c) )

Guest

20th February 2005, 19:00

Here's Beta 7 with timecodes and dropframes:

http://neuron2.net/dgpulldown/dgpulldown.html

@Inwards

Can you test this please? Also, for the timecode generation you round the fractional rates up to the nearest integer first. Is that strictly correct?

scharfis_brain

20th February 2005, 19:12

small suggestion for your GUI.

I think that two pulldown menues, or two rows of checkboxes should more flexible than predifined ratios.
also you can remove the maybe user-unfriendly text-boxes.

1st choose input framerate
then the GUI reduces the possible output rates (greys out the illegal ones), so one cannot choose a wrong one.

something like this (with default at 25p -> 29.97i)

input output
( ) 23.976p
( ) 24p ( ) 24i #<- does 24i exist?!?
(o) 25p ( ) 25i
( ) 29.97p (o) 29.97i
( ) 30p ( ) 30i
( ) 50p ( ) 50p
( ) 59.94p ( ) 59.94p
( ) 60p

Guest

20th February 2005, 19:23

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

20th February 2005, 19:39

, 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

20th February 2005, 20:09

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

20th February 2005, 20:11

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

20th February 2005, 20:25

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

20th February 2005, 20:44

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

20th February 2005, 21:00

Um, 25 / 16.667 < 1.5.

scharfis_brain

20th February 2005, 21:01

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

20th February 2005, 21:06

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

Guest

20th February 2005, 21:22

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

20th February 2005, 21:28

@scharfi

I'm not getting enough sleep. Forgive me.

25 / 16.666667 = 1.5, so it is OK.

:rolleyes:

Guest

20th February 2005, 21:29

Originally posted by JetlagMk2
Um, 25 / 16.667 < 1.5. Like I said, it's a sleep thing. :p

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

Guest

20th February 2005, 21:31

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

21st February 2005, 00:01

@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

21st February 2005, 01:44

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

mrslacker

21st February 2005, 06:21

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

21st February 2005, 07:08

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

21st February 2005, 07:29

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

21st February 2005, 13:45

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

21st February 2005, 14:16

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.

Guest

21st February 2005, 14:22

Originally posted by Paulcat
I'd have to learn how to use avisynth first! Yes, that is correct.

Avisynth is one of the easiest tools I have ever used. I don't understand this cult of mysteriousness. To resize in Avisynth you make a simple text file with this in it:

avisource("myfile.avi")
lanczosresize(720,480)

That's it, you're done! You just open this text file as if it were an AVI in TMPGEnc.

Paulcat

21st February 2005, 15:43

I think it has to do with seeing tons and tons of other people's scripts all trying to do the same things in different ways!

Someday when I have free time, I will play with it a bit and see what it can do (quite a lot from all accounts), but for now, the only video work I am doing is converting from PAL, so if I can get your pulldown to give me a more fluid playback (than tmpgenc's 29.976 framerate conversion), that's all I am looking for.

I also encoded the final video in interlaced mode...the stutter is still evident using either your pulldown or tmpgencs conversion to 29.976 fps. Like I said earlier, I will try beta8 and see. Do all your conversions play in all your players now? (I only have two stand-alones to test with, and although the sony multi-disc will play svcd's, odd framerates mess it up (they DO play, but the image is all odd and green, like something in night-vision mode))

Still, I've learned more in a few weeks in this forum than anywhere else on line. Thanks to all of you for the help.

p.s. n2, what's your cat's name?

buzzqw

21st February 2005, 15:48

@paulcat

Neuron2 is the Cat (or it seems a cat)... you must ask the name of human pet :D

BHH

Xesdeeni

21st February 2005, 15:57

Originally posted by neuron2
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 how do they telecine 24 to 60 on HD 720p broadcasts?

Xesdeeni

scharfis_brain

21st February 2005, 16:01

@Xesdeeni:
they just repeat the frames and encode at 60fps.

Guest

21st February 2005, 16:09

@Paulcat

If you refuse to use the recommended tools, your support options will be limited. But do try Beta 8, as it may correct misinterpretation of the flags.

I now live in the quantum vacuum. The human is called "Donald". It used to call me "Sheba" for some inexplicable reason; I've been "neuron2" since the 32nd Big Bang. "Donald" has a new feline whose coherent histories currently render it in a non-superimposed quantum state. He calls it "Crystal".

Guest

21st February 2005, 16:13

I think we should give props and kudos to Xesdeeni for seeding these developments with his initial post to this thread.

Guest

21st February 2005, 16:19

Originally posted by scharfis_brain
@Xesdeeni:
they just repeat the frames and encode at 60fps. There's a little known fact about the flags that I must confess. If progressive_sequence is 1, then RFF repeats *frames* like this:

rff = 0 -> one frame (normal)
rff = 1 and tff = 0 -> two frames (one repeated)
rff = 1 and tff = 1 -> three frames (two repeated)

I don't know if this is used in practice. We might try some experiments. But it does explain why some players may have got confused/jerky before I started setting progressive_sequence to 0. It also may help in returning the 720p 60fps material to film rate.

DGDecode currently supports only field repeats.

danpos

21st February 2005, 18:14

Originally posted by neuron2
I think we should give props and kudos to Xesdeeni for seeding these developments with his initial post to this thread.

Yep, DG! Really the topic started by our mate Xesdeeni resulted in that very, very cool app: DGPulldown.

Xesdeeni: kudos! :)

I've to say that new release of DGPulldown has worked like a charm for me, because of the 25 PS pulled down to 29.97 fps through DGPulldown resulted in a NTSC DVD that plays smoothly in my SAP (LG DV5921N). So, I think that you (DG) deserves my respects (and kudos) as well!

Best Regards,

Paulcat

21st February 2005, 18:23

Hmm, did the cat create the pulldown or the man? Heh heh, a cat owns me as well...

I used beta8 to run a new test, and it works like a charm. The pulled-down 25fps video plays as smooth as the original. Whatever you fixed from beta4 to beta8 has done the trick. Very well done!

You should make sure this ends up in the download section here; for anyone doing what I was doing, this is an invaluable tool!

Guest

21st February 2005, 18:33

Originally posted by Paulcat
I used beta 8 to run a new test, and it works like a charm. The pulled-down 25fps video plays as smooth as the original. Whatever you fixed from beta 4 to beta 8 has done the trick. Glad to hear it! I suspected that would be the case. Thank you for your feedback.

jptheripper

22nd February 2005, 17:49

quick question.

i processed a flick with beta 4, and to save space the source m2v is now gone. Is there anyway i can reprocess to beta 8 without re-ripping the raw files? Is it worth the effort?

Guest

22nd February 2005, 19:04

No way and not worth the effort.

mrslacker

22nd February 2005, 20:38

Can't you just reprocess the already processed file? It's not like it matters how the input frames are flagged, just that they are coded at the specified input rate. Right? Might it be worth reprocessing if you have subtitles that require drop_frame to be set and time codes? You also set the progressive_frame and clear progressive_sequence in beta 8. That's a nice seat belt to ensure that the rff flags are interpreted appropriately!

jptheripper

22nd February 2005, 21:51

its no big deal, i can rerip the m2v if playback isnt smooth

Guest

22nd February 2005, 22:10

Originally posted by mrslacker
Can't you just reprocess the already processed file? No, because it's not an elementary stream anymore. He ditched the M2V.

Xesdeeni

22nd February 2005, 22:45

Originally posted by neuron2
There's a little known fact about the flags that I must confess. If progressive_sequence is 1, then RFF repeats *frames* like this:

rff = 0 -> one frame (normal)
rff = 1 and tff = 0 -> two frames (one repeated)
rff = 1 and tff = 1 -> three frames (two repeated)

I don't know if this is used in practice. We might try some experiments. But it does explain why some players may have got confused/jerky before I started setting progressive_sequence to 0. It also may help in returning the 720p 60fps material to film rate.

DGDecode currently supports only field repeats. So, asking the devil's advocate question, and realizing that DGDecode wouldn't handle it correctly, couldn't you revert to frame repeating for frame rates under 2/3 the destination? (I'm thinking about the old films with the weird frame rates, as well as the anime that seems to be so poorly telecined.)

Xesdeeni

Guest

22nd February 2005, 23:03

Yes, of course. I mentioned I will be experimenting in this regard.

Also, there is an outstanding problem with some 720p 60fps material, such that the obvious ways of bringing it back to film rate end up out of sync because frames are "missing". I'm wondering now if they are being repeated with frame repeat flagging! I plan to look again at those streams. If frame repeating is supported by players, it would desirable to support it and enhance DGDecode.

But before that I am making a new deinterlacer with the equivalent of DCDi. There are some screenshots at my web site showing the effect of the EDI method I developed.

So many things, so little time. :(

mrslacker

22nd February 2005, 23:19

Originally posted by neuron2
But before that I am making a new deinterlacer with the equivalent of DCDi. There are some screenshots at my web site showing the effect of the EDI method I developed.

Cool! Hardware with Faroudja chips are extra pricy. A free and tweakable filter would be great, even at the expense of increased bits.

JetlagMk2

23rd February 2005, 20:03

neuron2: I left you a gift on your ftp.

Guest

23rd February 2005, 20:22

Originally posted by JetlagMk2
neuron2: I left you a gift on your ftp. If it was DGPulldown.c.zip, the archive is corrupt. Can you put a good one there and explain what it is about? Thank you.

JetlagMk2

23rd February 2005, 20:42

Oh, I must've forgotten to set bin. :( I made improvements to the timecode, dropframe, and flag generating areas. The top of the file has a better list of what I remember doing. :D Oh, and something that should make scharfis_brain happy. :)

edit:
Well, I might as well put it out there for all to see. It seems to work well enough on my test material.
http://www.jetlag.us/dgpulldown100sje.zip
/*
* What I did
* - Fixed the timecode generation
* - Implemented drop frame timecode
* (in the timecode, not just the flag)
* - Added a timecode offset like "real" DVDs (00:59:59,00)
* - Flag generation is all integer math now
* - Current fps input box now accepts '/' and '*' for
* fractions and multiplication
* - It will also accept numbers with up to 6 decimal places
* - Or a little of each (ie 60/1.001 50/3 23.975444)
* - separated fps checks from generate_flags
* - Watch the timecode while you wait, update per half-meg
* - Maybe some other stuff I can't think of right now
* - My code is not so tight, expect some slop :)
*
* Things I thought about doing
* - remove radio buttons and target fps box replace with two
* drop down menus [23.976,...,60,Custom] [23.976,...,60]
* "Custom" would enable the current fps input box
* - add an option to output timecode to a file
* - add an option to *not* write the converted stream
* (to be used with the above option)
*
* - Jetlag
*
*/

Guest

23rd February 2005, 23:54

Hey, thanks, Jetlag!

I better list you as a co-author.

I'm busy right now bringing up my new Athlon 64FX-55 with Asus A8N-SLI Deluxe with 1GB low latency Corsair memory, so I won't get to your changes for a while. I've only gotten as far as a Windows 95 DOS prompt from a boot floppy. But it's really fast at doing "dir". :) Next is the 10000 RPM Sata drive, Plextor DVD Writer, Windows XP and etc.

tyee

24th February 2005, 05:03

neuron2
Let me know if that SATA 10,000rpm drive is noisy. I assume it's the WD Raptor 74GB?? I'm considering it now. Now back to the topic at hand.

tyee

JetlagMk2

24th February 2005, 05:32

I have some examples so people can see what sort of pattern the generalized flag generation method produces compared to the original method. The generalized method works by inserting a field when the next frame is going to be more than half of a field behind in time. The original method was explained earlier. If you've followed me so far here's some d2v info to look at. Each piece is from the same 25fps PAL source. The first block is the of the demuxed file, the second is the original method, and the third is the generalized method, both performing 25->29.97.

VirtualDub 1.6.4 reports: 25.000 fps 2359 frames (1:34.36)Demux only
c00 1 0 0 0 0 f2 f2 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 15964 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 312468 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 741084 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 1331604 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 1813716 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 2398868 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 3006236 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 3523512 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 4080320 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 4625612 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 5195356 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 5766536 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 6332192 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
800 1 0 6918648 0 0 72 72 d2 f2 f2 e2 f2 f2 e2 f2 f2 e2 f2 f2 e2
...
VirtualDub 1.6.4 reports: 29.970 fps 2828 frames (1:34.36)Original method (100b4)
c00 1 0 0 0 0 f2 f2 d2 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 15964 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 312468 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 741084 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 1331604 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 1813716 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 2398868 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 3006236 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 3523512 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 4080320 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 4625612 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 5195356 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 5766536 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 6332192 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
800 1 0 6918648 0 0 73 70 d1 f2 f2 e3 f0 f1 e2 f2 f3 e0 f1 f2 e2
...
VirtualDub 1.6.4 reports: 29.970 fps 2828 frames (1:34.36)Generalized method (100sje)
c00 1 0 0 0 0 f2 f3 d0 f1 f2 e2 f3 f0 e1 f2 f2 e3 f0 f1 e2
800 1 0 15964 0 0 72 73 d0 f1 f2 e2 f3 f0 e1 f2 f2 e3 f0 f1 e2
800 1 0 312468 0 0 72 73 d0 f1 f2 e2 f3 f0 e1 f2 f2 e3 f0 f0 e1
800 1 0 741084 0 0 72 73 d0 f0 f1 e2 f3 f0 e0 f1 f2 e3 f0 f0 e1
800 1 0 1331604 0 0 72 73 d0 f0 f1 e2 f3 f0 e0 f1 f2 e3 f0 f0 e1
800 1 0 1813716 0 0 72 73 d0 f0 f1 e2 f3 f0 e0 f1 f2 e3 f0 f0 e1
800 1 0 2398868 0 0 72 73 d0 f0 f1 e2 f3 f0 e0 f1 f2 e3 f0 f0 e1
800 1 0 3006236 0 0 72 73 d0 f0 f1 e2 f3 f0 e0 f1 f2 e3 f0 f0 e1
800 1 0 3523512 0 0 72 73 d0 f0 f1 e2 f2 f3 e0 f1 f2 e2 f3 f0 e1
800 1 0 4080320 0 0 72 72 d3 f0 f1 e2 f2 f3 e0 f1 f2 e2 f3 f0 e1
800 1 0 4625612 0 0 72 72 d3 f0 f1 e2 f2 f3 e0 f1 f2 e2 f3 f0 e1
800 1 0 5195356 0 0 72 72 d3 f0 f1 e2 f2 f3 e0 f1 f2 e2 f3 f0 e1
800 1 0 5766536 0 0 72 72 d3 f0 f1 e2 f2 f3 e0 f1 f2 e2 f3 f0 e1
800 1 0 6332192 0 0 72 72 d3 f0 f1 e2 f2 f3 e0 f1 f2 e2 f3 f0 e0
800 1 0 6918648 0 0 71 72 d3 f0 f0 e1 f2 f3 e0 f0 f1 e2 f3 f0 e0
...
RFFs are red. You'll see how the generalized method's pattern is sort of drifting between 22301 and 23001. The patterning looks neat and theoretically keeps better sync, but I can't really say if the output looks any different.

JetlagMk2

24th February 2005, 14:02

It looks like my dropframes are off. :( New version soon...

Paulcat

24th February 2005, 14:03

Originally posted by neuron2
Hey, thanks, Jetlag!

I better list you as a co-author.

I'm busy right now bringing up my new Athlon 64FX-55 with Asus A8N-SLI Deluxe with 1GB low latency Corsair memory, so I won't get to your changes for a while. I've only gotten as far as a Windows 95 DOS prompt from a boot floppy. But it's really fast at doing "dir". :) Next is the 10000 RPM Sata drive, Plextor DVD Writer, Windows XP and etc.

Must be NICE...had a lottery win have we? Heh heh..

ehonauer

24th February 2005, 16:07

I've been looking for a good PAL -> NTSC method for some time. Thank you Donald! I'll have to try this out with one of my PAL discs.

I agree that AVSynth is easy to use, but keep in mind some people aren't even comfortable using a command prompt, so...

JetlagMk2

24th February 2005, 20:46

http://www.jetlag.us/dgpulldown100sje2.zip

The dropframes should be dropping at the right times now.

Guest

25th February 2005, 07:31

Originally posted by Paulcat
Must be NICE...had a lottery win have we? Heh heh.. Something like that. :D

It's up and running now. I can preview an SD transport stream in DGIndex at 146 fps. Wheeee!

So far, no AVS script I've run has played less than real time. BSPlayer just shows 29.97 play rate for everything. I'm not even denting this thing yet. Wow, even mf's scripts might become usable. :sly:

Guest

25th February 2005, 07:33

Originally posted by tyee
Let me know if that SATA 10,000rpm drive is noisy. I assume it's the WD Raptor 74GB?? I'm considering it now. Now back to the topic at hand. Yeah, that's the one. No, it is fine.

Xesdeeni

25th February 2005, 15:30

I realize this is OT, and I'll start another thread if you like (I started one before (http://forum.doom9.org/showthread.php?s=&threadid=84519), but I don't know if you saw it).

Would it be possible to use DxVA, or a codec that can use DxVA to help speed up the decode further in DGDecode? Moonlight has one (http://moonlight.co.il/support/research/dxva/).

Xesdeeni

pipieye

26th February 2005, 21:25

@jetlag
Tested your sje2 version and maestro did not like it.
The import chapters all got screwed up, meaning the imported markers are off.
Or does this mean now we also need to translate the chapter timelines to 29.976 to get this to be in sync again?
Pipi

JetlagMk2

28th February 2005, 00:33

I do not use maestro but I would think the chapter marks might need to be changed.

Something like:
newmark = oldmark * newfps / oldfps

pipieye

28th February 2005, 07:03

@jetlag
I used neuron's version and all is in sync.
So not sure what your version had any advantage over neuron's.
Thanks
Pipi

Guest

28th February 2005, 14:13

Originally posted by pipieye

I used neuron's version and all is in sync.
So not sure what your version had any advantage over neuron's.
Which version of mine? My version 1.0.1 incorporates Jetlag's most recent contributions, except that the dropframes checkbox is not AUTO3STATE.

JetlagMk2

28th February 2005, 17:26

Any particular reason you chose to leave that out? The 3rd state lets the program choose to drop frames based on the target framerate, non-integer framerates get drop, integer framerates get nondrop. Forcing the opposite setting will cause the timecode to drift.

unixfs

28th February 2005, 17:37

Hi,
I'm very new to telecining in general, so I'd like to ask a couple
of newbye questions about the classical soft-telecining: 23.976 -> 29.97 and 24->30 header tricks.

I guess I have to always unset the progressive_sequence and always set
the progressive_frame (besides the tff/rff cycle), correct?

Should I apply telecining to frames sorted in display (rather than decoding), correct?

What about timestamps? Should I recalculate them after telecining
(so 1 frame out of two will last 1.5 * patched nominal framerate),
or should I leave them as they are before telecining?

Thanks.

JetlagMk2

28th February 2005, 18:12

Originally posted by unixfs
I guess I have to always unset the progressive_sequence and always set
the progressive_frame (besides the tff/rff cycle), correct?

Correct.

Should I apply telecining to frames sorted in display (rather than decoding), correct?
It is applied in display order.

What about timestamps? Should I recalculate them after telecining
(so 1 frame out of two will last 1.5 * patched nominal framerate),
or should I leave them as they are before telecining?

The timestamp is relative to the decoded frames, so you recalculate. But if you're not changing the speed at which the film plays the HH:MM:SS portion of the timestamp will already be correct. But if you want it perfect you recalculate. I simply counted the fields as the file gets parsed.

Guest

28th February 2005, 18:15

Originally posted by JetlagMk2
Any particular reason you chose to leave that out? The 3rd state lets the program choose to drop frames based on the target framerate, non-integer framerates get drop, integer framerates get nondrop. Forcing the opposite setting will cause the timecode to drift. Well, you didn't document that and it wasn't obvious to me why there were three states, and so I thought it was confusing to the user. I've not received my diploma in mind reading. :)

I'll put it back and add a description to the text file tonight.

mpucoder

28th February 2005, 19:27

Just started reading this thread, so forgive me if I missed something in the 25 pages! Back around page 6 there was talk about the legal mpeg-2 framerates, and "how could you encode a 22fps source?". Are you guys aware of the frame_rate_extension data in the sequence_extension header? This allows you to alter the framerate by a ratio of n/d, where n can be from 1 to 4, and d is from 1 to 32. It's not legal in DVD, but it is for elementary streams that you might want to add pulldown to. You can't get exact, but 3/4 of 29.97 is close to 22 (22.4775). The lowest mpeg-2 can go is 24/32, or 3/4fps. The highest is 4*60.

Also pulldown can be done on a frame basis if the progressive sequence flag is set. This requires all pictures to be frame pictures, and progressive.

Guest

28th February 2005, 20:22

Originally posted by mpucoder
Just started reading this thread, so forgive me if I missed something in the 25 pages! Back around page 6 there was talk about the legal mpeg-2 framerates, and "how could you encode a 22fps source?". Are you guys aware of the frame_rate_extension data in the sequence_extension header? This allows you to alter the framerate by a ratio of n/d, where n can be from 1 to 4, and d is from 1 to 32. It's not legal in DVD, but it is for elementary streams that you might want to add pulldown to. You can't get exact, but 3/4 of 29.97 is close to 22 (22.4775). The lowest mpeg-2 can go is 24/32, or 3/4fps. The highest is 4*60. I assume the majority of users want this tool for making DVDs.

Also pulldown can be done on a frame basis if the progressive sequence flag is set. This requires all pictures to be frame pictures, and progressive. Yes, we discussed that.

mpucoder

28th February 2005, 21:13

Originally posted by neuron2
I assume the majority of users want this tool for making DVDs.
True, but wasn't there some discussion about home movies, old silent films, etc being converted to DVD and how to express their framerate, prior to pulldown, in mpeg-2?

manono

28th February 2005, 21:45

...but wasn't there some discussion about home movies, old silent films, etc...

That may have been me. Hi mpucoder. I was speculating that maybe 18fps home movies and silent films at any framerate could be DGPulldown'd for DVD, until I was set straight that the minimum was 20fps. Since then I've done one for 25->29.97fps, 1 for 22->29.97fps, and several for 20->29.97fps. All play fine on any DVD player I've tried, software or hardware.

I'm sorry, but I didn't understand most of what you wrote in your first post in this thread, but were you implying that it may be possible to create DVDs using framerates lower than 20fps? That is, store, for example, 18fps on the DVD, and then Pulldown to 29.97fps?

mpucoder

28th February 2005, 21:57

Originally posted by manono
were you implying that it may be possible to create DVDs using framerates lower than 20fps? That is, store, for example, 18fps on the DVD, and then Pulldown to 29.97fps? No, not under most circumstances. There were two things I was pointing out, one was how to express non-standard framerates so that a pulldown program would automatically know what to do.
The other was about progressive sequences, and that they can be used to convert from as low as 10fps to NTSC. But they are not practical, too many other conditions must be true to be able to use them.

manono

1st March 2005, 03:23

OK, thanks for the explanation, mpucoder.

I've used your MuxMan on a number of occasions, including several times when testing out neuron2's DGPulldown. Unless it was I that had screwed something up, it's always worked great. It's much appreciated.

digidragon

1st March 2005, 14:27

I notice that in the latest versions the 'Set timecodes' and 'Set drop frames' options are checked by default. Should these be left checked when converting for normal DVD playback?

Guest

1st March 2005, 14:46

Originally posted by digidragon
I notice that in the latest versions the 'Set timecodes' and 'Set drop frames' options are checked by default. Should these be left checked when converting for normal DVD playback? They're set for compatibility with some DVD authoring applications. I would leave them set unless they cause problems. I'm not aware of any cases where they cause any problems, however.

tyee

1st March 2005, 16:59

I would leave them set unless they cause problems. I'm not aware of any cases where they cause any problems, however

One thing that comes to mind is that if I import an m2v into my authoring application, once it finishes scanning it, it will show the full running time in either drop or non-drop timecode. Usually when using non-drop T/C, both the audio and video running times agree within a couple of frames, but if encoded with drop-frame T/C I believe the audio and video will show different values.

It's nice to have both show the same time. So my next question is if we use drop-frame for video, how do we get the audio timecode to show drop-frame also? Can it be done or shall we just not worry about it.

tyee

powderkegz

1st March 2005, 17:24

So I've been following this thread with great interest for quite a long time, and am extremely excited at what I've seen come out of it.

My question goes to the one-clickableness of this all now - would it now be possible to use this program in conjunction with DVD-Rebuilder to easily do a PAL->NTSC conversion? Is there a simple way to convert menus from PAL->NTSC? I thought I remembered someone mentioning a program to do this, but now I can't find that post .... Also, does the use of DGPulldown affect the timing of subtitles at all? Obviously, in converting PAL->NTSC, you deal with a lot of subtitled material.

Thanks for all the wonderful work you all have done - we really appreciate it.

Peace,
powderkegz

jptheripper

1st March 2005, 20:59

numenu4u will do pal to ntsc conversion i believe, however, if you have audio its an issue.

as for rebuilder, i would love this. the issue at the moment is the menus i think.

mrslacker

1st March 2005, 22:29

Yes, I think the integrated menu support would be necessary in DVD-RB before this pulldown technique could be used with Rebuilder. What good is an NTSC movie with a PAL menu? When and if Rebuilder gets support for menu processing, the world of standards conversion will be wide open. I guess conventional conversions can be done with the filter editor (??), but NuMenu4U seems to be the easiest or only way to handle the menus at the moment.

pipieye

2nd March 2005, 05:43

Originally posted by neuron2
Which version of mine? My version 1.0.1 incorporates Jetlag's most recent contributions, except that the dropframes checkbox is not AUTO3STATE.

Sorry for the delayed response.
Using 1.0.0 Beta8 with Maestro has perfect sync on subtitles, chapters and audio all using the 25fps with no timestretching.

I'm not sure with other authoring software...

I use this mainly to do PAL->NTSC conversion, now only needed to reencode @25fps with 720x480 without touching the rest.

Guest

2nd March 2005, 14:28

@pipieye

I don't use Maestro. I don't know what a chapter mark is, where it is stored, or how to change it. If you or Jetlag can assist in this regard I can make approriate changes, otherwise you'll just have to use the earlier version.

Paulcat

2nd March 2005, 22:34

Since this thread has a lot to do with converting from PAL to NTSC, I need help with an error I encountered today.

Using TMPGEnc to encode a 25 fps M2V file, and DGPulldown (1.0.2) to pull the framerate to 29.976, I tried to encode my file to DVD format only to be hit with a "Too long GOP" error. My settings in TMPGEnc indicate my max. frames per GOP is 18 (for NTSC DVD).

I tried loading the un-pulled down 25 fps file into my authoring software and got the same error (as well as a 720x480 resolution cannot be used with a framerate of 25 error!)

Is this a problem with the source material? The original, re-sized, and pulled-down M2V's all play fine. My authoring software will allow me to ignore this error and make a "non-standard" dvd...is this a good idea or will it be a coaster...

Any ideas out there?

Guest

2nd March 2005, 23:45

Load the pulled down M2V in DGIndex and generate a project. Then verify that the frame rate is detected as 29.97, the size is 720x480, and that none of the GOP lines in the D2V have more than 18 pictures. The first 6 numbers per GOP line should be skipped; the rest are pictures.

If they're all true, it can't hurt to try it. One coaster won't bankrupt you.

Which TMPGEnc version are you using? I've done this with 2.5 without any such problems. The fact that it happens with the unpulled-down M2V tends to exonerate DGPulldown.

Jeffster

3rd March 2005, 04:55

Your goal with TMPGenc is to encode a new PAL (25fps) video stream (which just happens to be 720x480). The max. GOP length for PAL is 15 (12 recommended).

Perhaps that is why you are getting that error because you are encoding your PAL stream with a GOP length of 18 which is illegal?

Guest

3rd March 2005, 05:32

Yeah, that sounds right. Just go ahead and force it.

Jeffster

3rd March 2005, 06:19

I just tested a thought I had...

Encoded a resized PAL stream with a GOP length of 15 (3/5).
After running DGPulldown on it and creating a d2v of the pulldowned file (29.970fps), it now has a GOP length of 18, checked with info of DGDecode.

So, I imagine if you encoded a PAL stream with a GOP length of 18 as you tried, the pulldowned file will be >18?

I can't check that because CCE won't allow me to set a GOP length greater than 15, but it seems logical :)

Guest

3rd March 2005, 09:14

That's not possible (for the GOP structure to be changed by pulldown).

Jeffster

3rd March 2005, 11:11

Originally posted by neuron2
That's not possible (for the GOP structure to be changed by pulldown).

ooops... I was just counting the number of frames to the next GOP change, watching the info from DGDecode (and not thinking) :o

What I was counting was the Display frames, and I didn't differentiate between that and the number of Encoded frames between GOP's which hasn't changed, of course. Sorry for the confusion. :scared:

Paulcat

3rd March 2005, 13:14

Thanks for the help. I changed my GOP settings one at a time, and checked each result with my authoring program, and once I got down to maximum 15 frames/GOP, everything worked.

It's odd, because although the SOURCE material was PAL, the final file is in NTSC, and should accept a maximum GOP size of 18.

Donald: I am using TMPGEnc Plus 2.524 (the latest version), and yes, your DGPulldown works fine!

What difference does the GOP size make to the final picture in any case? More I-frames, larger file size? What?

Guest

3rd March 2005, 15:50

You can force the GOP to 18. After pulldown, the frame rate, size and GOP structure will then be just right for DVD authoring. TMPGEnc is just warning you. He doesn't know you plan to pull it down subsequently!

Smaller GOP generally means more I frames and thus a larger encoded file.

mpucoder

3rd March 2005, 18:42

Originally posted by neuron2
That's not possible (for the GOP structure to be changed by pulldown).
Sure it is, GOP size is measured in displayed frames. Every rff adds a field to the GOP size.

JetlagMk2

3rd March 2005, 22:24

I added some more functionality.

* The timecode now starts at the same point as the input file OR whatever time you specify.

* Write timecode to a textfile.

* "No change" - Don't perform pulldown.

* "No output" - Don't write output.

With various combinations of the options all manner of silly things can now be done. Default settings are most likely what you need, though.

Maybe the first thing on the list will help rectify sub & chapter point problems. :confused:

http://jetlag.us/dgpulldown100sje3.zip

mpucoder, when muxman imports chapter points, is it looking for the encoded frame number, or the display frame number? What I mean is, would the numbers have to be changed after pulldown is run on a file?

Guest

3rd March 2005, 22:29

Originally posted by mpucoder
Sure it is, GOP size is measured in displayed frames. Every rff adds a field to the GOP size. I was clearly referring to the encoded GOP structure.

powderkegz

4th March 2005, 16:48

OK, now I've gotten a bit confused - would someone please explain to me the difference between jetlag's and neuron2's versions of DGPulldown?

Thanks,
pk

Guest

4th March 2005, 18:33

Jetlag has been contributing enhancements and improvements. Instead of sending me the changes he prefers to just release his own version. It causes confusion, but if he prefers it that way, it's fine by me. Right now, he's a version ahead with his sje3; I've incorporated changes up to and including sje2.

pipieye

5th March 2005, 06:38

Originally posted by JetlagMk2

Maybe the first thing on the list will help rectify sub & chapter point problems. :confused:

Hi Jetlag/Neuron:
Sample of Maestro chp file to import chapter points:
$Spruce_IFrame_List
00:00:00;00
00:03:05;04
00:05:58;21
00:08:55;07
...

Chapter points were created from the original 25fps IFO file.

Sample subtitle file to import into Maestro created using subrip:
st_format 2
Display_Start non_forced
TV_Type PAL <-- edit to NTSC
Tape_Type NON_DROP <-- edit to DROP
Pixel_Area (0 575) <-- edit to 479
Directory K:\Programs\Encode\demux\bmp

#
# Palette entries:
#
# 00 : RGB(255, 0, 0)
# 01 : RGB(255,255,255)
# 02 : RGB( 0, 0,255)
# 03 : RGB( 0, 0, 0)
#

SP_NUMBER START END FILE_NAME
Color (0 1 2 3)
Contrast (0 15 15 15)
Display_Area (000 000 719 479)
0001 00:00:22:08 00:00:28:00 test00001.bmp
Display_Area (000 000 719 479)
0002 00:00:28:02 00:00:31:10 test00002.bmp

I guess the important part is the timecode which gets manipulated and throws the sync off from 25fps to 29.976fps???

Pipi

JetlagMk2

5th March 2005, 16:37

I notice they both rely on timecodes, so messing with timecodes could certainly mess up the sync. beta 8 started timecodes at 00:00:00,00, which happens to coincide with your example, so the result would just happen to work. My first version started the timecode at 00:59:59,00, because that's what a lot my material was starting at. My second version was supposed to start there too but I broke it just before releasing it and didn't notice. :scared: My third revision now looks into the input file and takes note of where it starts and uses that (unless you manually override it). It *should* stay in sync now for any starting timecode as long as the length of the video is not changing (and it shouldn't change if you're just doing pulldown and not changing it on purpose).

DMagic1

5th March 2005, 20:04

I just did my first project with this. It worked perfectly. Very nice solution.

Zeul

6th March 2005, 20:50

Just wondering how far this can go for NTSC -> PAL ?

Guest

6th March 2005, 21:26

Originally posted by Zeul
Just wondering how far this can go for NTSC -> PAL ? Nowhere.

scharfis_brain

6th March 2005, 21:36

the only possible NTSC to PAL conversion is:
progressive NTSC-Film telecined to PAL

pipieye

7th March 2005, 00:36

A little off topic
My little contribution to this site...
Its a little app I wrote to batch modify the mbl files created by the export button option of DVDRemake to convert from PAL to NTSC.
For those movies with BOVs....

Sorry no help file... but should be easy to use.
Open the mbl and click convert.
Or click on batch and point to a folder with your mbl files.
A newmbl folder will be created.

Then import newmbl back to your NTSC created vobs.

edit: sorry the server complained file is too big to post. :(

Pipieye

spon

12th March 2005, 02:11

Hello all. I've read thru this entire thread and must admit that most of it is (way) above my head and I really appreciate all the hard work that went into this utility. I think it's something that a lot of people will find very useful. That being said, I'm having a problem with the audio sync.

In the past in order to convert PAL to NTSC i've had pretty good success using the assumefps (23.976) command in my script and then slowing down my audio in BeSweet to 23.976 also. works pretty good, but I thought I'd try this new technique.

I converted my PAL avi to a PAL mpeg 2 file using DVD2SVCD (settings on AVI2DVD). I then ran the m2v file thru DGPulldown with the default settings and 25fps -> 29.976.

I then loaded the resulting m2v file and the original AC3 audio file (which I demuxed from the original PAL avi file) into TMPGEnc DVD Author to author the DVD. The resulting picture looks great, however the audio is out of sync.

Any ideas?

Thanks

pipieye

12th March 2005, 03:37

@spon,
Before you demux your avi file, check to see the a/v delay in the original avi muxed file. Sometimes there is a delay offset.
Pipi

spon

12th March 2005, 03:55

thanks pipieye. this is going to be a stupid question, but how would I check that? I checked G Spot, Vdub and Vdub mod but don't see any indication of a delay. where would I look?

manono

12th March 2005, 10:38

HI-

I don't think it's just a delay issue (unless you're counting progressive asynch). You probably shouldn't be using DVD2SVCD for this, as it doesn't support DGPulldown. If you set it for PAL->NTSC, it'll give you a slowed down 720x480 .m2v. If you leave it at the PAL setting, it's going to give you an .m2v at the correct length and FPS for DGPulldown, but at 720x576. Neither is any good for the purposes of using DGPulldown to make a 25->29.97fps NTSC DVD.

What resolution is that .m2v? 720x576? If so, it wouldn't be NTSC compliant, and perhaps TMPGEnc DVD Author did something to it that screwed up the audio. I've used DVD2SVCD quite a bit, but I've never used TMPGEnc or TMPGEnc DVD Author, so I have no idea what it did to your .m2v, if anything.

You might compare the original AVI length, with the length of the authored DVD. If somewhere along the line the video got converted to 23.976fps, for every 100 minutes of movie, the NTSC version will be about 4 minutes longer, and the audio asynch will get worse (4 minutes worse eventually) as the movie goes along. But if your audio asynch is constant and small, then it can be fixed once you know the delay. Don't ask me how, though, as I don't know. Maybe pipieye does.

spon

14th March 2005, 04:56

thanks guys. believe it or not, I think the problem was that I simply had the wrong conversion button pressed or something. I ran my PAL m2v file thru again and this time it synced up perfectly.

In case anyone else wants to try this method, what I did in DVD2SVCD was simply click on the "edit before video encoding" button in the FrameServing tab. Then when the avisynth script opened up I changed the encoding size to 720*480. That way it produced a PAL video with NTSC size. Then after running it thru DGPulldown it worked great!

manono

14th March 2005, 05:17

Hi-

what I did in DVD2SVCD was simply click on the "edit before video encoding" button in the FrameServing tab. Then when the avisynth script opened up I changed the encoding size to 720*480.

Ahh, good thinking. I forgot about that. Glad you got it working OK. Another convert. :)

hoozdapimp

16th March 2005, 18:38

so what exactly would happen if you fed this thing a 25i source? I don't have any 25i to test it with. My severe lacking of knowledge regarding the mpeg2 standard leaves me no obvious answer to this question :)

Guest

16th March 2005, 20:24

Suppose you have this where the top line is the top field and each letter is a new picture:

A C E
B D F

If you pulldown the first frame, you get:

A A C E
B D F

...which gives a temporal sequence of:

A B A D C F E

...which is all screwed up. If you have progressive video it looks like this:

A A B C
A B C

which gives a temporal sequence of:

A A A B B C C

mpucoder

16th March 2005, 22:29

You would also have to encode it as progressive in order for the pulldown to work. rff can only be set for progressive frame pictures.

Rombaldi

20th March 2005, 20:36

Unintended benefit or stupid cockup??

I had been following this thread for a while with interest, and finally had a use to give it a try. Had the complete run of a US series that someone in the UK recorded for me (on DVD-R) that had been cut short over here (and several left unshown, and they were widescreen to boot over there.. but I digress) so I thought I would give this a go.

(wait till the end if you see this coming).

Extracted the MPEG program file from the DVD-R, edited the adverts, saved and split to M2V/AC3 files.

Procoder to do the re-encode for a 'quick' test.

Used it's adaptive deinterlace. Set the output to PAL/25FPS Progressive, overrode to make the output 720x480. Ran quickly with no problem. Checked the length of the program before and after encode. Same down the frame.

Ran it thru DGPULLDOWN... and the time came out 4% LONGER. 40:35:11 vs 42:19:44. Huh?

I had done three episodes at once, and checked them all, all came out 4% longer. Audio obviously way the smeg out of sync.

I did find it curious that it had (effectively) reversed the 'PAL Speedup' of the video (the episodes after Pulldown were the SAME LENGTH as a NTSC recording I had done of some of them). So I mentally said to myself "must be a Procoder 'glitch'" and for the heck of it, went AC3 > WAV on the audio, used CoolEdit to 'stretch' it back to the new length (and drop the pitch 4% in the process). Back to AC3, authored/burned the discs and threw them in the player.

PERFECTION! Smooth picture, no jerkyness or stutter, audio synced up perfectly all the way thru... tried it on several different players (including a finicky Panasonic DVD-Recorder) and no problems anywhere, you could not tell them from a 'native' NTSC disc.

I started the next batch, encoded the same way, using the same version of DGPULLDOWN...

...and this batch, the time didn't change on the PD'ed files. The new files matched the length of the original files and the same length as the PAL audio track.

WTF?

After several hours of re-encoding, pulldown and experimentation, I found what I had done 'wrong' the first time.

Instead of having DGPulldown set to 25 -> 29.97, I had neglected to change it from the default of 23.976 -> 29.97. Every time I ran it that way, the run time went 'up' by 4%.

So, instead of taking a changing a 25fps stream to 29.97fps, it was taking a 25fps stream, assuming it was 23.976fps and changing that to 29.97fps.

The problem is, it dosen't appear to 'hurt' anything, and has the unxpected benefit of 'undoing' the PAL speedup. Sure, I have to dink with the audio track, but I had planned to at least do the 4% pitch correction to bring the sound back down to 'normal' from munchkin talk.

I'm SURE this will only work this way on NTSC material that was converted to PAL (and now effectively being converted back), but the question is...

.. did I do something 'wrong' or was this one of those 'ah ha' moments where something 'good' happens when you don't expect it? Or is it something that will bite me in the butt when I least expect it?

I guess it's true that me most interesting words in research aren't "EUREKA!" but "hmmm.. that's strange...".

DMagic1

21st March 2005, 08:03

Is there any way to do a batch process with this? I'd like to do multiple files at once.

Guest

21st March 2005, 14:47

@DMagic1

Not at this time.

Guest

21st March 2005, 14:51

@Rombaldi

Yes, you can use the tool that way. Most people prefer not to have to process the audio, but if you prefer that approach, go for it.

Rombaldi

21st March 2005, 19:57

@neuron2

Coolness... it only takes me about 5 minutes to 'stretch' an audio file so it's not a biggie. For stuff that is PAL in origin then there (appears) to be no need to do it, but for the NTSC>PAL>NTSC trip it makes a big diff..

Kudos to all involved for such a great tool, it's working like a charm!

scotty47

26th March 2005, 22:45

I am new to burning movies, when i tried to join 3 files in Lab pro the files are mpeg, it would not join them and said they were pal format, how can I check if something is in pal. thanks.......scotty

johnruiz

28th March 2005, 07:31

Originally posted by spon
In case anyone else wants to try this method, what I did in DVD2SVCD was simply click on the "edit before video encoding" button in the FrameServing tab. Then when the avisynth script opened up I changed the encoding size to 720*480. That way it produced a PAL video with NTSC size. Then after running it thru DGPulldown it worked great!

Tried this method last night, couldn't get it to work.

Dvd2Svcd would not resize to NTSC (720.480)
unless I add an NTSC framerate(23.976)into avisynth.

What am I missing?
Do I need to adjust any other settings?

Edit:Found a solution.

Guest

28th March 2005, 15:14

Originally posted by scotty47
I am new to burning movies, when i tried to join 3 files in Lab pro the files are mpeg, it would not join them and said they were pal format, how can I check if something is in pal. thanks.......scotty This seems unrelated to this thread.

PAL will be 25fps and typically have a height of 576.

scotty47

28th March 2005, 15:25

Opp's Sorry.........................scotty47

nnigam

28th March 2005, 21:48

I have read this long, and informative thread. I plan to try this tonight. My source is a home video dvd I received with a mpeg file which is 720x576 progressive, 25fps pcm audio. I demuxed this with dgindex. Converted the wav to ac3 format. Then pulled the ac3 and the m2v into dvdauthor checking this as a ntsc dvd. It did the conversion correctly and audio synched up. It played perfectly on my pc, but the dvd player showed color overlays, offset picture etc.

I plan on trying dgpulldown tonight, but I was wndering if the color space had anything to do with my problem when creating the m2v with avisynth script in quenc. My original file though of PAL dvd specs was not a dvd file but a simple mpg file.

Also, I read somewhere about fixing the frame rate in video that has different frame rates. Will this work on TS files. I have several where the advertisements are at a different frame rate then the program causing an audio synch errors.

video

31st March 2005, 11:49

neuron2.. almost there.

so I've started with an ntsc dvd, tv series, progressive (dead like me, complete season 1).
tried to transcode to pal. DGIndex told, that it's safe to do, so i froced film.
i did 1x02.avs as:

mpeg2source(1x02.d2v, cpu2="oooooo", idct=7)
lanczosresize(720, 576)

then encoded it with hank's HC-12, 2 pass, progressive, 23.976 fps, gopsize 12, 2 b-frames
after that i instrumented 1x02.m2v with DGpulldown 23.976->25, got 1x02.pulldown.m2v
remuxed with audio, and dvd-authored.
an rw disc is burnt and put into rotel rdv-1050, i set up for progressive output and expected 23.976fps on component, but it wasn't 23.976. it was telecined 25fps. feeding back 1x02.pulldown.m2v to DGIndex, it says NTSC 87% :rolleyes:
what did i wrong?

Guest

31st March 2005, 14:38

@video

You start with an NTSC DVD. There is no need to use DGPulldown at all.

Tell me exactly what you are trying to accomplish. Without knowing that I can't tell you where you went wrong.

It sounds to me like you used DGPulldown to flag 23.976 to 25fps. Then you complain that the output is flagged 25fps???

If it's a player issue you are raising, I don't know anything about how progressive players would handle this. But why bother flagging if you want progressive playback?

video

31st March 2005, 15:57

Originally posted by neuron2
@video

You start with an NTSC DVD. There is no need to use DGPulldown at all.

Tell me exactly what you are trying to accomplish. Without knowing that I can't tell you where you went wrong.

It sounds to me like you used DGPulldown to flag 23.976 to 25fps. Then you complain that the output is flagged 25fps???

If it's a player issue you are raising, I don't know anything about how progressive players would handle this. But why bother flagging if you want progressive playback?

may I ask back? Why does MGM telecine 23.976fps up to 29.97? :D I wanted to achieve the same.
with a progressive display i intended to have 23.976fps however i wanted to make the disc playable on conventional PAL tv/player, too ;)

if i encode with gop size 24, may it work, what do you think?

Guest

31st March 2005, 17:08

Originally posted by video
May I ask back? Why does MGM telecine 23.976fps up to 29.97? :D I wanted to achieve the same. Then why did you pull it down to 25fps?

however i wanted to make the disc playable on conventional PAL tv/player, too ;) You can flag it to 25 or 29.97. There's no way to do both at the same time.

if i encode with gop size 24, may it work, what do you think? It will not work.

video

31st March 2005, 18:01

Originally posted by neuron2
Then why did you pull it down to 25fps?

because most of the tv sets here doesn't support 23.976fps progressive, neither ntsc and nor even pal60, i mean 15+ yeras old tv sets. oops i may try not pull it down at all, leave it 23.976, but i feel that's illegal for a dvd...

Originally posted by neuron2
You can flag it to 25 or 29.97. There's no way to do both at the same time.

afaik i didn't flag it 29,97

Originally posted by neuron2
It will not work.
sad news...

manono

31st March 2005, 19:35

I don't understand, video. Didn't your DVD play OK on your player? From what I can gather, it played fine on yours, but you're afraid it may not play well on other players? The only way to be sure is to try on as many other players and TV sets as possible, but my guess (not being in a PAL area) is that it will play well on all of them.

an rw disc is burnt and put into rotel rdv-1050, i set up for progressive output and expected 23.976fps on component, but it wasn't 23.976. it was telecined 25fps. feeding back 1x02.pulldown.m2v to DGIndex, it says NTSC 87%

That's to be expected. Sounds just right. If you have an all progressive setup, you should get back all progressive frames when played. Advance a frame at a time with your player and check. I've used DGPulldown with many different basic framerates, not just PAL 25fps to NTSC 29.97fps, and they all play well on mine and all the others on which I've tested.

video

31st March 2005, 19:59

Originally posted by manono
If you have an all progressive setup, you should get back all progressive frames when played. Advance a frame at a time with your player and check. I've used DGPulldown with many different basic framerates, not just PAL 25fps to NTSC 29.97fps, and they all play well on mine and all the others on which I've tested.

24 frames in a gop and works :) i mean 23.976 when progressive mode turned on, and telecined 25fps when progressive mode turned off. - however, a 24 frame gop is a little bit out of spec, afaik. i feel that rotel might get confused on this telecine. 23.976->25 mean the player should out approx. 25 frames from 24, and the gop size is 12, so it's a sequence of gops having rff frames and not having rff frames.

manono

31st March 2005, 20:53

Actually I said that a bit wrong last time. Of course you'll get back all progressive frames on a progressive display. What I meant to say is that you should get back only the stored frames, and not the telecined additional frames. Since the "deinterlacing" chipsets in most Progressive Scan DVD players are better than those in the HDTVs, I don't know why you'd want to output 480i to the TV, letting it take over the "deinterlacing". Maybe you're just testing. But mine's a cadence reader, and maybe flag readers behave differently (and worse). Of course, when played on a standard interlaced PAL TV set, the telecined 25fps will be played.

Xesdeeni

31st March 2005, 22:43

Speaking of that. I have a cheap progressive DVD player. It handles the handful of movies I've viewed pretty well. But I have some educational cartoons for my daughter that it can't handle at all. As with most cartoons, they're even less than 24 fps (although I haven't checked to see exactly how much less). I'm assuming the flags are such that the player gets confused. What's the best way to fix them? Do I have to re-encode to ensure progressive encoding? Do I need to run the extracted MPEG through a utility to strip the flags before I try DGPulldown? Or do I need more specific info before you can suggest a course? If so, what tool would give me the flag info?

Xesdeeni

mpucoder

31st March 2005, 22:47

Maybe there's nothing wrong with the flags? Have you tried the cartoon on a software player, or another standalone?

video

31st March 2005, 22:50

Originally posted by manono
Actually I said that a bit wrong last time. Of course you'll get back all progressive frames on a progressive display. What I meant to say is that you should get back only the stored frames, and not the telecined additional frames. Since the "deinterlacing" chipsets in most Progressive Scan DVD players are better than those in the HDTVs, I don't know why you'd want to output 480i to the TV, letting it take over the "deinterlacing". Maybe you're just testing. But mine's a cadence reader, and maybe flag readers behave differently (and worse). Of course, when played on a standard interlaced PAL TV set, the telecined 25fps will be played.

manono okay. yes it was about testing how to do the best ntsc-pal transcode from progressive ntsc source. traditional way, such as speed up and resample/recode audio has a lot of drawbacks. companies like MGM do this, because they have the audio on 24/192 or similar LPCM or MLP format, but if you transcode a dvd it's about redo a lossy compression with pitch artifacts (speeding up soundtrack). professionals have expensive and good audio tool suite to even preserve pitch of the speeded up soundtrack. hobbist may not have such an advanced tool.
So the morale for me:
with the 12:13 pulldown
+ no need of tampering the subtitle timestamps
+ audio is perfectly preserved
- 12:13 pulled down ntsc film may not output 23.976fps on progressive pb enabled standalone players, but 25 fps guaranteed. Visually it's not that bad as 2:3 pulled down ntsc

bottom line: worth doing this :)

ps: i am so sorry if i've made somebody upset

Xesdeeni

31st March 2005, 22:58

Originally posted by mpucoder
Maybe there's nothing wrong with the flags? Have you tried the cartoon on a software player, or another standalone? I didn't say there was anything wrong with the flags, I said the player can't handle them. The player was listed in a shootout where it had problems with some types of flags. But it doesn't have problems with what we consider "straightforward" flags. I was just asking how to convert these DVDs to this format (since I'll probably want to duplicate the DVDs to save them from my daughters' replay fever anyway :) ).

I don't have another progressive player. I'll try a software player (in our study) or the MyHD card (usually busy recording HD). But the standalone is what we use to view DVDs.

BTW, if I switch the DVD to interlaced output and let the TV deinterlacer, it looks much better (but that's too complicated for my wife, and still can have some BOB sometimes).

Xesdeeni

Guest

31st March 2005, 23:35

Originally posted by Xesdeeni
Or do I need more specific info before you can suggest a course? If so, what tool would give me the flag info?
You can create a D2V using DGIndex on the VOBs. The flags are then available (in display order) as bits 0 and 1 of the frame flags digits:

bit 0 = RFF
bit 1 = TFF

For example, for normal pulldown, you'd see:

... x0 x1 x2 x3 x0 x1 x2 x3 ...

If you'd like to upload a VOB fragment to my server, I'd be happy to have a look at it.

video

1st April 2005, 01:05

oh.. oh.. some little problem. a cheapo pal player when outputs 16:9 to a 4:3 tv, plays my 12:13 pulled down movie with jumps up a down one pel, twice a second. :( kinda field operation interfers with vertical decimation?

Xesdeeni

16th May 2005, 22:28

Sorry it's been so long, but life gets in the way of important things :-)
Originally posted by neuron2
You can create a D2V using DGIndex on the VOBs. The flags are then available (in display order) as bits 0 and 1 of the frame flags digits:

bit 0 = RFF
bit 1 = TFF

For example, for normal pulldown, you'd see:

... x0 x1 x2 x3 x0 x1 x2 x3 ...
What do you make of:...
800 1 0 779386880 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 779849728 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 780193792 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 780587008 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 781015040 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 781447168 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 781858816 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
...?
If you'd like to upload a VOB fragment to my server, I'd be happy to have a look at it. Any suggestions on the best tool to extract the data without modifying it?

Xesdeeni

Guest

16th May 2005, 22:37

Originally posted by Xesdeeni
What do you make of:...
800 1 0 779386880 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 779849728 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 780193792 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 780587008 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 781015040 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 781447168 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
800 1 0 781858816 4 9 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
...?
Any suggestions on the best tool to extract the data without modifying it?
That's all top field first with no pulldown. It may be hard telecined but you can't tell that from this.

I don't know what you mean by your last question. The final digit of the flag bytes is the traditional, 0/1/2/3 described many times here.
If you see 1's or 3's, there is pulldown. 0 means two fields with bottom first; 1 means 3 fields with bottom first and bottom repeated; 2 means two fields with the top field first; 3 means 3 fields with the top field first and top repeated.

mrslacker

16th May 2005, 22:44

While this is on the table, what is the first digit of the flag bytes? I've lost track of the meanings when dgdecode has evolved.

Guest

17th May 2005, 00:51

From the D2V format document contained in the distribution ZIP file :)

The sequence of flags fields contains per-picture data corresponding
to the pictures in *display* order, i.e., the flags fields are re-ordered
into display order. Each per-picture flags field is an 8-bit hex number
bit-mapped as follows:

bit 0: rff flag.
bit 1: tff flag.
bits 3-2: reserved (0).
bits 5-4: picture_coding_type (I = 1, P = 2, B = 3).
bit 6: progressive_frame (0 = interlaced, 1 = progressive).
This specifies that the picture is part of a frame
(either a frame picture making up the entire frame, or a
field picture making up one of the fields of the frame) whose
fields are sampled at one moment. A RFF flag may be present
however, such that the *displayed* frame after pulldown is
interlaced.
bit 7: 1 if the picture is decodable without referring to the
previous GOP, else 0.

End of stream is signaled with a flags field value 0xff, so the field
is written as ff.

EDIT: Corrected the document error which had bits 6 and 7 swapped.

Xesdeeni

17th May 2005, 14:14

Originally posted by neuron2
That's all top field first with no pulldown. It may be hard telecined but you can't tell that from this.So that means it was encoded as progressive frames, but with interlacing? (i.e. there are progressive frames with fields from two different film frames--maybe that's what you mean by "hard telecine"?) If that's right, I can't just modify the flags to eliminate the combing on my cheap DVD player, right? I'd have to re-encode.I don't know what you mean by your last question.You stated:If you'd like to upload a VOB fragment to my server, I'd be happy to have a look at it.But any tool I would use to do this would modify the VOB to another format, like MPEG. What tool do you recommend to extract a bit of the VOB but leave it in VOB (TS?) format?

Xesdeeni

Guest

17th May 2005, 14:38

Originally posted by Xesdeeni
But any tool I would use to do this would modify the VOB to another format, like MPEG. What tool do you recommend to extract a bit of the VOB but leave it in VOB (TS?) format?
Use a VOB cutter, e.g., VOBSplit. I'll answer your other questions after seeing the VOB fragment.

manono

17th May 2005, 14:59

Hi Xesdeeni-

I can't speak for neuron2, and he's more than welcome to correct and/or amend what I'm about to say.

So that means it was encoded as progressive frames, but with interlacing?

It was encoded as interlaced. Now, it may be truly interlaced (all frames from 2 different points in time), or it may have been telecined prior to encoding (hard telecine). When trying to tell which you have, make a non-ForceFILM .d2v with DGIndex and open it in something where you can advance a frame at a time-I use GKnot. If interlaced, every frame is interlaced, and if hard telecined, you'll see the evidence of the telecine-3 clean progressive frames followed by 2 interlaced frames. That kind is stored that way on the DVD, at 29.97fps, as opposed to progressively encoded FILM, where 23.976fps is stored on the DVD, with the flags set to output 29.97fps.

If that's right, I can't just modify the flags to eliminate the combing on my cheap DVD player, right? I'd have to re-encode.

That's correct. If hard telecined, you can reencode with an IVTC in the .avs to get back the original 23.976fps, and then run Pulldown afterwards to have your player output 29.97fps. Do you really see combing when you play that kind? This is on a computer or HDTV? Those things are supposed to at least deinterlace it. No software players and relatively few hardware DVD players can perform an on-the-fly IVTC to output clean frames, and about all they'll do is to deinterlace it. That's one reason why hard telecine is such nasty stuff; that and the fact that precious bits are being wasted on encoding 29.97fps, where 23.976fps could have been encoded. It doesn't make much difference when played back over a standard interlaced TV set, though.

What tool do you recommend to extract a bit of the VOB but leave it in VOB (TS?) format?

I don't know what a VOB (TS) is, but the Doom9 Download section has a couple of Vob cutters. You might try Chopper XP. Others include MPEG2Cut and VobSplit.

Edit: I see that while I was typing, neuron2 answered. Since I spent all this time typing it up, then you have to read it. :)

Xesdeeni

17th May 2005, 16:52

Originally posted by manono
So that means it was encoded as progressive frames, but with interlacing?

It was encoded as interlaced.What specific part of the D2V are you looking at. Isn't each line a GOP? And in that excerpt, aren't there 12 frames per GOP, as indicated by the last 12 columns? If so, it looks like the first 2 frames are interlaced, but the other 10 are interlaced, based on the bit descriptions above.Now, it may be truly interlaced (all frames from 2 different points in time), or it may have been telecined prior to encoding (hard telecine). When trying to tell which you have, make a non-ForceFILM .d2v with DGIndex and open it in something where you can advance a frame at a time-I use GKnot. If interlaced, every frame is interlaced, and if hard telecined, you'll see the evidence of the telecine-3 clean progressive frames followed by 2 interlaced frames. That kind is stored that way on the DVD, at 29.97fps, as opposed to progressively encoded FILM, where 23.976fps is stored on the DVD, with the flags set to output 29.97fps.I've used an AVISynth script with DGMPGDec.dll and VirtualDub. But if the flags were set as expected on a progressive stream, wouldn't you see the exact same thing? I thought when you view the output, you can't be sure whether a frame was encoded progressive or interlace or whether the flags are doing the work.If that's right, I can't just modify the flags to eliminate the combing on my cheap DVD player, right? I'd have to re-encode.

That's correct. If hard telecined, you can reencode with an IVTC in the .avs to get back the original 23.976fps, and then run Pulldown afterwards to have your player output 29.97fps. Do you really see combing when you play that kind? This is on a computer or HDTV?This is on a cheap progressive DVD player on an HDTV. If I set the DVD for progressive, I get combing. If it set it for interlaced output, the TV deinterlaces fine. But I like to leave the DVD player in progressive mode, since it works well for most movies. Changing to interlaced is too much for my wife and kids. Of course, they don't really notice the combing, but it bugs me :-)

Xesdeeni

Guest

17th May 2005, 17:31

Sorry, there is a bug in the document (but not in the code). Bits 6 and 7 are swapped.

Guest

17th May 2005, 17:38

Originally posted by Xesdeeni
I've used an AVISynth script with DGMPGDec.dll and VirtualDub. But if the flags were set as expected on a progressive stream, wouldn't you see the exact same thing? I thought when you view the output, you can't be sure whether a frame was encoded progressive or interlace or whether the flags are doing the work. If you have no RFF flags in the D2V and you see this pattern, then it is hard telecined. If you see RFF flags and this pattern then it is pulldown telecined. In the latter case, if you use field operation RAW, you will not see any combed frames.

manono

17th May 2005, 18:39

Hi-

What specific part of the D2V are you looking at?

All the 2's in the .d2v. If it had been encoded as Progressive, it would have gone 0 1 2 3 0 1 2 3. Run the Vobs through DGIndex and you'll see that it's NTSC/Interlaced. Theoretically it could be Progressive, I guess, and still be all 2's in the .d2v, if it was 30fps Progressive, but such NTSC DVDs are so rare as to not be worth mentioning. I don't know that I've ever seen one, although I think I remember making a DVD extra that way recently. PAL is a different story. Most of them are encoded as Interlaced even though the content is usually Progressive.

But if the flags were set as expected on a progressive stream, wouldn't you see the exact same thing?

Yes, but I was explaining how to tell the difference between Interlaced and hard telecined content. If it was a Progressive stream, you'd also have the RFF flags (0 1 2 3), and most likely you could ForceFILM it, something you can't do with what you have. If it's a movie, then most likely it can be IVTC'd, though.

If I set the DVD for progressive, I get combing.

That sounds pretty bizarre to me that all it can do is a simple Weave. That makes it less than useless for Interlaced/hard telecined content, where all you can do is to pass off the deinterlacing to the TV set. Are you sure there aren't any other deinterlacing settings to at least do a Bob or a vertical filter/blend so you don't get combing?

By the way, I'm assuming that this is an NTSC DVD. Looking back on your posts I see mention of 24fps, but nothing specifically stating it's an NTSC DVD.

SeeMoreDigital

17th May 2005, 18:59

Originally posted by Xesdeeni
This is on a cheap progressive DVD player on an HDTV. If I set the DVD for progressive, I get combing. If it set it for interlaced output, the TV deinterlaces fine. But I like to leave the DVD player in progressive mode, since it works well for most movies. Changing to interlaced is too much for my wife and kids. Of course, they don't really notice the combing, but it bugs me :-)Do you think this "combing" effect is more prevalent with NTSC DVD content?

I have PAL and NTSC DVD versions of the same movie and have often noticed that PAL progressive playback seems to look smoother than NTSC progressive... but I put this down to my equipment running at 50Hz and not 60Hz... Should this matter?

Cheers

mrslacker

17th May 2005, 21:13

Originally posted by Xesdeeni
What tool do you recommend to extract a bit of the VOB but leave it in VOB (TS?) format?

AFAIK DVD uses program stream.

Originally posted by neuron2 Sorry, there is a bug in the document (but not in the code). Bits 6 and 7 are swapped.
OK, so all frames are labeled progressive in that D2V. In what way? In that the mpeg progressive_frame flag is set in the picture header? Or that the picture_structure in the picture_coding_extension indicates a frame picture instead of a field picture pair?

This sort of addresses what manomo said about most PAL being progressive but encoded as interlaced. @manomo Are you saying that they are encoded as field pictures, not frame pictures?!? Or are you just saying the picture header is set to indicate interlaced frames? I would hope the encoder is not operating under the assuption that its input is not progressive, in the strict temporal definition. After all, this is why actual interlaced material is "harder" to encode. Bottom line, are you talking about a difference in the encoding algorithm, or just a stream discrepancy? Just curious.

But, as neuron2 mentioned, playing back a d2v with field operation set to RAW FRAMES would at least tell you if the original content is progressive, interlaced, hard telecined, or just messed up.

p.s. I hope this post doesn't look weird. I'm using lynx on the command line b/c of network problems.

manono

18th May 2005, 08:28

Hi mrslacker-

I'm sorry, but I didn't fully understand your questions. Maybe some data from BitRate Viewer will help (and maybe not).

Here's one from an NTSC R1 DVD movie encoded as Progressive which showed as 100% FILM in the DGIndex produced .d2v:

Pic. structure: Frame
Field topfirst: Yes
DCT type: Frame
Quantscale: Nonlinear
Scan type: ZigZag
Frame type: Progressive

Here's one from a "Making Of" docu on the same DVD (Hitchcock's "Dial M For Murder") encoded as Interlaced. The .d2v is 0.00% FILM, and all full of 2's It's a mix of 30fps interlaced talking heads and photos being zoomed in and out, and hard telecined film clips:

Pic. structure: Frame
Field topfirst: Yes
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced

And finally, here's one from a PAL DVD (the R2 PAL version of "Closer") which was encoded as Interlaced but had all Progressive content. The .d2v is also 0.00% FILM and also all full of 2's:

Pic. structure: Frame
Field topfirst: Yes
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced

Guest

18th May 2005, 13:09

Originally posted by mrslacker
OK, so all frames are labeled progressive in that D2V. In what way? In that the mpeg progressive_frame flag is set in the picture header? Or that the picture_structure in the picture_coding_extension indicates a frame picture instead of a field picture pair? No, they are flagged as interlaced (bit 6 is progressive_frame and 0=interlaced). The progressive_frame flag in the picture coding extension is referred to. It's semantics are as described in the document.

mrslacker

18th May 2005, 16:36

@neuron2
We're on the same page now. So, there's really no garauntee that a picture flagged as either progressive or interlaced is actually encoded that way, forgetting about the true nature of content entirely. For example, you could have originally progressive material, encoded as interlaced material, and later flaged as progessive. It would look progressive when viewed and when glancing at the flags, but it was encoded wrong. Does that make sense?

There are 10 types of people who understand binary, those who do and those who don't. And I started counting bits at 1 instead of 0... Oh the shame! Thanks.

mpucoder

18th May 2005, 16:45

While you cannot reliably determine the nature of the source from the flags, especially PAL, the flags DO tell you how each picture is encoded. That is their purpose. Progressive frame pictures are decoded differently than non-progressive (and fiddling with the flag will produce strange results). Also only progressive frame pictures can be pulled down using rff. However, and you will love this, within a progressive frame picture each macroblock can be either progressive or interlaced.

mrslacker

18th May 2005, 17:22

Yes! That's exactly what I'm talking about. The DCT type the material was encoded with. The spec says that progressive_frame implies a given dct_type, if I'm reading it correctly.

I bring this up because I hear reports of material encoded as this or that, but are they talking about reckless and improper changing of the flags, or are they talking about the way the encoder treated the material in creating the DCT's macroblocks.

Like you said, mpucoder, the consequences would be quite deleterious. Given the widespread use of pulldown.exe -nopulldown (or maybe ReStream) with -prog_frames [p|i] set on a whim... Well it's nerve racking.

EDIT: I just wish there were a better way to determine Frame or Field DCT Coding. Is there no immutable indicator of frame or field macroblocks? Building a histogram of the macroblock types in a frame would be the idea way to determine and report the intended frame type... at least for the sake of the decoder to function properly.

mpucoder

18th May 2005, 19:13

You don't need a histogram for the decoder to operate properly, just the information as presented. That's the nature of streaming protocols.
There is a lot of interaction with picture structure, progressive frame, frame_pred_frame_dct, and dct_type. Also pulldown is affected by progressive sequence as well as the tff and rff flags. And alternate_scan can be more efficient at times for interlaced material. But why worry about it? All that is needed for pulldown is non-progressive sequence with progressive frame pictures. Anything else will not work properly. And trying to change flags without re-encoding just to make it work will fail as well. The choice of DCT and scan pattern are just tools for the encoder to get the best quality for the least bits, and not indicators of the source material type.

mrslacker

18th May 2005, 19:45

Originally posted by mpucoder
You don't need a histogram for the decoder to operate properly, just the information as presented.
Then just for informational purposes. But, If all macroblocks are field-coded, they you know the picture was encoded as part of an interlaced sequence, not just labeled incorrectly. What if you don't trust the information (flags) you are given? Does the decoder still function optimally, determining the nature of each macroblock? Maybe these questions are silly. I don't know enough to say.

All that is needed for pulldown is non-progressive sequence with progressive frame pictures. Anything else will not work properly. And trying to change flags without re-encoding just to make it work will fail as well.
I'm getting completely off topic, as I'm not thinking about pulldown, just frame type flagging. I just want to know what it means when people say that PAL is usually progressive, but encoded as interlaced.

The choice of DCT and scan pattern are just tools for the encoder to get the best quality for the least bits, and not indicators of the source material type.
Why else would an encoder split every 16x16 macroblock into 16x8 fields by taking alternating lines of pixels, unless the operator of the encoder explicitly specified interlaced encoding mode. This seems to be a pretty solid indicator of a stream that should be reported as interlaced.... For all practical purposes, it needs to be flagged that way (correctly), as you said in your last post. But if all you can do is trust the flags, I'm thinking in circles.

mrslacker

18th May 2005, 19:54

Originally posted by mpucoder
However, and you will love this, within a progressive frame picture each macroblock can be either progressive or interlaced.
OK, I see. The decision to use frame or field DCT coding is made on a macroblock-by-macroblock basis. Funky! But if they are all frame or field...

Maybe I should stop asking and start reading. Thanks for all the tips, manomo, neuron2, and mpucoder. :)

scharfis_brain

30th May 2005, 20:50

I ran in several problems recently, related to dgpulldowned files.
I am doing a 23.976 fps to 50i pulldown to avoid Audio conversion.

If I want to create a SVCD:
- muxing with TMPGenc results in non-seekable videos
- muxing with bbmpeg results in a seekable mpeg with destroyed pulldown (runs at 20 fps / 25fps with 3:2 pulldown)

If I want to create a DVD:
- muxing with IfoEdit returns a non seekable DVD (with software players)
- muxman rejects the m2v. (says GOP too long)
- authoring with DVDlab was sucessfully

Also I noticed that my 23.976p - 50i pulldowned DVDs don't run smoothly on the PC.
there is a stop every second, like every 24th frame gets duplicated.
But the progressive video itself is true 23.976 fps. so why does it jerk like that?

Using lates DGPulldown and MediaPlayerClassic.

nnigam

1st June 2005, 14:10

I do not know about svcd, but for dvd the spec is 29.97fps for NTSC and 25fps for PAL, so 50fps encoding is most likely the problem. The authoring program should have given an error..

For my stuff, I just separate out the audio/video. Change the fps of the video to whatever I need using dgpulldown, and then mux with my authoring program. No problem at all, and audio is in perfect synch. Most of my stuff is 60p fps that coumes out as 23.976 so I just convert this to 29.97 for dvd.

scharfis_brain

1st June 2005, 14:56

I do not know about svcd, but for dvd the spec is 29.97fps for NTSC and 25fps for PAL, so 50fps encoding is most likely the problem. The authoring program should have given an error..
I am not encoding 50fps.
50i == 25i

Guest

1st June 2005, 16:35

The GOP length issue is known. There are a couple threads about it.

Regarding jerkiness, the pulldown should repeat a field about once per half-second. It shouldn't be noticeable. Can you make available an encoded clip that shows this, so I can check that the pulldown is applied correctly?

scharfis_brain

1st June 2005, 17:09

Regarding jerkiness, the pulldown should repeat a field about once per half-second. It shouldn't be noticeable.

Judging from my encoded DVD, the pulldown is applied correctly
(two minor stops per second, only visible in panning scenes)

Only the progressive playback with the PC shows on big stop per second, where it should be two minor ones per second, or even better: NONE!

Can you make available an encoded clip that shows this, so I can check that the pulldown is applied correctly?

Which format do you like to see?
m2v or VOB?

Guest

1st June 2005, 18:31

Judging from my encoded DVD, the pulldown is applied correctly
(two minor stops per second, only visible in panning scenes)

Only the progressive playback with the PC shows on big stop per second, where it should be two minor ones per second, or even better: NONE!

Which format do you like to see?
m2v or VOB? Your choice.

TimIacobucci

6th June 2005, 23:23

I have encoded a divx avi via avisynth with cce. This avi was 25 fps. I then used dgpulldown to flag it to 29.97 for authoring in dvd maestro. I have done this maybe 30 times before successfully without any problems.

But with this project when I bring the flagged video into maestro the time length of the video is stretched approximately proportional to the change in frame rate from 1 hour 54 minutes to 2 hours 17 minutes. The length is also incorrect in media player classic as well but shows up fine in vdubmod. I have rencoded and redone the pulldown twice to be sure it wasn't some strange glitch.

I can’t make much sense of why this isn't working and any suggestions would be appreciated.

Also many thanks for the great program, until this it has always worked flawlessly.

Guest

7th June 2005, 03:05

Can you make a shorter version that shows the problem and then upload it to my server?

Guest

19th June 2005, 14:19

I see a few files on my FTP, but I forgot to tell you to inform me here of the filename if you upload a stream. So, if you have uploaded a stream, please tell me the file name. Thank you.

Rosco42

20th June 2005, 20:48

I've got a very weird problem with DGPulldown... well, not with DGPulldown itself I think but it's in the loop..

did a bunch of re-encodes using the method (720x480, 25fps, progressive) and then ran DGPulldown on them, all nicely appearing to be 29.97 to the outside world (TMPGenc Author, Womble Video Wizard (not editing, checking the frame rate), etc.. etc..)

Then I was trying out a new authoring program (DVD Composer www.codejam.com) and it only sees the video as 23.97 FPS, naturally the audio track drifts way out of sync..)

Here's the problem.... I fed it some OTHER "real" 3:2 pulldown streams (the 'normal way' of 23.97 > 29.97) and it sees that as 29.97 just fine... only chokes on the 25 > 29.97 stream....

any thoughts on how to 'enlighten' the the program that it's misreading the stream? I've been in contact with the author and they are looking at it (and pointed them to the dgpulldown link on www.videohelp.com) but nothing like checking in at the source...

flumpdumpy

29th June 2005, 15:46

I've been toying around with backing up some HD content that I have captured. and I noticed something interesting about 720p streams. Most of this is common knowledge so please forgive me for going over rudimentary stuff here, I'll get the point as quickly as possible.
The majority of HD programming other than sports, is filmed on movie-type cameras that record at 24fps. When a show is then broadcast in 1080i it uses the same pulldown method that DVD's use to change to 29.97fps. When a show is broadcast in 720p, it uses a similar method to get to 59.94fps. The difference though, is that with a progressive input and progressive output, whole frames are repeated, not fields.
Getting 720p show back down to it's original 23.976fps is no problem. But since I am going to have to re-encode anyway, I'd like to make the video stream as compliant as possible so I won't have to re-encode again when recordable HD-DVD's or Blu-Ray come out.
I originally thought, "Hey, no problem, I'll use the custom setting in DGpulldown and set it to 23.976->59.94". But then I got to thinking, is this really going to give me what I need. So here is the question:
If I use the custom setting to go from 23.976 to 59.94, will it achieve this by repeating whole-frames or fields. Because if it uses fields, that will likely thrash the video output.

Guest

30th June 2005, 02:17

It can only repeat fields. You can't do that conversion with DGPulldown.

Xesdeeni

8th July 2005, 14:41

Just a word of thanks for the utility. I've used it a few times, but it really shines in my latest project.

I have some PAL DiVX files I'm converting to DVD. They are a series of 13 45-minute shows at 640x360 16:9 resolution. Two shows per DVD*R would mean 6 Mbps for the video, which would be pretty good quality. But I really didn't want 7 DVDs. Four shows per DVD*R would mean 3 Mbps for the video. My experience is that MPEG-2 doesn't do so good with 3 Mbps, but that was doing mostly noisy, interlaced sources. So I thought I'd just give it a try with progressive frames and DGPulldown. I used a very good MPEG encoder and multi-pass, and the results are FANTASTIC! Even on my 65" screen, there really isn't much degradation from the already reduced DiVX quality. I attribute this to being able to encode progressive frames and avoiding the 17% extra overhead of field repetition.

So thanks for taking my idea and running with it. It works great!

Two and a half suggestions though:

1. I'm guessing it would be faster to convert if the source and destination could be on different drives. But you can't choose the destination.

1.5. It looks like the files are exactly the same size before and after. Is it possible to modify them in place without copying them?

2. A batch or CLI method would be nice, since I have to convert multiple files after encoding.

Xesdeeni

Prodater64

26th July 2005, 01:59

@neuron2: Despite you mentioned command line reference is in the text file, I can' find out that reference. Could you post it here, please?

Prodater64

29th July 2005, 22:16

2. A batch or CLI method would be nice, since I have to convert multiple files after encoding.
Xesdeeni

I think there is a cli option (I find out one reference deep in this thread). So I asked neuron2 in my previous post, but still have not answer.
Lets wait until neuron2 read these posts.

Guest

29th July 2005, 22:47

DGPulldown started out in life as a command line tool but it evolved into a GUI and command line support was lost. I'll keep that and the other suggestions in mind for a rainy day.

Prodater64

30th July 2005, 00:10

DGPulldown started out in life as a command line tool but it evolved into a GUI and command line support was lost. I'll keep that and the other suggestions in mind for a rainy day.

Is there a working old cli version?
Several encoding tools as DVD2SVCD or DIKO, and another ones not so knew, need a cli version for make life easy to users (included me :D ).
If there is any version, please post its link (I saw in all yours dgpulldown version txt files, but there is not any cli reference)

Other question: A time ago, doing some test I flaged a 25 fps stream as 29.97 (or vice versa, I don't remember now). Played in my SAP it showed ok. I think I only flaged fps and not resolution, but don't remember that also.
I did use DVDPatcher.
The question is:
Is flaging with DVDPatcher a similar method than DGPulldown?

And last one: We can use classic pulldown.exe to do same as DGPulldown, related to system change? If not, explain this point please.

Edited: Nevermind last question. I have read the answer in a previous post.

Guest

30th July 2005, 00:55

Is there a working old cli version? There's no CLI version with full features. You're going to have to be patient.

I did use DVDPatcher. The question is: Is flagging with DVDPatcher a similar method than DGPulldown? I'm not familiar with DVDPatcher but I would guess not, otherwise someone would have mentioned it a long time ago.

And last one: We can use classic pulldown.exe to do same as DGPulldown, related to system change? If not, explain this point please. pulldown.exe can do standard 3:2 pulldown (23.976 -> 29.97) only.

Don

MegadetH

31st July 2005, 18:25

I use a program called DIVX to DVD Converter,and i have some divx videos that are Pal format i just drop them into this program select force NTSC, and it coverts every time successfully, and you can allso drop VOB files in it but I havent tried this yet but i have droped a VOB file to it just to see if it would read it i will try and convert PAL to NTSC here shortly, but it will convert a PAL Divx vid. to NTSC DVD so i would convert the PAL DVD to DIvx then back to NTSC DVD.

:helpful:

Guest

31st July 2005, 18:42

I use a program called DIVX to DVD Converter,and i have some divx videos that are Pal format i just drop them into this program select force NTSC, and it coverts every time successfully Yes, but the question is whether it does this by using flagging or by duplicating frames. If you could supply a short VOB fragment from the output of this program, I could determine the answer to that question.

MegadetH

31st July 2005, 19:47

Ok how do I supply you with a fragment?

DaveTv

31st July 2005, 19:53

I really like this program.........the results of my conversions are fantastic.

If you don't mind a suggestion or two...

1.) Allow file to be dragged onto the gui, for loading.

2.) Allow a different destination.

Thanks.

Guest

1st August 2005, 03:42

Ok how do I supply you with a fragment? You chop the front of the VOB using ChopperXP and then you upload it to my FTP site and tell me the filename. 50-100 MBytes will be enough.

Prodater64

2nd August 2005, 07:47

DGPD_PAL2NTSC by Prodater64

At the moment, and don't know for how many time, Donald Graft won't give CLI support to DGPulldown.
As 25 to 29.97 pulldown is very interesting and it would solve many problems with sync issues, I wrote a little app that gives CLI (or parsing parameter) support to DGPulldown. It means if you parse 25fps video stream name as parameter, DGPulldown will do its job and you will obtain a 29.97 flagged video stream. You can use it with original audio without change it.
You need DGPulldown.exe and DGPD.exe the litte app I wrote. There is also a DGPD.bat file that only is an example of how to call DGPD.exe.
All files should be in same folder.

Edited:

Udated.
See http://forum.doom9.org/showthread.php?t=98209

zoinbergs

21st September 2006, 19:53

First of all.. I'd like to say THANK YOU for the development of this program... it sure is fun to use!

I do have one question though.........

Is there any way to use this irregular flagging technology with an actual MPEG2 Encoder to physically insert the additional interlaced frames?

I'm not so much concerned about the increased file sizes I would be creating, as I am with utmost compatibility with stand-alone players / TVs. If the frames were physically there, instead of just the flags to create the frames, then 100% compatibility would ensue, and no DVD players playing my content would have to pull down anything.

I believe TMPGEnc duplicates every fifth frame to achieve 25 --> 29.97 fps, but I'm looking for a smoother transcoding procedure that something like DGPulldown's flags are creating. (But not physically creating -- which is what I want to do).

Pure and authentic 29.97 fps video, with no flags whatsoever in it, would certainly help in my search for ultimate DVD compatibility.

Any help on this subject is quite appreciated!!!!!!!!

Thank You,
William

PS- Another quick question.. where the heck does 25fps (truly) interlaced video come from? I mean, 29.97fps interlaced video usually comes from FILM that is 3:2 from 23.976fps.. but I always thought 25fps was PAL's progressive -- kinda like the US with it's 23.976 NTSC progressive. I don't believe I've ever seen 23.976fps interlaced (unless of course each frame is split into two identical fields). Could this 25fps interlaced be a pulldown from 23.976 to allow the playing of FILM on a PAL disc?

Thank you so much for any insight you may be able to provide!!!!!!!!

Wilbert

21st September 2006, 21:20

PS- Another quick question.. where the heck does 25fps (truly) interlaced video come from?
Sports for example. Yes, movies are usually progressive.

SeeMoreDigital

21st September 2006, 21:57

PS- Another quick question.. where the heck does 25fps (truly) interlaced video come from? Count yourself lucky you don't live in the UK then.... As all std-def DVB TV is broadcast as "interlaced" :scared:

Guest

21st September 2006, 22:35

Is there any way to use this irregular flagging technology with an actual MPEG2 Encoder to physically insert the additional interlaced frames? If the video is already in MPEG2 then you can flag the M2V elementary stream as required using DGPulldown. Then load the M2V into DGIndex and make a project with Honor Pulldown Flags. Then serve the video into your encoder and encode in interlaced mode. For non-MPEG2, you can use this method:

bob
changefps(59.94) # for 25fps -> 29.97fps
separatefields
selectevery(4,0,3)
weave

I'm not so much concerned about the increased file sizes I would be creating, as I am with utmost compatibility with stand-alone players / TVs. If the frames were physically there, instead of just the flags to create the frames, then 100% compatibility would ensue, and no DVD players playing my content would have to pull down anything. This concern of yours is overblown, IMHO. I am not aware of any player that doesn't properly honor DGPulldown'ed streams. It is perfectly ordinary and legal MPEG2 syntax.

PS- Another quick question.. where the heck does 25fps (truly) interlaced video come from? From 50 fields/sec video cameras used in PAL countries.

I mean, 29.97fps interlaced video usually comes from FILM that is 3:2 from 23.976fps.. No, that is not interlaced content; it is telecined content.

You need to distinguish the nature of the content from the final analog signal that goes to an interlaced display. At the display everything is "interlaced"; but the content may not be.

zoinbergs

22nd September 2006, 02:32

Thank you, thank you, thank you neuron2!

Your wisdom is very much appreciated!

I was quite skeptical about keeping the flags, but I'll trust your word that it is indeed legal MPEG2 syntax. Believe me, I did NOT want to re-encode all this PAL material I have!

And yes, you're correct.. there is a big difference between telecined and interlaced content. I guess I have to wonder now instead... is true 29.97fps interlaced content twice as smooth as 29.97fps progressive? Because in essence there'd be twice the movement (like in a pan for instance).. moving from one field to the next? Would there be 59.94 individual (non-identical) fields, or is the bottom field for one frame the same (camera shot) as the top field for the next frame?

Sorry if that sounds confusing.. I just have some interlaced content here that doesn't look like it came from a progressive source (so it's not telecined).. but rather from some other source... I presume from an interlaced video camera. Every single frame shows one (top) field from the previous frame, and one (bottom) field from the next one. Does that make any sense?

Oh wait a second! I think I got it.. if both fields for each frame were from the same camera shot, then it'd be progressive, right? Even if it's encoded as interlaced it'd still show no horizontal lines that (true) interlaced content shows. So what I have is simply put, interlaced content! Still 29.97 frames.. but divided into fields that are split between those frames. Right?

I've read over and over again what interlaced content is.. but my mind just can't wrap itself around it (yet).

Hopefully I just answered my own question here though!

- - - - - - - - - - - - - - - - - - -

I hate to ask now.. (because I don't want to feel like I'm milking you guys for answers).. but I have just one more question.

I have a progressive NTSC video stream at 29.97fps that has clearly been converted by someone else from a PAL source at 25fps. I know this because every fifth frame has been phyiscally duplicated.

So is there any way to undo this conversion so I can add DGPulldown's flags to it.. so I can make a smoother video in the end?

I hope there's an easy answer to this one.. but if there isn't.. don't bother spending too much time on it! It's only a question..

I tried using TMPGEnc to do the trick, and ended up with 3 unique frames and a duplicated one! Every fourth frame was deleted.. when the fifth frame was supposed to. Boy does it look funny though!

- - - - - - - - - - - - - - - - - - -

Thank you so very much guys for all your support! Hopefully I can be as knowledgable on this stuff as you are.. so I may someday be the one to answer people's questions.. thus giving you a break from doing it. =)

"You can give a man a fish, and feed him for a day. Or you can teach a man to fish, and watch him drink beer in a boat all day."

Guest

22nd September 2006, 02:49

I guess I have to wonder now instead... is true 29.97fps interlaced content twice as smooth as 29.97fps progressive? Temporally, yes.

Would there be 59.94 individual (non-identical) fields Yes. Each field is sampled at a different temporal moment. The moments are defined by the field frequency.

Sorry if that sounds confusing.. I just have some interlaced content here that doesn't look like it came from a progressive source (so it's not telecined).. but rather from some other source... I presume from an interlaced video camera. Every single frame shows one (top) field from the previous frame, and one (bottom) field from the next one. Does that make any sense? Once you know a simple notation, it's easy to describe these things. I use a letter to indicate a temporal moment, so a and b are two different moments. Also, use [] to denote frame boundaries. The first letter in [] is the top field and the second is bottom. Then, this is interlaced:

[ab][cd][ef]...

This is progressive:

[aa][bb][cc][dd]...

This is progressive with a one-field phase shift:

[.a][ab][bc][cd]...

This is 3:2 telecine:

[aa][ab][bc][cc][dd]...

You can also have blended fields:

[a a+b][b+c c] (and many variants thereof)

Oh wait a second! I think I got it.. if both fields for each frame were from the same camera shot, then it'd be progressive, right? Yes, but it could be shifted (see above).

What pattern are you seeing in the above notation? Look at a scene with constant motion.

I have a progressive NTSC video stream at 29.97fps that has clearly been converted by someone else from a PAL source at 25fps. I know this because every fifth frame has been phyiscally duplicated.

So is there any way to undo this conversion so I can add DGPulldown's flags to it.. so I can make a smoother video in the end? Sure. Do this:

Telecide() # You can omit this if there are no field shifts
FDecimate(25)

Now you encode progressive MPEG2 at 25fps and then apply DGPulldown. The result will not actually be smoother because you haven't added any new temporal information, but it will have less "judder" and that is perceived as smoother.

zoinbergs

22nd September 2006, 06:47

Ooh, that's some juicy information man! Thank you!

I believe I was viewing some progressive shifted video running at [.a][ab][bc][cd]...

I believe Telecide() would shift it back, correct? Or would there need to be a parameter to insert in those there parenthesis?

I think I'm gettin the hang of this stuff! Who knew video could be so difficult to work with though...

zoinbergs

22nd September 2006, 12:06

Well neuron.. I believe I'm gonna stick with DGPulldown flags to go from PAL to NTSC!

I tried doing the conversion the long way like you had talked about.. and boy was it funny looking! I don't know what happened exactly.. but a lot of my frames turned out to be blended ones (from the de-interlace before resize to 720x480 I presume).. that were then interlaced again (because I chose to encode that way!)

WHAT A MESS I told myself, and decided to scratch the whole idea. I like flags very much so now. ;)

Guest

22nd September 2006, 13:18

I believe Telecide() would shift it back, correct? Or would there need to be a parameter to insert in those there parenthesis? Correct. Please refer to the documentation for parameter descriptions. Often the defaults you get if you don't specify anything are fine.

I tried doing the conversion the long way like you had talked about.. and boy was it funny looking! I don't know what happened exactly.. but a lot of my frames turned out to be blended ones (from the de-interlace before resize to 720x480 I presume).. that were then interlaced again (because I chose to encode that way!) Of course, if you have interlaced video and you don't mind deinterlacing it, then sure, just apply DGPulldown. But if you want to change the rate ofinterlaced material while keeping it interlaced (full temporal content), then the long method can be used. You got blends because you used blend mode when you deinterlaced. But DO NOT deinterlace progressive content; use a field matcher like Telecide() to realign the progressive frames, then apply DGPulldown.

zoinbergs

29th September 2006, 13:31

Well neuron2, I've definitely mastered the art of DGPulldown! No more blended fields either, thanks to the wonderful Telecide paramater finally being used correctly! (The lack thereof was indeed my problem).

Here's something for you to ponder though! You'd better sit down for this one.........

Okay, so I'll try and keep this short! But please forgive me if I write too much..

So after running DGPulldown (25 --> 29.97) on a 720x480 25fps Progressive video, I got what I had expected, an NTSC DVD-compliant MPEG2. The newly flagged video passed right through my TMPGEnc DVD Author v1.6.34.89 just fine, also what I had expected.

But when I ran it through my TMPGEnc DVD Author v2.1.9.90, it crashed it! I mean, it totally crashed it. I got as far as the where the actual DVD authoring takes place, but after writing the menu, it said it failed to write the VOB.

After that I tried burning a previously known-to-be-good video, and that had crashed it too! So I'm pretty sure the unusual flagging pattern did something to the entire program, disabling burning capabilities altogether.

So, I uninstalled the program, restarted my computer, and then reinstalled the program. STILL NO BURNING CAPABILITIES. DGPulldown's flags I thought had permanently disabled my TMPGEnc DVD Author!

I decided to uninstall v2.1.9.90 again, and go ahead and install my old trusty v2.1.7.88. Low and behold, it burned my known-to-be-good video with no problems! BUT, as soon as I tried the flagged video, it crashed that version too.

So both versions were rendered useless, no matter how many uninstalls and reinstalls I did of each.

So that got me thinking.. maybe TMPGEnc DVD Author doesn't actually "uninstall" its registry entries when you remove the program from your computer. Sure, the registry entries were removed physically (from the Software/Pegasys, Inc./TMPGEnc DVD Author v2.0 folders in various users and the local machine), but everytime I reinstalled each version, I got the same error message when trying to burn perfectly good MPEG2 files (not the flagged ones).

The reason I think this is, is because I finally did a hard uninstall, and deleted the registry entries myself, along with the program folder in C:\Program Files too. Before I was going through Add/Remove Programs in my control panel, but that way wasn't working, so I thought I'd get creative!

So, after the hard uninstall, I reinstalled (from scratch you could say -- registry entries and all) the latest version of 2.1.9.90.... and IT WORKED! My burning capabilies were back, for compliant videos that is, but of course, still not for flagged videos.

What I'm wondering is if TMPGEnc DVD Author v2.0 (both revisions) just move their registry entries somewhere else when "uninstalled." The fact everything worked after I hand-removed the entries just boggles my mind!

Alright, so anyways, the moral of the story is that DGPulldown is NOT compatible with TMPGEnc DVD Author v2.1.9.90 OR v2.1.7.88 in any way, shape or form. But with your suggestion about using Honor Pulldown Flags in DGIndex, I'm definitely still a happy camper when I rencode my videos using the newly hard-telecined material!

I thought you'd might like to know this though, neuron2. Maybe there's something you can do about it? I'm not concerned about the issue though, if that's what you're thinking. I'm VERY satisfied with your wonderful program DGMPGDec! Your work is flat out brilliant, and I commend you for it.

It seems to me like you're ahead of the game, and feeble little programs like TMPGEnc DVD Author just can't keep up with you. ;)

Guest

29th September 2006, 13:48

The pulldown is perfectly legal and normal MPEG2 syntax. If DVD Author can't accept it, then seek support from TMPGEnc. I haven't heard this from anyone else though.

zoinbergs

29th September 2006, 19:41

The pulldown is perfectly legal and normal MPEG2 syntax. If DVD Author can't accept it, then seek support from TMPGEnc. I haven't heard this from anyone else though.

That is precisely what I think too! Perfectly legal MPEG2 syntax.

I wasn't implying that something was wrong with your DGPulldown, was I? Because the program is brilliant. :)

I'll have to indeed haggle some TMPGEnc DVD Author customer support representative to see what he might know on the subject! Chances are he knows little though. Isn't "customer service" an oxy-moron? Just kiddin...

Thanks for all your hard work though, man. In my opinion, you're a total genius, and your work is priceless! I don't know what I'd do without the technological advancements you have made in this community. Please keep up the good work! ;)

Paulcat

3rd October 2006, 20:47

Is there some good reason to upgrade from TMPGEnc DVD Author 1.6.xx to 2.1.xx, support for subtitles perhaps?

I am running 1.6.xx and find it just fine for most applications but I have to turn to Muxman when adding subtitles.

Also, if you use DGPulldown to convert a 23.976 file to a 29.97 file, does TDA still crash? Or is it just the flagging from PAL to NTSC that does it?

Paul

zoinbergs

8th October 2006, 05:40

Is there some good reason to upgrade from TMPGEnc DVD Author 1.6.xx to 2.1.xx, support for subtitles perhaps?

I use v2.1.9.90 for the FANTASTIC menu navigation features. I arrange pretty weird menus for my DVDs, and in v1.6 it doesn't show how each button is accessed (using left-right-up-down buttons).. and too many times have I created orphan buttons that can't be accessed with a remote!

Fortunately v2 has the layer to show arrows (backward and forward) from each button to the next, completely eliminating such a problem. I simply arrange my buttons based on the arrows.

I'm not sure about subtitle support, but I'll look into it for ya!

Also, if you use DGPulldown to convert a 23.976 file to a 29.97 file, does TDA still crash? Or is it just the flagging from PAL to NTSC that does it?

I haven't tried 23.976-->29.97 yet, as I have not been in contact with true film footage for awhile.

Actually, I take that back. I have some film footage that already has the flags in it (from the producers)... does anybody know a quick and easy way to strip these flags off so I can add them via DGPulldown? That'll give me a sample to try with TDA2.1 then.

I hope it's only my system that may have this incompatibility issue, but I doubt it.. I am a freak when it comes to perfectly running PC systems. I very rarely run into any sort of problems.

I've contacted TMPGEnc for any light they may be able to shed on the situation, but I haven't received any e-mail back yet.

foxyshadis

8th October 2006, 06:37

zoinbergs

8th October 2006, 12:52

By setting a custom pulldown of 29.97->23.976, you should be able to strip the flags and keep from introducing more. It probably only works if the underlying content is pure film, and might not work at all. ymmv.

I don't believe this method works.. I tried it. Then again, I'm using DGPulldown. Perhaps the old fashioned regular Pulldown.exe would work?

I wonder if dgindex can do it with ignore pulldown flags or forced film, when extracting m2v while processing.

I just tried these two methods as well. DGIndex only ignores the flags in its newly created *.d2v project. The demuxing just passes the original video through, flags and all.

Hmm... I'm almost positive there's another thread I need to find that explains flag stripping in detail! No sense in getting off topic in here.. we're dealing with PAL-->NTSC conversions, right?

Time for some research. =)

Guest

8th October 2006, 15:59

You don't have to strip the flags first. Just run DGPulldown and it will overwrite the flags with the new ones.

If you do want to remove pulldown with DGPulldown, you set the source rate to the destination rate. E.g., 23.976 -> 23.976. As described in the help file. :)

zoinbergs

8th October 2006, 19:24

You don't have to strip the flags first. Just run DGPulldown and it will overwrite the flags with the new ones.

I had a feeling it would do such wonders..

If you do want to remove pulldown with DGPulldown, you set the source rate to the destination rate. E.g., 23.976 -> 23.976. As described in the help file. :)

Brilliant! I must have overlooked that in the help file. BTW, your explanations of (practically) everything you write about are something of another world.. :) You make is so easy to learn this stuff! I really do appreciate the help you have given the a/v community!

Alright.... time to go test some material....

And I'm back! Looks like DGPulldown's flags using 23.976-->29.97 are working in TDA2.1 -- so I presume at this point that TDA doesn't know what to do with irregular flag patterns aside from 3:2 pulldown.

Oh well I say.. as long as DGIndex keeps honoring the flags, I'm set!

And that concludes our little experiment for today...

zoinbergs

10th October 2006, 12:47

Dear neuron2,

I have working for hours trying to figure out the parameters to use for Telecide().

I know there's a riduculously easy answer to this question too.. of which I'm gonna hit myself upside the head for if you answer it! Hopefully you can give me a quick and dirty rundown? Thanks in advance if you can!

Okay so here's my problem:

I'm trying to phase shift a 25i clip, that has sections in it that were derived from film. It's a promotional video for a movie (that was released in 23.976p), and it was released in PAL @ 25i--phase shifted.

The previous encoder did a very good job to phase shift everything equally.. which means that I want to keep ALL the original frames, and simply match every field with the next one.. no matter what source it was derived from.

While using the default parameters for Telecide() I'm getting some mismatches, mostly in the film footage sections of the clip. Understandable I believe, since there was prolly some 24-->25 pulldown going on in the initial creation of the clip.

So I don't want Telecide to try and guess what progressive frames to restore (because it's trying to create 24fps again).. I just want a good old blind field matching and nothing more. Just every field with the next one.. consistently throughout the enitre clip.

Do you happen to know of the correct parameters I can set to achieve such results? I'm guessing that it's gotta do something with setting the pattern guidence to mode 2, and the gthresh to 0.0? Or have I got it backwards?

Here's what I need in terms of matching:

Original =

[.a][ab][cd][de][ef][fg][gh][hi][....

Strictly & Consistently Shifted (throughout the entire clip):

[aa][bb][cc][dd][ee][ff][gg][hh][ii][....

No pattern to match other than perfectly phase shifted 25i. (I'm trying to get the FILM sections to undergo the same phase shifting, no matter what.)

Now I believe I wouldn't need any post-processing because the FILM footage that was used isn't interlaced. Actually, none of the clip is true interlaced material, I don't think. It's all just been phase shifted from an entirely progressive source. There's no patterns needing to be matched, nothing.

Also, I'm a little confused about [b]dthresh and vthresh. If I am correct, dthresh picks out the interlaced frames of the clip for use in post-processing, and vthresh decides how much of those picked frames to deinterlace after that?

Thank you SO MUCH for any help you may be able to provide me! I'm trying my best to understand your tutorials and guides (which has gotten me incredibly far too by the way..... I think I've just hit a small road block with this clip, that's all.

Hope to hear from you soon!

Sincerely,
William

Guest

10th October 2006, 14:26

If it's a consistent phase shift then there is no reason to match fields.

separatefields()
trim(1,0)
weave()

No field matcher is perfect because they rely on heuristics to compare the fields.

BTW, this query is off-topic here. You should have started a new thread.

zoinbergs

10th October 2006, 14:45

Ahhhhh! I knew it had to be as simple as that!!!! :eek: Thank you SO much for the insight!

BTW, this query is off-topic here. You should have started a new thread.

I guess I forgot to tell you that I'm phase shifting the 25i clip so that I can have a progressive source to conduct a pulldown to 29.97 with.

But a new thread would have had the same effect, huh?

Don't worry... I'm a learning... :)

Piper

11th October 2006, 14:45

Is there an issue with DGPulldown 25 -> 29.97 on HCenc (0.18) encoded mpeg-2 files? The reason I ask is this; I have an NTSC capture of a UK broadcast which I've restored to 25 fps. It's in anamorphic widescreen format (720x480) and I run it through HCEnc with the following switches:

profile: best
dc prec: 10
aspect ratio: 16:9
scene change: checked (all others unchecked, including pulldown, interlaced etc)
GOP length: 18 (also tried 15)

The length of the resulting m2v file is: 43:41:120
After running it through DGPulldown (1.0.9) the length increases to: 45:30:08

At first I thought it might be a GOP issue, so I tried 15 as well with the same results.

I've successfully used this procedure many times with TMPGEnc encoded files without issue. Can anyone speculate on what might be causing this?

Thanks

Mr_Odwin

11th October 2006, 16:27

How are you determining the length of the m2v files?

Piper

11th October 2006, 16:46

Using DVD Architect, however I get the same results (albeit less accurate) if I open them in Zoom Player.

Guest

11th October 2006, 18:18

Try making a project using DGIndex on the pulled down M2V and then do Parse D2V to get the running time (see bottom of log). What is it?

Piper

12th October 2006, 05:07

@neuron2: Thanks for the tip (and the apps). Both the original and pulldown .m2v files are 43 minutes, 41 seconds. Finally some sanity! The issue here is with DVD Architect whereas using the same files with DVD Author worked perfectly.

Thanks!

unixfs

4th December 2006, 12:04

Yesterday I merged in mencoder's mpeg muxer (in svn) neuron2's generalized teleciner code.
Thanks neuron2!
P.S. some comment in the source code (especially in the generate function) wouldn't really hurt ;)

ad25

29th March 2007, 16:06

manolito

29th March 2007, 16:34

Everything about your procedure looks alright to me. (I think you know that you have to demux your video before step 1)

Just a little advertising here: If you happen to use DVD2SVCD, have a look at http://forum.doom9.org/showthread.php?p=971974#post971974
This is an automated procedure to convert PAL to NTSC with the additional bonus that the chapter points you might already have in your PAL video will also be converted.

Cheers
manolito

Xesdeeni

29th March 2007, 21:32

I have an interlaced PAL video that I would like to create an NTSC DVD from. I just want to confirm my understanding from reading through the thread.

1. Use Avisynth to deinterlace and resize to 720x480
2. Encode to a 720x480 25fps progressive MPEG-2 file
3. Use DGPulldown to flag the 25fps file to 29.97fps
4. Author DVD

Is there anything I'm missing? Thanks in advance.If it's truly interlaced (each of the 50 fields contains motion), I wouldn't recommend that process, which is best for progressive frame sources. You would be converting 50 "instants of time" to 25. Instead, I'd recommend that you:
1. Use AVISynth and a plugin (LeakKernelBob, SmoothDeinterlacer, etc.) to deinterlace the video to 50 (progressive) Fps.
2. Scale the video to 720x480.
3. Use ChangeFPS() or ConvertFPS() to convert/change the frame rate to 59.94 (progressive) Fps. Which one you use depends on your personal preference. ConvertFPS() blends frames. ChangeFPS() replicates frames. I prefer ChangeFPS().
4. Divide the frames into fields and throw out every other one (SeparateFields().SelectEvery(4,0,3) or SeparateFields().SelectEvery(4,1,2), depending on your destination field polarity).
5. Encode to a 720x480@29.97 interlaced Fps MPEG-2.
6. Author DVD.

Xesdeeni

ad25

29th March 2007, 22:14

Conclusion:

1. DGPulldown method for Progressive PAL to NTSC.
2. ChangeFPS/ConvertFPS method for Interlaced PAL to Interlaced NTSC.

Thanks for the replies.

Guest

30th March 2007, 02:34

We don't make blanket statements about "best" around here. :)

ad25

30th March 2007, 15:46

Sorry about that. I have reworded my reply.

laserfan

11th April 2008, 21:17

I resurrected this old thread because I think Xesdeeni and DG aka neuron2 have done a wonderful thing creating the DGPulldown tool. Hasn't gotten enough pub IMHO and it surely deserves it (never was a "DGPulldown" thread created per se, was there?). Anyway...

I bought a pricey DVD set from Sweden (PAL) which I did not want to convert to 720x480 because I thought my media players (networked ShowCenters) would play the original ripped 25fps MPEG2. Turns out at least my analog NTSC TV didn't like the original much (jerky, prolly had something to do with 25x2 vs 29.97x2 :p). Anyway, a simple DGPulldown from 25-->29.97 did the trick.

Amazingly, I was able to re-mux (using IfoEdit that didn't care this was non-standard stuff) the original 720x576 and 25fps AC3 audio with a brand-new subtitle track I made for it and it all plays beautifully! Just want to say THANKS you guys especially neuron2 for exe-cuting this! :cool:

Guest

11th April 2008, 21:24

I've never heard of anyone doing that before. Thanks for bringing it to our attention, and thank you for your kind words.

SeeMoreDigital

12th April 2008, 10:23

I actually did some tests a few years ago with (PAL) 720x576 MPEG-2 sources running at (NTSC) 29.970fps and 23.976fps speeds.... And vice-versa.

From what I remember, most, if not all my DVD players managed to puke out an NTSC signal... which was a positive step.

I was however unable to find a DVD authoring tool that would allow me to create "non DVD standard" VOB sets suitable for burning onto DVD.

Cheers

EDIT: Found a thread: http://forum.doom9.org/showthread.php?t=83499

laserfan

12th April 2008, 16:11

From what I remember, most, if not all my DVD players managed to puke out an NTSC signal... I was however unable to find a DVD authoring tool that would allow me to create "non DVD standard" VOB sets...Well, as I said IfoEdit worked for me. I had intended to sacrifice a DVD+R to try my VIDEO_TS with, and based on your post I have a better-than-zero chance of actually seeing it work on any of my NTSC players! I'll try it today!

laserfan

18th April 2008, 04:36

Well, the result plays smoothly on the one Sony (NTSC) DVD player I've tried, but it isn't displaying at the proper AR i.e. it's taller than it should be. It looks like, since the player's been told this is a 720x480 NTSC picture, and it's not, it's 720x576, that it's "too tall" at least on my 4:3 analog TV. Haven't tried it yet on my 16:9, I guess that's next.

But it looks like the DVD has to be either a PAL at 720x576 or an NTSC at 720x480, and since it's now a 29.97 program IfoEdit (authoring proggie) decided "NTSC". I suppose if I change it to PAL then my player will balk.

Will play with this some more...glad at least my media players don't care that it's 720x576 (and display at proper AR).

laserfan

28th April 2008, 15:13

Got 'round to trying my DGPulldown DVD (a 720x576 PAL disc that I didn't re-encode) on my 16x9 setup last night and it worked! The disc plays as if it were NTSC, but it's 576, and the AR is A-OK.

One oddity is that the DVD player's display has an odd staccato cadence about it i.e. is not at all smooth, but the picture (25fps to 29.97fps) is smooth and good.

I have another PAL disc on-the-way and will use this same method to play from my upconverting HD-XA2.

DoctorM

23rd April 2009, 08:17

I've been using the 25 to 29.97 pulldown method for awhile and have been very pleased with the results (better than most commercial conversions if you ask me).

I'm working on a full DVD conversion now and saw a couple of strange things this time.
First, the DVD is 1:54:57 in length. While the untouched audio in the NTSC version syncs throughout, the runtime (checked in a couple different pieces of software) shows 1:54:50.

Which brings me to the second problem. I would disregard the runtime discrepancy since there is no sync issue, but the converted chapters are off. The theoretical calculation for conversion would be: 30/25 * original cell.

And this is true. Examining the time of each chapter on the NTSC conversion done this way matches the PAL original. The times also show correctly when using any software that shows the time points of the chapters (ChapterXtractor, DVDRemake, etc.)

BUT, while the times are right, the actual frames drift progressively until they are 7 seconds off at the end.
I can account for this by changing the cell calculation to: 29.97/25 * original cell. Calculated this way the chapter breaks appear in the correct location, but the actual timestamp is wrong.

Has anyone ever noticed this before? I can't make heads or tails of it.

Guest

23rd April 2009, 14:30

DoctorM

24th April 2009, 00:01

Let's address the running time first. How did you create the M2V stream that you applied pulldown to from the DVD? What are the exact steps that produced it? What is the running time of that M2V before and after applying pulldown?

The source was 25i. Using AVISynth, Yadif(), and some other clean up filters, I converted to 25p.
The video was encoded with CCE 2.70 with the Frame Rate set to 25.

Before pulldown the runtime shows 1:54:57.320 by VDubMod (1:54:56 according to DVD Lab Pro).
After applying 25 to 29,97, the runtime is still 1:54:56 (also by DVD Lab Pro) (VDubMod shows around 1:36:ish.).

Test builds of the DVD with MuxMan and DVD-lab Pro made no difference.
The runtime is 1:54:50 in Media Player Classic and VLC.
IfoEdit shows 1:54:50.13.
PowerDVD does show the correct 1:54:57 time but it could be ignoring the pulldown flags.

I tested on 3 stand alone DVD players.
A very old high end Sony, a few year old mid range Panasonic and a mid range 1 year old Philips.
All 3 agree that the runtime is 1:54:50.

29.97/25 * original cell still gives the correct chapters by frame but at a different time point than the original.

Which all seems to make sense since 1:54:57 / 30 * 29.97 = 1:54:50.

Guest

24th April 2009, 05:02

Looks like pulldown is irrelevant and you should be posting this elsewhere.

DoctorM

24th April 2009, 06:52

Looks like pulldown is irrelevant and you should be posting this elsewhere.

Perhaps that is true, but the issue comes from the 25 to 29.97 pulldown method being used to make an NTSC DVD. I'm sure I can't be the first person to notice this (although I may be the first one to care).

Does DGIndex default to non-drop frame in these cases when it should be drop frame?

Guest

24th April 2009, 14:20

Does DGIndex default to non-drop frame in these cases when it should be drop frame? Why are you talking about DGIndex here?

Try setting the drop frames explicitly by clicking until it is checked but not gray.

I never do any chapter stuff so don't really know what you are talking about. If you can identify a problem with DGPulldown and tell me what needs to be done I will do it, but I have no time to get all wound up in chapters and authoring right now.

DoctorM

24th April 2009, 18:18

Why are you talking about DGIndex here?

Try setting the drop frames explicitly by clicking until it is checked but not gray.

I never do any chapter stuff so don't really know what you are talking about. If you can identify a problem with DGPulldown and tell me what needs to be done I will do it, but I have no time to get all wound up in chapters and authoring right now.

Sorry, I mis-typed. I did mean DGPulldown not DGIndex.
The chapters aside, I just worry when the runtime changes when it isn't suppose to. I'll test with drop frames and see if it corrects that.

Edit: No, it's worse with DF. The audio desyncs and the runtime becomes 1:59:44. I guess the change in runtime is just a quirk associated with doing this. Thanks for the help.

Guest

24th April 2009, 18:32

You said the runtime before and after pulldown was the same. So why would that be a DGPulldown issue?

DoctorM

25th April 2009, 00:42

You are right, I am wrong. I assumed it was dgpulldown's method of setting flags that messed with the runtime and chapters once the disc was authored.
After reencoding the same video to 29.97i I found the same thing: 7 second shorter runtime and the chapters were at a different time point than the PAL version.

It's just a bugaboo in ALL PAL to NTSC conversion methods. I apologize for blaming your great piece of software.

Guest

25th April 2009, 03:47

No problem. It's always worth asking if there's any doubt about it.

mpucoder

27th April 2009, 05:18

Ran into this thread while looking for posts about MuxMan and thought I'd explain.
With NTSC DVDs the actual runtime is longer than the timecodes and all time references because DVDs use non-drop timecode. Said another way, the timecodes are computed as if the video were running at 30fps, when it is actually running slower.
Before pulldown the runtime shows 1:54:57.320 by VDubMod (1:54:56 according to DVD Lab Pro).
After applying 25 to 29,97, the runtime is still 1:54:56 (also by DVD Lab Pro) (VDubMod shows around 1:36:ish.).

Test builds of the DVD with MuxMan and DVD-lab Pro made no difference.
The runtime is 1:54:50 in Media Player Classic and VLC.
IfoEdit shows 1:54:50.13.
PowerDVD does show the correct 1:54:57 time but it could be ignoring the pulldown flags.
Those programs that show 1:54:50 are showing the runtime as reported by the ifo file, those that show the actual runtime either parse the video or recognize that the value in the ifo is non-drop and convert it to the actual runtime.

I tested on 3 stand alone DVD players.
A very old high end Sony, a few year old mid range Panasonic and a mid range 1 year old Philips.
All 3 agree that the runtime is 1:54:50.

29.97/25 * original cell still gives the correct chapters by frame but at a different time point than the original.

Which all seems to make sense since 1:54:57 / 30 * 29.97 = 1:54:50.
Yes, cell times do need to be adjusted to account for the non-drop timecode used.

DoctorM

27th April 2009, 06:17

Thank you for clearing that up.

WorBry

27th January 2011, 18:02

Got 'round to trying my DGPulldown DVD (a 720x576 PAL disc that I didn't re-encode) on my 16x9 setup last night and it worked! The disc plays as if it were NTSC, but it's 576, and the AR is A-OK.

I know this is fairly old post/thread, but could someone explain how this is achieved.

I've applied DGPullDown (25 to 29.970) to an 576/25p (16:9) elementary stream and remuxed the AC3 audio. MediaInfo confirms the resulting mpg stream is now 576/29.970p. As predicted, my DVD authoring app (TMPGenc DVD Author) objects that the resolution is unacceptable.

So, how does one apply the IFOEdit workaround?

Cheers.

laserfan

27th January 2011, 18:14

I've applied DGPullDown (25 to 29.970) to an 576/25p (16:9) elementary stream and remuxed the AC3 audio. MediaInfo confirms the resulting mpg stream is now 576/29.970p. As predicted, my DVD authoring app (TMPGenc DVD Author) objects that the resolution is unacceptable.

So, how does one apply the IFOEdit workaround?
Almost 3 years so I'm not CERTAIN, but... forget TMPGenc; go back to "elementary streams" and just select DVD Author menu item in IfoEdit and add your streams.

WorBry

27th January 2011, 18:26

Yep, that works. Thanks alot. :)

WorBry

27th January 2011, 18:48

Actually, after giving it a go, the original PAL DVD plays more smoothly than the 29.970/576 DVD on both of my NTSC DVD players (Bose 3.2.1 (via HDMI) and LG LDA-830 (via Component)) on my NTSC Panasonic plasma HDTV.

By contrast, a DivX encode (25p, 720x416, HomeTheatre) of the same video plays very jittery on the LG LDA-830.

Cant help but wonder why the PAL DVD plays so much better than the DivX?

Edit: The specs of my Panasonic plasma HDTV (TC-P42U1) state that it is a strictly NTSC system i.e. will only accept NTSC signal frequencies/resolutions. So evidently both of my DVD players (also purchased here in Canada) are effectivey multi-system (and rendered region free) - capable of reading PAL and outputting NTSC. I'm trying to understand this more completely. Does anyone know how such DVD players normally carry out the conversion? I know there must be vertical line conversion. Thinking more about the frame rate conversion. Doesnt appear to be straight 25p->24p 'slowdown' - I tried a rate-changed/resized encode (576/25p -> 480/23.976p) for comparison, and that is perceptibly slower on playback. So what then - interpolation ??