This should make no difference as the byte is ignored
Found-by: tim nicholson <nichot20@yahoo.com>
Reviewed-by: tim nicholson <nichot20@yahoo.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Added HLS encryption with -hls_key_info_file <key_info_file> option. The
first line of key_info_file specifies the key URI written to the
playlist. The key URL is used to access the encryption key during
playback. The second line specifies the path to the key file used to
obtain the key during the encryption process. The key file is read as a
single packed array of 16 octets in binary format. The optional third
line specifies the initialization vector (IV) as a hexadecimal string to
be used instead of the segment sequence number (default) for encryption.
Changes to key_info_file will result in segment encryption with the new
key/IV and an entry in the playlist for the new key URI/IV.
Key info file format:
<key URI>
<key file path>
<IV> (optional)
Example key URIs:
http://server/file.key
/path/to/file.key
file.key
Example key file paths:
file.key
/path/to/file.key
Example IV:
0123456789ABCDEF0123456789ABCDEF
Example:
ffmpeg -f lavfi -i testsrc -c:v h264 -hls_key_info_file file.keyinfo
foo.m3u8
file.keyinfo:
http://server/file.key
/path/to/file.key
0123456789ABCDEF0123456789ABCDEF
Example shell script:
BASE_URL=${1:-'.'}
openssl rand 16 > file.key
echo $BASE_URL/file.key > file.keyinfo
echo file.key >> file.keyinfo
echo $(openssl rand -hex 16) >> file.keyinfo
ffmpeg -f lavfi -re -i testsrc -c:v h264 -hls_flags delete_segments \
-hls_key_info_file file.keyinfo out.m3u8
--
Signed-off-by: Christian Suloway <csuloway@globaleagleent.com>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
GNUTLS_SHUT_RDWR means GnuTLS will keep waiting for the server's
termination reply. But since we don't shutdown the TCP connection at
this point yet, GnuTLS will just keep skipping actual data from the
server, which basically is perceived as hang.
Use GNUTLS_SHUT_WR instead, which doesn't have this problem.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
GNUTLS_SHUT_RDWR means GnuTLS will keep waiting for the server's
termination reply. But since we don't shutdown the TCP connection at
this point yet, GnuTLS will just keep skipping actual data from the
server, which basically is perceived as hang.
Use GNUTLS_SHUT_WR instead, which doesn't have this problem.
Signed-off-by: Martin Storsjö <martin@martin.st>
Neccessary -> Necessary
formated -> formatted
thee -> the
eventhough -> even though
seperately -> separately
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
* commit 'a7ac1a7b94447f33ae95be4d6d186e2775977f91':
flv: Name an enum and use its type
Conflicts:
libavformat/flvdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Some files have SeekHead elements with broken IDs. They mismatch with
the ID of the destination element. These files are written by
"IDMmkvlib0.1" (as identified by the MuxingApp and WritingApp elements),
and the SeekHead IDs are actually endian-swapped.
This confuses the SeekHead logic of the demuxer. It will read some
elements twice, because the SeekHead ID is used to identify and remember
already read elements. With the file at hand, the stream list was
duplicated by reading the Tracks element twice.
Fix this by rejecting invalid EBML IDs in SeekHead entries. (This fix is
relatively specific to the broken file at hand, and doesn't protect
against some other cases of broken SeekHead, such as valid but
mismatching target element IDs.)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
There is no support for non integer sample rates, using doubles/floats currently could
only lead to rounding differences between platforms
Previous version Reviewed-by: Mark Harris <mark.hsj@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Make the logic in libavformat/hevc.c parse_rps align with libavcodec/hevc_ps.c ff_hevc_decode_short_term_rps
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is required for the (not yet in git) private stream detection/export,
no other testcase known
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Send a footer to correctly close client sockets.
This fixes network errors in client applications.
Signed-off-by: Stephan Holljes <klaxa1337@googlemail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
display_matrix_size is only initialized when av_stream_get_side_data()
returns a side data pointer. The code is safe since the only effect this
has is setting the display_matrix pointer to NULL which it was already
anyway.
The flag was set unintentionally and the code will break if a NULL
packet is passed in.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b14086ca38efa1a86cb0f0c6aa147b05f698877b':
mkv: Correctly report the latest packet had been flushed
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The first check is done without the AVIOContext, so alloc it only if said check succeeds
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
The first check is done without the AVIOContext, so alloc it only if said check succeeds
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit 'caf7be30b11288c498fae67be4741bfbf083d977':
mpjpgdec: free AVIOContext leak on early probe fail
Conflicts:
libavformat/mpjpegdec.c
See: 34d278f983, this was mistakenly reimplemented, also see ffmpeg IRC log of today
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This can be useful for debugging, or in scenarios where the user
doesn't want to use the system's DNS settings for whatever reason.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Together with the next commit this prevents non-PCM S302M from being selected unless either
it can be decoded or the user selects passthrough/copy
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Per matroska Block Structure [1], for keyframes 0th bit of the flag
should not be set (unlike SimpleBlocks). For Blocks, keyframes is
inferred by the absence of ReferenceBlock element (as done by
matroskadec). This CL writes the flag correctly and inserts the
ReferenceBlock element for non-keyframes. The timestamp inserted is
that of the immediately preceding frame (which is true for VP8 and VP9
- the only 2 codecs using the matroska block element as of now). It
also considers all non-video frames (audio, subtitles, metadata) to
be keyframes.
[1] http://www.matroska.org/technical/specs/index.html#block_structure
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is the maximum rate possible based on the frame size limit of MXF D-10
Previous version reviewed by tim nicholson <nichot20@yahoo.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
mpz_import and mpz_export were added in GMP 4.1, in 2002.
This simplifies the DH code by clarifying that it only uses pure
bignum functions, no other parts of nettle/hogweed.
Signed-off-by: Martin Storsjö <martin@martin.st>
If avio_read fails, the buffer can contain uninitialized data.
This fixes 'Conditional jump or move depends on uninitialised value(s)'
valgrind warnings, and addresses a few memleaks.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
In this case the mov demuxer can return a large number of empty packets.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Otherwise the loop can take a lot of time if num_descr is very large.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
OSX does not know MSG_NOSIGNAL. BSD (which OSX is based on) has got
the socket option SO_NOSIGPIPE (even if modern BSDs also support
MSG_NOSIGNAL).
Signed-off-by: Martin Storsjö <martin@martin.st>
OSX does not know MSG_NOSIGNAL, and provides its own non-standard
mechanism instead. I guess Apple hates standards.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b2f0f37d242f1194fe1f886557cf6cefdf98caf6':
rtmpdh: Generate the whole private exponent using av_get_random_seed() with nettle/gmp
Merged-by: Michael Niedermayer <michaelni@gmx.at>
A negative sample duration is invalid according to the spec, but there
are samples that use it for the DTS calculation, e.g.:
http://files.1f0.de/samples/mp4-negative-stts-problem.mp4
These currently get out of A/V sync.
Also change the logging type to AV_LOG_WARNING, because decoding the
sample can continue.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Users have no means to find out from a failure how to make it work
or is it preferred to check and print a warning for h264 concat without auto_convert ?
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e9e86d9ef637f5a600c76b352ffe5a82b71b25d1':
rtmpdh: Create sufficiently long private keys for gcrypt/nettle
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8016a1bd3b60e917e1b12748dd80c06c3462c286':
rtmpdh: Remove an unnecessary check in the gcrypt/nettle dh_compute_key
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '063f7467e4d14ab7fe01b2845dab60cc75df8b53':
rtmpdh: Add fate test for the DH handshake routine
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0508faaa11bf7507ffdd655aee57c9dc5a8203f4':
rtmpdh: Pass the actual buffer size of the output secret key
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9f1b3050d9e31e9283d818f3640f3460ac8cfb5b':
rtmpdh: Check the output buffer size in the openssl version of dh_compute_key
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '127d813bcb5705202b7100cf1eccd1e26d72ba14':
rtmpdh: Fix a local variable name in the nettle/gcrypt codepath
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '78efc69e7c990226f4b913721ef1b308ca5bfa04':
rtmpdh: Make sure ret is initialized in the nettle version of bn_hex2bn
Merged-by: Michael Niedermayer <michaelni@gmx.at>
There was a misunderstanding betewen bits and bytes for the parameter
value for generating random big numbers.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'd4d90504a687d2c0ef77ccf11d831f24dcff9cf1':
tls_gnutls: Add missing includes for the gcrypt thread safety callbacks
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* cehoyos/master:
lavc/x264: Support bgr0 as input pix_fmt.
lavf: Use av_codec_get_tag2() in avformat_query_codec().
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Move the OpenSSL and GnuTLS implementations to their own files. Other
than the connection code (including options) and some boilerplate, no
code is actually shared.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Apparently it can happen that a mp3 file has junk data between id3 tag
and actual mp3 data. Skip this to avoid outputting nonsense timestamps.
(Two packets had the same timestamps, because the mp3 parser failed to
compute a frame duration.)
In this case, the junk consisted of 1044 bytes of zero, which
incidentally is the same size as normal mp3 frames in this stream. I
suspect the mp3 was edited with some tool which wiped the Xing/LAME
headers. Data near the end of the file suggests it was encoded with
"LAME3.97", but the normal Xing/LAME headers are missing. So this could
be "normal". mpg123 also attempts to skip at least 64KB of junk data by
scanning for headers.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Move the OpenSSL and GnuTLS implementations to their own files. Other
than the connection code (including options) and some boilerplate, no
code is actually shared.
Signed-off-by: Martin Storsjö <martin@martin.st>
In this case the mov demuxer can return a large number of empty packets.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
