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>
This solves the problem discussed in https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
by allowing AVCodec::write_header to be delayed until after packets have been
run through required bitstream filters in order to generate global extradata.
It also provides a mechanism by which a muxer can add a bitstream filter to a
stream automatically, rather than prompting the user to do so.
Revert requested by Balint Marton <cus@passwd.hu>
See: [FFmpeg-devel] ffplay: insertion point of the auto rotation filter - Github ticket #141
This reverts commit 9cc1e644f3.
Palettized QuickTime video in Matroska has hitherto not been recognized
whatsoever, and the "palette" used has been completely random.
The patch for matroskadec.c fixes this issue by adding a palette side
data packet in matroska_deliver_packet(), much in the same way as it's
done in mov.c.
Video samples for testing are available at
https://drive.google.com/open?id=0B3_pEBoLs0faWElmM2FnLTZYNlk.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This consists mainly of moving the palette handling from
the mov_parse_stsd_video() function to a new ff_get_qtpalette() function
in the new file qtpalette.c, which will be shared by both matroskadec.c and
mov.c.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Previous "currently size is limited" didn't give away
much in terms of useful info.
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
