I still don't fully understand the cause but the difference between
the samples that trigger the bug and the samples that don't is
that the former uses delay frames and the later uses drop frames
as placeholders for the packed frame. So, if we see the one type
of frame, we can assume the bug will or won't be present.

Right now, I'm detecting the frame types by size, which may not be
safe in general, but given the specific codec and file type, I
expect any scenario where we encounter these frames where they
aren't being used for b-frame packing won't care one way or
another whether the work around is in effect or not.
Signed-off-by: Philip Langdale <philipl@overt.org>

Fix warning:
libavcodec/utils.c: At top level:
libavcodec/utils.c:714:5: warning: "FF_API_VIDEO_OLD" is not defined

Also fix trac issue #139.

Our muxer writes these out, so we really should support reading them.
Fixes ticket #30.

* qatar/master:
Duplicate  AMV: disable DR1 and don't override EMU_EDGE
Duplicate  lavf: inspect more frames for fps when container time base is coarse
Wrong and we have correct fix: Fix races in default av_log handler
  vorbis: Replace sized int_fast integer types with plain int/unsigned.
  Remove disabled non-optimized code variants.
NO  bswap.h: Remove disabled code.
  Remove some disabled printf debug cruft.
  Replace more disabled printf() calls by av_dlog().
NO  tests: Remove disabled code.
NO  Replace some commented-out debug printf() / av_log() messages with av_dlog().
  vorbisdec: Replace some sizeof(type) by sizeof(*variable).
NO  vf_fieldorder: Replace FFmpeg by Libav in license boilerplate.

Conflicts:
	libavcodec/h264.c
	libavcodec/vorbisdec.c
	libavutil/log.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

This works around a possibly exploitable crash.
Appearently, vlc can be exploited with a malicous file. This should get
reverted as soon as a proper fix is found.

Reported-at: Thu, 21 Apr 2011 14:38:25 +0000
Reported-by: Dominic Chell <Dominic.Chell@ngssecure.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 89f903b3)
(cherry picked from commit 9b919571e506fbb72b81a35ca1e7c1bd6efc4209)

As per issue2629, most 23.976fps matroska H.264 files are incorrectly
detected as 24fps, as the matroska timestamps usually have only
millisecond precision.

Fix that by doubling the amount of timestamps inspected for frame rate
for streams that have coarse time base. This also fixes 29.970 detection
in matroska.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 78431098)

Tested with mplayer based on this report
http://thread.gmane.org/gmane.comp.video.mplayer.user/66043/focus=66063Signed-off-by: Reinhard Tartler <siretart@tauware.de>

Prevent competing threads from overwriting (shared) buffers.

Original patch by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

int/unsigned is the natural memory access type for CPUs, using sized types
for temporary variables, counters and similar just increases code size and
can possibly cause a slowdown.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This is not documented (and possibly not originally intended),
but it's what the current reference decoder does.

	ffmpeg | branch: master | Anton Khirnov <anton@khirnov.net> | Tue Apr 26 09:59:07 2011 +0000| [f8fec050] | committer: Anton Khirnov

	mpegtsenc: make PMT PID really start on pmt_start_pid
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

No longer needed after martins change to the values.
Though this would have been nicer ABI wise but iam too lazy to maintain this difference

This reverts commit 183401b9.

* qatar/master:
LOTS of duplicates ...
  avio: Fix the deprecated fallback URL-prefixed open flags
  avoid duplicate -lm in .pc files
  mpeg12: terminate mpeg2_video_profiles arrays
  network: Check POLLERR and POLLHUP in ff_network_wait_fd
  mpegtsenc: make PMT PID really start on pmt_start_pid
  nut format: support PIX_FMT_BGR48LE and PIX_FMT_BGR48BE
  rawvideo codec: support PIX_FMT_BGR48LE and PIX_FMT_BGR48BE
  hflip: make the filter accept PIX_FMT_BGR48LE and PIX_FMT_BGR48BE pixel formats
  crop: make the filter accept PIX_FMT_BGR48LE and PIX_FMT_BGR48BE pixel formats
  libswcale: PIX_FMT_BGR48LE and PIX_FMT_BGR48BE scaler implementation

Conflicts:
	configure
	libswscale/swscale.h
	tests/ref/lavf/ts
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This hack is no longer needed.

This reverts commit 191e08d1.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The lowres support doesn't work correctly (crops the video), so let's remove it.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

lowres higher than 3 crashes ffmpeg/ffplay here
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The lowres support doesn't work correctly (crops the video), so let's remove it.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The lowres support doesn't work correctly (crops the video), so let's remove it.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

While deprecated, they're totally useless as long as their values
are different from the AVIO_FLAG values that are used internally.
Currently, this leads to old libav applications still compiling
correctly (since we haven't removed the fallback wrappers), but
failing since the functions internally compare to the new AVIO_FLAG
values.

These should be removed at some point, but they aren't removed yet.
The intent is to be able to recompile an old application against
the new ABI without modifying the code, and this doesn't work
currently.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Reported by: Luca Abeni
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>