Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

This is in preparation for adding support for other colorspaces
and coding types.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

If the dts difference is more than 1000 times the average dts
difference, restart the analysis.
Signed-off-by: Martin Storsjö <martin@martin.st>

These are normally initialized to AV_NOPTS_VALUE at the start
of avformat_find_stream_info, but if a new stream is found while
this function is running (e.g. like in mpegts), the newly added
AVStreams didn't have these values properly initalized, leading
to avformat_find_stream_info terminating too soon (when the
first timestamps are far from 0).
Signed-off-by: Martin Storsjö <martin@martin.st>

Some files' embedded art seems to have the mimetype 'image/JPG' instead
of 'image/jpg'. Libav fails to parse those because it matches
case-sensitively.

Use av_strncasecmp() to fix this behaviour.
Signed-off-by: Mohammad Alsaleh <msal@tormail.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This fixes running FATE without --enable-gpl.

Signed-off-by: Martin Storsjö <martin@martin.st>

Also fix the bytestream reader size parameter to take the
offset into account.
Signed-off-by: Martin Storsjö <martin@martin.st>

They describe properties that are inherent to a codec (as described by
an AVCodecID) without referring to a specific implementation.

C++ does not allow to mix different enums, so e.g. code comparing
ACodecID with CodecID would fail to compile with gcc.

This very evil hack should fix this problem.

This makes struct AVDictionary fully opaque now that nothing
needs to access it directly any more.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This adds a function to retrieve the number of entries in a
dictionary and updates the places directly accessing what should
be an opaque struct to use this new function instead.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This addition must be done as 64-bit to avoid overflow and for
the subsequent clipping to be meaningful.
Signed-off-by: Mans Rullgard <mans@mansr.com>

In 16-bit arithmetic, x * 0xffffc is simply x * -4 with extra overflows,
(and the constant was probably meant to be 0xfffc).  Combined with the
shift, this simplifies to -x >> 1.  Finally, clearing the low two bits
with a 32-bit mask and switching to a 32-bit type allows more efficient
code on 32-bit machines.
Signed-off-by: Mans Rullgard <mans@mansr.com>

(x << 2) - x is just an optimisation of 3 * x the compiler is
perfectly capable of doing on its own.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Mans Rullgard <mans@mansr.com>

The condition is trivially true, but keeping the assert() is
sensible to avoid FFM_HEADER_SIZE ever getting out of sync with
the actual code.
Signed-off-by: Mans Rullgard <mans@mansr.com>

The only compiler I have that does not define the standard
offsetof() macro is "Bruce's C Compiler", a simple compiler
for producing 8/16-bit 8086 code, usually for use in early
stages of PC booting.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This list is incomplete (we also use UINT16_MAX), so there does
not appear to be any system we care about that needs these.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This fixes build failures on debian/kfreebsd, which has the
sctp.h header, but it is currently broken (a cpp test succeeds,
but a compile test fails), see http://bugs.debian.org/684330 for
details.

Also remove the checked item from HAVE_LIST, since the corresponding
HAVE_* define isn't used by the source code.
Signed-off-by: Martin Storsjö <martin@martin.st>

This function is only ever called through a function pointer,
so marking it inline makes no sense.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>