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

[DRC <dco...@us...>]

Aye, there's the rub.  I'm not sure if that's possible.  :(  You could
create a progress monitor, but the progress monitor won't be called
between MCUs.  It is only called once for each call to
jpeg_read_scanlines(), so I think the best granularity you could achieve
would be for the progress monitor to be called between each MCU row.
Also, since the MCU column counter is internal, there wouldn't be any
way of tracking the progress in terms of individual MCUs decoded unless
you made a backward-incompatible modification to the library.

I really think the best thing you can do is to use a larger buffer in
order to reduce the ratio of slow to fast MCU decodes to the point that
the slow MCU decodes are an insignificant part of the overall execution
time.  That's essentially what the TurboJPEG wrapper does.

On 6/16/17 2:44 PM, Leon Scroggins via Libjpeg-turbo-devel wrote:
> 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...
> <mailto: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...>
>     <mailto: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...
>     <mailto:Lib...@li...>
>     https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel
>     <https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel>
> 
> 
> 
> 
> -- 
> 
>  •  Leon Scroggins
> 
>  • sc...@go... <mailto:sc...@go...>