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

There is nothing we use of the latest version, downgrade version number
to increase decoding support.

Based on this comment by vel2000:
http://ffmpeg.org/trac/ffmpeg/ticket/1642#comment:17

In avfilter_config_links(), if the current channel layout is not
specified, set the same value of the previous link in the filterchain.

Consistent with the logic used to set the other link parameters.

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

yasm generates a warning instead of an error when "CPU amdnop" is not supported, so the check always succeeds.

HAVE_CPUNOP as true when the available yasm version doesn't support amdnop doesn't make sense.
Check http://fate.ffmpeg.org/log.cgi?time=20120901143315&log=compile&slot=x86_64-archlinux-gcc-oldyasm to see the amount of warnings it generates.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

This fixes stream lookup in flv demuxer. When used with librtmp
protocol streams are sometimes added after head arrived. If the
first stream added in flv header reader is Audio stream then it
is messed with Video stream added later in the code patched.
The result is I have 2 Audio streams (first of them is said to have
a video codec like h264) instead of Audio/Video pair.
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>

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

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

It breaks linking with suncc sometimes
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>

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

* cus/stable:
  ffplay: only free vfilters on exit
  ffplay: replace SDL_delay in read thread with SDL_CondWait
  ffplay: requeue last picture on forced video refresh
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* stev47/master:
  cpia: move reget_buffer after header check
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* qatar/master:
  crypto: Remove a stray double space
  Rename missed cases of FF_OPT_TYPE_* to AV_OPT_TYPE_*

Conflicts:
	libavfilter/vf_delogo.c
	libavfilter/vf_lut.c
	libavfilter/vsrc_testsrc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

If the header is invalid, there is no need to get at buffer.
Do it after the header has been checked.
Suggested by Reimar Döffinger

It was natively integrated into libavfilter.

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

With this change avconv compiled against libav and linked to ffmpegs libs
will run through the whole fate testsuite without any crashes.
857 tests pass, the remaining tests fail one way or another, which is
to be expected as avconv is not a drop in replacement for ffmpeg
The testsuite used was the ffmpeg fate testsuite, not libavs.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

After much discussion and back-and-forth, we reached the conclusion
that matroska uses convergence_duration for subtitle duration because
a 32bit value isn't large enough to store the duration if sub-micro-second
timebases are used. Matroska may not be the only one that supports these
timebases, but it's certainly the only one that ffmpeg attempts to support
in this way.

The long term solution that we seemed to reach was that if we encounter
a matroska file with a sub-micro-second timebase, we should internally
scale it up to at least micro-second, and then duration can be used
normally. This suggests that on the encode side, we should not allow
generation of files with sub-micro-second timebases, but that's a separate
issue.

That being a non-trivial change, and the subtitle interoperability breakage
being very real, I'm re-submitting this small change for consideration.

In this diff, we make sure that duration is populated by the matroska
demuxer, and that convergence_duration is respected in matroskaenc and
srtenc, but that duration is used otherwise. This ends up being a strict
improvement - pipelines that use convergence duration are unchanged, and
ones that are currently broken due to the duration mismatch will start
working - except for the ones with the extreme timebases, but those were
already broken.
Signed-off-by: Philip Langdale <philipl@overt.org>

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

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

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

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

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

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

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

needed for avcodec_find_best_pix_fmt2()
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

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

and deprecate avcodec_find_best_pix_fmt2()
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>