"Ronald S. Bultje" <[email protected]> writes: > 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.
If reading is guaranteed to be safe, doing it unconditionally is probably faster since is reduces inter-instruction dependencies. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
