With pre-2.0 Intel drivers in CBR mode, if an explicit SEI message with
the old (now deprecated) type is not included, the driver generates and
inserts some timing SEI which is almost certainly invlaid. Before
7a4fac5e91 we always inserted our own SEI
so this would not be visible, but since then it has been possible to
disable that. We would also like to avoid using the deprecated type,
and using the new type, while working in old drivers, does not suppress
the spurious message like the old type does.
Therefore, suppress the bad SEI insertion by providing a zero-length
buffer with the old type, which the driver can insert harmlessly.
This is an ABI change in libva2: previously the Intel driver had this
behaviour and it was implemented as a driver quirk, but now it is part
of the specification so all drivers must do it.
This has been deprecated in libva2 because hardware does not and will not
support it. Therefore never consider it for decode, and for encode assume
the user meant constrained baseline profile instead.
Use the appropriate metadata filter for each codec - in the absence of any
options to modify the stream, the output bitstream should be identical to
the input (though the output file may differ in padding).
All tests use conformance bitstreams, the MPEG-2 streams are newly added
from the conformance test streams
<http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_13818-4_2004_Conformance_Testing/Video/>
Whether the udu string should be freed depends on whether the SEI it
gets added to was created internally by cbs or externally by the bsf.
The current code frees it twice in the former case.
Since there is no information about the source format, "unspecified"
is the correct value to write here.
All tests using the MPEG-2 encoder are updated, as this changes the
header on all outputs.
It is not necessary to pad to the CTU size. The CB size of 8x8 should be
sufficient, but due to constraints in the Intel driver (the one usable
implementation of this) it has to be padded to 16x16 like in H.264.
This applies a specific fixup to some Bluray 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.
Use AVCodecContext.compression_level rather than a private option,
replacing the H.264-specific quality option (which stays only for
compatibility).
This now works with the H.265 encoder in the i965 driver, as well as
the existing cases with the H.264 encoder.
Add comments to describe the sources of the constraint values expressed here,
and add some more related values which will be used in following patches.
Fix the incorrect values for SPS and PPS count (they are not the same as those
used for H.264), and remove HEVC_MAX_CU_SIZE because it is not used anywhere.
This is something of a hack. It allocates a new hwframe context for
the target format, then maps it back to the source link and overwrites
the input link hw_frames_ctx so that the previous filter will receive
the frames we want from ff_get_video_buffer(). It may fail if
the previous filter imposes any additional constraints on the frames
it wants to use as output.
Use the flags argument of av_hwframe_ctx_create_derived() to pass the
mapping flags which will be used on allocation. Also, set the format
and hardware context on the allocated frame automatically - the user
should not be required to do this themselves.
Some frames contexts are not usable without additional format-specific
state in hwctx. This change adds new functions frames_derive_from and
frames_derive_to to initialise this state appropriately when deriving
a frames context which will require it to be set.
This only supports one device globally, but more can be used by
passing them with input streams in hw_frames_ctx or by deriving new
devices inside a filter graph with hwmap.
If -hwaccel foo is supplied without any other device options, and the
foo hwaccel is meant to have a device, try to make such a device with
default parameters for the hwaccel to use.
This was left over from an earlier version which created the new
packet inside the current frame structure. Now it just leaks an
unused packet, so remove the allocation entirely.
The non-H.26[45] codecs already use this form. Since we don't
currently generate I frames for codecs which support them separately
to IDR, the p_per_i variable is set to infinity by default so that it
doesn't interfere with any other calculation. (All the code for I
frames still exists, and it works for H.264 if set manually.)
Takes a raw input stream containing frames with correct timestamps but
possibly out of order and inserts additional show-existing-frame
packets to correct the ordering.
In order to work correctly with the i965 driver, this also fixes the
direction of forward/backward references - forward references are
intended to be those from the past to the current frame, not from the
current frame to the future.
Adds functions to convert to/from strings and a function to iterate
over all supported device types. Also adds a new invalid type
AV_HWDEVICE_TYPE_NONE, which acts as a sentinel value.
This was broken by 4e528206bc - the webp
decoder was assuming that it could set the output pixfmt of the vp8
decoder directly, but after that change it no longer could because
ff_get_format() was used instead. This adds an internal get_format()
callback to webp use of the vp8 decoder to override the pixfmt
appropriately.
The Intel proprietary VAAPI driver enforces the restriction that a
buffer must be created inside an existing context, so just ensure
this is always true.
If the stream timebase is coarser than the muxing timebase then the
monotonisation process may fail because adding one to the timestamp
need not actually produce a different timestamp after the rescale.
The driver is somewhat bitrotten (not updated for years) but is still
usable for decoding with this change. To support it, this adds a new
driver quirk to indicate no support at all for surface attributes.
Based on a patch by wm4 <nfxjfg@googlemail.com>.
The string codec name need not be as long as the value we are
comparing it to, so memcmp may make decisions derived from
uninitialised data that valgrind then complains about (though the
overall result of the function will always be the same). Use
strncmp instead, which will stop at the first zero byte and
therefore not encounter this issue.
Only do this when building for a recent VAAPI version - initial
driver implementations were confused about the interpretation of the
framerate field, but hopefully this will be consistent everywhere
once 0.40.0 is released.
Default to using VBR when a target bitrate is set, unless the max rate
is also set and matches the target. Changes to the Intel driver mean
that min_qp is also respected in this case, so set a codec default to
unset the value rather than using the current default inherited from
the MPEG-4 part 2 encoder.
Mark Thompson