Re: [Libjpeg-turbo-devel] passing the right amount of data to libjpeg-turbo

[Leon S. <sc...@go...>]

Thanks! Is there a good way to ensure that fill_input_buffer is called
(i.e. the buffer is empty) at the start of an MCU? Otherwise I could
imagine that we might use a large enough value, but still end up hitting
the slow case because we exhaust our buffer in the middle of the first MCU.

On Fri, Jun 16, 2017 at 3:17 PM, DRC via Libjpeg-turbo-devel <
lib...@li...> wrote:

> Referring to the code in jdhuff.c, the slow case will be used if:
> (1) There are fewer than cinfo->blocks_in_MCU * 128 bytes in the buffer, or
> (2) There is an unread marker from a previous entropy decode (such as a
> restart marker), or
> (3) The fast case encounters a marker (such as a restart marker)
>
> There is nothing you can do about (2) and (3), but you should be able to
> minimize the use of the slow path by ensuring that at least
> cinfo->blocks_in_MCU * 128 bytes are in the buffer.  You may not be able
> to ensure that at the end of the image, though.
>
> On 6/16/17 11:29 AM, Leon Scroggins via Libjpeg-turbo-devel wrote:
> > What is the best way to determine how much data to pass to
> > fill_input_buffer? Often we are streaming data, so we need to copy it
> > into a buffer before providing it. We've noticed that depending on the
> > amount of data in the buffer, libjpeg-turbo will call either call
> > decode_mcu_slow or decode_mcu_fast, which can make a difference in
> > decoding speed. We can always use a large buffer in order to make us
> > more likely to hit the fast case, but we can still hit the slow case
> > sometimes. I was wondering if there might be some query we can use to
> > determine the ideal amount of data to supply in a given call to
> > fill_input_buffer so that we never hit the slow case?
> >
> > --
> >
> >  •  Leon Scroggins
> >
> >  • sc...@go... <mailto:sc...@go...>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Libjpeg-turbo-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel
>



-- 

 •  Leon Scroggins

 •  sc...@go...