What configuration/environment you are using to build/run 5.1.1 version of moviemasher?

[manojmmewara]

For me, 5.0.6 version of moviemasher is working fine. But when I am trying to compose the new docker image with changes, I end up with various issues like: docker compose vs docker-compose commands written in scripts or issues with node modules installation/versioning or esm build failing because of dependency on other packages...

I am using the same commands to build and run docker image like sudo npm run build

Can you please share your development environment version of different software like: npm, node, docker, os, etc?

Thanks in advance !!!

[syntropo]

Sure, I'm guessing our versions of Docker are off if you're having trouble with docker compose.

OS: macOS Monterey 12.6.1 Node: 16.14.2 NPM: 8.6.0 Docker: 20.10.20

Also keep in mind that there are no build artifacts included in the repository, so some modules need to be built before others. For instance, to build the theme the core and client modules need to have been previously built. You should be able to just execute npm run build initially to build everything in proper order.

Also note that the build scripts aren't actually using sudo! The $SUDO variable contains an empty string by default. This variable is only there to make it easy to run the scripts in other environments where sudo is more appropriate.

[manojmmewara]

Hi, @syntropo Thank you very much for sharing the versioning, Your help really appreciable, I will try it out and update back...

I am having one more doubt regarding extending the functionality of Moviemasher.

Suppose I use Moviemasher as NPM Package Library in my project and wanted to extend some of the functionality like adding new video effects or making a few changes in an existing component like changing the behavior of any existing UI Component.

Then what way do you suggest, will be extending it via prototyping and passing props in the component will efficient?

[syntropo]

Hopefully, most of the React components are simple enough that they can just be copied. I'd probably recommend this over extending, at least for the more experimental components.

Extending classes in the core library is a bit trickier since they mostly follow pretty strict interfaces that are checked at runtime by guard clauses. Effects in particular are complex since they are made up of one or more Filters, which are JavaScript representations of the FFmpeg filters. They are used in the client to create the preview but also on the server to create the FFmpeg command that ultimately renders the mash as video.

If you want a new Effect which simply recombines existing Filters, this is quite easy... The Effect can be defined in JSON and imported either by returning it in the Endpoints.data.definition.retrieve response when effects are requested, or by calling the Defined.define method directly. The existing effects are all defined by JSON files living in the packages/moviemasher.js/src/Definitions/DefinitionObjects/effect directory.

Creating new Filter classes is more involved and really deserves its own documentation at some point... Until then I'd suggest reviewing the existing classes in packages/moviemasher.js/src/Filter/Definitions which all descend from FilterDefinitionClass and implement the FilterDefinition interface. To augment the client preview each Filter can override the filterDefinitionSvg method to include an SvgItem, and/or the filterDefinitionSvgFilter method to include one or more SvgFilters.

If your application is expecting to render videos that include your Filter then the commandFilters method must also be overridden to return CommandFilters to include in FFmpeg's command. The tricky part is finding an FFmpeg filter that easily maps to an SVGFilterElement in the browsers.

[manojmmewara]

Thanks for the support, Doug !!!