Keep aspect ratio in AviSynth?

[Downgraded286]

I use AviSynth to deinterlace or detelecine my DVDRips when needed. As you know, DVD resolution is 720x480, however... I've either run into DVDs that modify the aspect resolution, displaying in either 640x480 (4:3) or ~853x480 (16:9). If I run the video through AviSynth however, it comes out being displayed in 720x480. I can fix the aspect ratio later in my process, but it's troublesome to do so. Can I make AviSynth preserve the original aspect ratio?

[KarMa]

You using any GUI, like MeGUI or AvsPmod?

Anyway you can use one of the resizers, like

Spline64Resize(854,480)

There are a bunch of other resizers out there too, http://avisynth.nl/index.php/Category:Resizers

[Downgraded286]

I'm loading my AviSynth Scripts into VirtualDub, at least, for now.

I'd rather not resize the output video, I'd like to keep the resolution the same, just preserve the aspect ratio flags.

[KarMa]

Then that would be the job of the container to store the flag information. With .MKV you can set flags, it's just a matter of the player reading and obeying those flags. Avisynth is completely irrelevant to this issue.

[Cornucopia]

Frame/display AR and Pixel/sample AR are decided upon & set with an encoder. Avisynth is not an encoder, but a frameserver, so it knows nothing about AR. All it understands (WRT this context) is H and V resolutions.

Scott

[hello_hello]

Avisynth itself is oblivious to the aspect ratio. It just sees pixels
All DVDs are either 4:3 or 16:9. None use a display aspect ratio of 720x480, even though that's the resolution.

Assuming you're using the x264 encoder, you can set the aspect ratio when configuring it. Rather than set the display aspect ratio though, you set the pixel aspect ratio (shape of the pixels), or as it's referred to in x264-speak, the sample aspect ratio. If you're using x264 via the command line, you'd add --sar 10:11, for example.

There's a list of pixel aspect ratios here:
https://www.doom9.org/showthread.php?p=1058927#post1058927
However DVDs don't always use the same ones.

The "Exact PAR according to ITU-R BT.601" are the official pixel aspect ratios after digitising an analogue signal, but they're convoluted and the digital equivalents are mostly used instead these days.

The "Almost exact and commonly used ITU-PAR" were the PARs commonly used by GUIs for calculating DVD resizing, but they're not used much any more. They're probably also the least accurate.

The "MPEG-4 PAR" are the digital equivalents of the "ITU PARs". The resulting display aspect ratios are virtually the same as ITU.

The "Generic PAR" are the pixel aspect ratios for an exact 16:9 or 4:3 display aspect ratio. None of the previous PARs are exactly 16:9 or 4:3. They're all a little wider.

My 2 cents.... assuming you're not resizing at all, for 4:3 DVDs use the appropriate MPEG4 PAR. ie --sar 10:11 for 4:3 NTSC.
The resulting display aspect ratio will be about 1.367:1 or it'll display at about 656x480 instead of 640x480.
For 16:9 use the appropriate generic PAR. ie --sar 32:27 for 16:9 NTSC. In my opinion 16:9 DVDs mostly ignore the ITU/mpeg4 PARs and should be resized to exactly 16:9.

Not that it matters for anything else, but as a side note the mpeg4 PARs are the only Bluray complaint PARs for standard definition 720x480 (or 720x576 for PAL).

[Downgraded286]

Could I set the aspect ratio in the Handbrake additional options box? That would make this a lot easier for me. I know there's a way to adjust it in the GUI, but it's... quirky at best.

[jagabo]

Could I set the aspect ratio in the Handbrake additional options box?

I haven't found a way. The x264 sampling aspect ratio is set with "--sar=X:Y" (where X and Y are integers). Unfortunately, Handbrake uses colon as a separator so it doesn't parse the command properly and passes garbage to x264.

[manono]

I'm loading my AviSynth Scripts into VirtualDub, at least, for now.

I'd rather not resize the output video, I'd like to keep the resolution the same, just preserve the aspect ratio flags.

Could I set the aspect ratio in the Handbrake additional options box? That would make this a lot easier for me. I know there's a way to adjust it in the GUI, but it's... quirky at best.

