[libav-bugs] [Bug 660] New: AIFF Decoder not adding pad bytes

bugzilla at libav.org bugzilla at libav.org
Sun Mar 23 21:01:09 CET 2014


http://bugzilla.libav.org/show_bug.cgi?id=660

           Summary: AIFF Decoder not adding pad bytes
           Product: Libav
           Version: 9
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: critical
          Priority: Normal
         Component: libavformat
        AssignedTo: bugzilla at libav.org
        ReportedBy: libavbug at byom.de


libav often fails to decode AIFF songs.
I found the reason in aiffdec.c. In the function aiff_read_header at the end
you currently see this:

    default: /* Jump */
        if (size & 1)   /* Always even aligned */
            size++;
        avio_skip(pb, size);
    }
}

Actually this should be this:

    default: /* Jump */
        avio_skip(pb, size);
    }
    if (size & 1) {   /* Always even aligned */
        --filesize;
        avio_skip(pb, 1);
    }
}

The AIFF specification says that a padding byte has to be added whenever a
chunk is of odd size. Your code only does this for UNKNOWN chunks (in the
default code path of the switch). My correction jumps over the padding byte in
all cases. Additionally your code did not decrement the remaining filesize when
jumping over the byte. So the code above fixes two bugs at once.

Here is an example header of an AIFF file that could not be decoded by libav.
The NAME chunk has 13 bytes and therefore libav failed to load all following
chunks, because it did not jump over the padding byte after the name with odd
length:

46 4F 52 4D 00 A6 18 0F 41 49 46 46 43 4F 4D 4D 00 00 00 12 00 02 00 29 7B C0
00 10 40 0E AC 44 00 00 00 00 00 00 4E 41 4D 45 00 00 00 0D 41 6E 73 61 67 65
20 31 34 30 33 31 35 00 41 55 54 48 00 00 00 05 ...

Thank you!

-- 
Configure bugmail: http://bugzilla.libav.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.


More information about the libav-bugs mailing list