- 20 Nov, 2015 16 commits
-
-
Michael Niedermayer authored
This should fix a infinite loop Reviewed-by:
Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
server_attached is newly added so the demuxer knows if there is an attached server that can update the write index. This is needed to fix a infinite loop Signed-off-by: -
Michael Niedermayer authored
Reviewed-by:
-
Rodger Combs authored
Also rearranged the relevant check to reduce code duplication Signed-off-by: -
Maksym Veremeyenko authored
Signed-off-by: -
Maksym Veremeyenko authored
Signed-off-by: -
-
Ganesh Ajjanagadde authored
The ad-hoc pi constant has a ludicrous number of digits that offer no value whatsoever. M_PI is more consistent and readable across the codebase. Reviewed-by:
Paul B Mahol <onemda@gmail.com> Reviewed-by:
Nicolas George <george@nsup.org> Signed-off-by:
Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
Ganesh Ajjanagadde authored
See e.g https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c for rationale. Reviewed-by:
Ronald S. Bultje <rsbultje@gmail.com> Reviewed-by:
Hendrik Leppkes <h.leppkes@gmail.com> Signed-off-by:
-
Ganesh Ajjanagadde authored
See e.g https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c for rationale. Reviewed-by:
-
Ganesh Ajjanagadde authored
See e.g https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c for rationale. Reviewed-by:
-
Ganesh Ajjanagadde authored
See e.g https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c for rationale. Reviewed-by:
-
Ganesh Ajjanagadde authored
See e.g https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c for rationale. Reviewed-by:
-
wm4 authored
If videotoolbox_common_end_frame failed, then the AVFrame was returned to the API user with the dummy buffer (in AVFrame.buf[0]) still set, and the decode call indicating success. These "half-set" AVFrames with dummy buffer are a videotoolbox specific hack, because the decoder requires an allocated AVFrame for its internal logic. Videotoolbox on the other hand allocates its frame itself internally, and outputs it only on end_frame. At this point, the dummy buffer is replaced with the real frame (unless decoding fails).
-
Michael Niedermayer authored
The replaced check should have become redundant Found-by:
-
Michael Niedermayer authored
Found-by:
-
- 19 Nov, 2015 13 commits
-
-
Andreas Cadhalpun authored
It is used as size argument of ff_canopus_parse_info_tag, which uses it as size argument to bytestream2_init, which only supports sizes up to INT_MAX. Changing it's type to unsigned simplifies the check. Reviewed-by:
Vittorio Giovara <vittorio.giovara@gmail.com> Signed-off-by:
-
Paul B Mahol authored
Signed-off-by: -
James Almer authored
Signed-off-by:James Almer <jamrial@gmail.com>
-
James Almer authored
Signed-off-by: -
Derek Buitenhuis authored
* commit '1fc94724': xtea: Clarify that the current API works in big endian mode Merged-by:
Derek Buitenhuis <derek.buitenhuis@gmail.com>
-
Derek Buitenhuis authored
These are all no-op merges. * commit '7b2211bf': dds: add missing newline to log messages dds: validate compressed source buffer size dds: validate source buffer size before copying Merged-by:
-
Derek Buitenhuis authored
* commit 'b5f963bf': mov: Drop dref when unable to parse Merged-by:
-
Derek Buitenhuis authored
* commit '303f9319': mov: Correctly store dref paths Merged-by:
-
Derek Buitenhuis authored
* commit 'e25cac50': lavc: Add missing mem.h header to libxvid and screenpresso Merged-by:
-
Derek Buitenhuis authored
* commit '73b03249': aiff: Support demuxing G.722 streams Merged-by:
-
Michael Niedermayer authored
The replaced check should have become redundant Signed-off-by: -
Michael Niedermayer authored
Signed-off-by: -
Michael Niedermayer authored
This allows removing a special case for the fixed point decoder and will make error checks simpler Signed-off-by:
-
- 18 Nov, 2015 11 commits
-
-
Michael Niedermayer authored
This should avoid some tsan warnings Found-by:
Chris Cunningham <chcunningham@google.com> Signed-off-by:
-
Andreas Cadhalpun authored
Previously only the edit_rate of material_track was checked. If it's negative, it causes assertion failures in av_rescale_rnd. Reviewed-by:
Tim Nicholson <nichot20-at-yahoo.com@ffmpeg.org> Signed-off-by:
-
Michael Niedermayer authored
In case of bitstream errors the deblock filter and slices can access uninitialized top_borders from previous slices which did not fill them as they stoped halfway due to error or where entirely missing. This also makes code using these tables deterministic in case of missing or damaged slices Found-by: Tyson Smith Signed-off-by: -
Michael Niedermayer authored
Signed-off-by: -
Derek Buitenhuis authored
This is a no-op. * commit '5f2c8315': thp: set duration for audio stream too Merged-by:
-
Derek Buitenhuis authored
* commit '1d62ee38': movenc: Add a unit test for signaling of the track start times Merged-by:
-
Derek Buitenhuis authored
* commit 'bef3b1f5': movenc: Allow setting start_dts/start_cts before writing actual packets Merged-by:
-
Derek Buitenhuis authored
This way, it never starts with 0xFFF0, and never trips the ADTS "Detection" code in movenc.c. Signed-off-by: -
Michael Niedermayer authored
Reviewed-by:
-
Bryan Huh authored
DASH manifest should have framerate specified as an attribute in the AdaptationSet element and Representation elements. Though ISO/IEC 23009-1:2014 doesn't seem to define frameRate as a required attribute, it is at least optional, and DASH-IF IOP 3.0 seems to require it. See section 3.2.4 of http://dashif.org/w/2015/04/DASH-IF-IOP-v3.0.pdf In the event that avg_frame_rate is not set in the muxer, we ignore the frameRate tag altogther. Signed-off-by:
-
Paul B Mahol authored
Signed-off-by:
-
