When CMD is crc/framecrc, always use the macros CRC/FRAMECRC, even if it
includes unnecessary requirements for rawvideo/pcm_s16le encoders (as
actually noticed in a comment of the Makefile).
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
First, always require file protocol when FATE suite is used.
Then, add missing dependencies while removing duplicates.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Follows the proper order defined by the spec, even if mostly cosmetic, and is
also preparation for a following change.
Signed-off-by: James Almer <jamrial@gmail.com>
Tests both the Media 100 decoder (using the media100_to_mjpegb BSF
implicitly) as well as using said BSF, followed by the MJPEGB decoder.
(We currently hit a bug when remuxing: The demuxer treats compressorname
as encoded in a Mac character encoding (Mac OS Roman?) and converts
it to UTF-8, yet the muxer just writes it.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The iirfilter is only used in its test tool since
01ecb7172b which
stopped using it in AAC, its only user.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The follow cmd output corrupted file before the patch:
ffmpeg -f lavfi -i color=blue,trim=duration=0.04 \
-f lavfi -i anullsrc,atrim=duration=2 \
-movflags +empty_moov+hybrid_fragmented \
-frag_duration 1000000 \
-frag_interleave 1 \
output.mp4
1. first_track is the first track with track->entry != 0. As in the
command above, video track (track index 0) has a single frame. When
flush the second fragment, first_track is 1, the audio track.
2. write_moof = i == first_track, so write_moof is false for i = 0.
3. When mov->frag_interleave != 0, mov->mdat_buf != NULL, because
it contains audio data. So avio_write is called before write_moof,
that is, the data write before moof, and mov_finish_fragment
executed with wrong mdat_start.
4. With normal fmp4 output, the error isn't obvious. With
hybrid_fragmented, ffplay output.mp4 shows a lot of error messages.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Don't use a 7.1 EAC3 input file for which our decoder is not
bitexact; instead just use the asynth-44100-8.wav file
which (as a 7.1 file) exhibits the same issue fixed by
1b3f4842c1.
(Either the encoder or the resampler are still not completely
bitexact, so we limit the number of frames output.)
Also switch to a framecrc test so that the output channel layout
is directly contained in the ref file.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The file has buggy timestamps (it uses B-frames, yet pts==dts)
and therefore the last frame is currently discarded by FFmpeg cli.
Using -fps_mode passthrough avoids this and provides coverage
of the SVQ3 draining logic.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
