How to convert 1080p flagged for 1080i output

[MrVideo]

For the life of me I can't remember the term for a MPEG-2 video that is stored in the transport stream as 1080p23.976, but with flags to cause the output during playback on the user's display to be 1080i29.97.

I have such a video that I want to convert to H.264 1080p23.976.

Here is a sample of the DGI file:

DGMPGIndexFileNV14 DGIndexNV 2041 X32
c:\Program Files\dgavcdecnv\

e:\\Test_file.m2v 773655414

DEVICE 0
DECODE_MODES 0,1,0
STREAM 0
CLIP 0 0 0 8
RANGE 0 0 773655413 0
AUDIO

SEQ 0
SEQEXT 0
GOP 1 1
0:FRM I 3 1 0 0
1:FRM P 3 1 0 0
2:FRM P 3 1 0 0
3:FRM P 3 1 0 0
4:FRM P 3 1 0 0
5:FRM P 3 1 0 0
6:FRM P 3 1 0 0
7:FRM P 3 1 0 0
8:FRM P 3 1 0 0
9:FRM P 3 1 0 0
10:FRM P 3 1 0 0
11:FRM P 3 1 0 0
12:FRM P 3 1 0 0
13:FRM P 3 1 0 0
14:FRM P 3 1 0 0
15:FRM P 3 1 0 0
16:FRM P 3 1 0 0
17:FRM P 3 1 0 0
18:FRM P 3 1 0 0
19:FRM P 3 1 0 0
20:FRM P 3 1 0 0
21:FRM P 3 1 0 0
22:FRM P 3 1 0 0
23:FRM P 3 1 0 0
24:FRM P 3 1 0 0
25:FRM P 3 1 0 0
26:FRM P 3 1 0 0
27:FRM P 3 1 0 0
28:FRM P 3 1 0 0
SEQ 1572965
SEQEXT 0
GOP 0 1
29:FRM B 3 0 0 0
30:FRM B 3 0 1 1
31:FRM I 3 1 0 0
32:FRM B 3 1 1 1
33:FRM B 3 0 0 0
34:FRM P 3 0 0 0
35:FRM B 3 0 0 0
36:FRM B 3 0 0 0
37:FRM P 3 0 0 0
38:FRM B 3 0 1 1
39:FRM B 3 1 0 0
40:FRM P 3 1 1 1
41:FRM B 3 0 0 0
42:FRM B 3 0 1 1
43:FRM P 3 1 0 0
44:FRM B 3 1 1 1
45:FRM B 3 0 0 0
46:FRM P 3 0 1 1
47:FRM B 3 1 0 0
48:FRM B 3 1 1 1
49:FRM P 3 0 0 0
50:FRM B 3 0 1 1
51:FRM B 3 1 0 0
52:FRM P 3 1 1 1
53:FRM B 3 0 0 0
54:FRM B 3 0 1 1
55:FRM P 3 1 0 0
56:FRM B 3 1 0 0
57:FRM P 3 1 0 0
58:FRM B 3 1 0 0
59:FRM P 3 1 0 0
60:FRM B 3 1 0 0
61:FRM P 3 1 1 1
62:FRM B 3 0 0 0
63:FRM B 3 0 1 1
64:FRM P 3 1 0 0
65:FRM B 3 1 1 1
66:FRM B 3 0 0 0
67:FRM P 3 0 1 1
68:FRM B 3 1 0 0
69:FRM B 3 1 1 1
70:FRM P 3 0 0 0
71:FRM B 3 0 1 1
72:FRM B 3 1 0 0
73:FRM P 3 1 1 1
74:FRM B 3 0 0 0
75:FRM B 3 0 1 1
76:FRM P 3 1 0 0
77:FRM B 3 1 1 1
78:FRM B 3 0 0 0
79:FRM P 3 0 0 0
SEQ 5108982
SEQEXT 0
GOP 1 1
[... skip ...]
11908:FRM B 3 1 1 1
11909:FRM P 3 0 0 0
11910:FRM B 3 0 0 0
11911:FRM B 3 0 0 0
11912:FRM P 3 0 0 0
11913:FRM B 3 0 0 0
11914:FRM P 3 0 0 0
11915:FRM B 3 0 1 1
11916:FRM P 3 1 0 0
11917:FRM B 3 1 1 1
11918:FRM P 3 0 0 0
11919:FRM B 3 0 1 1
11920:FRM P 3 1 0 0
SEQ 773415009
SEQEXT 0
GOP 1 1
11921:FRM I 3 1 0 0
SIZ 1920 x 1088
FPS 30000 / 1001
CODED 11922
PLAYBACK 14386
82.69% FILM
ORDER 1

What filter is used to handle this type of conversion?

Thanks for any pointers.

[MrVideo]

Oh, and yes, it will encode as H.264 1080i29.97 with 2:3 pulldown perfectly.

I'd also like to know why this didn't work:

LoadPlugin("C:\Program Files\DGAVCDecNV\DGDecodeNV.dll")
dgsource("e:\\Test_file.dgi")
assumetff()
telecide(guide=1,post=0,y0=750,y1=1079)
decimate()

If dgsource is presenting the video to AVS at 2:3 pulldown, since it recoded it just fine as 1080i29.97, why the normal IVTC that I use above doesn't work?

[Guest]

What exactly do you mean when you say it didn't work?

[MrVideo]

Oops, sorry about not providing that bit of info.

The resulting recoded file still had fields from two different source frames.

The 1080i file that was recoded had no trouble with the info provided from your program, as the x264 encoder was given perfect 2:3 pulldown interlaced frames.

