Avidemux2.7.9-dev version (old thread)

[butterw]

In all filters with a simple slider layout, there should be always be an associated spinbox when the parameter is integer or float, there is no reason not to.
Ex: Sharpness\Blur, Colors\Color Temperature, Colors\Hue, Noise\Wavelet denoiser.
Artistic\Cartoon, Artistic\Charcoal, etc.
Also there is an issue in Artistic\Vignette: no tooltips are displayed.

Arguably, it may not be indispensable to have a spinbox when the layout is more complex. For these filters it may be better to find a way to display a tooltip on the slider (currently the sliders don't have value tooltips unless they are moved).

Sliders could be added in Noise\FluxSmooth, Noise\Hqdn3d.

[eumagga0x2a]

eumagga0x2a is this something you could do?

The refresh of official nightlies was requested a few days ago and the macOS build is the only one not done yet. I have no influence on when exactly and whether at all it happens.

There is a new problem with macOS/Homebrew as the Homebrew maintainers were keen to update Qt to 6.0.2 which requires some (or even a lot of) work to make Avidemux compile. I'm on it now.

There is another case when field for tweaking numbers is very useful - automation.

The presence or absence of spinboxes doesn't matter at all when the automation is done the proper way by using internal python scripting.

In all filters with a simple slider layout, there should be always be an associated spinbox when the parameter is integer or float, there is no reason not to.

This is quite a pain to implement as we get two linked controls, fighting against each other and threatening to lock up from signal/slot recursion if sloppily coded. I must admit that I do prefer to have both (even for float point values) from usability POV, but I don't like how this looks.

Also there is an issue in Artistic\Vignette: no tooltips are displayed.

This is trivial to add by using our enhanced version of QSlider.

currently the sliders don't have value tooltips unless they are moved

Bothers me a lot too. Other, more important tasks prevent me from fixing this myself at the moment.

The reason for going with tooltips was to show the value of the slider when there is no space for  anything else whatsoever.

[eumagga0x2a]

A fresh macOS Catalina nightly has been uploaded to https://avidemux.org/nightly/osx_catalina/

[signy13]

There is another case when field for tweaking numbers is very useful - automation.

The presence or absence of spinboxes doesn't matter at all when the automation is done the proper way by using internal python scripting.

As far as I know there is no way how to change one filter according of values from another filter.
For example I have a script, which puts two partial delogo filters. In the next step I configure one of the filters (X, Y, W, H) and put one of values into clipboard (more values would be also possible with another bash script). Then I open the second filter (just the partial dialog) and press a keyboard shortcut which runs an external script (written in bash) which opens the delogo filter and modifies a value (or possibly more values) of the second delogo filter and closes all the dialogues.

But I might be wrong so my question is: is there a way in TinyPy how to change properties of one partial delogo filter according to properties of previous/next partial delogo filter? For example get X and W values from one filter, do some math operation with them and then modify X and W values in previous filter?

From my point of view Avidemux has some limitations (for example no possibility of creating shortcuts for custom scripts) which I can partially remove by writing bash scripts so I do not have to do some repeated actions manually over and over again.

[Who]

A fresh macOS Catalina nightly has been uploaded to https://avidemux.org/nightly/osx_catalina/

Thanks, much appreciated! I got it and am using it now, although as it happens I don't have anything right now that requires more than just basic processing, so no need to try the new Delogo filter yet (that is the only one I am certain I will be using, just not today).  My videos seem to go in batches, some require only the simplest of processing (basically cutting out extraneous material, and maybe a fade to black at the end or something), and others require a whole lot more, but today I'm doing simple ones.  Anyway, it seems to be working with no issues so far, just waiting to see if it still crashes at the end of some videos.

[Who]

Okay, first real quick comments on the 2.7.9 nightly:

1. It did not crash after the first video.  EDIT: But it did after the second one that I did.

2. If there is a way to get rid of those segmented numbers in the time display I am not finding it.

3. Even though I didn't think I would have an need to use a Delogo filter tonight, it turns out I did and of course I immediately found a situation where it doesn't work well. The problem occurs when there is a black border that is immediately adjacent to the bottom of the logo, or if the logo overlaps the black border.  In that case you get a trapezoidal shaped black space inside the logo area.  The only way to avoid it that I could find was to crop the border out BEFORE using the Delogo filter, then it only drew in color from the rest of the frame.  I do like that filter better than the original Delogo filter because you don't see that crosshatch pattern that sometimes occurred with the original.  I guess the only thing I wonder is what are the ideal settings for the blur and gradient for general use (in other words if what you are trying to eliminate is present on the screen through several scene changes), because I tried a few different combinations and none of them seemed to give the best results on every scene.  But using the mask is genius for getting rid of those weird-shaped things you want to eliminate every now and then!

Might have more to say after further usage but those are my initial observations.

[szlldm]

I immediately found a situation where it doesn't work well. The problem occurs when there is a black border that is immediately adjacent to the bottom of the logo, or if the logo overlaps the black border.  In that case you get a trapezoidal shaped black space inside the logo area.  The only way to avoid it that I could find was to crop the border out BEFORE using the Delogo filter, then it only drew in color from the rest of the frame.

Basically it works so, that "it eats away" the mask (white blob) by filling the boundary with neighbouring colors. If the area is immediately next to a black border, then it will fill with black color. If the mask  reach the edge of the image (like after you cropped), then it will "eat away" from the known boundaries.

I guess the only thing I wonder is what are the ideal settings for the blur and gradient for general use (in other words if what you are trying to eliminate is present on the screen through several scene changes), because I tried a few different combinations and none of them seemed to give the best results on every scene.

The Blur parameter controls the blur amount of the mask area, while increasing the Gradient parameter it will blur less near the edge of the mask area, and more at the center.

[signy13]

I compiled Avidemux from fresh source yesterday and bumped into a not pleasant change. I have a Mplayer Delogo filter and I configure it by rewriting numbers (for example number in the field X):

• I select a digit in the number,
• I write another number (just press a key on numpad).

In the previous versions (a week old and earlier) of Avidemux the changed number was processed immediately so the red rectangle (showing the filtered area) was redrawn. That was very convenient way of tuning values by a keyboard.

In the current version of Avidemux the change is not processed immediately and I have to do an other action (hit Tab key for example). This change makes this "keyboard tuning" of numerical values worse.
Is it possible to revert this change?

[Who]

I immediately found a situation where it doesn't work well. The problem occurs when there is a black border that is immediately adjacent to the bottom of the logo, or if the logo overlaps the black border.  In that case you get a trapezoidal shaped black space inside the logo area.  The only way to avoid it that I could find was to crop the border out BEFORE using the Delogo filter, then it only drew in color from the rest of the frame.

Basically it works so, that "it eats away" the mask (white blob) by filling the boundary with neighbouring colors. If the area is immediately next to a black border, then it will fill with black color. If the mask  reach the edge of the image (like after you cropped), then it will "eat away" from the known boundaries.

I guess the only thing I wonder is what are the ideal settings for the blur and gradient for general use (in other words if what you are trying to eliminate is present on the screen through several scene changes), because I tried a few different combinations and none of them seemed to give the best results on every scene.

The Blur parameter controls the blur amount of the mask area, while increasing the Gradient parameter it will blur less near the edge of the mask area, and more at the center.

Thanks for clarifying that.  Maybe would be a good idea to add that to the help text.

One other thing I have noticed about the new version, although this is a problem I have seen before, just more rarely:

1. Load a fairly long video

2. Edit out some portion of the video at the start or in the middle.

3  Go to near the end, and mark off a section using the A and B markers.

4. Apply a filter that can be made partial, such as "blacken borders."

5. After creating the filter right click on it to make it partial.  If you are lucky, it will copy the times exactly from the A and B markers.  If you are not, it will have those times offset by roughly the amount of time you edited out, or some fraction thereof.

This makes no sense to me - I mean, after all, the times corresponding to the A and B markers have to be stored or calculated in some way so they display correctly, so why is that time not always transferred precisely when you specify a partial filter?  It almost seems to me as if when you create a partial filter, it pick up the time from the wrong internal variables or something.  If you have not cut out any portion of the original video then the times will always be correct, but if you have made one or more cuts then it is a crap shoot - sometimes the times are correct and sometimes they are not.  But so far, I have been more unlucky in the Avidemux 2.7.9 nightly, because partial filter times have been more consistently wrong tonight.  Is it really so hard to just precisely copy the times from the A and B boxes of the GUI display when creating a partial filter, or is this another issue that nobody sees but me?

[Who]

I compiled Avidemux from fresh source yesterday and bumped into a not pleasant change. I have a Mplayer Delogo filter and I configure it by rewriting numbers (for example number in the field X):

• I select a digit in the number,
• I write another number (just press a key on numpad).

In the previous versions (a week old and earlier) of Avidemux the changed number was processed immediately so the red rectangle (showing the filtered area) was redrawn. That was very convenient way of tuning values by a keyboard.

In the current version of Avidemux the change is not processed immediately and I have to do an other action (hit Tab key for example). This change makes this "keyboard tuning" of numerical values worse.
Is it possible to revert this change?

It is not just the Delogo filter. I have noticed the same thing about certain other filters as well.  Can't immediately give a specific example but I do agree that it was handy to see the result of what you have already typed in real time in certain filters.  Blacken borders is one that I know was changed in some way that makes it harder to see the results of the values you have entered, but I think that happened starting in 2.7.8.

[signy13]

It is not just the Delogo filter. I have noticed the same thing about certain other filters as well.  Can't immediately give a specific example but I do agree that it was handy to see the result of what you have already typed in real time in certain filters.  Blacken borders is one that I know was changed in some way that makes it harder to see the results of the values you have entered, but I think that happened starting in 2.7.8.

I guess it affects more filters of Avidemux, I just did not checked it...
It does not affect Avidemux 2.7.8-210313 (compiled on 13 March).

[eumagga0x2a]

One other thing I have noticed about the new version, although this is a problem I have seen before, just more rarely:

1. Load a fairly long video

2. Edit out some portion of the video at the start or in the middle.

3  Go to near the end, and mark off a section using the A and B markers.

4. Apply a filter that can be made partial, such as "blacken borders."

5. After creating the filter right click on it to make it partial.  If you are lucky, it will copy the times exactly from the A and B markers.  If you are not, it will have those times offset by roughly the amount of time you edited out, or some fraction thereof.

Do you add (even temporarily) and preview any filter between steps 1 and 2? If you do, all the values used to calculate the start and end time will be completely off once you perform an edit = modify the duration as they come from the bridge instance (the translation layer between the editor and the filters) which is created only once.

Apart from that, both the code deriving the end time from video duration in the bridge constructor and its usage via createEmptyVideoFilterChain and createVideoFilterChain in GUIPlayback::initialize() are buggy, seem to be easy to fix.

My desperate idea to scale start and end time in the partial filter constructor in case the duration of the video as reported by the bridge and the one reported by the parent filter don't match makes the behaviour of the partial filter even more confusing.

[eumagga0x2a]

I compiled Avidemux from fresh source yesterday and bumped into a not pleasant change. I have a Mplayer Delogo filter and I configure it by rewriting numbers (for example number in the field X):

• I select a digit in the number,
• I write another number (just press a key on numpad).

In the previous versions (a week old and earlier) of Avidemux the changed number was processed immediately so the red rectangle (showing the filtered area) was redrawn. That was very convenient way of tuning values by a keyboard.

The old behaviour, the default behaviour of QSpinBox, is called keyboard tracking and I actually dislike it very much as I prefer to fill in the values without the application starting to interpret them prematurally (I feel pressured). However, I do acknowledge that disabling keyboard tracking, contrary to swsResize filter, is not mandatory here and can be reverted without breaking functionality.

[Who]

One other thing I have noticed about the new version, although this is a problem I have seen before, just more rarely:

1. Load a fairly long video

2. Edit out some portion of the video at the start or in the middle.

3  Go to near the end, and mark off a section using the A and B markers.

4. Apply a filter that can be made partial, such as "blacken borders."

5. After creating the filter right click on it to make it partial.  If you are lucky, it will copy the times exactly from the A and B markers.  If you are not, it will have those times offset by roughly the amount of time you edited out, or some fraction thereof.

Do you add (even temporarily) and preview any filter between steps 1 and 2? If you do, all the values used to calculate the start and end time will be completely off once you perform an edit = modify the duration as they come from the bridge instance (the translation layer between the editor and the filters) which is created only once.

Sometimes I do that and sometimes I don't.  But what I don't understand is that the values shown in the A and B boxes always seem to be correct, and if I manually change the partial filter start and end times to match those then it always works.  So, why can't it just take the times from there rather than this "bridge instance" that you speak of?

Apart from that, both the code deriving the end time from video duration in the bridge constructor and its usage via createEmptyVideoFilterChain and createVideoFilterChain in GUIPlayback::initialize() are buggy, seem to be easy to fix.

My desperate idea to scale start and end time in the partial filter constructor in case the duration of the video as reported by the bridge and the one reported by the parent filter don't match makes the behaviour of the partial filter even more confusing.

You're talking about the internals of the program which I do not understand at all.  All I am saying is that when you go to make a filter partial, it should be getting its times from whatever internal variables provide the time to the A and B boxes in the GUI display, since in my experience those are always correct no matter how many edits you may have made or how many filters you have used.

[Who]

I compiled Avidemux from fresh source yesterday and bumped into a not pleasant change. I have a Mplayer Delogo filter and I configure it by rewriting numbers (for example number in the field X):

• I select a digit in the number,
• I write another number (just press a key on numpad).

In the previous versions (a week old and earlier) of Avidemux the changed number was processed immediately so the red rectangle (showing the filtered area) was redrawn. That was very convenient way of tuning values by a keyboard.

The old behaviour, the default behaviour of QSpinBox, is called keyboard tracking and I actually dislike it very much as I prefer to fill in the values without the application starting to interpret them prematurally (I feel pressured). However, I do acknowledge that disabling keyboard tracking, contrary to swsResize filter, is not mandatory here and can be reverted without breaking functionality.

I guess that is the difference between people, I don't feel that the premature application of those values is pressuring in any way.  And for some filters, such as blacken borders, it is actually helpful to be able to see the area to be blackened change as you enter or change the numbers.

Maybe this could be made a configurable option so that those who like the old way can have it back?