avdevice_register_all() is still required to register devices into
lavf (this is required due to lavd being somewhat of a hack).
Signed-off-by: Josh de Kock <josh@itanimul.li>
example:
AVPixelFormat pixFmts[] = { AV_PIX_FMT_RGB24, AV_PIX_FMT_RGBA };
int loss = 0;
AVPixelFormat best = avcodec_find_best_pix_fmt_of_list(pixFmts, AV_PIX_FMT_BGRA, 1, &loss);
best is AV_PIX_FMT_RGB24. But AV_PIX_FMT_RGBA is better.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
On modern x86 systems its around 2x faster. For systems without
FPUs it'll be slower, but our policy is to prefer floating point
implementations and to let users decide what's best (or just not
compile them on systems without FPUs).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This avoids mixing 8bit variants with pro and 10bit with non pro mode.
Fixes: out of array read
Fixes: poc_03_30.avi
Found-by: GwanYeong Kim <gy741.kim@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When targeting darwin, clang requires commas between arguments,
while the no-comma form is allowed for other targets.
Since Xcode 9.3, the bundled clang supports altmacro and doesn't
require using gas-preprocessor any longer.
Signed-off-by: Martin Storsjö <martin@martin.st>
Clang supports the macro expansion counter (used for making unique
labels within macro expansions), but not when targeting darwin.
Convert uses of the counter into normal local labels, as used
elsewhere.
Since Xcode 9.3, the bundled clang supports altmacro and doesn't
require using gas-preprocessor any longer.
Signed-off-by: Martin Storsjö <martin@martin.st>
When targeting darwin, clang requires commas between arguments,
while the no-comma form is allowed for other targets.
Since Xcode 9.3, the bundled clang supports altmacro and doesn't
require using gas-preprocessor any longer.
Signed-off-by: Martin Storsjö <martin@martin.st>
See the earlier fix for movtextdec for details. The equivalent bug is
present on the encoder side as well.
We need to track the text length in 'characters' (which seems to really
mean codepoints) to ensure that styles are applied across the correct
ranges.
Main Profile is yuv420p 8 and 10 bit
High Profile is yuv444p 8 and 10 bit
Professional Profile is yuv422p 8, 10, and 12 bit, plus every other pixfmt at 12 bit
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '43778a501f1bfbceeddc8eaeea2ea2b3506beeda':
Support AV1 encoding using libaom
This contains some extra changes taken from the libvpx encoder
wrapper, most of them contained in the set_pix_fmt() function.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c438899a706422b8362a13714580e988be4d638b':
Add AV1 video decoding support through libaom
This contains some extra changes taken from the libvpx decoder
wrapper, most of them contained in the set_pix_fmt() function.
Merged-by: James Almer <jamrial@gmail.com>
Zero sized packets are already handled below in the function.
This is more in line with av_packet_ref().
Signed-off-by: James Almer <jamrial@gmail.com>
Subtitles which contained styled UTF-8 subtitles (i.e. not just 7 bit
ASCII characters) were not handled correctly. The spec mandates that
styling start/end ranges are in "characters". It's not quite clear what
a "character" is supposed to be, but maybe they mean unicode codepoints.
FFmpeg's decoder treated the style ranges as byte idexes, which could
lead to UTF-8 sequences being broken, and the common code dropping the
whole subtitle line.
Change this and count the codepoint instead. This also means that even
if this is somehow wrong, the decoder won't break UTF-8 sequences
anymore. The sample which led me to investigate this now appears to work
correctly.
This is for applications which want to explicitly check for invalid
UTF-8 manually, and take actions that are better than dropping invalid
subtitles silently. (It's pretty much silent because sporadic avcodec
error messages are so common that you can't reasonably display them in a
prominent and meaningful way in a application GUI.)
This reverts commit 7a02b364b6.
The packet fetched by ff_bsf_get_packet() and ff_bsf_get_packet_ref()
is now guaranteed to be reference counted.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This new side-data will contain info on how a packet is encrypted.
This allows the app to handle packet decryption.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some bitstream filters may buffer said packet in their own contexts
for latter use. The documentation for av_bsf_send_packet() doesn't
forbid feeding it non-reference counted packets, which depending on
the way said packets were internally buffered by the bsf it may
result in the data described in them becoming invalid or unavailable
at any time.
This was the case with vp9_superframe after commit e1bc3f4396, which
was then promptly fixed in 37f4a093f7 and 7a02b364b6. It is still the
case even today with vp9_reorder_raw.
With this change the bitstream filters will not have to worry how to
store or consume the packets fed to them.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Based on hevc_parser code. This prevents repeated unnecessary allocations
and frees on every packet processed by the bsf.
Reviewed-by: Jun Zhao <mypopydev@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Nothing currently guarantees that the packet passed to the bsf will
be writable.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
