[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