Vhs capture advice.

[dellsam34]

Ok lets see the original frame.

[Sharc]

Distorted only if you are forcing the player (TV, whatever) to play the cropped video as 4:3. If the player respects the SAR flag one will see the cropped picture (at its new DAR which is no longer 4:3 of course) with the objects undistorted. If the player respects the SAR there is actually no need for padding back. Of course one can pad it back in order to get the same output irrespective of playing it as 4:3 or according to the SAR. Double stitched, so to speak. Read posts #298 and #318 again

Sure if you only want to watch on the computer screen in an oddball frame, TV's and monitors can only show 4:3 materials as 4:3 frame and all the setting has to match that frame. For your own viewing pleasure you can do whatever you please but to share with the rest of the world you have to follow the standard.

My TV plays these non-padded "oddball" .mp4 or .mkv frames properly. For distribution one is on the very safe side though with the double-stitch (I do it as well when I give it away), i.e. encoding and flagging with the correct SAR plus padding back to the desired standard DAR. I think we can agree on this

[Alwyn]

Sure if you only want to watch on the computer screen in an oddball frame, TV's and monitors can only show 4:3 materials as 4:3 frame and all the setting has to match that frame. For your own viewing pleasure you can do whatever you please but to share with the rest of the world you have to follow the standard.

It plays correctly on ios, Android and my LG TV, and on YT. They all pillarbox it correctly.

[dellsam34]

Pillarbox it, See the magic word? Isn't that padding? Rules are rules cannot be broken, A 4:3 frame takes only a 4:3 shape, A 16:9 frame takes only a 16:9 shape, It's impossible to force a different shape in a different frame without padding or stretching, It's in the Geometry book if you guys still remember, If your ideas were true we wouldn't have gone through letter boxing, pillar boxing and anamorphic when we transitioned from 4:3 to 16:9.

[Alwyn]

Pillarbox it, See the magic word? Isn't that padding?

No, of course it isn't. You adding pixels back from 704 to 720 is padding. A player displaying a 266x576 video correctly by adding black sides is entirely different, and it would appear that no longer do we need supply 720x576 to any player to get it to display correctly.

Original video attached.

[Sharc]

....If your ideas were true we wouldn't have gone through letter boxing, pillar boxing and anamorphic when we transitioned from 4:3 to 16:9.

Anamorphic = non-square pixels have nothing to do with transition from 4:3 to 16:9. Even 4:3 DVDs are anamorphic. "Anamorphic widescreen" has just been a marketing gimmick for 16:9 DVDs.
I think we are fighting words now ....

[dellsam34]

No, of course it isn't. You adding pixels back from 704 to 720 is padding. A player displaying a 266x576 video correctly by adding black sides is entirely different, and it would appear that no longer do we need supply 720x576 to any player to get it to display correctly.

That's exactly is, It's called filling up the 4:3 frame, Try the resolution I suggested and use a resizing software and get back to me.

Anamorphic = non-square pixels have nothing to do with transition from 4:3 to 16:9. Even 4:3 DVDs are anamorphic. "Anamorphic widescreen" has just been a marketing gimmick for 16:9 DVDs.

I don't know how old you are since you know only as far back as DVD, but anamorphic has everything to do with transition to 16:9, It was the only viable option to watch laser discs encoded in a 4:3 frame but with a squeezed horizontally picture, so when displayed on a 16:9 TV it will restore the frame to its original form, keeping the vertical resolution intact but loosing on the horizontal resolution.

[Sharc]

I don't know how old you are since you know only as far back as DVD, ......

Old enough to have enjoyed cinematographic movies in cinemas, which were filmed with anamorphic lenses long before digital video entered the scene.
Let's stop here

[dellsam34]

Yes, that was indeed before analog TV, But for the same exact reasons, you can't fit something into something unless you add black space to it or stretch it, I agree we have derailed the thread enough.

[lollo]

My 2 cents.

Given a 720x576 ITU-R BT.601-4 (formerly "CCIR-601" or "Rec.601") analog capture:

1- mask bottom and top noise, crop left and right, addborders left and right to build 704x576 frame, encode with DAR=4:3
best option, no resizing, higher compatibility with PC players and TVs, residual top and bottom black borders, standard dimensions frame usage

2- given that cropping has no impact on Sample Aspect Ratio = Pixel Aspect Ratio, crop the frame as needed and encode with appropriate SAR = PAR
second best option, no resizing, relies on respecting the SAR = PAR from the player, no residual top and bottom black borders, non standard dimensions frame usage

A resize option (except upscale to fit screen or YT requirements) is not an option for me.

[Alwyn]

@Dellsham43, all I ask you to do is play my video in post #325. If you find a player/TV that will not play it correctly, let us know.

[jagabo]

For those of you who want to scale your arbitrarily cropped non-square-pixel video here are two AviSynth functions that do it:

function ResizeToWidth(clip old, int new_width, int sarx, int sary)
{
    new_height = float(old.height) * float(new_width) / float(old.width) / float(sarx) * float(sary)
    Spline36Resize(old, new_width, int(new_height+0.5))
}

