* commit '955aec3c7c7be39b659197e1ec379a09f2b7c41c':
mpegaudiodecheader: check the header in avpriv_mpegaudio_decode_header
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'cea1eef25c3310a68dd327eb74aae14ad3c2ddef':
lavc: get the profile name through the codec descriptor in avcodec_string()
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'cdc9ce098e8d101b43b8f68dd35ba7226f4a728c':
lavc: print the name of the codec, not its implementation, in avcodec_string
FFmpeg has already done this.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '6bf4c1d71199b92894f24db6386ed5070e590a16':
r3d: do not create the audio stream until we know the sample rate
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '9f1eccb97bf8894cb18b14f642500686505ef186':
ff_parse_specific_params: do not use AVCodecContext.frame_size
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This can happen if s->ls changes from 0 to 1, but picture allocation is
skipped due to s->interlaced.
In that case ff_jpegls_decode_picture could be called even though the
s->picture_ptr frame has the wrong pixel format and thus a wrong
linesize, which results in a too small zero buffer being allocated.
This fixes an out-of-bounds read in ls_decode_line.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
support reading encrypted mp4 using aes-ctr, conforming to ISO/IEC
23001-7.
a new parameter was added:
- decryption_key - 128 bit decryption key (hex)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Commit b272c3a5aa has sped up dsd_tablegen, and now table generation takes
~ 40k cycles. Thus, these tables can always be generated at runtime.
Tested with/without --enable-hardcoded-tables.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Prevents that following scalers in the filter chain will do unintentional color range conversions.
Fixes Ticket #5096
Signed-off-by: Thomas Mundt <loudmax@yahoo.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Let's disable the ISAs first, and then the core capabilities, as we do
for the rest of the cores. This way the code is better organized.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Tables are bit identical.
Sample benchmark (Haswell, GNU/Linux+gcc):
old:
814485 decicycles in dsd_ctables_tableinit, 512 runs, 0 skips
new:
356808 decicycles in dsd_ctable_tableinit, 512 runs, 0 skips
Binary size should essentially be identical, and is in fact identical on
the configuration I tested on.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Solves an issue that will get triggered when gcc 20 rolls in.
Found-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This fixes crashes caused by out-of-bounds writes.
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
These are just for prefixes and may be hardcoded easily; see lavu/eval
for this approach.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This commit for qtpalette.c and qtpalette.h adds 1-bit video to the
"palettized video" category, since if the video sample description
contains a palette, the two colors in the palette can be any color, not
necessarily black & white.
Unfortunately, I've noticed that the qtrle (QuickTime Animation) decoder
blindly assumes that 1-bit video is black & white. I don't have enough
knowledge about the decoder to fix this, though.
Below is a link to a sample 1-bit QuickTime Animation clip of a rotating
earth that uses blueish colors, and they will be correctly rendered in
QuickTime, but not in FFmpeg (which will use black & white).
https://drive.google.com/open?id=0B3_pEBoLs0faUlItWm9KaGJSTEE
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
get_ue_golomb() cannot decode values larger than 8190 (the maximum
value that can be golomb encoded in 25 bits) and produces the error
"Invalid UE golomb code" if a larger value is encountered. Use
get_ue_golomb_long() instead (which supports 63 bits, up to 4294967294)
when valid h264/hevc values can exceed 8190.
This updates decoding of the following values: (maximum)
first_mb_in_slice 36863* for level 5.2
abs_diff_pic_num_minus1 131071
difference_of_pic_nums_minus1 131071
idr_pic_id 65535
recovery_frame_cnt 65535
frame_packing_arrangement_id 4294967294
frame_packing_arrangement_repetition_period 16384
display_orientation_repetition_period 16384
An alternative would be to modify get_ue_golomb() to handle encoded
values of up to 49 bits as was done for get_se_golomb() in a92816c.
In that case get_ue_golomb() could continue to be used for all of
these except frame_packing_arrangement_id.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Replaces by real arithmetic. Tested the validity of these transformations separately.
Numerical differences are ~1e-15, and should not matter: it is not even
clear which is more precise mathematically.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Previosly output was almost useless because background noise, due to
windowing function picked and which is not actually present in audio,
had too much brightness.
Now output of sine wave matches more with SoX.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Hendrik Leppkes
Lou Logan
Michael Niedermayer
Andreas Cadhalpun
erankor
Paul B Mahol
Ganesh Ajjanagadde
Thomas Mundt
Rostislav Pehlivanov
yukari yakumo
Vicente Olivert Riera
Michael Niedermayer
Carl Eugen Hoyos
Mats Peterson
Mark Harris
James Almer
Joel Holdsworth
Rodger Combs