IVTC and AR halfD1 questions, converting to xvid

[poisondeathray]

In regards to resizing a Half D1 (352x480) in Xvid, would it make sense to lose the height resolution rather than expand the half-width. That is, resize to 352 x 240 (or actually 320 x 240 for square pixels), rather than to 640 x 480?

It would depend what you are playing this back on , and if it supported non-square pixels for xvid playback . My preference is to keep the original frame size (so 352x480 and setting the DAR setting in the encoder , or afterwards with another tool like mpeg4modifier)

For square pixels , it would depend on the quality of the content , for me to justify what square dimension to resize to.

Also wondering what causes the green line you see on the bottom of some divx? I saw it on some 512x384 divx which I thought was an okay frame size.

Not sure.... would need more details . Is this on PC playback or Standalone DVD player ? If PC playback, what software and decoder ?

[spiritgumm]

hi poisondeathray,
I was converting the Half D1 for filesharing, and assume it will be played on a variety of systems, including dvd players. I thought converting to square pixels was standard practice (seems to be the advice in Xvid guides, and in posts here).

The green line is visible using Media Player Classic (with whatever default decoder, I guess), but isn't displayed on my dvd player/TV. I figured it was still part of the encode, but just cropped out. It's on a bunch of divx (all encoded from dvds the same way) which I downloaded.

When I recently played an unfinished script (the video was cropped but not resized yet) with MPC, I got the same green line at the bottom. When I resized, green was gone, so I thought perhaps it was a MOD-related issue.

[poisondeathray]

RE: square pixels - if you want the most compatibility between systems, square pixel the safest way to go.

But 320x240 seems like an awfully low resolution , even for the low quality sources that you have posted. I just listed my personal preferences, but again I would resize in accordance to the quality of the source if I were to use square pixels. You could use other "in between" 4:3 mod16 resolutions eg. 576x432 , or whatever you feel like, if the quality doesn't justify 640x480 (waste of bitrate going to be required for that frame size)

RE green line: 512x384 is mod16 compliant , so that doesn't explain it . It must be MPC or your directshow system filters. Can you try in VLC, or MPCHC , or KMPlayer and see if green line is there

[spiritgumm]

Inre to resizing: yes, since the quality isn't too great to begin with, I don't want to inflate the size since I'm uploading them.
Inre green line at bottom: I'm using MPC HC (sorry I didn't make that clear). I downloaded the lastest version of it, as well as VLC, but the green is still displayed. If you're curious, here's a clip:
green.avi

[poisondeathray]

As far as I can tell , that green line is hardcoded into the file. It's present even when using different decoders. Whoever made it probably had problem decoding the original source, so the green line is now permanently part of that video

You might not see it on regular DVD/TV setup because of overscan

I think the only way to get rid of it would be to crop it out (+ resize) and re-encode

[jagabo]

I agree, the video is encoded with the green line.

[spiritgumm]

