(To be fair, knowing ffmpeg exists doesn't mean I'd be able to easily write a video player with it without a lot of research. For that reason I find this tutorial is still quite interesting and valuable.)
For those who are curious how much of a video player can actually be implemented in 1k lines when including a decoder and using existing libraries/OS for nothing more than showing a framebuffer --- I've tried writing toy decoders (no optimisations, pure C, decoding only) for H.261, MPEG-1, and H.262 (MPEG-2). Their line counts are, respectively, 740, 1083, 1461. The MPEG-2 decoder can also decode MPEG-1 since the latter is really an extension of the former. The simplest renderer, using Win32 GDI, is <100 lines. The line counts above are not "code-golfed", although I do tend to write very terse code (avoiding unnecessary abstraction etc.), but also includes things like comments and commented-out debugging code.
That seems to imply that, in 1kLoC of C, you should be able to write a complete video player for MPEG-1, and not much more beyond that. If you're even the slightest bit interested in video compression, I'd recommend giving it a try starting with '261 --- it's not as difficult as it sounds at first glance, and the results are very visible.
(When I have the time, I plan to continue this exercise with H.263, MPEG-4 ASP, and then H.264.)
That's awesome. But isn't H.264 like, 20 times more complicated than H.262? Or maybe not, I just think I remember looking at some big manual, not sure if it was actually H.264. But it seemed super complex. Maybe not as difficult for people who are really good at math.
H.264's complexity increase mainly comes from the large number of prediction modes and macroblock types, which are essentially attempts to encode more efficiently the differences between successive frames.
The maths has actually gotten simpler; the predecessors are all traditional DCT-based (JPEG-like) codecs while H.264 uses a simple integer approximation. Regardless, from a decoder implementation perspective, the theory behind it all is not that important; the spec tells you exactly what you need to do, and the increase in complexity is mainly reflected in needing to write more code to handle the larger number of cases.
H.261 is simple because it has a choice of only two resolutions, one framerate, two frame types (I and P), and 10 macroblock types.
H.262/MPEG-2 is already a significant increase in complexity since it supports a varying set of resolutions, framerates, interlacing, and chroma subsampling, has 3 frame types (I, P, B), 20 macroblock types (dependent on frame type), and more complex motion compensation.
H.263 has no interlacing but adds optional intra prediction, more advanced motion vector encoding, and a few other features.
H.264 has about 50 macroblock types, even more complex intra prediction, and motion compensation has a larger choice of which frames to predict from.
I had to resist the urge to post something similar and yea, it's still way too hard to track down documentation for already solved stuff like this, so there's great value in an article demystifying the process.
> (To be fair, knowing ffmpeg exists doesn't mean I'd be able to easily write a video player with it without a lot of research. For that reason I find this tutorial is still quite interesting and valuable.)
The tutorial is still 1000 lines of C, involving SDL, ffmpeg and threads.
Yikes :)
Last time I did something like this (a UI that among other things, played a live stream from a cheapo IP camera), I used python and the libvlc python bindings. Creating a bare bones media player with it was trivial and it worked very well for what I needed. The only complaint I had at the time was that the documentation was absolutely terrible. A cursory look today reveals that they seem to have improved it, so yay?
And yes, the end result in my case came out MUCH smaller than 1000 lines (but lines of code is a shitty metric anyway).
If you "just" need a media player, IMHO, libvlc is not an awful option (in Python, at least - I have no experience with other bindings): https://wiki.videolan.org/LibVLC/
You got my downvote, there. I saw your comment before I got a chance to read the article, and once I saw the article, and its many pages breaking the components down into introducing the framework, outputting video, sound, etc...
The equivalent to what you're saying would be if he'd just used the HTML5 <video> tag.
This is actually a great article, it taught me a little bit more about FFMPEG under the hood, and knowledge is power.
