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).
* 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>
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>
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>
* 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>
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>
While there is no reason for starting a frame with anything else
than a Mode A packet, some senders seem to consistently use Mode B
packets for everything. This fixes depacketization of such streams.
Signed-off-by: Martin Storsjö <martin@martin.st>
