704 vs 720, why crop?

[dphirschler]

OK, I see enough posting about this. I might as well ask...

I understand that I can make a DVD compliant video with 704x480. I've been doing it for quite some time. But I see people recommending that to make a 704 clip, I must crop 8 pixels off the sides first. Here is an example.

https://www.videohelp.com/forum/viewtopic.php?p=1006956#1006956

I'll go ahead an admit, I totally don't understand why. I've seen conflicting advice on this site through the years, so I just want to know once and for all what is the correct answer?

Source: 720x480. What do I do?

a) crop 8 from the sides and encode at 704x480,

b) crop 8 from the sides, pad it with black, then encode at 704x480,

c) resize to 704x480, then encode at 704x480, or

d) none of the above?


What if my source is 640x480? What if I captured it at 704x480? FulciLives, I've seen you chime in on this before. What is your opinion? I always thought the correct answer was 'C'. Is it different depending on whether I capture the video or rip a DVD?


Darryl

[indolikaa]

This issue has always confused me. I can never get a clear enough head to figure it out.

An excellent question. I hope someone can answer it.

[petar]

d.
It's a DVD compliant resolution already. I can't think of a single reason why you'd want to resize it to 704x480. Where did you read that you should resize?

However if your source is 640x480 then it's better to resize to 704x480.

[BSR]

I can't think of a single reason why you'd want to resize it to 704x480..

My captures have some black bars and distortions on the sides from capturing the overscan. This would be a case where I would want to cut sides off or black them out so I don't waste bitrate on that junk.

Wonder if just cropping 16 total from the sides and not add borders to make it 720 again would distort the image slightly?

[lordsmurf]

For reasons of maintaining correct aspect ratio, not all software and hardware will properly resize video.

For example, the ATI AIW cards I have are 704 native, and therefore 352 is perfect.

But not all cards are like this.

Not all software will convert 720 to 352x and stay true to aspect.

This is why. Another price to pay for having lower quality hardware/software.

BSR, what you just described is improper usage and likely results in a aspect ratio error.

[petar]

I can't think of a single reason why you'd want to resize it to 704x480..

My captures have some black bars and distortions on the sides from capturing the overscan. This would be a case where I would want to cut sides off or black them out so I don't waste bitrate on that junk.

That's fine. But that doesn't mean you need to resize. Mask the overscan and that's it. If you cut the overscan you'll loose the edges on a TV screen, regardless whether you resize or not (and if you resize you'll distore the aspect ratio as lordsmurf mentioned).

[dphirschler]

For reasons of maintaining correct aspect ratio, not all software and hardware will properly resize video.

For example, the ATI AIW cards I have are 704 native, and therefore 352 is perfect.

But not all cards are like this.

Not all software will convert 720 to 352x and stay true to aspect.

Smurf, I am still confused. Will not the video (whether it be 352, 704, or 720) still be shown on the TV at 4x3 ratio? It shouldn't matter what software resized it; the apsect ratio should be correct as long as the whole picture fills the frame. Are you saying that the aspect ratio gets screwed upon capture (depending on the capture card)?


Darryl

[lordsmurf]

For reasons of maintaining correct aspect ratio, not all software and hardware will properly resize video.

For example, the ATI AIW cards I have are 704 native, and therefore 352 is perfect.

But not all cards are like this.

Not all software will convert 720 to 352x and stay true to aspect.

Smurf, I am still confused. Will not the video (whether it be 352, 704, or 720) still be shown on the TV at 4x3 ratio? It shouldn't matter what software resized it; the apsect ratio should be correct as long as the whole picture fills the frame. Are you saying that the aspect ratio gets screwed upon capture (depending on the capture card)?


Darryl

Yes. It can be. You see this often on BT8x8 cards.

[petar]

Will not the video (whether it be 352, 704, or 720) still be shown on the TV at 4x3 ratio?

Yes. Resolution and aspect ratio are independant in the MPEG world.

Darryl, if you must must resize 720x480 to 704x480 (though as I mentioned before, I can't see why - how much bitrate will you save? And you'll affect the quality because of the resize) just go ahead with your option c) - no need to crop, pad or anything. If the original 720x480 source had an aspect ratio of 4:3 (or 16:9) and you flag the output MPEG stream as 4:3 (or 16:9 respectively), the output can be any DVD compliant resolution, it will play just fine.

[Alan69]

