1)Some filters allow cross-referenced expressions e.g. x=y+10. In
such cases, filters evaluate expressions multiple times for
successful evaluation of all expressions. If the expression for one or
more variables contains a RNG, the result may vary across evaluation
leading to inconsistent values across the cross-referenced expressions.

2)A related case is circular expressions e.g. x=y+10 and y=x+10 which
cannot be succesfully resolved.

3)Certain filter variables may only be applicable in specific eval modes
and lead to a failure of evaluation in other modes e.g. pts is only
relevant for frame eval mode.

At present, there is no reliable means to identify these occurrences and
thus the error messages provided are broad or inaccurate. The helper
function introduced - av_expr_count_vars - allows developers to identify
the use and count of variables in expressions and thus tailor the error
message, allow for a graceful fallback and/or decide evaluation order.

fix the playpath truncation if the len > 512
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Found-by: liuwenhuang <liuwenhuang@tencent.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

Fixes ticket 8383
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Fixes misdetection of zYLx.wav
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Helps: test_roman.mjpeg (note this is not really just mjpeg)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The earlier requirement was for the new buffer to be bigger than the old
one. This has been relaxed to only demand that the new buffer can hold
all the data written so far. This is in preparation for further commits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes: out of array read
Fixes: 18715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5659333417500672

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>

Encoders must return reference counted packets.

This was checked only for encoders using the AVCodec->encode2() API, while
blindly accepting whatever encoders using the AVCodec->receive_packet() API
were returning.
Signed-off-by: James Almer <jamrial@gmail.com>

The current approach has two different calls to av_bsf_send_packet():
A normal one, sending a packet; and an extraordinary one just for
flushing. These can be unified into one by making use of the newly
documented fact that av_bsf_send_packet() allows to signal flushing via
empty packets (i.e. packets without data and side-data).

This also fixes CID 1455685 which resulted from the fact that the call
for flushing was not checked given that it couldn't fail.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Explicitly allowing empty packets to signal flushing helps getting rid
of special cases. It does not hinder the ability to send i.e.
timing-only packets, because one can send packets with zero size and
pkt->data set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

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>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

avformat/hlsenc: free the original malloc pointer to avoid error when system function used in the following patch
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

fix ticket: 7811
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

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