[FFmpeg-devel] Command-lineparameters usedtoo latefor has_codec_parameters()
Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL
Fri Jan 16 14:48:28 CET 2009
Luca Abeni wrote:
> Hi Alexandre,
> Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL wrote:
>>> According to the documentation in avcodec.h, in decoding pix_fmt is set by
>>> libavcodec so no, I do not think it is possible (and I think setting pix_fmt
>>> before reading any frame would not make much sense).
>> Even if I pre-set it to the same value that I know is in the bitstream ?
>> Then, ffmpeg is unable to avoid the read-in-memory of a full GOP at the
>> beginning ?
> I might be wrong here (and I hope people will correct me if I am wrong), but
> I think pix_fmt is set as soon as the H.263 codec is initialised (by calling
> ff_h263_decode_init(). So, you do not really need a whole GOP (a whole GOP
> will be needed, I think, for setting width and height, but you can set them
> in rtp_parse_open()). But I do not know if it is possible to decode a stream
> if you did not receive the first frame of the GOP (I mean: if you do not
> decode the I frame, you cannot decode the P frames depending on it, right?).
> But I am not sure about this...
OK, just checked: indeed, ff_h263_decode_init() immediately sets the
pix_fmt (to yuv420p by default). But the problem is that
ff_h263_decode_init() is only called on the first try_decode_frame(),
which itself is triggered by the FALSE returned from has_codec_parameters().
So it seems we have a chicken-and-egg issue: we decide that
bitstream-based guessing is due based on the absence of some parameters,
*then* we get these parameters from codec init (after reading just 1
frame), *then* we wait for a full GOP for no reason... Strange, eh ?
More information about the ffmpeg-devel