Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

> On 2 Jan 2019, at 19:18, Steinar H. Gunderson  
> wrote:
> 
> On Wed, Jan 02, 2019 at 04:34:28PM +0100, Nicolas George wrote:
>> This is not a leak, it is short-sightedness by leak detectors.
> 
> Most modern leak detectors distinguish between memory that's still reachable
> (usually not a leak) and memory that's not (almost always a leak). This sounds
> like an example of the former.
> 

Thanks Steinar. Personally I would always want the tool I am using to tell me 
about memory allocations I had made and not freed, but I guess it partly comes 
down to personal taste!

More importantly in this case though, according to the documentation it is 
necessary to call x265_cleanup() in order for the next encoder to be able to 
use a new CU size.

Here is the original x265 ticket:

https://bitbucket.org/multicoreware/x265/issues/110/add-an-api-to-reset-cached-variables-so
 


I don't know whether encoders can be opened/closed in this manner with 
different CU sizes using the ffmpeg command line tool, but they could be for 
other applications linking to the ffmpeg libraries.

So even if it's not deemed necessary to add an API for the purpose of avoiding 
spurious memory leak reports (fair enough), it might be useful for the above, 
whether though something similar to my patch or maybe just a simple global 
function.

From the docs:

https://x265.readthedocs.io/en/default/api.html 


(Search for x265_cleanup)

Regards

Oliver
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Steinar H. Gunderson]

On Wed, Jan 02, 2019 at 04:34:28PM +0100, Nicolas George wrote:
> This is not a leak, it is short-sightedness by leak detectors.

Most modern leak detectors distinguish between memory that's still reachable
(usually not a leak) and memory that's not (almost always a leak). This sounds
like an example of the former.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

> On 2 Jan 2019, at 18:38, Nicolas George  wrote:
> 
> Oliver Collyer (2019-01-02):
>> Can you clarify what you mean by "static variables are unacceptable". 
>> They're all over the place in ffmpeg (random example 
>> https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281526/libavcodec/ffjni.c
>>  
>> )...
>>  what am I missing?
> 
> The JNI stuff is hardly an example of good practice, we are stuck with
> java's awful design.
> 
> For the rest, they are not static variables, they are static constants.
> 
> There are a few cases 
> 

Ok thanks for the clarification about the approach taken for static variable 
usage and memory freeing in the ffmpeg project Nicolas, that is useful to know.

So I could re-write the patch to not use static variables, and I'm perfectly 
happy to do so, but there is no point, right?

Regards

Oliver

> Regards,
> 
> -- 
>  Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Hendrik Leppkes]

On Wed, Jan 2, 2019 at 4:33 PM Oliver Collyer  wrote:
>
> Can you clarify what you mean by "static variables are unacceptable". They're 
> all over the place in ffmpeg (random example 
> https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281526/libavcodec/ffjni.c
>  
> )...
>  what am I missing?
>

We try to clean them up where we can, and new ones are unacceptable.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Nicolas George]

Oliver Collyer (2019-01-02):
> Can you clarify what you mean by "static variables are unacceptable". They're 
> all over the place in ffmpeg (random example 
> https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281526/libavcodec/ffjni.c
>  
> )...
>  what am I missing?

The JNI stuff is hardly an example of good practice, we are stuck with
java's awful design.

For the rest, they are not static variables, they are static constants.

There are a few cases 

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Nicolas George]

Oliver Collyer (2019-01-02):
> I guess the OS frees it up on application exit, but that seems a messy
> way to be going about things, I guess that's why the developers of
> x265 provided the function.

There is nothing messy about it. Also, other parts of the project do
things like that without freeing, and even without providing an API to
free it. Including internal components.

This is not a leak, it is short-sightedness by leak detectors.

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

>>> +static int open_enc_count = 0;
>>> +static pthread_mutex_t open_enc_count_lock = PTHREAD_MUTEX_INITIALIZER;
>> 
>> Static variables are unacceptable. And indeed, these are wrong: you are
>> counting several instances, possibly of different APIs, but with a
>> single counter.
>> 
> 
> Yes, I see what you mean.
> 

