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

[Reimar Döffinger]

On Thu, Aug 26, 2010 at 09:35:57AM +0200, Laurent Aimar wrote:
> Hi,
> 
> On Wed, Aug 25, 2010 at 10:06:47PM +0200, Reimar D?ffinger wrote:
> > On Wed, Aug 25, 2010 at 09:18:06PM +0200, Laurent Aimar wrote:
> > > On Wed, Aug 25, 2010 at 08:30:27PM +0200, Reimar D?ffinger wrote:
> > > > On Wed, Aug 25, 2010 at 08:02:22PM +0200, Laurent Aimar wrote:
> > > > > On Wed, Aug 25, 2010 at 06:24:43PM +0200, Reimar D?ffinger wrote:
> > > > > > On Wed, Aug 25, 2010 at 05:10:13PM +0200, Michael Niedermayer wrote:
> > > > > > Not really, this is just about being able to play any fixed-framerate
> > > > > > content without needing timestamp handling (as in, none at all).
> > > > > > This is "needed" to make one (the most basic) timing method of MPlayer
> > >                  ^^
> > > > > > work with H.264 PAFF.
> > >  + 
> > > > You are asking me exactly the same question again? Seriously?
> > >  You answered about MPEG-4 N-VOP and that's all, while here you says it is
> > > needed for H264. That's why I asked again, either I misunderstood, or you are
> > > wrong here.
> > >  So, from what I understand, it's quite the opposite, you need something for
> > > MPEG-4 because the current 'hack' in mplayer breaks H264. Is that right?
> > 
> > Well, it doesn't really matter which is indicated, the question is more or
> > less always: Why did this data packet not produce a frame, should we increment
> > a "frame" counter or not (I guess that would also be useful for frame-based seeking)?
> > The MPEG-4 N-VOP case is just an example that there are at least two different
> > cases why something does not produce a frame and where that question is
> > answered differently.
>  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.

>  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.