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

Anatoly Nenashev anatoly.nenashev
Wed Nov 10 16:08:47 CET 2010


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.




More information about the ffmpeg-devel mailing list