Althoughthe data that x265_cleanup() frees is static anyway (see 
Bitcost::Destroy()), so I think this is actually desired behaviour i.e. this is 
global state across all APIs that should be freed up before exit.

Can you clarify what you mean by "static variables are unacceptable". They're 
all over the place in ffmpeg (random example 
https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281526/libavcodec/ffjni.c
 
)...
 what am I missing?

Regards

Oliver



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

> On 2 Jan 2019, at 18:05, Nicolas George  wrote:
> 
> Oliver Collyer (2019-01-02):
>> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> 
> Please use git format-patch to prepare your patches. Also please try to
> convince your MUA to use text/plain for patches.
> 
>> +static int open_enc_count = 0;
>> +static pthread_mutex_t open_enc_count_lock = PTHREAD_MUTEX_INITIALIZER;
> 
> Static variables are unacceptable. And indeed, these are wrong: you are
> counting several instances, possibly of different APIs, but with a
> single counter.
> 

Yes, I see what you mean.

> The way I read things, the leak you are trying to fix does not exist: it
> is global state, kept until the end but not lost.
> 

Well, as per my earlier post - x265 provides a function to free up this memory 
which otherwise isn't freed up, hence memory debuggers report these allocations 
as leaks, and ffmpeg provides no mechanism to call this function.

I guess the OS frees it up on application exit, but that seems a messy way to 
be going about things, I guess that's why the developers of x265 provided the 
function.

> Regards,
> 
> -- 
>  Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Nicolas George]

Oliver Collyer (2019-01-02):
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c

Please use git format-patch to prepare your patches. Also please try to
convince your MUA to use text/plain for patches.

> +static int open_enc_count = 0;
> +static pthread_mutex_t open_enc_count_lock = PTHREAD_MUTEX_INITIALIZER;

Static variables are unacceptable. And indeed, these are wrong: you are
counting several instances, possibly of different APIs, but with a
single counter.

The way I read things, the leak you are trying to fix does not exist: it
is global state, kept until the end but not lost.

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

