Remove duplicated out-of-loop init code, and do color matrix
initialization at the beginning of each y iteration.

Allow factorization and avoid an useless matrix update in the last
iteration.

The previous table appears to be wrong (it was copied from the original
MPlayer super2xsai filter in order to keep binary compatibility).

The new table is consistent with the init code and apparently fixes a
combing artifact on the left edge of the generated image.

Use the same values of the video output link.

Avoid the need to override the default_start_frame() with an ad-hoc
start_frame() callback.

In particular, fix the super2xsai filter which was setting the
input w/h values in the output.

The function will abort through an assert if the source is not defined,
or if the internal state of the source is inconsistent (e.g. type = AUDIO
&& !src->audio).

Help debugging.

Return AVERROR(EINVAL) in case of invalid coded size.

* qatar/master:
  af_resample: fix format modifier in debug string for FF_API_SAMPLERATE64
  segment: remove unnecessary <strings.h> include
  fate: add snow hpel tests
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Janne Grunau <janne-libav@jannau.net>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

This prevents out of array read.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

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 Bradshaw <mbradshaw@sorensonmedia.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

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

Add a NULL to prevent undefined behavior
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

as it breaks ICC:
libavcodec/libavcodec.a(snowenc.o): In function `encode_q_branch':
/home/fate/x86_64-linux-gnu-icc-2011.4.191/src/libavcodec/snowenc.c:405: undefined reference to `ff_epzs_motion_search'
/home/fate/x86_64-linux-gnu-icc-2011.4.191/src/libavcodec/snowenc.c:414: undefined reference to `ff_get_mb_score'
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

It is generally bad idea even if codecs use same code.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Paul B Mahol <onemda@gmail.com>

currently a overflow there should be impossible but future changes to
the code could easily introduce a bug that no longer limits the 2
values sufficiently so better protect it via av_assert.
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: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* qatar/master:
  Avoid C99 variable declarations within for statements.
  rtmp: Read and handle incoming packets while writing data
  doc: document THREAD_TYPE fate variable
  rtpdec: Don't require frames to start with a Mode A packet
  avconv: don't try to free threads that were not initialized.

Conflicts:
	doc/fate.texi
	ffplay.c
	libavdevice/dv1394.h
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>

We generally do not declare variables within for statements and
there are compilers that choke on such constructs.

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

This makes sure all incoming packets are read and handled (and reacted
to) while sending an FLV stream over RTMP to a server. If there were
enough incoming data to fill the TCP buffers, this could potentially
make things block at unexpected places. For the upcoming RTMPT support,
we need to consume all incoming data before we can send the next
request.
Signed-off-by: Martin Storsjö <martin@martin.st>