[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