[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