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

[Michael Niedermayer]

On Wed, Aug 25, 2010 at 04:40:30PM +0200, P?sztor Szil?rd wrote:
> Michael Niedermayer:
> > This discussion is difficult because you invent things that plain dont
> > exist and i have to guess constantly what you actually refer to
> 
> Ok if my expressions confuse you then read $subj...

not any better


> 
> > now please explain where the problem is with calling the decoder again if
> > it did not output a frame?
> 
> As Reimar D?ffinger already wrote at the beginning of this thread:
> > That doesn't work due to
> > a) 0-sized packets in AVI

what do 0 sized packets in avi have to do with the decoder?


> > b) MPEG4 non-coded VOPs

i said already that this case needs some change so the user app knows
when it occurs.
the patch posted does alot more and the discussion also seems to point toward
that there is more.
but noone explains why or what that would be


> > both of which need to be counted for this purpose but do not output frames.
> > Of course it is possible to add special-cases to applications to handle
> > this, but a solution in libavcodec that can be shared seems preferable to
> > me.
> 
> So, with h264 that may be ok, but once the generic wrapper layer hides the
> actual decoder function, there's no way to know if, despite the decoder not
> producing a picture, a frame duration should be waited or not.
> As it has been stated here many times in this discussion.

The packet you get from the demuxer/parser has a pts, dts and a duration
they tell you when to feed it in the decoder, when it will be dislpayed
to the end user and for how long.
if some packets lack this information than its beacause of the incomplete
implementation of timestamp calculation that i have mentioned many times

the decoder will independantly of that tell you via repeat_pict for how long
each frame should be displayed when this information is available
and it should tell be yet not existing means when it outputs a skiped frame
aka n-vop


[...]

> I respect your work on libavcodec but you are repeatedly missing the point in
> this thread. Please stop me sending to read the spec and the code, the
> problem is not there.

the problem either is there or in you not describing what your problem is

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


The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- 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/1ccbfe43/attachment.pgp>