November 28, 2021, 06:21:46 AM

News:

--


Avidemux2.7.9 - Latest dev Version thread

Started by butterw, February 17, 2021, 10:34:23 AM

Previous topic - Next topic

eumagga0x2a

You Avidemux session continues since almost 15 hours – this is quite a long encode run! 358.3% CPU load and 820 MiB of allocated memory shoud not be critical (157 MiB of compressed memory indicates that the most of memory on the system is in use and that much memory allocated by Avidemux is not actively accessed).

Have you checked that /tmp/admlog.txt is not growing extremely fast and extremely large for the reasons I mentioned in my last reply?

To improve system responsiveness despite active encode running, you can use

renice -n <value> -p <PID of Avidemux process>
where <value> is a positive figure <= 20 and the PID should be used as reported by

ps -ef | grep Avidemux
(the second column is the PID).

szlldm

New nightly 210905
-new Fade In and Fade Out filters
-x264 encoder has color properties
-Wavelet sharpener has a noise cutoff parameter (to remove sharpened compression artifacts)
-Partial filter markers behaviour changed (frame at B marker excluded)
-Main window's maximized state is persistent
-Reduced window size on loading a video
-Motion interpolation improved quality and performance
-VHS filter has a noise parameter
+bugfixes

Who

Well I am REALLY sorry to have to report this bug - this is the first time I have encountered a bug so bad that it caused me to restore a previous version from my Time Machine backup.  And unfortunately I did not notice this bug until I had already encoded a couple of videos, but for whatever reason they did not seem to be affected (at least I really hope not, my fear is this problem might have shown up in some random spot!).

The problem appears to be that the times you set for partial filters aren't honored, at least when using the Blacken Borders filter.  Instead, the start and/or end gets set to some completely random times! I did a little experimenting to see if I could figure out if there was any logical pattern to it, but it did not appear to be, except that in the very limited experimenting that I did the times actually used will be less than the times you set.  The times display correctly in the filters list, but Avidemux either isn't reading them correctly or something else is happening.  I kept thinking that surely I had somehow made a mistake, or that perhaps it was really doing the filtering but just not showing it in the filtered preview, but after extensive trial and error I figured out that no, it really was not using the times that had been set.  I tried closing and re-opening Avidemux and starting from scratch but had the same result.

So in frustration I went back to the version I'd been using in mid-August (which I think was actually from back in March or thereabouts) and loaded the exact same video and did everything the same as I had done it in the new version, and of course then the filter worked and it ran at the correct time.  I know this is why you release nightlies, to find stuff like this, but since some other issues had been fixed in the new version I was hoping this would be one I could use for a while.  I'm really kind of surprised no one else has reported this yet, maybe it is specific to the MacOS version?

eumagga0x2a

Should be fixed now, thank you for catching it.

The reason was my old blunder which was mostly harmless because it compared values one of which was factor 1000 too high, so that the faulty check actually almost never hit. szlldm has noticed the bug in the check and fixed the check, making it fatal.

eumagga0x2a


Who

It is very late at night here so I'm not ready to start encoding another full video yet (have to sleep sometime), but I did a quick check using the same original video where I had first noticed the problem, using the same filter in the same spot, and now it works as it should.  So, it does appear that the new nightly fixes the bug, so thanks very much for the quick response!

szlldm

New nightly 211003
-new filter: Deband
-fix VDPAU
-preference for loading sequentially named images in reverse order
-menu actions to reset each marker separately
-support for PNG as mp4 video codec

szlldm

New nightly 211026/211027
-HDR tone mapping (settings in Video menu and Preferences)
-TureHD decoder support
-redesigned VU meter (Audio metre)
-extended ProRes decoder support
-"Search previous black frame"

Anon40213

November 04, 2021, 12:09:55 PM #158 Last Edit: November 04, 2021, 12:12:00 PM by Anon40213
Hi,

Win8.1 64 nightly211027

I just tried a new version and is the small loading circle on 211027 every time I move across the navigation line, no matter how small/big the step, supposed to be there? Can it be disabled if it's meant to be?

It's freaking me out a bit to see it there and is it saving something?  I'd rather not want to have to find some large cache has been stored somewhere that I got to delete every time I'm finished editing.

eumagga0x2a

"Small loading circle" is called busy cursor. It provides feedback that the application is not idle, which is always the case when seeking. And yes, it is an enhancement. Navigation can be very slow in high resolution HDR videos, especially when HDR tone mapping is enabled. A lack of feedback may tempt user to repeat actions, further delaying execution of commands.

szlldm

New nightly 211111
-bugfixes&polish
-ffNvEnc can creat intra-only streams
-navigation during play (cursor keys for seeking, go to marker A/B, etc.)
-the Go menu has been extended with the not well known time jump commands