[FFmpeg-trac] #3895(ffmpeg:open): Multiple issues around the new function of -max_error_rate

FFmpeg trac at avcodec.org
Wed Aug 27 12:58:19 CEST 2014

#3895: Multiple issues around the new function of -max_error_rate
             Reporter:  JayBlanc    |                    Owner:
                 Type:  defect      |                   Status:  open
             Priority:  important   |                Component:  ffmpeg
              Version:  git-master  |               Resolution:
             Keywords:  regression  |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
Changes (by ubitux):

 * keywords:   => regression
 * priority:  normal => important
 * status:  new => open
 * component:  undetermined => ffmpeg


 Replying to [comment:8 JayBlanc]:
 > Repeating myself again: Please do not ask me to saturate my uplink for a
 considerable amount of time doing something that could get me into legal
 difficulty. The problem as described explains the issue, and it is trivial
 to confirm by reading the source how the new behaviour works and what it's
 impact is on maintaining compatibility with previous versions that did not
 have a positive return value unless a fatal error occurred.

 More than 2/3 of error in a stream is kind of surprising and the problem
 might be somewhere else in FFmpeg, that is the reason a sample was
 requested. May I ask what kind of errors you have?

 > I've pointed out the problem, I've fixed the problem for you, I've
 submitted a patch. But I do not want to become a developer on this project
 and I do not have time to spend on arguing to defend this patch on the
 mailing list, and I do not want to have to sign up to yet another open
 source project's mailing list in order to submit a trivial patch.

 You do not need to register to the mailing list to send the patch; the
 reason this was requested is because the review is not simple in the Trac,
 and that's just not how the project does it.

 Anyhow, you current patch is breaking something else: in particular, it's
 breaking in case decoding a picture fails (the CLI will exit 0 instead of
 !0). See Ticket #2405.

 I agree with you that this is a regression and something should be done
 about it, but your patch is unfortunately not the correct solution. Maybe
 the picture-case should be handled specially.

Ticket URL: <https://trac.ffmpeg.org/ticket/3895#comment:9>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list