[FFmpeg-devel] [PATCH 1/2] h261, h263 decoders: convert to RL_VLC.

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sun Aug 31 16:51:00 CEST 2014


On Sun, Aug 31, 2014 at 03:38:21PM +0200, Reimar Döffinger wrote:
> 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:
> > > > > 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).
> 
> 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.

If I checked things correctly, luckily that makes no difference.
The escape code is 7 bits, the full one is 9 bits.
However we either read 15 or 19 additional bits, so we do
not need to update in the 15 bit and we need to in the 19 bit case
no matter what.


More information about the ffmpeg-devel mailing list