[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-datatype-dev
Subject:    [datatype-dev] Re: CR: PR 269661: part 2 of 3 Fragmented allocation
From:       Sujeet Kharkar <skharkar () real ! com>
Date:       2011-07-18 23:36:38
Message-ID: 4E24C386.5090804 () real ! com
[Download RAW message or body]

Looks good.

--Sujeet
On 7/18/2011 4:07 PM, Jamie Gordon wrote:
> Synopsis
> ========
> Reduce memory fragmentation in mp4 filewriter
>
> Branches: PRODUCER_14_0_RN, HEAD
> Suggested Reviewer: Sujeet, Dean
>
>
> Description
> ===========
> Atoms that require a very large number of entries (such as one per
> frame or ~1/2 frames) were making many many allocations, which need to
> be maintained until the file is written. This causes an enormous amount
> of heap fragmentation with the MS allocator, even with LFH enabled.
>
> Fix is to increase the allocation size and do it much less frequently.
> The structure used already handles this, but all atoms were using the
> default block size 256, which is much too small for stts, ctts, stsz,
> and stco/co64. I increased the block size to 4K for stts/ctts and stsz,
> and 1K for stco.
>
> These size choices are somewhat arbitrary but seem to be doing quite
> well.
> stsz is usually one entry per frame for video.
> stts/ctts vary a lot depending on codec and encoding parameters, but
> for h.264 tend to average something like one entry per two frames.
> stco is one entry per chunk which is currently just every 20 frames.
>
>
> Files Affected
> ==============
> datatype/mp4/filewriter/mp4atoms.h
>
>
> Testing Performed
> =================
>
> Platforms Tested: win32-i386-vc9/2K3
> Build verified: win32-i386-vc9
>
>
> QA Hints
> ===============
>
>


_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
[prev in list] [next in list] [prev in thread] [next in thread]