summaryrefslogtreecommitdiff
path: root/tests/ref/fate
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* avfilter/palettegen: make refs order deterministicClément Bœsch2023-01-032-2/+2
| | | | | | Currently, in case of equality on the first color channel, the order of the ref colors is defined by the hashing function. This commit makes the sorting deterministic and improve the hierarchical ordering.
* avfilter/palettegen: base box split decision on a perceptual modelClément Bœsch2023-01-032-2/+2
| | | | | Similar to the change in paletteuse, we rely on a perceptual model to decide how and where to split the box.
* avfilter/palettegen: change cut score from ∑e² to max e²Clément Bœsch2023-01-032-2/+2
| | | | | | This is following the results from personal research¹. ¹: https://github.com/ubitux/research/tree/main/color-quantization#results
* avfilter/palettegen: define the best axis to cut using the squared errorClément Bœsch2023-01-032-2/+2
| | | | | | This is following the results from personal research¹. ¹: https://github.com/ubitux/research/tree/main/color-quantization#results
* avfilter/paletteuse: switch to a perceptual modelClément Bœsch2023-01-034-284/+284
| | | | | Now the selection of the color is based on a distance built around human perception of color instead of the unreliable sRGB triplet one.
* avfilter/vf_tinterlace: support full-range YUVNiklas Haas2022-12-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | This filter, when used in the "pad" mode, currently makes the distinction between limited and full range solely by testing for YUVJ pixel formats at link setup time. This is deprecated and should be improved to perform the detection based on the per-frame metadata. In order to make this distinction based on color range metadata, which is only known at the time of filtering frames, for simplicity, we simply allocate two copies of the "black" frame - one for limited range and the other for full range metadata. This could be done more dynamically (e.g. as-needed or simply by blitting the appropriate pixel value directly), but this change is relatively simple and preserves the structure of the existing code. This commit actually fixes a bug in FATE - the new output is correct for the first time. The previous md5 ref was of a frame that incorrectly combined full-range pixel data with limited-range black fields. The corresponding result has been updated. Signed-off-by: Niklas Haas <git@haasn.dev>
* avfilter/drawutils: rgb48/bgr48 is supportedPaul B Mahol2022-12-101-0/+2
|
* Revert "avcodec/decode: use a packet list to store packet properties"James Almer2022-12-071-1/+1
| | | | | | | | | | | | | | The idea behind last_pkt_props was to store the properties of the last packet fed to the decoder. Any sort of queueing required by CODEC_CAP_DELAY decoders that consume several packets before they start outputting frames should be done by the decoders in question. An example of this is libdav1d. This is required for the following commits that will fix last_pkt_props in frame threading scenarios, as well as maintain its contents during flush. This revers commit 022a12b306ab2096e6ac9fc9b149828a849d65b2. Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec/ass: specify a permissive encodingOneric2022-12-0324-24/+24
| | | | | | | | | | | | | | | The Encoding field (and the \fe tag) allows to limit font selection to only those fonts declaring support for the specified codepage in their OS/2's table "Code Page Character Range" field. Particularly, Encoding=0 means only font's declaring support for "ANSI", or rather "Latin (Western European)", are allowed to be selected. Specifying Encoding=1 allows all fonts to be considered. We do not want to limit font selection, so specify Encoding=1. NB: at the time of writing libass only partially supports this field, thus hiding the issue in any libass-based renderer. A VSFilter-based DirectShow filter or XySubFilter will reveal the issue when a font not declaring support for latin characters is specified in a style.
* avcodec/ass: accurately preserve coloursOneric2022-12-0324-0/+24
| | | | | | | | | | | | | | | | | | Colour values used in ASS files without a "YCbCr Matrix" header set to "None" are subject to colour mangling, due to how ASS was historically conceived. A more in-depth description can be found in the documetation inside libass' public ass_types.h header. The important part is, if this header is not set to "None", the final output colours can deviate from the literal value specified in the file. When converting from non-ASS formats we do not want any colour shift to happen, so let's set the appropiate header. NB: ffmpeg's subtitle filter, does not follow libass' documentation regarding colour mangling, thus hiding the bug. Anything based on VSFilter, XySubFilter or e.g. mpv do and might show the issue. (Of course native ASS subs, which _do_ rely on colour mangling won't work properly with the subtitle filter, but this can be fixed another time)
* avcodec/h2645_sei: Also support Active Format Descriptor for HEVCAndreas Rheinhardt2022-12-011-0/+204
| | | | | | | | | | | | | | | It is valid for HEVC; in fact, the ATSC-HEVC spec [1] simply refers to the relevant H.264 spec. It is also trivial to implement now: Just move applying AFD to ff_h2645_sei_to_frame() and stop ignoring AFD when parsing a HEVC SEI containing it. A FATE-test for this has been added. [1]: https://www.atsc.org/atsc-documents/a3412017-video-hevc/ Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/tiff: add read support for compressed rgb floating point formatsMark Reid2022-11-166-0/+36
| | | | | | | floating point uses a slightly different predictor technique describe here http://chriscox.org/TIFFTN3d1.pdf Signed-off-by: Anton Khirnov <anton@khirnov.net>
* fate/video: vqc testcasePeter Ross2022-11-071-0/+6
|
* fate/microsoft: add mss2 region test casePeter Ross2022-11-071-0/+7
|
* aacdec: convert to lavu/tx and support fixed-point 960-sample decodingLynne2022-11-062-145/+145
| | | | | | | | | | | This patch replaces the transform used in AAC with lavu/tx and removes the limitation on only being able to decode 960-sample files with the float decoder. This commit also removes a whole bunch of unnecessary and slow lifting steps the decoder did to compensate for the poor accuracy of the old integer transformation code. Overall float decoder speedup on Zen 3 for 64kbps: 32%
* ac3: convert to lavu/txLynne2022-11-065-61/+61
|
* avutil/channel_layout: add a 7.1(top) channel layoutJames Almer2022-11-031-0/+1
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avformat/tests/imf: add CPL timecode testPierre-Anthony Lemieux2022-11-031-0/+1
|
* avcodec/svq1: fix interframe mean VLC symbolsPeter Ross2022-11-011-11/+11
| | | | | | | | | | | | | | | | | | Fixes ticket #128. The SVQ1 interframe mean VLC symbols -128 and 128 are incorrectly swapped in our SVQ1 implementation, resulting in visible artifacts for some videos. This patch unswaps the order of these two symbols. The most noticable example of the artiacts caused by this error can be observed in https://trac.ffmpeg.org/attachment/ticket/128/svq1_set.7z '352_288_k_50.mov'. The artifacts are not observed when using the reference decoder (QuickTime 7.7.9 x86 binary). As a result of this patch, the reference data for the fate-svq1 test ($SAMPLES/svq1/marymary-shackles.mov) must be modified. For this file, our decoder output is now bitwise identical to the reference decoder. I have tested patch with various other samples and they are all now bitwise identical.
* avutil/channel_layout: add a cube channel layoutJames Almer2022-10-301-0/+1
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec/sgidec: Use planar pixel formatsAndreas Rheinhardt2022-10-058-8/+8
| | | | | | | The data in SGI images is stored planar, so exporting it via planar pixel formats is natural. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/rl2: Remove wrong checkAndreas Rheinhardt2022-10-021-108/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This check is intended to be avoid buffer overflows, yet there are four problems with it: 1. It has an in-built off-by-one error: len == out_end - out is perfectly fine and nothing to worry about. This off-by-one error led to the pixel in the lower-right corner not being set properly for the back frame of the sample from the rl2 FATE-test. This pixel is copied to every frame which is the reason for the update to the reference file of said test. With this patch, the output of the decoder matches the output as captured from the reference decoder* (apart from the fact that said reference somehow lacks the top part of the frame (copied over from the background frame)). 2. Given that the stride of the buffer may be different from the width of the video (despite one pixel taking one byte), there is a second check lateron making the first check redundant (if one returns immediately; a simple break at the second check is not sufficient, because it only exits the inner loop). 3. The check is based around the assumption of the stride being positive (it has this in common with the other check which will be fixed in a future commit). 4. Even after fixing the off-by-one error, the check in question is still triggered by all the non-background frames in the FATE sample as well as by A1100100.RL2. In all these cases, they use len == 255 and val == 128. For videos with background frame this just means "copy from the background frame", which would be done anyway lateron.* Yet for videos without it copying it is necessary to avoid leaving uninitialized parts in the video. *: Available in https://samples.mplayerhq.hu/game-formats/voyeur-rl2/ **: Due to this, the code that copies the rest from the back frame is no longer executed for any of the samples available on the sample server. Given that these are only the files from the demo version of this game, I don't know whether this code is executed for any file in existence or not. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil: add RGBA single-float precision packed formatsPaul B Mahol2022-09-252-0/+13
|
* avutil: add RGB single-precision float formatsPaul B Mahol2022-09-252-0/+11
|
* fate/cbs: Add tests for h264_redundant_pps BSFAndreas Rheinhardt2022-09-254-0/+454
| | | | | | | | This also tests writing slice data in the unaligned mode (some of these files use CAVLC) as well as updating side data as well as parsing ISOBMFF avcc extradata. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fate/segafilm: Add tests for segafilm (de)muxerAndreas Rheinhardt2022-09-204-0/+1463
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fate/ffmpeg: Use transcode instead of enc_dec in shortest-sub testAndreas Rheinhardt2022-09-201-2/+415
| | | | | | | | | | | | | | | enc_dec is designed for raw input and output and computes the PSNR between these two. The input of the shortest-sub test is the idx file of a vobsub sub+idx combination and the output is the output of framecrc of said vobsub subtitle muxed into Matroska together with a synthesized video. Calculating the PSNR between these two files makes no sense, therefore switch to a transcode test, where the ref file file contains the output of framecrc directly, making the interleavement better visible in the ref file at the cost of a larger ref file (>400 lines). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fate/mxf: add JPEG 2000 testPierre-Anthony Lemieux2022-09-201-0/+78
| | | | | Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fate/mxf: Add ProRes remux testAndreas Rheinhardt2022-09-201-0/+67
| | | | | | | Also covers writing mastering display metadata. Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/aptxenc: Process data in complete blocks of four samples onlyAndreas Rheinhardt2022-09-192-4/+4
| | | | | | | | | | | Do this by setting AVCodecInternal.pad_samples. This prevents reading into the frame's padding and writing into the packet's padding. This actually happened in our FATE tests (where the number of samples is 2 mod 4), which therefore needed to be updated. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/utils: Support APTX (HD) in av_get_audio_frame_duration()Andreas Rheinhardt2022-09-191-7/+10
| | | | | | | | | | | | APTX decodes four bytes of input to four stereo samples; APTX HD does the same with six bytes of input. So it can be easily supported in av_get_audio_frame_duration(). This fixes invalid durations and (derived) timestamps of demuxed APTX HD packets and therefore fixed the timestamp in the aptx-hd FATE test. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fate/audio: Add tests for APTX (HD)Andreas Rheinhardt2022-09-192-0/+33
| | | | | | | | | | | | | | | We have de- and encoders for APTX and APTX HD, yet not FATE tests. This commit therefore adds a transcoding test to utilize them. Furthermore, during creating these tests it turned out that the duration is set incorrectly for APTX HD. This will be fixed in a future commit. (Thanks to Andriy Gelman for finding an issue in an earlier version that used a 192kHz input sample which does not work reliably accross platforms.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* lavu/pixdesc: favour formats where depth and subsampling exactly matchPhilip Langdale2022-09-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since introducing the various packed formats used by VAAPI (and p012), we've noticed that there's actually a gap in how av_find_best_pix_fmt_of_2 works. It doesn't actually assign any value to having the same bit depth as the source format, when comparing against formats with a higher bit depth. This usually doesn't matter, because av_get_padded_bits_per_pixel() will account for it. However, as many of these formats use padding internally, we find that av_get_padded_bits_per_pixel() actually returns the same value for the 10 bit, 12 bit, 16 bit flavours, etc. In these tied situations, we end up just picking the first of the two provided formats, even if the second one should be preferred because it matches the actual bit depth. This bug already existed if you tried to compare yuv420p10 against p016 and p010, for example, but it simply hadn't come up before so we never noticed. But now, we actually got a situation in the VAAPI VP9 decoder where it offers both p010 and p012 because Profile 3 could be either depth and ends up picking p012 for 10 bit content due to the ordering of the testing. In addition, in the process of testing the fix, I realised we have the same gap when it comes to chroma subsampling - we do not favour a format that has exactly the same subsampling vs one with less subsampling when all else is equal. To fix this, I'm introducing a small score penalty if the bit depth or subsampling doesn't exactly match the source format. This will break the tie in favour of the format with the exact match, but not offset any of the other scoring penalties we already have. I have added a set of tests around these formats which will fail without this fix.
* fate/spdif: Add spdif testsAndreas Rheinhardt2022-09-1312-0/+1451
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These tests test both the demuxer as well as the muxer wherever possible. It is not always possible due to the fact that the muxer supports more codecs than the demuxer. The spdif demuxer does currently not set the need_parsing flag. If one were to set this to AVSTREAM_PARSE_FULL, the test results would change as follows: - For spdif-aac-remux, the packets are currently padded to 16bits, i.e. if the actual packet size is odd, there is a padding byte. The parser splits this byte away into a one byte packet of its own. Insanely, these one byte packets get the same duration as normal packets, i.e. timing is ruined. - The DCA-remux tests get proper duration/timestamps. - In the spdif-mp2-remux test the demuxer marks the stream as being MP2; the parser sets it to MP3 and this triggers the "Codec change in IEC 61937" codepath; this test therefore returns only two packets with the parser. - For spdif-mp3-remux some bytes end up in different packets: Some input packets of this file have an odd length (417B instead of 418B like all the other packets) and are padded to 418B. Without a parser, all returned packets from the spdif-demuxer are 418B. With a parser, the packets that were originally 417B are 417B again, but the padding byte has not been discarded, but added to the next packet which is now 419B. This fixes "Multiple frames in a packet" warning and avoids an "Invalid data found when processing input" error when decoding. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fate/subtitles: Add PGS remux testAndreas Rheinhardt2022-09-121-0/+15
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fate/id3v2: Add test for reading and writing UTF-16 BOM tagsAndreas Rheinhardt2022-09-121-0/+42
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* swscale/output: add support for Y210LE and Y212LEPhilip Langdale2022-09-109-0/+16
|
View Lorry Controller Status