IVTC and AR halfD1 questions, converting to xvid

[spiritgumm]

Have a half D1, 352x480 (4:3) which I'd like to convert to xvid. I saw a similar thread about this for divx, but I don't need to deinterlace (tho maybe ivtc). I didn't see a final definitive solution using avisynth.
https://www.videohelp.com/forum/archive/352x480-half-d1-mpeg2-to-divx-how-do-i-keep-proper-aspect-ratio-40-33-t345427.html

I'd also like to IVTC various dvd video which were recorded from multigeneration vhs. They seem to have 2:3 pulldown, except one (or both) of the duplicate fields will have motion-blur so it's almost a different field altogether. That is, sometimes 2: (1:2), or (1:1)(1:2). I'm not sure how to tweak TFM, Tdecimate or other ivtc (like Telecide) to accomplish a judder-free ivtc, as the guides assume you understand what the settings mean already.

[jagabo]

For the AR, just set the XVID DAR flag to 4:3. Or resize to a 4:3 frame size (like 640x480) and set the PAR flag 1:1 (square pixel).

Post a short sample of your video for IVTC help...

[spiritgumm]

I usually use avisynth and convert to xvid in Vdub The square pixel setting is default, so I took a sample of the 352x480 video (included below, called Bus.m2v) but combing became very noticeable (which I guess makes sense). Btw, I'm pretty sure all these videos are telecined 29.97, not interlaced. Someone suggested resizing it to 512x384, which did not produce combing, so that might be the better option.

The attached video Work.avi (dont have the dvd on my HD at the moment) had the (1:1)(1:2) pattern. The video Hat.m2v has similar problems. I didn't upload the video with the 2: (1:2) because the picture is very poor and I didn't want to frustrate your analysis.
And the Bus.m2v would be nice to IVTC, but again might not be feasible.

I posted a complicated dvd 2 weeks ago, but didn't get any replies. Dont suppose you have an idea about that one?
https://forum.videohelp.com/threads/322943-need-help-with-basic-IVTC-problem

[jagabo]

bus.m2v looks like a pretty straight forward PAL to NTSC conversion with blended fields. Yadif().SRestore() did a pretty good job with that:

MPEG2Source("bus.d2v", CPU=2)
Yadif(mode=1, order=1)
SRestore()

Work.avi had a huge temporal filter added while interlaced. Each frame/field is a blend of several. It's pretty hopeless but the above script did improve it some.

Hatful.m2v is the same as the first.

[spiritgumm]

thank you, Jagabo. The script looks good for Hatful. As I dont know it's original source, it could have been Pal TV. This would explain why the runtime is 4% short, and voices slightly higher pitched. When I add "assumefps(23.976, true)" after your script, the the pitch and runtime are corrected. Is that what I should do, or can your existing script be altered to do this?

When I tried the script with Work.avi, the bartender leaving at the end looked alittle choppy, and bus.m2v had a certain hesitancy (noticeable in the ceiling fan, and later). I'm pretty sure these were never PAL, and I'd like to get them as 23.976, too.

[jagabo]

You can try changing SRestore() to SRestore(frate=23.976) for the different clips and see if that's any smoother. The fan shot was smoother. But this technique is never perfect so try it on a variety of shots for each source.

[spiritgumm]

thanks again , the addition of Frate worked great in the Bus.m2v clip. I'll verify with a few more samples. Since there isn't any combing, the resize to 640x480 looks about the same as the 512x384 I tried earlier.
Motion in Work.avi is still choppy, so I'll leave it be.

So if I want to slow down Hatful.m2v from Pal to Ntsc, adding assumefps(23.976) below your script is the recommended fix? Inserting frate doesn't appear to slow it down.

[jagabo]

So if I want to slow down Hatful.m2v from Pal to Ntsc, adding assumefps(23.976) below your script is the recommended fix? Inserting frate doesn't appear to slow it down.

Yes, use AssumeFPS() to slow the video down.

[spiritgumm]