You know AviSynth yet still use Handbrake? You could dump Handbrake and use a better program. For example, I use RipBot264 to open my AviSynth scripts and you can easily set the SAR to whatever you like:

[Downgraded286]

Ripbot has its own set of issues, at least for me. Adding subtitles is difficult, at least for those included in the container from the DVD, and the audio is a bit weird. I used Ripbot once to test something and the audio came out really low. I may end up moving to Vidcoder.

Also, using Ripbot with avisynth is troublesome because I lose the audio, subtitles and chapter markers.

[manono]

Ripbot has its own set of issues, at least for me. Adding subtitles is difficult, at least for those included in the container from the DVD

I don't burn subs into video myself, but there's no reason you can't add the subs to the AviSynth script using the TextSub or VobSub filters.

I used Ripbot once to test something and the audio came out really low.

I add the audio separately and have never had a problem. Maybe it was an older version, I don't know.

Also, using Ripbot with avisynth is troublesome because I lose the audio, subtitles and chapter markers.

Chapter markers, yes; the others, no.

Good luck with VidCoder. Maybe it'll set the aspect ratios properly as well as do the other things you want.

[hello_hello]

Could I set the aspect ratio in the Handbrake additional options box? That would make this a lot easier for me. I know there's a way to adjust it in the GUI, but it's... quirky at best.

Theoretically Handbrake should make it hard for you to output a video without the correct aspect ratio, given it's designed to take care of it for you.

This is the old version of Handbrake, but if you select "anamorphic custom" you should be able to set the pixel aspect ratio. This is how Handbrake version 0.9.9.5530 looks after opening a 720x480 16:9 video.



I'll confess I don't fully understand how the various options interact, as I don't use Handbrake myself and the options can be contadictory in that they should effect each other (the display width should change the pixel aspect ratio etc) so some settings must take precedence over others. If you set them all correctly though, you should be able to set any pixel aspect ratio you like.

For a 16:9 NTSC DVD the above settings will work, as long as there's no cropping or auto-cropping is disabled (otherwise you might need to change the resizing accordingly). Or....

Clearing the resize fields and the display width field should let you simply set the pixel aspect ratio. Cropping on it's own doesn't change the pixel aspect ratio so with the other fields cleared you can set the desired pixel aspect ratio regardless of cropping. As an example, there's eight pixels cropped from the bottom of the picture in the screenshot below, the pixel aspect ratio is set to 32:27 and for an NTSC DVD that'd result in a resolution of 720x472 and a display aspect ratio of 853x472.



That's what Handbrake should be doing for you when using "anamorphic loose" or "anamorphic strict" though. I'm not sure how or why you're managing to get it to output the wrong aspect ratio using either of those methods.

[Downgraded286]

