[FFmpeg-devel] AVDictionary for binary tags

[Dmitry Kostjuchenko]

Reimar,

> I find it hard to believe that it would be significant.

It may be less significant on modern PC CPUs and significant on mobile 
platforms with low-power ARM CPUs with slower CPUs and lower memory. 
Moreover converting image to base64 would waste some RAM: besides storage in 
form of string, the process of converting back to binary representation will 
cause additional memory allocation.

In case additional function is added as it was proposed in my patch memory 
allocation is done only once. Storing binary is treight forward - allocate 
memory, read from file, store pointer in dictionary. So it is fast, and 
avoid freq. memory allocations. Even if platform is fast, why spending CPU 
for just passing data :)

Best regards,
Dmitry.

----- Original Message ----- 
From: "Reimar Döffinger" <Reimar.Doeffinger at gmx.de>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Friday, January 20, 2012 10:19 PM
Subject: Re: [FFmpeg-devel] AVDictionary for binary tags


> On Fri, Jan 20, 2012 at 09:52:27PM +0200, Dmitry Kostjuchenko wrote:
>> I was thinking about base64 encoding but favored direct approach (in
>> my case) as it does not require client side to have base64
>> implementation and is much faster.
>
> If it uses FFmpeg it already has a base64 implementation.
>
>> Speed especially important when
>> processing many audio files, like hundreds up to thousands. Then
>> with such amount of files encoding/decoding to base64 just to pass
>> binary data would bring unnecessary overhead. Base64 and similar
>> encoding method is good but for few files.
>
> I find it hard to believe that it would be significant.
> Looking e.g. here:
> http://libb64.cvs.sourceforge.net/viewvc/libb64/libb64/BENCHMARKS?revision=1.2&view=markup
> On somewhat outdated hardware you'd reach over 31 MB/s,
> which is around the disk speed for linear access.
> I really don't see this slowing down your use-case
> noticeably unless those files are on a speedy SSD.
> Though I think our implementation is a good bit from
> optimal.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>