ffmpeg-python VS pythonic-cv

Even given an option it can be difficult to find the corresponding documentation, if only because of the many different submodules and encoders and decoders and filters that have o-so-slightly different options. That said, I've just switched from pydub to ffmpeg-python (due to memory issues of the former[1]) and judging from the Jupiter notebook[2] it seems a much more intuitive method of constructing ffmpeg pipelines.

[1] https://github.com/jiaaro/pydub/issues/135

[2] https://github.com/kkroening/ffmpeg-python/tree/master/examp...

You might want to look into ffmpeg-python as well

This bug on github sounds like the same issue you have

take a look at https://github.com/kkroening/ffmpeg-python

The ffmpeg-python python package still makes use of the “future” python package (search for “past” in the code base). These should be removed and updated as necessary.

I've had a look through these examples, but I can't get the numpy conversion to work (I get broken pipe errors, but if any of you can get it working this solution would be ideal)

Your going to be wanting to enumerate all the files in a folder, shuffle them, and then use a library for splicing them together. A quick google search brought me to moviePy, which seems pretty solid. ffmpeg is the industry standard for programmatically working with video, but it's...complicated to say the least. Looks like there are some good python bindings for it, but it may be overkill for this project. I'm sure there are others out there too.

stitching [0], [1], and [2]

[0]https://github.com/kkroening/ffmpeg-python#quickstart

[1]https://kkroening.github.io/ffmpeg-python/#ffmpeg.zoompan

[2]https://ffmpeg.org/ffmpeg-filters.html#Examples-133

I've been using ffmpeg-python recently, and it will do a lot of the crazy complex transforms for you, and you can write sane python code vs. trying to deal with the crazy default ffmpeg syntax.

https://github.com/kkroening/ffmpeg-python

ffmpeg is the traditional Swiss Army knife for video stuff. there's a Python library out there. might not be appropriate in an embedded environment though, it's a bit of a beast.

I did something similar in this example, where the “input” was someone covering up a webcam to switch to the next display source (in my case switching through a list of videos that would continue from where they left off).

If you’re wanting to continuously process your screen like a live video stream you might be interested in (my library) pythonic-cv, which supports MSS as a video input backend.

I’ve previously done something similar here, but the transition was triggered by covering a webcam (e.g. with a finger).

pythonic-cv (disclaimer: my library) includes MSS as an input stream option.

If that’s of interest, OpenCV provides a detailed stitching example, although my revision is likely a fair amount easier to follow and understand (but it’s been optimised for video, so if you’re wanting to use it with minimal modification you’ll need to provide your images in a sequence where each image has overlap with the one before it, not in a random order).

As something of a side note, you may be interested in (my library) pythonic-cv.

I wrote pythonic-cv because I found that pipelines regularly require pre and post processing that can be done in parallel across frames - you might want to take a look :-)

Likely areas for parallelisation depend on the operations that are happening - if there are independent stages then they can often be made to run at the same time in separate threads (or processes). Concurrency is similar, although more about doing something else while waiting for I/O, and can generally be solved with threads or asyncio coroutines. A common improvement for video-focused computer vision pipelines is reading in/capturing the next frame while the previous frame is being processed (e.g. like is done with pythonic-cv - disclaimer: my library), but given the frame rates you specified then that may help a bit but is likely not the main culprit. ML-based algorithms can often benefit from the inherent parallelisation of a GPU-based implementation, although that can be difficult or even impossible to achieve depending on the algorithm being used.

Personally I’d approach this using pythonic-cv - it has a VideoReader class that supports separate preprocess and process functions, and has threading built in. Then again, I wrote the library, so it’s not so surprising that I’d jump to using it.