PCR generation was based on counting packets for both CBR and VBR streams.
Couting packets might have worked for CBR streams (when muxrate was specified)
but it only took into account the packets of a service (or the packets of the
PCR stream lately), so even that was problematic for multi program streams.
The new code works on actual timestamps for both CBR and VBR streams. For VBR
streams the behaviour of the old code is simulated by selecting a PCR interval
which is the highest multiple of the frame duration but still less than 100 ms.
It should be trivial to add support for setting the PCR interval for VBR
streams as well in a later patch.
The accuracy of PCR packets for CBR streams was greatly improved by preemtively
sending them at PCR intervals even if sending the payload of another stream
is in progress.
This may fix these tickets:
- #5750
- #7524
Signed-off-by: Marton Balint <cus@passwd.hu>
The MPEG-TS muxer had a serious bug related to the use of multiple programs:
in that case, the PCR pid selection was incomplete for all services except one.
This patch solves this problem and selects a stream to become PCR for each
service, preferably the video stream.
This patch also moves pcr calculation attributes to MpegTSWriteStream from
MpegTSService. PCR is a per-stream and not per-service thing, so it was
misleading to refer to it as something that is per-service.
Also remove *service from MpegTSWriteStream because a stream can belong to
multiple services so it was misleading to select one for each stream.
You can check the result with this example command:
./ffmpeg -loglevel verbose -y -f lavfi -i \
"testsrc=s=64x64:d=10,split=2[out0][tmp1];[tmp1]vflip[out1];sine=d=10,asetnsamples=1152[out2]" \
-flags +bitexact -fflags +bitexact -sws_flags +accurate_rnd+bitexact \
-codec:v libx264 -codec:a mp2 -pix_fmt yuv420p \
-map '0✌️0' \
-map '0✌️1' \
-map '0🅰️0' \
-program st=0:st=2 -program st=1:st=2 -program st=2 -program st=0 -f mpegts out.ts
You should now see this:
[mpegts @ 0x37505c0] service 1 using PCR in pid=256
[mpegts @ 0x37505c0] service 2 using PCR in pid=257
[mpegts @ 0x37505c0] service 3 using PCR in pid=258
[mpegts @ 0x37505c0] service 4 using PCR in pid=256
Fixes ticket #8039.
v2: a video is stream is preferred if there are no programs, just like before
the patch.
Signed-off-by: Marton Balint <cus@passwd.hu>
98e419cb added SIMD for the convolution filter for x64 systems. As
usual, it used a check of the form
if (ARCH_X86_64)
ff_convolution_init_x86(s);
and thereby relied on the compiler eliminating this pseudo-runtime check
at compiletime for non x64 systems (for which ff_convolution_init_x86
isn't defined) to compile. But vf_convolution.c contains more than one
filter and if the convolution filter is disabled, but one of the other
filters (prewitt, sobel, roberts) is enabled, the build will fail on x64,
because ff_convolution_init_x86 isn't defined in this case.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This patch adds a new option to the scale filter which ensures that the
output resolution is divisible by the given integer when used together
with `force_original_aspect_ratio`. This works similar to using `-n` in
the `w` and `h` options.
This option respects the value set for `force_original_aspect_ratio`,
increasing or decreasing the resolution accordingly.
The use case for this is to set a fixed target resolution using `w` and
`h`, to use the `force_original_aspect_ratio` option to make sure that
the video always fits in the defined bounding box regardless of aspect
ratio, but to also make sure that the calculated output resolution is
divisible by n so in can be encoded with certain encoders/options if
that is required.
Signed-off-by: Lars Kiesow <lkiesow@uos.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Timeout (23sec -> 71ms)
Fixes: 15661/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP6A_fuzzer-6257865947348992
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Changing details as following:
1. Remove the local variable 'out_m' in 'CLIP_SH' and store the result in
source vector.
2. Refine the implementation of macro 'CLIP_SH_0_255' and 'CLIP_SW_0_255'.
Performance of VP8 decoding has speed up about 1.1%(from 7.03x to 7.11x).
Performance of H264 decoding has speed up about 0.5%(from 4.35x to 4.37x).
Performance of Theora decoding has speed up about 0.7%(from 5.79x to 5.83x).
3. Remove redundant macro 'CLIP_SH/Wn_0_255_MAX_SATU' and use 'CLIP_SH/Wn_0_255'
instead, because there are no difference in the effect of this two macros.
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 1 + 2147483647 cannot be represented in type 'int'
Fixes: 16041/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5685680656613376
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, when performing a SEEK_END seek, the subfile protocol
ignored the desired position (relative to EOF) and used the current
absolute offset in the input file instead.
And when performing a SEEK_CUR seek, the current position has been
ignored.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
gcc 6.x and 7.x generate wrong code for little endian machines
for the vec_lvsl/vec_perm instruction combos in some cases.
The bug was fixed in version 8.x
If these instructions are replaced with vec_xl, the problem goes
away for all versions of the compilers.
Fixes ticket #7124.
This should reduces the number of uninteresting timeouts encountered
A single threshold for all codecs did not work
Fixes: 13979/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QTRLE_fuzzer-5629872380051456 (14sec -> 4sec)
Fixes: 14709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5704215281795072 (179sec -> 7sec)
Fixes: 16296/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HNM4_VIDEO_fuzzer-5756304521428992 (108sec -> 9sec)
Fixes: 15620/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GIF_fuzzer-5657214435459072 (26sec -> 26ms)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes the following ubsan errors with the sample from ticket #7980:
libavcodec/zmbvenc.c:243:29: runtime error: left shift of negative value -4
libavcodec/zmbvenc.c:244:28: runtime error: left shift of negative value -2
Otherwise the user might get a silence padded frame in the beginning or in the
middle of the encoding.
Some other bug uncovered this:
./ffmpeg -loglevel verbose -y -f data -i /dev/zero \
-filter_complex "nullsrc=s=60x60:d=10[v0];sine=d=10[a]" \
-map '[v0]' -c✌️0 rawvideo \
-map '[a]' -c🅰️0 mp2 \
-f mpegts out.ts
Signed-off-by: Marton Balint <cus@passwd.hu>
This makes the changed code-path faster.
Change not tested except with the fuzzer testcase as I found no other testcase.
Improves: Timeout (136sec -> 74sec)
Improves: 16040/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-5705876062601216
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
This may break some valid tiff files, it appears the specification does not require
the offsets to be increasing. They increase in the 2 test files i have though except
the last offset which is 0 (an end marker) and for which a special case is added to
avoid asking for a sample for that end marker.
See: [FFmpeg-devel] [PATCH 2/2] avcodec/tiff: Detect infinite retry loop
for an alternative implementation
Fixes: Timeout (Infinite -> Finite)
Fixes: 15706/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5114674904825856
This variant was requested by paul on IRC
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 2082471995 * 36 cannot be represented in type 'int'
Fixes: 16025/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DDS_fuzzer-5136663778426880
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of 1 by 31 places cannot be represented in type 'int'
Fixes: 15817/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPC8_fuzzer-5636626409062400
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This also makes the code consistent with the existing similar MUL64()
in decode_var_block_data()
Fixes: signed integer overflow: -7277630735906765035 + -3272193951413647896 cannot be represented in type 'long'
Fixes: 16015/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5666552818434048
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: 2147483424 - -1772303236 cannot be represented in type 'int'
Fixes: 15708/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5067890362941440
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
assuming each block contains an empty chunk there has to be at least 8 bytes extra.
Fixes: 15327/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-5676669303521280
Fixes: Timeout (11->5sec)
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 -9
Fixes: 15299/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSS2_fuzzer-5660922678345728
Fixes: 15557/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1IMAGE_fuzzer-5673351911047168
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 -5
Fixes: 15294/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-5733921754447872
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: 2147483645 + 4 cannot be represented in type 'int'
Fixes: 15418/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5685269069561856
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The current function will report one error message, but the caller func
haven't check it, so change the default to process as AVCOL_TRC_UNSPECIFIED.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Rick Kern <kernrj@gmail.com>
Fixes the following ubsan error:
libavcodec/r210enc.c:69:28: runtime error: left shift of 522 by 22 places cannot be represented in type 'int'
Fixes ticket #7982.
