This made the output non binary reproducible across different versions of
zlib.
This reverts commit bce5855afb.
Signed-off-by: James Almer <jamrial@gmail.com>
The demuxer's 'missing_streams' private option is used to communicate
information from the demuxer to avformat_find_stream_info(). However,
that is not only unnecessarily complicated, it also leaks internal
information to users, e.g. this option appears in the results of the
fate-flv-demux test.
Use a new field in FFFormatContext to communicate this information
instead.
stddev and PSNR values change by the removal of format conversion and because
of the added sws_flags. Either or will have the same effect even on their own.
Signed-off-by: James Almer <jamrial@gmail.com>
This format is useful for doing certain lossless transforms on images,
RCT in particular, which require you to escalate the size from 16 to
32 bits to avoid overflows.
APIchanges will be done alongside when comitting.
FATE results differ when using the original zlib and zlib-ng.
Since we don't need to test the result from zlib itself, this commit
disables compression on tests for zlib-based codecs, which ends up
giving the same results with both libraries.
Signed-off-by: James Almer <jamrial@gmail.com>
md5 values change because the nut container now reports rawvideo as encoder
and Y410 as codec type instead of the bogus RGB[15].
Signed-off-by: James Almer <jamrial@gmail.com>
There's no need to keep using a custom decoder for this pixel format.
md5 values change because the nut container now reports rawvideo as encoder.
Signed-off-by: James Almer <jamrial@gmail.com>
There's no need to keep using a custom decoder for this pixel format.
md5 values change because the nut container now reports rawvideo as encoder.
Signed-off-by: James Almer <jamrial@gmail.com>
There's no need to keep using a custom decoder for this pixel format.
md5 values change because the nut container now reports rawvideo as encoder.
Signed-off-by: James Almer <jamrial@gmail.com>
This fixes an 11-year-old bug in the rgb2xyz functions, when used with a
negative stride. The current loop bounds turned it into a no-op.
Additionally, this increases performance on highly cropped images, whose
stride may be substantially higher than the effective width.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This code uses no encoder properties or state besides its name, and is
mostly muxer logic, and thus belongs more properly into the muxer.
The results of several test change due to different metadata tag order
(the "encoder" tag is now set first).
Only those that can be decoded with our implementation, so excluding
* C and D - independent layers
* G, H, I - more than 2 layers
Frame hashes verified against the reference implementation from
https://hevc.hhi.fraunhofer.de/svn/svn_3DVCSoftware/
The test constructs 66 sine waves of different frequencies and joins
them into a 7th order ambisonic layout with extra non-diegetic
stereo. The channels are then shifted circularly with channelmap and
separated into individual streams for muxing with channelsplit.
Note that the last step is necessary because swr is not capable of
interleaving planar to packed for more than 64 channels, which would be
necessary to mux such a stream as PCM.
Fix "ost->st->avg_frame_rate = ost->frame_rate" in streamcopy_init()
being reset to input's frame rate a few lines below.
Note that in current code, there are some discrepancies amongst the
muxers. For example, avienc relies on time_base, so it is not affected
by this patch, whereas mxfenc and matroskaenc do use avg_frame_rate,
so this patch fixes -r being honored.
In the updated fate test, the input is (wrongly) probed as 50fps. With
this patch, the correct value (25fps) is successfully forced with -r.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The time_base was a bad guess.
Currently, fate-time_base test data assumed that overriding the input
time_base would affect the frame_rate, but this behaviour is not
documented, so just fix the fate data now that this is fixed.
Fix regression since 10185e2d4c:
previously, when streamcopying, the time_base was guessed from the
frame_rate considering it is often constant, so guessing the frame_rate
back from the time_base was often not a problem.
To reproduce:
ffmpeg -i fate-suite/mpeg2/dvd_still_frame.vob -an -c copy out.mxf
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Replace the manually specified chroma location by one using standard
notation, arbitrarily "bottomleft" as it is a less common path.
Required if we want to phase out the use of manual chroma locations.
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references the SPS, the SPS/PPS
needs to come first.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This test confirms that we can write mDCv and cLLi chunks and read them
back via the png decoder. It uses an HEVC conformance sample with this
metadata as the base source for the side data in the frames.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Jan Ekström <jeebjp@gmail.com>
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
