The SDK supports NalHrdConformance, RecoveryPointSEI and AUDelimiter for
hevc encoder, so we may allow user to set these coding options like as
what we did for h264_qsv encoder.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Signed-off-by: Zhong Li <zhongli_dev@126.com>
Call ff_sws_rgb2rgb_init via ff_thread_once instead of checking one of the
variables it updates.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: 35210/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CPIA_fuzzer-5669199688105984
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 3530839700044513368 + 8386093932303352321 cannot be represented in type 'long long'
Fixes: 35182/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5398383270428672
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of 1 by 31 places cannot be represented in type 'int'
Fixes: 35023/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CLEARVIDEO_fuzzer-6740166587842560
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 486539264 * 14 cannot be represented in type 'int'
Fixes: 35281/clusterfuzz-testcase-minimized-ffmpeg_dem_RSD_fuzzer-6068262742917120
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These bits are reserved in earlier versions of the H.264 spec, and
some poor hardware decoders require they are zero. Thus, it is useful
to be able to zero these on streams that may have them set. The result
is still a valid H.264 bitstream.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Support single input for guided filter by adding guidance mode.
If the guidance mode is off, single input is required. And
edge-preserving smoothing is conducted. If the mode is on, two
inputs are needed. The second input serves as the guidance. For
this mode, more tasks are supported, such as detail enhancement,
dehazing and so on.
Signed-off-by: Xuewei Meng <xwmeng96@gmail.com>
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Remove some incorrect (or at least misleading) statements, such as the
formats being ordered by quality, or the first format being the native
one. Neither of those are true for hardware acceleration, which is the
main use of this callback.
HDR10+ metadata is stored in the bit stream for HEVC. The story is
different for VP9 and cannot store the metadata in the bit stream.
HDR10+ should be passed to packet side data an stored in the container
(mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is
passing it to the AVPacket side data.
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Zern <jzern@google.com>
Decoders like cuviddec ignore and overwrite all the properties set by the generic
code as derived from AVCodecInternal.last_pkt_props. This flag ensures libavcodec
will not store and potentially queue input packets that ultimately will not be used.
Signed-off-by: James Almer <jamrial@gmail.com>
Since commit 89ffcd1, the status pts of the output link is set to a
value in the input link time base, not in the output link time base when
EOF is reached. Usually this pst value is larger than the required one
because the output link time base is more greater than the input link
time base. When "-vf vpp_qsv,fps" is used, user has to wait a long time
for the ending of the pipeline because fps filter output a huge number
of frames until the wrong status pts is hit.
The issue can be triggered with the command below (use a clip with 1000
frames in this case):
$> time ffmpeg -hwaccel qsv -c:v hevc_qsv -i input.h265 -vf
"vpp_qsv=w=1920:h=1080,fps=fps=30" -f null -
...
[out_0_0 @ 0x564ccd27e020] 10000000 buffers queued in out_0_0, something
may be wrong.
frame=40119596 fps=88080 q=-0.0 Lsize=N/A time=371:28:39.96 bitrate=N/A
speed=2.94e+03x
video:17238889kB audio:0kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: unknown
real 9m7.451s
user 2m34.102s
sys 0m39.734s
In order to avoid the above issue, the same time base for input and
ouput links is used in this patch.
Fixes ticket #9286
Signed-off-by: Zhong Li <zhongli_dev@126.com>
Un-hardcode the 200ms minimum latency between emitting subtitle events
so that those that wish to receive a subtitle event for every screen
change could do so.
The problem with delaying realtime output by any amount is that it is
unknown when the next byte pair that would trigger output will happen.
It may be within 200ms, or it may be several seconds later -- that's
not realtime at all.
