* commit '18dc1ff0fb4572b1d50a44905aa1e76bc3bbb0ad':
configure: Add check_ld() helper function to simplify some expressions
Merged-by: James Almer <jamrial@gmail.com>
The protocol requires libsrt (https://github.com/Haivision/srt) to be
installed
Signed-off-by: Sven Dueking <sven.dueking@nablet.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This crash was introduced by 8bbf2dacbf,
which could incorrectly overwrite the failure result from creating the
device.
Fixes ticket #7108.
Reviewed-by: wm4 <nfxjfg@googlemail.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>
av_strtok calls strspn on a non-NULL *saveptr, so not NULL initializing
it is an issue.
Fixes CID #1428568
Reviewed-by: Karthick Jeyapal <kjeyapal@akamai.com>
Signed-off-by: Steven Liu <lq@onvideo.cn>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
The output frame size is larger than the image containing a subsampled
plane - use the actual size of the image being written rather than the
dimensions of the intended output frame.
Reviewed-by: Dylan Fernando <dylanf123@gmail.com>
Streams from a Segafilm cpk file can't be streamcopied because
keyframe flag isn't correctly set in stream index and
said flag is never conveyed to the packet
Fixes#7091
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Similar indirections are used for the -o compiler/assembler flag to
account for differences in compiler/assembler syntax. For x86asm half
the infrastructure for doing the same currently exists unused.
Finish and use that infrastructure for consistency.
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.)
Enables having proper bit rate values being written into the master
playlist in case of hard-constrained VBR where the maximum bit
rate utilized is known before hand.
Does the same thing as movenc.c, for example.
Signed-off-by: Jan Ekström <jan.ekstrom@aminocom.com>
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>
There's no need to allocate a new packet for it.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
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>
Should prevent unnecessary copy of data in cases where new references
to the packet are created within the muxer or a bitstream filter.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
It's been a noop for years, and it's been argued that in-band headers
should not be forcedly removed without the user's explicit request.
Also, as the FIXME line stated, this is a job for a bitstream filter
like extract_extradata, remove_extradata, dump_extradata, and
filter_units.
Signed-off-by: James Almer <jamrial@gmail.com>
