If no data was seen for a stream decoder are returning 0 when fed with
empty packets for flushing. We can stop flushing when the decoder does
not return delayed delayed frames anymore. Changes try_decode_frame()
return value to got_picture or negative error.
CC: libav-stable@libav.org
The H.264 decoder needs SPS and PPS for initialization during
multi-threaded decoding. When probed single-threaded SPS and PPS are
copied to extradata and are available for proper initialization of
the decoder before the first frame is decoded.
This fixes various problems with getting stream info. For example playback of the
file of Ticket88. Multithreaded find_stream_info should be reenabled
once it works correctly
This partly reverts 212fd3a1f1
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The decoders should not only be flushed on EOF or error, but also when
e.g. probe size was reached.
It is best to just always flush by default and only disable it
explicitly when we know that we have everything we need.
Fixes trac ticket #879.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Author: Michael Niedermayer <michaelni@gmx.at>
Date: Thu Nov 3 22:38:10 2011 +0100
lavf: fix null pointer dereference in rdt
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is no longer needed and causes various problems with RTSP
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This works around issues arising from inputs that claim to have a
filesize of 0.
Reported-by: buzz_
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It sets the supplied AVFormatContext pointer to NULL after freeing it,
which is safer and its name is consistent with other lavf functions.
Also deprecate av_close_input_file().
The information is relevant, but under normal circumstances
it raises far too many false alarms.
Signed-off-by: Nicolas George <nicolas.george@normalesup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Adding the thread count in frame level multithreading to has_b_frames
as an additional delay causes more problems than it solves.
For example inconsistent behaviour during timestamp calculation in
libavformat.
Thread count and frame level multithreading are both set by the user.
If the additional delay caused by frame level multithreading needs
to be considered in the calling code it has all information to take
it into account.
Should it become necessary to calculate a maximum delay inside
libavcodec it should be exported as its own field and not reusing
an existing field.
Based on a patch by Michael Niedermayer.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>