* cus/stable:
ffplay: avoid window resize crash on osx with libsdl 1.2.14
ffplay: add delay multiple times to frame_timer if it is less than current time
ffplay: remove early frame drop functionality
ffplay: calculate target clock dynamically, make code more readable
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Replace our incomplete w32threads implementation with x264's pthreads
w32threads wrapper.
Relicensed to LGPL with kind permission by Pegasys Inc.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
If the picture queue is empty, or when the calculated delay is 0, frame_timer
is not increased but we are still displaying the old frame. When we eventually
get a frame, where the computed delay is positive, so we don't need to drop any
more frames, then it is best to update frame_timer to be as near as the current
time as it can.
This way we dont't have to wait several frames to add the necesarry delays to
frame_timer to reach current time, therefore there are no extra frame drops
after reaching a positive delay.
Signed-off-by: Marton Balint <cus@passwd.hu>
The current impementation of early frame drops (dropping frames before adding
them to the picture queue) has multiple problems:
Even after gettin A-V sync, the frame droping continues until
VideoState->skip_frames reaches 1, which can take a lot of time causing useless
additional frame drops and bad AV-sync. This issue can be easily triggered with
for example changing the audio stream.
Also video_refresh currenly does not handle early skipped frames in every case,
for example if we skip a frame, then the last frame duration calculation will
compute the duration of the sum of the skipped frame and the duration of the
frame before that, and in compute_target_delay we may multiply this unusually
big delay.
Signed-off-by: Marton Balint <cus@passwd.hu>
Since target clock is based on the current A-V delay, it is better calculate it
when we actually need it rather than when we put a picture in the picture
queue.
The patch also makes a code a bit more readable by renaming some delay
variables to duration, and converting compute_target_time to a delay
calculating function which does not modify the state. Factoring out the
iteration of the pictq to standalone function is also done in this patch.
Signed-off-by: Marton Balint <cus@passwd.hu>
* qatar/master:
prores: get correct size for coded V plane if alpha is present
prores: do not set pixel format on codec init
pthread: prevent updating AVCodecContext from itself in frame_thread_free
pthread: copy coded frame dimensions in update_context_from_thread
vp8: prevent read from uninitialized memory in decode_mvs
vp8: force reallocation in update_thread_context after frame size change
vp8: fix return value if update_dimensions fails
matroskadec: fix out of bounds write
adpcmdec: calculate actual number of output samples for each decoder.
adpcmdec: check remaining buffer size before decoding next block in the ADPCM IMA WAV decoder.
adpcmdec: do not terminate early in ADPCM IMA Duck DK3 decoder.
adpcmdec: remove unneeded buf_size==0 check.
adpcmdec: remove unneeded zeroing of *data_size
dnxhdenc: fixed signed multiplication overflow
Conflicts:
tests/ref/fate/prores-alpha
tests/ref/fate/truemotion1-24
Merged-by: Michael Niedermayer <michaelni@gmx.at>
In particular: set output timebase to 1/output_sample_rate, fix output
PTS computation, and do not forget to copy properties values from the
input buffer.
The pixel format is not known until the frame header is parsed.
Guessing it here only causes trouble for the caller if the guess
turns out to be wrong (and actually causes very wrong output by
avconv/avplay).
Signed-off-by: Mans Rullgard <mans@mansr.com>
