[x265] Next steps on my road map

Tom Vaughan tom.vaughan at multicorewareinc.com
Thu Apr 9 08:20:30 CEST 2015


Hi Xinyue,
We definitely appreciate your contributions, and we understand your
ambition to build x265 into an application that can do much more.

Our philosophy from the start of the x265 project has been to keep x265
laser-focused on HEVC encoding only.  x265 is a foundation library, not an
application (the only application is the command-line interface, and that
is deliberately minimal).  x265 only handles uncompressed video as input,
and it only produces HEVC bitstreams as output.  We realize that to be
practical, everyone needs more than just uncompressed video input and raw
bitstream output.  But we regard input file parsing, demuxing and
decoding, and output muxing and file writing as application layer
functions.  There are many applications with these features that have
already adopted x265 (FFMPEG, Handbrake, VLC, etc.).  If you want to
create another GPL video encoder application using x265, you're certainly
free to do that.

Yes, there are license concerns.  But my biggest concern is that adding
these types of features to x265 dilutes focus on the core mission -
producing the best HEVC encoder.  It also permanently adds complexity to
the code base, and it adds a support burden for these features.

I haven't had a chance to discuss with Steve, who already responded to
this topic.  We'll have to see how we can best support your efforts to
create a more powerful HEVC encoder application.

Thanks,
Tom

-----Original Message-----
From: x265-devel [mailto:x265-devel-bounces at videolan.org] On Behalf Of
Xinyue Lu
Sent: Wednesday, April 8, 2015 7:45 PM
To: Development for x265
Subject: [x265] Next steps on my road map

Hi,

Here are some patches that are applied in my personal mod, and I'd like to
know which of them do you have interests so that I can clean up and submit
to official repo.

1. Logging to file with --log-file <file.log> --log-file-level <LEVEL>.

2. LAVF Input, can take common media files as input directly, e.g. MKV or
MP4 files.
Potentially add --demuxer <demuxer> option to manually pick a demuxer.
Potentially replace --y4m, remove bForceY4m.

The original authors of this patch is Mike Gurlitz
<mike.gurlitz at gmail.com> and Steven Walters <kemuri9 at gmail.com>.

LAVF Library is LGPL/GPL/nonfree.

3. Matroska Muxer

The original author is Mike Matsnev <mike at haali.su>.

4. L-Smash MP4 Muxer

The original authors are:
Laurent Aimar <fenrir at via.ecp.fr>
Loren Merritt <lorenm at u.washington.edu>
Yusuke Nakamura <muken.the.vfrmaniac at gmail.com> Takashi Hirata
<silverfilain at gmail.com>
golgol7777 <golgol7777 at gmail.com>

And liblsmash is GPL.

- - -

Apart from your interests, the license problem is also what I'm concerning
about.

x265 can be licensed under commercial license. Can we still port the patch
/ function from x264? Do you have an agreement that you can use x264 code
base / patches without licensing problem?

When linking against lsmash (or maybe libav) should I place an option like
ENABLE_GPL inside CMakeList?

Should these demuxers / muxers be enabled by default during compiling?

Thanks
_______________________________________________
x265-devel mailing list
x265-devel at videolan.org
https://mailman.videolan.org/listinfo/x265-devel


More information about the x265-devel mailing list