Some months ago I started some ffmpeg experiments I would like to slowly note here in my blog.
It’s not the first time I’ve tinkering with ffmpeg. But this time I was trying to fix a problem I like call “the VOD bias”. So allow me to start from there.
There are lots of multimedia FLOSS out there, from libraries to complete tools suites, being ffmpeg by far -and by merit- the most recognized of them all. However, it’s pretty common that all those tools and libraries are often designed with files use cases in mind. Which is about common sense, and it usually works great for most people. But since I work in the Live Streaming field, that means trouble, and it actually bites me quite often.
In Live Streaming, your challenge is to generate a constant, non-interrupted multimedia stream: the output of your work must have no gaps, no stops, no discontinuities. There are many reasons for that, only visible when you’re already working in this field -like a usual absolute disregard of responsability from players when anything happens with the stream, too sensible hardware, too anxious multimedia consumers, synthetic metrics that exaggerate any glitch consequences and turn it into a business problem, the draconic 24/7/365 uptime regime, etc-. But very, very rarely such reasons are part of the rationale behind multimedia software. And there are of course many examples, but a paradigmatic one is the ffmpeg behaviour when its job it to produce a stream -NOT a file-.
You see, ffmpeg is able to create mostly anything multimedia related. You can, for example, feed ffmpeg with an input multimedia stream, and do stuff with it. You can also convert an input file into an output stream -looped or not-, and you can even create a stream from several multimedia sources ffmpeg allows you to use -like hardware inputs, or “source filters” that creates media on-the-fly-. It calls itself quite acuratelly “media converter”. But surprisingly for the people who doesn’t work in live streaming, ffmpeg always works with a file rationale -not “streams”-, even when it allows you to do so many things with streams.
The consequences of this are quite a few. For example, if you tell ffmpeg to create an output stream with x and y characteristics, let’s say using another stream as input, and you set parameters like “constant bitrate”, “constant framerate”, “x frames per seconds”,…
continuar leyendo