This reverts commit c2d155e11e.
GCC 6 incorrectly passes the configure test and then logs many warnings
of the form:
src/libavformat/dump.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-bool-operation’
The initialisation should be common. For libmfx, it was previously
happening in the derivation function and this moves it out. For VAAPI,
it fixes some failures when deriving from a DRM device because this
initialisation did not run.
This is an ABI change in libva2: previously the Intel driver had this
behaviour and it was implemented as a driver quirk, but now it is part
of the specification so all drivers must do it.
This has been deprecated in libva2 because hardware does not and will not
support it. Therefore never consider it for decode, and for encode assume
the user meant constrained baseline profile instead.
Since af1761f7b5 ffmpeg waits for a frame in each
stream before writing the output header. If we are using threaded decoding for
attached pictures, we have to read till EOF to be able to finally flush the
decoder and output the decoded frame. This essentially makes ffmpeg buffer all
non-attached picture packets, which will cause a "Too many packets buffered for
output stream" eventually.
By forcing single threaded decoding, we get a frame from a single packet as
well and we can avoid the error.
Fixes part of ticket #6375:
ffmpeg -i 46564100.mp3 -acodec libmp3lame -ab 128k -ac 2 out.mp3
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Allows to specify the action to be performed when reading the last frame
from the internal FIFO buffer. By default the last frame is written to
filter output depending on the timestamp rounding method. When using
"pass" action the last frame is passed through if input duration
has not been reached yet.
Examples using an input file with 25Hz, 1.4sec duration:
- "fps=fps=1:round=near" generates an output file of 1sec
- "fps=fps=1:round=near:eof_action=pass" generates an output file of
2sec
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Make easier to handle the polling function before we implement
full threading support.
(cherry picked from libav commit ca960161f0)
Signed-off-by: James Almer <jamrial@gmail.com>
These changes store id3 chapter data in ID3v2ExtraMeta and introduce
ff_id3v2_parse_chapters to parse them into the format context if needed.
Encoders using ff_id3v2_read, which previously parsed chapters into the
format context automatically, were adjusted to call
ff_id3v2_parse_chapters.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Split it off from install-data.
Among other things, this prevents spamming triplicate log lines during install.
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: James Almer <jamrial@gmail.com>
Add missing AV_OPT_FLAG_FILTERING_PARAM flag to "start_time" option.
Fix indent of "round" named constants and clear unused field values.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Align order of "start_time" option within fps filter documentation to actual
implementation. Also fix some documentation cosmetics.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Fixes out of array access
Fixes: crash-huf.avi
Regression since: 6b41b44149
This could also be fixed by adding checks in the C code that calls the dsp
Found-by: Zhibin Hu and 连一汉 <lianyihan@360.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some V4L2 drivers fail to allocate buffers when sizeimage is not set
to a max value. This is indeed the case for s5p-mfc [1]
Most drivers should be able to calculate this value from the frame
dimensions and format - or at least have their own default.
However since this work around should not impact those drivers doing
the "right thing" this commit just provides such a default.
The calculations were extracted from the v4l2 driver used to develop
the ffmpeg v4l2_m2m support [2]. See venc.c and vdec.c
[1] linux.git/drivers/media/platform/s5p-mfc
[2] linux.git/drivers/media/platform/qcom/venus/
The string is allocated with CFStringGetCString but was being
deallocated with free(), which would intermittently result in
a segmentation fault. Use the correct function for freeing the
allocated CFString.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
This FFmpeg-specific "fuzzer fix" was never perfect, but now it
stopped encoding of actual content with a big enough DTS shift.
This returns the function to its original state of results
before negative CTS offsets were added.
I remember dealing with this function before, but somehow had
forgotten about it during VDD. The test cases not tripping this
over also didn't help.