Pulldown of 25 fps to NTSC [Archive] - Page 4

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.