Basic resize to DVD

[dahlany]

Hello forum, I have a very basic resize question. I hope I am posting in the right place.

I want to resize 640 x 480 clip, keeping the aspect ratio intact,
to 720 x 480. I can add borders to the left and right, but these black borders on the sides doesn't seem right.

Is there a way to resize this standard size to standard dvd size that fits the whole width and still keeps the aspect ratio?

[Zwitterion]

Spline36Resize(720,492)
Crop(0,6,-0,-6)
...is the correct way according to ITU-R BT.601.

You could also resize just like this:
Spline36Resize(720,480)
This will however result in a slight AR error on ITU-R BT.601 compliant playback devices (most standalones I guess). PC playback should be without AR error as DVD playback software usually doesn't resize according to ITU-R BT.601.

[dahlany]

Thanks for your help.

I have not used Spline36Resize before because there is no description about what it does.

How is it different than doing a basic BicubicResize(720,480) or Lanczos4Resize (720,480)?
In your first example, is some of picture getting cropped out, or is this specific to the way Spline36Resize works?

[Zwitterion]

I have not used Spline36Resize before because there is no description about what it does.

How is it different than doing a basic BicubicResize(720,480) or Lanczos4Resize (720,480)?
http://avisynth.org/mediawiki/Resize
The spline based resizers are sharper and more accurate than the bilinear and bicubic ones. They are about as sharp as lanczos but with less ringing.

In your first example, is some of picture getting cropped out, or is this specific to the way Spline36Resize works?
This has nothing to do with Spline36Resize.
If you want to utilize the whole width, you have two choices: either resize to 720x492 and crop a little bit from the top and the bottom, or resize to 720x480 and accept the slight AR error.

For all the gory details visit here:
http://lipas.uwasa.fi/~f76998/video/conversion/

[Gavino]

Crop(0,6,-0,-6)
Why do people write it like this? (not just you, I see it all over the place)

Don't they realise -0 = 0, and the minus is redundant?
Or is it just to remind themselves that it's relative to the edge ('self-documenting' code)?

[smok3]

i would either;

a. resize to 720x480
or
b. resize to 704x480 + pad to 720

LanczosResize(704,480) # (mod16)
AddBorders(8,0,8,0) # pad width 720

ignoring the slight AR error, this will give you better quality and some speed, since you don't have to resize one axis.

[Didée]

Why do people write it like this? (not just you, I see it all over the place)

Don't they realise -0 = 0, and the minus is redundant?
Or is it just to remind themselves that it's relative to the edge ('self-documenting' code)?
Me, I just like it so. :)

(Mainly for the symmetry, but also for less typing when switching between zero and non-zero cropping during scripting.)

[Guest]

Why do people write it like this? (not just you, I see it all over the place)

Don't they realise -0 = 0, and the minus is redundant?
Or is it just to remind themselves that it's relative to the edge ('self-documenting' code)? Because the Avisynth documentation doesn't offer that as an option. It shows both positive and both negative, and says:

"If a negative value is entered in the width and height these are also treated as offsets."

[Gavino]

Avisynth documentation ...:
"If a negative value is entered in the width and height these are also treated as offsets."
I guess it ought to say "if a negative or zero value ..."

I was just curious to know whether many people imagined that somehow the filter could tell the difference between -0 and 0.

[Guest]

I was just curious to know whether many people imagined that somehow the filter could tell the difference between -0 and 0. If they think it is parsed as a string, then yes. You'd have to know Avisynth internals to know whether the argument can be parsed as a string. I think people just follow the instructions, without imagining things.

[2Bdecided]

b. resize to 704x480 + pad to 720

LanczosResize(704,480) # (mod16)
AddBorders(8,0,8,0) # pad width 720No need to pad. No need to add borders. (I'm sure you know this better than me?!)

A simple resize to 704x480 is all that's required, and the aspect ratio "error" in this case is zero.

http://forum.doom9.org/showthread.php?p=1100187#post1100187

Cheers,
David.

[smok3]

2Bdecided; the op question was specifically set to width 720, so my suggestion is to ignore any slight errors for the sake of not needing to resize one axis.