Will not the video (whether it be 352, 704, or 720) still be shown on the TV at 4x3 ratio?

Yes. Resolution and aspect ratio are independant in the MPEG world.

Darryl, if you must must resize 720x480 to 704x480 (though as I mentioned before, I can't see why - how much bitrate will you save? And you'll affect the quality because of the resize)

The purpose is not for bitrate, the general reasoning for this is to cut the video down so exactly 2 pixels get merged into one for 352.

The real question is does the DVD spec say for 720 to be exactly the same width as 704, or is it ok to just chop. Regardless of what the spec says, you can bet there are machines that simply show 720 as 16 high-res pixels wider than 704 and 352 width for simplicity. In such a case the only way to keep things exactly correct is simply discard 8 pixels on each side for 704, then convert to 352. But then that messes it up slightly for machines that resize.

But the percentage aspect change would be tiny anyway. The real thought is that an optimized conversion of 704 to 352 should be 50% plus faster than 720 to 352. 704 only has to blindly merge 2 pixels for each target pixel, 720 has to look at 3 with shifting percentages. Actually should be twice as fast or more without the weighting calculations, but that is assuming the 704 conversion is properly optimized and not using the same generic formula that the 720 conversion uses.

For sure if I did it myself in assembly or C the 704 merge would be better than twice as fast without the extra pixel and weighting calculations. So the time of two sample conversions should tell you if a program was well optimized or not. Artifacts shoulld also be slightly less with less calculations to contribute error, but I'm not sure you'd see the difference really it'd be relatively small.

Alan

[petar]

I didn't understand from Darryl's question that he wants to resize to 352.

As an argument for resizing to 352 from 720, I can see some reasoning for cropping to 704 first but it don't think it's a strong argument.

First you'll be distorting the aspect ratio and loosing part of the picture (not much though).

Second, it will depend on the resizing algorithm used. To algorithms that use resampling (like bi-linear which is considered one of the better ones for downsizing) it won't make much difference. There's no one-to-one relation between the input and the output when resampling (the new image is completly different from the old one). Speedwise, you'll gain some time but that's about it.

[Alan69]

I didn't understand from Darryl's question that he wants to resize to 352.

As an argument for resizing to 352 from 720, I can see some reasoning for cropping to 704 first but it don't think it's a strong argument.

First you'll be distorting the aspect ratio and loosing part of the picture (not much though).

Second, it will depend on the resizing algorithm used. To algorithms that use resampling (like bi-linear which is considered one of the better ones for downsizing) it won't make much difference. There's no one-to-one relation between the input and the output when resampling (the new image is completly different from the old one). Speedwise, you'll gain some time but that's about it.

No good reason to resize from 720 to 704 without being for dropping to 352, didn't even check his post for actually having 352. Knew offhand that was the reason behind the original mentioned thread.

Whether it distorts aspect or not depends entirely on how the DVD alliance says to do 720 vs 704 pixels, have you read the DVD spec fully enough to be certain? I haven't really looked on that part yet. Also, no matter what they say, some DVD players will do it the other way, so it really depends on what your player does. Still a moot point since he shouldn't be doing anything anyway.

Any merge that uses anything other than those 2 pixels into one for a 704>352 is also a blur of some type, not just a resample. The edges of 2 704 pixels align perfectly with the 352 edges, anything looked at across those edges for a pixel's value will degrade the picture in one direction or another. May have an apparent gain for one factor or another, but the overall image will drop.

And if this is the case: "There's no one-to-one relation between the input and the output when resampling (the new image is completly different from the old one)"

Then how would you explain the two images looking almost precisely the same if they're completely different? And it's an exact 2:1 relation not 1:1 for this case. Bi-linear just means 2 linear, it does it linear on X and Y. But it also blurs the image, not just resizes it. It can produce a better looking result in some cases, but it is altering the image not just resizing it.

Alan

[petar]

Whether it distorts aspect or not depends entirely on how the DVD alliance says to do 720 vs 704 pixels, have you read the DVD spec fully enough to be certain?

