Avidemux Forum

Trimming videos is a common use case for Avidemux. So I'm confirming my feature request for the addition of a visual indicator (bar) on the timeline when the video has been trimmed (at the start of the end).

New nightly 210702
-Resample FPS filter now has Motion Interpolation option
-Chaining Resample FPS (with motion interpolation) and Change FPS slow motion effect can be achieved
-New filter: Quadrilateral transformation
-Search Black Frame buttons removed from the navigation widget
-Main window's widget visibilities are saved
-Rubber band visibility remembered per filter type
+bugfixes

New nightly 210714
-New filter: Image stabilizer (Reduce camera shakiness)
-Crop: autocrop can do perfect crops (if the scene is not too dark)
-swsResize: nearest neighbor option
-decoder support for planar GBR pixel format
-mp4 demuxer VP9 support
-fixing multithreaded decoding issues
-improved UI responsiveness during playback
-improved UI responsiveness during navigation (ie. performing repeated or continuous next frame/previous frame/etc. actions)
+bugfixes

Quote from: szlldm on July 15, 2021, 01:23:12 AMNew nightly 210714
-New filter: Image stabilizer (Reduce camera shakiness)

Where can I find documentation on the role of the GRAVITY parameter?

Dan.

Quote from: dosdan on July 15, 2021, 10:42:37 PMWhere can I find documentation on the role of the GRAVITY parameter?

There is none (yet)
Basically it means, with how much "force" will it pull back the frame to the center.
If the camera do panning, without "gravity" the frame would slide out of the image.

I'm thinking on an auto-gravity option.

Quote from: szlldm on July 15, 2021, 10:54:33 PMI'm thinking on an auto-gravity option.

An auto-crop/auto-zoom feature like in FFMPEG's libvidstab (based on http://public.hronopik.de/vid.stab/features.php?lang=en) would be nice. I made a batchfile testbench to experiment with it.

stab_testbench.bat
@echo off
setlocal
cls

rem Mode 1: Process file & then compare against original.
rem Mode 2: Compare two clips - no processing.
rem Mode 3: Final output processing of file - reanalyse.
rem Mode 4: Final output processing of file - reuse transform_vectors.trf.
rem Mode 5: Compares 2 processed versions (different output settings) - modes 3, 4, then 2.
set mode=1
set duration=30
set loglevel=info

rem *** Analysis Settings Modes 1,3 ***
set stepsize=2
set shakiness=10
set accuracy=15
set in_file=shaky_480p.mkv

rem *** Comparison Settings Modes 2,5 ***
set file1=30s_smoothing15.mkv
set file2=30s_smoothing30.mkv
set fontfile='c\:/windows/fonts/ariblk.ttf'
set fontsize=48

rem *** Output Settings Modes 1,3,4,5 ****
set outputname=Final.mkv
set smoothing=15
set unsharp=5:5:0.8:3:3:0.4
if %mode%.==5. set outputname=%file1%

rem *** Output Settings Mode 5 (clip from 2nd run) ****
set smoothing2=30
set unsharp2=5:5:0.8:3:3:0.4

