Opened 8 years ago
Closed 8 years ago
#5480 closed defect (invalid)
Immense memory use on Mac 32/64 bit while decoding H.264
Reported by: | glip | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | git-master | Keywords: | h264 |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
To reproduce I used demuxing_decoding.c from examples with turned off writing to output - just decoding is working (changed file attached).
ffmpeg version N-79632-g3ce1988 Copyright (c) 2000-2016 the FFmpeg developers
built with Apple LLVM version 7.3.0 (clang-703.0.29)
configuration: --prefix=build/macx64 --enable-gpl
libavutil 55. 22.101 / 55. 22.101
libavcodec 57. 38.100 / 57. 38.100
libavformat 57. 34.103 / 57. 34.103
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 44.100 / 6. 44.100
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100
Attachments (3)
Change History (5)
by , 8 years ago
Attachment: | valgrind.txt added |
---|
comment:1 by , 8 years ago
Keywords: | h264 added; h.264 decoding removed |
---|---|
Priority: | important → normal |
As-is, this ticket makes little sense: Memory usage for multi-threaded h264 decoding can be (very) high, I don't think this can be fixed (in a useful way), in any case there is already a ticket.
But the valgrind output you provided indicates possible leaks: Did you want to report them? If yes, please test again with --track-origins=yes
.
comment:2 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Afaict, no leaks in your valgrind output are caused by FFmpeg / its libraries.
Feel free to join the discussion in ticket #5224, I don't think there is anything that can be fixed though.
Valgrind