Fixes: -nan is outside the range of representable values of type 'long'
Fixes: signed integer overflow: 1000 * -9223372036854775808 cannot be represented in type 'long'
Fixes: 34890/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-5334208657620992
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also use helper function to set the timestamp. Maybe we could also use
nanosecond precision, but there were some float rounding concerns.
Signed-off-by: Marton Balint <cus@passwd.hu>
Export them in UTC, not the local timezone. This way the output is
the same everywhere. The timezone information stored in the file is
still ignored, since there seems to be no simple way to export it
correctly.
Format them according to ISO 8601, which we generally use for exporting
dates.
Fixes fate-flv-demux, which was broken since
958bea5248 on some platforms.
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
Fixes: 30209/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-5724831658147840
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: -2.21166e+304 is outside the range of representable values of type 'long'
Fixes: 29169/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5725452796821504
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 255 by 24 places cannot be represented in type 'int'
Fixes: 27516/clusterfuzz-testcase-minimized-ffmpeg_dem_KUX_fuzzer-5152854660349952
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 29440/clusterfuzz-testcase-minimized-ffmpeg_dem_KUX_fuzzer-5985279812960256.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: out of array access
Fixes: 29202/clusterfuzz-testcase-minimized-ffmpeg_dem_KUX_fuzzer-5112845840809984
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: -9223372036854767583 + -65536 cannot be represented in type 'long'
Fixes: 26910/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6734549467922432
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Those are private fields, no reason to have them exposed in a public
header. Since there are some (semi-)public fields located after these,
even though this section is supposed to be private, keep some dummy
padding there until the next major bump to preserve ABI compatibility.
Since release 4.2, FFmpeg fails to detect the correct streams in an RTMP
stream that contains a |RtmpSampleAccess AMF object prior to the
onMetaData AMF object. In the debug log it would show "[flv] Unknown
type |RtmpSampleAccess".
This functionality broke in commit d7638d8dfc
as unknown metadata packets now result in an opaque data stream, and the
|RtmpSampleAccess packet was an "unknown" metadata packet type.
With this change the RTMP streams are correctly detected when there
is a |RtmpSampleAccess object prior to the onMetaData object.
Signed-off-by: Peter van der Spek <p.vanderspek@bluebillywig.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These functions already free it themselves before they allocate the new
extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is not uncommon to find code where the caller thinks to know better
what the return value should be than the callee. E.g. something like
"if (av_new_packet(pkt, size) < 0) return AVERROR(ENOMEM);". This commit
changes several instances of this to instead forward the actual error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: leozhang <leozhang@qiyi.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes ticket #4519.
The metadata starting at 0xe00004 is encrypted
with the password "meta" but zlib does not
support decryption, so no kux metadata is read.
we found some very old videos which suffered from
corruption after 9e6a242755, but were fine
before.
These had "End of AC stream reached in vp6_parse_coeff" warnings in logs.
These also had flv Packet mismatch warnings.
Adding FlixEngine to the list of flv muxers which produce broken packet
sizes fixes this corruption.
FlixEngine is very old and not maintained or available anymore (since
2010), so we won't need to worry about newer versions fixing the issue.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
merge from libav: 585dc1aece
If the metadata packet is corrupted, flv_read_metabody can accidentally
read past the start of the next packet. If the start of the next packet
had been flushed out of the IO buffer, we would be unable to seek to
the right position (on a nonseekable stream).
Prefer to clearly error out instead of silently trying to read from a
desynced stream which will only be interpreted as garbage.
merge from libav: 585dc1aece
If the metadata packet is corrupted, flv_read_metabody can accidentally
read past the start of the next packet. If the start of the next packet
had been flushed out of the IO buffer, we would be unable to seek to
the right position (on a nonseekable stream).
Prefer to clearly error out instead of silently trying to read from a
desynced stream which will only be interpreted as garbage.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
If the metadata packet is corrupted, flv_read_metabody can accidentally
read past the start of the next packet. If the start of the next packet
had been flushed out of the IO buffer, we would be unable to seek to
the right position (on a nonseekable stream).
Prefer to clearly error out instead of silently trying to read from a
desynced stream which will only be interpreted as garbage.
Signed-off-by: Martin Storsjö <martin@martin.st>
refer to SPEC:
Annex E. The FLV File Format said:
E.3 TheFLVFileBody have a table:
Field Type Comment
PreviousTagSize0 UI32 Always 0
Reviewed-by: Bela Bodecs <bodecsb@vivanet.hu>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Ever since the codecpar changes, this has been always printed when
opening a flv file. This is because the codecpar changes made all
streams to be added lazily as read_packet is called.
Otherwise the codec context and codecpar might disagree on the codec id,
triggering asserts in av_parser_parse2.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
when parsing keyframe index metadata, list the message by trace log
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Michael Niedermayer
Marton Balint
Anton Khirnov
James Almer
Andreas Rheinhardt
Peter van der Spek
Andreas Rheinhardt
leozhang
Swaraj Hota
Jun Zhao
Carl Eugen Hoyos
Martin Storsjö
Steven Liu
Nikolas Bowe
Alex Converse
Luca Barbato
Carl Eugen Hoyos
wm4
Andreas Cadhalpun