Initially, avcodec/srtenc.c was outputting CRLF [1]. Later, a real SRT
muxer was added [2], which outputs LF. The original srtenc.c was
converted to use the muxer [3], changing its output to LF, except for
newline characters within subtitle text.
Fix this to avoid producing SRT files with mixed line endings.
[1] 8e43b6fed9
[2] 9e63c30daa
[3] 55180b3299
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This was introduced in commit 9c43703, to support a codec "extension"
in the prores_aw encoder.
This removes the chroma fill loop, and instead performs the inverse
transform on null coefficients, which achieves the same result and
fixes an off-by-one in the chroma values produced.
Updated test to reflect this change.
The first sample in the stsc box may not refer to the first stsd entry.
This is the case in h264/thezerotheorem-cut.mp4, and as such the
fate-h264_redundant_pps-side_data test is updated accordingly.
Signed-off-by: James Almer <jamrial@gmail.com>
The new logic should be easier to follow.
It also uses ff_inlink_consume_frame() for all simple passthrough operations
making custom get_audio_buffer callback unnecessary.
Fate changes are because the new logic does not repacketize input audio up
until the crossfade. Content is the same.
Signed-off-by: Marton Balint <cus@passwd.hu>
- Changes in mov_write_video_tag function to handle APV elementary stream
- Provided structure APVDecoderConfigurationRecord that specifies the decoder configuration information for APV video content
Co-Authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>
Signed-off-by: James Almer <jamrial@gmail.com>
A frame graph activation might not produce a frame in the requested sink, so
keep on requesting a frame there unless we encounter a filter activation with
buffersrc empty error.
This makes av_buffersink_get_frame(_flags) work according to its documentation
which claims that EAGAIN is only returned if additional frames must be inserted
into the graph.
Fate changes are because audio frames will have different sizes at segment
boundaries, but content is the same.
Signed-off-by: Marton Balint <cus@passwd.hu>
The way streams are coded in an IAMF struct follows a scalable model where the
channel layouts for each layer may not match the channel order our API can
represent in a Native order layout.
For example, an audio element may have six coded streams in the form of two
stereo streams, followed by two mono streams, and then by another two stereo
streams, for a total of 10 channels, and define for them four scalable layers
with loudspeaker_layout values "Stereo", "5.1ch", "5.1.2ch", and "5.1.4ch".
The first layer references the first stream, and each following layer will
reference all previous streams plus extra ones.
In this case, the "5.1ch" layer will reference four streams (the first two
stereo and the two mono) to encompass six channels, which does not match out
native layout 5.1(side) given that FC and LFE come after FL+FR but before
SL+SR, and here, they are at the end.
For this reason, we need to build Custom order layouts that properly represent
what we're exporting.
----
Before:
Stream group #0:0[0x12c]: IAMF Audio Element:
Layer 0: stereo
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Layer 1: 5.1(side)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Layer 2: 5.1.2
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Layer 3: 5.1.4
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:5[0x5]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
----
AFter:
Stream group #0:0[0x12c]: IAMF Audio Element:
Layer 0: stereo
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Layer 1: 6 channels (FL+FR+SL+SR+FC+LFE)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Layer 2: 8 channels (FL+FR+SL+SR+FC+LFE+TFL+TFR)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Layer 3: 10 channels (FL+FR+SL+SR+FC+LFE+TFL+TFR+TBL+TBR)
Stream #0:0[0x0]: Audio: opus, 48000 Hz, stereo, fltp (default)
Stream #0:1[0x1]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:2[0x2]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:3[0x3]: Audio: opus, 48000 Hz, mono, fltp (dependent)
Stream #0:4[0x4]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Stream #0:5[0x5]: Audio: opus, 48000 Hz, stereo, fltp (dependent)
Signed-off-by: James Almer <jamrial@gmail.com>
Follows the proper order defined by the spec, even if mostly cosmetic, and is
also preparation for a following change.
Signed-off-by: James Almer <jamrial@gmail.com>
Tests both the Media 100 decoder (using the media100_to_mjpegb BSF
implicitly) as well as using said BSF, followed by the MJPEGB decoder.
(We currently hit a bug when remuxing: The demuxer treats compressorname
as encoded in a Mac character encoding (Mac OS Roman?) and converts
it to UTF-8, yet the muxer just writes it.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows detecting changes and regressions in side data related code, same as what
framecrc does for before already for packet data itself.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
As described in section F.6.1 from ETSI TS 102 366.
Found-by: nyanmisaka
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Improves compatibility with Resolume products by adding an additional
hashtable for DXT color+LUT combinations, and padding the DXT texture
dimensions to the next largest multiple of 16. Produces identical
packets to Resolume Alley in manual tests.
Signed-off-by: Emma Worley <emma@emma.gg>
Up until now, our muxer wrote FFV1 in video-for-windows
compatibility mode out of concern for old demuxers that
only support that (whereas the demuxer accepts V_FFV1).
This commit switches to using native mode, because
a) V_FFV1 is around long enough so that old demuxers
should not be an issue (support in FFmpeg has been added
in commit 9ae762da7e
in March 2017/FFmpeg 3.3),
b) using native mode uses fewer bytes for the CodecPrivate,
c) the VfW extradata is zero-padded to an even length
if necessary, but our demuxer forgot to undo the padding
until very recently (92e310eb82),
so that there are many versions of our demuxer around that
are buggy wrt VFW, but not V_FFV1.
This affects the FFV1 extradata checksums, specifically
the (experimental) version 4 files with error check version 2*
as created by
ffmpeg -i ../fate-suite/mpeg2/sony-ct3.bs -c:v ffv1 \
-slices 16 -frames 1 -level 4 -strict experimental ffv1.mkv
VFW files like the above created by this muxer before this patch
would not work with an old demuxer.
*: Without error check version 2, the CRC for the whole extradata
is zero, which is not changed by appending a zero byte.
Reviewed-by: compn <ff@hawaiiantel.net>
Reviewed-by: Dave Rice <dave@dericed.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The structure is padded to an even length with an internal
size field to indicate the real size.
The matroska-matroska-display-metadata test (writing FFV1
in VFW mode) was affected by this.
It should also fix ticket #11613.
Reviewed-by: compn <ff@hawaiiantel.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't use a 7.1 EAC3 input file for which our decoder is not
bitexact; instead just use the asynth-44100-8.wav file
which (as a 7.1 file) exhibits the same issue fixed by
1b3f4842c1.
(Either the encoder or the resampler are still not completely
bitexact, so we limit the number of frames output.)
Also switch to a framecrc test so that the output channel layout
is directly contained in the ref file.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The file has buggy timestamps (it uses B-frames, yet pts==dts)
and therefore the last frame is currently discarded by FFmpeg cli.
Using -fps_mode passthrough avoids this and provides coverage
of the SVQ3 draining logic.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
I have several .ts captures where video and audio codec changes even
though the PMT version does not change and the PIDs stay the same.
This happens during transition to/from slate (mpeg2 video and audio)
to network broadcast (hevc video and eac3 audio in private PES).
I've updated fate ts-demux expected results.
Bitstream generated using the reference encoder, then edited to fix the
colour description and an extra metadata block added. FFmpeg decoder
output is identical to the reference decoder output.
The content used is the first three frames of "Waterfall" from the SVT
Open Content Video Test Suite 2022. This is copyright Sveriges
Television AB and is used under the Creative Commons Attribution 4.0
International License.
It is unnecessary, as we already have the entries sorted by
probability and therefore implicitly by length. All we need
on top of that to build the tree is the number of entries
of a given length.
Doing so gives a 3.6% speedup of ff_mjpeg_encode_huffman_close()
here; it also saves about 640B of .text here.
The new code puts values with higher probability to the left
of the tree. The old code did not and therefore
the FATE checksums needed to be updated. Due to MJPEG's
0xFF unescaping file sizes as well as file checksums
needed to be updated; the decoded picture hashes stayed
the same. Given that codes on the left of the tree have
on average fewer bits set than codes on the right, the
file sizes mostly improve (all except vsynth3-mjpeg-444).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A sample with a particular partitioning structure that could not be read
correctly before 26c5d8cf5d
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
this is a good compromise between speed and compression
-rw-r----- 1 michael michael 180987 Feb 6 14:29 lena-def.png
-rw-r----- 1 michael michael 128430 Feb 6 14:36 lena-pavg.png
-rw-r----- 1 michael michael 126269 Feb 6 14:36 lena-pmixed.png
-rw-r----- 1 michael michael 180987 Feb 6 14:35 lena-pnone.png
-rw-r----- 1 michael michael 127758 Feb 6 14:35 lena-ppaeth.png
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
