Bug#741170: [libav] XBMC quits playing corrupt stream from PVR backend due to libav

Reinhard Tartler siretart at gmail.com
Sun May 4 15:02:09 UTC 2014


Control: reassign -1 libavcodec55,xbmc

On Sun, Mar 9, 2014 at 12:23 PM, Bálint Réczey <balint at balintreczey.hu> wrote:
> Source: libav
> Version: 6:10~beta1-2
> Severity: important
>
> Hi,
>
> The problem has been originally reported at upstream [1] [2].
> XBMC should keep playing the corrupt stream since otherwise errors in
> broadcast signals would make watching TV impossible.
> Vanilla XBMC using its in embedded FFmpeg plays the file [3] attached
> to the upstream bug report.

I've just tried to reproduce this with latest libav/master using this test case:

$ valgrind .build_11_alpha1/local/bin/avconv -y -i /tmp/test.mkv -f rawvideo

The provided sample is very broken with many corruptions.
Nevertheless, the only valgrind error I can see is this:

==28236== Syscall param write(buf) points to uninitialised byte(s)
==28236==    at 0x5FBB35D: ??? (syscall-template.S:81)
==28236==    by 0x4A0D52: file_write (file.c:68)
==28236==    by 0x48FB1D: ffurl_write (avio.c:240)
==28236==    by 0x4907EB: avio_write (aviobuf.c:128)
==28236==    by 0x509D33: ff_raw_write_packet (rawenc.c:28)
==28236==    by 0x4EC25C: av_interleaved_write_frame (mux.c:427)
==28236==    by 0x45C152: write_frame (avconv.c:374)
==28236==    by 0x45C9BC: poll_filters (avconv.c:582)
==28236==    by 0x44CA48: main (avconv.c:2425)
==28236==  Address 0x8463ca2 is 21,506 bytes inside a block of size
32,768 alloc'd
==28236==    at 0x4C2D110: memalign (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28236==    by 0x4C2D227: posix_memalign (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28236==    by 0xA2B93D: av_malloc (mem.c:81)
==28236==    by 0x495F98: avio_open2 (aviobuf.c:690)
==28236==    by 0x457C6E: open_output_file (avconv_opt.c:1610)
==28236==    by 0x4599C6: avconv_parse_options (avconv_opt.c:2104)
==28236==    by 0x44C678: main (avconv.c:2566)
==28236==
==28236== Syscall param write(buf) points to uninitialised byte(s)
==28236==    at 0x5FBB35D: ??? (syscall-template.S:81)
==28236==    by 0x4A0D52: file_write (file.c:68)
==28236==    by 0x48FB1D: ffurl_write (avio.c:240)
==28236==    by 0x490888: avio_flush (aviobuf.c:128)
==28236==    by 0x4EC277: av_interleaved_write_frame (mux.c:430)
==28236==    by 0x45C152: write_frame (avconv.c:374)
==28236==    by 0x45C9BC: poll_filters (avconv.c:582)
==28236==    by 0x44CA48: main (avconv.c:2425)
==28236==  Address 0x845e8a2 is 2 bytes inside a block of size 32,768 alloc'd
==28236==    at 0x4C2D110: memalign (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28236==    by 0x4C2D227: posix_memalign (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28236==    by 0xA2B93D: av_malloc (mem.c:81)
==28236==    by 0x495F98: avio_open2 (aviobuf.c:690)
==28236==    by 0x457C6E: open_output_file (avconv_opt.c:1610)
==28236==    by 0x4599C6: avconv_parse_options (avconv_opt.c:2104)
==28236==    by 0x44C678: main (avconv.c:2566)
==28236==

To me, it seems that the decoder produced wrong data (which is bad as
well), but I'm unable to see a crash in libavcodec itself.

This is clearly something that needs to be looked at upstream. Would
you mind filing a bug at http://bugzilla.libav.org yourself so that I
don't need to act as a proxy?

Thanks.
Reinhard



More information about the pkg-multimedia-maintainers mailing list