jagabo, inre the "hatful" video, I haven't done widescreen xvid before, and I've gotten some complaints about this one because the image is alittle squat (squished). On TV playback, when I compare the dvdr video (zoom in the letterbox) to the cropped Xvid, the dvdr looks normal, but the Xivd is squished. Screengrabs of the xvid also look squished.
The original video is 704x480. When I crop all the black borders with crop(0,90,-2,-94), the result is 702x296, (technically that's 2.37:1), and I resize to 640x272 (2.35:1) for xvid. The proportions seem to be the same when I preview before/after in AvsP.
Xvid encoder (in Vdubmod) to set to "square pixel." I also tried the 16x9 setting, but no change in results.

The dvdr video appears to be Ntsc, but you said it was originally Pal - is it possible the pixel size is still Pal and this is causing an issue? I realize this probably doesn't make sense because the dvdr video looks normal on TV.

[jagabo]

hatful.m2v is a 4:3 NTSC MPEG file (the movie appears to be ~2.2:1 DAR). You can resize to a 4:3 frame size, crop away the black borders, and encode square pixel. Or you can crop away the black borders and set the PAR to 10:11, or DAR to 2.2:1. Note that not all players will respect PAR/DAR flags, so the first option is safer.

[manono]

When I crop all the black borders with crop(0,90,-2,-94), the result is 702x296, (technically that's 2.37:1)

First, cropping like that leaves black both above and below. It should be:

Crop(0,92,-2,-96)

And even with that it's not 2.37:1. You're assuming square pixels, and this is 4:3. The people that complained were absolutely right. As jagabo says, the ratio is 2.20:1, roughly. 704x320, 672x304, 648x296 (if you use Mod8), 632x288 (Mod8 again), resolutions like that.

The dvdr video appears to be Ntsc, but you said it was originally Pal - is it possible the pixel size is still Pal and this is causing an issue?

Unless you see evidence to the contrary (an oval shaped moon, for example), and I see none, you have to assume the correct aspect ratio was maintained. So, no, the PAL origins of the DVD have nothing to do with the aspect ratio now.

[spiritgumm]

jagabo, I understand the dvd is Ntsc now. I thought you were saying (or implied) it had been converted from Pal (in 4th post, that it was like the bus.m2v video). I only mentioned it now in case somehow it's original Pal pixel size was the issue (and isn't, as manono explained).
Searching thru the threads for Dar, Par (many of which you advised), looks like I should resize to 720x540 before cropping.

manono, thank you for clarifying about the Pal pixel size. Glad you agree with me (and the people that complained) that the video height was squished.

[jagabo]

720x540, 640x480, any 4:3 frame size. DVDs are always either 4:3 or 16:9 DAR so you can always resize to one of those ratios and then crop. Also keep in mind that MPEG family codecs are happiest with mod 16 or mod 8 frame sizes.

[spiritgumm]

I did a sample, looks okay. Still a tad shorter in comparison, but looks about the same when zoomed in on TV.

I researched but didn't find the answers, so I'll just ask (this is all regarding dvd-to-xvid):
For fullscreen dvd-to-xvid, I've been cropping black (and whatever crappy edge stuff) off, then resizing to 640x480 (or 512x384). Should I have been resizing first?
If so, the cropped picture isn't always a multiple of 4. Would I resize again?

There's an old Avisynth guide (on videohelp) for dvd-to-xvid which says letterbox should be cropped first, resized later. The guide has been commented on over the years, but I didnt see any critique of that advice. So is that incorrect? Or are certain videos like mine the exception?

I got the idea that the "hatful" movie was (or should be) 2.35:1 from IMDB.
If the video looks normal now and is 2.2:1, then I guess it doesn't matter what IMDB says, and I go by the dvd's dar. I guess if the video looked odd, reading the AR on IMDB might help in correcting it. Is this the best way to look at the situation?

Speaking of which, I have another movie that's fullscreen but needs some cropping all around. IMDB claims it should be 1.37:1. Since that's close to what the dvd is, it's difficult to eyeball any difference. My question is whether I should resize to get that AR (and again, before or after cropping?).

[jagabo]

It's always possible the DVD was made wrong and the movie should be 2.35:1. Or that the movie was slightly cropped at the sides to make it 2.2. Look for something that should be round (a ball, a car tire viewed directly from the side, a clock face, etc.) and measure it. The fact that it was 704x480 makes me think it's not a commercial DVD. A laserdisc cap maybe?

Regarding 4:3 stuff, the difference between cropping and resizing to 4:3 vs. resizing to 4:3 and cropping is probably negligible.

[manono]

The film could have been 2.35:1 in the theaters but the DVD makers could have cropped from the sides to make a 2.20:1 ratio DVD. Happens all the time. Given that they couldn't even make a proper NTSC master for the DVD, you know these aren't people whose work you can respect. Assuming they didn't wreck the aspect ratio (and I've seen plenty where it was compromised), you don't take the AR from IMDB or the DVD case or any other external source. You take it from the DVD and resize it to what it's supposed to be.

