-
Notifications
You must be signed in to change notification settings - Fork 55
Stream Processing
Small experiment with processing raw panorama video to stitched video using streams. This approach saves you a lot of disk space compared to converting video to images and stitching them individually.
Note: commands and gists used here might not work with the current or future versions of gear360pano script(s), correct them to suite your needs.
The idea is simple:
ffmpeg-decode-to-stream | stitch-this-image | ffmpeg-encode-from-stream
There's a possibility to tell ffmpeg to output frames to stdout. The problem being is that the next process in the stream needs to either tell when an image begins and ends or know exactly the image length. The latter approach is easier as we can use already existing tools to slice the stream into equal parts and we can easily calculate image size in bytes. The former approach would require writing a specialised software.
Here's a gist link to script that does that: https://gist.github.com/ultramango/8365652860090f67c6c857c0a2d79704
ffmpeg ${FFMPEGLOGLEVEL} -y -i ${TESTVIDEO} -pix_fmt rgb24 -f rawvideo - |. We tell ffmpeg to output video as raw rgb24 stream.
split -b ${READSIZE} --filter="convert -size ${TESTVIDEOSIZE} -depth 8 rgb:- jpg:- | ./gear360redir.sh" |. We're using split to split the stream into pieces and pass data through filter which is an external command (--filter). Since gear360pano.cmd script accepts jpegs we need to use ImageMagick to convert the image. gear360redir.sh script is used to silence ./gear360pano.cmd script and output only jpeg file (and accept input from stdin).
ffmpeg ${FFMPEGLOGLEVEL} -y -f image2pipe -r 30 -vcodec mjpeg -i - -c:v libx265 -x265-params crf=18 ${OUTVIDEO}. Accept images (jpeg: -vcodec mjpeg) as input from stdin.
This approach will be slower since there's extra step of converting raw image to jpeg. Test on a single small file show: 38 s ("traditional" script) vs 45 s (this approach).
Best if ffmpeg had a possibility to run external command to process a frame and then encode it, this would allow the processing to shrink to one (long) command only and would be probably the fastest.