Yeah, you're pretty much right about how it works
First you have to select anamorphic none, uncheck the keep aspect ratio box, then go to anamorphic custom, fix the resolutions (because by now it's changed to something extremely small) and set your PAR. Imagine ripping a TV series and having to do this for every one. Cumbersome isn't it? I think vidcoder handles it better, though.

Usually handbrake already knows what's going on and I don't have to change it, but if I run it through avisynth it loses the aspect ratio information and displays 720x480.

[hello_hello]

Yeah, you're pretty much right about how it works
First you have to select anamorphic none, uncheck the keep aspect ratio box, then go to anamorphic custom, fix the resolutions (because by now it's changed to something extremely small) and set your PAR. Imagine ripping a TV series and having to do this for every one. Cumbersome isn't it?

I'm OCD about that sort of thing and even for a TV series I create a script for each episode manually, adjusting the cropping/resizing as required in order to encode each episode at the same resolution and display aspect ratio, so I'm effectively already doing that for each one.

I'm not sure what your process involves exactly... I'm not sure why you're running it through Avisynth before encoding with Handbrake..... but you can set the aspect ratio in a script if you use MeGUI to do the encoding.

MeGUI's x264 encoder configuration lets you specify the PAR and you can save as many encoder configurations with different PARs as you like. Load a script for encoding, select the appropriate encoder configuration, and add the encoding job to the queue. The encoder GUI has a drop down list containing the mpeg4 and generic PARs, or there's a custom command line section where you can add your own. Or....

Normally when setting up a script for anamorphic encoding MeGUI takes care of the aspect ratio for you, so you don't need to set the PAR yourself. It does so by adding it's own display aspect ratio info to the top of a script, and when it's loaded for encoding, MeGUI checks it, along with the output resolution, and calculates the required pixel aspect ratio, which it adds to the command line.

If you open a 16:9 NTSC DVD and tell MeGUI to use the generic PAR and anamorphic encoding, it'll add the following to the top of the script it creates (assuming no cropping):

# Set DAR in encoder to 16 : 9. The following line is for automatic signalling.
global MeGUI_darx = 16
global MeGUI_dary = 9

If MeGUI's option for fudging the aspect ratio is set to 0%, when you tell MeGUI to use an ITU aspect ratio it'll add this:

# Set DAR in encoder to 8640 : 4739. The following line is for automatic signalling
global MeGUI_darx = 8640
global MeGUI_dary = 4739

MeGUI doesn't come configured for mpeg4 PARs, but you can create custom PARs, and the NTSC 16:9 mpeg4 PARs result in this:

# Set DAR in encoder to 20 : 11. The following line is for automatic signalling
global MeGUI_darx = 20
global MeGUI_dary = 11

For 4:3 NTSC the display aspect ratios are....

Generic:

# Set DAR in encoder to 4 : 3. The following line is for automatic signalling
global MeGUI_darx = 4
global MeGUI_dary = 3

ITU:

# Set DAR in encoder to 6480 : 4739. The following line is for automatic signalling
global MeGUI_darx = 6480
global MeGUI_dary = 4739

MPEG4:

# Set DAR in encoder to 15 : 11. The following line is for automatic signalling
global MeGUI_darx = 15
global MeGUI_dary = 11

Another good reason for ignoring the ITU aspect ratios and using either generic or mpeg4, is even though they use different PARs, the generic display aspect ratios are the same for both NTSC and PAL, and the MPEG4 display aspect ratios are exactly the same for NTSC and PAL (assuming no cropping, of course).

You could add the appropriate DAR info to the top of your own script and if you load it into MeGUI for encoding it'll set the appropriate PAR (otherwise it'll set 1:1), but be aware it's the "display" aspect ratio at the top of the script, so if you apply any cropping you'll need to work out the new DAR if you're adding it to the script yourself. The resolution/resizing doesn't matter as for anamorphic encoding changing it doesn't normally effect the display aspect ratio, but don't change the DAR/resolution/resizing in a script after loading it for encoding. If you need to change it, delete the encoding job from MeGUI's job queue, modify the script, then load it again so MeGUI can re-calculate the correct pixel aspect ratio.

[Downgraded286]

My process goes like this (assuming AviSynth is needed, and it would be needed only for deinterlace/detelecine operations):

1. Rip DVD with MakeMKV.
2. Load MakeMKV result into VirtualDub/AviSynth for deinterlace/detelecine
3. Because the output from step 2 only keeps video (losing audio, subtitles, and chapter markers), load MakeMKV source and VirtualDub/AviSynth output video into MKVToolNix, merging the deinterlaced/detelecined video track with original audio tracks
4. Load MKVToolNix output file into Handbrake for final compression

AviSynth also removes the aspect ratio information (hence the creation of this thread) which is a headache. I actually wouldn't mind resizing the video in my AviSynth script if the DVD source was 4:3 (making the output video 640x480) because that would be more efficient. Why store in 720x480 only to display in a smaller resolution? However, it would be less efficient to resize to 854x480 if I could store in 720x480 and display in 854x480 with an aspect ratio flag.

I also realize I could probably just use a different encoder in VirtualDub, or load my AviSynth script into something else, but currently I like to use the lossless codecs in VirtualDub and compress with h.264 later on because not only do I compress the video track, I also transcode the audio track to 80kbps stereo AAC.

If there's a way to improve this process, great, if not, it looks like I'll most likely be tinkering with VidCoder next (MeGUI is an option, but it presents the same thus far impassible AviSynth problem of losing everything but the video track).

[manono]

1. Rip DVD with MakeMKV.
2. Load MakeMKV result into VirtualDub/AviSynth for deinterlace/detelecine
3. Because the output from step 2 only keeps video (losing audio, subtitles, and chapter markers), load MakeMKV source and VirtualDub/AviSynth output video into MKVToolNix, merging the deinterlaced/detelecined video track with original audio tracks
4. Load MKVToolNix output file into Handbrake for final compression

1. Decrypt using DVD Decrypter or DVDFab HD Decrypter.
2. Use MPEG2Source to open your video in an AviSynth script, add in the deinterlace or IVTC filters, and encode in the x264 encoder of your choice.
3. Add the encoded video, your audio, your subs, your chapters into MKVToolNix, set the aspect ratio flag, and output your finished MKV.
4. A complete waste of time.

[jagabo]

I like to add the SAR information while encoding with x264, and also at the container level while muxing. That way both the h.264 stream and the container indicate the same aspect ratio.

AviSynth also removes the aspect ratio information (hence the creation of this thread) which is a headache.

Why is this a headache? You just tell the encoder what the aspect ratio is while encoding. Or the muxer while muxing.

[hello_hello]

Encoding the video twice (even if one encode is lossless) simply to re-encode the audio seems fairly pointless.
Me.... I mostly extract the audio and chapters etc myself (gMKVExtractGUI for MKV) and if I'm re-encoding the audio I generally use foobar2000 for that, but you could use any program capable of encoding audio independently of the video (ie something that isn't Handbrake). To create and encode the Avisynth script I use MeGUI, then I mux it all manually with MKVToolNixGUI.

