Resize Filter UI Improvement

[butterw]

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) ?

[butterw]

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.   

[eumagga0x2a]

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.

[butterw]

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.
 

 

[xyzzy]

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.

[alexstorm]

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

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.

[eumagga0x2a]

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

Spline added, bogus default fixed a month ago.

How 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).

[butterw]

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

Spline added, bogus default fixed 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 ?
   

[eumagga0x2a]

If 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/

It would be useful to know the parameters used

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

As a side note how to know which version of ffmpeg avidemux is built-on ?

"Help" --> "About"

[butterw]

If 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/

As 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.

[eumagga0x2a]

On 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...

The 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.

you 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/

[butterw]

On 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...

The 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.

[eumagga0x2a]

The ffmpeg version should probably be mentionned somewhere in the release notes

It was. To be always up-to-date, please bookmark https://github.com/mean00/avidemux2/blob/master/cmake/admFFmpegVersion.cmake.

Latest 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.

If 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.

[butterw]

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).

[eumagga0x2a]

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} 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.