Last segment indicated by mpd is not parsed.
Example stream: http://dash.akamaized.net/dash264/TestCasesIOP41/LastSegmentNumber/1/manifest_last_segment_num.mpd

This patch supports parsing of Supplemental Descriptor with @schemeIdUri set to http://dashif.org/guide-
lines/last-segment-number with the @value set to the last segment number.
Reviewed-by: Steven Liu <lq@onvideo.cn>

This crash was introduced by 8bbf2dac,
which could incorrectly overwrite the failure result from creating the
device.

Fixes ticket #7108.
Reviewed-by: wm4 <nfxjfg@googlemail.com>

Fixes CID1415951
Reviewed-by: Jun Zhao <mypopydev@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Jun Zhao <mypopydev@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-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>

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>

Makes kmsgrab visible in "ffmpeg -devices".
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

Fixes Coverity CID 1430382.

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>

Behaves like existing convolution filter.
Signed-off-by: Mark Thompson <sw@jkqxz.net>

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>

Fixes ticket #7074
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes ticket #7075
Signed-off-by: James Almer <jamrial@gmail.com>

Forward error codes where possible.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@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.)

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>

Fixes Coverity CID 1419523.
Signed-off-by: Marton Balint <cus@passwd.hu>

move shuffle_bytes_1230, 3012, 3210 with the other shuffle_byte
declaration

swscale/rgb : move shuffle func shuffle_bytes_1230, shuffle_bytes_3012, shuffle_bytes_3210 in order to add SIMD

Revert "avcodec/vp9_superframe_bsf: cache packets by creating new references rather than moving them"

This reverts commit 7a02b364.

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>

Signed-off-by: Sasi Inguva <isasi@isasi.mtv.corp.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 e1bc3f43, which
was then promptly fixed in 37f4a093 and 7a02b364. 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>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

So user can pick which channels to extract.
Signed-off-by: Paul B Mahol <onemda@gmail.com>