MeGUI's OneClick encoder should automatically keep the audio and/or convert it, along with subtitles and chapters etc. It's highly configurable, including being able to create Avisynth script templates. I barely used it myself though.

Or....
If you open a source video using MeGUI's File/Open menu, it's just a matter of following the prompts to add the indexing job to the queue which includes extracting the audio (if DGIndex is used for indexing or the source is MKV). For other file types the indexing process creates a script to re-encode the audio rather than extract it, but MeGUI re-encodes them individually and it's AutoEncode function can do the muxing for you if you like.

There's a Chapter Creator under the Tools menu for manually extracting IFO and MPLS chapters, or for extracting them from MKVs. Should you need to do it manually, Vob Subber will extract DVD subtitles and I'm pretty sure the HD Streams Extractor under the Tools menu will extract subtitles from MKVs.

It's possibly better to rip and work with the original vob files (using DGIndex to index them and MPEG2Source in a script to open the video as manono suggested) as I find DGIndex/MPEG2Source less troublesome. If you already have DVDs ripped as MKVs I'd consider opening the MKVs with TSMuxer, remuxing them as TS files and using the TS files as the source for encoding. MeGUI will use DGIndex/MPEG2Source for indexing and decoding TS files too. You're not using something horrible like DirectShowSource to open the video with AVIsynth currently, are you?

MeGUI can convert to AAC using either NeroAAC or QAAC. Both better quality than Handbrake's AAC encoder, although you need to download the required files yourself.

For the record, there'd be nothing stopping you loading the audio into VirtualDub and re-encoding it along with the video, although that's a whole other story and probably not the easiest way to go about it, given the desired output is h264/AAC/MKV. It could be done though, without having to encode the video twice.

[Downgraded286]

Encoding the audio in your opinion may be a waste of time, but to me, it's not. I don't care about 5.1 audio or really high bitrate stereo, I'll happily chop it down a bit thereby cutting my resulting filesize in half. The smaller I make my files, the more I can fit on my HDD as my stuff grows over time.

I tried changing the aspect ratio in MKVToolNix. It worked... kinda. It displayed with the aspect ratio I selected in MPC-HC, but not on the PS3. Handbrake didn't even pick up on the modified aspect ratio, so that isn't going to make my process easier, either. Vidcoder however is very good about saving those PAR settings, much more than Handbrake, so I may switch to Vidcoder...

MeGui seems worth a shot when I have some more time to play with it.

