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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sun Aug 31 15:38:21 CEST 2014


On Sun, Aug 31, 2014 at 09:24:24AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> 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 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.


More information about the ffmpeg-devel mailing list