Pulldown of 25 fps to NTSC

[Inwards]

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]

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]

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]

@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]

@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]

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]

@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]

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]

@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]

@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]

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]

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]

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

[JetlagMk2]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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

[Guest]

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]

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

[digidragon]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Guest]

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]

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]

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]

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]

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

Anyway, GUI coding bores me.

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

[scharfis_brain]

, i.e., 23.97544.

uh? what?

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

*scharfi_becomes_hurry_to_test_out_some_things*

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

EDIT:
wow! again!

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

yeah. finally super-8 with progressive encoding on DVD :) :)

[Guest]

Originally posted by scharfis_brain
yeah. finally super-8 with progressive encoding on DVD Hey, Mikey, he gets it!

Only the output frame rate needs to be legal.

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

[digidragon]

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

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

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

[Guest]

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

So I did another re-encoding using TMPGEnc, but this time specified an interlaced output, and gspot reported it as I/L TFF. After running this through DGPulldown, VLC and MPC both played it without any jerkiness. That's very important and I'm glad you pointed it out. The RFF flag is interpreted differently depending on the value of progressive_sequence and progressive frame, according to ISO. DGPulldown needs to set progressive_sequence to 0 and progressive frame to 1. This may explain why a few players got confused. I'll crank a new version right away.

[Guest]

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

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

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

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

[JetlagMk2]

Um, 25 / 16.667 < 1.5.

[scharfis_brain]

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

I don't understand.

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

[digidragon]

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

[Guest]

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

I don't understand.

16.666667 -> 25 seems to work.
dgpulldown doesn't complain about anything. Darn those floating point comparisons! I'll fix it once and for all.

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

a a b
a b b

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

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