Splitting the whole thing up and encoding the audio and video separately, I admit, is more efficient, but... seems a lot to keep track of. Not that my process currently isn't any less convoluted, though...

For future experiments, if I were to resize in AviSynth (which I am considering at least for 4:3 DVDs) Where would I put the resize command in my script? Currently, script is:

setmtmode(5,4) 
ffmpegsource2("F:\AviSynth Worker\Lewis Black Red White and Screwed.mkv") 
setmtmode(2) 
qtgmc(edithreads=2) 
selecteven()

[manono]

I tried changing the aspect ratio in MKVToolNix. It worked... kinda. It displayed with the aspect ratio I selected in MPC-HC, but not on the PS3.

Then you should take jagabo's suggestion and set the SAR in the encoder and not the muxer, although you could do it in both, I believe.

For that script you're showing, resize at the end.

And once again, if the source is a DVD, use MPEG2Source. Making an MKV out of a perfectly good DVD source before going to work on it is just asking for trouble. My opinion, anyway, although others might disagree.

[hello_hello]

I never said re-encoding the audio is a waste of time, I said encoding the video twice in order to re-encode the audio is a waste of time, given you can re-encode the audio without having to output lossless video and then remux it first.

Some players and/or conversion programs only pay attention to the container aspect ratio, some only pay attention to the aspect ratio written to the video stream, and if there's more than one aspect ratio a player/encoder needs to pick which one to use. I don't know if Vidcoder does it any differently to Handbrake, but that's why as a general rule, it's better to tell the x264 the desired aspect ratio, so after muxing, the video stream and container aspect ratios are the same.

If you're referring to resizing to square pixels, always de-interlace first and resize second. You can resize the width of interlaced video before de-interlacing but not the height, so normally you'd just resize second. If you do resize the height of interlaced video before de-interlacing you'll see the result pretty easily.

Why SelectEven()? If the source is truly interlaced, de-interlacing to 59.940fps progressive should look much smoother, and for a given CRF value it probably won't increase the bitrate all that much. I don't think it's worth throwing half the frames away, given most players these days support anything up to at least 720p at 60fps.

[Downgraded286]

Yeah, it looks like with the way my process is currently, and what I want to achieve, Vidcoder is the answer, instead of Handbrake. Handbrake can do it but it's much more cumbersome than Vidcoder. I'll just have to add each video one by one in order to keep the subtitles, which is troublesome, but less so than changing the aspect ratio in Handbrake.

I'll give MeGui a stab though, and see if I can't figure out a way to make my clunky process a bit better.

I used to add TDecimate() at the end of my QTGMC script... that really did screw with the video and had no place there. It wasn't as noticeable with South Park, which is what I started working with in the first place... but man it wrecked some havoc later on with other types of shows. Considering my target device is a toaster (PS3) I'd think it would be better to stick with 29.97FPS. It doesn't look bad to me at all. Maybe it's foolish, but I just prefer it to be there.

So far, it seems I'll be trying 3 things:
1. Resizing in AviSynth for 4:3 DVDs, so that my source file winds up actually being sized 640x480 instead of 720x480 and display in 640x480. Waste of storage space going on currently...
2. Experiment with MeGui, see where that gets me. If not...
3. Switch to Vidcoder instead of Handbrake, since it's easier to work with changing aspect ratios.

There's also the option of encoding with h.264 right off the bat and encoding audio separately, but that seems like it could get a bit messy.

[hello_hello]

Even using Vidcoder involves processing the video twice, assuming you're processing it with an Avisaynth script first.

TDecimate() is for removing duplicate frames. It's normally used as part of the process of converting "film" back to 23.976fps. ie film that's had 3:2 pulldown applied to convert it to 29.970fps. By default TDecimate removes 1 frame in 5, so the default TDecimate() would be the same as TDecimate(Cycle=5, CycleR=1). In it's default form it's normally used like this:

TFM().TDecimate()

TFM does the field matching to produce progressive frames, which for reversing 3:2 pulldown results in one frame in five being repeated, which TDecimate removes for 23.976fps. It's a whole different thing to de-interlacing. You normally wouldn't de-interlaced telecined film or apply reversed pulldown to interlaced video.

