Slashdot Mirror

You can view the source for libaom, which is the reference encoder and decoder. And FFmpeg 4.0 (which incorporates libaom) has been released.

or straight ffmpeg for a more low-level/ghetto feel(*).

Regarding the upload:
- Keep in mind that Google will recompress each uploaded video using its whole range of supported codec and varied screen resolution.
(Even if you upload a good H264, it will also generate lower bitrate H264, VP9, Theora, H263, soon AV1 too, etc. Same goes with audio: AAC, OPUS, Vorbis, MPEG Audio Layer, etc.)
- Thus even if you have a ginormous internet connection with massive bandwidth, the recompression *will* take time even if the file transfer itself finishes quickly. You'll have to wait anyway until the various versions become available.

OBS/ffmpeg/ShadowPlay won't change much to that part.
---

(*) actually, it's not only for the lulz / ghetto feel. We're a bioinformatics lab, most of the people here around are more used to run command-line pipeline on the CLI. ffmpeg actualy *does* make sense to them.

Old school: Use the lowest level language in which you can solve the problem conveniently.
New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting.

I think you'll agree that the new school is the majority.

That's because the Chrome and Firefox web browsers and the Thunderbird mail client have enough of a budget for multi-platform development and testing.

I use the same image editor on all three platforms. I use the same network analyzer on all three platforms. I use the same video tools on all three platforms. I use the same office suite on all three platforms. I use the same shell, the same command line tools, the same interpreters on all three platforms.

The claim that native applications equal only one operating system is plainly false. It's pointless trying to defend that position.

https://trac.ffmpeg.org/query?...

read about them.

https://trac.ffmpeg.org/query?...

Lock and load, boys.

Compiling FFmpeg on Ubuntu / Debian / Mint

Compiling FFmpeg on CentOS / RHEL / Fedora

Other platforms.

Compiling FFmpeg on Ubuntu / Debian / Mint

Compiling FFmpeg on CentOS / RHEL / Fedora

Other platforms.

Compiling FFmpeg on Ubuntu / Debian / Mint

Compiling FFmpeg on CentOS / RHEL / Fedora

Other platforms.

You don't need to pretend to know when you can read and know exactly what the owners of FFmpeg, and GPL (and LGPL) in general, require right here:

https://www.ffmpeg.org/legal.h...

Like stealing from a Girl Scout

https://trac.ffmpeg.org/query?...

You could try it out
https://trac.ffmpeg.org/wiki/H...

https://trac.ffmpeg.org/query?...

Parasites, or what exactly are these? Criminals? Is it a crime?

Like this one

https://trac.ffmpeg.org/ticket...

Blue Iris Video Security Software

  Perspective Software

No indication of GPL use. Claims work as his own.

From the download package, BlueIris.exe is UPX compressed. Decompress, then investigate 22 MB file with strings.exe.

libswresample license: GPL version 2 or later

  libswscale license: GPL version 2 or later

  libavcodec license: GPL version 2 or later

  libavformat license: GPL version 2 or later

  libavutil license: GPL version 2 or later

Compile strings discovered:

--enable-gpl --cpu=i686 --prefix=/c/msys/1.0/ffmpeg/build --enable-libx264

Here's something fun to do. Tell PayPal that BlueIris is violating term 9c of the user agreement (since they take PayPal for their registration fee):

PayPal User Agreement

Like this one

https://trac.ffmpeg.org/ticket...

Blue Iris Video Security Software
  Perspective Software

No indication of GPL use. Claims work as his own.

From the download package, BlueIris.exe is UPX compressed. Decompress, then investigate 22 MB file with strings.exe.

libswresample license: GPL version 2 or later
  libswscale license: GPL version 2 or later
  libavcodec license: GPL version 2 or later
  libavformat license: GPL version 2 or later
  libavutil license: GPL version 2 or later

Compile strings discovered:

--enable-gpl --cpu=i686 --prefix=/c/msys/1.0/ffmpeg/build --enable-libx264

All this has been baked and there's multiple documents covering it along with any customizations. I realize handbrake is out there and I use it but sometimes ffmpeg direct is always best for me. scaling example:

-vf scale=640:480

for removing black bars example:

-vf "cropdetect=24:16:0" to a dummy file, then once you know the size of the bars (crop detect output)
-vf "crop=640:256:0:36"

