It's a common usecase to request a video size after crop. Before
this patch, user must know the video size before crop, then set
crop_right/crop_bottom accordingly. Since HEVC can have different
CTU size, it's not easy to get/deduce the video size before crop.
With the new width/height options, there is no such requirement.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This BSF is supposed to be used in conjunction with mp3_header_compress,
which has been removed more than ten years ago in commit
c6080d8900. It mangled the headers
by removing the CRC field as well as fields that are supposed
to stay constant for the entirety of a stream (which are put into
extradata). This made these files unplayable; they need to be
decompressed with the BSF first (which does not happen automatically).
Even in this case the CRC does not get restored.
I am not aware that such compressed files exist at all; therefore
this commit removes the BSF completely.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is no check for whether these supposedly redundant PPS
are actually redundant. One could check via memcmp which would
work in practice* (because all content buffers are initially
zero-allocated), but this is not portable as compilers may
trash padding inside structures as they wish.
In case the PPS is not really redundant the output is garbage.
This happens with several files from the FATE-suite. E.g.
h264-conformance/CVCANLMA2_Sony_C.jsv doesn't decode correctly
any more, whereas h264-conformance/CABA3_TOSHIBA_E.264 even
fails in ff_cbs_write_packet(), because the inferred value
of num_ref_idx_l0_active_minus1 mismatches with the value set
in the slice (this happens when num_ref_idx_l0_default_active_minus1
changes in the PPS; the value in the slice header is inferred from
the original PPS's num_ref_idx_l0_default_active_minus1).
*: Unless slice_group_id is used, i.e. unless slice_group_map_type
is six.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Required to remux m2ts to mkv
Minor changes and porting to FFBitStreamFilter done by the committer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They correspond to the relevant fields from the packet that follows the
one where the expressions are being applied.
Signed-off-by: James Almer <jamrial@gmail.com>
Users may take the description literally which leads to inverted
results.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: Jun Zhao <barryjzhao@tencent.com
These bits are reserved in earlier versions of the H.264 spec, and
some poor hardware decoders require they are zero. Thus, it is useful
to be able to zero these on streams that may have them set. The result
is still a valid H.264 bitstream.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
It's based on the following specs:
RDD 45:2017 - SMPTE Registered Disclosure Doc - Interoperable Master Format - Application ProRes
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
It's based on the following specs:
RDD 36:2015 - SMPTE Registered Disclosure Doc - Apple ProRes Bitstream Syntax and Decoding Process
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
The earlier version had three deficits:
1. It allowed to set the stream to RGB although this is not allowed when
the profile is 0 or 2.
2. If it set the stream to RGB, then it did not automatically set the
range to full range; the result was that one got a warning every time a
frame with color_config element was processed if the frame originally
had TV range and the user didn't explicitly choose PC range. Now one
gets only one warning in such a situation.
3. Intra-only frames in profile 0 are automatically BT.601, but if the
user wished another color space, he was not informed about his wishes
being unfulfillable.
The commit also improves the documentation about this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The dump_extra bitstream filter currently simply adds the extradata to
the packets indicated by the user without checking whether said
extradata already exists in the packets. Besides wasting space
duplicated extradata in the same packet/access unit is also forbidden
for some codecs, e.g. MPEG-2.
This check has been added to be able to use the mpeg2_qsv encoder (which
only adds the sequence headers to the first packet) in broadcast
scenarios where repeating sequence headers are required.
The check used here is not perfect: E.g. dump_extra would add the
extradata to a H.264 access unit consisting of an access unit delimiter,
SPS, PPS and slices.
Fixes#8007.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The default is to dump extradata to keyframes, not all frames.
Also improve the description of the relevant AVOption.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This can remove units with types in or not in a given set from a stream.
For example, it can be used to remove all non-VCL NAL units from an H.264 or
H.265 stream.
Update dump_extra bit stream filter docs to follow current
code implement.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Reviewed-by: Steven Liu <lq@onvideo.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
documents delete_filler option for bsf h264_metadata.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This applies a specific fixup to some Blu-ray streams which contain
redundant PPSs modifying irrelevant parameters of the stream which
confuse other transformations which require correct extradata.
A new single global PPS is created, and all of the redundant PPSs
within the stream are removed.
(cherry picked from commit e6874bc3af)
