[FFmpeg-trac] #2695(avcodec:new): Occasional Access Violation: H264 with bad streams

FFmpeg trac at avcodec.org
Fri Jun 21 09:12:59 CEST 2013


#2695: Occasional Access Violation: H264 with bad streams
-------------------------------------+-------------------------------------
             Reporter:  BlackWarren  |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:  avcodec      |                  Version:  git-
             Keywords:  h264 crash   |  master
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------
 Summary of the bug:
 When playing a certain unreliable live stream, experienced core-dumps
 about every four hours on average.
 How to reproduce:
 {{{
 ffplay rtmp://planeta-online.tv:1936/live/channel_22
 }}}
 Version: Git trunk sources as of 5/24/13.  "version.sh" reports
 "N-53488-g953e335".
 Built: 6/20/13.
 Details:
 When playing unreliable H264 streams with FFPlay, I seem to get core-dumps
 randomly every few hours.  The exact location is usually the second
 instruction of "pred8x8_top_dc_8_mmxext" in "h264_intrapred.asm", where it
 dereferences "dest_cr" after subtracting "uvlinesize" from it, as called
 from the line reading

     h->hpc.pred8x8[h->chroma_pred_mode](dest_cr, uvlinesize);

 in "h264_mb_template.c".  "uvlinesize" is typically something like 320 at
 the time of crash, with "mb_y" zero.

 My take on this is that, when presented with garbaged stream data, the
 H264 frame decoder sometimes tries to perform predictions that involve
 higher rows (lower memory addresses): if "mb_y" happens to be zero (the
 top row), this means that it tries to read memory from "negative rows",
 addresses a few hundred bytes before the beginning of the legitimate frame
 data.  Often, those addresses point to harmless random bytes, but
 occasionally it actually points to unmapped memory pages, causing Access
 Violations.

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


More information about the FFmpeg-trac mailing list