On 2016-03-22 00:10:37 +0100, Hendrik Leppkes wrote: > On Tue, Mar 22, 2016 at 12:06 AM, Janne Grunau <[email protected]> wrote: > >> + GetByteContext gbc; > >> + PutByteContext pbc; > >> + uint8_t escaped_buf[256]; > > > > that looks plenty for sane SPS' but it should be easy to come up with > > scaling lists which exceeds this size (up to 6 * 16 + 2 * 64 signed > > exp-golomb values for [-128,127]). Since this is a codepath for not spec > > complient streams I'd just add a warning and return an error if the > > escaped_buffer is too small. > > > > Increasing the buffer a bit to hold enough bits for any possible valid > SPS shouldn't really hurt anything, so why build a fallback but then > limit it to something arbitrary like this?
Calculating the maximal SPS size is non-trivial. My best guess is between 1.1 and 1.5k (the scaling list data for 4:4:4 is in the worst case alone 1k (6 * 4x4 + 6 * 16x16 at 17 bits per value if I'm not mistaken). The annoying part is that is purely a theoretical maximum and it makes no sense to have scaling lists which take that much space to code. Checking for output buffer overruns (or testing the input size against the temp buffer size) is a good idea anyway for insane cases like including the first IDR-frame in extradata. Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
