summaryrefslogtreecommitdiff
path: root/tests/ref
Commit message (Collapse)AuthorAgeFilesLines
* fate/jpg: add RGB mjpeg fate testsLeo Izen2023-05-175-0/+30
| | | | | Adds FATE tests for RGB jpegs to test commit 0b352e350e773673f11ea380f3507923c70e1175.
* tests/fate: add a simple test for libx264Anton Khirnov2023-05-151-0/+85
| | | | | | | | Since this is an external encoder not under our control, we cannot test the encoded output exactly as is done for internal encoders. We can still test however that the output is decodable and produces the expected number of frames with expected dimensions, pixel formats, and timestamps.
* avformat/tests/imf: add invalid resource testPierre-Anthony Lemieux2023-05-111-0/+2
|
* fftools/ffprobe: print exported stream AVOptionsJames Almer2023-05-084-7/+7
| | | | | | | Similar to the decoder AVOptions, this is useful to show values from options exported by the demuxer. Signed-off-by: James Almer <jamrial@gmail.com>
* fftools/ffmpeg: always use the same path for setting InputStream.[next_]dtsAnton Khirnov2023-05-022-28/+28
| | | | | | | | | | | | | | | | | | | | | Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.
* fftools/ffmpeg: rework audio-decode timestamp handlingAnton Khirnov2023-05-023-334/+334
| | | | | | | | | | | | | | | | | | | | | Stop using InputStream.dts for generating missing timestamps for decoded frames, because it contains pre-decoding timestamps and there may be arbitrary amount of delay between input packets and output frames (e.g. dependent on the thread count when frame threading is used). It is also in AV_TIME_BASE (i.e. microseconds), which may introduce unnecessary rounding issues. New code maintains a timebase that is the inverse of the LCM of all the samplerates seen so far, and thus can accurately represent every audio sample. This timebase is used to generate missing timestamps after decoding. Changes the result of the following FATE tests * pcm_dvd-16-5.1-96000 * lavf-smjpeg * adpcm-ima-smjpeg In all of these the timestamps now better correspond to actual frame durations.
* lavf/dv: use a more granular timebase for audioAnton Khirnov2023-05-021-8/+8
| | | | | | | | | | | | | One that is fine enough to represent all DV audio sample rates. Audio packet durations are now sample-accurate. This largely undoes commit 76fbb0052df471075858c1cb82b04c8be7adba8d. To avoid breaking the issue fixed by that commit, resync audio timestamps against video if they get more than one frame apart. The sample from issue #8762 still works correctly after this commit. Slightly changes the results of the lavf-dv seektest, due to the audio timebase being more granular.
* lavf/dv: do not set video timebase more than onceAnton Khirnov2023-05-024-44/+44
| | | | | | | | | | | | | Current code will call avpriv_set_pts_info() for each video frame, possibly setting a different timebase if the stream framerate changes. This violates API conventions, as the timebase is supposed to stay constant after stream creation. Change the demuxer to set a single timebase that is fine enough to handle all supported DV framerates. The seek tests change slightly because the new timebase is more granular.
* lavf/dauddec: set timebase to 1/samplerateAnton Khirnov2023-04-282-18/+18
| | | | | Prevents lavf from generating inexact timestamps with the default timebase of 1/90000.
* fftools/ffmpeg_enc: always use video frame durations when availableAnton Khirnov2023-04-244-71/+71
| | | | | | | | | Previously they would only be used with trivial filtergraphs, because filters did not handle frame durations. That is no longer true - most filters process frame durations properly (there may still be some that don't - this change will help finding and fixing them). Improves output video frame durations in a number of FATE tests.
* fate/jpeg2000: add JPEG 2000 tests using ITU/ISO conformance materialsPierre-Anthony Lemieux2023-04-2214-0/+84
| | | | | | | | | Adds JPEG 2000 decoder tests using materials from the conformance suite specified in Rec. ITU-T T.803 | ISO/IEC 15444-4. The test materials are available at https://gitlab.com/wg1/htj2k-codestreams Signed-off-by: Pierre-Anthony Lemieux <pal@palemieux.com>
* fate/h264: test disabling croppingJames Almer2023-04-221-0/+288
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* fate: add tests for RGB jpegsLeo Izen2023-04-213-0/+18
| | | | | Added framecrc tests for RGB JPEGs to verify future changes to the decoder.
* fate/png-icc-parse: update ref dataSteven Liu2023-04-211-12/+5
| | | | | | | | | | When enable lcms2, the fate-png-icc-parse will get error bellow. TEST png-icc-parse This because updated how PNG handles colors (no longer using mastering display metadata for that). Reviewed-by: Leo Izen <leo.izen@gmail.com> Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
* fftools/ffmpeg: propagate frame durations to packets when encodingAnton Khirnov2023-04-1919-133/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove now-obsolete code setting packet durations pre-muxing for CFR encoded video. Changes output in the following FATE tests: * numerous adpcm tests * ffmpeg-filter_complex_audio * lavf-asf * lavf-mkv * lavf-mkv_attachment * matroska-encoding-delay All of these change due to the fact that the output duration is now the actual input data duration and does not include padding added by the encoder. * apng-osample: less wrong packet durations are now passed to the muxer. They are not entirely correct, because the first frame duration should be 3 rather than 2. This is caused by the vsync code and should be addressed later, but this change is a step in the right direction. * tscc2-mov: last output frame has a duration of 11 rather than 1 - this corresponds to the duration actually returned by the demuxer. * film-cvid: video frame durations are now 2 rather than 1 - this corresponds to durations actually returned by the demuxer and matches the timestamps. * mpeg2-ticket6677: durations of some video frames are now 2 rather than 1 - this matches the timestamps.
* fftools/ffmpeg: stop using fake dts for generating timestampsAnton Khirnov2023-04-1352-3472/+3472
| | | | | | | | | | | | | When no packet dts values are available from the container, video decoding code will currently use its own guessed values, which will then be propagated to pkt_dts on decoded frames and used as pts in certain cases. This is inaccurate, fragile, and unnecessarily convoluted. Simply removing this allows the extrapolation code introduced in the previous commit to do a better job. Changes the results of numerous h264 and hevc FATE tests, where no spurious timestamp gaps are generated anymore. Several tests no longer need -vsync passthrough.
* fftools/ffmpeg: change video decoding timestamp generationAnton Khirnov2023-04-133-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When no timestamps are available from the container, the video decoding code will currently use fake dts values - generated in process_input_packet() based on a combination of information from the decoder and the parser (obtained via the demuxer) - to generate timestamps during decoder flushing. This is fragile, hard to follow, and unnecessarily convoluted, since more reliable information can be obtained directly from post-decoding values. The new code keeps track of the last decoded frame pts and estimates its duration based on a number of heuristics. Timestamps generated when both pts and pkt_dts are missing are then simple pts+duration of the last frame. The heuristics are somewhat complicated by the fact that lavf insists on making up packet timestamps based on its highly incomplete information. That should be removed in the future, allowing to further simplify this code. The results of the following tests change: * h264-3386 now requires -fps_mode passthrough to avoid dropping frames at the end; this is a pathology of the interaction of the new and old code, and the fact that the sample switches from field to frame coding in the last packet, and will be fixed in following commits * hevc-conformance-DELTAQP_A_BRCM_4 stops inventing an arbitrary timestamp gap at the end * hevc-small422chroma - the single frame output by this test now has a timestamp of 0, rather than an arbitrary 7
* lavf/rawdec: mark raw demuxers as having no timestampsAnton Khirnov2023-04-131-1/+1
| | | | | | Changes the result of the h264_redundant_pps-mov test, where the output timebase is now 1001/24000 instead of 1/24. This is more correct, as the source file actually is 23.98fps.
* lavf/rawdec: set avg_frame_rateAnton Khirnov2023-04-136-32/+32
| | | | | | | | | | | | Timestamps in two FATE H.264 conformance tests now start at 1 instead of 0, which also happens in some other H.264 tests before this commit and so is not a big issue. Conversely, timestamps in some HEVC conformance tests start from a smaller value now. Ideally this should be addressed later in a more general way. h264-conformance-frext-frext2_panasonic_b no longer requires -vsync passthrough.
* fftools/sync_queue: make sure audio duration matches sample countAnton Khirnov2023-04-091-1/+0
| | | | | | | | | For audio AVFrames, nb_samples is typically more trustworthy than duration. Since sync queues look at durations, make sure they match the sample count. The last audio frame in the fate-shortest test is now gone. This is more correct, since it outlasts the last video frame.
* fate/matroska: add HDR10+ muxing testsJames Almer2023-04-082-0/+126
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avformat/matroskaenc: support writing Dynamic HDR10+ packet side dataJames Almer2023-04-0827-85/+85
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avformat/matroskaenc: write a MaxBlockAdditionID elementJames Almer2023-04-0527-85/+85
| | | | | | A non zero value is mandatory for Matroska if the track has blocks with BlockAdditions. Signed-off-by: James Almer <jamrial@gmail.com>
* tests: Add more j2k tests to cover a wider range of casesMichael Niedermayer2023-04-028-0/+32
| | | | Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avcodec/j2kenc: Fix funky bpno errors on decodingMichael Niedermayer2023-04-027-14/+14
| | | | Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avformat/mxfenc: fix stored/sampled/displayed width/heightJerome Martinez2023-03-262-1/+4
| | | | | | | | | | | | | | | | | | | | According to MXF specs the Stored Rectangle corresponds to the data which is passed to the compressor and received from the decompressor, so they should contain the width / height extended to the macroblock boundary. In practice however width and height values rounded to the upper 16 multiples are only seen when muxing MPEG formats. Therefore this patch changes stored width and height values to unrounded for all non-MPEG formats, even macroblock based ones. For DNXHD the specs (ST 2019-4) explicitly indicates to use 1080 for 1088p. For ProRes the specs (RDD 44) only refer to to ST 377-1 without precision but no known commercial implementations are using rounded values. DV is not using 16x16 macroblocks, so 16 rounding makes no sense. The patch also fixes Sampled Width / Display Width to use unrounded values. Signed-off-by: Marton Balint <cus@passwd.hu>
* fftools/ffprobe: print crop_* frame fieldsJames Almer2023-03-2617-97/+273
| | | | | Reviewed-by: Stefano Sabatini <stefasab@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
* tests: Fix fate-source after 0fbae2178b4ffda298b10473aa6fe17ef524eff9Martin Storsjö2023-03-261-0/+1
| | | | Signed-off-by: Martin Storsjö <martin@martin.st>
* avcodec/snowenc: Fix visual weight calculationMichael Niedermayer2023-03-267-38/+38
| | | | Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 supportJerome Martinez2023-03-251-0/+3
|
* tests: add bwdif to fate filter testsJames Darnley2023-03-253-0/+134
|
* fftools/ffprobe: stop using AVFrame.pkt_{pos,size}Anton Khirnov2023-03-201-159/+159
| | | | | | | | | | | | | | | | | | | These fields are ad-hoc and will be deprecated. Use the recently-added AV_CODEC_FLAG_COPY_OPAQUE to pass arbitrary user data from packets to frames. Changes the result of the flcl1905 test, which uses ffprobe to decode wmav2 with multiple frames per packet. Such packets are handled internally by calling the decoder's decode callback multiple times, offsetting the internal packet's data pointer and decreasing its size after each call. The output pkt_size value before this commit is then the remaining internal packet size at the time of each internal decode call. After this commit, output pkt_size is simply the size of the full packet submitted by the caller to the decoder. This is more correct, since internal packets are never seen by the caller and should have no observable outside effects.
* fate: add a yuv422p test for the untile filterJames Almer2023-03-161-0/+13
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* fate/mov: add PCM in mp4 testZhao Zhili2023-03-152-0/+34
| | | | Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
* fate/vpx: add a vp9_superframe_bsf testJames Almer2023-03-101-0/+30
| | | | | | This splits a sample and merges it again, so it also tests the vp9_superframe_split bsf Signed-off-by: James Almer <jamrial@gmail.com>
* tests: actually test yadif's 10 and 16-bit functionsJames Darnley2023-03-062-60/+60
|
* avcodec/pngdec: read colorspace info when decoding with AVDISCARD_ALLLeo Izen2023-02-282-5/+5
| | | | | These chunks are lightweight and it's useful information to have when running ffmpeg -i or ffprobe, for example.
* fate/imfdec: add audio testPierre-Anthony Lemieux2023-02-181-0/+207
| | | | | | Adds a test where the temporal boundaries of audio and video resources do not line up. Signed-off-by: Pierre-Anthony Lemieux <pal@palemieux.com>
* avformat/movenc: allow writing out channel count in MP4 and 3GPJan Ekström2023-02-141-1/+1
| | | | | | | | | | | | | | | | | | | ISOBMFF (14496-12) made this field ('channelcount') in the AudioSampleEntry structure non-template¹ somewhere before the release of the 2022 edition. As for ETSI TS 126 244 AKA 3GPP file format (V16.1.0, 2020-10), it does not seem contain any references limiting the channelcount entry in AudioSampleEntry or in its own definition of EVSSampleEntry. fate-mov-mp4-chapters test had to be adjusted as it output a mono vorbis stream, which would now be properly marked as such in the container. 1: As per 14496-12: Fields shown as “template” in the box descriptions are fields which are coded with a default value unless a derived specification defines their use and permits writers to use other values than the default.
* ffprobe: report the corrupt flag on packetsrcombs2023-02-0935-2780/+2780
| | | | Signed-off-by: Anton Khirnov <anton@khirnov.net>
* ffmpeg: add video heartbeat capability to fix_sub_durationJan Ekström2023-02-031-0/+48
| | | | | | | | | | | | | | | | | | | Splits the currently handled subtitle at random access point packets that can be configured to follow a specific output stream. Currently only subtitle streams which are directly mapped into the same output in which the heartbeat stream resides are affected. This way the subtitle - which is known to be shown at this time can be split and passed to muxer before its full duration is yet known. This is also a drawback, as this essentially outputs multiple subtitles from a single input subtitle that continues over multiple random access points. Thus this feature should not be utilized in cases where subtitle output latency does not matter. Co-authored-by: Andrzej Nadachowski <andrzej.nadachowski@24i.com> Co-authored-by: Bernard Boulay <bernard.boulay@24i.com> Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
* avcodec/png: use libavutil/csp.h for cHRM chunksLeo Izen2023-01-252-13/+2
| | | | | | | | | | | | | | | | | | | | | | | | The cHRM chunk is descriptive. That is, it describes the primaries that should be used to interpret the pixel data in the PNG file. This is notably different from Mastering Display Metadata, which describes which subset of the presented gamut is relevant. MDM describes a gamut and says colors outside the gamut are not required to be preserved, but it does not actually describe the gamut that the pixel data from the frame resides in. Thus, to decode a cHRM chunk present in a PNG file to Mastering Display Metadata is incorrect. This commit changes this behavior so the cHRM chunk, if present, is decoded to color metadata. For example, if the cHRM chunk describes BT.709 primaries, the resulting AVFrame will be tagged with AVCOL_PRI_BT709, as a description of its pixel data. To do this, it utilizes libavutil/csp.h, which exposes a funcction av_csp_primaries_id_from_desc, to detect which enum value accurately describes the white point and primaries represented by the cHRM chunk. This commit also changes pngenc.c to utilize the libavuitl/csp.h API, since it previously duplicated code contained in that API. Instead, taking advantage of the API that exists makes more sense. pngenc.c does properly utilize the color tags rather than incorrectly using MDM, so that required no change. Signed-off-by: Leo Izen <leo.izen@gmail.com>
* ffprobe: fix data hash renderingStefano Sabatini2023-01-246-1220/+1220
| | | | | | | | Print data hash before side data list, fix wrong nesting level of data hash element. In particular, fix trac issue: http://trac.ffmpeg.org/ticket/7217
* avfilter/vf_cropdetect: add ability to change limit at runtimeAshyni2023-01-243-44/+44
| | | | | | Fixes: https://trac.ffmpeg.org/ticket/9851 Signed-off-by: Ashyni <jeffrey.c@tuta.io>
* avformat/segment: calculate segment durations correctly.Gyan Doshi2023-01-161-2/+2
| | | | | | | | | segment_time and segment_times are defined as duration specifications, not timestamps, so calculation of segment duration must account for initial timestamp. Fixed. FATE ref for segment-mp4-to-ts changed on account of avoiding premature segment cut at the end of the first segment.
* avcodec/h2645_sei: add support for Ambient Viewing Environment SEIJan Ekström2023-01-131-0/+12
| | | | | | | | | | Defined by H.274, this SEI message is utilized by iPhones to save the nominal ambient viewing environment for the display of recorded HDR content. The contents of the message are exposed to API users as AVFrame side data containing AVAmbientViewingEnvironment. As the DV RPU test sample is from an iPhone and includes Ambient Viewing Environment SEI messages, its test result gets updated.
* lavf/spdifdec: support EAC3rcombs2023-01-131-0/+659
| | | | | | Parsing should probably be enabled for all codecs, at least for headers, but e.g. the AAC parser produces 1-byte packets of zero padding with it, so I'm just enabling it for EAC3 for the moment.
* avcodec/av1_parser: export timing information when presentJames Almer2023-01-101-24/+24
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* fftools/ffmpeg: always generate CFR output when -r is usedAnton Khirnov2023-01-102-86/+8
| | | | | | | | | | | | | | | | Current code may, depending on the muxer, decide to use VSYNC_VFR tagged with the specified framerate, without actually performing framerate conversion. This is clearly wrong and against the documentation, which states unambiguously that -r should produce CFR output for video encoding. FATE test changes: * nuv-rtjpeg: replace -r with '-enc_time_base -1', which keeps the original timebase. Output frames are now produced with proper durations. * filter-mpdecimate: just drop the -r option, it is unnecessary * filter-fps-r: remove, this test makes no sense and actually produces broken VFR output (with incorrect frame durations).
* lavc/bitstream: templatize for BE/LEAnton Khirnov2023-01-061-0/+1
| | | | Allows using both BE and LE bitstream readers in the same file.
View Lorry Controller Status