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

Laurent Aimar fenrir
Thu Aug 26 09:35:57 CEST 2010


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

 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.


More information about the ffmpeg-devel mailing list