Again, there's lots of recipes out there and it's all documented as well. Just search.

I was really excited to see that new builds of ffmpeg (which is FOSS) implement the hqx family of filters, but I've also read that these filters are pretty outdated at this point. So I was hoping that this article would be a comparison of upscaling algorithms, both free and proprietary. But alas...

I'm talking data de-duplication searching tools,

Son, are you kidding me?

multi-monitor window managers,

What?

downloading / p2p tools,

Excuse me?

media players,

You fail it

media encoders

Wrong

etc.

Are you even trying?


In unrelated news, slashdot doesn't let me post this reply as-is, because it consists of too short lines, on average. Wtf. Fooooooooooooooooooooooooooooooooooooooooooooooo

Well no, however consider this

http://www.ffmpeg.org/legal.html

Q: Bottom line: Should I be worried about patent issues if I use FFmpeg?
A: Are you a private user working with FFmpeg for your own personal purposes? If so, there is remarkably little reason to be concerned. Are you using FFmpeg in a commercial software product? Read on to the next question...

Q: Is it perfectly alright to incorporate the whole FFmpeg core into my own commercial product?
A: You might have a problem here. There have been cases where companies have used FFmpeg in their products. These companies found out that once you start trying to make money from patented technologies, the owners of the patents will come after their licensing fees. Notably, MPEG LA is vigilant and diligent about collecting for MPEG-related technologies.

So what happens in practice is if you use FFMpeg non commercially there's no reason for them to pursue you for license fees. However if your company uses H.264 commercially and starts to make money they would.

It's sort of like if you violate a software patent in your FOSS library you will not be sued. However if someone uses that FOSS library in a device and they start to make money the patent holder may well come after you.

A good example would be Linux. Linux implements things like FAT32 long filenames which are most likely patented. You don't get sued as an individual user. However suppose TomTom make millions selling GPS devices in the US. Then there is a fair chance they helpful folks at Microsoft may sue you and demand you sign a license. At that point you can pony up the cash or counter sue them

E.g.

http://en.wikipedia.org/wiki/Microsoft_Corp._v._TomTom_Inc.

Note there actually is a lot wrong with this system. It gives old, large companies with an extensive patent portfolio an advantage over new, small ones with a smaller portfolio for example and that seems to me to be the opposite of what the law should do in the interests of competition. Many software patents are of dubious originality. Even companies like Google and Microsoft have fallen victim to dubious patents. In fact the reason they build up patent portfolios is primarily defensive - it means that if they are sued for patent violation they most likely have a patent which the company suing them is violating too.

Still the idea that people will be sued because they encode or decode videos using FFMPEG is bogus. As is the idea that putting a H.264 video on the internet will mean you need to pay a license fee. In practice only people who are making enough profit to make them a target get sued for patent infringement. Or that the Linux Foundation of people like Canonical will be sued for infringing patents. Canonical declined to discuss patents with Microsoft but they did license the MPEG LA patents. They also joined the PCI SIG. So it seems like industry standards with a patent pool are something they accept. Microsoft trying to collect royalties on their patents unilaterally they won't. There's a certain amount of sense in this position.

Incidentally once you understand how the system works you can see why FFMPEG or other open source products don't get granted 'unlimited no cost license'. Not to distribute - they can already do that for free. What they can't do is to offer a free license to their end users to decode or encode H.264. If they could do that people would just use FFMPEG in their products and not pay the license fee to the MPEG LA.

Of course another point people miss is about video is that 'not patent encumbered' is a rather dishonest phrase. With something like WebM all you can say is that they are not currently known to use any technology, rather than they ar

For all their ardous work!

FFMpeg donations page is here:
http://ffmpeg.org/donations.html

I really wonder how many software and hardware vendors which rely on it hit that donation button. Half of media apps I use and paid for has ffmpeg embedded.
Could be none.

For all their ardous work!

FFMpeg donations page is here:
http://ffmpeg.org/donations.html

http://ffmpeg.org/download.html#releases

It's libdvdcss, not libdvdcs. And the CSS (content scramble system) is only one part of the puzzle; non-encrypted DVDs will still require a MPEG-2 codec, which is also patent-encumbered and has royalty fees associated with it.

