Avidemux Forum

Suggestion:

1) track whether the loaded video has been modified (Delete, Cut, Paste operations performed and not undone) and
- if this is the case display * in the titlebar.
- Display + if an Append operation has been performed (without source modification)

2) in the Save Dialog: trying to overwrite any of the source video segments always fails (because the files are open in Avidemux). This is expected an info message should be displayed instead of an Exception.
 

Quote from: butterw on January 19, 2021, 12:28:21 PM1) track whether the loaded video has been modified (Delete, Cut, Paste operations performed and not undone) and
- if this is the case display * in the titlebar.

Once "save video" is consistently relabeled as "export video..." and "save as project" has become "save...", this otherwise very familiar UI convention can be investigated. Else users will be profoundly confused why "saving" video doesn't remove the asterisk in the window title.

In general, I am not sure that the whole makes sense with Avidemux as changes can be performed by executing a project script without the GUI noticing.

Quote from: butterw on January 19, 2021, 12:28:21 PM- Display + if an Append operation has been performed (without source modification)

Again, the path via a project script would remain uncovered as scripting invokes editor commands directly.

Quote from: butterw on January 19, 2021, 12:28:21 PM2) in the Save Dialog: trying to overwrite any of the source video segments always fails (because the files are open in Avidemux). This is expected an info message should be displayed instead of an Exception.

Very much wanted, very difficult to design and to implement (while a segment has always a single reference video, this reference video is an abstraction which knows nothing about the files underneath – there are not necessarily even any files involved, it may be a frame server), patch welcome.

Quote from: eumagga0x2a on January 19, 2021, 02:15:36 PM

Quote from: butterw on January 19, 2021, 12:28:21 PM1) track whether the loaded video has been modified (Delete, Cut, Paste operations performed and not undone) and
- if this is the case display * in the titlebar.

Once "save video" is consistently relabeled as "export video..." and "save as project" has become "save...", this otherwise very familiar UI convention can be investigated. Else users will be profoundly confused why "saving" video doesn't remove the asterisk in the window title.

It makes sense to collect the various suggestions in one place for consideration. But I'm not in any way suggesting that changes to the interface should be made without taking the time to think them through first.

As far as I'm concerned the current Save and Save As Project... are fine. 
A Save Full command is worth considering, but should only be implemented if it can be done cleanly and easily. Adding Reset Markers to the toolbar would probably be a valid alternative.

Regarding the * feature: I sometimes load a file in the GUI, try some lossless cuts, and undo them if they are not satisfactory. The question is then, do I actually need to save the file. Is there any way of knowing this currently ?

Quote from: butterw on January 19, 2021, 12:28:21 PM- Display + if an Append operation has been performed (without source modification)

Again, the path via a project script would remain uncovered as scripting invokes editor commands directly.
[/quote]

I don't know in detail how avidemux works, but in my view this shouldn't be the case. I.e. it shouldn't matter whether there is a GUI or not, or whether a command was launched via a script or not:
- there should just be updated variables reflecting the current state of the application, which can be tested.
- If there is a GUI it is only expected it will reflect the current state, when it updates.

I think the Append "+" status in the GUI is both easy to implement and genuinely useful.
- It's useful because of how Append works in Avidemux, which isn't clear unless you look into a project file (most users never look into them, some users such as myself never even use them).
- For my workflow, I sometimes need to append segments via GUI and save them to a single file (the original segments get deleted). But once opened/appended (maybe via drag&drop) it's really quite easy to forget that a file is multi-segment and needs to be saved even if no operation was performed on it. A simple reminder helps a lot here.

In a script you typically need to test ed.nbSegments().
But it shouldn't be required when opening an interactive shell in the GUI to enter commands manually.
 

Quote from: butterw on January 19, 2021, 12:28:21 PM2) in the Save Dialog: trying to overwrite any of the source video segments always fails (because the files are open in Avidemux). This is expected an info message should be displayed instead of an Exception.

Quote from: eumagga0x2aVery much wanted, very difficult to design and to implement (while a segment has always a single reference video, this reference video is an abstraction which knows nothing about the files underneath – there are not necessarily even any files involved, it may be a frame server), patch welcome.

One simple thing that can easily be done is to add "_edit" to the default save name in the GUI. It's a great hint/reminder that you can't overwrite the source.  
Testing the dev build with default settings, I realised this is feature is not on by default (it should be IMO). Moreover I realized I don't even know how this is configured ?

Quote from: butterw on January 19, 2021, 07:16:13 PMRegarding the * feature: I sometimes load a file in the GUI, try some lossless cuts, and undo them if they are not satisfactory. The question is then, do I actually need to save the file. Is there any way of knowing this currently ?

Currently, the only indication of a dirty state is the entry for Undo in the Edit menu becoming enabled (this is tracked for segment layout only, not for encoder and muxer configuration). It should be possible to enhance this by an asterisk in window title. The problem is with the semantics of "save" in Avidemux which actually matches the meaning of "export", while "save project" is actually "save the current work" and only this would be in scope of "*" in the window title.

The need to export a video is not related to editing steps and there is no way to guess what the user wants (brain implants are not yet the thing ;-)).

Quote from: butterw on January 19, 2021, 07:16:13 PMI don't know in detail how avidemux works, but in my view this shouldn't be the case. I.e. it shouldn't matter whether there is a GUI or not, or whether a command was launched via a script or not

