summaryrefslogtreecommitdiff
path: root/tests
Commit message (Collapse)AuthorAge
* swscale/output: add support for Y210LE and Y212LEPhilip Langdale2022-09-10
|
* swscale/output: add support for XV30LEPhilip Langdale2022-09-10
|
* swscale/output: add support for XV36LEPhilip Langdale2022-09-10
|
* swscale/output: add support for P012Philip Langdale2022-09-10
| | | | This generalises the existing P010 support.
* fate/matroska: Add test for updating AV1 extradataAndreas Rheinhardt2022-09-10
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* tests/fate-run: Allow to set input options for encoding passAndreas Rheinhardt2022-09-10
| | | | | | This will be useful in the next commit. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avformat/mov: don't read duration from mvhd atomJames Almer2022-09-08
| | | | | | | | | | | | | | | This duration is equal to the longest duration in all track's tkhd atoms, which may be comprised of the sum of all edit lists in each track. Empty edit lists in tracks represent start_time, and the actual media duration is stored in the mdhd atom. This change lets the generic demux code derive the longest track duration taken from mdhd atoms, so the correct duration and start_time combination will be reported. Should fix ticket #9775. Reviewed-by: zhilizhao(赵志立) <quinkblack@foxmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
* checkasm/tx: add checkasm support for the iMDCTLynne2022-09-06
|
* ref/fate/ffprobe_xsd: Change ref fileAndreas Rheinhardt2022-09-06
| | | | | | | Forgotten in 5c16df1b92c519238e10664eeab3adb3b9016edd, because neither I nor patchwork ran fate with xmllint. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avformat/matroskaenc: Write CodecDelay for codecs != OpusAndreas Rheinhardt2022-09-05
| | | | | | | | | The field is not specific to Opus. The mp2fixed encoder signals initial_padding and is used by both the matroska-encoding-delay test as well as the lavf-mkv tests which necessitated several FATE ref changes. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avformat/matroskaenc: Use custom min timestampAndreas Rheinhardt2022-09-05
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avformat/matroskaenc: Actually apply timestamp offset for OpusAndreas Rheinhardt2022-09-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Matroska generally requires timestamps to be nonnegative, but there is an exception: Data that corresponds to encoder delay and is not supposed to be output anyway can have a negative timestamp. This is achieved by using the CodecDelay header field: The demuxer has to subtract this value from the raw (nonnegative) timestamps of the corresponding track. Therefore the muxer has to add this value first to write this raw timestamp. Support for writing CodecDelay has been added in FFmpeg commit d92b1b1babe69268971863649c225e1747358a74 and in Libav commit a1aa37dd0b96710d4a17718198a3f56aea2040c1. The former simply wrote the header field and did not apply any timestamp offsets, leading to desynchronisation (if one uses multiple tracks). The latter applied it at two places, but not at the one where it actually matters, namely in mkv_write_block(), leading to the same desynchronisation as with the former commit. It furthermore used the wrong stream timebase to convert the delay to the stream's timebase, as the conversion used the timebase from before avpriv_set_pts_info(). When the latter was merged in 82e4f39883932c1b1e5c7792a1be12dec6ab603d, it was only done in a deactivated state that still did not offset the timestamps when muxing due to "assertion failures and av sync errors". a1aa37dd0b96710d4a17718198a3f56aea2040c1 made it definitely more likely to run into assertion failures (namely if the relative block timestamp doesn't fit into an int16_t). Yet all of the above issues have been fixed (in commits 962d63157322466a9a82f9f9d84c1b6f1b582f65, 5d3953a5dcfd5f71391b7f34908517eb6f7e5146 and 4ebeab15b037a21f195696cef1f7522daf42f3ee. This commit therefore enables applying CodecDelay, fixing ticket #7182. There is just one slight regression from this: If one has input with encoder delay where the first timestamp is negative, but the pts of the part of the data that is actually intended to be output is nonnegative, then the timestamps will currently by default be shifted to make them nonnegative before they reach the muxer; the muxer will then ensure that the shifted timestamps are retained. Before this commit, the muxer did not ensure this; instead the timestamps that the demuxer will output were shifted and if the first timestamp of the actually intended output was zero before shifting, then this unintentional shift just cancels the shift performed before the packet reached the muxer. (But notice that this only applies if all the tracks use the same CodecDelay, or the relative sync between tracks will be impaired.) This happens in the matroska-opus-remux and matroska-ogg-opus-remux FATE tests. Future commits will forward the information that the Matroska muxer has a limited capability to handle negative timestamps so that the shifting in libavformat can take advantage of it. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avformat/matroskaenc: Only write DiscardPadding if nonzeroAndreas Rheinhardt2022-09-05
| | | | | | | | | | | | | | | | | It is possible for the trailing padding to be zero, namely e.g. if the AV_PKT_DATA_SKIP_SAMPLES side data is used for leading padding. Matroska supports this (use a negative DiscardPadding), but players do not; at least Firefox refuses to play such a file. So for now only write DiscardPadding if it is trailing padding and nonzero. The fate-matroska-ogg-opus-remux was affected by this. (I wish CodecDelay would not exist and DiscardPadding would be used to instead trim the codec delay away (with the Block timestamp corresponding to the time at which the actually output audio is output).) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fate/matroska: Add tests for muxing with initial_paddingAndreas Rheinhardt2022-09-05
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fftools/ffprobe: Report initial and trailing paddingAndreas Rheinhardt2022-09-05
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* lavc/dv: remove ff_dvvideo_init()Anton Khirnov2022-09-05
| | | | | | | | | | | The function contains only two assignments, setting DVVideoContext.avctx and AVCodecContext.chroma_sample_location. However, the decoder does not use the former, and the encoder should not be setting the latter. Therefore move the first assignment to dvenc and the second to dvdec. Make the encoder warn if the user-signalled chroma sample location does not match the supported one, and return an error on higher compliance levels.
* lavu/pixfmt: Add P012, Y212, XV30, and XV36 formatsPhilip Langdale2022-09-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These are the formats we want/need to use when dealing with the Intel VAAPI decoder for 12bit 4:2:0, 12bit 4:2:2, 10bit 4:4:4 and 12bit 4:4:4 respectively. As with the already supported Y210 and YUVX (XVUY) formats, they are based on formats Microsoft picked as their preferred 4:2:2 and 4:4:4 video formats, and Intel ran with it. P12 and Y212 are simply an extension of 10 bit formats to say 12 bits will be used, with 4 unused bits instead of 6. XV30, and XV36, as exotic as they sound, are variants of Y410 and Y412 where the alpha channel is left formally undefined. We prefer these over the alpha versions because the hardware cannot actually do anything with the alpha channel and respecting it is just overhead. Y412/XV46 is a normal looking packed 4 channel format where each channel is 16bits wide but only the 12msb are used (like P012). Y410/XV30 packs three 10bit channels in 32bits with 2bits of alpha, like A/X2RGB10 style formats. This annoying layout forced me to define the BE version as a bitstream format. It seems like our pixdesc infrastructure can handle the LE version being byte-defined, but not when it's reversed. If there's a better way to handle this, please let me know. Our existing X2 formats all have the 2 bits at the MSB end, but this format places them at the LSB end and that seems to be the root of the problem.
* libswscale: add support for VUYX formatPhilip Langdale2022-08-25
| | | | | | As we already have support for VUYA, I figured I should do the small amount of work to support VUYX as well. That means a little refactoring to share code.
* lavu/pixfmt: Introduce VUYX formatPhilip Langdale2022-08-25
| | | | | | | | | | | | | | This is the alphaless version of VUYA that I introduced recently. After further discussion and noting that the Intel vaapi driver explicitly lists XYUV as a support format for encoding and decoding 8bit 444 content, we decided to switch our usage and avoid the overhead of having a declared alpha channel around. Note that I am not removing VUYA, as this turned out to have another use, which was to replace the need for v408enc/dec when dealing with the format. The vaapi switching will happen in the next change
* avutil/half2float: adjust conversion of NaNTimo Rothenpieler2022-08-19
| | | | | | | | | | | IEEE-754 differentiates two different kind of NaNs. Quiet and Signaling ones. They are differentiated by the MSB of the mantissa. For whatever reason, actual hardware conversion of half to single always sets the signaling bit to 1 if the mantissa is != 0, and to 0 if it's 0. So our code has to follow suite or fate-testing hardware float16 will be impossible.
* checkasm: sw_scale: Produce more realistic test filter coefficients for yuv2yuvXMartin Storsjö2022-08-19
| | | | | | | | | This avoids triggering overflows in the filters, and avoids stray test failures in the approximate functions on x86; due to rounding differences, one implementation might overflow while another one doesn't. Signed-off-by: Martin Storsjö <martin@martin.st>
* avcodec/h263dec: Remove redundant code to set cur_pic_ptrAndreas Rheinhardt2022-08-18
| | | | | | | | | | | | | | It is done later in ff_mpv_frame_start() (and nobody uses current_picture_ptr between setting it in ff_mpv_frame_start()). (The reason the vsynth*-h263-obmc ref files change is because the call to ff_find_unused_picture() now happens after the older pictures have been unreferenced in ff_mpv_frame_start(), so that their slots in the picture array can be immediately reused; the obmc code is somehow buggy and changes its output depending on the earlier contents of the motion_val buffer.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* checkasm/sw_scale: hscale does not requires cpuflag test.Alan Kelly2022-08-18
| | | | | | This is done in ff_shuffle_filter_coefficients. Signed-off-by: Anton Khirnov <anton@khirnov.net>
* libswscale: Enable hscale_avx2 for all input sizes.Alan Kelly2022-08-18
| | | | | | ff_shuffle_filter_coefficients shuffles the tail as required. Signed-off-by: Anton Khirnov <anton@khirnov.net>
* checkasm: motion: Test different h parametersMartin Storsjö2022-08-17
| | | | | | | | | | | | | | | | | | Previously, the checkasm test always passed h=8, so no other cases were tested. Out of the me_cmp functions, in practice, some functions are hardcoded to always assume a 8x8 block (ignoring the h parameter), while others do use the parameter. For those with hardcoded height, both the reference C function and the assembly implementations ignore the parameter similarly. The documentation for the functions indicate that heights between w/2 and 2*w, within the range of 4 to 16, should be supported. This patch just tests random heights in that range, without knowing what width the current function actually uses. Signed-off-by: Martin Storsjö <martin@martin.st>
* checkasm: Provide enough alignment in the new yuv2plane1 testMartin Storsjö2022-08-16
| | | | | | This fixes the checkasm test in some setups on x86. Signed-off-by: Martin Storsjö <martin@martin.st>
* checkasm/hevc_add_res: add 12bit testJ. Dekker2022-08-16
| | | | | | | Also fix the bug where in every other byte only the lower 2 bits were used in the 8bit test. Signed-off-by: J. Dekker <jdek@itanimul.li>
* checkasm: updated tests for sw_scaleSwinney, Jonathan2022-08-16
| | | | | | | | | | | | | | | | | Change the reference to exactly match the C reference in swscale, instead of exactly matching the x86 SIMD implementations (which differs slightly). Test with and without SWS_ACCURATE_RND - if this flag isn't set, the output must match the C reference exactly, otherwise it is allowed to be off by 2. Mark a couple x86 functions as unavailable when SWS_ACCURATE_RND is set - apparently this discrepancy hasn't been noticed in other exact tests before. Add a test for yuv2plane1. Signed-off-by: Jonathan Swinney <jswinney@amazon.com> Signed-off-by: Martin Storsjö <martin@martin.st>
* lavu/pixfmt: add packed RGBA float16 formatTimo Rothenpieler2022-08-13
| | | | | This is the default format of the Windows compositor and what DXGI Desktop Duplication will give you for any kind of HDR output.
* avcodec/wmv2dec: Zero mb_type array for I picturesAndreas Rheinhardt2022-08-10
| | | | | | | | | | | | | | | | | | | | Up until now, ff_wmv2_decode_secondary_picture_header() only set the mb_type array for non I-pictures, so that the decoding process uses the earlier values of this array; this affects the output of the wmv8-x8intra FATE-test (which this patch therefore updates). These earlier values were set when decoding earlier frames or when the buffer was initially zero-allocated. A consequence of this is that the output of this test would be random if ff_find_unused_picture() would select the unused picture to return at random. Furthermore decoding from a keyframe onwards depends upon the earlier state of the decoder. This patch therefore zeroes said array when decoding an I picture. (It is not claimed that zero is the right value to fill the array with. I just don't know.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/mpegpicture: Move mb_var, mc_mb_var and mb_mean to MpegEncCtxAndreas Rheinhardt2022-08-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These tables are only used by encoders and only for the current picture; ergo they need not be put into the picture at all, but rather into the encoder's context. They also don't need to be refcounted, because there is only one owner. In contrast to this, the earlier code refcounts them which incurs unnecessary overhead. These references are not unreferenced in ff_mpeg_unref_picture() (they are kept in order to have something like a buffer pool), so that several buffers are kept at the same time, although only one is needed, thereby wasting memory. The code also propagates references to other pictures not part of the pictures array (namely the copy of the current/next/last picture in the MpegEncContext which get references of their own). These references are not unreferenced in ff_mpeg_unref_picture() (the buffers are probably kept in order to have something like a pool), yet if the current picture is a B-frame, it gets unreferenced at the end of ff_mpv_encode_picture() and its slot in the picture array will therefore be reused the next time; but the copy of the current picture also still has its references and therefore these buffers will be made duplicated in order to make them writable in the next call to ff_mpv_encode_picture(). This is of course unnecessary. Finally, ff_find_unused_picture() is supposed to just return any unused picture and the code is supposed to work with it; yet for the vsynth*-mpeg4-adap tests the result depends upon the content of these buffers; given that this patchset changes the content of these buffers (the initial content is now the state of these buffers after encoding the last frame; before this patch the buffers used came from the last picture that occupied the same slot in the picture array) their ref-files needed to be changed. This points to a bug somewhere (if one removes the initialization, one gets uninitialized reads in adaptive_quantization in ratecontrol.c). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* checkasm: Silence warnings about unused return value from read()Martin Storsjö2022-08-08
| | | | | | | This codepath is enabled by default on arm, if the linux perf API is available, unless disabled with --disable-linux-perf. Signed-off-by: Martin Storsjö <martin@martin.st>
* swscale/output: fix reading chroma values when generating vuya outputJames Almer2022-08-08
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* fate: fix reference file for fate-pixfmt_bestJames Almer2022-08-07
| | | | | | Missed in 85c59bd6de88aafa7b5682d7b71ff1adefe21a9e Signed-off-by: James Almer <jamrial@gmail.com>
* avformat/riff: map AYUV fourcc to RAWVIDEO decoderJames Almer2022-08-07
| | | | | | There's no need to keep using a custom decoder for this pixel format. Signed-off-by: James Almer <jamrial@gmail.com>
* swscale/output: add VUYA output supportJames Almer2022-08-07
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec: WBMP (Wireless Application Protocol Bitmap) image formatPeter Ross2022-08-07
| | | | | Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> Signed-off-by: Peter Ross <pross@xvid.org>
* avcodec/flacdsp: Split encoder-only parts into a ctx of its ownAndreas Rheinhardt2022-08-05
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/flacdsp: Remove unused function parameterAndreas Rheinhardt2022-08-05
| | | | | | Forgotten in e609cfd697f8eed7325591f767585041719807d1. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* lavu/pixfmt: Add packed 4:4:4 formatPhilip Langdale2022-08-03
| | | | | | | | | The "AYUV" format is defined by Microsoft as their preferred format for 4:4:4 content, and so it is the format used by Intel VAAPI and QSV. As Microsoft like to define their byte ordering in little-endian fashion, the memory order is reversed, and so our pix_fmt, which follows memory order, has a reversed name (VUYA).
* avformat/flvenc: fix timestamp of key frame indexZhao Zhili2022-08-03
| | | | | | | | | Firstly, the timestamps generated from framerate are inaccurate for variable framerate mode. Secondly, the timestamps always start from zero, while pts/dts can start from nonzero. FLV demuxer rejects such index with message: "Found invalid index entries, clearing the index".
* fate/lavf-image: Disable file checksums for exr testsAndreas Rheinhardt2022-08-02
| | | | | | | | | | The generated files are endian-dependent, so no checksums may be part of the ref files. Fixes ticket #9854. Tested-by: Sebastian Ramacher <sramacher@debian.org> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* tests/fate-run: Allow to skip file checksums for lavf_imageAndreas Rheinhardt2022-08-02
| | | | | | | | | | | | | | The output file (even the filesize) of the recently added EXR tests depends on the endianness; therefore checksums of these files must not be part of the ref file. Therefore this commit adds an option (unused for now) to disable these checksums on a per-test basis. In order to avoid having to check twice, the checksum and the filesize info are moved to immediately follow one another; this results into updates to the ref files of all lavf-image tests. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* tests/ref/fate/filter-metadata-cropdetect[12]: Fix ref fileAndreas Rheinhardt2022-07-30
| | | | | | | | Necessitated by 6ca43a9675d651d7ea47c7ba2fafb1bf831c4d0b and 425b309fa43236f4b7c098c7829b70a421fc1dd7. Reviewed-by: Martin Storsjö <martin@martin.st> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* lavfi/cropdetect: Add new mode to detect crop-area based on motion vectors ↵Thilo Borgmann2022-07-30
| | | | | | and edges This filter allows crop detection even if the video is embedded in non-black areas.
* fate/png: add test for ICC profile parsingNiklas Haas2022-07-30
| | | | | | | This tests the new "-flags2 icc_profiles" option by making sure the embedded ICC profile gets correctly detected as sRGB. Signed-off-by: Niklas Haas <git@haasn.dev>
* fate/imf: Rename IMF fate-targetAndreas Rheinhardt2022-07-26
| | | | | | | | | | It conflicts with the name of the test using the testtool in libavformat.mak. Fixes ticket #9841. Reviewed-by: Pierre-Anthony Lemieux <pal@sandflow.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* fate/hevc: add clip for persistent_rice_adaptation_enabled_flagXu Guangxin2022-07-25
| | | | | | Tests the issue fixed in c8bc0f66a875bc3708d8dc11b757f2198606ffd7. Signed-off-by: Xu Guangxin <oddstone@gmail.com>
* fftools/ffmpeg: use the sync queues to handle -framesAnton Khirnov2022-07-23
| | | | | | | | | | | | | | | | Same issues apply to it as to -shortest. Changes the results of the following tests: - matroska-flac-extradata-update The test reencodes two input FLAC streams into three output FLAC streams. The last output stream is limited to 8 frames. The current code results in the first two output streams having 12 frames, after this commit all three streams have 8 frames and are the same length. This new result is better, since it is predictable. - mkv-1242 The test streamcopies one video and one audio stream, video is limited to 11 frames. The new result shortens the audio stream so that it is not longer than the video.
* fftools/ffmpeg: rework -shortest implementationAnton Khirnov2022-07-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The -shortest option (which finishes the output file at the time the shortest stream ends) is currently implemented by faking the -t option when an output stream ends. This approach is fragile, since it depends on the frames/packets being processed in a specific order. E.g. there are currently some situations in which the output file length will depend unpredictably on unrelated factors like encoder delay. More importantly, the present work aiming at splitting various ffmpeg components into different threads will make this approach completely unworkable, since the frames/packets will arrive in effectively random order. This commit introduces a "sync queue", which is essentially a collection of FIFOs, one per stream. Frames/packets are submitted to these FIFOs and are then released for further processing (encoding or muxing) when it is ensured that the frame in question will not cause its stream to get ahead of the other streams (the logic is similar to libavformat's interleaving queue). These sync queues are then used for encoding and/or muxing when the -shortest option is specified. A new option – -shortest_buf_duration – controls the maximum number of queued packets, to avoid runaway memory usage. This commit changes the results of the following tests: - copy-shortest[12]: the last audio frame is now gone. This is correct, since it actually outlasts the last video frame. - shortest-sub: the video packets following the last subtitle packet are now gone. This is also correct.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-22 17:21:33 +0000