1080i true interlaced source to DVD

[nebbish_2112]

I have true interlace (non telecined) 1080i broadcast I want to encode for DVD.

I have determined field order by:

LoadPlugin("E:\Software\Ripping\dgmpgdec148\DGDeco de.dll")
MPEG2Source("E:\"video\test.d2v")
AssumeTFF().SeparateFields()

Frame by frame analysis provide this to be TFF order.

I have determined true interlace source by:

LoadPlugin("E:\Software\Ripping\dgmpgdec148\DGDeco de.dll")
MPEG2Source("E:\"video\test.d2v")

During movement, every frame proved interlaced. I also believe it to be truly interlaced as the video is a music performance from Today show which I doubt was telecined for broadcast.

As the video is destined for DVD, I use the following script served into TMPGEnc. Video is encoded as 29.97 fps, 16:9 display, interlaced, TFF, with bitrate of 9400 kbits/sec.

LoadPlugin("E:\Software\Ripping\Avisynth_256\AviSynth 2.5\plugins\BT709ToBT601.dll")
LoadPlugin("E:\Software\Ripping\dgmpgdec148\DGDeco de.dll")
LoadPlugin("E:\Software\Ripping\leakkerneldeint154 \LeakKernelDeint.dll")
MPEG2Source("E:\"video\test.d2v")
LeakKernelBob(Order=1)
LanczosResize(720,480)
BT709ToBT601()
FadeIn(30)
FadeOut(30)
AssumeTFF().SeparateFields()
SelectEvery(4,0,3).Weave()

When burned to DVD-RW and viewed on my 720p HDTV, the video is clear on static shots. However any panning produces an uncomfortable type of blurring. Noticable jerkiness is especially evident on the news ticker that scrolls across screen bottom.

Is there any hope for my HDTV to DVD endeavor, or is there something I'm just not doing correctly? I've been fine tuning my script for some time now and I thought I had a winner, but I'm fast becoming frustrated with the whole process and ready to chuck all digital equipment and go back to being analog man.

[Soopafresh]

Your Avisynth settings look correct. The only thing I can think of is that the Mpeg encoder you're using is set to BFF by mistake. The type of problem you're describing is most often TFF/BFF mixups.

[nebbish_2112]

Well I changed field order to see what would happen, and the result was very poor. This assures me that I have the field order set correctly.

Do you think what my Video monitor wants some other type of input? It is a 720P display and perhaps progressive material is better suited? Am I reaching here? There has to be an explanation. Pehaps I'll view the material on my older analog set and see what it looks like.

Lastly, can I make my script for 29.97 progressive? Would I just select even fields and encode as 29.97 progressive? I'm sure my player can handle this content and I'm willing to make a batch of test files to see what looks best on my TV.

Thank you.

[Alex_ander]

I did something like this, looked good with my material:

LoadPlugin("...\DGDecode.dll")
MPEG2Source("...\video.d2v")
AssumeTFF().SeparateFields()
SelectEven()
LanczosResize(720,480)

[Soopafresh]

Absolutely. You can deinterlace 1080i to 480p resolution with excellent results. Script modification is minor.

I like Yadif as a deinterlacer - it's pretty fast and accurate. http://avisynth.org.ru/yadif/yadif09.zip

You have to load it slightly differently than other Avisynth plugins.

LoadPlugin("E:\Software\Ripping\Avisynth_256\AviSy nth 2.5\plugins\BT709ToBT601.dll")
LoadPlugin("E:\Software\Ripping\dgmpgdec148\DGDeco de.dll")
Load_stdcall_plugin("E:\Software\Ripping\yadif.dll ")

MPEG2Source("E:\"video\test.d2v")

assumeTff()
Yadif()
LanczosResize(720,480)
BT709ToBT601()
FadeIn(30)
FadeOut(30)

Try Alex_ander's suggestion first. I used to do it that way - it's very fast, although I like visual results of using Yadif. Try them both and you decide.

[nebbish_2112]

Thank you both. I will try it both ways and see what appeals to me. Too bad TMPEGEnc won't let me encode 29.97 material at 720x576. Guess I can't have the best of all worlds.

Lastly, do you think there's anything about my theory of native 720p set better displaying progressive than interlace material, or am I just talking out my a$$?

