Hacker News Reader

Comment by tbirdz | Hacker News Reader

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.

View on HN

The goal of this site is to provide a tutorial on how to use ffmpeg as a library. The real title is "An ffmpeg and SDL Tutorial", and the web page title is "ffmpeg tutorial". The link was posted here with only the subtitle, to make the post more alluring or mysterious (AKA clickbait).

The tutorial itself is solid, though it should probably mention the year of publication in the title - it was last updated in 2015, but it has been around since 2007.

I know you are joking, but speaking of libraries, you can now create custom video players with libVLC in less than 100 lines, and get a lot of features in a few hundreds lines. (VLC is now based on libVLC)

And that works on all platforms, including Android and iOS, and gives you both hardware decoding and FFmpeg libavcodec software decoding. Without having the complexity (and sometimes performance issues) of GStreamer.

Would you need a license for H.264 and other codecs, if you wanted to put up a fully open source MIT-licensed custom-purpose libVLC-based player that you created on the iOS, Android, Mac, et al app stores?

First, libVLC is LGPL. But for the other part, it depends.

For MPEG-4 ASP or H.264, this is usually decoded by the hardware or the OS. For some other codecs, notably Dolby and DTS, it's more tricky.

Oop, I should have been more clear -- I meant patent licenses for codecs that are still encumbered by patents.

He also forgot to mention that you first have to create the universe.

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.

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.

calling out hardware != using software libraries

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.

> 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

Do you really think those DirectX libraries have music players, graphics assets (so that you don't need to procedurally generate all) and other components that intros/demos need?

Writing 4k demos is anything but trivial. It's in no way comparable to video player situation.

> 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.

But all developers still have the same size limit and access to the same apis. Which means that creative competition is totally possible.

Yes. But what I mean is, people look at some demos and say "wow this only fits into 4k", and they completely forget that these demos rely on hundred of Mbs of system libraries in the first place.

But sure, comparing between 4k demos is possible, but as DirectX evolves the comparison becomes unfair, since the system libraries add more functionalities over time.

That's true. I still remember the times where all you had was api to set individual pixels in 64Kb memory area. Yet people were able to make nice effects even using 256 bytes of assembly code.

This is society that we live in. We keep building on each other's stuff and it's good. :D Let's keep moving the needle. Let's see where we end up.

Reply on news.ycombinator.com