Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>

A part of v8-v15 needs to be preserved across calls.

Update the class name to uniform indev/outdev style.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

fix error like "offset 0x1f85: partial file", the root cause is when
read the mp4 file from http, and the moov in the end of the mp4 file,
reconfig the buffer will drop some data.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Signed-off-by: Zhongxing Jiang <tomajsjiang@tencent.com>

Add new API ffio_realloc_buf for AVIO buffer realloc.
Signed-off-by: Zhongxing Jiang <tomajsjiang@tencent.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

ff_write_chained essentially duplicated the functionality of
av_packet_rescale_ts. This has been changed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

There is no reason for these functions to modify the given packets at
all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

avcodec/flicvideo: Optimize and Simplify FLI_COPY in flic_decode_frame_24BPP() by using bytestream2_get_buffer()

Fixes: Timeout (31sec  -> 22sec)
Fixes: 16217/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLIC_fuzzer-5658084189405184

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Timeout (42sec -> 379 ms)
Fixes: 16323/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LOCO_fuzzer-5679178099195904

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

tools/target_dec_fuzzer: adjust pixel threshold for MSRLE, as it allows coding gigantic images on tiny input

Fixes: Timeout (12sec ->2sec)
Fixes: 16125/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSRLE_fuzzer-5650846364205056

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The option tables of the various fftools (in particular ffprobe) are
arrays of OptionDef; said type contains a union of a pointer to void and
a function pointer of type int (*)(void *, const char *, const char *)
as well as a size_t. Some entries (namely the common entry for writing a
report as well as several more of ffprobe's entries) used the pointer to
void to store a pointer to functions of type int (*)(const char *) or
type int (*)(const char *, const char *); nevertheless, when the functions
are actually called in write_option (in cmdutils.c), it is done via a
pointer of the first type.

There are two things wrong here:
1. Pointer to void can be converted to any pointer to incomplete or
object type and back; but they are nevertheless not completely generic
pointers: There is no provision in the C standard that guarantees their
convertibility with function pointers. C90 lacks a generic function
pointer, C99 made every function pointer a generic function pointer and
still disallows the convertibility with void *.
2. The signature of the called function differs from the signature
of the pointed-to type. This is undefined behaviour in C99 (given that
C90 lacks a way to convert function pointers at all, it doesn't say
anything about such a situation). It only works because none of the
functions this patch is about make any use of their parameters at all.

Therefore this commit changes the type of the relevant functions
to match the type used for the call and uses the union's function
pointer to store it. This is legal even in C90.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: left shift of negative value -961533698048
Fixes: 16242/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5738550670131200

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: left shift of negative value -14671840
Fixes: 16000/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5145977817661440

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Deprecated since 2014.
Signed-off-by: Marton Balint <cus@passwd.hu>

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>

Maybe we should use service ID instead of increasing numbers?
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

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:v:0' \
  -map '0:v:1' \
  -map '0:a: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>

SDL_WINDOWEVENT_SIZE_CHANGED should be used instead of SDL_WINDOWEVENT_RESIZED
because SDL_WINDOWEVENT_RESIZED is only emitted if the resize happened due to
an external event.

Fixes ticket #8072.

Additional references:
https://bugzilla.libsdl.org/show_bug.cgi?id=4760
https://wiki.libsdl.org/SDL_WindowEventIDSigned-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>

Fixes: Timeout (95sec -> 30ms)
Fixes: 14765/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_INDEO2_fuzzer-5692455527120896

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Timeout (197sec ->144ms)
Fixes: 15034/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5733549405110272

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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/ffmpegReviewed-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: Timeout (81sec -> 0.2sec)
Fixes: 16169/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FOURXM_fuzzer-5662570416963584

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
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/ffmpegReviewed-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>

For now: print the input size as detected by AVSEEK_SIZE.

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Thilo Borgmann <thilo.borgmann@mail.de>
Signed-off-by: Zhong Li <zhong.li@intel.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.

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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>

Improves: Timeout (220sec -> 108sec)
Improves: 15570/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HNM4_VIDEO_fuzzer-5085482213441536

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>