A threshold of 1 is sufficient for simple_dump_cut.webm, 10 is used
just to be sure the next truncated file doesnt cause the same issue
Obvious alternative fixes are to simply accept that the file is broken or to
write some advanced error concealment or to
simply accept that the decoder wont stop at the end of input.
Fixes: Ticket 8069 (artifacts not the differing md5 which was there before 1afd246960202917e244c844c534e9c1e3c323f5)
Fixes: simple_dump_cut.webm
Fixes: regression of 1afd246960202917e244c844c534e9c1e3c323f5
fate-vp5 changes because the last frame is truncated and now handled
differently.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit b6b9ac5698c8f911841b469af77199153278c55c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 70fb3fa990d604211d5b24fc43cdfe31560de250)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For B field pictures, the spec says,
> The prediction shall be made from the field of the same parity as the field being predicted.
I did it.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 8b154cb3e90a3e599cadf477d815a9854b7bb4e1)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 65da5c56e661a839e017db4c51c73d6f3d8a8fcb)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should fix the fate failure due to a truncated last frame.
Alternatively the frame could be dropped.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d34bf886e963445350c4987f7a9ed77bd9c9a5c7)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 664/clusterfuzz-testcase-4917047475568640
The change to fate is due to a truncated last frames which is now detected as damaged.
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 513a3494396d0a20233273b3cadcb5ee86485d5c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes#6214 and vsynth1-dnxhd-720p-hr-lb.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
(cherry picked from commit e1940d2458353943e2fab6bdb87d2278077e22a5)
This reverts commit e0c6b32046f4bab7d34be77dd2f03b2a80c86d39.
Said commit changed the behavior of the demuxer and decoder in a non
backwards compatible way.
Demuxers should make extradata available at init if possible, and send
new extradata as side data within a packet if needed.
A better fix for the remuxing crash will follow.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 16c429166ddf1736972b6ccce84bd3509ec16a34)
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
(cherry picked from commit 719c15aa9ad6983200b78e5dbc17443f649c8af9)
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Also test the fallback to png creation for a single frame.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
(cherry picked from commit 97792e85c338d129342f5812e2a52048373e57d6)
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The dynamic buffer does not contain the CRC32 element so calls to avio_tell()
don't take it into account. This resulted in CueRelativePosition values being
six bytes short.
This is a regression since 6724525a1576ca334d2ffdc085620bb44aea7394
Instead of adding yet another custom check for CRC32 to fix a size or an offset,
remove the existing ones and reserve the six bytes in the dynamic buffer.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit eabbc64728c2fdb74f565aededec2ab023d20699)
Current code doesn't initialize AVPacket::pos. Made it point to FLVTAG so flv_read_packet can decode from pos
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We don't currently support values 1 (centimeters), 2 (inches) or 3 (DAR),
only the default value 0 (pixels) which doesn't need to be written.
The fate refs are updated as unknown SAR is now signaled in the output
files with the addition of the new element.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The spec says:
"Mandatory elements with a default value may be left out of the file. In the absence
of a mandatory element, the element's default value is used."
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Attachment tags were being written targeting non-existent streams in the
output file.
Also filter filename and mimetype entries, as they are standard elements
in the Attachment master.
Signed-off-by: James Almer <jamrial@gmail.com>
Using the stream timebase simply overflows
Fix integer overflow in psp framerate computation
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes a long-standing issue where running FATE in parallel could result
in the terminal being left misconfigured, particularly if a test failed or
was canceled wtih ^C.
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
The durations are never written in that situation.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This is a bit messy, mainly due to timestamp handling.
decode_video() relied on the fact that it could set dts on a flush/drain
packet. This is not possible with the old API, and won't be. (I think
doing this was very questionable with the old API. Flush packets should
not contain any information; they just cause a FIFO to be emptied.) This
is replaced with checking the best_effort_timestamp for AV_NOPTS_VALUE,
and using the suggested DTS in the drain case.
The modified tests (fate-cavs and others) still fails due to dropping
the last frame. This happens because the timestamp of the last frame
goes backwards (ffprobe -show_frames shows the same thing). I suspect
that this "worked" due to the best effort timestamp logic picking the
DTS over the decreasing PTS. Since this logic is in libavcodec (where
it probably shouldn't be), this can't be easily fixed. The timestamps
of the cavs samples are weird anyway, so I chose not to fix it.
Another strange thing is the timestamp handling in the video path of
process_input_packet (after the decode_video() call). It looks like
the code to increase next_dts and next_pts should be run every time
a frame is decoded - but it's needed even if output is skipped.
Fixes gapless decoding. Adjust skip_samples field correctly in case of DISCARDed audio frames.
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit is initially largely based on commit 4426540 from Anton
Khirnov <anton@khirnov.net> and two following fixes (80fb19b and
fe7b21c) which were previously skipped respectively in 98e3153, c9ee36e,
and 7fe7cdc.
mpeg4-bsf-unpack-bframes FATE reference is updated because the bsf
filter now actually fixes the extradata (mpeg4_unpack_bframes_init()
changing one byte is now honored on the output extradata).
The FATE references for remove_extra change because the packet flags
were wrong and the keyframes weren't marked, causing the bsf relying on
these proprieties to not actually work as intended.
The following was fixed by James Almer:
The filter option arguments are now also parsed correctly.
A hack to propagate extradata changed by bitstream filters after the
first av_bsf_receive_packet() call is added to maintain the current
behavior. This was previously done by av_bitstream_filter_filter() and
is needed for the aac_adtstoasc bsf.
The exit_on_error was not being checked anymore, and led to an exit
error in the last frame of h264_mp4toannexb test. Restoring this
behaviour prevents erroring out. The test is still changed as a result
due to the badly filtered frame now not being written after the failure.
Signed-off-by: Clément Bœsch <u@pkh.me>
Signed-off-by: James Almer <jamrial@gmail.com>
