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.
Maybe such large values could be disallowed earlier and closer to where
they are set.
Fixes: signed integer overflow: 538976288 * 8224 cannot be represented in type 'int'
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_RM_fuzzer-6704350354341888
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: 5404200000 - -9223372031709351616 cannot be represented in type 'long'
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_REALTEXT_fuzzer-6737340551790592
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: 2 * -1725947872 cannot be represented in type 'int'
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_QCP_fuzzer-6726807632084992
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: 1207959552 * 4 cannot be represented in type 'int'
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_PP_BNK_fuzzer-6747301169201152
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: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_NUT_fuzzer-6739990530883584
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: 2048 * 1122336 cannot be represented in type 'int'
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_MSF_fuzzer-6726959600107520
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: 0 - -9223372036854775808 cannot be represented in type 'long'
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_MPL2_fuzzer-6747053545881600
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: 15 + 9223372036854775796 cannot be represented in type 'long'
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_MPC8_fuzzer-6723520756318208
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_MPC8_fuzzer-6739833034768384
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: 6365816 * 1000 cannot be represented in type 'int'
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_MCC_fuzzer-6737934184218624
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: 588 * 16719904 cannot be represented in type 'int'
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-6748331936186368
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka 'int'); cast to an unsigned type to negate this value to itself
Fixes: assertion failure
Fixes: 29102/clusterfuzz-testcase-minimized-ffmpeg_dem_DXA_fuzzer-6744985740378112
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: null pointer passed as argument 1, which is declared to never be null
Fixes: 33791/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5107575256383488.fuzz
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 negative value -1
Fixes: 33736/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SIREN_fuzzer-6657785795313664
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix memory leak for RequestItem upon error while pushing to the
request_queue in the completion callback.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
Instead use --preprocessor-arg; in binutils 2.36, the --preprocessor
flag was changed so that it no longer accepts a string containing
multiple arguments, but the whole --preprocessor argument is
treated as the path to the preprocessor executable (where the path
can contain spaces).
It's currently unclear whether this behaviour will stay or if it
is going to be reverted in the future, see discussion at [1]. Just
to be safe, avoid using the --preprocessor argument. Don't redeclare
the full preprocessing command, but just add the $(CC_DEPFLAGS) options.
Based on a patch by Kyle Schwartz.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=27594
Signed-off-by: Martin Storsjö <martin@martin.st>
When streaming mode is enabled with fMP4/CMAF for DASH output, the
segment files are available to read by players as soon as the first byte
is written instead of only after the file is fully written. The DASH
manifest currently only gets written when the final write to the segment
file occurs. This means that players cannot stream the first segment
while it is being written.
When -lhls is enabled with MP4 segments the HLS manifest is written
immediately to advertise the in-flight segments. This change adds the
same behavior for the DASH manifest so players can stream it
immediately.
AV_OPT_TYPE_VIDEO_RATE AVOption types are parsed as expressions, but in a
limited way. For example, name constants can only be parsed alone and not as
part of a longer expression.
This change allows usage like
ffmpeg -i IN -vf fps="if(eq(source_fps\,film)\,ntsc_film\,source_fps)" OUT
Suggested-by: ffmpeg@fb.com
Signed-off-by: James Almer <jamrial@gmail.com>
Again. 240M matrix is different from BT.601! And 170M is the same
as BT.601. It is primaries that are the same in 240M and 170M, as
for jp2k_rsiz see page 17 of ST 422:2019. IT WAS THERE since 2006.
This wrong jp2k_rsiz is a copy-paste of header_open_partition_key.