function ResizeToHeight(clip old, int new_height, int sarx, int sary)
{
    new_width = float(old.width) * float(new_height) / float(old.height) * float(sarx) / float(sary)
    Spline36Resize(old, int(new_width+0.5), new_height)
}

# call with something like: ResizeToWidth(1280, 12, 11) # for 12:11 SAR

The first function resizes to the specified width and whatever height is required to retain the geometry with square pixels. The second resizes to the specified height and whatever width is required to retain the geometry with square pixels.

Some notes:

When AviSynth converts floats to integers it truncates rather than rounds. So, for example, 600.1 and 600.9 both are truncated to 600. That's why I added 0.5 before converting to an integer -- essentially rounding instead of truncating.

These functions do not limit the sizes to even values. They will sometimes fail with 4:2:0 and 4:2:2 chroma subsampled video which requires mod 2 dimensions. My point here was to show the resizing calculations. I'll leave the mod 2 adjustment as a project for the user.

[Sharc]

For those of you who want to scale your arbitrarily cropped non-square-pixel video here are two AviSynth functions that do it:

function ResizeToWidth(clip old, int new_width, int sarx, int sary)
{
    new_height = float(old.height) * float(new_width) / float(old.width) / float(sarx) * float(sary)
    Spline36Resize(old, new_width, int(new_height+0.5))
}

function ResizeToHeight(clip old, int new_height, int sarx, int sary)
{
    new_width = float(old.width) * float(new_height) / float(old.height) * float(sarx) / float(sary)
    Spline36Resize(old, int(new_width+0.5), new_height)
}

# call with something like: ResizeToWidth(1280, 12, 11) # for 12:11 SAR

The first function resizes to the specified width and whatever height is required to retain the geometry with square pixels. The second resizes to the specified height and whatever width is required to retain the geometry with square pixels.

Some notes:

When AviSynth converts floats to integers it truncates rather than rounds. So, for example, 600.1 and 600.9 both are truncated to 600. That's why I added 0.5 before converting to an integer -- essentially rounding instead of truncating.

These functions do not limit the sizes to even values. They will sometimes fail with 4:2:0 and 4:2:2 chroma subsampled video which requires mod 2 dimensions. My point here was to show the resizing calculations. I'll leave the mod 2 adjustment as a project for the user.

Thanks for this, it may replace my Excel.
In case of interlaced 4:2:0 chroma subsampled video one should probably adjust the heights (vertical dimensions) to mod4, no? (unless one deinterlaces beforehand, of course).

[jagabo]

In case of interlaced 4:2:0 chroma subsampled video one should probably adjust the heights (vertical dimensions) to mod4, no? (unless one deinterlaces beforehand, of course).

Interlaced video has to be mod 4. But progressive can be mod 2. That said, there are a few old players/editors that have problems with mod 2. So I recommend mod 4 for everything.

[Leanoric]

I think that I might be gaining a very basic understanding of this resizing and SAR business, maybe not though I have a few questions to be sure.




1. A 720x576 video that needs no cropping, my minidv capture for example, can be encoded to mp4 as is with a SAR of 16:15?


2. It can also be resized without any cropping to 768x576 or 1440x1080 with a SAR of 1:1 applied?


3. A video that is to be encoded at 704x576 but needs to be cropped to 692x560 first, has to be resized to 704x576 with borders and SAR 12:11? It cant be resized to 704x576 without borders?


4. A video can be cropped to say 692x560 and then resized straight to 768x576 without any borders with SAR 1:1.


5. For the time being, Im going with 1440x1080. Is that my best option for playback on modern screens or are there any advantages to 768x576 or 704x576 with borders apart from smaller file size?

[Skiller]

1. A 720x576 video that needs no cropping, my minidv capture for example, can be encoded to mp4 as is with a SAR of 16:15?