According to MeGUI, which has a preset for the PS3 as a target playback device, the x264 command line requires this:
--level 4.1 --vbv-bufsize 31250 --vbv-maxrate 31250

Which means the PS3 supports Level 4.1 with extra bitrate restrictions, and Level 4.1 includes the decoding of 720p or lower at up to 68fps.
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
Level 4.1 support is fairly standard these days. In fact it's becoming less than standard now 4k is more common.

De-interlacing to 29.970fps with QTGMC doesn't look bad at all, but de-interlacing to 59.940fps looks better to me (or for me the choice is mostly 25fps or 50fps), and that's how interlaced video would generally be de-interlaced on playback for a progressive display. 54.940fps, not 29.970fps.

I always resize 4:3 NTSC to 640x480.... Spline36Resize(640,480). If it's progressive video I usually can't see a loss of detail and if it's interlaced you'd probably need bionic eyes. In fact even though it starts out at 720x576 I still mostly resize interlaced PAL to 640x480. I resize everything to square pixels though as the media players built into the TVs here don't support anamorphic MP4/MKV and display it as though the pixels are square.

There's no reason why you can't encode audio and video separately. That's what any AVisynth based encoder GUI would generally do anyway, even if you appear to be creating a single encoding job for it to do. Try it. Extract the audio from one of your MKVs with gMKVExtractGUI, re-encode it, and use MKVToolnixGUI to replace the old audio with the new. There's no reason why it can't be done the same way when re-encoding the video too.

[Downgraded286]

I'm running into a roadblock with MeGUI. I haven't completed a job yet, but I think I got it doing what I want it to do. Now I just load up the mkv made by makemkv and MeGUI is doing it all in one go, or at least, I think that's what it's doing. Problem is it's only encoding at 6FPS. I wouldn't care if that's all I could do, but my CPU load is only around 35%. It should be able to go much faster, shouldn't it? I'm loading the mkv into the one click encoder. Could it be a problem with my AviSynth template?

<input>
setmtmode(2) 
qtgmc(edithreads=2) 
selecteven()

This has worked before in Virtualdub and loaded my CPU entirely.

Well, nevermind, tweaking edithreads value loaded my CPU to the max and is getting me ~17fps. Slow, but, if everything pans out, significantly faster than my old process.

[jagabo]

You can use a faster preset in QTGMC and get faster processing but still pretty good results.

[Downgraded286]

I'm not worried about the slow speed, if it really was only 6fps I'd be okay with it. I just don't want it to be slower than it could be because it's not using all my resources. Everything seems to be working out though.

[KarMa]

Yeah, I don't find massive differences between the QTGMC presets, so I tend to use the fastest non-yadif setting "super fast". But there is an obvious difference in quality between Yadif and the preset "super fast", with Yadif being worse. I don't use the preset "ultra fast" as that uses Yadif.

Standard QTGMC can't really use more than one core, compared to x264 which has great multithreading abilities.

[Downgraded286]

Well, it appears to me that my new process should be able to go as follows:
1. Rip DVD with MakeMKV, rename files appropriately, shove in folder
2. Point MeGUI to folder, say go to work and hey, it's done in 1/4 the time as before with much less effort! Might have to tweak the AviSynth settings depending on the original PAR...

Next thing to figure out is how to use MeGUI without AviSynth for things I want to encode that don't require deinterlace or detelecine. Or continue using Handbrake for that.

[hello_hello]

I'm running into a roadblock with MeGUI.

Well, nevermind, tweaking edithreads value loaded my CPU to the max and is getting me ~17fps. Slow, but, if everything pans out, significantly faster than my old process.

I've never tweaked "editthreads" because I don't use a multithreaded Avisynth. For multithreading I run more than one encode at a time. MeGUI can run two or more simultaneously according to the number of "Workers" you have enabled. I find that a lot more stable than multithreading, but whetever works for you.

[Downgraded286]

In the MeGui AviSynth settings, there's a box for max width. What's this for? Mine was set to 720 by default, but I ran a larger video through to see what would happen, thinking the video would be resized, but it wasn't.