On Tue, Jan 16, 2007 at 11:07:46AM +0100, Jindrich Makovicka wrote: > On 1/15/07, Diego Biurrun <diego at biurrun.de> wrote: > > > >Samuel Hocevar wrote his own fuzzer and let it loose on some multimedia > >players: > > > >http://sam.zoy.org/zzuf/ > > > >ffplay shows quite a few crashes, MPlayer as well, some of which are > >related to FFmpeg. No time for details right now, but it's easy enough > >to reproduce and the samples are tiny. > > MPlayer's mpeg1 sample (http://sam.zoy.org/zzuf/lol-mplayer.mpg) may > actually expose a bug in ffmpeg h264 decoder: > > [h264 @ 0x869b678]insane cropping not completely supported, this could > look slightly wrong ... > [h264 @ 0x869b678]Unknown NAL code: 15 > [h264 @ 0x869b678]Unknown NAL code: 16 > [h264 @ 0x869b678]Unknown NAL code: 0 > [h264 @ 0x869b678]slice type too large (0) at 0 0 > [h264 @ 0x869b678]decode_slice_header error > [h264 @ 0x869b678]non existing PPS referenced > [h264 @ 0x869b678]decode_slice_header error > ==7924== Jump to the invalid address stated on the next line > ==7924== at 0x0: ??? > ==7924== by 0x83FF46C: decode_slice (h264.c:7372) > ==7924== by 0x84001C4: decode_nal_units (h264.c:8075) > ==7924== by 0x840125C: decode_frame (h264.c:8218) > ==7924== by 0x82474BF: avcodec_decode_video (utils.c:904) > ==7924== by 0x812BA92: decode (vd_ffmpeg.c:774) > ==7924== by 0x80F3235: decode_video (dec_video.c:355) > ==7924== by 0x8098620: main (mplayer.c:3440) > ==7924== Address 0x0 is not stack'd, malloc'd or (recently) free'd For the record: This seems to have been fixed by recent h264.c changes, but now there is an infinite loop (or so it seems) with the following output: [h264 @ 0x10719f54]warning: first frame is no keyframe Diego
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4