Cisco open sources it's h264 codec, allows mozilla to use it for FREE.

[hajj_3]

http://blogs.cisco.com/collaboration/open-source-h-264-removes-barriers-webrtc
https://blog.mozilla.org/blog/2013/10/30/video-interoperability-on-the-web-gets-a-boost-from-ciscos-h-264-codec/

It looks as though h264 will be used in WebRTC as well as VP8 now :)

Source code: http://www.openh264.org/

[mandarinka]

Well, VP8 wasn't standardised for that use (as a mandatory codec) - webrtc is just a draft after all. It's just that browser vendors ship drafts to have "the latest" or to push their codec (Google).

[hajj_3]

webrtc is supposed to be finalised next week. It may allow vp8 and h264, i guess we have to wait and see.

[mandarinka]

It will basically allow everything you want to implement. The conflict lies in specifying a specific codec that every implementation must implement (for guaranteed cross-compatibility). This so called "MTI" (mandatory to implement) could in theory be both VP8 and H.264, but that makes no sense - only one MTI is needed, and both candidates have people being opposed. The likely outcomes are probably only one MTI codec or no MTI codec.

[Przemek_Sperling]

As far as I read the core would be opensourced but the modules would be not. They would be downloadable only as binaries only from Cisco servers. Is it a new definition of being open sourced? Sorry, do not buy it, I want access to the source of everything, not a part only.

[nevcairiel]

Its a patent thing. The whole source will be available, however to be able to transfer the patent rights, Firefox has to download a binary from Cisco, which was build from the available open-source code.
At least thats how i understand it. No source is being hidden, its just for the patents.

[edzieba]

As I understand it, the source is available under the BSD license, and you can build it, modify it, etc in accordance with that software license. BUT: only the binary built by Cisco from that source is covered under the MPEG-LA patent license agreement. If you take the exact same source and build it yourself, you have no license and the MPEG-LA can send you mean letters.

It at least means that you can compare the Cisco blob with a fresh build from the provided source and be able to tell if Cisco are doing anything fishy, but there's no way to transfer the license conferred by the blob to any other encoder.

[koliva]

Is it only for Mozilla? Can anybody check-out the binaries and use them in their products?

[hajj_3]

Is it only for Mozilla? Can anybody check-out the binaries and use them in their products?

anyone can :)

[koliva]

anyone can :)

Wow, they have balls then.
How do they call their codec then?

[nm]

One issue with their offering is that the code currently only supports Baseline profile and they are basically asking for the community to participate in building usable decoder and encoder components. That might take a while.

http://www.openh264.org/faq.html

Q. Which profiles of H.264 will be supported?
A: The initial code has the baseline profile. We look forward to working with the open source community to add high profile and others.

[Kurtnoise]

