This fixes some differences between runs of the ffserver tests
(in my local tree 2 runs gave the same result with this but i had other
changes too)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Move global thread variables to better place.
Use correct variable for simple and complex filtergraphs.
This makes number of threads set per filter work again.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This commit is based on commit 35c8580 from Anton Khirnov <anton@khirnov.net>
which was skipped in b8945c4.
The avcodec_copy_context() call in the encode path is left in place for now
as AVStream.codec is apparently still required even after porting ffmpeg to
the new bsf API.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
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>
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 is largely based on commit 15e84ed3 from Anton Khirnov
<anton@khirnov.net> which was previously skipped in bbf5ef9d.
There are still a bunch of things raising codecpar related warnings that
need fixing, such as:
- the use of codec->debug in the interactive debug mode
- read_ffserver_streams(): it's probably broken now but there is no test
- lowres stuff
- codec copy apparently required by bitstream filters
The matroska references are updated because they now properly forward
the field_order (previously unknown, now progressive).
Thanks to James Almer for fixing a bunch of FATE issues in this commit.
Signed-off-by: Clément Bœsch <clement@stupeflix.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Every date parsing routine now uses av_parse_time which handles 'now' and
provides greater precision as well. This change also enables the segmenter
muxer to set the proper 'now' creation time at the beginning of each segment.
Signed-off-by: Marton Balint <cus@passwd.hu>
These casts are unnecessary, and may safely be removed.
Found by enabling -Wpedantic on clang 3.7.
Tested with FATE.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
The "loop" option is used in several demuxers (like img2dec) and muxers, using the same name in ffmpeg_opt
breaks them. Feel free to revert this and replace by any other solution or rename both as preferred
This is just as a quick fix to avoid the regression with existing command lines and to have both named
the same (which does not work)
Example:
./ffmpeg -loop 1 -i fate-suite/png1/lena-rgb24.png -t 1 test.avi
will produce 25 frames with the img2dec loop but only 1 frame at 25fps with the ffmpeg loop option
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The amv one probably looks suspicious, but since it's an intra-only
codec, I couldn't possibly imagine what it would use the edge for,
and the vsynth fate result doesn't change, so it's probably OK.