Jan Ekström (12021-02-10): > > No! Why would you do that? It adds one level of escaping, we already > > have way too much of them. > > Because: > 1. we have the functionality for it > 2. it matches the AVOption. > > Please do not take it as if I did not have any logic behind my actions > whatsoever, which is what the exclamation mark looks like.
I am sorry it gave that impression. I wanted just to express my dismay at having to reject this version once again. The logic you applied makes sense, but only if you forget that this key-value parser is there to work around a limitation of the options parsing code, i.e. the fact that only one value can be set for each option. And it comes with drawbacks, mainly the need to escape. If our options parser was more powerful or better designed, we could gladly get rid of this parsed. The parser for the concat script does not suffer from this limitations, and therefore does not need to be saddled with the corresponding drawbacks. > > I am not sure it is the right order. Options added on the fly should > > take precedence over options written in a file, in general. But the > > global / specific distinction makes it less clear-cut. > > > > You set the AVOption for option(s) to be applied for all files, and if > you want to only set some option for specific files you set them in > the list. > > *You* requested the latter capability, I added it. And I was talking about the precedence order in which you added it. > Yes. This just matches the rest of the documentation strings etc for > such things. Again, the lack of care for anything that is not directly related to the core functionality makes our work harder and less good later. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