I was tempted to provide more access to high-level editor functions via scripting, which resulted in things getting messy (e.g. ed.nextFrame() decodes the next frame and updates currentPts, but doesn't update the preview buffer which serves adm.saveJpeg(path) as the source). In the future, a better design emerges, I hope.

Quote from: butterw on January 19, 2021, 07:16:13 PMOne simple thing that can easily be done is to add "_edit" to the default save name in the GUI.

This is automatically done so in file dialog when a filename collision is detected. However, a user can always overrule the suggestion, potentially destroying data (there is no file locking on Linux, so it is trivial to destroy the source video by selecting it as output file).

Quote from: eumagga0x2a

Quote from: butterw on January 19, 2021, 07:16:13 PMOne simple thing that can easily be done is to add "_edit" to the default save name in the GUI.

This is automatically done so in file dialog when a filename collision is detected. However, a user can always overrule the suggestion, potentially destroying data (there is no file locking on Linux, so it is trivial to destroy the source video by selecting it as output file).

Yes, I just saw it's directly in the code.
My suggestion to improve this feature would be to make it a configurable preference (I always rename _edit to _ed), this would have the added benefit of making it identifiable by the user.
I also think this should always be activated
- it's simpler to understand that way and it also applies when the source file isn't in the default save dir
- name collison or not, I find it's always useful to know an edit as been made.
- on Windows as I described, it will ask for confirmation to overwrite one of your source files and then fail because the file is in use.
- I would consider overwritting source files very poor practice in an editing app (Gui, scripts, filters, encoding parameters what could not go wrong ?)

Quote from: eumagga0x2a on January 19, 2021, 08:16:50 PM

Quote from: butterw on January 19, 2021, 07:16:13 PMRegarding the * feature: I sometimes load a file in the GUI, try some lossless cuts, and undo them if they are not satisfactory. The question is then, do I actually need to save the file. Is there any way of knowing this currently ?

Currently, the only indication of a dirty state is the entry for Undo in the Edit menu becoming enabled (this is tracked for segment layout only, not for encoder and muxer configuration). It should be possible to enhance this by an asterisk in window title. The problem is with the semantics of "save" in Avidemux which actually matches the meaning of "export", while "save project" is actually "save the current work" and only this would be in scope of "*" in the window title.

The need to export a video is not related to editing steps and there is no way to guess what the user wants (brain implants are not yet the thing ;-)).

For me (as a non-project user) the * would be most useful as an indicator of an actual modification of the video bitstream save/export:
so only Muting audio, removing audio tracks or Delete/Cut/Paste operations that have been performed without being undone.
So it should trigger if duration or number of audio tracks have changed and if possible also if there are non-undone Delete/Cut/Paste operations.

Different users may clearly have different expectations here. There probably should be a preference value for what * takes into account.

If it initially simply mirrors Undo, it probably should debut as a default-off feature. Not taking into account encoder or container settings could be a big deal for some. My issue would be that Undo gets triggered as soon as you set a Marker, even if it is later Reset.

EDIT2: To modify an ongoing Edit, saving the project and manually editing it may currently be a better way of proceeding than going through a long list of Undos.

EDIT: In the cross-platform video player mpv, the user can dynamically set configuration strings. ex: title="mpv v0.33 - ${filename} (${width}x${height})". The result will be displayed by default in the the window titlebar, if there is one.

 

Quote from: butterwI think the Append "+" status in the GUI is both easy to implement and genuinely useful.
- It's useful because of how Append works in Avidemux, which isn't clear unless you look into a project file (most users never look into them, some users such as myself never even use them).
- For my workflow, I sometimes need to append segments via GUI and save them to a single file (the original segments get deleted). But once opened/appended (maybe via drag&drop) it's really quite easy to forget that a file is multi-segment and needs to be saved even if no operation was performed on it. A simple reminder helps a lot here.

The bottom line is that you when you save a project with appended video segments, you need to be careful to keep all the original segments unchanged (! not just the first file).

Issue: The GUI does not provide any info about segments being loaded or their number. Moreover it's possible to undo the segment append by error with just an additional CTRL-Z.
Proposed solution: add an append string "+N" to the window title display when N>1, N being the total number of segments.

File Changed Status (Operations that affect the file saved in Copy Mode).

It seems the number of video segments could be used to determine the File Changed status, together with the original duration.
- The number of current audio tracks can be compared to the total audio tracks count. 
- The number of video segments compared to the number of video source files indicates whether edit operations were  performed. However this may currently overdetect edit operations.

From my testing, undo of an operation cancels the corresponding newly created segments, but segment consolidation isn't performed in the following case:
- If a a segment is cut then later pasted at the same position (the result is n=3 segments instead of 1)

Project file output:
adm.clearSegments()
adm.addSegment(0, 0, 8399999)
adm.addSegment(0, 8399999, 57700000)
adm.addSegment(0, 66099999, 1052800000)

instead of:
adm.addSegment(0, 0, 8399999+57700000+1052800000)

Consolidating addSegment lines on Paste would make the output project more readable and could improve file change detection.

EDIT: Given that segments are the basic editing blocks in Avidemux (they are used for undo for instance), it does in fact make sense to not consolidate them by default. There should however be a dedicated command to consolidate segments. Currently you need to save/reload an output file for this.   
 

When a .py file is opened instead of a video file, it is likely a project file.

There should be a custom error msg informing the user to use Project Script > Run project instead of the generic cannot find a demuxer error.