When recv() returns 0 in case of SOCK_STREAM type, it means EOF and with
this patch returns value accordingly.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Per MediaSDK documentation, it requires width/height to 16 alignment.
Without this patch, hwupload pipeline may fail if 16 alignment is
not met. Although this patch also apply 16 alignment to qsv encoder/decoder,
it will not bring any side-effect to them as they are already aligned.
Signed-off-by: Ruiling Song <ruiling.song@intel.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Allows consumers who are converting hardware buffers
to OpenGL textures to render the frames at the intended
display resolution.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
When building with libopenmpt 0.3, use the libopenmpt file header
probing functions for probing. libopenmpt probing functions are
allocation-free and designed to be as fast as possible.
For libopenmpt 0.2, or when libopenmpt 0.3 file header probing cannot
probe successfully due to too small probe buffer, test the filename
against the file extensions supported by the libopenmpt library that
is actually linked, instead of relying on a hard-coded file extension
list. File extension testing is also allocation-free and designed to
be fast in libopenmpt. Avoiding a hard-coded file extension list is
useful because later libopenmpt versions will likely add support for
more module file formats.
libopenmpt file header probing is tested regularly against the FATE
suite and other diverse file collections by libopenmpt upstream in
order to avoid false positives.
FATE passes with './configure --enable-libopenmpt' as well as with
'./configure --enable-libopenmpt --enable-libmodplug'.
libopenmpt probing adds about 5%..10% cpu time (depending on precise
usage pattern and host CPU and compiler version used for libopenmpt)
compared to all current internal FFmpeg probing functions combined in
tools/probetest for all of its module formats combined (currently 41
modules formats in libopenmpt 0.3.4 and 234 file formats in FFmpeg).
Signed-off-by: Jörn Heusipp <osmanx@problemloesungsmaschine.de>
Reviewed-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When a decoded stream is being looped, after each post-EOF rewind,
decoders are flushed in seek_to_start(). This only drains 1 frame, and
thus the output has a few frames missing at the tail of each iteration
except the last.
With this patch, process_input is looped till process_input_packet
reaches EOF.
Fixes#7081
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also fixes one potential leak of side data in out if
the av_packet_from_data() call fails.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes building with VAAPI but not libdrm, which was broken by
389f4c3e0d. Just unconditionally include
the header, since it doesn't depend on libdrm being present.
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.
The type of the result of a shift operation is unaffected by the type of
the right operand, so some existing code overflows with undefined behaviour
when the element length is 32. Add a helper macro to calculate the maximum
value correctly and then use it everywhere this pattern appears.
Found-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
In the previous implementation the first input or output device
was skipped when device_next was called with prev = NULL
Signed-off-by: Felix Matouschek <felix@matouschek.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
test extract color and alpha
with the three main kind of hap frame :
- no snappy compression
- snappy compression and one chunk
- snappy compression and several chunks (16 here)
like the bsf filter need to be used with vtag and encoder edition
also test the information of the target mov for color and alpha
If the string consists entirely of whitespace, this could in theory
continue to write '\0' before the start of the memory allocation. In
practice, it didn't really happen: the generic HTTP header parsing code
already skips leading whitespaces, so the string is either empty, or
consists a non-whitespace. (The generic code and the cookie code
actually have different ideas about what bytes are whitespace: the
former uses av_isspace(), the latter uses WHITESPACES. Fortunately,
av_isspace() is a super set of the http.c specific WHITESPACES, so
there's probably no case where the above assumption could have been
broken.)
It's trivial to craft a HTTP response that will make the code for
skipping trailing whitespace access and possibly overwrite bytes outside
of the memory allocation. Why this can happen is blindingly obvious: it
accesses cstr[strlen(cstr)-1] without checking whether the string is
empty.
libavformat prints a warning that the cookie couldn't be parsed (see
callers of parse_cookie()). This is obviously not true - it could be
parsed, but was simply ignored. Don't return an error to avoid the
warning.
This adds a way for an API user to transfer QP data and metadata without
having to keep the reference to AVFrame, and without having to
explicitly care about QP APIs. It might also provide a way to finally
remove the deprecated QP related fields. In the end, the QP table should
be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
There are two side data types, because I didn't care about having to
repack the QP data so the table and the metadata are in a single
AVBufferRef. Otherwise it would have either required a copy on decoding
(extra slowdown for something as obscure as the QP data), or would have
required making intrusive changes to the codecs which support export of
this data.
The new side data types are added under deprecation guards, because I
don't intend to change the status of the QP export as being deprecated
(as it was before this patch too).
Everything related to the QP data is deprecated, with qp_table_buf being
an inconsistent exception. Some parts were under the deprecation guards,
some not. It probably didn't even compile.
