On Wed, 2010-04-14 at 09:33 +0300, Uri Lublin wrote:
> On 04/12/2010 09:57 PM, Alexander Larsson wrote:
> > I did some simple testing of the new mjpeg encoder.
> > Showing the youtube "will it blend - ipad" video i got quite better
> > compression (24k per frame average as opposed to 35k before), but the
> > code used a bit more cpu (9.8 msec per frame where it was 4.2 before). I
> > made a simple change in the libjpeg code to make it a bit faster, but we
> > might still be able to tweak this a bit in favour of performance rather
> > than compression if thats what we want.
> >
>
> Hi Alex,
>
> Nice.
>
> In client/mjpeg_decoder.cpp -> decode_data(), there is a code that memmove
> data
> to the beginning of the buffer.
>
> Do you think we can gain better performance by actually implementing
> _cinfo.src
> functions ? This way we may be able to avoid (some) memory copying, e.g. by
> using a circular-buffer (and modulo calculation) or maybe even with no
> internal
> buffer.
In current use we actually always pass an entire frame of data to
decode_data() each time. I think rather than doing some fancy buffer
work we could just special case that case and avoid copying data at all.
i.e. if there is no existing data, just set _jsrc.next_input_byte to
point to to data, and if not everything is copied (unlikely given the
above), just copy the remainder into _data afterwards.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
[email protected] [email protected]
He's a gun-slinging coffee-fuelled inventor from the Mississippi delta. She's
a bloodthirsty insomniac doctor from a different time and place. They fight
crime!
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
