* qatar/master: (22 commits)
g722dec: check output buffer size before decoding
g722dec: cosmetics: reindent/linewrap
g722dec: remove the use of lowres for half-rate decoding.
tta: check for extradata allocation failure in tta demuxer
tta: check for allocation failure of decode_buffer
tta: use correct frame_length calculation.
tta: add support for decoding 24-bit sample format
cosmetics: indentation
tta: remove pointless braces
tta: check output buffer size after adjusting frame length for last frame
tta: fix reading of format in TTA header.
tta: remove useless commented-out lines
tta: check remaining bitstream size while reading unary value
lavf: deprecate AVStream.stream_copy
avconc: split choose_codec() to choose_decoder/choose_encoder.
lavf: simplify by using FFMAX/FFMIN.
mpegenc: add preload private option.
cosmetics: simplify latm_decode_init
latm: avoid unnecessary reinit of the aac decoder
aacdec: initialize sbr context only in new channel elements
...
Conflicts:
avconv.c
libavcodec/resample.c
libavcodec/tta.c
libavformat/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Without this patch each displayed second is incremented 1 frame early,
second 0 is only 24 frames long where as every other second is 25 frames
long.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It is broken because an AVCodecContext can be opened/closed multiple
times, and sample_rate is getting divided by 2 each time that happens.
This removes the only use of lowres for audio.
Note that this will not work in most cases with avconv and avplay due to the
AVCODEC_MAX_AUDIO_FRAME_SIZE limit, but it will decode correctly if given a
large enough output buffer.
The situation was not clear when support was added but it is now:
CELT and Opus are really two different codecs.
The current code supports CELT via libcelt, not Opus.
Signed-off-by: Nicolas George <nicolas.george@normalesup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* cus/stable:
ffplay: add frame drop statistics
ffplay: consider estimated time of filter in early frame drop
ffplay: reimplement early frame drop
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This patch reimplements early frame drop, it is now based on the current
difference between the master clock and the video clock, and the pts of the
current and the last displayed (or skipped) frame. If the frame to be added to
the queue is late after decoding, then we drop it early because later we would
drop it anyway (unless it is the only frame in the picture queue).
The current approach has only one downside that I know of, it does not handle
well when the filters are changing significantly the pts of the frames, because
we compare pts values from filtered and unfiltered frames.
We also start using the pictq_mutex to ensure consistent video_current_pts,
video_current_pts_drift, frame_last_pts, frame_last_dropped_pts and
frame_last_dropped_pos values.
Signed-off-by: Marton Balint <cus@passwd.hu>