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() );
        });
}
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:

• any custom JS filter will run on the main thread (EventLoop or worker thread)
• any packet dispatched by a custom filter and requiring a JS callback upon packet destruction (shared data dispatch) will force filters consuming these packets to run on the main thread as well.
• any filter assigned with a JS binding will be scheduled on the main thread

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.