Increase the nb_bitstream_filters value as soon as the context is allocated, so
if option parsing fails the last context is actually freed.
Reviewed-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '1e93c1e30ff0e8bf6094a426ca60f005e9cdaed3':
avconv: do not set encoder options when streamcopy is used
This chunk was removed in 955b818cf9
already.
Merged-by: Clément Bœsch <u@pkh.me>
This commit is initially largely based on commit 4426540 from Anton
Khirnov <anton@khirnov.net> and two following fixes (80fb19b and
fe7b21c) which were previously skipped respectively in 98e3153, c9ee36e,
and 7fe7cdc.
mpeg4-bsf-unpack-bframes FATE reference is updated because the bsf
filter now actually fixes the extradata (mpeg4_unpack_bframes_init()
changing one byte is now honored on the output extradata).
The FATE references for remove_extra change because the packet flags
were wrong and the keyframes weren't marked, causing the bsf relying on
these proprieties to not actually work as intended.
The following was fixed by James Almer:
The filter option arguments are now also parsed correctly.
A hack to propagate extradata changed by bitstream filters after the
first av_bsf_receive_packet() call is added to maintain the current
behavior. This was previously done by av_bitstream_filter_filter() and
is needed for the aac_adtstoasc bsf.
The exit_on_error was not being checked anymore, and led to an exit
error in the last frame of h264_mp4toannexb test. Restoring this
behaviour prevents erroring out. The test is still changed as a result
due to the badly filtered frame now not being written after the failure.
Signed-off-by: Clément Bœsch <u@pkh.me>
Signed-off-by: James Almer <jamrial@gmail.com>
This commit also drops SDL1 support for ffplay.
Tested-by: James Almer <jamrial@gmail.com> (Windows, mingw-w64)
Signed-off-by: Josh de Kock <josh@itanimul.li>
Although cuvid can only output 8bit, it can consume HEVC Main10 if
the bit depth is set properly. In cases where >8bit is not supported,
this change is still beneficial as the decoder will fail to be
created instead of plowing throw and decoding as 8bit.
We need to remove the dynlink fanciness and replace it with normal
function prototypes and update the include paths and configure logic.
We don't need to explicitly check for PICPARMS now - they're going
to be there.
For unknown reasons, the only accurately descriptive version of
cuviddec.h is in the Video SDK - the one in CUDA 7.5 lacks vp8
PICPARAMS and the vp9 struct definition is inaccurate. The CUDA 8 RC
includes an ancient version of this file from many many years go.
However, the one in the Video SDK is modified to work through a
dynamic link mechanism which we don't really want to use, so the
next change will modify the files to just declare functions in
the normal way.
I've split the changes so it's clear to see what changed between
the original files and ones that work for us.
Although the old API is supposed to be functional, the crystalhd
decoder is currently not working for non-annex.b h.264 content.
So, let's update to the modern API and make it work again.
Signed-off-by: Philip Langdale <philipl@overt.org>
Currently does not work with the ffmpeg cli tool, due do it using the
old one in one out API.
Anything using the new API, like mpv, can make use of it, provided it is
prepared for a decoder modifying the framerate and outputing multiple
frames per input. FFmpeg itself is not.
