I'm looking for a non-(L)GPL library to decode MPEG-4 stream. I don't mind it being commercial. The price is as not important as code quality and support. Any suggestions are welcome. Your own experience is even better.
-
1LGPL is not an option because user could hijack DLL to copy the video. – Łukasz Lew Jan 04 '11 at 14:56
-
2@Lukasz Lew, you must be kidding me. Security through obscurity does not work, tried and failed thousands of times. – ismail Jan 04 '11 at 14:58
-
1The problem with DLL hijack is not with users but with content providers. They are not willing to stream their videos if I use any codec that is in separate DLL. – Łukasz Lew Jan 04 '11 at 15:13
-
Srlsly? Isn't for example Flash in separate DLL? – vartec Jan 04 '11 at 15:19
-
Yes. avcodec has to be in DLL that is named avcodec.dll and it has fixed interface. It is very simple to create DLL-in-the-middle to dump the stream. You can't do such thing with flash. – Łukasz Lew Jan 04 '11 at 15:27
4 Answers
You can only try Commercial ones:
Ligos : http://ligos.com/index.php/home/products/mediarig_encoder/
MainConcept : http://www.mainconcept.com/products/sdks/video.html
Rohzet (carbon coder) : http://www.rhozet.com/products.html
Flip factory : http://www.telestream.net/flipfactory/overview.htm
All of these are practically well used in broadcast productions and are of good grade. The order doesn't reflect any preference. Most of them are either usable as SDK or independent application with dongle or otherwise.
However, your fear is rather fundamental, and fleeing DLL might not be possible to be prevented trivially.

- 2,110
- 1
- 17
- 31
I was under the impression that CoreAVC is by far the best performant H.264 codec. http://corecodec.com/products/coreavc

- 11,270
- 7
- 55
- 129
-
I have troubles with communication with that company. I sent and received two e-mails. It took two months. – Łukasz Lew Jan 04 '11 at 14:43
Depends what you mean by non-GPL. There are many that are LGPL (thus non-viral). Like the most popular one libavcodec which is part of FFmpeg.
By contrast x264, which is GPL-ed, is only needed for encoding, not for decoding.
FFmpeg makes it clear how to compile it in non-viral way.

- 131,205
- 36
- 218
- 244
-
LGPL is not an option for me since it would need to be put in a separate DLL. This would allow to create a simple DLL hijack to illegally dump the video stream. – Łukasz Lew Jan 04 '11 at 14:58
-
-
There are ways to deal with that. It wouldn't be very difficult to check the hash of the DLL. – vartec Jan 04 '11 at 15:18
-
LGPL and separate DLL has nothing in common, you can compile FFMPEG as static library so no separate DLL – Andriy Tylychko Jan 04 '11 at 16:51
-
1@Andy Wrong, the LGPL dictates the requirement that the user be able to replace the LGPL library in your application. This requires one of two methodologies, the first being dynamic linking. The second option would be to distribute the compiled object code before linking so that the user could link in their own version of the library. BTW, IANAL. – joshperry Mar 02 '11 at 20:42
-
@joshperry: +1, interesting, didn't know this. as I understood, [static linking means `derivative work`](http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Differences_from_the_GPL) and is inappropriate for most closed-source projects – Andriy Tylychko Mar 05 '11 at 21:28
-
so if I use ffmpeg x264 format only for encoding then I don't have to worry about anything? – user924 Dec 20 '17 at 20:03
Are you going to require your own videocard drivers as well, or what happens if I use a video driver that does whatever I want with what your decoder sends me? Are you going to somehow force users to use only your video cables as well, and somehow destroy any video camera in the vicinity, and wipe clean the users' memories of what they see? Such madness! So what if you use a GPL library? You cannot lock down the Universe.
-
As I said in the comment the problem is not with the users but with the content providers. They explicitly don't want a codec in a separate DLL. – Łukasz Lew Jan 04 '11 at 16:22
-