actually my calc says that 720 version gives error 0;
http://resizecalc.somestuff.org/index.php?ssmw=640&sar=1&sar2=&ssmh=480&CT=&CL=&CR=&CB=&trw=720&dar=0.888889&dar2=&mod=&padw=&padh=&css=&doit=true

but iam not 100% sure if that is correct (and honestly i can't be bothered to go throught the entire theory again...)

[2Bdecided]

2Bdecided; the op question was specifically set to width 720I know, but he doesn't really know what he's asking. 704 is clearly better in this case, given his last sentence.

actually my calc says that 720 version gives error 0;
http://resizecalc.somestuff.org/index.php?ssmw=640&sar=1&sar2=&ssmh=480&CT=&CL=&CR=&CB=&trw=720&dar=0.888889&dar2=&mod=&padw=&padh=&css=&doit=true

but iam not 100% sure if that is correct (and honestly i can't be bothered to go throught the entire theory again...)You have a different PAR for 4x3 at 720 vs 704. That's how some PC software (incorrectly IMO) plays back DVDs. It's not how stand-alone DVD players play back DVDs, and it's not ITU Rec.601 compliant. The pixel aspect ratio is the same, whether you have 704 or 720 pixels. 720 pixels = more picture, not thinner pixels.

Cheers,
David.

[fibbingbear]

I've been following this thread and just want to make sure I understand....

640x480 is 4:3, assuming a PAR of 1:1

The video should be encoded to 704:480 (or 720:480), and some flag set somewhere to indicate SAR of 4:3, so whether on TV or PC, it'll have the right aspect ratio.

So why stretch to ~720x480? Why not let the DVD player do that? Is it required when you burn a DVD that the video be ~720pixels wide?

[Brother John]

With generic PAR it’s very simple: Resize 640×480 -> 720×480 and you’re done. PAR is 8/9 in this case.

With ITU-R BT.601 it’s a little more complicated. Exact ITU PAR for NTSC 4:3 is 4320/4739. That means new width needs to be
640 * 4739/4320 = 702.074
So the »as close as you can possibly get« ITU solution would be to resize to 702×480 and add a 1 pixel border left and right to get to 704×480 which is a valid NTSC DVD resolution. (You could go to 720×480 by adding additional borders. Doesn’t make sense though.)

Unfortunately resizing to a non-mod4 width in YV12 color space is not possible with current AviSynth. And adding non-mod2 borders isn’t the best thing you can do to YV12 either. I recommend to accept the minimal aspect error and do as 2Bdecided said: resize directly to 704×480. The error is much too small to justify any lossy conversions/interpolations that would be necessary otherwise.

[dahlany]

ok, it seems that a simple resize to 704x480 will keep the aspect ratio and is still NTSC DVD compliant.

This may be slightly off track, but it came from http://lipas.uwasa.fi/~f76998/video/conversion/
When a 720x480 dvd is played on a standalone, there is always some pixels getting cutting off,
whereas when a 704x480 is played, the centered clip takes up the full display. Is this correct?

In this case, do standalone players ever display some anomalies on the left or right side due
to some missing pixels that should be there?



Is it correct in saying that resizing a 640x480 directly to 720x480 will be close to, maybe even imperceivable,
but will not be keeping the original aspect ratio? This is in reference to following mistakes in the past I may have been making.

I think I may have misinterpreted the instructions that
xxxResize(720, 480, 0, 0, 320, 240)
would auto-resize the 320x240 clip to 720x480, keeping the same aspect ratio.

When viewing this on a standalone player, it looks correct, and does not appear to be "fat",
although it may actually be.

However, after doing a simple A-B comparison, on the computer between a direct resize (720x480) and
a (720, 480, 0, 0, 320, 240), they appear to be exactly the same.
I am not sure now what (720, 480, 0, 0, 320, 240) is doing,
but it seems to do a simple resize to 720x480.

[Gavino]

However, after doing a simple A-B comparison, on the computer between a direct resize (720x480) and
a (720, 480, 0, 0, 320, 240), they appear to be exactly the same.
I am not sure now what (720, 480, 0, 0, 320, 240) is doing,
but it seems to do a simple resize to 720x480.
That's right (assuming you are starting with a 320x240 clip).

The extra parameters (http://avisynth.org/mediawiki/BicubicResize) simply crop out a subframe of the original before resizing, but if you ask to crop an area 320x240 you will get the whole clip anyway, the same as without the extra parameters.

[smok3]

720 pixels = more picture, not thinner pixels.
will let you thinker with that one, like i said i reread the theory enough times allready :)

[dahlany]

I know, but he doesn't really know what he's asking. 704 is clearly better in this case, given his last sentence.

I think this is a correct statement. I seemed to assumed incorrectly that a standard ntsc dvd must be
encoded at 720x480 to be compliant.



I think a have a grasp now, but to make sure...

Is it safe to say that to make a standard ntsc dvd, that all of
the following will resize a 640x480 clip, and maintain the orginal aspect ratio, and the results played on
a standalone will look basically the same?

resize directly to (720x480)
resize directly to (704x480)
BicubicResize(720, 480, 0, 0, 640, 480)


And more of an avisynth question, the last example being more useful if
the resolution is something other than 640x480 (or 320x240)?

[manono]

And more of an avisynth question, the last example being more useful ifthe resolution is something other than 640x480 (or 320x240)?
The last example is useless any time there's no cropping to be done.

Wanna make it easy on yourself? Use FitCD to find the crop/resize/addborders lines for your scripts. It's up to you whether or not to use ITU resizing. I usually do.
This may be slightly off track, but it came from http://lipas.uwasa.fi/~f76998/video/conversion/
When a 720x480 dvd is played on a standalone, there is always some pixels getting cutting off,
whereas when a 704x480 is played, the centered clip takes up the full display. Is this correct?
No. Overscan is overscan. It'll cut off pixels whatever the resolution. Even some DVD players crop a video. I didn't read the article, but maybe he's talking about 704x480 of active video with 8 pixels of black added to both the right and left sides to make the actual resolution 720x480. Then what gets lost will be mostly the black. Some people like to add black borders around their videos to account for the overscan. FitCD can help with that if you wish. Personally, unless there are hardcoded subs that might get partially lost to the overscan, I think it's a bad idea.

[smok3]

yes, black pixels are probably bad idea today, because there is a big chance that:

a. video will be played on pc
b. video will be played on plasma/lcd tv

[2Bdecided]

This may be slightly off track, but it came from http://lipas.uwasa.fi/~f76998/video/conversion/
When a 720x480 dvd is played on a standalone, there is always some pixels getting cutting off,
whereas when a 704x480 is played, the centered clip takes up the full display. Is this correct?No. Overscan is overscan. It'll cut off pixels whatever the resolution.720 vs 704 has nothing to do with overscan.

On an analogue output, the active line (the part that conventionally represents picture data) is equivalent to about 704 pixels (exactly 702 for "PAL"; it's a bit more complex for NTSC). Most chips don't let pixels beyond this limit get output on the analogue video signal - they add a short fade down to black/blank. There is space for these extra pixels in the analogue signal, but it's non-standard to put picture into this space: they would be "too" close to the colour burst at the start of the line and the sync pulse at the end of the line.

Stand alone DVD players don't care about overscan - they send the full active area to the display device - it's the display which puts the edges of the original image "beyond" the edges of the target display, thus losing some picture information.

Cheers,
David.

[2Bdecided]

yes, black pixels are probably bad idea today, because there is a big chance that:

a. video will be played on pc
b. video will be played on plasma/lcd tvAlmost all plasma/LCD TVs still overscan, especially on SD inputs, so you won't see the black.

I agree it's a slight nuisance on PCs though - especially if the edge is ragged or noisy, or even just soft.

Cheers,
David.

[manono]

720 vs 704 has nothing to do with overscan.
Meaning what? That overscan can still cut into the active video of a 704 width DVD, right? Isn't overscan what dahlany is talking about in his previous post? He seems to be asking if a 704 width DVD will show the full 704 pixel width and I answered it wouldn't necessarily, depending on the overscan of the set. Or maybe I misunderstood him. Or maybe I misunderstood you.
Stand alone DVD players don't care about overscan - they send the full active area to the display device
Quite a few DVD players crop the image before sending it on to the TV set. We find this in a review of the very popular but very bad Philips DVP-642 progressive scan DVD player:
But unfortunately, the player has a low white level of 97 IRE, fails below black, has some excessive pixel cropping (5 on each side), and is a bit too rolled off in the upper frequency range.
http://www.hometheaterhifi.com/cgi-bin/shootout.cgi?function=search&articles=all#PhilipsDVP-642

And as near as I can tell, my Sony LCD HDTV doesn't overscan at all.

[smok3]

imho
a. ok, so overscan is basically from analog domain, so using pixels as measurement is moot, better % imho.
b. there is something called safe action area and safe title area, this terms were in used for SD video production at least, i don't think that is standardized in HD yet and we will have problems with that (especially if you think HD has to be compatible with SD at some point/and at least for few years...)

[2Bdecided]

And as near as I can tell, my Sony LCD HDTV doesn't overscan at all.Have you tested that? If it's true for SD interlaced, then you must see all kinds of rubbish that's not meant to be seen - broadcasters aren't always very careful, and a transfer from VHS would look terrible at the bottom.

Some recent 1920x1080 panels have a 1:1 pixel mode, with no overscan for HD, but even that isn't selected by default, and the manual warns users that selecting this mean the edges of the picture aren't clean.


Regarding 704 vs 720 vs overscan - sorry, yes you were right of course - overscan cuts into both. I jumped in because I thought you were saying that the 8 extra pixels were the overscan - but that's not what you said at all. My apologies.

I didn't know some players didn't even get all 704 out. Sometimes they smooth the transitions to avoid ringing, but I didn't know they could lose several pixels entirely from 704.

Cheers,
David.

[manono]

Have you tested that? If it's true for SD interlaced, then you must see all kinds of rubbish that's not meant to be seen - broadcasters aren't always very careful, and a transfer from VHS would look terrible at the bottom.
I haven't done any formal tests, like with the pictures and all, but it's because of stuff like DVD transfers from VHS tapes (and also unblending with the likes of RePAL and other such filters which often leave behind a single flickering row of pixels on the top or bottom) that I discovered this. I can see that single flickering row on the top and bottom. It's not one of those TVs available now with the non-overscan mode. Broadcast television is fine, and it's because of what I've read about garbage at the edges that I think I'm "normal" there. I'm referring specifically to DVDs. I should have qualified my response before.

[2Bdecided]

In my tests, I found you often get different amounts of overscan with composite/S-video, component interlaced, and component progressive connections. You get none if you connect via VGA.

I only tested 15 new TVs, but they were from as many different manufacturers as I could find (6-7 I think - basically an LCD and a Plasma from each, plus a DLP), and I used an appropriate test card. Having no overscan was certainly not "normal" - though it was down to only one or two lines on component progressive (480p) sources on some TVs. It was similar to CRTs (5-10%) on all the composite inputs.

Cheers,
David.

[manono]

Maybe you should check using a digital hookup. That's another thing I guess I should have mentioned; the fact that the DVD player (an Oppo) is connected to the TV with an HDMI cable. The TV's nothing special; it's a Sony Bravia 46" LCD bought at Costco just before Christmas. It's not from the expensive Bravia series with the 120Hz refresh rate, just a standard Bravia. As you can tell, I'm far from an expert on this subject. Heck, I don't even know the lingo ("test card" and not "pictures and all"). :) But sometimes I forget to crop away that one flickering row of pixels, and I see it on the TV as well as the computer moniter. I have no idea what's going on at the left and right sides, only the top and bottom. Most of my DVD viewing these days is of the 4:3 variety. None of my testing is thorough, more like observations, and I'll happily bow to your more professional testing.

[2Bdecided]

I didn't test HDMI/DVI. I'm sure that would make a difference.

It seems good practice to make sure that nothing in the supplied picture area (704 or 720) is objectionable in case it is seen, but also to ensure that it's won't be missed in case it isn't seen. Most broadcasters stick to this most of the time, but not all.

Cheers,
David.