Right now we only have image/single-frame processing capability. For animations, see #28. Many of the requirements for video is similar to animations, though with different performance characteristics, as videos are very large by comparison.
A possible architecture would be as follows. The API should however not expose much of the details of this architecture, such that we can optimize common usecases by creating tailored flows for those.
Explode the video into frames (possibly extracting a subset)
Process the frames one-by-one, potentially with different graph/parameters on each. Or using a time-window of frames, when inter-frame processing is needed
Combining/joining frames together to form a new video
Preserving metadata will however be a bit tricky, essentially requiring to carry it along in a sidechannel and re-applying at the end step.
We want to handle many different types of video formats on input and output, so a library with support for many of these, like GStreamer or ffmpeg.
Longer term it is desirable to be able to plug in GPU-accelerated processing.
Right now we only have image/single-frame processing capability. For animations, see #28. Many of the requirements for video is similar to animations, though with different performance characteristics, as videos are very large by comparison.
A possible architecture would be as follows. The API should however not expose much of the details of this architecture, such that we can optimize common usecases by creating tailored flows for those.
Preserving metadata will however be a bit tricky, essentially requiring to carry it along in a sidechannel and re-applying at the end step.
We want to handle many different types of video formats on input and output, so a library with support for many of these, like GStreamer or ffmpeg.
Longer term it is desirable to be able to plug in GPU-accelerated processing.