> On 2 Jan 2019, at 16:03, Oliver Collyer  wrote:
> 
> 
> 
>> On 2 Jan 2019, at 12:58, Oliver Collyer  wrote:
>> 
>> Hello
>> 
>> So this time I'm reporting some potential memory leaks in the x265 encoder. 
>> There are a few hundred following a short encode session, but all seem to 
>> have the same call stack as below but varying allocation sizes.
>> 
>> I am calling avcodec_open2() to open the encoder and then 
>> avcodec_free_context() to clean it up afterwards, as per the documentation.
>> 
>> My code is built against the latest from 
>> https://github.com/ShiftMediaProject/FFmpeg 
>>  
>> > > and I'm using Visual Leak 
>> Detector to detect the leaks.
>> 
>> Or would this be better posted in whatever mailing list x265 development 
>> uses?
>> 
>> Regards
>> 
>> Oliver
>> 
>> -- Block 63379 at 0x8CC3A370: 262225 bytes --
>> Leak Hash: 0x95CBF73D, Count: 15, Total 3933375 bytes
>> Call Stack:
>>   ucrtbased.dll!aligned_malloc()
>>   emu-server.exe!x265::x265_malloc() + 0x48 bytes
>>   emu-server.exe!x265::BitCost::setQP() + 0x9A bytes
>>   emu-server.exe!x265::Search::setLambdaFromQP() + 0xF8 bytes
>>   emu-server.exe!x265::Analysis::compressIntraCU() + 0x87E bytes
>>   emu-server.exe!x265::Analysis::compressCTU() + 0xC8B bytes
>>   emu-server.exe!x265::FrameEncoder::processRowEncoder() + 0xFA7 bytes
>>   emu-server.exe!x265::FrameEncoder::processRow() + 0x128 bytes
>>   emu-server.exe!x265::WaveFront::findJob() + 0x125 bytes
>>   emu-server.exe!x265::WorkerThread::threadMain() + 0x18A bytes
>>   emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0x14A bytes
>>   emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0xD2 bytes
>>   KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes
>>   ntdll.dll!RtlUserThreadStart() + 0x21 bytes
>> Data:
>>   70 A3 C3 8C4B 02 00 00ED ED ED EDED ED ED ED p...K... 
>> 
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>>   7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
>> }.}.}.}.
>> 
>> 
>> Visual Leak Detector detected 236 memory leaks (25197214 bytes).
> 
> So looking into this some more, according to the x265 docs:
> 
> "When the application has completed all encodes, it should call 
> x265_cleanup() to free process global, particularly if a memory-leak 
> detection tool is being used. x265_cleanup() also resets the saved CTU size 
> so it will be possible to create a new encoder with a different CTU size:
> /* x265_cleanup:
> * release library static allocations, reset configured CTU size */
> void x265_cleanup(void);"
> 
> This function explicitly frees the allocations being reported by VLD above.
> 
> I cannot see that this done anywhere by the ffmpeg libraries though. Maybe 
> this is not considered significant as the OS deals with this on exit?
> 
> I did notice in libx265.c...
> 
> AVCodec ff_libx265_encoder = {
>.name = "libx265",
>.long_name= NULL_IF_CONFIG_SMALL("libx265 H.265 / HEVC"),
>.type = AVMEDIA_TYPE_VIDEO,
>.id   = AV_CODEC_ID_HEVC,
>.init = libx265_encode_init,
>.init_static_data = libx265_encode_init_csp,
>.encode2  = libx265_encode_frame,
>.close= libx265_encode_close,
>.priv_data_size   = sizeof(libx265Context),
>.priv_class   = ,
>.defaults = x265_defaults,
>.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
>.wrapper_name = "libx265",
> };
> 
> ...there is the concept of initialisation of static data, but looking at 
> AVCodec there is no similar cleaning-up function (confirmed by looking at 
> 

Re: [FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

> On 2 Jan 2019, at 12:58, Oliver Collyer  wrote:
> 
> Hello
> 
> So this time I'm reporting some potential memory leaks in the x265 encoder. 
> There are a few hundred following a short encode session, but all seem to 
> have the same call stack as below but varying allocation sizes.
> 
> I am calling avcodec_open2() to open the encoder and then 
> avcodec_free_context() to clean it up afterwards, as per the documentation.
> 
> My code is built against the latest from 
> https://github.com/ShiftMediaProject/FFmpeg 
>  
>  > and I'm using Visual Leak 
> Detector to detect the leaks.
> 
> Or would this be better posted in whatever mailing list x265 development uses?
> 
> Regards
> 
> Oliver
> 
> -- Block 63379 at 0x8CC3A370: 262225 bytes --
>  Leak Hash: 0x95CBF73D, Count: 15, Total 3933375 bytes
>  Call Stack:
>ucrtbased.dll!aligned_malloc()
>emu-server.exe!x265::x265_malloc() + 0x48 bytes
>emu-server.exe!x265::BitCost::setQP() + 0x9A bytes
>emu-server.exe!x265::Search::setLambdaFromQP() + 0xF8 bytes
>emu-server.exe!x265::Analysis::compressIntraCU() + 0x87E bytes
>emu-server.exe!x265::Analysis::compressCTU() + 0xC8B bytes
>emu-server.exe!x265::FrameEncoder::processRowEncoder() + 0xFA7 bytes
>emu-server.exe!x265::FrameEncoder::processRow() + 0x128 bytes
>emu-server.exe!x265::WaveFront::findJob() + 0x125 bytes
>emu-server.exe!x265::WorkerThread::threadMain() + 0x18A bytes
>emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0x14A bytes
>emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0xD2 bytes
>KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes
>ntdll.dll!RtlUserThreadStart() + 0x21 bytes
>  Data:
>70 A3 C3 8C4B 02 00 00ED ED ED EDED ED ED ED p...K... 
> 
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
>7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
> }.}.}.}.
> 
> 
> Visual Leak Detector detected 236 memory leaks (25197214 bytes).