So the answer to GP's questions should really be "no", and "sometimes". VLC does not pay licensing fees; libdvdcss appears to bypass the licensing fees, but FFmpeg does not. From the ffmpeg.org legal readme:

Q: Does FFmpeg use patented algorithms?
A: We do not know ... various standards FFmpeg supports contain vague hints that any conforming implementation might be subject to some patent rights in some jurisdictions ...
Q: Is it safe to use such patented algorithms?
A: Patent laws vary wildly between jurisdictions ... whether you are safe or not depends on where you live ...
Q: Is it perfectly alright to incorporate the whole FFmpeg core into my own commercial product?
A: You might have a problem here. There have been cases where companies have used FFmpeg in their products. These companies found out that once you start trying to make money from patented technologies, the owners of the patents will come after their licensing fees. Notably, MPEG LA is vigilant and diligent about collecting for MPEG-related technologies.

The FFmpeg team has some ideas about this.

I see they are currently updating the page - they do that a lot.

What I am unclear on is whether they are just noisy whiners, or if they ever actually put the legal teeth to any of their targets?

Tell that to x264 and FFmpeg.

They aren't located in a place where software patents are valid.

Tell that to x264 and FFmpeg.

I did. They said something about being based in France...

Tell that to x264 and FFmpeg.

> RealAudio with the single exception of the SIPR codec.

Uh, what? You seem to be about 2-3 years behind the times:
http://ffmpeg.org/doxygen/0.6/sipr_8c-source.html

He also started ffmpeg.

"And when's the last time you edited photos, video, or audio with a CLI?"

For images, that's what Imagemagick or netpbm are for, and I use them all the time. I've also used ffmpeg for video, although not as frequently. If I had to use a GUI for the same tasks (hundreds of images), I'd probably give up in frustration. For batch operations there's nothing better than a CLI.

As others have noted there is a place for both CLI and GUI operations. It is disappointing to see how many people think a GUI is the be-all and end-all of computing. I wouldn't want to use a system if a CLI wasn't available in some form as an option because for some tasks it is the best choice. Hmmm.... although if I was forced to use MS-DOS as the only CLI option ("C:\ prompt") I could see people's point. It's truly awful, and I don't touch it on Windows. I install Cygwin. Anyone who has only experienced MS-DOS as their CLI experience doesn't really know what's possible.

Bah. Buy ALAC (iTunes plus) right now and convert it to anything you like with FFmpeg. That gets me lossless legit music that I can do anything I want with.

How ironic, Slashdot's CAPTCHA just offered to feed me an mp3 of the word I am to type.

That seems to be a great way to get folks to avoid GPLed software like the plague. Here's another. The guy is cooperative and asks for clarification on what exactly the developers want done for compliance. What does he get? A whole lot of shit in return.

Here's the bug:
https://roundup.ffmpeg.org/issue1162

The MediaCoder author is asking what he violated and the FFmpeg dev is just telling him to RTFL (license), all of it. The FFmpeg dev is being a jerk, too, and calling him names. The MediaCoder author even mentioned that he asked on the mailing list before distributing and got told that him usage was fine.

MediaCoder might be violating the license, but it looks like an honest mistake that the author wants to rectify. The FFmpeg dev would rather call him names than show him what he did wrong.

It should be mentioned that MediaCoder is in the ffmpeg hall of shame: http://www.ffmpeg.org/shame.html (I cannot link any more direct because ffmpeg's bug tracker uses a self signed cert)

Judging from the related bug tracker the author appears to almost be playing dumb.
I agree that it is a fine program and I myself have suggested it to non-tech savy friends, but that doesn't mean I feel good about doing so.

As you're making an issue of this - I decided to dig. I found references to ffmpeg in the main executable, and only in the main executable. Is MyVideoConverter in compliance with the license found here -> http://www.ffmpeg.org/legal.html ?

Open Source should have no problems coming up with better alternatives. In this case, it seems there's a problem (hint !)

In fact you're wrong. I can play H264 on my Ubuntu jaunty box just fine. This is simply about licensing the codec for OEM legal use. Ubuntu has never had problems actually playing the video for a long time.

when a better, open alternative to H.264 comes along, make the switch.

You mean like the one that has been in Ubuntu for years?

