[FFmpeg-devel] [PATCH] avformat/mov: fix hang while seek on a kind of fragmented mp4.

[C.H.Liu]

 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,

Charles

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
> specific
> > clip?
> >
> > Here is my test steps:
> > 1. To ensure that it’s not affected by caches, delete all except the .git
> > 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
> happens:
> (note the box has 14gb free and the input file is less than 4kb size)
>
> snapshot=70
> #-----------
> time=1856698079
> mem_heap_B=8487679
> mem_heap_extra_B=522580313
> mem_stacks_B=0
> heap_tree=peak
> n2: 8487679 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
>  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
> (ffmpeg_opt.c:3313)
>                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
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>