Encoding status window improvement

[poutnik]

I thank Avidemux developers for their great works.

Design of ADM encoding status window seems to be out of their focus for some time. (Win64 - ADM 2.6.8 )

I suggest developers may consider to implement Kalman filter[1] or even simple exponential filter[2] to Remaining time estimation. Or, at least to limit rather provoking precision. It seems to me to be quite funny to display estimated milliseconds, while value jumps wildly. I mean wildly -  within dozens of minutes or up to hours. I would mention a title quote from one scientific textbook: "Ignorance in science is seldom as well manifested as in lack of precision limitation of scientific calculations."

For total size, much more useful value would be estimated final size. E.g. estimated size 500 MB is more useful that 15 MB at 3%

Perhaps even better would be Finish time estimation, instead of remaining time, but not necessary.

Similar as for Remaining time can be applied to frame rate. It is OTOH over-rounded for eventually filtered values, that are IMHO more informative that real-time values..

---
[1] Kalman filter is used in many mobile applications, or in famous FFT3DFilter plugin of Avisynth. It is rather estimator than filter, combining recursive estimation from past with current measurements.
[2] exponential filter works like

Code Select Expand

CurrentFilteredEstimation = ( K * PreviousFilteredEstimation + RealTimeEstimation )/(K+1). For finish time can be used as is, for remaining time it would be

Code Select Expand

CurrentFilteredRemainingTime=[ K * ( PreviousFilteredRemainingTime - Time interval ) + RealTimeRemainingTime ]/(K+1)

[Jan Gruuthuse]

Could it be you're not using latest 2.6.8 avidemux? Found here http://www.avidemux.org/nightly/win64/ 64-bit 04/12/2014.

[poutnik]

That is strange, as I do use ADM 2.6.8, downloaded few weks ago, so it should be 2.68v2, as bugfix was mentioned.
But the look of my window seems different, even GUI theme.

[Jan Gruuthuse]

Could be difference between linux and windows: need AQUAR to confirm this? Should only be how it looks, not functionality.

You do have x265 support in avidemux? That is latest release 64-bit only.

Transition started way back in September 2014:2.6.8 Gui simplified
You downloaded from nightly and replaced existing by the unpacked content? Unpack with 7-zip from here http://www.7-zip.org/
If 32-bit, not as recent, download here: http://www.avidemux.org/nightly/win32/

Time(s) you are seeing is a varying prediction of the process, depending on:
- the current CPU load
- the complexity of the frames been processed
- data transfer in/from memory/hard disc.
- windows
- ...

[poutnik]

I see. You mean nighly, I had in my mind stable one.
No, there is no x265 support.

Sorry, I forgot to check nighly previsously, if there is change.
But as the state is in stable for very long time, it did not come to my mind.

Fact is, I have hasitated to play with ADM nighlies until now, even if I am used to it for other applications.
As it is not so long time ago, when ADM 2.6 stable had for me hardly beta stability, now crashing only at some way of cutting.

[poutnik]

Time(s) you are seeing is a varying prediction of the process, depending on:
- the current CPU load
- the complexity of the frames been processed
- data transfer in/from memory/hard disc.
- windows
- ...

This is obvious to me, but it has IMHO low information value if a user wants to know how long it will last...
Usable more precise estimation techniques based e.g. on long term interval are simple.

[Jan Gruuthuse]

I'm just user, possible time display issue has changed with latest revisions. Can't confirm 100%. I'm just daily user, not a developer. I haven't seen these fluctuations for a long time. Just try nightly. There have been more optimising (h264 and x265). Make copy of original location so you can eventually copy back current avidemux installation.

currently using: ubuntu 14.04 LTS 64-bit, core i7-3770k, 16 GB ram, GPU Hard Ware acceleration geforce GT-520, hdd SATA 6 Gb/s 7200 rpm   cache 64 MB.

[poutnik]

Could it be you're not using latest 2.6.8 avidemux? Found here http://www.avidemux.org/nightly/win64/ 64-bit 04/12/2014.

Now the windows looks similar, but estimation of final size is even more difficult than before.
One has to look at progress on one tab, than to total size on the other tab, and that to do calculation on calc or in mind.

I am not sure if it was a good idea to divide it to tabs...  :-( It is smaller, but less useful.

[poutnik]

.........
I haven't seen these fluctuations for a long time. Just try nightly. There have been more optimising (h264 and x265). Make copy of original location so you can eventually copy back current avidemux installation........................

I have deployed it to separate folder.

I see such fluctuations since ADM 2.5.x. At least I do not remember they were not there.  I wonder why they are not averaged by some simple and efficient algorithm.

Win64 ADM nightly from Dec4  does not seem to offer X265.

[Jan Gruuthuse]

Check in Help: Plugins: Video Encoder: 5th line: HEVC (x265).
If present there, could be you need to install x265 on your windows? Perhaps others can confirm or explain more on howto for windows?
With linux this is used: https://www.videolan.org/developers/x265.html

[poutnik]

Check in Help: Plugins: Video Encoder: 5th line: HEVC (x265).
If present there, could be you need to install x265 on your windows? Perhaps others can confirm or explain more on howto for windows?
With linux this is used: https://www.videolan.org/developers/x265.html

My instance does not have it there.
But I have not installed external codec either.

[Jan Gruuthuse]

OK, and the encoding window did that change? 2 tabs: [Main] & [Advanced]
Let's wait and see reports from other windows user.

[poutnik]

OK, and the encoding window did that change? 2 tabs: [Main] & [Advanced]
Let's wait and see reports from other windows user.

Yes, it did change, I may did not confirmed it explicitly, just commenting its look in previous posts.

I like personally the previous window, even if remaining time was to milliseconds, now in minutes.  Absence of stabilization of estimation remains, and size estimation for x264 CRF encoding is very unhandy.

[poutnik]

E.g. I like  nonmodal windows of MeGUI,  that are not big, minimizeable and contain useful information.

Target size and remaining time are filtered, size is drifting slowly, and time is jumping in order of seconds.

My guess is, they may use simple but efficient proportional estimation,

FinalSize            = CurrentSize * Totalframes / ProcessedFrames
RemainingTime = ElapsedTime * RemainingFrames / ProcessedFrames

that can be filtered as well by exponential filtering.