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>
Fixes ticket #4628.
The problem arose, in the sample file at least, in the last block where the
minimum and maximum Rice partition orders were both 0. In that case, and any
other where pmax == pmin, the original UINT32_MAX placeholder value for
bits[opt_porder] was getting overwritten before the comparison to check if the
current partition order is a new optimal, so the correct partition order and
RiceContext params were not being set.
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>
* commit 'a4fbd55d6e03eabdbecc3b7892ec09eb8062d066':
h264: er: Copy from the previous reference only if compatible
See: fdc64a1044
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9af7e8045e3e63ab39adedae9a7c11b1c410af26':
lavc: Clarify the behaviour of dimension and format context fields
Conflicts:
libavcodec/avcodec.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '03ca6d70df192125a772dadd01acfe3905aa653f':
x264: Factor out the reconfiguration code
Conflicts:
libavcodec/libx264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is more robust.
And only check if there is actually a frame returned.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Also use the frame pixel format instead of the one from the codec
context, which is more robust.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Also use the frame pixel format instead of the one from the codec
context, which is more robust.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The AVCodecContext width, height, coded_width, coded_height and format
are used mainly as decoding hints and they get internally overwritten
during the data parsing stage.
Do not assume they match the last AVFrame provided by
avcodec_decode_video2 and assimilated functions since multi-threading
and other frame reordering might make those values to refer to frames
that will be outputted in the future.
CC: libav-stable@libav.org
* commit '74ea1167d91ccb2e1f2943efa030f2c278b598be':
tls_gnutls: fix hang on disconnection
See: 2222f419da
Merged-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>
Paul B Mahol
Michael Niedermayer
Christian Suloway
George Boyle
James Zern
Christian Suloway
Andreas Cadhalpun
Luca Barbato
Vittorio Giovara
wm4