No I mean free. See for example FFmpeg, which is LGPL licensed while implementing a variety of patented codecs - their FAQ is interesting. Some people disagree with them, but it's interesting that Google are an MPEG-LA licensee AND distribute FFmpeg with Chromium/Chrome.

Note that patents need not be universally valid. E.g. a specific patent may be recognised only in limited jurisdictions, or software patents may not be recognised generally in some. The GPLv2 specifically allows for free software that is covered by patents to still be distributed, see clause 8.

The GPLv3 is even more specific in that it seems to require only the onward transmission of any relevant patent licence rights that the distributor/contributor holds - that is it requires any rights that are held to be passed on, it does NOT require that a free software work be free of patent claims. See clause 11.

I personally don't know exactly what the legalities tbh, particularly not for the case where the creator and distributor of the code never held a patent licence. Both versions of the GPL seem to be drafted with the case of patent owners/licensees in mind, and it's not obvious what they say about the non-licensee case.

I presume however that Googles' lawyers do know though. So it does not seem to me that patent issues automatically mean software can not be considered free.

Here we go - someone who doesn't understand the difference between an open standard and a free/libre standard. For example wrt ffmpeg and patent infringement

=====

Patent Mini-FAQ

A lot of legal questions surrounding patents arise when discussing multimedia technology. This mini-FAQ attempts to address these issues. Note that much of this discussion is based on precedent, or what has happened in the past under similar circumstances. Very little consideration is given to what could happen. If you use your imagination, you can visualize any dire scenario and cease doing any productive work.

Q: Does FFmpeg use patented algorithms?
A: We do not know, we are not lawyers so we are not qualified to answer this. Also we have never read patents to implement any part of FFmpeg, so even if we were qualified we could not answer it as we do not know what is patented. Furthermore the sheer number of software patents makes it impossible to read them all so no one (lawyer or not) could answer such a question with a definite no, those who do lie. What we do know is that various standards FFmpeg supports contain vague hints that any conforming implementation might be subject to some patent rights in some jurisdictions, examples for such statements are:

For H.264:

ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process.

And for MPEG-4:

The user's attention is called to the possibility that, for some of the processes specified in this part of ISO/IEC 14496, conformance with this specification may require use of an invention covered by patent rights. By publication of this part of ISO/IEC 14496, no position is taken with respect to the validity of this claim or of any patent rights in connection therewith.

Q: Is it safe to use such patented algorithms?
A: Patent laws vary wildly between jurisdictions, and in many countries patents on algorithms are not recognized. Plus the use of patents to prevent the usage of a format or codec on a specific operating system or together with specific other software might violate antitrust laws. So whether you are safe or not depends on where you live and how judges interpret the law in your jurisdiction.

Q: Bottom line: Should I be worried about patent issues if I use FFmpeg?
A: Are you a private user working with FFmpeg for your own personal purposes? If so, there is remarkably little reason to be concerned. Are you using FFmpeg in a commercial software product? Read on to the next question...

Q: Is it perfectly alright to incorporate the whole FFmpeg core into my own commercial product?
A: You might have a problem here. There have been cases where companies have used FFmpeg in their products. These companies found out that once you start trying to make money from patented technologies, the owners of the patents will come after their licensing fees. Notably, MPEG LA is vigilant and diligent about collecting for MPEG-related technologies.

===== UTI are the people who actually develop the spec, the ITU-T Video Coding Experts Group .

