2019-04-10 15:00 GMT+02:00, Tobias Rapp <[email protected]>: > On 10.04.2019 14:07, Carl Eugen Hoyos wrote: >> 2019-04-10 14:02 GMT+02:00, Tobias Rapp <[email protected]>: >>> [...] >>> >>> When playing back an SD input file the memory usage of the example >>> binary reaches ~1GiB after less than a minute. >> >>> Running the command with valgrind doesn't show leaked memory. >> >> massif allows to see where the memory is allocated. > > Thanks for the hint. The output file contains a lot of stacktraces that > look like this (full file attached): > > #----------- > snapshot=63 > #----------- > time=29114488380 > mem_heap_B=997350860 > mem_heap_extra_B=55004 > mem_stacks_B=0 > heap_tree=peak > n2: 997350860 (heap allocation functions) malloc/new/new[], --alloc-fns, > etc. > n2: 992362580 0x10B126E: av_malloc (mem.c:87) > n1: 987047128 0x10932AC: av_buffer_allocz (buffer.c:72) > n2: 987047128 0x1093B94: av_buffer_pool_get (buffer.c:312) > n1: 987043001 0x79D970: avcodec_default_get_buffer2 (decode.c:1633) > n1: 987043001 0x79E259: ff_get_buffer (decode.c:1895) > n1: 987043001 0x9E7C1E: ff_thread_get_buffer (pthread_frame.c:890) > n1: 987043001 0x8B428B: decode_frame (huffyuvdec.c:934) > n1: 987043001 0x79B93E: decode_receive_frame_internal > (decode.c:433) > n1: 987043001 0x79C576: avcodec_send_packet (decode.c:705) > n0: 987043001 0x48074E: main (filtering_video.c:240) > n0: 4127 in 1 place, below massif's threshold (1.00%) > n0: 5315452 in 16 places, all below massif's threshold (1.00%) > n0: 4988280 in 29 places, all below massif's threshold (1.00%) > > > So possibly the AVPacket reference is not dropped anymore after trim has > reached its end position?
That's what I thought when I read your original description, no more useful ideas here, sorry! Carl Eugen _______________________________________________ Libav-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
