Avidemux Forum

1. Should round to mod8 by default (vs only mod16). 1080p is mod8 not mod16 !
2. Should display the output Aspect Ratio (ex: 1.778 - 16/9, 4/3, 9/16, 21/9)
and display the mod level ex: mod16, especially if it is too low (mod-4, mod-2)

(Improvements to resize functionality:)
3. More/updated options for resize: more Algorithms + parameters, bicubic should be default (for downscaling) ?

Spline36Resize seems to be the current go-to resizer in avisynth: http://avisynth.nl/index.php/Spline36Resize.
Mitchell-Netravali family Bicubic(B, C) can also be used.
Lanczos is not recommended for downsizing compressed sources.

Regarding the mod setting:
mod-16 is best, but modern codecs can all handle mod-8 (because 1080 is mod-8)
Say you had to crop the source video and want to resize down, the GUI doesn't give you enough help in determining the right resize dimensions.   

At the codec level, 1920x1080 is in most cases not really 1920x1080, it is 1920x1088 with 8 lines at the bottom cropped. I realize that with 16 as roundup value, it is impossible to input 1920x1080, which is IMHO a minor inconvenience.

This "Resize" filter provides GUI access to some features offered by libswscale in FFmpeg, other providers should be exposed in dedicated plugins. In any case, code contributions are welcome, but further work on swsResize plugin in not on my todo list.

Thank you for your input.

I suggest the output Aspect Ratio could be displayed in the Crop and Resize Filters (as a numerical value ex: 1.3750, except in the case of exact 4:3, 16:9, 9:16 ratios).
This simple fix would significantly improve usability.
 

 

Have a go at it.  It really shouldn't be that hard.  I'd never worked on a Qt graphical app before and fixed up the x265 options with one night of hacking.

I created an online calculator for video resizing with version 2.7 for Windows.  It's especially helpful after removal of black bars. 

https://www.producerelease.com/blu-ray/parcalc.htm (https://www.producerelease.com/blu-ray/parcalc.htm)

For all .mkv videos it's much easier to use the Mkv Muxer - Configure and force a new default display width that is just 16/9 * the current video height. For DVD's that would 480 * 16/9 = 853 and you are done.  I have a calculator for this on my page so you can match any aspect ratio you like.

===

I realize now, I don't really need to use Video Output Configure to resize the video, because the Mkv Muxer Force a new default width does the job.  Before I figured that out, I wanted to see what was going on with the mkv encoder - Output 1 settings Pixel Aspect Ratio (DAR).

For example:  Say you have a 16:9 720 x 480 DVD with black bars top and bottom.
Custom - Pixel Aspect Ratio (DAR):
16:9 will show very squashed and not do what you expected to see.
32:27 (a ratio of 1.185) works and makes the video look normal in 16:9 format with the black bars in place.  Sure enough, 32:27 is listed in the pulldown Predefined Aspect Ratio to force the change to 16:9.

So where did 32:27 come from?

We are changing display video playback. We are not actually adding any pixels anywhere.

We know that 480 height * 1.778 is 853.  Currently the video is 720 wide.  So, what does it take to make 720 into 853?  The answer is 32/27.0002. Aha!

This is the formula
  A = 32 and B = 27,
  r = 1.778 (16:9)
  w = 720 and h = 480

  A * w / h / r = B

  You can run this for any value A and get a B value.  Let's pick A=16.  Then B=13.50006... Hmmm.  Let's try just A=1 to see if that is easier.  Then B = 0.843754.  This is all fine, but the Output 1 Custom Pixel Aspect Ratio entry only takes whole numbers. And that is the problem.

  How do you find custom matching whole numbers for your video resize?  32:27 works to change a DVD video source back to 16:9 but what if you crop out the black bars first and get a video is 720 x 372.  You check and the original ratio for this film and it is 2.35. Run the formula for A=1 we get B = 0.8236. Buzzer!!!  You can't enter decimals into the Custom fields and the numbers only go up to 9999.  You could just take A=9999 and make B=8235. That should be close enough. I put a calculator for these numbers on the project page link above.  It finds the best whole number ratios for Output 1 Custom Pixel Aspect Ratio.

  For this example of removal of black bars to get a video 720 x 372. Using the calculator and raising the range up to 1500, a perfect ratio pops up as 1457:1200.  Hurray!

  But you don't need it, the Mkv Muxer Configure Forced Display Width is easier.  Force width to 874 and you are done.

  Anyway, hopefully that answers the puzzle of what was going on with that strange ratio setting. Try out the calculator.  It's very colorful. It was my Saturday coding project.

