Build h2645_parse.o with it, as every hevc_ps dependency also needs it.
This is more in line with h264's h264parse module.
Signed-off-by: James Almer <jamrial@gmail.com>
Remove the SDL_main define from the global cflags but not from the
ffplay cflags, and the -mwindows linker option from extralibs instead
of overriding it with the addition of -mconsole.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
When profile mismatch is allowed, use the highest supported profile for
VAAPI decoding.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
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/
Marton Balint
James Almer
Jun Zhao
bnnm
foo86
Carl Eugen Hoyos
Mark Thompson
Carl Eugen Hoyos
Michael Bradshaw
Sasi Inguva
Jorge Ramirez-Ortiz
Tobias Rapp
Luca Barbato
Kaustubh Raste
Lukas Stabe
Michael Niedermayer