On Fri, Aug 18, 2017 at 5:23 PM, Vittorio Giovara < [email protected]> wrote:
> Hello, > with the standard expansions and several new options being added, I > would like to propose a "de-facto" standard in option names to > simplify integration and deploying of open source coding tools. > Especially for well known options, such as color properties, there is > little value in offering different names than what other tools already > use, while on the other hand using the same names everywhere will > simplify developers' life, as well as users'. > > Right now x264 and ffmpeg use exactly the same names, as defined in > these tables https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/ > pixdesc.c#L2251-L2306: > API users will see them, ffprobe will print them, x264 will encode > them. Originally they were also designed to being compatible with > x265. > > However since last year new additions, the new options names are > becoming incompatible with that list, and with new options being added > (https://gist.github.com/Adsun701/472ec93957289f057e0c90599ec4bb9a) I > think it's would be beneficial to restore the compatible names and > mandate compatibility with the ffmpeg/x264 list. > I opened a bug/feature request as soon as I noticed > (https://bitbucket.org/multicoreware/x265/issues/348/ > add-aliases-for-smpte-st-2084-and-smpte-st) > but unfortunately it laid dormant for some time. > > Please consider changing the color properties names to the compatible > ones, or add alternative options that can be easily used across > projects. > Thanks for the note. I somehow missed the issue you'd opened in our BB. I will address this and fix x265 to follow the same convention as what is being used in ffmpeg and x264; makes no sense to use different names and force applications to map them. > Best regards > -- > Vittorio >
_______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
