8 ms·

How to Write a Video Player in Less Than 1000 Lines

127 points by striking 11y ago

gruez 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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"?
- LukeShu 11y ago
  I'm 99% sure that I've seen that "how to write a web browser in less than 100 lines" article; though I think we were calling it "embedding IE as a COM component", not a WebView.
sunnyshahmca 11y ago
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.
SoapSeller 11y ago
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 11y ago
  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.
tbirdz 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      calling out hardware != using software libraries
      - vog 11y ago
        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.
Hydraulix989 11y ago
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.
Hydraulix989 11y ago
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_of_projects_or_companies/ https://www.reddit.com/comments/9e25a/hall_of_shame_a_list_o... 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. :)
- voltagex_ 11y ago
  Any perceived nastiness might come from years of people earning lots of cash from using ffmpeg and giving nothing back.
  - Hydraulix989 11y ago
    That's surprising to me because it's entirely possible to commercialize ffmpeg derivatives using LGPL while still complying with that license. In MediaCoder's case, the nastiness ensued because the author didn't distribute the source code with the ffmpeg binaries that he included with his software. LGPL v3 even relaxes that particular clause at issue by adding: "If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code." Meanwhile, the ffmpeg authors bull-headedly refused to mention to the MC developer what term he was violating, and other ffmpeg mailing list users were equally as puzzled as the MC developer. I might add that the MC developer submitted patches with contributions to ffmpeg, all of which were refused without cause by the ffmpeg team. This kind of treatment seems pretty tight-wad, wouldn't you say so?
ratboy666 11y ago
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.

127 points by striking 11y ago

gruez 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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"?
LukeShu 11y ago
I'm 99% sure that I've seen that "how to write a web browser in less than 100 lines" article; though I think we were calling it "embedding IE as a COM component", not a WebView.

sunnyshahmca 11y ago

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.

SoapSeller 11y ago

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 11y ago
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.

tbirdz 11y ago

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 11y ago
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 11y ago
  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 11y ago
    calling out hardware != using software libraries
    - vog 11y ago
      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.

Hydraulix989 11y ago

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.

Hydraulix989 11y ago

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_of_projects_or_companies/ https://www.reddit.com/comments/9e25a/hall_of_shame_a_list_o... 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. :)

voltagex_ 11y ago
Any perceived nastiness might come from years of people earning lots of cash from using ffmpeg and giving nothing back.
- Hydraulix989 11y ago
  That's surprising to me because it's entirely possible to commercialize ffmpeg derivatives using LGPL while still complying with that license. In MediaCoder's case, the nastiness ensued because the author didn't distribute the source code with the ffmpeg binaries that he included with his software. LGPL v3 even relaxes that particular clause at issue by adding: "If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code." Meanwhile, the ffmpeg authors bull-headedly refused to mention to the MC developer what term he was violating, and other ffmpeg mailing list users were equally as puzzled as the MC developer. I might add that the MC developer submitted patches with contributions to ffmpeg, all of which were refused without cause by the ffmpeg team. This kind of treatment seems pretty tight-wad, wouldn't you say so?

ratboy666 11y ago

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.