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.
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?
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.
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.
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"?
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.
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.
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.
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.
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.
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"):
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.
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. :)
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?
I didn't know about MediaCoder, I was talking about the wall of shame in general. I won't try to speak for the developers themselves. I'd be interested to know if any patches have been rejected without comment recently.
> 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....
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.
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.
Well, it is the way Audacity gets around patent issues. The official builds (at least on Windows) come with support for FFmpeg, but not the DLL. If you want FFmpeg, you either need to build it yourself or download a pre-built version. Once added to your %PATH%, Audacity will dynamically load the libraries at runtime.
The funny/ironic thing is that ffmpeg (they HATE when people spell it FFmpeg -- FFmpeg is to ffmpeg as Frisco is to San Francisco) is very likely infringing on MPEG LA's patents. They have a glob of evasive rhetoric tiptoeing around that issue ("we are not lawyers," etc.) in their FAQ while not failing to expose their hypocrisy.
> 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.
They are pretending they are free software but they are not. They pretend they are non profit but use scare tactics like commercial companies. Seriously its one thing to contribute for public good and another thing to restrict its usage. I am sorry but no matter how many times GPL envenglists redefine "free", its not.
No it protects the users freedom. One you understand that the GPL/LGPL are intended to protect user freedom not developer freedom they make a lot more sense.
I don't see any scare tactics, and no-one's pretending to be non-profit who isn't. The LGPL terms are really not very onerous (we're not talking about the GPL here), and do make users' lives a lot easier.
> The LGPL terms are really not very onerous (we're not talking about the GPL here), and do make users' lives a lot easier.
We are talking about complex licences here. If you are going to release something in public good, please make the licence short and sweet like MIT/BSD.
GPL ( even LGPL) are dev-unfriendly licences and restrict devs freedom.
> GPL ( even LGPL) are dev-unfriendly licences and restrict devs freedom.
I concur it's the very contrary.
When I (an end user, somewhat skilled in software development) obtain a GPL-licensed piece of software, I'm granted the freedoms to modify it and distribute my modifications. Or hire someone to do so. Or whatever. The only thing I'm asked is to grant others the same freedoms I enjoy myself, if I'd to distribute the software further.
When I obtain a proprietary piece of software, I can either curse my way through reverse-engineering (as far as it's legal in my juristdiction) or wait until the proprietors would do something. That said, I'm basically powerless.
When I obtain a BSD or MIT-licensed piece of software, it depends on the good will of the developers whenever they provide me with the source code (and license grants) or not. If they do, my options roughly match the GPL case - I'm granted the four essential freedoms. If they don't, then it's no different from the case that I just got a proprietary blob. So, we're basically relying on everyone's good will - but given so, GPL doesn't hinder the experience of those who're sharing anyway, and simply excludes those who don't want to respect their users with "if you don't want others to use your code, then don't use my code - write your own" attitude.
I can't call "unfriendly" asking to respect another developer's will to keep their code free for everyone. Yes, the licensing makes their code unfit for the purposes of developing proprietary software, but being unfit is not unfriendly.
> When I (an end user, somewhat skilled in software development) obtain a GPL-licensed piece of software, I'm granted the freedoms to modify it and distribute my modifications. Or hire someone to do so. Or whatever. The only thing I'm asked is to grant others the same freedoms I enjoy myself, if I'd to distribute the software further.
> I can't call "unfriendly" asking to respect another developer's will to keep their code free for everyone. Yes, the licensing makes their code unfit for the purposes of developing proprietary software, but being unfit is not unfriendly.
We are arguing semantics here. The point is, a dev cannot make use of GPL software in closed src. GPL software has a VERY BIG cost/restriciton and it will most likely outweigh open sourceness where as Proprietary/MIT/BSD does not require every confidential intellectual property it touches to be made public.
> When I obtain a proprietary piece of software, I can either curse my way through reverse-engineering (as far as it's legal in my juristdiction) or wait until the proprietors would do something. That said, I'm basically powerless.
Proprietary software can be open source. Beside we are not talking about open source here. We are talking about viral nature of GPL.
> When I obtain a BSD or MIT-licensed piece of software, it depends on the good will of the developers whenever they provide me with the source code (and license grants) or not.
BSD/MIT automatically implies open source.
> If they do, my options roughly match the GPL case
Except the big restriction.
> GPL doesn't hinder the experience of those who're sharing anyway, and simply excludes those who don't want to respect their users with "if you don't want others to use your code, then don't use my code - write your own" attitude.
This is fine attitude to have if you are the only contributing. But most open source contributors do not care.
They rather contribute than waste their time in flame wars. Case in point: GPL/share-alike adoption has been in steady decline.
All GPL does is stop devs from using it rather than create more open source softwares as GPL creaters hoped. You donate open source not demand it. But its seems GPL creaters missed that point.
> The point is, a dev cannot make use of GPL software in closed src.
Yes. That's the very idea of GPL. One's either accepting it and gets what it grants, or not.
> BSD/MIT automatically implies open source.
Ok, I simplified the wording and the meaning was lost. Let me fix it. I meant, I got a binary but that binary was produced from a BSD/MIT/Apache/whatever-licensed source code. If that source isn't available to me (like on the almost every single Android phone we have out there), I'm basically powerless.
> Proprietary software can be open source.
This is certainly wrong. Unless you're not using OSI definition of open source, but something of your own. Or if we mean something different under the term "proprietary".
> Case in point: GPL/share-alike adoption has been in steady decline.
Not surprising. GPL had lost, you're totally right on this.
It was predicted long ago - as most users don't possess any engineering skills, they don't exercise their freedoms to access the source code, modify it and distribute the modifications. The freedom to distribute the original software lost it to the unauthorized distribution ("piracy") and freemium-type software. Users don't care (actually IIRC it was shown that they tend to cope with whatever inconvenience they find, rather than try to fix it - that's also how privacy wars were lost), and developers find it that proprietary software has a well-known business models to bring profits, while free software requires to tread carefully.
Yet, it's wrong that "all it does is stop devs from using it". The word "all" is surely incorrect. It does stop some devs from using it - two groups, actully: a) those who want to develop proprietary software and b) those who just can't stand it for any personal reasons. But that's not all it does - I've mentioned what it also does above.
> Ok, I simplified the wording and the meaning was lost. Let me fix it. I meant, I got a binary but that binary was produced from a BSD/MIT/Apache/whatever-licensed source code. If that source isn't available to me (like on the almost every single Android phone we have out there), I'm basically powerless.
The BSD/MIT is the agreement between original devs and binary provider. There is no BSD/MIT between binary provider and you. If all the company is giving you binary but not source I dont think there can be BSD/MIT. So if someone gives you something labeled as BSD/MIT its going to be open source with no string attached.
> This is certainly wrong. Unless you're not using OSI definition of open source, but something of your own. Or if we mean something different under the term "proprietary".
It appears I am using my definiton for open source. To me open source means something whose source files are available.
So proprietary can come with sources which is likely for dev centric software.
> It was predicted long ago - as most users don't possess any engineering skills, they don't exercise their freedoms to access the source code, modify it and distribute the modifications. The freedom to distribute the original software lost it to the unauthorized distribution ("piracy") and freemium-type software. Users don't care (actually IIRC it was shown that they tend to cope with whatever inconvenience they find, rather than try to fix it - that's also how privacy wars were lost), and developers find it that proprietary software has a well-known business models to bring profits, while free software requires to tread carefully.
I agree GPL is user-friendly but it is so at the cost of dev-unfriendliness.
> Yet, it's wrong that "all it does is stop devs from using it". The word "all" is surely incorrect. It does stop some devs from using it - two groups, actully: a) those who want to develop proprietary software and b) those who just can't stand it for any personal reasons. But that's not all it does - I've mentioned what it also does above.
We are on HN so almost all devs are people who develop proprietary softwares. Even HN aside, all most all software development is proprietary. Hence the trend.
In my ideal world open source development works like this. We come togther, do our part while asking nothing in return and solve a common problem. Thats it. No strings or condition or anything.
It seems you've created your own definitions for both "open source" and "free software" in order to exclude copyleft from both categories and allow proprietary software to be included in both categories. Both of these terms have definitions going back decades by now which contradict yours; in the open source case, one of the reasons for starting to using the term in the first place was to avoid possible misconceptions or misunderstandings of what "free software" referred to!
Definiton I am using is common sense. OSI one is overly complex for example it has point "5. No Discrimination Against Persons or Groups".
> It seems you've created your own definitions for both "open source" and "free software" in order to exclude copyleft from both categories
Copyleft is not a requirement for open source or OSI Open Source. It is for FSF Free Software though.
I am aware of how "free software" can be misinterpreted. Thats why I havnt used it. But allow me to explain whats wrong with FSF definition. The word free implies unrestricted freedom like MIT/Public Domain which is true for users but not devs (proprietary devs to be specific). Nothing wrong with intention of this perticular definiton. But choice of the word is misleading. "republic software" may be ? Also note both are lawyers definitons.
Just curious what would you label something whose source you can view and/or modify for personal use ? Google says open source.
All this definition debate aside, last 5 posts have been about dev unfriendly restrictions of GPL/copyleft/share-alike. Free software was not mentioned at all. Only once[1] I mention open source which is to illustrate the point that proprietary does not necessarily mean you cannot view the source and cannot modify for personal use. Proprietary certainly does not come with same big restrictions as GPL. For a dev,
MIT/BSD > Proprietary with source > Proprietary >>> GPL.
> Both of these terms have definitions going back decades by now which contradict yours; in the open source case, one of the reasons for starting to using the term in the first place was to avoid possible misconceptions or misunderstandings of what "free software" referred to!
Yes both have been standardized but I doubt the actual adoption.
[1] Okay I have used it more than once. But every other usage works with either definitons.
The qualifier to note is "same" not "big restrictions".
No sane developer agreement[1] would require the modification/usage and all other associated confidential IPs to be disclosed. Or it would suffer heavy market share just like GPL. Ofcourse this does not mean such proprietary softwares does not exist but they would be abandoned once another competing product without such restrictions comes to market, just like GPL.
[1] Or even EULAs if the software is likely to be used as building block such as Photoshop/Unity etc.
[2] I am assuming here. I would like to know if such softwares exist.
I meant the EULAs on end user software. This perfectly illustrates how completely people miss the point of the GPL.
The GPL is intended to promote the freedoms of the end users of software. It is not really that concerned with developers as a special category of users. People already understand all the points you are making about developer freedom being more important that user freedom and either: (1) agree with you or, (2) disagree. If you don't like it just don't use it on your own work and use liberally licensed libraries in your own projects, don't complain on the internet about how other people choose to treat their own IP.
Also your definitions are contrary to the generally accepted and fairly clearly defined ones which will just lead to confusion for you and people you interact with. Maybe it would be easier to just use the right words rather than fighting to re-define them?
I dont know where I made you think that I misunderstand the intentions of GPL.
> The GPL is intended to promote the freedoms of the end users of software. It is not really that concerned with developers as a special category of users. People already understand all the points you are making about developer freedom being more important that user freedom and either: (1) agree with you or, (2) disagree.
You twice brought users into the discussion but its about effect of GPL on devs.
> If you don't like it just don't use it on your own work and use liberally licensed libraries in your own projects, don't complain on the internet about how other people choose to treat their own IP.
I am not complaining. I am convincing that GPL is dev-unfreindly. That is convincing devs to stay away from GPL not dictacting how they should licence their own softwares.
I am also sad GPL people have made great massively collabrated projects (where most contributers do not even realize what restrictions they are imposing, even on themselves) like OpenStreetMap canserous. I will be very happy when this ideaology dies.
> Also your definitions are contrary to the generally accepted and fairly clearly defined ones which will just lead to confusion for you and people you interact with. Maybe it would be easier to just use the right words rather than fighting to re-define them?
Okey now you are just nitpicking. There is only one place where I can be misunderstood, and I have clarified it twice.
OK so you are advocating a POV rather than discussing an issue.
Just a word of advice for your future advocacy endeavours. The GPL is about users. Devs aren't special according to its proponents. You will need to appreciate the fact that the GPL is about user freedom in order to convince them.
So whats the issue ? Whether one should pick GPL for his own software. ANSWER: NO.
Most worthwhile open source contributions are paid by commercial companies. And if given a choice they will spend their money in contributing to BSD/MIT softwares rather than GPL. By picking GPL you would be decreasing potential contributions.
We havnt even discussed the elephent in the room. How your project can turn into legal battle ground, divide the community and fill the maillist and issue tracker with nonsense rather than actual work. Or how *GPL licence is so complex and still there is no common consensus on its interpretation. Or how little it is tested in courts and even that in just two countries. Or what GPLv4 turned out to be and would it recieve the same fate as GPLv3.
I shouldn't be getting drawn into this but here goes.
The issue is freedom and IP rights.
Maybe you are missing some fundamental understanding about IP rights. If person A (might be an individual or a company) writes some software it is person A's IP with person A's copyright and they have the right to choose its licence according to their own preferences. If person B writes some other software they can want to use person A's library, however, person B has no fundamental right to use person A's IP. This right can only be derived from person A's permission which is often supplied for software in the form of a licence.
Some people like the idea of their software never ending up in a proprietary product so they choose the GPL. Others don't care so they choose liberal licences. Others want to make a dollar every time someone else uses their software so they choose proprietary licences. Other don't care about non-commercial usage but want to make a dollar every time someone else makes a dollar using their IP - they might choose dual AGPL+proprietary. Others might like to licence only for use in space/underwater/1000m above sea level/on a train again their choice not mine or yours. Even Richard Stallman recommends more liberal licences in some scenarios and actually ffmpeg might class as one of those (analogous to ogg vorbis).
In summary: In the current world people are free to choose how other people use their IP.
> We havnt even discussed the elephent in the room. How your project can turn into legal battle ground, divide the community and fill the maillist and issue tracker with nonsense rather than actual work. Or how *GPL licence is so complex and still there is no common consensus on its interpretation. Or how little it is tested in courts and even that in just two countries. Or what GPLv4 turned out to be and would it recieve the same fate as GPLv3.
With the state of software patents any project under any licence can turn into a legal battle ground.
> Proprietary/MIT/BSD does not require every confidential intellectual property it touches to be made public.
A lot of proprietary libraries you can license have very onerous licensing terms; certainly much longer and more complex than the LGPL. E.g. the notice requirements that got MediaCoder into trouble are often exactly the same (that's why so many programs have "contains an implementation of the LZW algorithm" or "uses Bink video technology" or "built with the Unreal engine" or that Creative sound codec I've forgotten the name of, on their splash screens and in their about boxes). Heck, the advertising clause in the original (4-clause) BSD license is much more onerous than anything in the LGPL. Sure, the makers of those libraries don't say "we will give you free legal advice but only if you make your whole program open-source" - but that's because they won't offer you free legal advice at all, they expect you to understand and comply with the license you have from them. And you will often have to e.g. give them access to perform audits so that they can confirm you're complying with the license (and paying royalties correctly, if you're using a library you pay per-use royalties for).
The LGPL is less permissive than the MIT license, sure. But it's absurd to claim it's somehow less open source or more restricted than typical proprietary library licenses.