So looking into this some more, according to the x265 docs:

"When the application has completed all encodes, it should call x265_cleanup() 
to free process global, particularly if a memory-leak detection tool is being 
used. x265_cleanup() also resets the saved CTU size so it will be possible to 
create a new encoder with a different CTU size:
/* x265_cleanup:
 * release library static allocations, reset configured CTU size */
void x265_cleanup(void);"

This function explicitly frees the allocations being reported by VLD above.

I cannot see that this done anywhere by the ffmpeg libraries though. Maybe this 
is not considered significant as the OS deals with this on exit?

I did notice in libx265.c...

AVCodec ff_libx265_encoder = {
.name = "libx265",
.long_name= NULL_IF_CONFIG_SMALL("libx265 H.265 / HEVC"),
.type = AVMEDIA_TYPE_VIDEO,
.id   = AV_CODEC_ID_HEVC,
.init = libx265_encode_init,
.init_static_data = libx265_encode_init_csp,
.encode2  = libx265_encode_frame,
.close= libx265_encode_close,
.priv_data_size   = sizeof(libx265Context),
.priv_class   = ,
.defaults = x265_defaults,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
.wrapper_name = "libx265",
};

...there is the concept of initialisation of static data, but looking at 
AVCodec there is no similar cleaning-up function (confirmed by looking at 
avcodec/allcodecs.c).

Is there a precedent for how to handle something like this - I don't see how I 
can access the x265_api pointer in order to call the x265_cleanup 

[FFmpeg-devel] Memory leaks using x265 encoder

[Oliver Collyer]

Hello

So this time I'm reporting some potential memory leaks in the x265 encoder. 
There are a few hundred following a short encode session, but all seem to have 
the same call stack as below but varying allocation sizes.

I am calling avcodec_open2() to open the encoder and then 
avcodec_free_context() to clean it up afterwards, as per the documentation.

My code is built against the latest from 
https://github.com/ShiftMediaProject/FFmpeg 
 
> and I'm using Visual Leak 
Detector to detect the leaks.

Or would this be better posted in whatever mailing list x265 development uses?

Regards

Oliver

-- Block 63379 at 0x8CC3A370: 262225 bytes --
  Leak Hash: 0x95CBF73D, Count: 15, Total 3933375 bytes
  Call Stack:
ucrtbased.dll!aligned_malloc()
emu-server.exe!x265::x265_malloc() + 0x48 bytes
emu-server.exe!x265::BitCost::setQP() + 0x9A bytes
emu-server.exe!x265::Search::setLambdaFromQP() + 0xF8 bytes
emu-server.exe!x265::Analysis::compressIntraCU() + 0x87E bytes
emu-server.exe!x265::Analysis::compressCTU() + 0xC8B bytes
emu-server.exe!x265::FrameEncoder::processRowEncoder() + 0xFA7 bytes
emu-server.exe!x265::FrameEncoder::processRow() + 0x128 bytes
emu-server.exe!x265::WaveFront::findJob() + 0x125 bytes
emu-server.exe!x265::WorkerThread::threadMain() + 0x18A bytes
emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0x14A bytes
emu-server.exe!x265::Thread::`scalar deleting destructor'() + 0xD2 bytes
KERNEL32.DLL!BaseThreadInitThunk() + 0x14 bytes
ntdll.dll!RtlUserThreadStart() + 0x21 bytes
  Data:
70 A3 C3 8C4B 02 00 00ED ED ED EDED ED ED ED p...K... 

7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.
7D 01 7D 017D 01 7D 017D 01 7D 017D 01 7D 01 }.}.}.}. 
}.}.}.}.


Visual Leak Detector detected 236 memory leaks (25197214 bytes).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel