[Tinypy] Tips & docs on Avidemux .py scripting

[eumagga0x2a]

The closest I get is opening the filesave dialog with gui.fileWriteSelect("Output Filename"), but the extension is not auto-selected.

Regarding the file dialog, gluing fileWriteSelect via pyFileSelWrite to GUI_FileSelReadExtension is on my todo list (probably post-release).

Already happened, albeit not verbatim, of course (I mentioned GUI_FileSelReadExtension by error, it serves a different purpose).

Please use fileReadSelectEx / fileWriteSelectEx functions in pyGui to open such file dialogs. If the first argument is an empty string, a default caption is used. Only a single extension (e.g. "mkv") is supported.

[butterw]

The new method is called with gui.fileWriteSelectEx("title", "mkv") ? 
Does the save dialog use the extension of the output container by default ? That's the most important thing IMO.

- to mux to a different container you have to explicitly set the container with ex: adm.setContainer("MKV") or via GUI
- there is currently no way of knowing the container set in the GUI.
- there is currently no way of knowing the path/extension of the input file.
- there is currently no way of splitting extension from filename

For my split script, I prefix the output save name based on the filename (including extension) chosen in the save dialog:
save name = p1_filename
if filename already exists, there is a overwrite warning (! filename will not be overwritten, but p1_filename will be overwritten silently if it does exists).

Knowing the path name would be useful to be able to bypass the gui.fileWriteSelect (single output filename path selector dialog). Often with a script (ex: ffmpeg command-line) you just need to save  prefixed (or postfixed) filenames to an output dir.

[eumagga0x2a]

The new method is called with gui.fileWriteSelectEx("title", "mkv") ?

This is correct.

Does the save dialog use the extension of the output container by default ? That's the most important thing IMO.

No. File dialog minds its business, uses whatever the caller passes to it and doesn't ask impolite questions about the caller's affairs

- to mux to a different container you have to explicitly set the container with ex: adm.setContainer("MKV") or via GUI

Yes, sure.

- there is currently no way of knowing the container set in the GUI.

True, ADM_Composer::getCurrentMuxer() needs to be wired into tinyPy.

- there is currently no way of knowing the path/extension of the input file.

If you use gui.fileReadSelect with or without Ex, you have got the full path. Once the file is loaded, there is no (safe) way. Handling of input is encapsulated in demuxers, the "file" can be a frame server or a large set of files, logically treated by demuxer as one single file.

- there is currently no way of splitting extension from filename

Indeed, not in the subset of Python implemented by tinyPy. Easily accomplished with external tools on command line.

if filename already exists, there is a overwrite warning (! filename will not be overwritten, but p1_filename will be overwritten silently if it does exists).

The overwrite warning is triggered by file dialog (probably not on macOS, it does its own thing), if you alter the filename behind its back, how should it catch it??

[butterw]

- there is currently no way of knowing the container set in the GUI.

True, ADM_Composer::getCurrentMuxer() needs to be wired into tinyPy.

Got it.
But it's not clear why 2 methods are needed. Why not just replace the existing gui.fileWriteSelect with something like gui.fileWriteSelectEx(title="", ext=None) ?

Once the file is loaded, there is no (safe) way. Handling of input is encapsulated in demuxers, the "file" can be a frame server or a large set of files, logically treated by demuxer as one single file.

If there was a way to access it, the filename as displayed by the GUI would be useful (without extension, with filepath).

The overwrite warning is triggered by file dialog (probably not on macOS, it does its own thing), if you alter the filename behind its back, how should it catch it??

Likely not worth worrying about as it just complicates things, but the following may be possible:
- Disabling the overwrite warning by passing an extra parameter to the write dialog.
- Handling the overwrite warning from python using get_folder_content("/home/foo/videos","mkv")

[eumagga0x2a]

Why not just replace the existing gui.fileWriteSelect with something like gui.fileWriteSelectEx(title="", ext=None) ?

For the same reason we have audioSetNormalize(int,int,int) and audioSetNormalize2(int,int,int,int): in order to avoid breaking existing scripts. However, you have the point as the impact would be really minimal this time as fileWriteSelect / fileReadSelect is not used in scripts Avidemux auto-generates.