The sources code have been released (https://github.com/cisco/openh264)...

OpenH264 is a codec library which supports H.264 encoding and decoding. It is suitable for use in real time applications such as WebRTC. See http://www.openh264.org/ for more details.


Encoder Features
Constrained Baseline Profile up to Level 5.2 (4096x2304)
Arbitrary resolution, not constrained to multiples of 16x16
Rate control with adaptive quantization, or constant quantization
Slice options: 1 slice per frame, N slices per frame, N macroblocks per slice, or N bytes per slice
Multiple threads automatically used for multiple slices
Temporal scalability up to 4 layers in a dyadic hierarchy
Spatial simulcast up to 4 resolutions from a single input
Long Term Reference (LTR) frames
Memory Management Control Operation (MMCO)
Reference picture list modification
Single reference frame for inter prediction
Multiple reference frames when using LTR and/or 3-4 temporal layers
Periodic and on-demand Instantaneous Decoder Refresh (IDR) frame insertion
Dynamic changes to bit rate, frame rate, and resolution
Annex B byte stream output
YUV 4:2:0 planar input


Decoder Features
Constrained Baseline Profile up to Level 5.2 (4096x2304)
Arbitrary resolution, not constrained to multiples of 16x16
Single thread for all slices
Long Term Reference (LTR) frames
Memory Management Control Operation (MMCO)
Reference picture list modification
Multiple reference frames when specified in Sequence Parameter Set (SPS)
Annex B byte stream input
YUV 4:2:0 planar output

[LoRd_MuldeR]

The sources code have been released (https://github.com/cisco/openh264)...

FWIW, here are some Win32 builds:
http://www.mediafire.com/download/v2k4v3z5c0r4c8l/openh264.2013-12-09.rar

[Nozdrum]

FWIW, here are some Win32 builds:
http://www.mediafire.com/download/v2k4v3z5c0r4c8l/openh264.2013-12-09.rar

Did anyone try it? any command that I tried to use didn't work, I think there's something wrong with the files, only 2 mbyte probably they forgot to add something.
The console says:

Wels SVC Encoder Usage:

Syntax: welsenc.exe welsenc.cfg
Syntax: welsenc.exe welsenc.cfg [options]

But there's no welsenc.exe there :confused:

[LoRd_MuldeR]

I think encConsole.exe and decConsole.exe are the CLI front-ends for welsenc.dll and welsdec.dll, respectively.

Anyway, my attempts to use the decoder didn't work either:
D:\Sandbox\CiscoH264>decConsole.exe sample.264 output.yuv
load library sw function successfully
H264 source file name: sample.264..
Sequence output file name: output.yuv..
------------------------------------------------------
-------------------------------------------------------
iWidth: 0
height: 0
Frames: 0
decode time: 3.741623 sec
FPS: 0.000000 fps
-------------------------------------------------------

D:\Sandbox\CiscoH264>

Just gives me an empty "output.yuv" file...

[Nozdrum]

I think encConsole.exe and decConsole.exe are the CLI front-ends for welsenc.dll and welsdec.dll, respectively.

Anyway, my attempts to use the decoder didn't work either:
D:\Sandbox\CiscoH264>decConsole.exe sample.264 output.yuv
load library sw function successfully
H264 source file name: sample.264..
Sequence output file name: output.yuv..
------------------------------------------------------
-------------------------------------------------------
iWidth: 0
height: 0
Frames: 0
decode time: 3.741623 sec
FPS: 0.000000 fps
-------------------------------------------------------

D:\Sandbox\CiscoH264>

Just gives me an empty "output.yuv" file...

oh that works!! (only for decConsole.exe) thanks, at least the commands respond :)

[Nozdrum]

This is the full list of commands from encConsole.exe:
>encConsole.exe

Wels SVC Encoder Usage:

Syntax: welsenc.exe -h
Syntax: welsenc.exe welsenc.cfg
Syntax: welsenc.exe welsenc.cfg [options]

Supported Options:
-bf Bit Stream File
-frms Number of total frames to be encoded
-gop GOPSize - GOP size (2,4,8,16,32,64, default: 1)
-iper Intra period (default: -1) : must be a power of 2 of GOP size (or -1)
-spsid Enable id adding in SPS/PPS per IDR
-denois Control denoising (default: 0)
-scene Control scene change detection (default: 0)
-bgd Control background detection (default: 0)
-aq Control adaptive quantization (default: 0)
-ltr Control long term reference (default: 0)
-rc Control rate control: 0-disable; 1-enable
-tarb Overall target bitrate
-numl Number Of Layers: Must exist with layer_cfg file and the number of input layer_cfg file must equal to the value set by this command
The options below are layer-based: (need to be set with layer id)
-org (Layer) (original file); example: -org 0 src.yuv
-drec (Layer) (reconstruction file); Setting the reconstruction file, this will only functioning when dumping reconstruction is enabled
-sw (Layer) (source width)
-sh (Layer) (source height)
-frin (Layer) (input frame rate)
-frout (Layer) (output frame rate)
-lqp (Layer) (base quality layer qp : must work with -ldeltaqp or -lqparr)
-ltarb (Layer) (spatial layer target bitrate)
-slcmd (Layer) (spatial layer slice mode): pls refer to layerX.cfg for details ( -slcnum: set target slice num; -slcsize: set target slice size constraint )

>pause

I finally managed to get something out of it, using this command line:
encConsole.exe welsenc.dll output.h264

The console reported this:
WELS CPU features/capacities (0x4000723f) detected:
HTT: Y, MMX: Y, MMXEX: Y, SSE: Y, SSE2: Y, SSE3: Y, SSSE3: Y, SSE4.1: Y, SSE4.2: N, AVX: N, FMA: N, X87-FPU: Y, 3DNOW: N, 3DNOWEX: N, ALTIVEC: N, CMOV: Y, MOVBE: N, AES: N, NUMBER OF LOGIC PROCESSORS ON CHIP: 2, CPU CACHE LINE SIZE (BYTES): 64
Frames: 1
encode time: 0.075078 sec
FPS: 13.319481 fps

This is the output file (300 KB):
http://i.imgur.com/f53D7P9.png (http://i.imgur.com/f53D7P9.png)

Media info:
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Scalable Baseline@L3.1 / Scalable Baseline@L3.0 / Scalable Baseline@L1.2 / Baseline@L1.0
MultiView_Count : 1 / 1 / 1
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 40ms
Width : 160 pixels
Height : 90 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Default : Yes
Forced : No

I've no idea where that file came from, since I didn't find any way to give an input file, probably need to try some random command.

Also while it was being muxed, MKV Merge reported this:

Warning: 'output.h264' track 0: This AVC/h.264 track's timing information indicates that it uses a variable frame rate. However, no default duration nor an external timecode file has been provided for it, nor does the source container provide timecodes. The resulting timecodes may not be useful.

[foxyshadis]

Looks like you encoded welsenc.dll as if it was a raw video file, using some default setting assumptions. Looks like the command-line will assume the first argument is a raw video if you don't specify a config file.

You can define the input in the config file, using InputFile, SourceWidth, and SourceHeight options, or with the command-line options -org -sw -sh. For instance: -org 0 myvid.yuv -sw 0 320 -sh 240. The 0 is required (you can have more layers, too; this defaults to AVC Baseline, and includes Extended & Scalability extensions). Only raw video is supported. You can look at the JM reference encoder to see how config files work, it looks like they just copied the format, or look in /testbin at the combination of welsenc.cfg and layer2.cfg.

This codec is a piece of crap mostly based on the JM reference software, only remotely interesting because Cisco is willing to pay for the royalties. It's most likely going to be much too slow and crappy quality to gain any traction as a built-in Firefox tool, unless the devs are allowed to scrap and rewrite it. At least it has some asm functions. There's no reason Cisco couldn't have offered to pay the royalties to use x264 and FFMpeg instead.

[mandarinka]

Those are not BSD licensed, which is important to many people. /I guess it's not a coincidence that Xiph software as well as libvpx are BSD-licensed too... probably for the same reasons that Cisco thinks GPL/LGPL stuff is not enough/.

[iwod]

But Theoretically speaking, could another company just Paid 5 Million and allow anyone to use x264? Would GPL / LGPL still matters?

[nevcairiel]

But Theoretically speaking, could another company just Paid 5 Million and allow anyone to use x264? Would GPL / LGPL still matters?

Of course license matters. x264 is GPL, and therefor really hard to use in a commercial environment, unless you pay for the commercial x264 license.

The only thing Cisco did was pay the patent fees for users of their (binary) decoder. It has nothing to do with the license.
It protects the users of this binary decoder from being sued by the MPEG-LA on patent infringement, however if you used x264, they could still sue you for violating their license terms, if you don't obey them. This is why the Cisco decoder is BSD licensed. Their license is so liberal that you can do pretty much anything.

[LoRd_MuldeR]

Of course license matters. x264 is GPL, and therefor really hard to use in a commercial environment, unless you pay for the commercial x264 license.

Well, as for Mozilla/Firefox, their software is released under the MPL (Mozilla Public License), which is a GPL-compatible license. Consequently mixing MPL'd and GPL'd code is fine, i.e. x264 could be incorporated into Firefox license-wise. It's the patent royalties that are the problem here. So Cisco could as well have decided to pay the patent royalties for everybody who which to include x264 into their software, instead of doing the same thing for their own H.264 encoder. Except, maybe, that the demand (and thus the overall patent royalties they have to pay) would have been much higher, if they had offered a really good H.264 encoder ;)

Anyway, for a web-browser, a H.264 decoder is much more important than an encoder, I think. So if this brings reliable H.264 playback support to Firefox (i.e. without having to rely on system codecs) this is still a good thing.

[nevcairiel]

So if this brings reliable H.264 playback support to Firefox (i.e. without having to rely on system codecs) this is still a good thing.

Reliable? Hardly, at least not today.
The decoder is way too limited in features, most of the H264 content in the world it probably can't even decode because its unsupported profiles.

[LoRd_MuldeR]

Well, even if they only do "Baseline" Profile (for now), I think it's still better to have built-in support for H.264 "Baseline" Profile rather than having whatever the user's system Codec happens to support or maybe no H.264 support at all.

For web-designers it's already more than annoying to get their stuff working on all major web-browser. Having to use browser-switches is ugly. But as soon as the browser's capabilities may vary by system-specific Codecs, it's getting horrible. So guaranteed H.264 "Baseline" profile on all major browsers would certainly make things easier. And, AFAIK, the two other major browsers, IE and Chrome, already do support H.264 for quite a while.

[Selur]

Anyone managed to compile the openH264 console application? (got added to the git repository 3days ago)

[LoRd_MuldeR]

Anyone managed to compile the openH264 console application? (got added to the git repository 3days ago)

Here we go:
http://www.mediafire.com/download/g0h2bx893ucml3r/openh264.encConsole.2014-01-08.rar

[Caroliano]

What guarantees that they will continue compiling new improved versions after WebRTC standard is defined? Will they compile for other architectures and OS? I don't like this.

Patents are incompatible with truly open standards, especially in software where the licensing costs are literally INFINITELY more costly than a copy of the software itself. We need some patent reforms...

[xooyoozoo]

One of the developers for this was on HN a month back (https://news.ycombinator.com/item?id=6902810) and wrote about simply using x264 as a base for the distributed binary:

If the x264 people think they can give x264 to Cisco under a license that we can compile it and distribute the binaries with no changes to our MPEG LA licensing agreements, tell them to get talk of me (fluffy@cisco.com) if they want to do this. I came to the conclusion Cisco could not do this without x264 giving us an appropriate license.

Don't know if this was ever pursued as a possibility and was simply shot down by Cisco management and/or x264 folks, but it seems reasonable and doable to hash out a deal on a CBP-limited x264 binary.

[LoRd_MuldeR]

In what way is the GPL not a suitable license? It explicitly does allow redistribution of binaries, even for commercial purposes.

Yes, the GPL does require to also provide the complete sources along with the binary. But that shouldn't be a problem here, as long as they just distribute binaries of libx264.

[iwod]

a Cisco based x264 would be awesome. I dont understand why it couldn't be done either.

Edit: I guess something to do with this?
http://x264licensing.com/

[LoRd_MuldeR]

Edit: I guess something to do with this?
http://x264licensing.com/

That site is for licensing x264 under a different license than the GPL - e.g. if some company would like to integrate x264 into their application, but cannot do this under the GPL, because their application is ClosedSource.

At the same time, the Cisco deal is all about taking over the patent royalties for binary distributions of the H.264 encoder/decoder. To my understanding, there should be nothing that is blocking them from taking over the patent royalties for binary distributions of x264 rather than doing the exactly same thing with their own H.264 encoder - except that there would be a much greater demand for x264 ;)

Since they would be distributing only x264 or libx264 (not some application using libx264), there is no problem with respect to the GPL at all. The GPL explicitly allows redistribution! Sure, such GPL'd x264 binary/library could only be used in GPL-compatible applications then. But Firefox is released under the MPL (Mozilla Public License) license, which is a GPL-compatible license. So no problem here either, as far as Firefox is concerned.

MPL version 2.0 is compatible with both the Apache License and by default "the GNU GPL version 2.0, the GNU LGPL version 2.1, the GNU AGPL version 3.0, and all later versions of those licenses"

And even if they only want to distribute a Baseline-restricted version of x264, they could simply make a patch with the required restrictions. As long as the modified code (or the patch) is published, there's no problem with respect to the GPL.

[smok3]

Firefox provided with <video> tag and url to mp4 files, saying that type is mp4 still doesn't burp anything usefull, no video, no error, so basically you are up to the js tricks on the most basic level of providing video, now pick one;
a. firefox, please go away
b. html5 video is flawed
(Yeah i know its about codecs, but i seriously don't care..., I mean it's 2014 man)

I'd doubt that any amount of cisco "magic" could improve that.

[Kurtnoise]

For those who are interested, I've made some fresh windows builds today :

-> x86 platform (http://www.mediafire.com/download/iskkifey030skeq/openh264_x86_20140623.7z)
-> x64 platform (http://www.mediafire.com/download/y3k1ckchs811sls/openh264_x64_20140623.7z)

[Kurtnoise]

This codec is available through FF 33 now (http://www.ghacks.net/2014/07/18/firefox-openh264-gecko-media-plugins-current-state-development/)...

[iwod]

Looks like OpenH264 still isn't getting Mainline Profile Support.
Having the current OpenH.264 within Firefox is completely useless. At least it cant play most if not all of the Youtube MP4 video.

What happen to the x264 and Cisco deal? Does anyone know?

[pcordes]

Sorry for the necro, came across this thread long after it was posted. Looks like openh264 is still just a license hack, not something anyone would ever want to use, given any other option.


Since they would be distributing only x264 or libx264 (not some application using libx264), there is no problem with respect to the GPL at all.

This is true, but doesn't solve the problem Cisco is trying to solve. x264 is GPLed, not LGPLed, so only GPL-compatible code can legally use the library. Cisco could distribute a patent-licence-paid libx264, but no closed source software could use it without violating copyright law. There are some major open source projects with GPL-incompatible licenses, too.

Distributing a GPLed libx264 alongside their openh264 would probably cost them twice the royalties, or else someone would have thought of this loophole already, right?


The license that http://x264licensing.com/ sells is still somewhat restrictive. e.g. You have to contribute your changes (http://x264licensing.com/content/are-you-required-provide-source-code-changes-back-x264-llc) back to the x264 project. And if Cisco paid a distribution license for anyone anywhere to use unmodified x264 binaries in closed-source apps, there goes most of the x264 licensing revenue. So they'd have to charge Cisco a lot, or take the hit to help Cisco make the internet better. But yes, the x264 copyright holders could make this happen.

IDK who makes the licensing decisions for x264, but if it's anyone that cares about video quality on the Internet, they'd give Cisco a decent price to let them make x264 available for use in everything.

I *hate* crappy video that could look better at the same filesize, but doesn't because people suck. (bad encoders, bad settings, etc.)


x264 doesn't include a decoder, but libavcodec is lgpled. There are no copyright problems distributing a compiled binary of it, for use with anything. (there's a compile option to exclude GPL and non-free stuff, so you get a LGPL binary.)

Cisco could do that right now, and have a presumably-still-bad baseline-only encoder, but a state-of-the-art multithreaded decoder from ffmpeg. Their current library is BSD-licensed, but you only get patent-royalty coverage if you use their binary blob, so it might as well be LGPLed, because that's the part that makes it interesting.