[x265] Next steps on my road map

[Xinyue Lu]

Hi Tom (and also Steve),

I first would like to thank you for developing that wonderful tool.

I fully understand that you would like to focus on the core. And
that's why I'm asking beforehand so I will have an idea which patches
need to be submitted to you.
I am looking to make x265 as powerful as x264, i.e. decoding and
encoding videos in one step. I personally use make / rake style
automated scripts to encode videos, thus having these abilities
(including demuxers, muxers, and logging into file) within the command
line interface are more important to me.

I'm absolutely happy to keep these patches in my own repo. I just
wanna make sure if some of the patches are that you are (or will be)
looking for.

- - -

Hi Steve,

Logging into file function, is to log whatever information on the
console into a log file.

For example, the parameters, input, output, and final encoding status
will be copied into a text file.

It's more like a CLI only patch. I was not thinking about callbacks
from the core. The patch meant to be applied on the general_log
function which also fputs the messages into the log file.

- - -

Thanks,
Xinyue

On Wed, Apr 8, 2015 at 11:20 PM, Tom Vaughan
<tom.vaughan at multicorewareinc.com> wrote:
> 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