Quote from: butterw on July 23, 2020, 08:28:06 PM3. More/updated options for resize: more Algorithms + parameters, bicubic should be default (for downscaling) ?

Spline added, bogus default fixed (https://github.com/mean00/avidemux2/commit/a12cdad1480670e4eaa5576a4c1e4d3754e6ca65) a month ago.

Quote from: alexstorm on December 13, 2020, 09:53:28 PMHow do you find custom matching whole numbers for your video resize?

av_d2q(double d, int max)

from libavutil/rational.h (if it may be C).

Quote from: eumagga0x2a on December 13, 2020, 11:27:04 PM

Quote from: butterw on July 23, 2020, 08:28:06 PM3. More/updated options for resize: more Algorithms + parameters, bicubic should be default (for downscaling) ?

Spline added, bogus default fixed (https://github.com/mean00/avidemux2/commit/a12cdad1480670e4eaa5576a4c1e4d3754e6ca65) a month ago.

Yes, I saw it on github. These improvements are very much appreciated, thanks. If there are dev-builds for windows, I would be happy to try them out.
Bicubic and Spline typically come with additionnal parameters. It would be useful to know the parameters used (ex:
catmull-rom (b=0, c=0.5) is a lot sharper than bspline (b=1, c=0)). As a side note how to know which version of ffmpeg avidemux is built-on ?
   

Quote from: butterw on December 31, 2020, 10:01:55 AMIf there are dev-builds for windows, I would be happy to try them out.

Of course there are nightlies for Windows:

cross-compiled with MinGW on Linux: https://avidemux.org/nightly/win64/
native builds compiled with VC++ on Windows: https://avidemux.org/nightly/vsWin64/

Quote from: butterw on December 31, 2020, 10:01:55 AMIt would be useful to know the parameters used

Currently, just the default (i.e. none).

Quote from: butterw on December 31, 2020, 10:01:55 AMAs a side note how to know which version of ffmpeg avidemux is built-on ?

"Help" --> "About"

Quote from: eumagga0x2a on December 31, 2020, 10:12:23 AM

Quote from: butterw on December 31, 2020, 10:01:55 AMIf there are dev-builds for windows, I would be happy to try them out.

Of course there are nightlies for Windows:

cross-compiled with MinGW on Linux: https://avidemux.org/nightly/win64/
native builds compiled with VC++ on Windows: https://avidemux.org/nightly/vsWin64/

Quote from: butterw on December 31, 2020, 10:01:55 AMAs a side note how to know which version of ffmpeg avidemux is built-on ?

"Help" --> "About"

On Win10, with the stable version I only get avidemux 2.7.6 release. Also true for 2.7.1 release (also installed).
Avidemux v2.7.7 (201229_) nightly does have fflibs4.2.4. info.

The nightly uninstalled my previous VC++ x64 2.7.6 stable release (Note: this happens even if you don't agree to it !!!).

I'd forgotten about the dev-builds, you probably should add links to the nightlies and this forum on your github repo readme and in the release notes.

Quote from: butterw on December 31, 2020, 11:33:13 AMOn Win10, with the stable version I only get avidemux 2.7.6 release.

You are right, I forgot about it as I never use releases...

Quote from: butterw on December 31, 2020, 11:33:13 AMThe nightly uninstalled my previous VC++ x64 2.7.6 stable release (Note: this happens even if you don't agree to it !!!).

They cannot coexist when installed. You can copy the program directory elsewhere and use as a portable build, just don't run both simultaneously. Official MinGW builds are provided also as ZIP archives.

However, if declining uninstall of the previous version doesn't just cancel installation and proceeds with uninstall instead, this is a bug.

Quote from: butterw on December 31, 2020, 11:33:13 AMyou probably should add links to the nightlies and this forum on your github repo readme and in the release notes.

Nightlies are mentioned at the top of http://fixounet.free.fr/avidemux/download.html linked from https://www.avidemux.org/

Quote from: eumagga0x2a on December 31, 2020, 11:48:27 AM

Quote from: butterw on December 31, 2020, 11:33:13 AMOn Win10, with the stable version I only get avidemux 2.7.6 release.

You are right, I forgot about it as I never use releases...

Quote from: butterw on December 31, 2020, 11:33:13 AMThe nightly uninstalled my previous VC++ x64 2.7.6 stable release (Note: this happens even if you don't agree to it !!!).

They cannot coexist when installed. You can copy the program directory elsewhere and use as a portable build, just don't run both simultaneously. Official MinGW builds are provided also as ZIP archives.


However, if declining uninstall of the previous version doesn't just cancel installation and proceeds with uninstall instead, this is a bug.

Looks like a bug. The only choice given in the uninstall dialog is OK. When you try to bypass it, it still proceeds with uninstalling.

The ffmpeg version should probably be mentionned somewhere in the release notes or logs (if troublesome to add to the "About" for Releases).
Latest stable FFmpeg 4.3.1 "4:3" released on 2020-07-11, 4.2.4 was the the previous stable.

Renaming the folder to avoid uninstall and portable mode OK. If I'm understanding correctly avidemux doesn't use registry, but it uses AppData\Roaming\avidemux in the profile to store settings ? Both my installed versions seem to be using the same config3 settings file.

Quote from: butterw on December 31, 2020, 12:40:42 PMThe ffmpeg version should probably be mentionned somewhere in the release notes

It was (https://github.com/mean00/avidemux2/commit/70efbd78987fd664e5127ccf78288dd26b021f04#diff-5512f2ffeb21093400f360b8d4a23a1a345439aa7d01657c0471720b8c703fdb). To be always up-to-date, please bookmark https://github.com/mean00/avidemux2/blob/master/cmake/admFFmpegVersion.cmake (https://github.com/mean00/avidemux2/blob/master/cmake/admFFmpegVersion.cmake).

Quote from: butterw on December 31, 2020, 12:40:42 PMLatest stable FFmpeg 4.3.1 "4:3" released on 2020-07-11, 4.2.4 was the the previous stable.

Sure. Some useful stuff has missed the 4.3.x branch, so I hope to be able to go for 4.4.x or whatever when it gets released after 2.7.7 is out.

Quote from: butterw on December 31, 2020, 12:40:42 PMIf I'm understanding correctly avidemux doesn't use registry, but it uses AppData\Roaming\avidemux in the profile to store settings ?

Correct, the registry is not used (or rather it is used, but only by the installer). Therefore, Avidemux doesn't need to be installed, extracting an archive containing the program directory at any not-network location is enough.

To avoid conflicts, potentially messing up the configuration, run Avidemux as a "portable app" (rename "avidemux.exe" to "avidemux_portable.exe") to instruct it to place the profile in the program directory (which must be writable). In general, don't run multiple instances of Avidemux concurrently.

from https://ffmpeg.org/ffmpeg-scaler.html:
param0, param1: Set scaling algorithm parameters. The specified values are specific of some scaling algorithms and ignored by others. The specified values are floating point number values.
- ex: Lanczos(3.0)
based on user comments (I haven't done any verification tests): 
- ffmpeg default is bicubic(Catmull-Rom): sharp bicubic, mitchell(B=0, C=0.5)
- "spline" is sharper than avisynth's spline16, but softer than spline36

So it seems avidemux now has 3 sharp resizers. Adding param0/param1 could provide a smoother option with bspline bicubic(1, 0).

The API of libswscale wrapper ADMColorScalerFull would need to be extended to allow to pass parameters. This is not a big deal, just

a) I am happy with the default {0, 0.6} (https://github.com/FFmpeg/FFmpeg/blob/c9f3835b2b4d2f50a20113caa0a2d23107fe3f89/libswscale/utils.c#L440) for bicubic and

b) wrapping an API into a GUI in a way which helps the big majority to use the tool rather than giving more powers to a tiny minority who is able to use the command line tool anyway is a difficult task.

Next release cycle, maybe.

Sure, and sharp bicubic is a good default.

I don't use this resize interface very often, but each time I do, I feel like it needs basic improvements.
Maybe adding a textbox to the right of error X/Y with the output Aspect Ratio would be feasible ?
ex: AR: 1.778 (16/9)
Currently to get the desired result you have too know the right output resolutions. An average user will often get it wrong.

Quote from: butterw on January 02, 2021, 08:32:14 PMMaybe adding a textbox to the right of error X/Y with the output Aspect Ratio would be feasible ?
ex: AR: 1.778 (16/9)

It wouldn't be difficult to show (storage width / storage height) as a float, but how should this help the user?? For the use case of output display using square pixels only?

Quote from: butterw on January 02, 2021, 08:32:14 PMCurrently to get the desired result you have too know the right output resolutions.

By specifying the desired display aspect ratio or display width in muxers which support this (MKV, WebM, MP4 and MOV), the necessary pixel aspect ratio is automatically calculated based on pixel size of the source. No effort on user side required.

Quote from: eumagga0x2a on January 02, 2021, 08:53:00 PM

Quote from: butterw on January 02, 2021, 08:32:14 PMMaybe adding a textbox to the right of error X/Y with the output Aspect Ratio would be feasible ?
ex: AR: 1.778 (16/9)

It wouldn't be difficult to show (storage width / storage height) as a float, but how should this help the user?? For the use case of output display using square pixels only?

I only use square pixels (PAR=1 ?) I don't know what the buttons at the top of the interface do. Probably the output Width/Height*PAR should be displayed if possible. This output display would avoid having to copy/paste out the values and manually calculate the AR for each suggested set of values. The error X/Y display is one thing that does work well in this interface.

Quote

Quote from: butterw on January 02, 2021, 08:32:14 PMCurrently to get the desired result you have too know the right output resolutions.

By specifying the desired display aspect ratio or display width in muxers which support this (MKV, WebM, MP4 and MOV), the necessary pixel aspect ratio is automatically calculated based on pixel size of the source. No effort on user side required.

You also need to know the output AR to use DAR. You have to be near the desired ratio to apply DAR, otherwise you get a significant AR error.
 
Output Format > configure > DAR is in a different somewhat hidden, interface so it seems easy to forget about.
One thing missing seems to be a 9/16 DAR (increasingly popular in mobile/internet videos).
I don't know what display width does in avidemux.

I do personally prefer mod-16 exact ratios: no possible issues down the line (video players, muxers, editors, etc.). 
I've checked rotation and it doesn't round-trip. Meaning a mp4 file with a rotation tag doesn't get auto-rotated when it is opened in avidemux.
Is mp4 container DAR preserved though a basic remux with ffmpeg, or a conversion to mkv ? If the user goes through the trouble of setting parameters, they need to stick by default.

Quote from: butterw on January 02, 2021, 11:05:40 PMI only use square pixels (PAR=1 ?)

If you never need to create a DVD video or work with output of HDV camcorders, this is fine.

Quote from: butterw on January 02, 2021, 11:05:40 PMI don't know what the buttons at the top of the interface do.

The menus apply a factor to width or height in pixels to account for PAR specific to selected scenario. If you work with square pixels only, why are you concerned about aspect ratio at all? Whatever dimensions you set will work right, just keep aspect ratio locked. The whole complexity arises only from anamorphic video.

Quote from: butterw on January 02, 2021, 11:05:40 PMYou also need to know the output AR to use DAR. You have to be near the desired ratio to apply DAR, otherwise you get a significant AR error.

This setting in the muxers creates anamorphic video, yes.

Quote from: butterw on January 02, 2021, 11:05:40 PMOne thing missing seems to be a 9/16 DAR (increasingly popular in mobile/internet videos).

As you noticed later down the post, this one simply doesn't exist. It is 16/9 rotated.

Quote from: butterw on January 02, 2021, 11:05:40 PMI've checked rotation and it doesn't round-trip. Meaning a mp4 file with a rotation tag doesn't get auto-rotated when it is opened in avidemux.

Correct, this is by design. The only metadata which will round-trip ATM is color info (matrix coeficients, color primaries, transfer characteristic, color range) from MKV to MKV in copy mode.

Container DAR was created for anamorphic (DVD) videos yes. But it can also be used to fix videos that don't have a perfect ratio (ex: near 9/16) to avoid padding at playback (with a negligible AR error).
These container parameters can be useful to fix a video (ex: rotation), but I don't use them if I'm (re)-encoding because I know they are not well supported in editors.

Resizing implies there is re-encoding. To be useful the GUI needs to help with the following:
1. the output dimensions should really be mod-16 (or at least mod-8).
2. the AR error should be small
3. the output AR also needs to be a perfect (or at least near perfect) ratio, and currently the GUI provides no info on this point.

There are very few mod-16 perfect ratios, and it isn't the only AR that users have to deal with. So having an output display would be helpful ex: 1.778.
I never encounter non-square pixel so I can't comment on whether it is a perfect solution for this use case, but at least it does no harm and it seems simple enough to implement.

Quote from: xyzzy on December 03, 2020, 09:21:41 AMHave a go at it.  It really shouldn't be that hard.  I'd never worked on a Qt graphical app before and fixed up the x265 options with one night of hacking.

Is it possible to modify/recompile an existing filter plugin and it's ui without recompiling the whole of avidemux ?
As long as the I/O remains unchanged, I would assume the modified plugin could be used with an existing build of Avidemux ?
I'm using the VC++ 2.7.7 version on Win10, what software configuration would be required for this (and is there a guide) ?
 

I wonder whether https://avidemux.org/smif/index.php?msg=88622 is still valid.

Some user feedback on the GUI changes, based on testing of the latest Win64 dev build (210118):
- The change with cutting/deleting at the end seems to work well. 
- [resize GUI] the default should be mod-16 values rather than no-rounding
- [resize GUI] The interface as tested provides very little useful info if AR Locked is unchecked.
My suggestion would be to always display the numerical value of output AR next to X/Y error as discussed in my forum post. When the interface is opened it also shows the source AR, which is key to determine if AR should be Locked.
- [crop GUI] displaying the numerical value of Output AR would be useful (or the source AR in the keep-AR box)
- [crop GUI] being able to move around the crop Window would be nice (crop values would need to adjust once it's done...)
- [mplayer eq2] the luma histogram is a great addition, if possible the 16-235 limit bands could be dashed or colored

!!! Since v2.7.7 the resize GUI no longer allows to force a mod value (ex: mod-16) if lock Aspect Ratio is unchecked.

EDIT:
with TinyPy  width and height are not taken into account when full parameters are not provided. Is this a bug ?
adm.addVideoFilter("swscale", "width=640", "height=360", "algo=1") returns 1, the filter is added but does not resize, I would expect the provided width and height values to be enforced by default.

The full command which does work is available in the saved project:
adm.addVideoFilter("swscale", "width=640", "height=360", "algo=1", "sourceAR=0", "targetAR=0", "lockAR=True", "roundup=2")
roundup sets the GUI parameter for rounding
- 0: no rounding
- 1: mod-16 rounding
- 2: mod-8 rounding
It would be good if parameter reference for filters was provided somewhere (what they do, their default values and range).

Is it possible to specify a single dimension (w or h), lockAR and mod-8 rounding ?

Quote from: butterwIs it possible to specify a single dimension (w or h), lockAR and mod-8 rounding ?

It seems you currently must specify both w and h, but it's possible specify for instance the same value for both and the filter will then auto-update if the resize filter interface is opened in the GUI.

EDIT: Its possible to write a resize wrapper function with TinyPy, but it could only know the resolution of the input video, which would be different from the current resolution if a crop filter has been applied.

Can swscale filter downsize a video of arbitrary dimensions to a minimal dimension (ex: wh_min=288), via script ? 
- with Mod-8 output Resolution
- while preserving Aspect Ratio (small error acceptable)

If you invoke swsResize from a tinyPy script, you need to calculate output dimensions in Python. All the aspect ratio preserving and dimensions roundup happens in the Qt configuration dialog only, which is not involved here.

I wonder what content you all are working with.  If it's original master from a current camera, then the aspect ratio 16:9  or 1.77777778 is correct.  Older master content will match the camera.  But any other content that is a republished version is not necessarily correct.  Some aspect ratios of this type of content is correct but many are slightly to terribly wrong, stretched or squashed, for many reasons.

At any specific height, the exact correct ratio might be a length that is a fraction and is not available.  You can't enlarge the video to a fraction of a pixel. And with encoders the target width has to be even, to boot.  By the way, this happens about 99% of the time.  So, if you showed an exact fraction ratio it would only match what you expect perhaps 1 in 100 times.

This is the reason why acceptable height sizes are in use online: 480, 720, 1080... and even these numbers don't have an even numbered matching width for ever aspect ratio.

I use the swsResize a lot when getting content from anything other than a camera or post production master video.

I crop out black bars, look up the correct original aspect ratio, take the new height of the cropped video and use my interactive chart to find the best pixel match.  That works most of the time, but for old content already transferred once to digitial that might have additional cropped pixels bringing it back to the original aspect ration might actually go too far.  In those cases you can search for something in a frame that should a circle, like someone iris looking right into the camera, cars passing by with a straight on look at the tire, a straight on look for a clock, or even a match the opening company logos and then tweak the width a little more to fine tune.  If this was to also show the new aspect ratio that fixes everything, it might say some very large fraction and really not be useful.

For example:  The number of pixels widths for content 480 pixels of height is:

1:1.7777778 (16:9) width: 853.3333296... which is unusable, so 854 which is 1.7791666... (pretty close - for HD TV screen it's 1 pixel too wide)

1:1.85 width: 888 (this one actual works, but ironically it's never used on DVD's because post production chooses to show any movie in 1.85 with thin top and bottom black bars so it works on widescreen TV's. If you wish to convert to a copy that keeps the black bars, then 888 is exact.  If you want to crop out the black bars, then the next best pixel combo is 944 x 510 which would be exact for HD TV and 1 pixel too tall for 4K TV... good enough. This assumes playback on the TV with a browser, not through DVD or blu-ray.  The exact ratio of 944 x 510 is: 1.85098039... )

1:2.35 width: 1128 (also works fine, but never used because again, content released in 2.35 uses black bars. the next best pixel size is 912 x 388 which is still accurate at 4K. The ratio, however is 2.3505154...)

So, you are not going to get the fractions or exact ratio numbers you expect if they were printed inside the UI area of sysResize.  How much use is it to see such numbers?  I suppose you could play with the pixel height and width and try to get it as close as possible.  It's not that easy.  I prefer to use the calculators on my page: https://www.producerelease.com/blu-ray/parcalc.htm#v

You can enter the width and the target ratio in the first calculator.  The table below tells how close the width / height combination gets to the target ratio.  There is a right arrow where you can scan upwards to see if the next few sizes get any closer.  You want gold or blue results.

It all get comically complex, pretty quick.  If anyone is interested, you are welcome to use the calculators on my page, mentioned above.

---

The first calculator on the page takes height and target ratio and finds width. It is most useful for cropping content to get rid of black bars and then resizing it exactly right to playback with the correct aspect ratio.  The trick is to find the right pixel ratio in even whole numbers which is what is needed to run the encoder. The lower right arrow button opens the next group of pixel sizes.  You can often find a better ratio match using this arrow button.


The second calculator is further down the page and it takes width and target ratio and finds height.  There is also a list of recommended pixels sizes for each ratio, which is sort of all you need anyway.

The third calculator at the bottom of the page, is really only for forcing the width so the player knows what width to use.  It doesn't work for prepping videos for uploading to the Internet social media or for playback in a browser.  Only full featured video players can pick up on the forced width command.  If all you use is VLC to watch everything, you can use this calculator and force the width.  It does NOT apply to this forum post of using sysResize.

- 16/9 480p should be avoided if possible. 854x480 is low Aspect Ratio error even if it isn't a perfect ratio, but the main issue is that it is only mod-2.

- Cropped videos can end up having any ratio, even if the initial capture was done at 16/9.

- Because of smartphone cameras and screens, portrait mode video is increasingly popular.
In photography, the most commonly used AR for this are 4/5=0.8 and 3/4=0.75. The AR crop in my photo app swaps between landscape and portrait mode (AR=4/3 will mean 4/3 with x>y or 3/4 with x<y). Why can't Avidemux crop filter UI do this ?

- The current swsResize UI isn't much help at all. In a GUI using an external calculator shouldn't be required. Adding a display of output AR to the crop and resize filters is a trivial to implement improvement.

- On mobile devices players, if container DAR correction isn't supported, it may be possible to stretch the video to fit the screen (Width). Black sidebars in portrait mode are very ugly.