I have been doing several long recordings with GoPro cameras recently. The cameras automatically split the recordings into 4GB files, which leaves me with a myriad of files to work with. I have therefore made a script to help with the pre-processing of the files.
This is somewhat similar to the script I made to convert MXF files to MP4, but with better handling of the temp file for storing information about the files to merge:
Save the script above as mergevideos.sh, put it in the folder of your files, make it executable, with a command like:
chmod u+x mergevideos.sh
run the file:
and watch the magic.
The script above can be remixed in various ways. For example, if you want a smaller output file (the original GoPro files are quite large), you can use FFmpeg’s default MP4 compression settings by removing the “-c copy” part in the last line above. That will also make the script take much longer, since it will recompress the output file.
I am recording a lot of short videos these days for my sound actions project. Sometimes the recordings end up being rotated, which is based on the orientation sensor (probably the gyroscope) of my mobile phone. This rotation is not part of the recorded video data, it is just information written into the header of the MPEG file. That also means that it is possible to change the rotation without recoding the file. It is possible to see the rotation by looking at the metadata of a file:
ffmpeg -i filename.mp4
Then you will see a lot of information about the file. A bit down in the list is information about the rotation:
Side data: displaymatrix: rotation of -90.00 degrees
Fixing it is as simple as running this command on the file:
To simplify making these wrap-up videos, I am this time around recording them with my Samsung Galaxy s21 Ultra and a set of Røde Wireless GO II microphones. Time is limited when making these videos, so I have decided to quickly trim the files with FFmpeg instead of spending time in video editing software.
I have started shooting videos in 4K, not necessarily because I need it right now, but all my equipment supports 4K these days, and it feels more future-proof. However, FutureLearn does not like 4K and is rather picky about the files to be uploaded:
File format: .mp4 / .mov / .m4v
File size: up to 5GB
Frame rate: 25 fps
Bit rate: min 2 Mbps constant bit rate
Sound: AAC 44khz stereo
So how do you go about creating such files? Well, FFmpeg comes to the rescue again:
The one-liner is relatively self-explanatory. First, I apply a video filter that scales down the video to 1080p and reduces the framerate to 25fps. Then I specify that the audio should be reduced to 44100 Hz. FutureLearn wants a bitrate of 2 Mbps but does not specify a preferred bitrate. I decided to go for 8 Mbps, the suggested bitrate for 1080p uploads to YouTube. I added a minimum bitrate of 2 Mbps at the end, but I don’t think it is necessary since the bitrate used for MP4 files is constant.
All in all, this means that I can do the complete video editing with two simple one-liners, one for trimming the file and the one above for converting to the correct format. That way, I should manage to create two such wrap-up videos each week for the coming weeks.
I often want to create motion videos, that is, videos that only show what changed between frames. Such videos are nice to look at, and so-called “frame differencing” is also the start point for many computer vision algorithms.
We have made several tools for creating motion videos (and more) at the University of Oslo: the standalone VideoAnalysis app (Win/Mac) and the different versions of the Musical Gestures Toolbox. These are all great tools, but sometimes it would be nice also to create motion videos in the terminal using FFmpeg.
I have previously written about the tblend function in FFMPEG, which I thought would be a good starting point. However, it turned out to be slightly more challenging to do than I had expected. Hence, this blog post is to help others looking to do the same.
It does the frame differencing, but I end up with a green image:
I spent quite some time looking for a solution. Several people report a similar problem, but there are few answers. Finally, I found this explanation suggesting that the source video is in YUV while the filter expects RGB. To get the correct result, we need to add a format=gbrp to the filter chain: