MeGUI SAR

[koberulz]

I have a 720x576 50fps progressive AVI.

I have two AviSynth scripts:

AVISource("File.avi")
AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave()
ConvertToYV12(matrix="rec601",interlaced=true)

AVISource("File.avi")
SelectEven()
Spline36Resize(768,576)
ConvertToYV12(matrix="rec601",interlaced=false)

The progressive square-pixel version is encoded in MeGUI with Force SAR set to 1:1. The interlaced version has Force SAR set to 12:11, which I'm led to believe is correct for PAL 4:3, and should make the two the same when I play them in VLC.

Except...it doesn't:



Where have I gone wrong?

[sneaker]

720 * 12/11 is 786, not 768. (Have not tested. Try it.)

[koberulz]

So should I be adjusting the progressive version to a width of 786, or the interlaced version to a SAR of 16:15?

[hello_hello]

In theory, 704x576 = 4:3 so you'd resize to 786x576 square pixels, or crop 8 pixels from each side and resize to 768x576 square pixels, or you'd set 16;15 as the SAR (whether you crop 8 pixels or not).

I say "in theory" because I don't know what the source is, and whether it was created using the above method or of it was created assuming 720x576 = 4:3 (in which case you'd use 12:11 for the SAR).

[koberulz]

It's a PAL VHS tape, captured at 720x576.

[jagabo]

Crop 16 pixels of the width (eg, 8 off the left, 8 off the right) then resize what's left to 768x576 and encode square pixel. Or crop, leave the frame at 704x576, and encode SAR 12:11.

In at ITU cap the 4:3 image is in the inner 704x576 portion of the frame (actually for PAL it closer to 702x576 but 704 is commonly used). Extra pixels are captured at the left and right in case the picture is off center.

[koberulz]

Itu?

[jagabo]

ITU = International Telecommunication Union
https://en.wikipedia.org/wiki/International_Telecommunication_Union

ITU cap = ITU rec.601 specification for capturing SD analog video, almost all capture devices follow this spec
https://en.wikipedia.org/wiki/Rec._601

By the way, the reason there is an aspect ratio discrepancy in some programs is because the MPEG specification (used on DVD, for example) indicates the 4:3 image is contained in the entire 720x480/576 frame. That leads to a different sampling aspect ratio (16:15 for 720x576 PAL).

[koberulz]

So would it be valid to keep the script I have and flag as 16:15, or...?

If not, what about if I wanted to create a DVD from the same material? At present, the idea is to use that avs to create an MP4, but also have it available to run through HCEnc for DVD.

I've additionally got a 720p50 AVS which resizes to 960x720 before padding 160 on each side. Is that okay or does that need to be cropped as well? I remember initially just using SD2HD for that and it made the footage wider, which I'm guessing might be related? I was told to stick with the manual resize though...

[poisondeathray]

So would it be valid to keep the script I have and flag as 16:15, or...?

If not, what about if I wanted to create a DVD from the same material? At present, the idea is to use that avs to create an MP4, but also have it available to run through HCEnc for DVD.

It depends on which rules you want to adhere to...

I've additionally got a 720p50 AVS which resizes to 960x720 before padding 160 on each side. Is that okay or does that need to be cropped as well? I remember initially just using SD2HD for that and it made the footage wider, which I'm guessing might be related? I was told to stick with the manual resize though...

HD is almost always uses square pixels , the exception is 1440x1080 which is usually 16:9 , with a sar of 4:3

SD2HD / HD2SD has parameters InputPAR and OutputPAR, so you can adjust them . The defaults use ITU aspect ratios, because that's used in broadcast

[jagabo]

Commercial DVD generally ignore the difference between the ITU and MPEG specs regarding aspect ratios. They capture following the ITU spec and write it to the DVD flagging it as 4:3 by the MPEG spec. Ie, they don't care about the difference and nobody can really see the ~2 percent difference. In the days of analog TVs most TVs were off by more than that anyway.

[koberulz]

It depends on which rules you want to adhere to...

I'm not sure how helpful that is.

HD is almost always uses square pixels

Right, but the question is whether I should be doing the 16-pixel crop before resizing to 960x720, and/or resizing to something other than 960x720...

Additional query: I have a 720p clip that goes one hour, five minutes and 38 seconds. Encoded as CRF 17, which I'm led to believe is quite high in terms of quality, it spits out a file a mere 2.02 GB - the equivalent of a bitrate of just over 4,400 kbps. Should it be higher than that? It's a game of basketball, so plenty of movement and such...

I was following this guide, trying to create a Blu-Ray from several different files, both 720p and 1080i which is why I went the math route instead of just working out total runtime. CRF 17 encodes for the whole lot combine for just 5.99 GB, with a runtime of a touch over 100 minutes. Which, again, seems low given that low twenties is generally recommended for CRF and none of it is coming anywhere near Blu-Ray's max bitrate. In fact, the second clip I did the math on to work out what its average bitrate should be returned a result of 54,000 kbps, where its CRF version is around 14,000.

