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

Reimar Döffinger Reimar.Doeffinger
Wed Aug 25 22:06:47 CEST 2010


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.
I am not sure that is an exhaustive list though (thinking of e.g. VP8 alt-ref frames,
since obviously we won't get an implementation of them that works without hacks).
The one thing I am sure about is that we need more than an error return value
and a returned or not returned frame.
What exactly we need I am not that sure about.



More information about the ffmpeg-devel mailing list