[FFmpeg-trac] #4947(avcodec:open): libx264/265 encoder "parameter unknown" is a warning rather than an error

[FFmpeg]

#4947: libx264/265 encoder "parameter unknown" is a warning rather than an error
-------------------------------------+-------------------------------------
             Reporter:  wader8       |                    Owner:
                 Type:  enhancement  |                   Status:  open
             Priority:  wish         |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  libx264      |               Blocked By:
  libx265                            |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by wader8):

 Okay, but just to be sure in case this get's challanged, upon re-reading
 the original description, I think I have to rewrite and point out what I
 think I didn't explain well enough.

 In practise arises when a ffmpeg parameter is mistakenly used in the place
 where a avcodec parameter should be used, however, it also applies to any
 invalid avcoded parameter, so techincally it has nothing to do with
 ffmpeg's parameters, but I believe it does have to do with ffmpeg error
 level system in some fashion, as the codec most probably isn't running the
 whole console application.

 In x265 codec the message for an invalid parameter is simply "'''''unknown
 parameter'''''", however in the case of the x264 codec it is clearly
 labeled as an "error" by the original developers and the message reads
 "'''''error parsing option'''''", however neither are treated as actual
 errors by FFMPEG core and are treated as if they were a warning and so the
 process continues with default param values, which in a real situation may
 not be practical as the user who is originally trying to define such
 custom values for these params which have to be manually written. may want
 to have them customized to his/her precise liking, so the continuation of
 the encoding/decoding process may not be in any benefit in such cases, the
 user may go AFK, come back later only to find out the results are not to
 his liking, and would have to redo the whole process which does not save
 time and effort. Furthermore in rare case scenarios it may even take more
 time if the full verbose output is used for various codecs and ffmpeg,
 searching through the ouput to notice this warning may prove even more
 time consuming.

 In a similar case some time ago,  this is how it was fixed there
 http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=8c4ca4aa5aa998e31337e30ff30ebf48f534acc2

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4947#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker