Allowing larger timestamps makes it impossible to calculate basic things like the
difference of 2 timestamps or their sum without checking each individual computation for
overflow.
This should avoid a significant number of overflow checks

Fixes Ticket5136
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes Ticket #5897.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

As it does not work anymore since 655b6dcb

Found-by: carl
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes out of array access

Found-by: Thomas Garnier using libFuzzer
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Current code doesn't initialize AVPacket::pos. Made it point to FLVTAG so flv_read_packet can decode from pos
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Allows to write correct value for biBitCount into BITMAPINFOHEADER.
Before, ff_put_bmp_header() always wrote "24" as biBitCount
for utvideo because bits_per_coded_sample was never set by the
encoder.

Fixes out of array read

Found-by: Thomas Garnier using libFuzzer
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

the bps value is only stored with level >= 1, using rgb48 with level 0 requires the
user app to keep track of the bps by external means, which does not always happen
also we force level >= 1 for other 16bps formats, so this is consistent.
Found-by: Jerome Martinez <jerome@mediaarea.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

This is intended to workaround bug "665 Integer Divide Instruction May
Cause Unpredictable Behavior" on some early AMD CPUs, which causes a
div-by-zero in this codepath, such as reported in Mozilla bug #1293996.

Note that this isn't guaranteed to fix the bug, since a compiler is free
to reorder instructions that don't depend on each other. However, it
appears to fix the bug in Firefox, and a similar patch was applied to
libvpx also (see Chrome bug #599899).

Reviewed-By: Michael Niedermayer <michael@niedermayer.cc>

3 parts:
- Supports multiple chapter streams
- Exports regular text chapter streams as opaque data. This prevents consumers
  from showing chapters as if they were regular subtitle streams.
- Exports video chapter streams as thumbnails, and provides the first one as
  an attached_pic.

Reviewed-By: Michael Niedermayer <michael@niedermayer.cc>

This is disabled by default when the empty_moov flag is enabled

This allows a consumer to run the muxer's init function without actually
writing the header, which is useful in chained muxers that support
automatic bitstream filtering.

Some codecs set this in the parser, but not the decoder

Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This way locally installed documentation refers to itself instead of the
website.

Bud-Id: https://bugs.debian.org/841501Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

1.MMI_ load/store macros are defined in libavutil/mips/mmiutils.h
2.Replace some unnecessary unaligned access with aligned operator
3.The MMI_ load/store is compatible with cpu loongson2e/2f which not support instructions start with gs
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

1.mmiutils.h defined MMI_ load/store macros for loongson2e/2f/3a
2.mmiutils.h defined some mmi assembly macors
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>