ffplay: remove refresh thread to achieve more precise frame delay

We use a refresh loop which displays the frames and also does the polling for
pending events in a non-blocking way. If we know the required delay until the
next frame, then exactly that amount of sleeping will be done. After each
handled event we check if we have to display a frame which kind of makes
displaying the frame a high priority event.

This improves greatly the smoothness of the video output especially with 50fps
content.

Signed-off-by: Marton Balint <cus@passwd.hu>
ffplay: remove remains of video_clock

We are now using a pts based approach, libavutil/libavcodec should provide the
correct pts-es anyway. This also fixes an issue when seeking to a frame with a
pts set to zero.

Signed-off-by: Marton Balint <cus@passwd.hu>
ffplay: only display frames if there are no pending events

Otherwise events could just pile up if displaying a frame takes more time than
the duration of the frame.

Signed-off-by: Marton Balint <cus@passwd.hu>
vf_yadif: factorize initializing the filtering callbacks

Do it all in config_props().
vf_yadif: fix out-of line reads

Some changes in the border pixels, visually indistinguishable.
get_buffer(): do not initialize the data.

There may be more decoders that rely on this. Those should be found and
fixed.
h264: simplify calls to ff_er_add_slice().

partitioned_frame is never set for h264 (as easily seen from git grep).
h264: remove a pointless if()

!encoding is always true, we do not have a H.264 encoder
svq3: remove a pointless if()

The H264 context is always uninitialized at this point.
error_resilience: decouple ER from MpegEncContext
mpegvideo: split ff_draw_horiz_band().

Split out dependency on MpegEncContext.
h264: deMpegEncContextize

Most of the changes are just trivial are just trivial replacements of
fields from MpegEncContext with equivalent fields in H264Context.
Everything in h264* other than h264.c are those trivial changes.

The nontrivial parts are:
1) extracting a simplified version of the frame management code from
   mpegvideo.c. We don't need last/next_picture anymore, since h264 uses
   its own more complex system already and those were set only to appease
   the mpegvideo parts.
2) some tables that need to be allocated/freed in appropriate places.
3) hwaccels -- mostly trivial replacements.
   for dxva, the draw_horiz_band() call is moved from
   ff_dxva2_common_end_frame() to per-codec end_frame() callbacks,
   because it's now different for h264 and MpegEncContext-based
   decoders.
4) svq3 -- it does not use h264 complex reference system, so I just
   added some very simplistic frame management instead and dropped the
   use of ff_h264_frame_start(). Because of this I also had to move some
   initialization code to svq3.

Additional fixes for chroma format and bit depth changes by
Janne Grunau <janne-libav@jannau.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>
sws/x86: improve rounding for yuv2yuvX

This tries to compensate for the errors introduced by
the rounding of pmulhw

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
lavfi/unsharp: use named options, and add missing checks on matrix size values

In particular, avoid out-of-buffer access and crashes with too big
values, and rework documentation accordingly.
doc/filters: itemize unsharp examples

Also drop pointless example.
lavfi/unsharp: extend range for amount values, to reflect the behavior of mp=unsharp

Also update the documentation accordingly, and suggest a meaningful range.
lavfi/kerndeint: use aligned linesizes for the temporary buffer.

This improves the performances just enough to match mp=kerndeint.

Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
lavfi/kerndeint: move is_rgb_packed definition to the internal context

No need to recompute it for each new frame.
lavfi/yadif: remove unnecessary cast

Finish what 99162f8 started

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
lavfi/yadif: support 9, 12, and 14 bits per pixel

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