- Disabling the overwrite warning by passing an extra parameter to the write dialog.

I actually remembered it wrong, QFileDialog::DontConfirmOverwrite is always set in the file dialog (Avidemux tries to handle collisions on its own), except of on macOS where this flag is useless (if you ignore the warning Avidemux shows, your way gets blocked by one more dialog probably from the OS anyway). I'll need to recheck.

- Handling the overwrite warning from python using get_folder_content("/home/foo/videos","mkv")

This was an idea I wanted to suggest. Unsure whether it would be sufficient, however.

ADM_Composer::getCurrentMuxer() needs to be wired into tinyPy.

Done.

[butterw]

If I understand correctly:
- adm.getOutputExtension() #New: returns the extension of the current container, ex="mkv"
- adm.setContainer("mkv")  #sets the container to mkv

- gui.fileWriteSelectEx("title") #The new method makes sense for backwards compat if it sets the extension to the current container by default as opposed to the current gui.fileWriteSelect("title").
The new method would almost always be used rather than the old one.

From the python user code side it only saves one line of code, but it is simpler to use:
gui.fileWriteSelectEx("title")

vs
ext = adm.getOutputExtension()
gui.fileWriteSelectEx("title", ext)
 
Regarding the fileWriteSelect Overwrite warning:  it gets triggered on Windows.

[eumagga0x2a]

The new method makes sense for backwards compat if it sets the extension to the current container by default

You are right, backward compatibility is not that important here. Tying the filter to muxer is not viable as it would break the dialog for all other purposes.

[butterw]

Just noticed that the default name is the same as the input using gui.fileWriteSelect.
If it's possible to get it without opening gui.fileWriteSelect dialog, it would be useful in scripts to set the save name directly to something meaningful.

I am assuming default function parameter values and variable parameter numbers are possible in bindings ?
If not it can be done in Python with a wrapper.
 
- gui.fileWriteSelect("title") #current, no extension selected, default filename: video.*

- fileWriteSelectEx("title") #extension tied to the current muxer (ex:mkv), default filename: video.mkv
most frequently used, avoids using .mp4 extension with an mkv file

- fileWriteSelectEx("title", "jpg") # default filename: video.jpg

[eumagga0x2a]

Just noticed that the default name is the same as the input using gui.fileWriteSelect.

The file dialog obtains the default filename from the list of last files in Avidemux, it also checks whether the directory of that last file exists and if it does, it checks for filename collision. I doubt that this needs to be exposed via Python interface. So the only way to know which file is loaded, is

Code Select Expand

file = gui.fileWriteSelectEx("title","extension") # if extension is "", no filter is applied
if file is None: # dialog cancelled
    return
# now do whatever you want with the full path stored in string "file"
I still need to change the API for fileReadSelect / fileWriteSelect.

After some deliberation I am going to keep both variants, else people who switch between versions will have a hard time.

[butterw]

I've noticed the following issue on Windows:
- When run project or recent project is used, there is a file lock on the opened script, which stays in place until Avidemux is closed.
- This can be troublesome to edit/test scripts (saves fail),
- Closing the file doesn't help.
 
- The same issue does not occur when the script is called from the custom menu (but the menu only refreshes on app startup).
 

[eumagga0x2a]

Good catch, should be fixed now, thank you for your report.

[butterw]

adm.getOutputExtension() is causing an immediate crash on v2.7.7dev 29/01/2021 VsWin64, on Win10 from Shell.
admlog.txt is not updated.

[eumagga0x2a]

Oops, fixed. Thank you very much.

[butterw]

- There isn't currently any display in the GUI of the current number of open video files (can be >1 via appends) https://avidemux.org/smif/index.php?msg=90806

If possible, it would be useful to have a python binding to access this info (nbSegments changes when edits are made).
 

[eumagga0x2a]

If the same file is appended to itself, the number of reference videos will be 2 and the number of open files (I mean videos) will be 2 but it will be still one and the same video. I don't think such a function would be of much use.