Quoting Janne Grunau (2016-03-23 09:02:50) > 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.
I guess I could malloc it, input_size * 4 / 3 should be enough (every 3-byte sequence escaped). -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