No, neither fully nor in any part. If I have, I wouldn't be able to discuss them with you (you have to sign a non-disclosure agreement to obtain them). My knowledge is based on readings from web sites that I know are members of the DVD forum (so I'd expect the information to be accurate) and on personal experience (so don't trust everything I say ).

I wouldn't be surprised if some players do what you're saying. But on a PC screen, it will certainly distort the aspect ratio.

And if this is the case: "There's no one-to-one relation between the input and the output when resampling (the new image is completly different from the old one)"

Then how would you explain the two images looking almost precisely the same if they're completely different? And it's an exact 2:1 relation not 1:1 for this case. Bi-linear just means 2 linear, it does it linear on X and Y. But it also blurs the image, not just resizes it. It can produce a better looking result in some cases, but it is altering the image not just resizing it.

Yes, you actually explained better what I meant. With resampling, the way it's done is that a new image is, in a way, overlaid over the old one and built from scratch by referencing the old one, i.e. you're tearing down the old image and building a new one. That's what I meant by "there's no one-to-one relation" (maybe I didn't use the best terminology). At the end the new image will always be an alteration of the old one, at larger or smaller degree, depending on the actual image (the compression used) and the resampling algorithm. So whether you're going from 704 to 352 or 720 to 352, won't make big difference.

If you resize 704 to 352 you obviously have an advantage to resize without resampling which is way faster but you have disadvantages, most notable one being on angled lines (where you get what's knows as "stair stepping", nearest neighbour is also prone to this even though it uses resampling). Bi-linear resampling, as you mentioned, has the disadvantage that blurs the image (and also softens it) but should normally give you better quality when downsizing (though this is obviously subjective).

[thor300]

If you have a look at www.avisynth.org/Resize you will find that the recommended way to convert from 720x480 to 352x240 AND keep aspect ratio is:
AviSource("dv.avi").!BilinearResize(352, 240, 8, 0, 704, 480)
...which is same as:
crop(8,0,-8,0)
Reduceby2
...which is same as:
ReduceBy2
Crop(4, 0, 352, 240)
...so its obviously wrong to resize 720 directly to 352, it would **** up the aspect ratio plus it will blur the picture by creating all new frames.

[petar]

No, that's just wrong.

Look, it's very simple. Say your screen is 30 cm wide. You have an image of 720 pixels that full-screen fills 30 cm. Crop 8 pixels from left/right and fill again the 30 cm with 704 pixels - you've distorted the aspect ratio. You can resize all you want afterwards, your aspect ratio is fucked up (as you put it).

If you don't believe me, test it yourself. Make an image of a circle in 640x480 (or any 4:3 resolution you want). Convert it to DV (with Windows Movie Maker, for example). It doesn't matter if it's DV or not, just mentioning DV because in your script it's DV. Now resize to any mpeg compliant resolution you want (352x480 in our scenario but it makes no difference) and encode to mpeg with 4:3 aspect ratio. Play it - exactly the same.
Now crop first 8 pixels left and right and repeat the encoding (resize if you want to 352x480 or not, makes no difference) - your aspect ratio is wrong.

As for bluring the picture, bilinear resize blurs it no matter if you resize 704 to 352 or 720 to 352.

[thor300]

You are talking about computer screens with a 1:1 AR. But ofcourse we trust you more than the guys who developed the most advanced frameserver available? When you mixed in windows moviemaker you didnt exactly strengthen your credibility. Since when could we play DV on DVD players btw? Try it on DVD and test it on your TV, that should be different from your "Microsoft reality".

[lordsmurf]

. But ofcourse we trust you more than the guys who developed the most advanced frameserver available?

Sure. Why not? What makes him any more special than the rest of us? Nothing.

Petar seems to be making sense. Chopping off sides (adjusting SAR -AND- DAR) will corrupt the DAR because you've still go to resize it to 4:3 DAR.

Again, people are confusing SAR and DAR.
When you "cut off" pixels, you adjust DAR too, and that is BAD!
If you just resize the SAR, it'll still have same DAR. That is fine.

The 704->352 resize is best, but if you have 720 source, nothing you can do about this but use a good resizer like lanzcos (instead of bilinear or bicubic) and take your lumps.

This is just simple image work. The same rules apply to digital photography resizing. You prefer a 25-50-75% resize, but if you must do 33-66-etc ... then you just play with the hand you're dealt.

Somebody mentioned stair-stepping. That's a result of pushing source into 720x480 when it was not that resolution beforehand. It also happens with deinterlace.

In photo, a 25-50-75 is awesome using bicubic. You will have quality issues if you take a low res image (720x480 is low res) and run a funny resize on it using bilinear or bicubic ... you need lanzcos. A high res image has pixels to burn, so you can often get away with it. This is really one of the only reasons a super-high MP in digital photo can be useful.

[petar]

You are talking about computer screens with a 1:1 AR. But ofcourse we trust you more than the guys who developed the most advanced frameserver available? When you mixed in windows moviemaker you didnt exactly strengthen your credibility. Since when could we play DV on DVD players btw? Try it on DVD and test it on your TV, that should be different from your "Microsoft reality".

If you read my previous post in full, you'll see that none of your comments make sense. You don't need to use DV, I just mentioned to use DV in the test because in your script you use DV. Also you don't need to use Microsoft's Movie Maker. Use VirtualDub with your favourite DV codec if it makes you feel better. The final ouput for the test is mpeg (which you can author into a DVD). Where did I mention that you should play DV with your DVD player?
I have tried it and tested and that's what I suggest you do too.

I checked the avisynth web site and I see no evidence that the authors of the tool are responsible for the web site content. It's open to anyone to edit the text. It's possible that the script example you posted was put there by someone else rather than the avisynth authors.

Chopping off sides (adjusting SAR -AND- DAR) will corrupt the DAR because you've still go to resize it to 4:3 DAR.

Again, people are confusing SAR and DAR.
When you "cut off" pixels, you adjust DAR too, and that is BAD!
If you just resize the SAR, it'll still have same DAR. That is fine.

The 704->352 resize is best, but if you have 720 source, nothing you can do about this but use a good resizer like lanzcos (instead of bilinear or bicubic) and take your lumps.

That's it. I can't agree more.

[thor300]

Ok, think what you want, but 720 isnt the actual number of visible pixels anyway. 704 and 720 has the same amount of active pixels (i think 702 for PAL, a little more for NTSC. When going to 352 the number of visible pixels is 351 for PAL (in theory, can vary from TV to TV but i assume we want video that is close to correct on all TVs). So 702 for 720 and 704, 351 for 352, and last time i checked 702:2 was 351. So, resizing 720 to 352 without cropping will distort the AR, you will have 8 pixels on each side that shouldnt be there. The 720 resolution just fills out overscan area or what its called.

[lordsmurf]

Ok, think what you want, but 720 isnt the actual number of visible pixels anyway. 704 and 720 has the same amount of active pixels (i think 702 for PAL, a little more for NTSC. When going to 352 the number of visible pixels is 351 for PAL (in theory, can vary from TV to TV but i assume we want video that is close to correct on all TVs). So 702 for 720 and 704, 351 for 352, and last time i checked 702:2 was 351. So, resizing 720 to 352 without cropping will distort the AR, you will have 8 pixels on each side that shouldnt be there. The 720 resolution just fills out overscan area or what its called.

Sorry, now you're confusing overscan with DAR/SAR. That's still not it. Overscan exists on all files at 4:3 played back on a display device that has the overscan "feature". You cannot mix-n-match these terms like this. Each exists in a finite universe. Overscan involves the device. It has ZERO bearing on the SAR or DAR of the video file. These two concepts are not related.

[thor300]

Ok, we try again. 720 pixels will give 702 visible pixels, 704 will give 702 visible (the same, right?) and 352 will give exactly half. So you get the wrong aspect ratio when resizing from 720 to 352. What part of that is it you cant get without starting to row away by posting terminology corrections? And your hardware related overscan "feature", this overscan i mentioned is part of the analogue video standard still (and digital video need to use the same standards to be ITU-R BT.601 compatible). 720 is used because (i just paste from Jukka Aho's Resolution/AR conversion guide):
- 720 pixels are sampled to allow for little deviation from the ideal timing values for blanking and active line lenght in analog signal
- 720 pixels are also sampled to make it sure that the signal-to-be-digitized has had the time to slope back to blanking level at the both ends
- and more, read yourselves at:
http://www.uwasa.fi/%7Ef76998/video/conversion/
The point is still that these 8 extra pixels on the side will not show up on a normal TV, but they will show up when you resize 720 to 352 without crop. In other words the AR is fucked up (I know Petar like that one, so i had to use it once more).
For the rest of your post, its terminology picking and "finite universes" to avoid the fact that you need to crop before resizing 720 DVD to VCD to keep an exact aspect ratio (Lets just call it Petar's Circle so the terms are more correct).

[lordsmurf]

So you get the wrong aspect ratio when resizing from 720 to 352.

No. That is incorrect.

[thor300]

720x480 is NOT 4:3. DVD players will make it a correct 4:3 (except from maybe some noname players).
Smurf, can you explain why it would be more correct to resize 720 to 352?

[lordsmurf]

All video with 4:3 flags does this:


This is the 720x SAR


This is the 704x SAR


This is the 720 SAR cut to 704 SAR, shown here as seen at 4:3 playback


Look how chopping off SAR pixels changes DAR


And no matter your res, the overscan never moves:


Again, overscan is a device trait, has NOTHING to do with video file.

[thor300]

Ok, now i start to see where you got it wrong. I can repeat:
PAL 720 has 702 active pixels
PAL 704 has 702 active pixels

The 704 image will NOT be stretched out to the same as the 720 one. They both have 702 active pixels. Both, 702, active pixels. The DVD player "plays the active pixels".

Lets forget about the "overscan" part now, you are talking about the "TV safe area" i think, and that would be the same for both 704 and 720, OFCOURSE i have to add there.

I will be happy to say it once more: Resize from 720 to 352 will distort the aspect ratio

dphirschler, i second what you said first: FulciLives' opinion on this (A B C or D)
And i hope someone will read your link, so i second that too:
https://www.videohelp.com/forum/viewtopic.php?p=1006956#1006956

[lordsmurf]

I will be happy to say it once more: Resize from 720 to 352 will distort the aspect ratio

No. It won't. You're still confusing SAR and DAR.

[petar]

thor300,
Now you are completly mixing things up. Everything you mention/quoted is true but it does not apply to MPEG/DVD (nor to any other modern digital system). DVD supports both 704 and 720-pixel wide images and it does not distingush between aspect ratios of the two. All those 704/720 are active pixels. All will be visible on a PC screen but part will be cut on a TV screen due to the overscan.
However, because of these old limitations you mentioned some players may not display the whole 720 but just the 704-pixel wide area in the centre. This has nothing to do with the creation of the DVD (where you can use 720 or 704 active pixels). I think this is what confuses you and many other. Even though these players will display only 704 pixels, they'll be centred so the aspect ratio is the same as if they'd display 720 (imagine as if you'd mask 8 pixels left and right). Since TV has overscan you won't care anyway.

Look, we can go on and on all night. Why don't you do us a favour - take any mpeg stream you have on your pc in 720x576 (you say you're in Norway, so that would be PAL), resize it to 352x576 maintaining the same aspect ratio (4:3 if the source is 4:3, 16:9 if the source is 16:9) and play it. You'll see. Magically the aspect ratio will be maintained .

[thor300]

Something is confusing, but i dont think a "I know SAR and DAR" crusade will solve it.
The European Broadcasting Union published this in publication R92-1999:
"The EBU is aware of a certain amount of confusion about the active picture area in the implementation and use of digital signals conforming to the ITU-R Recommendation BT.601 [1].
Recommendation BT.60| specifies a line length of 720 luminance pixels (13.5 MHz sampling).
ITU-R Recommendation BT.470[2], specifies a line length of 52 µs for 625 line analogue signals. This corresponds to 702 luminance pixels.
This apparent difference can lead to difficulties in conversion, especially if users wish to maintain the correct aspect ratio of the pictures."

In the same publication they recommend this:
"· In 625-line television systems sampled to ITU-R Rec. BT.601 part A, only the central 702 luminance samples of the digital active line (samples 9-710 inclusive) and their associated chrominance samples should be used to carry the active picture.
The remaining 18 luminance samples and their associated chrominance samples may be used to carry picture information only but for no other purpose. It cannot be guaranteed that picture information in these samples will be displayed in either 4:3 or 16:9 aspect ratio images.
· The centre of the picture should retain its position throughout all production processes unless there are creative reasons to deliberately do otherwise."

Read some of my previous posts to get the rest of my story why i dont like to resize 720 to 352 without any cropping. Just to be problem member i must repeat that i trust the avisynth gyus on this, and that i dont understand why you doubt their level of expertise.

[thor300]

Even though these players will display only 704 pixels, they'll be centred so the aspect ratio is the same as if they'd display 720 (imagine as if you'd mask 8 pixels left and right).

Thats what I been saying, make up your mind now. I got it all wrong then you repeat what i said and then its correct?

[Phlexor]

http://www.uwasa.fi/~f76998/video/conversion/

That should put this debate to rest.

It's not about aspect ratio, it's about Pixel Aspect Ratio.