Since PTS is changed randomly for every audio frame, it matters. Also add some
forgotten filter dependencies.
Signed-off-by: Marton Balint <cus@passwd.hu>
Depending on input chunk size noticable corrpution was hearable, here is an
example command line:
ffplay -f lavfi -i "sine=440:r=8000:samples_per_frame=32,aresample=24000:filter_size=1:phase_shift=0"
Fix this by rounding the fixed point fractions up instead of down.
Signed-off-by: Marton Balint <cus@passwd.hu>
Jpeg2000 decoder is decoding in native endian, so let's use the same workaround
as in fate-mxf-probe-applehdr10.
Fixes ticket #10868.
Signed-off-by: Marton Balint <cus@passwd.hu>
The old layout happened to be a native layout and therefore missed some
recently fixed layout parsing bugs.
Signed-off-by: Marton Balint <cus@passwd.hu>
Since 7bf1b9b357,
the test produces ordinary \n, yet this is not what the reference
file used for the most time, leading to test failures.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Covers muxing from raw pcm audio input into FLAC, using several scalable layouts,
and demuxing the result.
Signed-off-by: James Almer <jamrial@gmail.com>
This is the 64bit version of Chris Doty-Humphreys SFC64
Compared to the LCGs these produce much better quality numbers.
Compared to LFGs this needs less state. (our LFG has 224 byte
state for its 32bit version) this has 32byte state
Also the initialization for our LFG is slower.
This is also much faster than KISS or PCG.
This commit replaces the broken LCG used before.
(broken as it had only a period ~200M due to being put in a double)
This changes the output from random() which is why libswresample.mak
is updated, update was done using the command in libswresample.mak
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marth64 <marth64@proxyid.net>
Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
used open source tool for processing 608/708 closed caption (CC) sources.
It can be used to archive the original, raw CC bitstream and to produce
a source file file for later CC processing or conversion. As a result,
it also allows for interopability with ccextractor for processing CC data
extracted via ffmpeg. The format is simple to parse and can be used
to retain all lines and variants of CC.
A free specification of RCWT can be found here:
https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT
This muxer implements the specification as of 01/05/2024, which has
been stable and unchanged for 10 years as of this writing.
This muxer will have some nuances from the way that ccextractor muxes RCWT.
No compatibility issues when processing the output with ccextractor
have been observed as a result of this so far, but mileage may vary
and outputs will not be a bit-exact match.
Specifically, the differences are:
(1) This muxer will identify as "FF" as the writing program identifier, so
as to be honest about the output's origin.
(2) ffmpeg's MPEG-1/2, H264, HEVC, etc. decoders extract closed captioning
data differently than ccextractor from embedded SEI/user data.
For example, DVD captioning bytes will be translated to ATSC A53 format.
This allows ffmpeg to handle 608/708 in a consistant way downstream.
This is a lossless conversion and the meaningful data is retained.
(3) This muxer will not alter the extracted data except to remove invalid
packets in between valid CC blocks. On the other hand, ccextractor
will by default remove mid-stream padding, and add padding at the end
of the stream (in order to convey the end time of the source video).
They are similar to AVIF images (both use the HEIF container).
The only additional work needed is to parse the hvcC box and put
it in the extradata.
With this patch applied, ffmpeg (when built with an HEVC decoder)
is able to decode the files in
https://github.com/nokiatech/heif/tree/gh-pages/content/images
Also add a couple of fate tests with samples from
https://github.com/nokiatech/heif_conformance/tree/master/conformance_files
Partially fixes trac ticket #6521.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The start code is matched against 0x000001, zero_byte was treated
as last byte of last frame rather than the beginning of next frame.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
