The change introduced in b18a9c2971
created a regression for non-subsampled progressive RGB jpegs. This
should fix that.
Additionally, this should fix other RGB JPEGs broken before the recent
patches, such as those in Trac issue #10190.
When enable lcms2, the fate-png-icc-parse will get error bellow.
TEST png-icc-parse
This because updated how PNG handles colors (no
longer using mastering display metadata for that).
Reviewed-by: Leo Izen <leo.izen@gmail.com>
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
The decoder is tagged as being FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM, so might as
well make use of it.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Also remove the _plus* and _minus* parts of some of these to be in line with
other similar fields in the decoder.
Signed-off-by: James Almer <jamrial@gmail.com>
The spec says: "The value of num_ref_loc_offsets shall be in the range of 0 to
vps_max_layers_minus1, inclusive".
Signed-off-by: James Almer <jamrial@gmail.com>
Remove now-obsolete code setting packet durations pre-muxing for CFR
encoded video.
Changes output in the following FATE tests:
* numerous adpcm tests
* ffmpeg-filter_complex_audio
* lavf-asf
* lavf-mkv
* lavf-mkv_attachment
* matroska-encoding-delay
All of these change due to the fact that the output duration is now
the actual input data duration and does not include padding added by
the encoder.
* apng-osample: less wrong packet durations are now passed to the muxer.
They are not entirely correct, because the first frame duration should
be 3 rather than 2. This is caused by the vsync code and should be
addressed later, but this change is a step in the right direction.
* tscc2-mov: last output frame has a duration of 11 rather than 1 - this
corresponds to the duration actually returned by the demuxer.
* film-cvid: video frame durations are now 2 rather than 1 - this
corresponds to durations actually returned by the demuxer and matches
the timestamps.
* mpeg2-ticket6677: durations of some video frames are now 2 rather than
1 - this matches the timestamps.
A single smvjpeg packet decodes into one large mjpeg frame, slices of
which are then returned as output frames. Packet duration covers all of
these slices.
Current code prefers deprecated AVFrame.pkt_duration over its
replacement AVFrame.duration whenever the former is set and not equal to
the latter. However, duration will only be actually used when the
caller sets the AV_CODEC_FLAG_FRAME_DURATION flag, which was added
_after_ AVFrame.duration.
This implies that any caller aware of AV_CODEC_FLAG_FRAME_DURATION is
also aware of AVFrame.duration. pkt_duration should then never be used.
Commit b18a9c2971 introduced a regression
that broke some baseline RGB jpegs. (See Trac issue #4045). This fixes
that.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
That field was added to store timestamp conversion state for audio
decoding code. Later it started being used by streamcopy as well, but
that use is wrong because, for a given input stream, both decoding and
an arbitrary number of streamcopies may be performed simultaneously.
They would then all overwrite the same state variable.
Store this state in MuxStream instead.
This is the last use of InputStream in of_streamcopy(), so the ist
parameter can now be removed.
It stores codec parameters of the stream submitted to the muxer, which
may be different from the codec parameters in AVStream due to bitstream
filtering.
This avoids the confusing back and forth synchronisation between the
encoder, bitstream filters, and the muxer, now information flows only in
one direction. It also reduces the need for non-muxing code to access
AVStream.
Reduces access to a deeply nested muxer property
OutputStream.st->codecpar->codec_type for this fundamental and immutable
stream property.
Besides making the code shorter, this will allow making the AVStream
(OutputStream.st) private to the muxer in the future.
Set InputStream.decoding_needed/discard/etc. only from
ist_{filter,output},add() functions. Reduces the knowledge of
InputStream internals in muxing/filtering code.
init_input_stream() can print log messages directly, there is no need to
ship them to the caller.
Also, log errors to the InputStream and avoid duplicate information in
the message.
Changing AVCodecContext.sample_aspect_ratio after the encoder was opened
is by itself questionable, but if anywhere it belongs in encoding rather
than filtering code.
Creating a new output stream of a given type is currently done by
calling new_<type>_stream(), which all start by calling
new_output_stream() to allocate the stream and do common init, followed
by type-specific init.
Reverse this structure - the caller now calls the common function
ost_add() with the type as a parameter, which then calls the
type-specific function internally. This will allow adding common code
that runs after type-specific code in future commits.
Leo Izen
James Almer
Steven Liu
Paul B Mahol
Anton Khirnov
Ronald S. Bultje
Michael Niedermayer