ff_parse_close expects priv_data to be the ParseContext directly and
thus doesn't work if it isn't at the beginning of OpusParseContext.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Make ff_opus_parse_extradata free allocated memory on error instead of
expecting callers to free it in that case.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This decreases the amount of computations and memory needed for analysing mpeg1/2 streams
the properties update is moved from code that is skiped if skip_frame is set
to code that is not skiped so the change doesnt loose that
from being executed
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This could happen when there was a frame number gap and frame threading was used.
This fixes#5458.
Debugging-by: Ronald S. Bultje <rsbultje@gmail.com>
Debugging-by: Justin Ruggles <justin.ruggles@gmail.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
We are checking during encoding if there is enough space as version 4 needs that
check.
Fixes Ticket6005
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 6a62795d4051f435a9a2c59395d96913693922f8)
Cherry pick Suggested-by: Martin Storsjö
This should fix the build failure on macosx
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes slow loops on fuzzed data
Fixes: 245/fuzz-3-ffmpeg_AUDIO_AV_CODEC_ID_FLAC_fuzzer
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Only works if packed headers are supported, where we can know the
output before generating the first frame.
(cherry picked from commit 0cf86fabfa5820596cca2cfead63c6f8df76c3f2)
Fixes: left shift of negative value
Fixes: 668346-media
Found-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When input surfaces are cuda frames, we will not know what the actual
underlying format (nv12, p010, etc) is at surface allocation time.
On the other hand, we will know when the input frames are actually
registered and associated with a surface.
So, let's delay format discovery until registration time, which is
actually how we handle other frame properties, such as dimensions.
By itself, this change doesn't allow for transcoding of 10bit
content from cuvid, but it reduces the problem to the hardcoding of
the sw format in ffmpeg_cuvid.c
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The delta escape (2) is supposed to work the same in 4-bit RLE as in
8-bit RLE. This is documented in the MSDN Bitmap Compression page:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx
The unchecked modification of line is safe, since the loop condition
(line >= 0) will check it before any pixel data is written.
Fixes ticket #5153 (output now matches ImageMagick for the provided sample).
Signed-off-by: Daniel Verkamp <daniel@drv.nu>
