On 2016-03-21 15:00:22 +0100, Anton Khirnov wrote:
> Instead of handling the problem inside NAL decoding code, add a higher
> level wrapper function. This should be more robust against future
> changes (and easier to read).
> ---
> libavcodec/h264.c | 49 +++++++++++++++++++++++++++++++++++++++----------
> 1 file changed, 39 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/h264.c b/libavcodec/h264.c
> index 0b5b6c2..613c633 100644
> --- a/libavcodec/h264.c
> +++ b/libavcodec/h264.c
> @@ -32,6 +32,7 @@
> #include "libavutil/stereo3d.h"
> #include "libavutil/timer.h"
> #include "internal.h"
> +#include "bytestream.h"
> #include "cabac.h"
> #include "cabac_functions.h"
> #include "error_resilience.h"
> @@ -501,6 +502,40 @@ fail:
> static int decode_nal_units(H264Context *h, const uint8_t *buf, int buf_size,
> int parse_extradata);
>
> +/* There are (invalid) samples in the wild with mp4-style extradata, where
> the
> + * parameter sets are stored unescaped (i.e. as RBSP).
> + * This function catches the parameter set decoding failure and tries again
> + * after escaping it */
> +static int decode_extradata_ps_mp4(H264Context *h, const uint8_t *buf, int
> buf_size)
> +{
> + int ret;
> +
> + ret = decode_nal_units(h, buf, buf_size, 1);
> + if (ret < 0) {
we shouldn't try this if err_recognition & AV_EF_EXPLODE is true.
Keeping the debug av_log would be good too.
> + 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.
Janne
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
