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>
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).
The replaced check should have become redundant
Found-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
* commit '1fc94724f1fd52944bb5ae571475c621da4b77a0':
xtea: Clarify that the current API works in big endian mode
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This allows removing a special case for the fixed point decoder and will
make error checks simpler
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
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 <michael@niedermayer.cc>
This is a no-op.
* commit '5f2c8315b3c1b28da0386fddb118ad6a0ed77a0c':
thp: set duration for audio stream too
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '1d62ee38894afb696674db78cee8f8d89204a8fe':
movenc: Add a unit test for signaling of the track start times
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This way, it never starts with 0xFFF0, and never trips the
ADTS "Detection" code in movenc.c.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
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: Michael Niedermayer <michael@niedermayer.cc>
In the spirit of commit 8199908fdf, likely
typo originally.
Found by enabling -Wparentheses on clang 3.7 and running a manual audit.
To the best of my knowledge, no such instances remain.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Unrecognized streams are not allocated
Fixes: flicker-1.color1.vp91447030769.08.webm
Found-by: Chris Cunningham <chcunningham@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '3eeb7edfc2a1157b7b0e0ce21ac2cd44d55d405b':
movenc: Add a unit test for frag_discont with edit lists
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
All diferences in unit tests have been acounted for.
* commit '59e8ec0aa8ab174701d01a3bfe96fedd0b7fcead':
movenc: Add an API unit test for fragmenting options/calls
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This is possibly undefined behavior based on sequence point rules, but I
have not studied the spec at that level of detail.
Fixes: CID 1338321.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>