[FFmpeg-trac] #3515(undetermined:new): Crashes or artifacts when playing a specific file/stream

[FFmpeg]

#3515: Crashes or artifacts when playing a specific file/stream
-------------------------------------+-------------------------------------
             Reporter:  evol         |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Trying to stream http://s3.amazonaws.com/ffmpeg-testing/badaccess.mp4
 using Chromium or VLC results in artifacts and/or crashes.

 Why am I submitting this bug report here? Both apps' video playing
 capabilities are powered by ffmpeg, so I think that the issue lies here
 somewhere.

 The problem is, I cannot reproduce this problem using just ffmpeg/ffplay.
 In addition to that, other videos encoded using the same software and
 settings are played back properly in all players, so I think that's not an
 issue with the video.

 I tested several configurations of players and operating systems while
 trying to play both the stream and the downloaded file. These are my
 results:

 || ||= Local file =||= Stream =||
 ||= Chrome 33 / OS X =|| crashes tab || crashes tab ||
 ||= Chromium git-3ca16748 / OS X =|| crashes tab || crashes tab ||
 ||= Chrome 33 / Windows (Native) =|| works || works ||
 ||= Chrome 33 / Windows (VM on OS X) =|| crashes tab || crashes tab ||
 ||= Chrome 33 / Linux =|| not tested || sometimes plays with artifacts,
 sometimes crashes ||
 ||= VLC 2.1.4 / OS X =|| crashes || plays with artifacts, then crashes
 whole system ||
 ||= VLC 2.1.3 / Windows =|| crashes || crashes ||
 ||= ffplay git-31c21d2f =|| works || works (low framerate) ||
 ||= QuickTime / OS X =|| works || works ||
 ||= Firefox 28 / OS X =|| works || works ||
 ||= Safari 7.0.2 / OS X =|| works || works ||

 I've managed to attach lldb to the Chromium tab process twice. One time
 I've got (sorry for not saving much information):

 {{{
 * thread #11: tid = 0x7eb97, 0x213cc453
 ffmpegsumo.so`ff_put_h264_chroma_mc8_rnd_ssse3 + 67, stop reason =
 EXC_BAD_ACCESS (code=1, address=0x23c58160)
 }}}

 The other time I've got:

 {{{
 * thread #16: tid = 0x24989, 0x213eb082
 ffmpegsumo.so`ff_pred8x8_vertical_8_mmx + 50, stop reason = EXC_BAD_ACCESS
 (code=1, address=0x22283160)
     frame #0: 0x213eb082 ffmpegsumo.so`ff_pred8x8_vertical_8_mmx + 50
 ffmpegsumo.so`ff_pred8x8_vertical_8_mmx + 50:
 -> 0x213eb082:  movq   %mm0, (%eax,%ecx,2)
    0x213eb086:  ret
    0x213eb087:  jmp    0x213eb090                ;
 ff_pred8x8_horizontal_8_mmx
    0x213eb089:  nop
 (lldb) bt
 * thread #16: tid = 0x24989, 0x213eb082
 ffmpegsumo.so`ff_pred8x8_vertical_8_mmx + 50, stop reason = EXC_BAD_ACCESS
 (code=1, address=0x22283160)
   * frame #0: 0x213eb082 ffmpegsumo.so`ff_pred8x8_vertical_8_mmx + 50
     frame #1: 0x21264bdf
 ffmpegsumo.so`hl_decode_mb_simple_8(h=<unavailable>) + 1663 at
 h264_mb_template.c:162
     frame #2: 0x2126ceb6 ffmpegsumo.so`decode_slice(avctx=<unavailable>,
 arg=0xb0080db4) + 406 at h264.c:4485
     frame #3: 0x2126cbf2 ffmpegsumo.so`execute_decode_slices(h=0x24be0000,
 context_count=<unavailable>) + 82 at h264.c:4636
     frame #4: 0x2125a8ce ffmpegsumo.so`decode_nal_units(h=<unavailable>,
 buf=<unavailable>, buf_size=2118106720, parse_extradata=<unavailable>) +
 2046 at h264.c:4999
     frame #5: 0x21268124 ffmpegsumo.so`decode_frame(avctx=<unavailable>,
 data=<unavailable>, got_frame=<unavailable>, avpkt=0x7e3fbebc) + 324 at
 h264.c:5136
     frame #6: 0x213533dc ffmpegsumo.so`frame_worker_thread(arg=0x7e3fbe00)
 + 492 at pthread_frame.c:153
     frame #7: 0x907bb5fb libsystem_pthread.dylib`_pthread_body + 144
 }}}

 I couldn't get more crash dumps out of Chromium, because suddenly the tabs
 started to close with status 0 without any crash reports that could be
 handled by lldb. :(

 Also, I'd like to note that the local file VLC crash was also because of a
 EXC_BAD_ACCESS.

 How to reproduce:

 Open http://s3.amazonaws.com/ffmpeg-testing/badaccess.mp4 using Chromium,
 Chrome or VLC.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/3515>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker