[FFmpeg-devel] [PATCH] Fix return value for incomplete H264 frame packets

Laurent Aimar fenrir
Thu Aug 26 21:14:38 CEST 2010

On Thu, Aug 26, 2010 at 08:39:43PM +0200, Reimar D?ffinger wrote:
> On Thu, Aug 26, 2010 at 09:35:57AM +0200, Laurent Aimar wrote:
> >  Unless I missed something, the only case where it is needed is with N-VOP.
> > If so, I think that if the mpeg4 decoder was changed to output pictures on
> > N-VOP (not on the one for packed bitstream, they can be distinguished) it
> > would solve the issue. And I find it more logical (completly skipped frames are
> > not silently rejected in other decoders, no?).
> I don't think it is FFmpeg policy to waste performance for a questionable convenience
> gain.
 I don't see how a call to reget_buffer() will a be "waste of performance"
and storing the fact that it is a N-VOP could probably be done in
AVFrame::pict_type (seems the right field to me).

> >  It can be argued that it is also needed for bitstream errors, but I don't think
> > it is really useful for what you want to achieve: if you have bitstream errors, it
> > is highly probable that frames are also lost at the transport level or that you
> > cannot detect the content of a buffer (frame vs field). In which case it is pointless
> > to only detect some of the errors.
> The bitstream error stuff is mostly because "we" have wanted this since a long time,
> it can be used by players to e.g. skip frames before the first keyframe at the start
> of the file (as e.g. some WMV from the Microsoft HD showcase had), or generally
> decide not to show any potentially broken files or just to more easily verify
> that some files aren't broken (e.g. after a download) in an automated way.
 IMHO, it has nothing to do with the reported issue (the fixed frame rate stuff).
I think they are distinct issues.


More information about the ffmpeg-devel mailing list