
How to Write a Video Player in Less Than 1000 Lines - striking
http://dranger.com/ffmpeg/
======
tbirdz
How to write a video player in 2 lines:

    
    
        #! /bin/sh
        vlc "$1"
    

In all seriousness though, if you are using libraries to implement almost all
of the complex functionality, then the "less than 1000 lines" comment is not
very relevant.

~~~
ekianjo
The problem is not limited to this article. For example in the Windows demo-
scene world, it's trivial to do 4k/64k demos by using all the DirectX
libraries available in the OS. So that the size of the actual demo is
completely relevant since you benefit from massive system libraries.

~~~
tbirdz
To be fair, many old school demos are calling out to specialized hardware in
their demos, for example the C64 SID chip, or Amiga graphics chipset. The API
for accessing this hardware is not as high-level as DirectX, but it still
serves as an external library of sorts for performing graphics/audio
operations. All the software-based graphics routines these demo coders created
are very impressive, don't get me wrong, but in the end there's still a large
part of the pipeline that the coder relies on that they did not create
themselves, and isn't factored into the overall code size.

Additionally, current OSes make it really hard, if not impossible, to get down
to this level of bare hardware. There's many layers on top that you're forced
to go through, closed graphics command stream, closed graphics driver, closed
kernel, closed userspace libraries, and the hardware is much more complex.
Really DirectX does serve as the lowest level standard way on Windows to
access graphics card hardware.

~~~
gcb0
calling out hardware != using software libraries

~~~
vog
It is the same issue, just moved around to a different component. In today's
world, most of the time "calling out hardware" means just triggering some
piece of software on a separate chip.

Nevertheless, I do think that the demo scene is impressive - for a different
reason.

I believe this is not about the absolute code size, but the _relative_ code
size: Within each demo category, all demos run on almost the same hardware
architecture and same software platform. Yet, some of them manage to create
effects in 4k which most other programmers wouldn't manage to create in 64k.

It is not about where the limits are (4k, 64k, 32 bytes, ...), but that there
are limits at all. This inspires creativity, pushing the border of what people
believe is doable within these limits.

------
gruez
Title is misleading. It's like writing a guide on how to instantiate a webview
and calling it "how to write a web browser in less than 100 lines".

~~~
slimsag
Agree, and it's a pity because this tutorial looks great. A better title would
be:

"Write your own video player with SDL and ffmpeg!"

Or something along those lines, anyway.

~~~
striking
Sorry about the clickbaity (although semi-accurate) title.

I would change it, but the post got revived from yesterday, so the edit
button's gone.

Is it really that bad a title, though? Few people actually write their own
video decoder or display code anymore...

~~~
taneq
It's not that bad, it's just the "how to write a ..." bit seems to imply that
you're actually implementing one, not just loading a library to play one.
Maybe "How to play a video in less than 1000 lines"?

------
SoapSeller
Ths tutorial is mostly about learning how to use FFMPEG&SDL.

While SDL has pretty good docs, FFMPEG(the library, not the command line tool)
has terrible one.

This is probably the best source of information about FFMPEG(beside the actual
code).

~~~
sunnyshahmca
Yeah, Totally agree. But FFMpeg code is pretty easy to read. I created a video
player with it for an embedded device, also implemented hardware accelerated
YUV->RGB in it.

------
sunnyshahmca
Before 8 years, I followed this tutorial and created a production video player
for an e-learning device. FFMpeg gives much better performance ( and less
flexibility ) than GStreamer.

------
Hydraulix989
Great tutorial, the information on AV syncing is a little out of date. If the
audio gets ahead of the video, then the video doesn't instantaneously skip to
catch up, it continuously renders frames at full rate.

IIRC, I also don't think their mapping from SDL audio channels to ffmpeg
channels is surjective (to say nothing of planar/non-planar audio).

I would suggest reading the ffplay.c example code.

------
ratboy666
So, my first thought on reading the title was "Good, someone has (re)
discovered APL (or J, K, Q or another array language)." Could be a good
algorithmic dive into mpeg. Mpeg decode and a simple player seems like a
reasonable sub-1000 line APL project. I include mp3 audio decode, of course.