Bottom line - if you want to implement h.264, be prepared to pay. But don't take anyone's word for it ... go ask them yourself. Ask if they (Apple, etc.) will give you permission to make a free version of an h.264 decoder that you can distribute for free around the world without paying a license fee. Tell them why YOU should be the first exception (x264 doesn't have theoir permission).

The only thing that end-users don't need a license for is to watch streaming video on the Internet (until 2015) - but the producers/streamers still need a license.

Assuming you are talking about the MP3 plugin it is free (as in beer) and the source code is available under the MIT license, which is GPL compatible. A similar approach could be used for H.264 and AAC decoders in Mozilla and Opera.

Open source implementations, for instance using the GPL, of H.264 and other codecs aren't illegal or disallowed as many people seem to think. In fact they are readily available and used by different companies who pay the licensing fees (if applicable). For instance Google distributes the FFMpeg H.264 decoder (GPL) with Chrome and has recently started using x264 (GPL) for their video encoding on Youtube. AFAIK they pay licensing fees for Chrome, but not for their Youtube use since the don't use more than 100.000 encoders.

good Free implementations of h264 exist

If you're referring to ffmpeg, it's infringing on several patents held by MPEG-LA

whether you are safe or not depends on where you live and how judges interpret the law in your jurisdiction.

Theora? Don't hold your breath. Apple, (one of the members of the MPEG-LA patent pool) won't use it no matter what.

That may be correct in a technical point of view and a very simple solution to this problem. Unfortunately, the world is a bit more complex than that, thanks for the mess of convoluted rules which each jurisdiction imposes on it's citizens. In this case, if you take a look at ffmpeg's patents min-FAQ" you will notice the following disclaimers:

Q: Does FFmpeg use patented algorithms?
A: We do not know, we are not lawyers so we are not qualified to answer this. Also we have never read patents to implement any part of FFmpeg, so even if we were qualified we could not answer it as we do not know what is patented. Furthermore the sheer number of software patents makes it impossible to read them all so no one (lawyer or not) could answer such a question with a definite no, those who do lie. What we do know is that various standards FFmpeg supports contain vague hints that any conforming implementation might be subject to some patent rights in some jurisdictions, examples for such statements are:
For H.264:

        ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process.

Q: Is it safe to use such patented algorithms?
A: Patent laws vary wildly between jurisdictions, and in many countries patents on algorithms are not recognized. Plus the use of patents to prevent the usage of a format or codec on a specific operating system or together with specific other software might violate antitrust laws. So whether you are safe or not depends on where you live and how judges interpret the law in your jurisdiction.

So, although ffmpeg supports H.264 and other patent-encumbered formats, it does so in spite of the patents that affect the implementations. As a consequence, they make it clear that if you rely on ffmpeg then you are at your own risk. And needlessly putting yourself at risk is never a good thing.

Mozlla's concerns don't seem related at all to the implementation of the video. Rather, they're concerned about the licensing issues related to their usage of it. According to the article (and the summary, at that), the only reason H264 is even legally embeddable in current software is due to a free-to-viewer clause, and even that may permanently expire in 2010.

Currently, most of the web (Flash excluded) is free to generate. I can make an HTML document, or a tool to generate HTML documents, and render those HTML documents without paying or owing anybody anything. To legally generate H264 files, you must pay for a license. To build software that generates H264 files, the software company must pay for a license. And (possibly) after 2010, a viewer or viewer software may have to pay for a license to watch the content. These are some pretty huge issues to overcome.

Just throw a DirectShow interface at the video player and quit shipping codecs.

How do you propose they do that on OS X or Linux?

The general idea is a good one, but FFmpeg is probably a more generaly useful approach.

As far as anyone is concerned h264 is an open free video standard. There's open free code for the encoder here and for the decoder here. Don't expectr a few misguided managers who think patents count for shit to change that.

Since the LGPLed FFmpeg library supports H.264 among other codecs, all they need to do is support it as a plugin. They can ship Firefox with a version compiled without "--enable-gpl" and without "--enable-nonfree".

Here's a link to the LGPL source file (well, presumably the main file implementing the support, I haven't studied the structure closely, and there are about a dozen files in the directory with h264 in the name):

http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/h264.c

http://bellard.org/
He's also the guy who launched ffmpeg and is working on Qemu, among other things...

For those not previously familiar with Fabrice Bellard, he's known for:

• LZEXE, very popular in the early 1990s as the first EXE-shrinker for DOS, or at least the first widely available one
• ffmpeg, video decoding library which he started and headed for a number of years
• QEMU, dynamic-translating generic emulator

Do you honestly think a half dozen audio codecs, and another half dozen video codecs would make for a "small" DLL?

libavcodec currently has decoders for 242 audio and video codecs, encoders for 100, demuxers for 129 container formats and muxers for 89.
The resulting DLL is about 7 MB.

1. They're getting a good patent portfolio that they can use to defend their investment in YouTube with. They're fairly heavily invested in using ffmpeg which may have patent issues.
2. They're getting some very smart people and a user base that they can use to help steer the direction of video they way they want it to go.
3. VP7's being used for video chat by Skype and AIM - they might find it useful for their expanding telecommunications offerings.