Streampunk / beamcoder

Node.js native bindings to FFmpeg.
GNU General Public License v3.0
397 stars 76 forks source link

demuxer.read() performance for a large number of streams #24

Closed ertee closed 4 years ago

ertee commented 4 years ago

With the demuxer.read() method moving sequentially through the available streams, when you are working with a piece of media that has a (relatively) large number of streams it can have a performance impact while you await each read() call to cycle through to the stream index you are looking for. For example, in a file that has one video stream and eight audio streams in order to access the data on audio track 8 you'll have made 9 await read() calls before you get there.

Is there something we can do to short circuit this somehow? Perhaps a method or additional property of the read() call that can move the read() pointer internally? For the 9 stream example above, if we were to know the index offsets to the stream_index we are looking to work with, we could potentially call read(9) instead which would be the equivalent of 9x await demuxer.read() calls, but only needing to return data for the last call so it should be much faster to do it on the native side if you can just move the read index pointer.

Does this sound like it makes sense? Or is there something else that may be a better solution?

scriptorian commented 4 years ago

There is a method to indicate to FFmpeg that a particular stream should be discarded when reading. You need to set the stream discard flag to 'all' (or the relevant string for one of the other AVDISCARD??? flags) before you start reading from the demuxer: e.g. stream.discard = 'all'.

Note: the demuxer reads all the streams from the start of the source as part of its creation before you can set the discard flags so the first few reads will deliver packets from all streams. Subsequently the discard flags will be obeyed.