[FFmpeg-soc] [soc]: r586 - dirac/libavcodec/dirac.c

Michael Niedermayer michaelni at gmx.at
Thu Aug 2 17:24:58 CEST 2007


Hi

On Thu, Aug 02, 2007 at 04:54:50PM +0200, Marco Gerards wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> Hi,
> 
> > On Thu, Aug 02, 2007 at 04:05:47PM +0200, Marco Gerards wrote:
> > [...]
> >> >> +
> >> >> +    if (s->picture.reference) {
> >> >> +        s->refframes[s->refcnt++] = s->picture;
> >> >> +    }
> >> >
> >> > i think refcnt should be checked somewhere so it cannot become too large
> >> 
> >> Yes.  I am waiting for the next update of the specification.  It will
> >> mention the levels that can be used and the amount of reference frames
> >> a certain level can have.
> >
> > a check against REFFRAME_CNT would do IMHO
> >
> > theres also the issue that frames can be lost due to packet loss or whatever
> > or they can be damaged in which case the retirement info for some frames would
> > be lost and we have to guess at some point which frame to kill
> > if we do this decission immedeatly when the max for the level/profile is
> > reached then its more likely that we would choose the wrong frame
> > if we wait a little longer then simply removing the oldest frame is more
> > likely really a unused frame
> 
> Yes, I thought of that too.  According to the specification the oldest
> frame has to be removed when the buffer is full.  But I wonder if that
> means that this also has to be done in the case a frame was lost, or
> specifically in this situation.
> 
> What do you propose?  Make the buffer a bit bigger than what the
> specification says and if even that buffer is overflowed, just kill
> the oldest frames?

yes

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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-soc/attachments/20070802/e6450149/attachment.pgp>


More information about the FFmpeg-soc mailing list