[FFmpeg-devel] h264: dealing with "broken links"

[Michael Niedermayer]

Hi

On Mon, Nov 19, 2007 at 01:39:27PM -0500, Mark Buechler wrote:
> How could this best be handled? Ignore non-IDR I frames until an IDR slice
> is found? 

no, this is the completely wrong direction
i think ive said it many times already, but heres it again

1. all unavailable reference frames must be allocated and guessed from
   available frames (just memcpy them from a random available frame would
   do for now)
2. drop unimportant frames (B frames / theres a priority field in the NAL
   header which could maybe be used)

1. is critically needed, 2. is optional, and 2. alone does not solve anything

unacceptable things:
* add NULL checks at random places the innermost loops seem to be really
  popular if one looks at what some people try to get into svn ...
  this is just WRONG, the missing frames must be allocated and of course
  not in the innermost loops!
* droping non IDR frames (breaks seeking and totally so for videos with
  no closed gops)

also dont to post!


> Would that prevent B frames from being allocated needlessly?
> 
> - Mark.
> 
> On 11/18/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> >
> > On Sun, Nov 18, 2007 at 11:48:43PM +0100, Reinhard Nissl wrote:
> > > Hi,
> > >
> > > in the thread "[PATCH] Enable PAFF decoding", Loren Merritt wrote, that
> > > H.264's "closed gop" implementation are IDR slices. When I start
> > > replaying a VDR recording at an I frame which is coded with IDR slices,
> > > I can successfully watch the recording.
> > >
> > > But I've got some samples from Russia which contain very few IDR coded I
> > > frames so, most often replay starts at an I frame which was coded with
> > > non IDR slices. But in that case, FFmpeg decodes the I frame properly
> > > but then runs out of frames when dealing with the B frame.
> > >
> > > It reports [h264 @ 0xb61bb2f0]warning: first frame is no keyframe
> > > and then gotos to a location in MPV_frame_start() where it allocates a
> > > further frame. This "loop" continues until all 32 frames are allocated,
> > > where replay terminates with an error.
> > >
> > > A debug version would have asserted before entering the loop:
> > >
> > > assert(s->pict_type != B_TYPE); //these should have been dropped if we
> > > don't have a reference
> > >
> > > But I'm a bit pointless where this should have been done. Attached is a
> > > hack which patches pict_type to P_TYPE in that case, which makes the
> > > sample play properly. As I do not get any errors regarding picture
> > > referencing, I think it is legal to try to replay "broken links"
> > > although they do not start with IDR slices.
> >
> > patch rejected, as the text says b frames should be droped if a reference
> > is missing
> > and changing pict_type to in invalid value is never acceptable
> >
> > [...]
> > --
> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > I am the wisest man alive, for I know one thing, and that is that I know
> > nothing. -- Socrates
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> >
> > iD8DBQFHQPPtYR7HhwQLD6sRAiPEAJ9SzGkZ+sFHyyEqU00+APXkaJPFWACfXlU+
> > aWzSQofqxQO166xxxZSb7Oo=
> > =fpqg
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at mplayerhq.hu
> > http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> >
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> 

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071119/7adf9896/attachment.pgp>