[Tinypy] Tips & docs on Avidemux .py scripting

[eumagga0x2a]

Actually, the existing dumpRefVideo() funciton in pyEditor breaks the tinyPy shell when called. Need to look into that.

[butterw]

Actually, the existing dumpRefVideo() funciton in pyEditor breaks the tinyPy shell when called. Need to look into that.

From my testing, there are a number of ed functions that don't seem to do much useful or raise exceptions. What are the dump functions used for ?

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.

It doesn't seem illogical to me that appending a video on itself should result in a count of 2 video sources. If it was the desired result, the user could have copy/pasted the video and avoided this.

The problem with appending files (or loading a project involving appended files) is that currently no information on the current status is provided by Avidemux. There is no way of knowing what is going on other than saving and analysing the project file (which requires expertise and may also be unpractical if the project involves a large number of files).

From what I understand the video count is available in Avidemux, but there is no plan to use it currently in the GUI. Exposing getVideoCount() (or whatever it should be named) in python would allow custom menu scripts to use this information.

[butterw]

flist = get_folder_content("B:/pics", "jpg")
is causing an immediate crash if the folder contains >=200 .jpg files.

Trying to append with TinyPy when no video is loaded results in  an error message "Assert failed..." then crash.py. A further test should be done to avoid this situation and instead display a clear error message and avoid crash.

[eumagga0x2a]

Trying to append with TinyPy when no video is loaded results in  an error message "Assert failed..." then crash

Totally avoidable, fixed by [editor] Open video instead of crashing when appendFile is called and no video is loaded yet.

[eumagga0x2a]

From my testing, there are a number of ed functions that don't seem to do much useful or raise exceptions. What are the dump functions used for ?

These functions can be useful for debugging, like hexDumpFrame which helped a lot during the work on solving issues with stream copy mode for AnnexB type H.264 and HEVC streams. None raise exceptions when used in the right way (i.e. with a video loaded), but evaluating uninitialized memory is indeed bad, should not occur after [editor] Let caller of ADM_Composer::getVideoPtsDts know when returned values are invalid.

[butterw]

What does Dump mean ? if it extracts some data, what does it do with it ?


With regard to adding Python bindings, how is it done ?

ex: adm.getOutputExtension()
Get the default filename extension for the current muxer, ex: "mkv"
https://github.com/mean00/avidemux2/commit/ad97816bad47dc554d7278a0359d3de6fb6ef5e7

In avidemux_plugins/ADM_scriptEngines/tinyPy/src
- ADM_pyAvidemux.h:
char *pyGetContainerEx(IEditor *editor);
- ADM_pyAvidemux.cpp: write the C++ binding function, which calls editor->getCurrentMuxer()

add the python binding to binding/adm.admPyClass:
/* METHOD */ str pyGetContainerEx:getOutputExtension(void)

ADM_pyAvidemux.cpp is autogenerated ?


 

[eumagga0x2a]

What does Dump mean ? if it extracts some data, what does it do with it ?

The functions print human-readable debug information to stdout, i.e. to the terminal on Linux or macOS or to admlog.txt on Windows.

ADM_pyAvidemux.cpp is autogenerated ?

adm_gen.cpp is autogenerated by the Perl script cmake/admPyClass.pl (this is also the reason for a huge diff as the order of autogenerated functions is random) from binding/adm.admPyClass file.

I can only encourage you to install Linux (Fedora might provide the best experience IMVHO) if you want to stay in touch with current development, not limited to Avidemux. Linux provides not only a completely different, superior level of comfort (IMHO) but it also lets you easily generate your own builds for Windows.

[butterw]

With the addition of a binding for int getVideoCount(void) I think the 2.7.7 TinyPy bindings would be complete at a basic level.

More advanced features could be added in the future (full access to segments was available in the Qtscript bindings for instance, and clipboard access could be interesting), which could then be used to improve / add custom commands to the GUI.

