[FFmpeg-trac] #1853(swscale:open): libswscale writes past scanline end

FFmpeg trac at avcodec.org
Sun Oct 28 03:29:42 CET 2012

#1853: libswscale writes past scanline end
             Reporter:  gjdfgh      |                    Owner:
                 Type:  defect      |                   Status:  open
             Priority:  normal      |                Component:  swscale
              Version:  git-master  |               Resolution:
             Keywords:              |               Blocked By:
             Blocking:              |  Reproduced by developer:  1
Analyzed by developer:  0           |

Comment (by cehoyos):

 Trying to address some of the comments made on irc about this ticket:
 After working on several thousand FFmpeg bug reports (not just 1500 - ? -
 on trac) and a few mails on ffmpeg-users, I feel very safe to assume that
 reports that I can reproduce have a significantly higher probability of
 being fixed than reports that I cannot reproduce / do not understand.
 So typically, it makes a lot of sense to report the problem in a way that
 it can be easily understood by somebody who is neither an English native
 speaker nor the original author of the code.
 Concerning the question why ffmpeg (the application) has to be used: Of
 course tickets can be opened for library usage only, but as was explained
 on irc, in 90% of all such cases the problem is either easily reproducible
 with ffmpeg (and it is much more likely that a developer will work on it
 because a test case is available without additional time-consuming effort)
 or a bug in the user application. In the remaining cases, trying to figure
 out why a problem is not reproducible with ffmpeg typically helps a lot
 understanding (and fixing) the issue.
 That brings me to another point that may also be relevant in this case: It
 is not only not the duty of the reporter to analyze an issue, it is
 actually his only duty to provide a reproducible report with all
 information needed to reproduce the problem. It is of course ok to add an
 analysis, but the analysis should never replace the actual report, it is
 purely optional.
 And I will of course continue to also comment on issues that I fail to
 understand - it is not a good idea to ignore tickets: I originally missed
 ticket #1587 and it is now an interesting looking report without a sample
 to reproduce;-(

 Or in other words: Please believe me that my comments are made with the
 intention to help the reporter (both with the original problems and with
 future reports).

Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1853#comment:4>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list