MiniDV follows DVCAM specification which sticks to the ITU Rec.601 standard, meaning the PAR is still 12:11, even though the entire 720px wide frame contains image. There may be camcorders, supposedly ones made towards the end of the MiniDV production cycle, as well as HDV camcorders running in DV mode, that do not stick to the ITU Rec.601 standard (although we have yet to see evidence of this, so I'm just mentioning it for completeness).

To be sure, you would have to test yourself. Or just use 12:11 as it's more likely to be correct than not.



I don't get what you mean by 968x576. Where does 968 come from?

[Leanoric]

Sorry I meant 768, Ill edit the post now.

[Sharc]

1. A 720x576 video that needs no cropping, my minidv capture for example, can be encoded to mp4 as is with a SAR of 16:15?


2. It can also be resized without any cropping to 968x576 or 1440x1080 with a SAR of 1:1 applied?

Upload a short unprocessed sample and someone might be able to tell (or give his best estimate). miniDV is usually 12:11.

3. A video that is to be encoded at 704x576 but needs to be cropped to 692x560 first, has to be resized to 704x576 with borders and SAR 12:11? It cant be resized to 704x576 without borders?

You could, but you shouldn't do this. Otherwise you would change the SAR of that video from 12:11 (=1.090909..) to non-standard 1.10295.
(Note: "resize to 704x576 with borders" is called padding rather than resizing. You don't change the SAR (the geometric shape of the objects in the video) with cropping or padding, it's still 12:11.)

4. A video can be cropped to say 692x560 and then resized straight to 968x576 without any borders with SAR 1:1.

?? Where did you get the 968 from?

5. For the time being, Im going with 1440x1080. Is that my best option for playback on modern screens or are there any advantages to 968x576 or 704x576 with borders apart from smaller file size?

Apart from the strange 968x576 it is your decision/preference. You may continue with upscaling to square pixels, but I don't see a real device compatibility issue with either of the 2 variants. Keep in mind you don't add any details to the video with upscaling.

Edit: I just noticed your correction re. 968

[dellsam34]

3. A video that is to be encoded at 704x576 but needs to be cropped to 692x560 first, has to be resized to 704x576 with borders and SAR 12:11? It cant be resized to 704x576 without borders?

Yes, close enough, But you don't want to resize from 560 to 576, that's damn close you will have a horrific scaling artifacts, You want to go directly to item 5 of your list.

[Leanoric]

Ok I think that I’m starting to get my head around some of this now.

Interesting what Skiller said about minidv being 12:11 in most cases. I wrongly assumed and encoded with 16:15. That said, I cant see anything wrong when watching it back so maybe it isnt worth worrying about too much.

[Sharc]

That said, I cant see anything wrong when watching it back so maybe it isnt worth worrying about too much.

Yes, the aspect ratio error is about 2% only if you did it wrong. No need to redo it.

[Leanoric]

Yes, the aspect ratio error is about 2% only if you did it wrong. No need to redo it.

No, especially as it took ages to do. I need a quicker computer!

[Sharc]

Yes, the aspect ratio error is about 2% only if you did it wrong. No need to redo it.

No, especially as it took ages to do. I need a quicker computer!

Well yes. Take it with a grain of salt, but deinterlacing, upscaling and encoding at 1440x1080 takes more time than keeping it interlaced and encoding the small frames without upscaling, and leave the deinterlacing and upscaling to the player/TV

[Skiller]

Modifying the SAR can be done without having to do the whole encoding again. It's just a quick remux.

But I agree, it's probably not worth the effort now.

[Bwaak]

1. A 720x576 video that needs no cropping, my minidv capture for example, can be encoded to mp4 as is with a SAR of 16:15?

MiniDV follows DVCAM specification which sticks to the ITU Rec.601 standard, meaning the PAR is still 12:11, even though the entire 720px wide frame contains image. There may be camcorders, supposedly ones made towards the end of the MiniDV production cycle, as well as HDV camcorders running in DV mode, that do not stick to the ITU Rec.601 standard (although we have yet to see evidence of this, so I'm just mentioning it for completeness).

FWIW, when you drop DV video into 4:3 frame in Vegas, you see thin black bars. I hope that all DV manufacturers abide by Rec. 601.

[Alwyn]

At the risk of thread drift...

There may be camcorders, supposedly ones made towards the end of the MiniDV production cycle, as well as HDV camcorders running in DV mode, that do not stick to the ITU Rec.601 standard (although we have yet to see evidence of this, so I'm just mentioning it for completeness).

For your viewing pleasure, here is exactly what I think you are talking about, Skiller.

It's a HDV camera (HV20), shooting in DV mode and captured via Composite to my GV-USB2; not a black bar to be seen (well maybe just a smidgeon top and bottom), and a pretty good image at that.


[Attachment 69408 - Click to enlarge]

The video is attached.

[Bwaak]

^ Looks like 720x576 is 4:3. Did not expect this from Canon.

[Sharc]

At the risk of thread drift...

There may be camcorders, supposedly ones made towards the end of the MiniDV production cycle, as well as HDV camcorders running in DV mode, that do not stick to the ITU Rec.601 standard (although we have yet to see evidence of this, so I'm just mentioning it for completeness).

For your viewing pleasure, here is exactly what I think you are talking about, Skiller.

It's a HDV camera (HV20), shooting in DV mode and captured via Composite to my GV-USB2; not a black bar to be seen (well maybe just a smidgeon top and bottom), and a pretty good image at that.


[Attachment 69408 - Click to enlarge]

The video is attached.

Thanks Alwin. Now doing the circle test with the rim of the wheel according post#320 gives vertical/horizontal=305/286=1.066 which indicates that the SAR is 16:15 rather than 12:11, means the camera is out of DVCAM spec. Apparently Canon abandoned the original SONY specs for this HDV camera.

Edit: To be asolutely certain, can you upload a digital copy of the unprocessed original DV file, i.e. without capturing via the GV-USB2?

[Alwyn]

Here you go, Sharc. Different wheel, same thing. Lying on driveway for camera at wheel centre not good for my elbows!

[Sharc]

.... and a pretty good image at that.

Except for the elevated blacks and the clipped whites. May have been caused by your capture setup. But this would be a subject for a new thread.