Is my total runtime just so low it's breaking the system, or are these numbers actually as low as they seem?

[poisondeathray]

It depends on which rules you want to adhere to...

I'm not sure how helpful that is.

And yet it's the only valid answer. I'm not trying to be a jerk

You have to make a choice. There are only 2 choices. Choose one.

Sometimes that choice is made for you (e.g you submit to a station or something, then they have guidelines, usually ITU)

HD is almost always uses square pixels

Right, but the question is whether I should be doing the 16-pixel crop before resizing to 960x720, and/or resizing to something other than 960x720...

It depends on what you have. Check your basketball, is it oval or spherical when shot straight on? Because pillarboxed 960x720 will be square pixel, you now have the unique opportunity to fix everything perfectly, all the errors that might have previously been introduced . And it will actually look correct everywhere, because 1280x720 is square pixel. None of this AR interpretation business

Additional query: I have a 720p clip that goes one hour, five minutes and 38 seconds. Encoded as CRF 17, which I'm led to believe is quite high in terms of quality, it spits out a file a mere 2.02 GB - the equivalent of a bitrate of just over 4,400 kbps. Should it be higher than that? It's a game of basketball, so plenty of movement and such...

Depends on more than just movement, other things like SD upscale, noise etc...

If you're concerned , use 2 pass and a bitrate calculator, or lower CRF with appropriate vbv-maxrate and vbv-bufsize

I was following this guide, trying to create a Blu-Ray from several different files, both 720p and 1080i which is why I went the math route instead of just working out total runtime. CRF 17 encodes for the whole lot combine for just 5.99 GB, with a runtime of a touch over 100 minutes. Which, again, seems low given that low twenties is generally recommended for CRF and none of it is coming anywhere near Blu-Ray's max bitrate. In fact, the second clip I did the math on to work out what its average bitrate should be returned a result of 54,000 kbps, where its CRF version is around 14,000.

Is my total runtime just so low it's breaking the system, or are these numbers actually as low as they seem?

Something is wrong with the calculator if avg bitrate video is 54Mb/s for BD

Personally I wouldn't use CRF for BD encoding

[jagabo]

You have an ITU cap. Crop it to 704x576 then upscale to 960x720 and pad to 1280x720.

[koberulz]

Something is wrong with the calculator if avg bitrate video is 54Mb/s for BD

Not 'for BD', that's just the number the calculator spat out when I gave it resolution, duration, and target size.

Personally I wouldn't use CRF for BD encoding

I'm not, I'm using CRF to determine file size targets for each of my files individually.

If I throw everything together and calculate for an hour 40 of 1920x1080 video, it's going to waste bitrate on the 1280x720 portion. Plus some clips are mostly just talking heads, others have a lot more going on.

So, I run them all through as CRF. Work out the total size of all the resulting files, and each of them individually. Work out what each file's size is as a percentage of the total. Work out how much space I have available on the disc (after audio and such), and thus what size each file needs to be in order to be the same percentage of the total BD size as it is of the CRF size. Then list that as my target when running the bitrate calculator, then run a two-pass encode to get the file that will actually go on the disc.

Separately, I'm using CRF to store some other video files (the digitised VHS that led to the SAR question), and seeing how small the results of this CRF encode were compared to what they ought to be for BD leads me to believe perhaps 17 is significantly too high a number for constant quality, which just doesn't jive with what others have posted and opens up the possibility I've made other errors.

Or, possibly, my runtimes are simply too short. But a bitrate-equivalent of 4000kbps for a basketball game seems very low...

[poisondeathray]

Don't just look at the numbers, correlate with the picture quality

1hr5min is not too short of a runtime, but 4.4Mb/s from CRF17 for 1280x720p50 does seem a bit low, unless the source quality was low (in terms of "smooth" with low detail, maybe an sd upscale; not "noisy" SD upscale, which would actually consume more bitrate)

[koberulz]

Don't just look at the numbers, correlate with the picture quality

What do you mean?

1hr5min is not too short of a runtime, but 4.4Mb/s from CRF17 for 1280x720p50 does seem a bit low, unless the source quality was low (in terms of "smooth" with low detail, maybe an sd upscale; not "noisy" SD upscale, which would actually consume more bitrate)

It's one of the VHS digitisations, it's been through denoising and such so possibly.

[poisondeathray]

Don't just look at the numbers, correlate with the picture quality

What do you mean?

1hr5min is not too short of a runtime, but 4.4Mb/s from CRF17 for 1280x720p50 does seem a bit low, unless the source quality was low (in terms of "smooth" with low detail, maybe an sd upscale; not "noisy" SD upscale, which would actually consume more bitrate)

It's one of the VHS digitisations, it's been through denoising and such so possibly.

I mean look at the before vs the after. Look at the immediate source and compare to the CRF encode. Is it "good enough" or what you expect ?

Examine not only in motion (normal playback), but even frame by frame. Note CRF scales frame quality with framerate (the higher the framerate, the lower the quality per frame at a given CRF ; the rational is if playback rate is fast, less likely user will "see" problems)