if %mode%.==2. goto :COMPARE
if %mode%.==4. goto :OUTPUT_MODE
if %mode%. NEQ 1. (if %mode%. NEQ 3. (If %mode%. NEQ 5. (Echo Invalid mode # & goto :EOF)))

echo ***************************************************************************************
echo Analysing...
echo.
ffmpeg -i %in_file% -t %duration% -y -hide_banner -loglevel %loglevel% -vf vidstabdetect=stepsize=%stepsize%:shakiness=%shakiness%:accuracy=%accuracy%:result=transform_vectors.trf -f null -
echo.

if %mode%.==3.  goto :OUTPUT_MODE
if %mode%.==5.  goto :OUTPUT_MODE

:STAB_and_COMP
echo ***************************************************************************************
echo Stabilising and Comparing...
echo.
if "%loglevel%"=="debug" pause & echo.
ffmpeg -i %in_file% -t %duration%  -y -hide_banner -loglevel %loglevel% -preset slow -codec:a copy -filter_complex "vidstabtransform=input=transform_vectors.trf:zoom=0:smoothing=%smoothing%,unsharp=%unsharp%[stab],[0:v:0]pad=iw*2:ih[bg];[bg][stab]overlay=w,drawtext=text=Shaky:fontfile=%fontfile%:fontsize=%fontsize%:x=0:y=0,drawtext=text=Stabilised:fontfile=%fontfile%:fontsize=%fontsize%:x=w/2:y=0" compared.mkv
start /wait "C:\Program Files\MPC-BE x64\mpc-be64.exe" compared.mkv
goto :EOF

:COMPARE
echo ***************************************************************************************
echo Comparing...
echo.
echo ffmpeg -i %file1% -t %duration%  -i %file2% -t %duration% -y -hide_banner -loglevel %loglevel% -preset fast -codec:a copy -filter_complex "[0:v:0]pad=iw*2:ih[bg];[bg][1:v:0]overlay=w,drawtext=text=%file1%:fontfile=%fontfile%:fontsize=%fontsize%:x=0:y=0,drawtext=text=%file2%:fontfile=%fontfile%:fontsize=%fontsize%:x=w/2:y=0" compared.mkv
ffmpeg -i %file1% -t %duration%  -i %file2% -t %duration% -y -hide_banner -loglevel %loglevel% -preset fast -codec:a copy -filter_complex "[0:v:0]pad=iw*2:ih[bg];[bg][1:v:0]overlay=w,drawtext=text=%file1%:fontfile=%fontfile%:fontsize=%fontsize%:x=0:y=0,drawtext=text=%file2%:fontfile=%fontfile%:fontsize=%fontsize%:x=w/2:y=0" compared.mkv
start /wait "C:\Program Files\MPC-BE x64\mpc-be64.exe" compared.mkv
goto :EOF

:OUTPUT_MODE
echo ***************************************************************************************
echo Stabilising and Outputting... 
echo.
ffmpeg -i %in_file% -t %duration%  -y -hide_banner -loglevel %loglevel% -vcodec libx264 -tune film -preset slow -codec:a copy -filter_complex "vidstabtransform=input=transform_vectors.trf:zoom=0:smoothing=%smoothing%,unsharp=%unsharp%" %outputname%
if %mode%.==5. goto :2ND_RUN
goto :EOF

:2ND_RUN
echo ***************************************************************************************
echo Stabilising and Outputting (2nd run)... 
echo ffmpeg -i %in_file% -t %duration%  -y -hide_banner -loglevel %loglevel% -vcodec libx264 -tune film -preset slow -codec:a copy -filter_complex "vidstabtransform=input=transform_vectors.trf:zoom=0:smoothing=%smoothing2%,unsharp=%unsharp2%" %file2%
ffmpeg -i %in_file% -t %duration%  -y -hide_banner -loglevel %loglevel% -vcodec libx264 -tune film -preset slow -codec:a copy -filter_complex "vidstabtransform=input=transform_vectors.trf:zoom=0:smoothing=%smoothing2%,unsharp=%unsharp2%" %file2%
goto :COMPARE

It requires FFMPEG to have been compiled with libvidstab & libfreetype (for the titles on the side-by-side comparison). These titles also requires a font, here 'c\:/windows/fonts/ariblk.ttf'.

Here's a 30s side-by-side comparison of the result of operating in Mode 1, "Process file & then compare against original", of the shake reduction:

https://dl.dropbox.com/s/254fayqtsfilorz/compared.mkv

You can clearly see the auto-crop/auto-zoom in action.

The batchfile ends by automatically playing the comparison video in a video player in another window:

start /wait "C:\Program Files\MPC-BE x64\mpc-be64.exe" compared.mkv

If you want to try your IS method on this source, it's a 480p YT d/l of "What is "no-chilling" home brew?" https://www.youtube.com/watch?v=Ih3jg3Xdcvs

Dan.

Thanks for the sample video! It is more shaky than those i tested with.
A fear an auto-zoom function would be problematic with the current filter, because it is single pass (for now). But an auto-gravity option would improve on it.

New nightly 210731
-Image stabilizer auto-gravity option
-Feedback by busy cursor during navigation
-Resize and Crop filters display output aspect ratio and nearest common ratio (e.g 1.7778 and 16:9)
-Toolbar can be hidden
-Encoding dialog displays output file name (full path), option (default value can be set at the Preferences) for deleting first pass temporary files
-Properties dialog displays average video bitrate

New nightly 210823
-New filter: Zoom (partializable crop filter)
-New filter category: Transition
-New filters: Fade from image, Fade in, Fade out and Fade through
+bugfixes

The last round of nightlies contains a major change in behaviour:

• Segments are created automatically aligned at the PTS of the first frame (a video seems to start at zero). The purpose is to facilitate adding segments by hand via tinyPy scripts. Now it is not necessary to match a PTS in the source video perfectly, which was often a challenge. The duration of the segment is automatically reduced.
• The frame matching the position of the marker B is now excluded from the range (as it should, actually). The reason is that in a typical use case editing an open GOP type video in copy mode, a standalone non-IDR keyframe at the end of video may be not fully decodable (it may require later frames which are missing). If marker B is set to the last picture of a video, it is now necessary to seek to marker A, reset markers and set marker A to extend marker B to the end of the video, else the last picture won't be included when saving the output. An option to extend (i.e. to reset)  the marker B alone is being contemplated.

Bugfixes (incomplete list):

• Seek to cut points optimized, should be faster in many cases.
• Old project scripts referencing retired hflip and vflip video filters are now automatically handled by the new all-in-one flip filter instead of triggering a crash.
• The CBR mode in the ffMpeg2 video encoder now does CBR.
• PTS reconstruction for cases like H.264 with B-frames in AVI container is now able to handle field-encoded video streams, doesn't drop the last few frames.
• The Matroska demuxer is now less prone to produce duplicated PTS in files which are perfectly fine.
• The OpenDML (AVI) demuxer won't cut the video short when B-frames are present.
• fadeTo and fadeToBlack filters on macOS produced wrong colors (purple tint) – now fixed.
• VideoToolbox H.264 encoder on macOS was broken when B-frames were disabled – fixed.
• A lot of memory leaks all over the place found and fixed.

Quote from: eumagga0x2a on August 24, 2021, 06:07:38 AMThe last round of nightlies contains a major change in behaviour:

• Segments are created automatically aligned at the PTS of the first frame (a video seems to start at zero). The purpose is to facilitate adding segments by hand via tinyPy scripts. Now it is not necessary to match a PTS in the source video perfectly, which was often a challenge. The duration of the segment is automatically reduced.
• The frame matching the position of the marker B is now excluded from the range (as it should, actually). The reason is that in a typical use case editing an open GOP type video in copy mode, a standalone non-IDR keyframe at the end of video may be not fully decodable (it may require later frames which are missing). If marker B is set to the last picture of a video, it is now necessary to seek to marker A, reset markers and set marker A to extend marker B to the end of the video, else the last picture won't be included when saving the output. An option to extend (i.e. to reset)  the marker B alone is being contemplated.

I'm trying to understand what has been changed here.  A typical use case for me it to load a video, trim off a little at the start (in which case I have been setting the B marker to the first frame I want to keep), trim off a little at the end (in which case I set the A marker to the first frame I want to delete), and also sometimes remove one or more sections in the middle.  For those, I set the A marker to the first frame I want to remove, and the B marker to the first frame I want to keep following the delete.  Are you now saying this is going to change?  I really hope not.

Basically, most of the editing I do requires that I be able to make precise cuts at particular points.  I can't have frames left behind that should have been cut, nor cuts that extend beyond the cut points I set.  Please tell me you are not making Avidemux less precise in this regard.  I don't understand what you mean when you are talking about PTS, or a "GOP type video", all I know is you appear to be saying that setting the A and B points will not produce a precise cut as was the case in the past, or maybe that setting the B frame will not make the cut in the same place as it would have in the past?  I REALLY hope I am wrong about that.  Please be aware that some of us don't really understand or pay much attention to the various types of frames; as long as the cuts or edits are made where we set the markers we're happy.

Quote from: eumagga0x2a on August 24, 2021, 06:07:38 AMBugfixes (incomplete list):

• .....
  
• A lot of memory leaks all over the place found and fixed.

Could this be the reason that my Mac has sometimes been getting flaky and then crashing when I have been running Avidemux for several sessions?  Does Avidemux clear these memory leaks when the program is closed (prior to this version), or is that impossible to do?  You also mention that "fadeTo and fadeToBlack filters on macOS produced wrong colors (purple tint) – now fixed" but I assume that refers to the new filters introduced in version 210823, not the Fade To Black filter that's been part of Avidemux for many versions now, because I've never noticed a purple tint in that.  Anyway where I am going with this is that if these changes affect MacOS (ESPECIALLY the memory leak issue), how about making a new MacOS nightly? I would really like to see if those fixes stop all the annoying crashes that I have been blaming on Catalina all this time!

Quote from: Who on August 26, 2021, 05:07:51 AMA typical use case for me it to load a video, trim off a little at the start (in which case I have been setting the B marker to the first frame I want to keep), trim off a little at the end (in which case I set the A marker to the first frame I want to delete), and also sometimes remove one or more sections in the middle. For those, I set the A marker to the first frame I want to remove, and the B marker to the first frame I want to keep following the delete.

Nothing has been changed here. The change affects the scenario when you save the selection from A to B. Now the picture matching B is not included (this is new, or, more precisely, this marks the return to the old behaviour from about 4 years ago).

Quote from: Who on August 26, 2021, 05:07:51 AMBasically, most of the editing I do requires that I be able to make precise cuts at particular points.  I can't have frames left behind that should have been cut, nor cuts that extend beyond the cut points I set.

As long as you re-encode, you can have the precision. There is none when you use the copy mode. Nothing has changed here.

Quote from: Who on August 26, 2021, 05:07:51 AMCould this be the reason that my Mac has sometimes been getting flaky and then crashing when I have been running Avidemux for several sessions?

I don't think so. But as the crash seemed to happen at the end of encoding, it might be related to the issues tackled by this commit for the filter manager only. If you run Avidemux from Terminal, reproduce the crash and provide its "last words" (a couple of pages worth or console output, please), it might help to assess the problem.

Quote from: Who on August 26, 2021, 05:07:51 AMYou also mention that "fadeTo and fadeToBlack filters on macOS produced wrong colors (purple tint) – now fixed" but I assume that refers to the new filters introduced in version 210823, not the Fade To Black filter that's been part of Avidemux for many versions now, because I've never noticed a purple tint in that.

No, the fixes correct the issue in the old filters.

Quote from: Who on August 26, 2021, 05:07:51 AMhow about making a new MacOS nightly?

I'd love it (I have no control over when it happens).

Quote from: eumagga0x2a on August 26, 2021, 07:05:58 AM

Quote from: Who on August 26, 2021, 05:07:51 AMCould this be the reason that my Mac has sometimes been getting flaky and then crashing when I have been running Avidemux for several sessions?

I don't think so. But as the crash seemed to happen at the end of encoding, it might be related to the issues tackled by this commit for the filter manager only. If you run Avidemux from Terminal, reproduce the crash and provide its "last words" (a couple of pages worth or console output, please), it might help to assess the problem.

First, thank you for the detailed response.  It is strange I have never noticed the purple tint on the fade to black but I am not complaining!  But as for the crashes, it may be a different issue because they don't typically happen at the end of encoding, at least not as far as I can tell.  What happens is that the system starts getting unresponsive, particularly for other software - Avidemux will keep working fine until the system dies completely (usually indicated by the clock in the top bar not updating).  But for example I might try to open a web browser, or some other piece of software, and the icon in the dock will just bounce for two or three minutes and then stop.  Or if I try to close an open program, it will take several minutes, assuming the system doesn't freeze.  If I walk away and leave it alone, Avidemux will usually continue until it completes, but if I insist on trying to open or close programs the system will generally freeze completely and require a hard power off (using the power switch).  So far it has always come back up once I hit the power switch and then everything works as it should, which is what has made me suspect a memory leak of some kind, but I never knew what was causing it.  I can't say for certain it has been Avidemux but I definitely would like to try the new version to see if it reduces or eliminates the occurrences of this problem.

This indeed looks like a different issue. If all source videos triggering the problem were exclusively MPEG-TS or -PS files, then you should profit from some nasty debug messages disabled by this commit. They could fill the log file /tmp/admlog.txt which is created when Avidemux is not run in Terminal with hundreds of megabytes of data.

In doubt, let a Terminal window open with top running while you are using Avidemux to monitor system load in real time.

Quote from: eumagga0x2a on August 26, 2021, 04:46:40 PMIn doubt, let a Terminal window open with top running while you are using Avidemux to monitor system load in real time.

This is a typical top line I see when I run top (not counting the column headers):
3044   Avidemux2.7  358.3 14:38:19 19/6  1    304   820M   0B     157M   3044  1    running  *1[3774]      0.00000 0.00000    501  4722093  1762  1911315+  553969+   18856886+ 7183590+  105089162+ 4365     6628    358.3 12246355863

The line continually changes (looks like every second or so) but Avidemux2.7 stays right up there.  Nothing else even comes remotely close in terms of CPU usage.