Documentation of the core library of GPAC
FilterSession class

FilterSession management. More...

+ Collaboration diagram for FilterSession class:

Data Structures

interface  _FilterSession

Detailed Description

See GF_FilterSession

The default behaviour is to run the session in blocking mode, which will prevent executing anything until the end of a session. While this may be OK for workers or simple applications, it is obviously problematic if you have async tasks to be performed by your node app.

An example approach for by-passing this is to create the session in non-blocking mode and use a recursive promise to run the session:

//create session in non-blocking mode:
let fs = new gpac.FilterSession(gpac.GF_FS_FLAG_NON_BLOCKING);
//setup your filters
//Run session as Promise
const FilterSessionPromise = (fs_run_task) => {
var fsrun_promise = () => {
return (fs.last_task==false) ? fs_run_task().then(fsrun_promise) : Promise.resolve();
return fsrun_promise();
const run_task = () => {
return new Promise((resolve, reject) => {
resolve( fs.run_step() );
FilterSessionPromise(run_task).then( ).finally( ()=> { console.log('session is done'); } ) );
console.log('Entering NodeJS EventLoop');

The filter session supports multithreaded mode, using e.g.

gpac.set_args(["", "-threads=N"]);

However it is currently not capable of running asynchronous callbacks into Node.

The consequences are:

For better multithreaded usage, it is therefore not recommended to use packets with shared JS data.

By default the filter session will run with implicit linking.