The scripts featured in the Auto Menu probably should be looked at before this release. Some might now be obsolete (vcd, svcd ?) and could be moved out.

[butterw]

The old scripts in the Auto menu seem to be DVD converters scripts. I've never used any of them, but they can be useful as examples. vcd and svcd.py are likely obsolete. I'm not sure what check24fps.py does.


 

[eumagga0x2a]

I'm not sure what check24fps.py does.

It looks like it probed time increment in order to classify fps. I'm not sure it is relevant now. Maybe just to showcase the usage of displayInfo().

[butterw]

I'm not sure what check24fps.py does.

It looks like it probed time increment in order to classify fps. I'm not sure it is relevant now. Maybe just to showcase the usage of displayInfo().

The thing is if the preference message level is set to error only, displayInfo doesn't even show up in the GUI.

- I would suggest removing obsolete or scripts of dubious use from the Auto menu, as a first step, a shorter list would better showcase genuinely useful scripts (and currently if you don't want these script in the Auto menu, you have to manually delete them each time you install).
- All the conversion scripts basically do the same thing, so one of these would showcase this use case just as effectively.
- Once the TinyPy interface is done, it will be possible to add more useful scripts (A directory loader script comes to mind).
I see you have added some functions in TinyPy to access segments and splitext, but I am still missing an editor->getVideoCount() binding.



 

 

 

[eumagga0x2a]

The thing is if the preference message level is set to error only, displayInfo doesn't even show up in the GUI.

My UX paradigm is not to keep users from shooting themselves in the foot at any cost. Users will always win.

- I would suggest removing obsolete or scripts of dubious use from the Auto menu, as a first step, a shorter list would better showcase genuinely useful scripts (and currently if you don't want these script in the Auto menu, you have to manually delete them each time you install).

Sure, later.

- Once the TinyPy interface is done, it will be possible to add more useful scripts (A directory loader script comes to mind).

Agreed, probably later. The interface is more or less done.

I see you have added some functions in TinyPy to access segments and splitext, but I am still missing an editor->getVideoCount() binding.

Surely an issue of comfort, but for now it should be possible to iterate over segments calling getRefIdxForSegment and taking the max.

[butterw]

- Once the TinyPy interface is done, it will be possible to add more useful scripts (A directory loader script comes to mind).

Agreed, probably later. The interface is more or less done.

OK.
Having a release version will allow to write scripts with the requirement of this version. Having a clean version number would be good when the interface is complete (ex: Avidemux 2.8 ).

I see you have added some functions in TinyPy to access segments and splitext, but I am still missing an editor->getVideoCount() binding.

Surely an issue of comfort, but for now it should be possible to iterate over segments calling getRefIdxForSegment and taking the max.

There can be very many segments, in which case this approach seems unefficient.

[eumagga0x2a]

for now it should be possible to iterate over segments calling getRefIdxForSegment and taking the max.

There can be very many segments, in which case this approach seems unefficient.

The inefficiency is not a concern, my suggestion simply won't work reliably as existing segments don't necessarily reference the video which was loaded last to get the highest id. I've added ADM_Composer::getVideoCount to the interface now.

Having a release version will allow to write scripts with the requirement of this version. Having a clean version number would be good when the interface is complete (ex: Avidemux 2.8 ).

It is not like an ABI of a library where all methods must match. An old script won't include a query of the interface version and will probably run nevertheless. A new script may include one and thus fail on an older Avidemux build which doesn't implement this method. However, if existing methods change their semantics, API versioning, tied to actual interface changes, not to Avidemux version, would be handy indeed.

[butterw]

As I understand it there have been no changes in TinyPy semantics: a script written 5 years ago is expected to run fine in the next release of Avidemux. However, a number of new functions have been added and scripts which use them will not be compatible with earlier versions of Avidemux (they will fail with TinyPy:Exception Key Error:xxx where xxx is the new unknown command).