f265 0.1 release - a free HEVC Encoder

[Kurtnoise]

f265 (http://www.f265.org/) is an open source HEVC/H.265 encoder
released under the BSD license.

It's cross platform - so, available on Linux, MacOS, Windows.

Not tested yet though...

[Selur]

the dynamically linked windows binary doesn't come with the dll(s?) which are required to use the binary. :/

[fumoffu]

Thanks for info
Can't wait for some tests x265 vs f265, speed, efficiency, quality (especially detail retention...).
It looks like it's in very early stage so I don't expect much but it would be a nice surprise if it turned out to be competitive.

[xkinn123]

does it use similar CLI with x265?
if so, has it support .264 input?

[Selur]

dev branch now has stdin pipe support and they are working on getting static builds working

[kypec]

Just out of curiosity, why are you developing your own HEVC encoder from scratch? Why not join x265 team and offer your programming skills to already well established open-source project?

[easyfab]

x265 is not only open source but according x265.org :

"x265 is also available to commercial companies who wish to distribute x265 without the open-source restictions that the GPL license imposes."

so you have your answer.

[mandarinka]

It's the GPL that might be the issue actually. Open source licenses are not all the same, and the f265 project clearly prefers BSD (which is business-friendly by default, much more so than GPL or even the terms that commercial licenses of x265/x264 offer, I think). Basically, just "being open source too" doesn't mean that much if the license is not favourable.

f265 is a child of a commercial company AFAIK (Vantrix)...

[BadFrame]

"x265 is also available to commercial companies who wish to distribute x265 without the open-source restictions that the GPL license imposes."
Yes, this is the same practice which x264 follows, which is that the project is fully open source and available under GPL, however if you wish to use it in a proprietary project (typically commercial) you can pay the x264 developers for a special licence which allows this.

so you have your answer.
Has it been established that the reason for f265's existance is licencing?

Either way, great to see another open source HEVC implementation.

[MasterNobody]

Sorry, to be badass but BSD-license also have it drawbacks. You don't have any guarantees that this project will be always open source and that by the time of maturity it wouldn't suddenly disappear and become fully commercial project. And so any developer that contribute to this project and accept your CLA mostly give up his rights without any compensation. Some people still remember what happened to OpenDivX project. So yes BSD is good for companies but not for the consumers or small contributors.

[mandarinka]

Yes. Although the last public version of f265 could still be forked into another open source project, a company can likewise make fully proprietary fork and after that cease to contribute into the public/BSD original project.

With the GPL/commercial scheme of x264/x265, proprietary forks are actually forbidden.

BSD license only guarantees that you would be able to use the actual code as licensed now. GPL/copyleft license guarantee that you will be able to use the code as licensed and the future evolutions/changes of it. I would say that yeah, as a small contributor who cares about what happens with your work later, BSD offers less guarantees. With BSD, more people might end up using your stuff (of course, you won't get paid for it), because it can be integrated into all sorts of projects thanks to this "free for all" licensing.

[BadFrame]

That's our main driver for attracting contributors. If you contribute to f265, you reap the results of your efforts,
In exactly what way do you 'reap the results' as opposed to contributing towards x265 ?


you keep the copyright on your code
AFAIK you retain copyright of your code even if you submit it under CLA to x265, it's not an exclusive agreement.


and the value of your contribution won't be judged by a company which has a vested financial interest in undervaluing it.
Well in your project there is no value proposition at all when submitting since anyone can pick up the f265 code and use it in proprietary projects without contributing anything back, either in code or money.

As such it seems likely that commercial interests will want to keep their most attractive enhancements to themselves (as competitive advantages) rather than contributing them back.

It will be interesting to see which model contributors end up favouring.

[BadFrame]

You don't have any guarantees that this project will be always open source and that by the time of maturity it wouldn't suddenly disappear and become fully commercial project.
Well the released open source code won't disappear all of a sudden, but it's true that nothing says that code improvements will continue to be contributed back to the open project.

The 'health' of these kind of permissively licenced projects typically depends heavily on the amount of code being contributed, if the enhancements made to the code is contributed back then it will prosper, if the most/best improvements remain in proprietary/commercial forks of f265 then it will likely suffer a slow death.

That said I know nothing of the developer status of f265, it might be that they already have a core team of strong developers devoted to the project.

[easyfab]

Hi Laurent,

More down to earth question, will you only target Haswell CPU and above (AVX2) for asm optimizations or will you do some SSE and AVX optimizations ?

[mandarinka]

If they decide tomorrow to stop offering a GPL version, then you can fork the GPL version but they get to keep their private fork.

The terms of the x264 contributor agreement don't allow that, and x265 uses the same terms AFAIK.

The commercial license doesn't allow proprietary forks. All the changes made by users of the commercial licensed x264/x265 must at the same time be provided into the GPL tree. They don't necessarily get merged, but they are required to be released (under GPL) so that it they could be merged (or used by somebody else).

Also the maintainer can't relicence the existing code AFAIK, besides parts that he (as author) has copyright to. Basically, the whole scheme was designed by the x264 authors to disallow proprietary forks or outright closing of the code.

(BTW, I don't think the possibility of proprietary forks and commercial subjects taking the codebase and extending it as a closed/commercial software is a bad thing. As long as it isn't against the code authors' wish, why not?
Many other open source projects use BSD and similar licenses to actually allow this. Some of those commercial "bad guys" will maybe make an excellent encoder, even if it will be a payware, it can still be a good thing it will exist. Xiph foundation uses permissive licenses for example.)

[mandarinka]

But MCW only has copyright to their own code (edit: and parts inherited from BSD, which have same status as f265's BSD code I guess). They can't relicense code of outside contributors, and more importantly, the sizeable chunk of stuff they have from x264 :D So in practice, they actually can't relicense x265...

/When x264 implemented the commercial licensing option, they had to track all the authors in the code and get permissions, or remove/rewrite affected code. And the permission was given only for the specific terms, which have those anti-closing parts.../

[x265_Project]

But MCW only has copyright to their own code (edit: and parts inherited from BSD, which have same status as f265's BSD code I guess). They can't relicense code of outside contributors, and more importantly, the sizeable chunk of stuff they have from x264 :D So in practice, they actually can't relicense x265...

/When x264 implemented the commercial licensing option, they had to track all the authors in the code and get permissions, or remove/rewrite affected code. And the permission was given only for the specific terms, which have those anti-closing parts.../

Nonsense.

Contributors to x265 must sign our Contributor License Agreement (https://bitbucket.org/multicoreware/x265/downloads/x265ContributorAgreement.pdf).

Similarly, we have a license to port and adapt x264 code for x265 which gives all rights necessary to commercially license x265.

[x265_Project]

AFAIK MCW owns the copyright on the code.
True.
They are not under any obligation to keep offering their code under the GPL.
False. As I've stated before, we made a clear (contractual) commitment to the x264 developers that we would make x265 available under the GPL, and it should be clear to all that we're fulfilling that commitment.

[Selur]

anyone building the development tree?

[Kurtnoise]

I cannot access to the dev branch...so, I cannot compile something. If someone is able to download it, please share.

[Laurent Birtz]

I cannot access to the dev branch...so, I cannot compile something. If someone is able to download it, please share.

Hi, normally the git clone should work over http with a recent enough git version (tested today):
git clone http://f265.org/repos/f265/ -b develop

If that doesn't work for you, please paste the error that you are getting.

[Kurtnoise]

Hi,

I got this :

$ git clone http://f265.org/repos/f265/ -b develop
Cloning into 'f265'...
fatal: http://f265.org/repos/f265/info/refs not valid: is this a git repository?

[Laurent Birtz]

Hi,

I got this :

$ git clone http://f265.org/repos/f265/ -b develop
Cloning into 'f265'...
fatal: http://f265.org/repos/f265/info/refs not valid: is this a git repository?


Weird. I know there were issues with older git versions, and git wouldn't work correctly from msys (I had to use a special environment instead). Perhaps try from a recent Linux system? Sorry for the hassle...

[filler56789]

And I've gotten this:

=>git clone git://f265.org/repos/f265/ -b develop
Cloning into f265...
warning: templates not found F:\APPLICATIONS\CMake/share/git-core/templates
f265.org[0: 207.96.195.176]: errno=No such file or directory
fatal: unable to connect a socket (No such file or directory)
:confused:

[Koti]

ran in cmd.exe
"C:\....\git.exe" --version
cd "C:\....\f265"
"C:\....\git.exe" clone http://f265.org/repos/f265/ -b develop


git version 1.8.4.msysgit.0
Cloning into 'f265'...
Checking connectivity... done

unfortunately I don't have a complete environment to build, but here is a zip of the clone

http://www.mediafire.com/download/6c68qtzby28qs6u/f265.zip

[LigH]

I remember a similar error message trying to clone x265 with git, but its repository is made for hg (Mercurial). There seem to be several git software projects with different features.

[Laurent Birtz]

Git is proving less reliable than I'd like. I will make daily archives available on the f265 server next week, for both the master and the development branches. I'll post when it's ready.

[smok3]

quick test on my home/slow machine, using defaults, i'am getting about 3 frames/minute encoding speed, anybody tested the speed allready? (on some decent machine)

[LigH]

No facts = no sense. Not even the frame dimensions are known, how shall we rate your speed? And details about your CPU would be useful too, the supported instruction set may be relevant.

[Kurtnoise]

Weird. I know there were issues with older git versions, and git wouldn't work correctly from msys (I had to use a special environment instead). Perhaps try from a recent Linux system? Sorry for the hassle...
Cannot access to my Linux box yet...so, let's try with msys first.

With the package provided by Koti, I get this now :
$ scons libav=none
scons: Reading SConscript files ...
Mkdir("build/f265")
scons: done reading SConscript files.
scons: Building targets ...
cp build\f265\f265_config.h.tmp build\f265\f265_config.h
cp build\f265\version.h.tmp build\f265\version.h
gcc /Fobuild\cli\cli.o /c cli\cli.c -g3 -O2 -std=gnu99 -Wall -Wno-write-strings
-Wno-parentheses -Wno-uninitialized -Wno-deprecated-declarations /I. /Icli /Ibui
ld
gcc: error: /Fobuild\cli\cli.o: No such file or directory
gcc: error: /c: No such file or directory
gcc: error: /I.: No such file or directory
gcc: error: /Icli: No such file or directory
gcc: error: /Ibuild: No such file or directory
scons: *** [build\cli\cli.o] Error 1
scons: building terminated because of errors.

[Selur]

I will make daily archives available on the f265 server next week, for both the master and the development branches. I'll post when it's ready.
Nice :)

[xkinn123]

/usr/bin/ld: cannot find -ljack
is there any way to fix this error other than use libav=none?

[Laurent Birtz]

The daily snapshots are now available at http://f265.org/download

[Laurent Birtz]

/usr/bin/ld: cannot find -ljack
is there any way to fix this error other than use libav=none?

I never heard of this error before. It looks like a missing dependency. On Ubuntu/Debian, try apt-get install libjack0

[Selur]

The daily snapshots are now available at http://f265.org/download
Thanks!

[Selur]

Okay, the daily snapshots are source only
-> can someone compile a Windows binary from that source and share it?

[x265.cc]

Okay, the daily snapshots are source only
-> can someone compile a Windows binary from that source and share it?

Latest Development Daily Snapshot with libav.

http://www.xup.to/dl,17953421/f265.7z/


Built with:
GCC 4.9.0
Libav 10.2
Python 2.7.7
NASM 2.11.05
SCons 2.3.1

//edit: Do not trust any (including my) binary files.. blah.. blah..

[xkinn123]

I never heard of this error before. It looks like a missing dependency. On Ubuntu/Debian, try apt-get install libjack0

still get that error...

[Selur]

@x265.cc: thanks!

[Selur]

@Laurent Birtz: I tried:
mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "F:\TESTCL~1\test.avi" | f265cli.exe -v -w 640x352 -c 429 - h:\Output\test.265
with the build x265.cc posted
and I get:
Hardware acceleration: AVX2.


Failed to read a frame from the input file.

I through the dev branch should support input via stdIn for quite some time now. (~two month,.. http://www.f265.org/bugs/ticket/5)

[x265.cc]

I through the dev branch should support input via stdIn for quite some time now. (~two month,.. http://www.f265.org/bugs/ticket/5)

JFYI, without hardware acceleration file input worked for me:

f265cli.exe -v input.mp4 output.h265

[Selur]

"hardware acceleration " <- ??? I was speaking about pipe/stdIn input, which should have nothing to do with hardware acceleration,...

[LigH]

Well, funny, isn't it? Just the opposite of x265, not implementing any input libraries beyond Y4M before the encoder is rather "feature complete", practically requiring pipe support to get frameserved.

On the other hand, "<input>" is too brief to be called "a documentation" of the supported input formats. One example suggests a rich support, having *.mp4 as input file. Compile instructions mention libav as optional component. But what is supported without?

[Kurtnoise]

4:2:0 YUV files as input if it's not compiled with libav...

[x265.cc]

"hardware acceleration " <- ??? I was speaking about pipe/stdIn input, which should have nothing to do with hardware acceleration,...


Sorry, i've meant:

JFYI, file input is working without problems. (My CPU does not support AVX/AVX2)

[LigH]

But how to serve real-time filtered video (e.g. from AviSynth or via ffmpeg pipe after applying ffmpeg internal filters) into f265 without writing an intermediate file?

[Laurent Birtz]

still get that error...

Sorry, I just don't know. Since it's system-specific, I have no way to debug/investigate this.

[Laurent Birtz]

I through the dev branch should support input via stdIn for quite some time now. (~two month,.. http://www.f265.org/bugs/ticket/5)

It should! A simple command works for me (Ubuntu 14.04):


cat RaceHorses_832x480_30.yuv | ./f265cli -w 832x480 - f265.265


The patch for the feature in the client is pretty straightforward.


/* Use standard input. */
if (!strcmp(ifd->path, "-"))
{
ifd->file_handle = stdin;
}


Since you're running from Windows, perhaps it's an issue with stdin being set in text mode instead of binary mode by default.


setmode(fileno(stdin), O_BINARY);


I've filed the bug: http://f265.org/bugs/ticket/22#ticket
I'm going on vacations next week. I asked Daniel to investigate this next week when he has time.

[Laurent Birtz]

But how to serve real-time filtered video (e.g. from AviSynth or via ffmpeg pipe after applying ffmpeg internal filters) into f265 without writing an intermediate file?

Can you clarify your needs?

The client can read YUV from either an intermediate file or from stdin (with the '-' argument). Selur reported a problem with this on Windows, but it's going to be fixed. So normally you can pipe data directly into f265, provided it is YUV.

When libav is compiled in, f265 can read any format supported by libav, provided a file argument is used (using stdin for that is not supported at this time).

Luca Barbato is working to integrate f265 directly in libav, using the library interface.

[x265.cc]

cat RaceHorses_832x480_30.yuv | ./f265cli -w 832x480 - f265.265



This also works on ms windows. (with cat for win32)