[FFmpeg-trac] #5231(avcodec:new): Crashes in ff_deblock_v_luma_8_sse2

FFmpeg trac at avcodec.org
Fri Feb 12 20:09:07 CET 2016


#5231: Crashes in ff_deblock_v_luma_8_sse2
-------------------------------------+-------------------------------------
             Reporter:  mi           |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avcodec
              Version:  unspecified  |               Resolution:
             Keywords:  h264 crash   |               Blocked By:
  SIGSEGV                            |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by mi):

 Replying to [comment:8 cehoyos]:
 > Replying to [comment:6 mi]:
 > > Reporting a problem in the latest ''release'' should be sufficient.
 >
 > Please understand that it is not (and has never been).

 Yes, it used to be worse -- the very idea of "release" was foreign to
 ffmpeg developers, I remember having this conversation with some of you
 before. We, downstream packagers, had to take date-based snapshots of your
 tree in order to provide ''something'' for our users.

 You know have something referred to as "releases", which I consider
 progress. The next step for you would be to actually support them...

 > (This was never different as far as I remember and is not different in
 projects that
 > are being compared, no matter what they tell you.)

 Whatever you may think of ''quality'' of other projects' releases -- and
 whether they are justified in using the name "release" for their snapshots
 at all -- no other project I've ever dealt with would force a bug-
 submitter to reproduce the bug on a non-released version of the software.
 Sometimes, if the buggy version is too old, the submitter may be asked to
 check, whether a more recent ''release'' still contains the problem, but
 the demand for use of the top of the trunk -- that's unique to ffmpeg.

 Replying to [comment:8 cehoyos]:
 > How can I reproduce this? I believe it is supposed to work (and it works
 fine here)...
 See ticket #5234.

 Replying to [comment:7 ubitux]:
 > I just tried {{{ffplay_g -cpuflags none+sse2 /tmp/staples-short.mp4}}}
 (and confirmed with
 > gdb that it indeed enters {{{ff_deblock_v_luma_8_sse2}}}) but couldn't
 reproduce the crash...

 What is your actual CPU? Like I wrote, I don't have this problem on a
 similar machine, which has Opterons instead of "GenuineIntel" E6700...

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


More information about the FFmpeg-trac mailing list