[FFmpeg-devel] [PATCH 2/2] MxPEG decoder

[Michael Niedermayer]

On Wed, Nov 10, 2010 at 06:08:47PM +0300, Anatoly Nenashev wrote:
> On 10.11.2010 17:59, Michael Niedermayer wrote:
>> On Wed, Nov 10, 2010 at 05:26:04PM +0300, Anatoly Nenashev wrote:
>>    
>>> On 09.11.2010 04:14, Michael Niedermayer wrote:
>>>      
>>>> On Mon, Nov 08, 2010 at 05:27:18PM +0300, Anatoly Nenashev wrote:
>>>>
>>>>        
>>>>> On 07.11.2010 16:28, Michael Niedermayer wrote:
>>>>>
>>>>>          
>>>>>> On Sat, Nov 06, 2010 at 05:10:41AM +0300, Anatoly Nenashev wrote:
>>>>>>      [...]
>>>>>>
>>>>>>            
>>>>>>> +        /* search for start marker - 0xff */
>>>>>>> +        while (mxg->current_pos + FF_INPUT_BUFFER_PADDING_SIZE<    mxg->buffer_size) {
>>>>>>> +            uint32_t x;
>>>>>>> +            uint8_t *p = mxg->buffer + mxg->current_pos;
>>>>>>> +
>>>>>>> +            ret = get_partial_buffer(s->pb, p, 4);
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>> calling this every 4 bytes is slow
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>> Replaced by 4-times get_byte calls.
>>>>>
>>>>>          
>>>> i suggest you look at START/STOP_TIMER
>>>> they are quite usefull to find out what is fast and what is slow
>>>>
>>>>
>>>>        
>>> I've used it. 4-times get_byte() is slower than get_partial_buffer for 4
>>> bytes. Now I've reimplemented this code to read 16 bytes at once. "16
>>>      
>> try with 256 bytes
>>
>>    
> If to read more than 16 byte at once then it is required additional  
> operations of memcpy and memmove.
> For example. If I read buffer of 256 bytes in which audio packet  
> available in position 10 and size 100 then I need
> to copy data of size 100-10=90 in new audio packet and move data of size  
> 256-100=156 in internal buffer. I think this may reduce the performance.

you dont need to move it.

and the overhead of all your code executed once every 16 bytes will reduce
performance more than an occasional memcpy(). That said it can be done
without memcpy by accessing the internal buffer but iam not suggesting this
to be done. What i suggest is that you dont execute complex code every few bytes

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101110/239fa129/attachment.pgp>