I was wondering if there was a definite reason for the green line(s) which pop up? Is it an issue with certain programs, or not following certain guidelines when encoding (which I thought after previewed a script that wasn't sized correctly). I suppose color space and half-pixels couldnt be the culprit?

From a post by Jagabo in this thread about the perils of resizing:
https://forum.videohelp.com/threads/260907-resizing-with-mod16-in-mind

I don't know if it has a name but I can tell you where it comes from. MPEG codecs use the YUV colorspace with planar YV12 subsampling internally. The U and V (color) planes are stored at half the resolution of the Y (intensity) plane. A 720x480 frame has a 720x480 Y plane with 360x240 U and V planes. So the full frame size needs to be a multiple of 2 to keep the U and V planes from having half pixels. (Of course, in practice, there are no half pixels. There would have to be special handling to account for it.)

[jagabo]

Yes, green borders like that are a common symptom when a file was encoded at a modulus (eg, mod2) that wasn't properly supported by the encoder or the decoder. For example, that video may have originally been encoded at 512x386 and somebody resized and reencoded to 512x384, or something like that.

I patched the AVI header and the STRF header to say the video was 512x380. It played back 4 lines shorter and without the green lines. But that's a nasty trick that will probably cause some players to crash. A safer option would be to remux into MKV and use the MKV playback cropping option.

[spiritgumm]

That's thinking outside the box. I dont know anything about MKV, so I'll have to research it.

Unrelated, but rather than start another thread:
I'm converting mpeg2 Pal dvd to Ntsc (resize in avisynth, run thru Dgpulldown 25-29.97). Retail discs of old 1960s video (maybe kinescope? there's ghostly quality.
Stepping thru the fields, some of the dvds have a one "frame forward, one frame slightly back" pattern. Adding TFM makes the video pattern progressive. However, after encoding sample scripts with and without TFM (followed by DGpulldown), the videos play the same. My question - do I need to TFM or what?

[manono]

Don't you know by now? Post a sample.

[spiritgumm]

figured it was a typical or known video format (maybe a standard PAL method for making old video play smoother), and yall would know it. Here's a clip:
VTS_04_1.demuxed.m2v

[manono]

Since it's interlaced you can't apply pulldown without first deinterlacing it. That's why you get a mess after DGPulldown - you can only apply pulldown to something progressive. So, either deinterlace it in the script before encoding it or do a conversion from PAL 25i to NTSC 29.97i, and then encode it as interlaced with no pulldown afterwards. You also have to be real careful with the resizing. And you don't use TFM since there are no fields that can be matched up.

[spiritgumm]

I'm resizing with lanczos4resize(720,480). What problems should I be looking out for in regards to resizing?

I added yadif plugin and
Yadif(mode=1, order=1)
SRestore(25)
I stepped thru the script (separatefields), and it looked the same as when I used TFM.
Then encoded the sample with HC, and ran Dgpulldown, same as I did for the TFM and original video sample. All 3 sample videos look the same (granted, I'm encoding them at a low bitrate to speed up the process, but I could still tell if there were any playback issues). I am also using a different clip from the video which is alittle easier to see motion.
Any ideas what I'm doing wrong? I did close/reopen HC before each encode and then load the script, so I didn't accidentally use the same script each time.

[manono]

Why are you using an unblender when it's not field-blended? If you want to make it progressive for AVI or whatever just deinterlace it.

As for resizing, if making it progressive, resize after deinterlacing it. If keeping it interlaced, resize while it's bobbed.

[jagabo]

Get rid of SRestore(). After Yadif():

ChangeFPS(59.94)
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()

That will give you 30i that's fairly smooth. If you prefer field blending use ConvertFPS() instead of ChangeFPS().

I also did a little experimenting with getting rid of the horizontal stripes:

Mpeg2Source(...)
AssumeTFF()
Yadif(mode=1, order=1)
BilinearResize(480,144)
BilinearResize(720,480)
TUnsharp(type=3, radius=3, strength=100, thresholdL=0, thresholdU=255)

ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()

[spiritgumm]

I've been "lucky" not to need to deinterlace (only ivtc-ing), but I dont know much about it for the same reason.
I wouldn't have known about resizing during bobbing (I thought it was the pixel size that might have mattered).

Thanks for the script, jagabo. I noticed that using Lanczos4Resize instead of Bilinear increased the sharpness. Is there a reason Bilinear must be used in this situation?
I assume down-resizing eliminates those horizontal lines. Does this also happen to eliminate the interlacing? I read something about that on a deinterlacing site.
What do you think about just using the two resize commands in the script? It seems like a progressive video results. Does it differ from regular deinterlacing? Are different deinterlacers used for different situations, so there's no single recommended one?
Is it better to change the FPS in Avisynth than to use DGpulldown later?

Mpeg2Source(...)
AssumeTFF()
Lanczos4Resize(480,144)
Lanczos4Resize(720,480)
TUnsharp(type=3, radius=3, strength=100, thresholdL=0, thresholdU=255)

[jagabo]

Thanks for the script, jagabo. I noticed that using Lanczos4Resize instead of Bilinear increased the sharpness. Is there a reason Bilinear must be used in this situation?

I thought Bilinear would better eliminate the horizontal lines and result in fewer artifacts from the TUnSharpen. You should experiment for yourself though.

I assume down-resizing eliminates those horizontal lines. Does this also happen to eliminate the interlacing?

The video was deinterlaced by Yadif before resizing, so no, downsizing does not eliminate the interlacing in this instance. If the video had been interlaced downsizing by half (in the vertical dimension) would be very much line a blend deinterlace.

What do you think about just using the two resize commands in the script? It seems like a progressive video results. Does it differ from regular deinterlacing? Are different deinterlacers used for different situations, so there's no single recommended one?

Again, the video was already deinterlace by Yadif in this case. I downsized vertically to eliminate the horizontal lines, and horizontally to eliminate some of the MPEG artifacts (the underlying video is so blurry it doesn't really hurt the contents). I upsized to get back up to NTSC DVD size. Then used TUnsharp to sharpen up the result.

Is it better to change the FPS in Avisynth than to use DGpulldown later?

After TUnsharp the video is at 720x480p50. The smoothest playback of that is to convert to 30i (60 fields per second). If you convert to 25p (you could use Yadif(mode=0) for that) and DgPulldown you will not get as smooth playback -- there will only be 25 different pictures every second with 3:2:3:2:2 judder, whereas the 50p->30i gives you 50 different pictures every second with a duplicate every 5 fields (5 tiny jerks per second). Which you prefer is a matter of taste. If I was making AVI or MKV files I'd leave the video at 50p.

[spiritgumm]

I tried the script but the video's jumpy (viewed on TV) when there's action. I posted my results below.
I was thinking I should make video progressive and encode with 3:2 pulldown (for dvd video), but sounds like progressive isnt always a priority. But if I wanted to, how would I get it 23.976 or 25 progressive?
For Pal TVshows already progressive, it sounds like you'd still recommend the ChangeFPS, etc. script over DGpulldown?

...If the video had been interlaced downsizing by half (in the vertical dimension) would be very much line a blend deinterlace.

That's what I meant when I asked about resizing making progressive video. On their own, I noticed that just the resize lines did this (blend deinterlace). I tried it with the video sample I used for my action clip below, but it also produced the same jumpy video as the whole script.

action.m2v

[jagabo]

You encoded that video progressive but it's interlaced, TFF. Your DVD player is probably playing it with the wrong field order (BFF).

[manono]

It doesn't play jumpy to me (on the computer).

But if I wanted to, how would I get it 23.976 or 25 progressive?[/URL]

Deinterlace it. For 23.976fps add AssumeFPS(23.976) and slow the audio to match.

You encoded that video progressive but it's interlaced, TFF.

Oh yeah, you're right. A big no-no.

[spiritgumm]

You encoded that video progressive but it's interlaced, TFF. Your DVD player is probably playing it with the wrong field order (BFF).

I guess HCencoder isn't as idiot-proof as I thought. An interlaced encode works on my regular player. The bad encode worked fine on another dvd player, though.
But my script wherein I only resized the video to give a blended deinterlace also looked jumpy (on my regular player, but played fine in another). Shouldn't that have looked okay encoded progressive? I don't think I added "assumeTff" in that script, was that it? Or could this be an issue with the player - I just hacked it for region 2 dvd - maybe something got messed up.

These TV shows range from 1959, 1966-9, 1971, and are either film, videotape, or a mix. I thought they were shot for Pal TV (25 fps), so I shouldn't slow them with Assumefps(23.976). That's why I was going to use DGpulldown for the progressive dvds.
If they should be slowed down (which is a simple script for the progressive dvds), for the interlaced dvds, would I use a variation of jagabo's script? That is, how do I deinterlace them? I've seen many scripts for it, but am unsure which to go with.

[jagabo]

You encoded that video progressive but it's interlaced, TFF. Your DVD player is probably playing it with the wrong field order (BFF).

I guess HCencoder isn't as idiot-proof as I thought. An interlaced encode works on my regular player. The bad encode worked fine on another dvd player, though.

When a progressive frame is sent to a interlaced device it is sent as two fields. Some players will send a progressive frame TFF, others BFF. So one of your players happened to send the progressive frame to the TV with the right field order -- so it played smoothly. The other sent with the opposite field order so it was jerky.

[spiritgumm]

Well, that makes sense for that sample. I guess I could see if adding AssumeTFF would fix that other sample.
So, no advice on deinterlace script? Should I use yadif, or smoothdeinterlacer or...?

Separate question: if one is slowing down Pal progressive video to film speed for avi files, should the speed be 24 fps (rather than 23.976 fps used for dvd video)?

[jagabo]

Well, that makes sense for that sample. I guess I could see if adding AssumeTFF would fix that other sample.

It would fix it for one player but not the other. If a video is interlaced you should encode it interlaced with the correct field order.

So, no advice on deinterlace script? Should I use yadif, or smoothdeinterlacer or...?

If you want to keep the smoothest motion (with the caveats mentioned earlier) you should keep it interlaced. But if you don't care about smooth motion) you should deinterlace with the best deinterlacer you can put up with. Yadif() is pretty good and fast. TempGaussMC_beta1mod() is better but very slow.

Separate question: if one is slowing down Pal progressive video to film speed for avi files, should the speed be 24 fps (rather than 23.976 fps used for dvd video)?

It should be 23.976 (24000/1001) fps. NTSC equipment is designed for 23.976/29.97 fps playback. But 24 fps will only give you one little jerk every ~40 seconds.

[spiritgumm]

I was thinking of backing up the Pal dvds to Ntsc dvd, and might later convert the Ntsc to xvid. So the general rule is leave (or keep) dvd interlaced, and deinterlace for avi? I had the impression I was suppose to deinterlace 24/7.

Is there any way to know if a Pal TVshow is sped up or not? Imdb runtimes aren't episode-accurate, and I thought some shows were shot at 25 fps.