Hi, On Sun, Aug 31, 2014 at 8:54 AM, Reimar Döffinger <reimar.doeffin...@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.doeffin...@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). Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
