* commit '7b3214d0050613bd347a2e41c9f78ffb766da25e':
lavc: add a field for passing AVHWFramesContext to encoders
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Doing slice_end - slice_start is unsafe and can lead to undefined behavior
until slice_end has been properly sanitized.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanag@gmail.com>
This allows to copy information related to the stream ID from the demuxer
to the muxer, thus allowing for example to retain information related to
synchronous and asynchronous KLV data packets. This information is used
in the muxer when remuxing to distinguish the two kind of packets (if the
information is lacking, data packets are considered synchronous).
The fate reference changes are due to the use of
av_packet_merge_side_data(), which increases the size of the output
packet size, since side data is merged into the packet data.
with older versions of libvpx
since:
432be63 lavc/libvpx: Fix support for RGB colorspace.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Zern <jzern@google.com>
The reference encoder limits it to 64, but testing revealed that there
is absolutely no difference for indices above 50 in amount of zeroed
coefficients.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit adds support for the (simple, allowed in the spec, but
inferior in quality) Haar wavelet transforms.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
control codes in a cc stream can be repeated, and must be ignored.
however, repeated characters must not be ignored. the code attempted to
wipe prev_cmd in handle_char to allow repeated characters to be
processed, but prev_cmd would previously get reset _after_ handle_char()
i also moved the prev_cmd reset out from handle_char() so it can be
re-used for special character sets, which _must_ be ignored when
repeated.
Similar to how the AAC encoder does it.
0 means the video's been compressed losslessly/almost losslessly
thoughout. Generally, the higher, the worse.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Fixes harmless integer overflow
Fixes Ticket5150
No speedloss measured, actually its slightly faster, but please benchmark & double check this
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
VLC uses hwaccel with frame threads and it works fine, but returning
an error here made it fail.
This regression was introduced in commit 31741ae.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Warning message text by nevcairiel
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add support for parsing SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into
the AVMasteringDisplayMetadata side data. Primaries are ordered in RGB order and
the values are converted to rationals ([0,1] for CEI 1931 Chroma coords,
and cd/m^2 for luma).
Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Today, we track the short term RPS size for DXVA, but only if the
SliceHeader RPS is being used. Otherwise it's left uninitialized.
NVIDIA's VDPAU implementation requires that the size be accurately
tracked even if an SPS RPS is being used. In this case, it's really
counting the size of the RPS idx information, but you end up with
mangled output if the value is not accurate.
VDPAU also needs the size of the long term RPS.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
ucNumDeltaPocsOfRefRpsIdx needs to contain the flat value from the SPS RPS,
and not the final computed value from the slice header RPS, as this calculation
is done internally by the driver again.
Sample-Id: http://trailers.divx.com/hevc/Sintel_4k_27qp_24fps_1aud_9subs.mkvi
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
