[FFmpeg-devel] [PATCH 1/2] h261, h263 decoders: convert to RL_VLC.
Ronald S. Bultje
rsbultje at gmail.com
Sun Aug 31 16:50:34 CEST 2014
On Sun, Aug 31, 2014 at 9:38 AM, Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> On Sun, Aug 31, 2014 at 09:24:24AM -0400, Ronald S. Bultje wrote:
> > On Sun, Aug 31, 2014 at 8:54 AM, Reimar Döffinger <
> Reimar.Doeffinger at gmx.de>
> > wrote:
> > > 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
> > 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).
> The point is we already _have_ those branches.
> And the escape code is one specific VLC code.
> So we should know _exactly_ how much we consumed, and can rely on that.
> You just have to find all the proper information.
Ah, ok, then it's fine, cool.
More information about the ffmpeg-devel