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

Michael Niedermayer michael at niedermayer.cc
Sat Feb 23 11:34:49 EET 2019


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190223/5fd3bd24/attachment.sig>


More information about the ffmpeg-devel mailing list