On Tue, Mar 7, 2017 at 5:24 AM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Tue, Mar 07, 2017 at 12:20:20AM +0200, Jan Ekström wrote:
>> x264-params does the same thing and this leaves us with a single
>> option that is name-matched with x265-params available in the
>> libx265 wrapper.
>> ---
>> libavcodec/libx264.c | 29 -----------------------------
>> 1 file changed, 29 deletions(-)
>
> please wait with this
>
The patch set has [RFC] in its topic as I knew any sort of removal is
going to be a multi-step process. As I noted, I wasn't sure of the
process so I noted that in my cover letter.
> ...
> its a long time ago but i faintly remember that the option you are
> about to remove worked while the one remaining had bugs
The x264opt code seems to:
* Use custom dict parsing instead of av_dict_parse_string
* Try real hard to set you a "1" even if you set something else:
> char param[256]={0}, val[256]={0};
> if(sscanf(p, "%255[^:=]=%255[^:]", param, val) == 1){
> OPT_STR(param, "1");
> }else
> OPT_STR(param, val);
* The OPT_STR macro tries to catch X264_PARAM_BAD_NAME, while
x264-params just outputs "Error parsing option '%s = %s'.\n" in all
failure cases of x264_param_parse.
The x264-params code seems to:
* Use av_dict_parse_string/av_dict_get
> av_dict_parse_string(&dict, x4->x264_params, "=", ":", 0)
> en = av_dict_get(dict, "", en, AV_DICT_IGNORE_SUFFIX)
* Just pass key=value one by one into x264_param_parse
> x264_param_parse(&x4->params, en->key, en->value)
Personally I prefer the latter as it utilizes generic tools we have in
our libraries and seems to keep the idea closer to KISS. Catching
X264_PARAM_BAD_NAME might be a good addition to x264-params, but not
sure how much more helpful that would be in the end.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