[MrVideo]

I tried creating intermediate MPEG-2 and H.264 1080i 2:3 pulldown files and while the 1080i files "looked" as though they had correct 2:3 pulldown, trying to convert those files to 1080p23.976 was a failure.

I used the script shown in the 2nd posting. At times the resulting file looks good, but most of the time there is tons of weaved fields into progressive frames. It is almost as if the 1080i29.97 files aren't really interlaced, even though the two programs I used to checked them, indicate as much.

Could explain why the script would not take the source file and work with it either.

I do not know what the frame sequences mean: 3 0 0 0 / 3 0 1 1 / 3 1 0 0 / 3 1 1 1

If the 3 0 0 0 means a pure interlaced frame, those first 29 frames are not getting converted to 1080p23.976 correctly, in that the interlaced frames are still there with two difference half-frame images.

I'm at a loss as to what to do to get this to work.

[Didée]

Your problem isn't even related to Avisynth. All you want Avisynth to do is to spit out plain 24p.

It is your encoder, resp. the encoding application, that needs to put pulldown flags into the output stream.

[Guest]

Didée, I think he's trying to do IVTC.

MrVideo, post a link to an unprocessed 50Mb+ sample of your source video. Choose a section with a lot of motion.

[MrVideo]

Correct. I'm playing around with doing IVTC of the file until the Blu-ray release later in the year.

(file removed)

It is not the speediest of connections, so it will eventually download.

Thanks.

[Guest]

Downloading...

Meanwhile, did you check for blended fields? That is a common cause of IVTC failure.

http://neuron2.net/faq.html#analysis

[MrVideo]

No, I haven't.

But, as an experiment last night I let VideoReDo do a recoding from MPEG-2 to H.264. I then took that H.264 file and did my normal 1080i29.97 -> 1080p23.976 conversion and there were no problems. Perfect IVTC.

[Guest]

Everything works fine for me with this script played in VirtualDub:

loadplugin("dgdecodenv.dll")
dgsource("Test_pulldown_video.dgi")
assumetff()
telecide(guide=1,post=0)
decimate()

There's no reason to use the y0/y1 ranges as you have.

If it fails on other parts of the movie, you need to give a sample that includes those parts.

[MrVideo]

That is weird. Let me run the script again on just that piece of video. My initial test piece starts from the beginning and is 5:23 in length and it didn't work out well at all.

The y0/y1 is part of the generic script because of network TV snipes.

[MrVideo]

OK, here is the weird part. If I go back to the beginning of the test file that I have, which is the beginning of the program, the encoding fails. It just can't IVTC correctly, even into the portion that it is able to do separately.

[MrVideo]

So, as a test, I removed the "previously on" portion from the start of the program and only recoded the actual program. That also worked.

Whatever is going on with the beginning of the file is messing with the filter so that it can't IVTC correctly.

Here is a file (no longer available) that shows the problem. It has a portion that leads up to the part that works alone, but will not work together.

I've tested the file and it does fail for me.

[MrVideo]

@neuron2

I actually expected the first sample that I posted to actually fail. My mistake for not running the sample thru the script/encoder before posting it. The file that is linked now does indeed fail when I run it through the script and the x264 encoder.

Sorry about the file posting and the slow DSL. I can't get a faster line where I am at.

I can't test the guide removal for a few hours, as the computer is busy on another project. If you'd rather wait to download the file until after I've tried the guide removal, that would be just fine. Not worth downloading if that fixes it.

I do appreciate the help.

[Guest]

With film percentage in the low 80s, guide=1 is probably not going to help, so it's worth trying without it.

I'm downloading the new sample to see what is going on in the beginning portion.

[Guest]

Why can't you use a decent file sharing site? <10Kbps is ridiculous.

[Guest]

OK, the first part has been edited after 3:2 pulldown, so there is no consistent pattern. You may need to turn on postprocessing to fix any orphaned fields for that section. You cannot use guide=1 on such material.

[MrVideo]

Why can't you use a decent file sharing site? <10Kbps is ridiculous.

Sorry, I just don't use them. Doing this is a far and between event.

But, even if I had used a file share site, the net result is that you still would have had to wait for the file to get uploaded before being able to download it.

I know, it just seems more of a pain when you are actually waiting while a file is downloading, vs. just waiting for a post that says the file is available. :D

[MrVideo]

You cannot use guide=1 on such material.

Thanks. I guess somewhere along the line I missed the fine print as to the threshold of when guide=1 can be used. I've used it constantly with video that may not have constant 2:3 cadence from beginning to end, i.e., the cadence may be lost at commercial breaks.

With all of the options removed, i.e., defaults used, the test file encoded perfectly.

Thanks for the help. I learned my something new for the day.

[Guest]

Disregard my whining. I'm an impatient soul. Need to work on that. :p

Let me clarify guide=1 a bit. It is intended for streams that are 3:2 pulled down throughout. With such streams, the field matching can fail due to noise, little mouth movements, etc. The guide option gives the matcher a sort of inertia such that it can overrule those little mismatches and stay in sync with the 3:2 pattern. If there is not a clean 3:2 pattern, it won't do anything useful.

[MrVideo]

Thanks for the added info about guide. I'll update my overall Z-shell script that sets up the AVS file by adding an option to control the setting of guide.

[MrVideo]

Once the telecide options were removed, specificially the guide=1, the whole 5:23 test piece of video encoded perfectly to 1080p23.976.

Thanks again.

[Guest]

Sweet! Thanks for the update.

[MrVideo]

You are welcome. Posting an update is something that I think should happen regarding final results for any of the threads in any forum.