The fate test is changed because the reference file depends on the use of
non cleared data at the very
end. Alternatively we could upload a new reference file, though that would
then have to be changed every time the handling of a truncated frame changes
or theres a change to error concealment, each time adding a new file ...
Fixes use of uninitialized memory
Fixed: msan_uninit-mem_7f3c02b81363_2787_RLG2_19.rm
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ca96e337169093979d7c763064ad9dae12b3108c':
vp9: drop support for real (non-emulated) edges
Conflicts:
libavcodec/vp9block.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ef8c93e2f18c624d0c266687e43ab99af7921dd3':
vp8: drop support for real (non-emulated) edges
Conflicts:
tests/fate/vpx.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
They are not measurably faster on x86, they might be somewhat faster on
other platforms due to missing emu edge SIMD, but the gain is not large
enough to justify the added complexity.
They are not measurably faster on x86, they might be somewhat faster on
other platforms due to missing emu edge SIMD, but the gain is not large
enough to justify the added complexity.
* commit '9d18a7d3ec09d6d933d648570643fde924aa391a':
fate: Update AAC ELD 5.1 ref for recent bugfixes.
also reenable fate-aac-er_ad6000np_44_ep0, as this commit updates the pcm
reference, so that the test works again
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b2212dec0f011893ec68eecaa990170fa24050d7':
aac: Fix TNS decoding for the 512 sample window family.
also temporarily disable fate-aac-er_ad6000np_44_ep0 as this commit
causes a mismatch with the reference pcm file
The test will be reenabled after all fixes and with a new pcm reference
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b318106fae65149356934fc72feafef3272fd4ea':
FATE: add a test for the lavr mixing case fixed in fc6a3ef40d
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a8cc88b1a23dc1515f27cfa98af16a273c539091':
tests/Makefile: allow FILTER* to be called with lists of filter names
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
fate: Explicitly specify the pixel format for the pngparser test
Conflicts:
tests/fate/image.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The RGB32 pixel format is RGBA/BGRA depending on target
endianness - make sure to convert it to one specific format for
the framecrc tests.
This fixes the pngparser fate test on big endian.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'cfb4ee30977732674d30c20e93a761c33c743972':
fate: add a pngparser test
Conflicts:
tests/fate/image.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'eddff165b4cdc1f064245a4bad6f4265581c12b1':
fate: add utility function to test parser, demuxer, and decoder
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is useful for debugging.
Reference and ffprobe.xsd changes done and tested by Stefano Sabatini.
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
Since we don't write lavf's string when bitexact is requested, this will
prevent the tag from being copied from the source stream.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '58a868968df445068a143f327ced03b6a02baf0d':
FATE: drop the last partial frame in the wmv8-drm test
Conflicts:
tests/ref/fate/wmv8-drm
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The encoder uses almost none of the mpegvideo infrastructure, only some
fields from MpegEncContext.
The FATE results change because now an all-zero quant matrix is written
into the file. Since it is not used for anything for ljpeg, this should
not be a problem.
This makes the USE_FLOATS == 0 available to the end user
More float optimizations can easily be added as well now
common code should be factored out into a common file once all
fixed point & floating point optimizations are done, this is to
avoid having to move code back and forth between files.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The old one didn't use segmentation. One uses segmentation in all frame
types (--aq-mode=1), and the other uses all segmentation features, but
only in inter frames (mbgraph).
* commit '874838dc6589d978611c89a40694a5074f892a76':
fate: add one select filter test
Conflicts:
tests/fate/filter-video.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Originally written by Ronald S. Bultje <rsbultje@gmail.com> and
Clément Bœsch <u@pkh.me>
Further contributions by:
Anton Khirnov <anton@khirnov.net>
Diego Biurrun <diego@biurrun.de>
Luca Barbato <lu_zero@gentoo.org>
Martin Storsjö <martin@martin.st>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This changes the tests that used the internal hevc checksum to use framecrc
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Conflicts:
tests/fate/hevc.mak
tests/ref/fate/hevc-conformance-DBLK_A_SONY_3
tests/ref/fate/hevc-conformance-DBLK_B_SONY_3
tests/ref/fate/hevc-conformance-DBLK_C_SONY_3
tests/ref/fate/hevc-conformance-DELTAQP_B_SONY_3
tests/ref/fate/hevc-conformance-DELTAQP_C_SONY_3
tests/ref/fate/hevc-conformance-POC_A_Bossen_3
Merged-by: Michael Niedermayer <michaelni@gmx.at>
A few fate instances on OS/2, OpenBSD, FreeBSD and IA64 linux currently
still fail a few tests with a maxdiff of 6.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '68edd5be0980941924ae633d98589d56a8091bbd':
FATE: use proper comparison mode in the lavr tests
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The tests are disabled as 2 do not pass yet
(fate-hevc-conformance-PPS_A_qualcomm_7 and fate-hevc-conformance-RAP_A_docomo_4)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '364af376f343d4706c4cdb7ab9fe0863994e6c01':
FATE: add lavr resampling tests
The tests do not pass, and thus where disabled
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9ab5f7107d2f1411e9fda6c36af64524e5ed31d1':
FATE: add lavr mixing tests
The tests do not pass, and thus where disabled
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Here is an extract of fate-samples/sub/vobsub.idx, with an additional
text at the end of each line to better identify each bitmap:
timestamp: 00:04:55:445, filepos: 00001b000 Ace!
timestamp: 00:05:00:049, filepos: 00001b800 Wake up, honey!
timestamp: 00:05:02:018, filepos: 00001c800 I gotta go to work.
timestamp: 00:05:02:035, filepos: 00001d000 <???>
timestamp: 00:05:04:203, filepos: 00001d800 Look after Clayton, okay?
timestamp: 00:05:05:947, filepos: 00001e800 I'll be back tonight.
timestamp: 00:05:07:957, filepos: 00001f800 Bye! Love you.
timestamp: 00:05:21:295, filepos: 000020800 Hey, Ace! What's up?
timestamp: 00:05:23:356, filepos: 000021800 Hey, how's it going?
timestamp: 00:05:24:640, filepos: 000022800 Remember what today is? The 3rd!
timestamp: 00:05:27:193, filepos: 000023800 Look over there!
timestamp: 00:05:28:369, filepos: 000024800 Where are they going?
timestamp: 00:05:28:361, filepos: 000025000 <???>
timestamp: 00:05:29:946, filepos: 000025800 Let's go see.
timestamp: 00:05:31:230, filepos: 000026000 I can't, man. I got Clayton.
Note the two "<???>": they are basically split subtitles (with the
previous one), which the dvdsub decoder is now supposed to reconstruct
with a previous commit. But also note that while the first chunk has
increasing timestamps,
timestamp: 00:05:02:018, filepos: 00001c800
timestamp: 00:05:02:035, filepos: 00001d000
...it's not the case of the second one (and this is not an exception in the
original file):
timestamp: 00:05:28:369, filepos: 000024800
timestamp: 00:05:28:361, filepos: 000025000
For the dvdsub decoder, they need to be "filepos'ed" ordered, but the
FFDemuxSubtitlesQueue is timestamps ordered, which is the reason of the
introduction of a sub sort method in the context, to allow giving
priority to the position, and then the timestamps. With that change, the
dvdsub decoder get fed with ordered packets.
Now the packet size estimation was also broken: the filepos differences
in the vobsub index defines the full data read between two subtitles
chunks, and it is necessary to take into account what is read by the
mpegps_read_pes_header() function since the length returned by that
function doesn't count the size of the data it reads. This is fixed with
the introduction of total_read, and {old,new}_pos. By doing this change,
we can drop the unreliable len16 heuristic and simplify the whole loop.
Note that mpegps_read_pes_header() often read more than one PES packet
(typically in one call it can read 0x1ba and 0x1be chunk along with the
relevant 0x1bd packet), which triggers the "total_read + pkt_size >
psize" check. This is an expected behaviour, which could be avoided by
having a more chunked version of mpegps_read_pes_header().
The latest change is the extraction of each stream into its own
subtitles queue. If we don't do this, the maximum size for a subtitle
chunk is broken, and the previous changes can not work. Having each
stream in a different queue requires some little adjustments in the
seek code of the demuxer.
This commit is only meaningful as a whole change and can not be easily
split. The FATE test changes because it uses the vobsub demuxer.