As for cropping first or resizing first, I always crop first, then followed by the resize.

[spiritgumm]

It's a home recording from broadcast TV (I assume it's still safe to mention a source and not get deleted here). I didnt make the recording.
It sounds like resize/cropping order actually don't matter too much, whether the movie is 4:3 full or letterbox, correct?
If so, did I screw up the movie by the particular size (640x272) I used for resizing after cropping the letterbox?
Btw, reason I left some pixels on top/bottom because at that time, I thought the movie was suppose to be 2.35:1, and cropping less would lean more in that direction (I know, I also wasn't taking into account the Ntsc 4:3 pixel size).

And if I want to find out the existing movie's correct AR, I crop out all the black and eyeball it for correct proportions (something round), rather than rely on outside info?

[jagabo]

What you can do is determine the right frame size first by resizing, then cropping. The remaining size will tell you the final aspect ratio (assuming there is no error on the DVD). Round width and height to mod 4 (not recommended but usually ok), mod 8, or mod 16 sizes. For the actual encoding crop first then resize to that size.

[spiritgumm]

So for diagnosing my letterbox video (assuming it's AR is correct as is), I resize to 640x480, crop off black down to 638x292 which is a ratio about 2.17. Round that to nearest standard AR which is 2.2. Pick one of the mod8, 2.2:1 resize options manono listed above (probably 648 x 296). Rewrite my script to crop followed by that resize.
Thank you, guys.

Stupid question about Vdubmod xvid settings - after encoding, if I happen to open the new xvid in Avidemux, it tells me the index needs to be updated and re-written. Is this necessary? Is there a Vdubmod setting to eliminate the need for a new index? I've already un-ticked the "packed bitstream" option in Vdubmod xvid encoder because it seemed to make for choppy playback in my dvd player.

[jagabo]

So for diagnosing my letterbox video (assuming it's AR is correct as is), I resize to 640x480, crop off black down to 638x292 which is a ratio about 2.17. Round that to nearest standard AR which is 2.2.

I wouldn't bother with picking a standard AR. Just start with 638x292. The nearest mod 8 size is 640x296. Or mod 16 size, 640x288 or maybe 624x288. You won't notice a 1 or 2 percent error in AR.

Stupid question about Vdubmod xvid settings - after encoding, if I happen to open the new xvid in Avidemux, it tells me the index needs to be updated and re-written. Is this necessary? Is there a Vdubmod setting to eliminate the need for a new index? I've already un-ticked the "packed bitstream" option in Vdubmod xvid encoder because it seemed to make for choppy playback in my dvd player.

I don't know why AviDemux sometimes says that. There's usually nothing wrong with VirtualDub's output.

[spiritgumm]

Thanks again.
The index thing happens every xvid I make in Vdubmod. If I leave the encoder set to "packed bitstream" and load the resulting xvid in Avidemux, I would prompted to unpack it but not usually to update the index.

Separate issue regarding yadif (applied to a different movie). I was testing my script before doing the whole movie (compressing dvd to xvid in Vdubmod). In random samples the audio starts synced, but quickly unsyncs. Original audio is ac3 which I typically compress in Vdubmod to mp3.
I then tried samples without compressing the audio (Vdubmod automatically decompresses the ac3 to PCM), and the clips were synced. I don't mind compressing the audio afterwards. I'm just wondering (before I do the whole movie) if the PCM audio will be synced all the way thru, or if I should deal with it now in my script? If the latter, what would I do?

[poisondeathray]

Vdubmod automatically decompresses the ac3 to PCM

No, actually that's avisynth . If you use an .avs script, it feeds uncompressed audio & video

If you encode with CBR MP3 audio, do you get the sync issues?

What is your avs script ?

[manono]

You can't tell from just playing a script whether or not the audio is synched, especially if playing it using VDubMod. Are you getting out-of-synch audio after doing the encoding and playing the resulting AVI? As long as the video stays the same length, I know of no reason for the audio to become unsynched. And I work with XviD and VBR MP3 all the time. Never had the problem. But then I also use BeSweet on the audio rather than doing it through VDub.

[spiritgumm]

oh, right, I forgot avisynth does the decompressing.

To clarify, my tests are done by loading my script in Vdubmod, setting audio compresson for CBR mp3, selecting a portion of the video and encoding. I also loaded the script with the added line to trim it into a short clip (rather than selecting the clip in Vdubmod), with same results. Audio starts synced, then drifts off. If I dont compress the audio, it stays synced.

I've only had a sync issue couple times before (I dont recall the script). I think that got solved either by encoding with Vdub Mp3 Freeze, or by adding "EnsureVBRMP3sync()" to the script. I tried Vdub Mp3 Freeze for this but didn't work. Didn't try Ensure because of the demuxing/converting to get the mp3 file, etc, and it would be easier just to use the PCM audio (assuming it stays synced).

I don't usually use yadif so maybe I'm not using it correctly. It's in-sync if I delete the group of yadif/restore/assumefps lines. De-syncing happens after them (I encoded samples), so it's not the later imaging filters. For brevity, I'm just posting the script to that point, but I can post the full script if wanted.

LoadCplugin("C:\Program Files\AviSynth 2.5\plugins\yadif.dll")
video=MPEG2Source("C:\Documents and Settings\Desktop\moon\VTS_01_1.d2v", cpu=0)
audio=nicac3source("C:\Documents and Settings\Desktop\moon\VTS_01_1 T80 2_0ch 256Kbps DELAY -29ms.ac3")
AudioDub(video, audio).DelayAudio(-0.029)

Yadif(mode=1, order=1)
SRestore()
assumefps(23.976, true)

[poisondeathray]

But if you use no audio compression (PCM) , the exact same script with exact same cuts in vdubmod (or using trim() ) works without sync issues? This doesn't make sense. I could expect sync problems if you were using something like DirectShowSource() and using cuts, but this should work . What mp3 encoder are you using (lame acm ? what version?)

[spiritgumm]

It is Lame Mp3 lameACM-3.98.4.zip. Actually you helped me that before.
https://forum.videohelp.com/threads/322043-how-to-get-audio-video-AVI-from-Avisynth

I just encoded a sample from the other movie I've been discussing here (hatful.m2v) because that script also uses yadif. Same sync problem -- but I didn't have an audio problem when I used that script a couple weeks ago.

[poisondeathray]

but I didn't have an audio problem when I used that script a couple weeks ago

So it worked before, but now it doesn't ? Were you using the same version of lame before ?

Maybe go back to an older lame version ?

What has changed in those few weeks? Did you install any codecs or codec packs, things like that ?

[poisondeathray]

A quick search shows 3.98.3 and maybe 3.98.4 have problems on some xp systems , and that 3.98.2 is stable . I just checked and that appears to be the one I have installed . You could try and see if it makes a difference

Everything you've said suggests that it's a problem with lame

Alternatively you can do the audio separately in another application

[spiritgumm]

I reinstalled the Lame I had (didn't help), and then the earlier version which didn't help. The other day, I installed/uninstalled a video program which had shared plugins with other "unused" programs, so maybe it happened then. I haven't noticed any sync problems with other xvids I've made lately, though. I just hope the PCM actually stays synced.

[spiritgumm]

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?
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.