[FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.
liuchh83 at gmail.com
Tue Feb 26 05:07:01 EET 2019
Attach one of my massif outputs.
The max memory usage is approximately 22.05MB. And the *extra *heap is not
The peak snapshot is the 7th. The H.264 decoder is responsible for 86.11%
of the memory usage.
The update_frag_index is responsible for 78,264 bytes. And the relevant
code is at line 1276 instead of line 1257. In my opinion, this is usual. It
create fragment items for every ‘moof’.
Thanks and Regards,
On Mon, Feb 25, 2019 at 7:07 PM C.H.Liu <liuchh83 at gmail.com> wrote:
> Would you mind share your input file? I still can’t reproduce the OOM.
> I have tried several types of mp4.
> I also tried to create a file like yours. According to the snapshot, seems
> it has no ‘sidx’ box and enable ‘use_mfra_for’.
> Massif didn’t report update_frag_index() function. I didn’t see an extra
> heap as big as here, either.
> The code around line 1257 creates an array of fragment indices for each
> track. It should be very small. Interesting.
> Sorry for disturbing.
> Thanks and Regards,
> Michael Niedermayer <michael at niedermayer.cc> 于2019年2月23日周六 下午5:35写道：
>> On Sat, Feb 23, 2019 at 03:22:08PM +0800, C.H.Liu wrote:
>> > I can’t reproduce the OOM. Is it possible the problem relate to a
>> > clip?
>> > Here is my test steps:
>> > 1. To ensure that it’s not affected by caches, delete all except the
>> > dir in my code dir. Then checkout again.
>> > 2. To ensure that the latest test clips are used. make fate-rsync
>> > SAMPLES=fate-suite/
>> > 3. To ensure that OS environment is clean, run test in docker.
>> > Below is one of my test logs:
>> heres some massif output that should show where the exessive allocation
>> (note the box has 14gb free and the input file is less than 4kb size)
>> n2: 8487679 (heap allocation functions) malloc/new/new, --alloc-fns,
>> n2: 8298639 0x12AAF2B: av_malloc (mem.c:87)
>> n1: 8294364 0x12AAF59: av_malloc (mem.c:126)
>> n1: 8294364 0x12AB24B: av_mallocz (mem.c:238)
>> n1: 8294364 0x12AB122: av_mallocz_array (mem.c:195)
>> n1: 8294364 0x743749: update_frag_index (mov.c:1257)
>> n1: 8294364 0x756174: read_tfra (mov.c:7293)
>> n1: 8294364 0x7563F0: mov_read_mfra (mov.c:7344)
>> n1: 8294364 0x743B01: mov_read_moof (mov.c:1338)
>> n1: 8294364 0x754A0C: mov_read_default (mov.c:6841)
>> n1: 8294364 0x756596: mov_read_header (mov.c:7385)
>> n1: 8294364 0x8254BB: avformat_open_input (utils.c:631)
>> n1: 8294364 0x415CE6: open_input_file (ffmpeg_opt.c:1104)
>> n1: 8294364 0x41F666: open_files (ffmpeg_opt.c:3273)
>> n1: 8294364 0x41F7F8: ffmpeg_parse_options
>> n0: 8294364 0x43DFC6: main (ffmpeg.c:4869)
>> n0: 4275 in 7 places, all below massif's threshold (01.00%)
>> n0: 189040 in 8 places, all below massif's threshold (01.00%)
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>> Its not that you shouldnt use gotos but rather that you should write
>> readable code and code with gotos often but not always is less readable
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4288 bytes
Desc: not available
More information about the ffmpeg-devel