Complete disappointment -- I learn nothing.

------
Hydraulix989
CAREFUL with ffmpeg!

Their license is DRACONIAN, and they are nasty about enforcing it.

Their legal page even suggests (or should I say, demands) additional
provisions above and beyond what the LGPL asks for (i.e. "There are also a few
items that are not really related to LGPL compliance but are good ideas
anyway"):

[https://www.ffmpeg.org/legal.html](https://www.ffmpeg.org/legal.html)

If they catch you violating their LGPL license, they act very antagonistically
to you -- as in, they are completely unwilling to work with you by taking the
hard line stance that the only way you can appease them and comply with their
license is to release your source code.

They even once had a Hall of Shame where they publicly called out offenders:
[https://www.reddit.com/comments/9e25a/hall_of_shame_a_list_o...](https://www.reddit.com/comments/9e25a/hall_of_shame_a_list_of_projects_or_companies/)

LGPL means no static linking, so using ffmpeg in your closed source
Android/iOS apps is already completely ruled out of the picture.

I mean, it's well within their rights to impose whatever license they want on
their software, but you shouldn't think that using ffmpeg in any closed source
or commercial software is a good idea.

EDIT: I think it's worth mentioning that none of this comes from personal
experience. :)

~~~
lmm
> Their license is DRACONIAN, and they are nasty about enforcing it.

The license is not draconian in the usual sense of the word. The requirements
of the LGPL are modest (frankly they require you to grant end users just about
the minimum rights that users should always get for any library that was used
in a program, IMO), and the license is well known and well understood.

> Their legal page even suggests (or should I say, demands) additional
> provisions above and beyond what the LGPL asks for (i.e. "There are also a
> few items that are not really related to LGPL compliance but are good ideas
> anyway"):

They explicitly say "It is not the only way to comply with the license, but we
think it is the easiest."

> If they catch you violating their LGPL license, they act very
> antagonistically to you -- as in, they are completely unwilling to work with
> you by taking the hard line stance that the only way you can appease them
> and comply with their license is to release your source code. > They even
> once had a Hall of Shame where they publicly called out offenders:
> [https://www.reddit.com/comments/9e25a/hall_of_shame_a_list_o...](https://www.reddit.com/comments/9e25a/hall_of_shame_a_list_o..).

You're talking about using stuff in closed source or commercial software? Do
you imagine a commercial company who you licensed a library from and then
proceeded to violate that license would be friendlier than that? Never mind
hall of shame, you'll be looking at demands for thousands of dollars. They
could be nicer about it but if they believe closed source software is
inherently harmful to its users I can understand their position, and it's not
their job to give you free legal advice.

> LGPL means no static linking, so using ffmpeg in your closed source
> Android/iOS apps is already completely ruled out of the picture.

I've used android apps that use it by allowing you to place the ffmpeg DLL in
their folder. It's more work (which is a problem with Android that should be
improved on) but it's the only way I can see to make sure that end users don't
get stuck with an old version. For exceedingly complex C code like video
codecs, security flaws are basically guaranteed (and sadly for the moment C
seems to be regarded necessary for performance - I've seen some OCaml/Haskell
video codecs but nothing like the wide format support of ffmpeg), and video
players are often used on untrusted files from the internet. So if you were
ever to stop developing your app - or even if the play store refused updates
for whatever means - it's absolutely vital to your end users' security that
they be able to upgrade the version of ffmpeg that the app uses, and this kind
of license is the only way to enforce that.

~~~
richardwhiuk
> I've used android apps that use it by allowing you to place the ffmpeg DLL
> in their folder

That's a ridiculously user hostile behaviour.

~~~
lmm
I've seen an app offer a link to a recommended version - one button first time
you run - and you then just have to "open" it with the app (and it'll use the
DLL from the "Downloads" folder). That's not seamless, but it's pretty close.

The fact that android doesn't offer any native way to have apps depend on
dynamic libraries is ridiculously user hostile on its part.

~~~
Hydraulix989
Wow, does non-rooted Android let apps load libraries from the Downloads
folder?

Seems like that could create some pretty big security issues.

~~~
lmm
Hmm, you're right. That's the way I remember it working but maybe I'm getting
confused.

