[FFmpeg-devel] [PATCH 1/2] h261, h263 decoders: convert to RL_VLC.
Ronald S. Bultje
rsbultje at gmail.com
Sun Aug 31 15:24:24 CEST 2014
On Sun, Aug 31, 2014 at 8:54 AM, Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> On Sun, Aug 31, 2014 at 08:37:56AM -0400, Ronald S. Bultje wrote:
> > On Sun, Aug 31, 2014 at 8:27 AM, Reimar Döffinger <
> Reimar.Doeffinger at gmx.de>
> > wrote:
> > > On Sun, Aug 31, 2014 at 02:21:46PM +0200, Reimar Döffinger wrote:
> > > > This has a few TODOs like adjusting the run tables instead
> > > > of having a -1 in the decode loop.
> > > > But please review the general idea.
> > >
> > > I forgot to say: this is the first time I use this API,
> > > and I was quite confused.
> > > And in particular I am not sure how much I can safely read
> > > from the cache without updating...
> > 25, right? Anything less, we'd advance a byte in update.
> Well, but then there is the question how many GET_VL_RLC
> may end up using at most.
> And that will depend on even more, for example, how much will
> it have used at most when you get into the escape path?
> I think this is quite tricky if you want to do it optimally,
> so I just guessed so far...
I'm not sure that's a good idea. So, basically, you want to make
pessimistic assumptions, not 90% worst or anything, just "worst-possible
case". Because after all, any bitstream that did decode correctly before
should still decode correctly after.
So If you want to use GET_VL_RLC, just assume it'll consume the max number
bits within its vlc code set. Once every 1/n_entries times, it actually
will (assuming random input), and you want to keep handling that case. If
you want to specifically optimize short codes, make a branch (i.e. if
code_len < .. or if code_prefix < ... or whatever).
More information about the ffmpeg-devel