| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building with libopenmpt 0.3, use the libopenmpt file header
probing functions for probing. libopenmpt probing functions are
allocation-free and designed to be as fast as possible.
For libopenmpt 0.2, or when libopenmpt 0.3 file header probing cannot
probe successfully due to too small probe buffer, test the filename
against the file extensions supported by the libopenmpt library that
is actually linked, instead of relying on a hard-coded file extension
list. File extension testing is also allocation-free and designed to
be fast in libopenmpt. Avoiding a hard-coded file extension list is
useful because later libopenmpt versions will likely add support for
more module file formats.
libopenmpt file header probing is tested regularly against the FATE
suite and other diverse file collections by libopenmpt upstream in
order to avoid false positives.
FATE passes with './configure --enable-libopenmpt' as well as with
'./configure --enable-libopenmpt --enable-libmodplug'.
libopenmpt probing adds about 5%..10% cpu time (depending on precise
usage pattern and host CPU and compiler version used for libopenmpt)
compared to all current internal FFmpeg probing functions combined in
tools/probetest for all of its module formats combined (currently 41
modules formats in libopenmpt 0.3.4 and 234 file formats in FFmpeg).
Signed-off-by: Jörn Heusipp <osmanx@problemloesungsmaschine.de>
Reviewed-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
| |
Signed-off-by: Jörn Heusipp <osmanx@problemloesungsmaschine.de>
Reviewed-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the string consists entirely of whitespace, this could in theory
continue to write '\0' before the start of the memory allocation. In
practice, it didn't really happen: the generic HTTP header parsing code
already skips leading whitespaces, so the string is either empty, or
consists a non-whitespace. (The generic code and the cookie code
actually have different ideas about what bytes are whitespace: the
former uses av_isspace(), the latter uses WHITESPACES. Fortunately,
av_isspace() is a super set of the http.c specific WHITESPACES, so
there's probably no case where the above assumption could have been
broken.)
|
|
|
|
|
|
|
|
| |
It's trivial to craft a HTTP response that will make the code for
skipping trailing whitespace access and possibly overwrite bytes outside
of the memory allocation. Why this can happen is blindingly obvious: it
accesses cstr[strlen(cstr)-1] without checking whether the string is
empty.
|
|
|
|
|
|
|
| |
libavformat prints a warning that the cookie couldn't be parsed (see
callers of parse_cookie()). This is obviously not true - it could be
parsed, but was simply ignored. Don't return an error to avoid the
warning.
|
|
|
|
| |
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
|
|
|
|
|
|
| |
fix ticket: #7021
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
|
|
|
|
|
|
|
| |
move fmp4_init_filename init in if else for first fmp4_init_filename set
value operation.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
|
|
|
|
| |
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
|
|
|
|
|
|
| |
fmp4_init_filename should append after base_output_dirname
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
|
| |
|
| |
|
|
|
|
|
|
| |
They belong in avcodec.
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
| |
Simplifies code.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
| |
Signed-off-by: Steven Liu <lingjiujianke@gmail.com>
|
|
|
|
| |
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks for the discussion. Here's the next version, now with /25 and removed
ff_log2().
The blocksize of the PCM decoder is hard-coded. This creates
unnecessary delay when reading low-rate (<100Hz) streams. This creates
issues when multiplexing multiple streams, since other inputs are only
opened/read after a low-rate input block was completely read.
This patch decreases the blocksize for low-rate inputs, so
approximately a block is read every 40ms. This decreases the startup
delay when multiplexing inputs with different rates.
Signed-off-by: Philipp M. Scholl <pscholl@bawue.de>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
| |
This is the fix for bug https://trac.ffmpeg.org/ticket/7073
Tested-by: Brainiarc7
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
|
|
|
|
|
|
|
|
|
|
| |
Fixes: runtime error: signed integer overflow: -9166684017437101870 + -2495066639299164439 cannot be represented in type
Fixes: Chromium bug 791349
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
Fixes seek for files with empty edits and files with negative ctts
(dts_shift > 0). Added fate samples and tests.
Signed-off-by: Sasi Inguva <isasi@isasi.mtv.corp.google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
Fixes: kira-poc
Found-by: Kira <kira_cxy@foxmail.com>
Change suggested by Kira
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
| |
Fixes: potential signed integer overflow
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
No testcase, this was found during code review
Found-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
Fixes: shift exponent 48 is too large for 32-bit type 'int'
Fixes: Chromium bug 786793
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
| |
Fixes: signed integer overflow: 3775922176 * 4278190080 cannot be represented in type 'long'
Fixes: Chromium bug 791237
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
Fixes: Chromium bug 795653
Fixes: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long'
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
| |
Some math (e.g: partition binary search) overflows if we have that many
parititions.
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
| |
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
|
|
|
|
|
| |
Consider edit rate when determining edit_units_per_packet and also make sure
that checks are done in edit rate time base and not in stream time base.
Fixes some errors reported with the sample in ticket #5863.
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
|
| |
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
|
| |
In this loop, |i| is the "index". And the memory allocated should be at
least the current "count", which is |i + 1|.
BUG=801821
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
| |
|
| |
|
|
|
|
|
|
|
| |
Fixes: runtime error: signed integer overflow: 7738135736989908991 - -7898362169240453118 cannot be represented in type 'long'
Fixes: Chromium bug 796778
Reported-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
| |
Fixes: Chromium bug 800123
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
| |
Fixes: Chromium bug 800123
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
Fixes: runtime error: signed integer overflow: 5 * -2147483647 cannot be represented in type 'int'
Fixes: Chromium bug 817338
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Reported-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
| |
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
|
|
| |
ff_get_extradata() frees any existing extradata before allocating now,
and using av_free() here leaves a dangling pointer that will result in
a double free.
Fixes a regression since 0ca33b1d4eb2a2a2e78ff3a37f1647917635b0d2.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
| |
Numeric hosts in certificates are not very common, but supported by LibreSSL.
Forward the IP address to make verification work in this case.
Fixes ticket #7029
|
|
|
|
|
|
|
| |
Cosmetic refactor
Reviewed-by: 74a2fa708af88d225ed708af758f236f869b1a57
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
| |
This prevents leaks in the rare cases the function is called when extradata
already exists.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mov_read_ctts ignores ctts entries having count <= 0. Generally, the
aggregate of all ctts entries' count fields resulting from mov_read_ctts
can be less than the corresponding sample_count.
mov_build_index attempts to normalize any existing ctts_data counts to
be 1, to make a 1-1 mapping of a ctts_data entry to a sample.
That 1-1 mapping left a tail of uninitialized ctts_data entries when the
aggregate, normalized ctts_count < sample_count.
Even more generally, later usage of ctts_data may depend on the entire
ctts_allocated_size having been initialized.
This change memsets the entire allocation of the normalized ctts_data in
mov_build_index, to prevent use of uninitialized data later.
BUG=816787
Change-Id: I7fd7db255e3aeed076ee32c90cb2df211741c052
Reviewed-on: https://chromium-review.googlesource.com/947110
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
| |
Documentation: http://mp4ra.org/atoms.html
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
| |
|
|
|
|
| |
enabled
|
|
|
|
|
| |
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
|
| |
fix ticket: #7044
Get the first video stream to reference for split segment
when there have more than one video stream
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Reviewed-by: Karthick Jeyapal <kjeyapal@akamai.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The allocated size of sc->ctts_data is
(st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
The size to memset at offset sc->ctts_data + sc->ctts_count should be
(st->nb_index_entries + entries - sc->ctts_count) *
sizeof(*sc->ctts_data))
The current code missed |entries| I believe, which was introduced in
https://patchwork.ffmpeg.org/patch/5541/.
However, after offline discussion, it seems the original code is much
more clear to read (before https://patchwork.ffmpeg.org/patch/5541/).
Hence this CL revert the memset logic to it's previous state by
remembering the |old_ctts_allocated_size|, and only memset the newly
allocated entries.
BUG=812567
Change-Id: Ibe94c7138e5818bfaae76866bfa6619a9b8a2b6b
Reviewed-on: https://chromium-review.googlesource.com/934925
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
|
|
| |
when seeking
Obviously this is still not perfect, but better then it was. Using the first
index table and mxf->current_edit_unit is still hardcoded in many places, so
this change has hopefully the less chance of breaking anything that works
now.
Signed-off-by: Marton Balint <cus@passwd.hu>
|