[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