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

[Michael Niedermayer]

On Wed, Aug 25, 2010 at 03:24:53PM +0200, P?sztor Szil?rd wrote:
> Michael Niedermayer:
> > we havent defined what the flags mean, how can any decoder set them if there
> > is no clear definition.
> 
> Ok then I'll wait i think. I'm not familiar with the code enough to be able
> to cover all possible cases for these flags.
>

> > i think you need to read the existing code and need to use clear language
> > "this problem" and the like without ever making any attempt at explaining
> > what that would be is rather useless.
> 
> "this problem" refers to the problem what this thread is all about.

> That is, when an incoming h264 packet contains a non-displayable field only,
> players can't know that they have to re-call the decoder with more data
> immediately, because not enough information is exported to them.

this on its own makes no sense.
you always have to call the decoder with more data if there is no output
also note there is no such thing as a "non-displayable field" you should
read the h264 spec. This discussion is difficult because you invent things
that plain dont exist and i have to guess constantly what you actually refer
to
now please explain where the problem is with calling the decoder again if
it did not output a frame?



> 
> > and repeat_pict refers to outputed pictures, they by definition cannot be
> > first-field-only so that case cannot be needed
> 
> And that's exactly what I'm talking about, that's why repeat_pict can't be
> used to indicate the first-field case, unless hacking a -1 value into it
> which is ugly and would probably break many things.

what you write makes absolutely no sense, setting repeat_pict there to -1
is wrong because it then would contain an incorrect value that does not
represent the actual duration.
Its a mystery to me what you are trying to accomplish. you just pick
random things like a return value or other fields with well specified
meaning and set them to something random.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100825/5b2b86c7/attachment.pgp>