Hi, On Thu, Dec 22, 2011 at 5:09 AM, Justin Ruggles <[email protected]>wrote:
> On 12/22/2011 01:38 AM, Ronald S. Bultje wrote: > > > Hi, > > > > On Wed, Dec 21, 2011 at 10:36 PM, Ronald S. Bultje <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > > > On Wed, Dec 21, 2011 at 7:32 PM, Justin Ruggles > > <[email protected] <mailto:[email protected]>> wrote: > > > > --- > > libavcodec/bytestream.h | 31 ++++++++++++++++++++++++++++++- > > 1 files changed, 30 insertions(+), 1 deletions(-) > > > > > > Will you use this for something? If so, patch OK. If not, I wonder > > whether we should add it... > > For example, I was working on fixing the overreads in the VQA video > decoder. It reads through the packet to get chunk offsets and sizes, > then parses them in a specific order. Having tell and seek would mean we > don't have to manually track the position separately in order to save > the offsets, and we could seek instead of reinit/skip. > > > > > I also just noticed a potential bug in our bytestream2 functions: > > > > if (g->buffer_end - g->buffer < bytes) > > return 0; > > > > This will not return 0 on overreads, but rather repeat the last byte. > > I'm not sure that's right. I believe peek and read should always read > > the location, but only adjust the offset if we're not yet beyond it. > > This is how bitstream works also. > > > Maybe I'm missing something, but it seems like this is the way it works > currently. If buffer == buffer_end then we're already past the last > valid byte. The only potential odd situation would be, for example, if > we try to read 4 bytes when there are only 3 bytes left it will return 0 > and not increment, and then reading 1 or 2 bytes will still return valid > data. Yeah me sleepyhead. We can measure (later) if performance improves if we make the reads unconditional and only the pointer increment conditional. That also allows making peek() branch-free. Ronald
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