[manono]

Lastly, do you think there's anything about my theory of native 720p set better displaying progressive than interlace material, or am I just talking out my a$$?

That depends on the deinterlacer used either by your player or the TV set, whichever you have do the deinterlacing. My Oppo DVD player and my 720p Samsung TV set both use the Faroudja chipset, and the deinterlacing is excellent. If you're outputting 720p from the player - if you're using it to upconvert, rather than the TV set - then it's doing the deinterlacing. I guess you do know that by making your video progressive 29.97fps, you'll be giving up half the framerate and losing half of the fluidity of motion.

[nebbish_2112]

[quote="manono"]

. I guess you do know that by making your video progressive 29.97fps, you'll be giving up half the framerate and losing half of the fluidity of motion.

I'm just trying to figure out why my original interlace script doesn't produce good video. The encoded content is destined for plain old DVD to be viewed on my 720p DLP Samsung display. I have no capability to play nor feed the original 1080i content with my current equipment, this is the reason I am converting in the first place.

[jman98]

I guess you do know that by making your video progressive 29.97fps, you'll be giving up half the framerate and losing half of the fluidity of motion.

Huh? I certainly may be misunderstanding something here and if so, please correct my ignorance (I really mean that), but since the source is 29.97 fps (remember 1080i is always broadcast at 29.97 fps in the USA - it's not like 60 fps 720p stuff) how is he going to "give up half the framerate" by staying at 29.97 fps?

[nebbish_2112]

My original material is 1080i at 29.97 fps.

However, I do have 720p material that does report at 59.941 framerate. This was capped by a user in NYC. So there must be higher framerate transmitter for 720p material here in US.

[Soopafresh]

However, I do have 720p material that does report at 59.941 framerate. This was capped by a user in NYC. So there must be higher framerate transmitter for 720p material here in US.

Yes. ABC HD broadcasts at 720p 59.94fps. With an HD capture card, you can get it in it's full glory and play it back on your PC at the same resolution. But a standard DVD player isn't going to support 59.94fps. The high end media players will support it, however.

Huh? I certainly may be misunderstanding something here and if so, please correct my ignorance (I really mean that), but since the source is 29.97 fps (remember 1080i is always broadcast at 29.97 fps in the USA - it's not like 60 fps 720p stuff) how is he going to "give up half the framerate" by staying at 29.97 fps?


He won't, but throwing away a field does result in reduced quality because the fields aren't identical. That's why bobbed footage looks so beautiful - the fields are placed side by side and the framerate consequently doubles, resulting in very natural looking video. Check out this page for some examples:

https://forum.videohelp.com/topic313674.html?highlight=bobbed

[Alex_ander]

.... but since the source is 29.97 fps (remember 1080i is always broadcast at 29.97 fps in the USA - it's not like 60 fps 720p stuff) how is he going to "give up half the framerate" by staying at 29.97 fps?

1080i is 29.97 and 59.94field/s (each field carries data of an independent motion phase). By deinterlacing (at 29.97) you drop half of motion phases and thus lose in motion reproduction.

[edDV]

However, I do have 720p material that does report at 59.941 framerate. This was capped by a user in NYC. So there must be higher framerate transmitter for 720p material here in US.

Yes. ABC HD broadcasts at 720p 59.94fps.

Fox also.

In some markets, PBS-HD 1080i/29.97 is processed (motion based Bob) to 720p/59.94. This allows lowering bit rate to fit two additional SD channels to the mux without jerky motion for the main channel.

[manono]

I guess you do know that by making your video progressive 29.97fps, you'll be giving up half the framerate and losing half of the fluidity of motion.

Huh? I certainly may be misunderstanding something here and if so, please correct my ignorance (I really mean that), but since the source is 29.97 fps (remember 1080i is always broadcast at 29.97 fps in the USA - it's not like 60 fps 720p stuff) how is he going to "give up half the framerate" by staying at 29.97 fps?

Have the replies since your post explained it to your satisfaction? If he encodes for interlaced 29.97fps and watches it on a standard interlaced TV set, he'll be viewing 59.94 fields per second. If he views his interlaced 29.97fps encode on his 720p Samsung, then he's viewing 59.94 full frames per second. The fields get bobbed for output to his progressive display. If, however, he deinterlaces his 1080i source to progressive 29.97fps, then when being displayed on his 720p set it's still 59.94 full frames per second, but each one gets displayed twice. He's tossed out half the fields.

Now, for ease of encoding, compression efficiency, and other reasons (bad deinterlacer in his player or TV set?), he may prefer to encode for progressive 29.97fps, but nebbish_2112 should realize what he's giving up.

I'm not sure just why his encoded DVD plays jerky, if that's what it does. Perhaps if he uploaded a small sample of the finished product (10 seconds or so of a section with movement), we could go over it for clues.

[nebbish_2112]

OK, so in the original script I posted I have:

"AssumeTFF().SeparateFields()"

If I had forgotten to add the "AssumeTFF()" do you think that may be responsible for the jerky performance I was seeing on my TV?

I have since added the "AssumeTFF()" to my script, encoded as interlace, and now it looks good.

Any thoughts?

[Alex_ander]

OK, so in the original script I posted I have:

"AssumeTFF().SeparateFields()"

If I had forgotten to add the "AssumeTFF()" do you think that may be responsible for the jerky performance I was seeing on my TV?

I have since added the "AssumeTFF()" to my script, encoded as interlace, and now it looks good.

Any thoughts?

If you mean the end of the script, then yes, in absence of AssumeTFF() the field order would be BFF in the end (by default field order is assumed BBF by AviSynth and the fields would be separated differently). In the beginning of the script AssumeTFF() (or even AssumeBFF) is ignored by LeakKernelBob() since it uses order=1 (means TFF) parameter to determine the field order.

[halsboss]

Just a thought, the ntsc equivalent of this is no good or doesn't work ?
"PAL 1080i HD -> 576i for DVD authoring" https://forum.videohelp.com/topic337231.html
Cheerio

[nebbish_2112]

This is all very interesting. As I learn more, I have the following thoughts and questions going through my head.

1. My intent was to take 1080i/30 material and encode for use on a SD DVD player for viewing on 720p DLP Sansung display. With everyone's generous help, I successfully resized and encoded to 480i which looks great on my TV. As I understand it, encoding as interlaced preserves all the original fields, as opposed to progressive which would throw away half the fields.

2. I have a 720p display. As such, any interlaced material introduced must be de-interlaced. As my DVD player is not of an upconveting variety, I imagine my TV is responsible for the de-interlace. This is true of any 1080i/30 signal coming directly from my cable television provider, or a 480i/30 signal coming from my DVD player.

3. Even though I have a native 720p display, if the television de-interlacing processing is good enough, than interlaced signals should view OK. I should have already known this as 1080i/30 content from my cable television provider looks great. This 1080i/30 signal is being de-interlaced by the television for progressive display. So I guess I was somewhat wrong when I assumed progressive material to be better suited than interlace material for my display. Again, by encoding my 1080i/30 material for 480i/30i this is optimal because my frames are preserved, and my 720p display is adequate to properly de-interlace this material for display.

4. Am I able to encode the 1080i content for 25fps, with a resolution of 720x576? I will be compromising some frames, but gaining some resolution? Just a crazy thought.

5. I was under the assumption that to enjoy Blu-Ray or HD DVD content, I would need a 1080p display. My display is really 1280x720. The SD content from my current DVD player is 720x480. There will be a certain difference in viewing Blu-Ray or HD DVD on my 720p display, though not as good as if I had a 1080p display. I am guessing it would be similar to the 720p content coming from FOX HD for example. This is a technology I should consider? HD DVD players are on the cheap.

6. Why do I worry about this when in 2009 interlace TV is going bye-bye?

[Alex_ander]

Am I able to encode the 1080i content for 25fps, with a resolution of 720x576? I will be compromising some frames, but gaining some resolution?

Here's a possible solution, I do so to prepare NTSC 1080i sources for PAL compilations:

LoadPlugin("...\DGDecode.dll")
LoadPlugin("...\LeakKernelDeint.dll")
MPEG2Source("...\DGIndex_project.d2v")
LeakKernelBob(order=1)
LanczosResize(720,576).ChangeFPS(50)
AssumeTFF().SeparateFields()
SelectEvery(4,0,3).Weave()

[halsboss]

I'd check on your assumption

2. I have a 720p display. As such, any interlaced material introduced must be de-interlaced. As my DVD player is not of an upconveting variety, I imagine my TV is responsible for the de-interlace. This is true of any 1080i/30 signal coming directly from my cable television provider, or a 480i/30 signal coming from my DVD player.

that you need to deinterlace. I thought the TV doesn't deinterlace either... it displays interlaced whilst having capacity to display in p if it gets it ? Shove 480i at it straight from an ntsc DVD if you're in ntsc country and let it do its job, either way. Just a thought - consider an upsizing DVD player ... the HDMI connection is well well worth it as I noticed a big big difference when I swapped over from a DVD player with composite connections to an upsizing one with digital HDMI connection.

4. Am I able to encode the 1080i content for 25fps, with a resolution of 720x576? I will be compromising some frames, but gaining some resolution? Just a crazy thought.

Can't see the benefit of this... If you have ntsc material, why not leave it like that without all the conversion/display issues... the tellys display it just fine.

Cheerio

[nebbish_2112]

I'm not sure just why his encoded DVD plays jerky, if that's what it does. Perhaps if he uploaded a small sample of the finished product (10 seconds or so of a section with movement), we could go over it for clues.

OK, here are two links to the material in question. I have included a clip of the original 1080i source

http://rapidshare.com/files/70360311/Test_Clip_1080i.mpg.html

and a clip of my encoded 480i. When played through my TV, the 480i clip is very shaky or jittery

http://rapidshare.com/files/70363896/Test_Clip_480i.mpg.html

Any thoughts now?

[manono]

Slow download, that place, and they want me to wait over an hour to get a second one (the source).

DGIndex and AviSynth's Info() command both say it's BFF. But it's not. That 480i sample is really TFF. There's a chance the field order got switched when being cut, but in any event you encoded it incorrectly. You set an incorrect field order in the encoder.

Before sending your script to the encoder add these 2 lines to the very bottom:

AssumeTFF()
SeparateFields()

Open the script in VDub(Mod), scroll to a place with movement, and then I hold down the keyboard's right arrow key to play it. If it plays smoothly it's really TFF. If it plays jerkily, it's really BFF. Then, if you like, you can replace AssumeTFF() with AssumeBFF(), and repeat the procedure. Anyway, for whichever field order it plays smoothly, that's how you should encode it. Remove those 2 last lines before sending to the encoder. About your earlier question:

If I had forgotten to add the "AssumeTFF()" do you think that may be responsible for the jerky performance I was seeing on my TV?

Yes, very possible, as Alex_ander also agreed. Meaning, I guess, that the script you gave first, and which you said you had used for the encoding, wasn't the exact script you used at all, was it?

[nebbish_2112]

OK, to discuss the original script I had orignally forgot to put in the Assume() in the script, but as I soon as I realized my error I did include this in the script with the same jerky result upon encodig and viewing on my TV.

Secondly, I do agree with you that the 480i test clip is in fact TFF. Perhaps this did happen upon cutting it.

Upon your recommendation, I did add

AssumeTFF()
SeparateFields()

to the end of my complete 1080i source and the video does in fact prove to be BFF.

To go futher I did check the filed order of the 1080i test clip I uploaded and it too does prove to be BFF, the same as the complete 1080i clip I have. Apparently the cut didn't affect it's field order. If it really is 1080i BFF, and I am encoding for BFF, I have no explanation for why this is happening.

Perhaps you may have success next hour in grabbing my 1080i test clip and evaluating for yourself.

Out of desperation, I think I may now keep this script written as BFF, but encode for TFF for the heck of it and see what happens.

(Not to cause confusion, this clip is not the same as the clip referenced in the script I originally provided above. I have 4 clips that are acting this way and some seem to be TFF and some BFF. The test clip I uploaded proves to me to be BFF and was encoded as BFF. If my original script reflected this particular uploaded test file, it would be written to reflect BFF.)

[manono]

Out of desperation, I think I may now keep this script written as BFF, but encode for TFF for the heck of it and see what happens.

A better (and faster) idea might be to just change the field order using ReStream. I don't use TMPGEnc, so I can't help with the settings in that one.

[nebbish_2112]

The results are in and the video looks great!

I swear it is bottom field first in all the testing I have done. I left script for bottom field first, but encoded as TFF and everything looks good.

I also ran raw m2v through ReStream, remuxed, and all is good.

So, how can tis be? Another test I did was write script for TFF, and encode for TFF and it again was jerky upon playback in my DVD player. I wonder if I kept script as TFF, and encoded as BFF if all would be OK this way?

Is it possible someting in the file is screwed up?

I really appreciate your help in all this.

[nebbish_2112]

Open the script in VDub(Mod), scroll to a place with movement, and then I hold down the keyboard's right arrow key to play it. If it plays smoothly it's really TFF. If it plays jerkily, it's really BFF.

Actually i was not able to tell if it played jerky in VDub MOD using this method. When scrolling through frame by frame this proved to be a better method as I could see the actual back and forth jerky movement with the incorrect field order specified.

[Alex_ander]

So, how can tis be? Another test I did was write script for TFF, and encode for TFF and it again was jerky upon playback in my DVD player. I wonder if I kept script as TFF, and encoded as BFF if all would be OK this way?

If you mean the actual field order after the script, it should match the encoder setting for correct result (unless the encoder offers some special setting for getting different field order). The field order from the script can differ from the expected if wrong field order of the source is considered. E.g. if your 1080i source is BFF and order=1 is used in LeakKernelBob instead of order=0, then AssumeTFF() before separating fields will make the script output BFF and vice versa (assumed BFF will give TFF in the end).

[nebbish_2112]

I guess I do not understand. Now I am really lost.

The field order for my 1080i source is BFF. As such, my script has LeakKernelBob = 0. AssumeBFF(). SelectEvery(4,1,2). Because my 1080i source is BFF, I must use this script and encode as BFF.

If my 1080i source is TFF, my script has LeakKernelBob = 1. AssumeTFF(). SelectEvery(4,0,3). Because my 1080i source is TFF, I must use this script and encode as TFF.

Is this incorrect thinking? I must be missing something.

[jagabo]

After LeakKernelBob() you have a series of frames, twice as many as in the original source.

SeparateFields() from there will separate the fields based on the Assumed field order.

Using SelectEvery(4, 0, 3) followed by Weave() will maintain the Assumed field order:

AssumeTFF(): 
Frames:               1     2     3     4 
SeparateFields():     1t 1b 2t 2b 3t 3b 4t 4b 
SelectEvery(4, 0, 3): 1t       2b 3t       4b 
Weave():              1t+2b       3t+4b 

AssumeBFF(): 
Frames:               1     2     3     4 
SeparateFields():     1b 1t 2b 2t 3b 3t 4b 4t 
SelectEvery(4, 0, 3): 1b       2t 3b       4t 
Weave():              1b+2t       3b+4t

Using SelectEvery(4, 1, 2) will reverse the field order:

AssumeTFF():
Frames:               1     2     3     4
SeparateFields():     1t 1b 2t 2b 3t 3b 4t 4b
SelectEvery(4, 1, 2):    1b 2t       3b 4t   
Weave():                 1b+2t       3b+4t (now BFF)

AssumeBFF():
Frames:               1     2     3     4
SeparateFields():     1b 1t 2b 2t 3b 3t 4b 4t
SelectEvery(4, 1, 2):    1t 2b       3t 4b   
Weave():                 1t+2b       3t+4b (now TFF)

[manono]

SelectEvery(4,1,2). Because my 1080i source is BFF, I must use this script and encode as BFF.

Yep, jagabo explained it. What you did made it TFF. Encoding as BFF will give you jerkiness. If you had said these things earlier we could have diagnosed the problem earlier, and you would have understood what was going on earlier.

Both of those scripts you presented give you a TFF result. There's nothing wrong with that necessarily. I do it that way sometimes myself, as my CCE is already set up for TFF encoding. But you have to know what to expect so you can set up the encoder correctly. Had you put on my little 2-line script addition to the bottom of your script, you would also have seen the error of your ways.

Actually i was not able to tell if it played jerky in VDub MOD using this method.

Maybe there are differences in how this works in the various VDub varients. I'm using VDubMod 1.5.10.2 and holding the right-arrow key works fine to play the video.