* commit '50078c1c8070dd8d1c329e8117ff30ec72489039':
libavutil: move FFALIGN macro from common.h to macros.h
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'dbce017913ce04966021a2f72e4f8fae5b4b7190':
mpegtsenc: add flag to embed an AC-3 ES the DVB way
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'cc4c24208159200b7aff5b5c313903c7f23fa345':
avresample: Mark avresample_buffer() as pointer to const
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
ff_clz is faster, and uses an intrinsic (at the moment on GCC). exp2 is
a wasteful function for a simple integer exponentiation.
Untested.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Fixes Ticket #5032
The samples in Ticket #5032 is using \r\r\n as line breaks. Since we
already are handling \r, or \n, or \r\n as line breaks, \r\n\n will be
considered as a double line breaks. This is an issue because
ff_subtitles_read_text_chunk() will as a result stop extracting a chunk
after just one line.
So instead of parsing the SRT by "chunks" (which means splitting every
double LB), this new parser is detecting timing lines, and split the
events on this basis. While this sounds safe and simple, it needs to
take into account the event number preceding the timing line while
handling situations such as:
- event number starting at 0 or actually any number instead of 1
- event numbers not being ordered at all
- event number being followed by text garbage (this really happened,
see Ticket #4898)
- event payload containing one or multiple number (a protagonist saying
a count-down, a date or whatever) which could be confused with a
chapter number
- event number being empty (see Ticket #2167)
- all kind of weird line breaks can appear randomly like wild pokémons
- untrustable line breaks (Ticket #5032)
The sample madness.srt tries to sum up most of this into one sample,
ticket5032-rrn.srt is the file containing \r\r\n line breaks. and
empty-events-2167.srt contains empty events.
* commit '64f8c439fd663fec4d57ac21af572d498fe21f7a':
rtmpproto: Include the full path as app when "slist=" is found
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '9f0b6e6827e21e3477abe1199dc2728e30b8c061':
vocdec: do not create the stream in read_header()
Not merged as it breaks FATE.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '2d0432d918a71468419b7ac1e543ab3b399d3d37':
vocdec: put the code not shared with other demuxers under appropriate ifdef
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '09ae7b81ea2051eec2be9964296bd6ef492c6622':
flvdec: do not create any streams in read_header()
Not merged. The demuxer issues warnings when a new stream is encountered
and reading the metadata requires that streams already exist.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This unbreaks muxing-encoding
Example:
ffmpeg -i matrixbench_mpeg2.mpg new.avi
-rw-r----- 1 michael michael 226035354 Jan 1 16:27 new.avi
-rw-r----- 1 michael michael 10016802 Jan 1 16:28 ref.avi
Also av_get_audio_frame_duration() itself uses frame_size
This reverts commit 29e6606e9b, reversing
changes made to 53448461a7.
* commit 'de9e199a039473ebe4b1b87382e3064d0ea2cf02':
lavc: make avpriv_mpa_decode_header private on next bump
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* 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>
