* commit '46ce9ded':
  tiff: K&R formatting cosmetics

Conflicts:
	libavcodec/tiff.c
	libavcodec/tiff.h
	libavcodec/tiffenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* cigaes/master:
  lavfi/trim: mark link closed on EOF.
  ffmpeg: ignore EOF when pushing frames to filters.
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

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

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

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

Fix trac ticket #2620.

EOF is not a fatal condition, it is normally produced
by a few filters.

TODO: take it into account to avoid useless decoding.

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

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

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

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

about 1% speedup
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

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

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

This reduces dependancy chains and improves speed by about 2%
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This fixes 2 files that where not part of the original change
See: de421b20Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* qatar/master:
  network: factor out connect-listening code

Conflicts:
	libavformat/network.h
	libavformat/tcp.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '28306e6d':
  network: factor out bind-listening code
  use my full first name instead of short one in copyrights

Conflicts:
	libavformat/tcp.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

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

* cus/stable:
  ffplay: detect when the created overlay buffers are not valid for the wanted overlay height
  ffplay: do not allow wider window than 16383
  ffplay: use 0 frame delay if redisplaying an already displayed frame
  ffplay: use more sane frame timer resetting logic
  ffplay: only update pts if not redisplaying a frame
  ffplay: fix compute_target_delay to better handle frames with long durations
  ffplay: if playing only audio or video only, show the master clock diff in status line
  ffplay: factorize clock functions
  ffplay: decrease video picture queue size to 3
Merged-by: Michael Niedermayer <michaelni@gmx.at>

It was ported to a native libavfilter filter.

Do not read padding or out-of-buffer values when computing the output
value for a pixel close to the image buffer edge.

This avoids non visible artifacts which affected the output checksum.

See thread:
Subject: [FFmpeg-devel] [PATCH] lavfi/mp/mcdeint: avoid uninited data read
Date: Thu, 30 May 2013 18:57:14 +0200

Fixes ticket #2614.

Introduce ff_listen_connect, to be shared with the other
non-tcp network protocols.

Introduce ff_listen_bind, to be shared with the other non-tcp
network protocols.

Currently the WebVTT demuxer parses the cues but throws away
the cue id (the optional first line of the cue) and cue
settings (the optional rendering instructions that follow
the timestamp).

However, in order to write inband text tracks (to WebM
files), the entire cue payload from the WebVTT source must
be preserved.

This commit makes no change to the data part of the output
buffer packet (where the actual cue text is stored), but
does add the cue id and settings as a side data items, if
they're present in the cue. Existing code that cares only
about the data part of the packet can continue to ignore the
side data.

There are two new packet data type flags,
AV_PKT_DATA_WEBVTT_IDENTIFIER and
AV_PKT_DATA_WEBVTT_SETTINGS.

The padding data is assumed to be 0 in several places, notably in
subtitles. This problem was not detected with fate-sub-srt test because
the first element of the side data (x1) is 0 in the test, so the
trailing side data present in the packet wasn't read by the decoder. The
issue can be observed with a large enough x1.

It is also noted in FF_INPUT_BUFFER_PADDING_SIZE doxy that MPEG
bitstreams require that padding with 0, so it might fix other issues.

This keeps the structure fields more consistent after cleanup
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes cases when the picture height was bigger than the maximum supported
overlay height...
Signed-off-by: Marton Balint <cus@passwd.hu>