Encode fails immediately on 2nd pass with "Cannot enlarge memory arrays."
maj160 opened this issue · comments
Attempting to encode 10 seconds of a video, the first pass (thread 1) finishes without problems, but then the second pass fails immediately.
Test cases: 720p mp4 (failed, logs attached), 720p mp4 (failed), 360p mp4 (encoded successfully)
Options chosen: 10 second duration, 2 threads, otherwise defaults.
Main log:
[18:49:33] Spawning jobs:
[18:49:33] 2 video thread(s)
[18:49:33] 1 audio thread
[18:49:33] Video 1 started first pass
[18:49:33] Video 2 started first pass
[18:49:33] Audio started
[18:49:41] Audio finished (00:00:07.1)
[18:50:40] Video 1 finished first pass (00:01:06.1)
[18:50:40] Video 1 started second pass
[18:50:44] Fatal error at Video 1: Uncaught abort("Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 67108864, (2) compile with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents some optimizations, or (3) set Module.TOTAL_MEMORY before the program runs.") at Error
at Error (native)
at xa (https://kagami.github.io/webm.js/1527e3d81b.ffmpeg-worker-webm.js:12:141)
at E (https://kagami.github.io/webm.js/1527e3d81b.ffmpeg-worker-webm.js:25:196)
at Function.g.Oa [as Rd] (https://kagami.github.io/webm.js/1527e3d81b.ffmpeg-worker-webm.js:35:165)
at Aa (https://kagami.github.io/webm.js/1527e3d81b.ffmpeg-worker-webm.js:18:24)
at wNa (https://kagami.github.io/webm.js/1527e3d81b.ffmpeg-worker-webm.js:4838:6988)
at oHa (https://kagami.github.io/webm.js/1527e3d81b.ffmpeg-worker-webm.js:4827:213617)
at SKa (https://kagami.github.io/webm.js/1527e3d81b.ffmpeg-worker-webm.js:4824:122774)
at Array.VKa (https://kagami.github.io/webm.js/1527e3d81b.ffmpeg-worker-webm.js:4824:134263)
at Object.gRa [as dynCall_vii] (https://kagami.github.io/webm.js/1527e3d81b.ffmpeg-worker-webm.js:4838:121823)
If this abort() is unexpected, build with -s ASSERTIONS=1 which can give more information.
Video 1 Log:
$ ffmpeg -hide_banner -ss 0 -i in.mp4 -t 5 -c:v libvpx -b:v 6489k -speed 4 -auto-alt-ref 1 -lag-in-frames 25 -sn -c:a libopus -b:a 64k -ac 2 -an -pass 1 -f null -
[h264 @ 0x747b40] Warning: not compiled with thread support, using thread emulation
[aac @ 0x74ed30] Warning: not compiled with thread support, using thread emulation
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'in.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: isommp42
creation_time : 2013-12-23 17:25:06
Duration: 00:02:04.97, start: 0.000000, bitrate: 1916 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1264x720, 1721 kb/s, 23.98 fps, 23.98 tbr, 48k tbn, 47.95 tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 191 kb/s (default)
Metadata:
creation_time : 2013-12-23 17:25:06
handler_name : IsoMedia File Produced by Google, 5-11-2011
[libvpx @ 0x76cd40] Warning: not compiled with thread support, using thread emulation
[libvpx @ 0x76cd40] v1.4.0
[h264 @ 0x769d20] Warning: not compiled with thread support, using thread emulation
Output #0, null, to 'pipe:':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: isommp42
encoder : Lavf56.36.100
Stream #0:0(und): Video: vp8 (libvpx), yuv420p, 1264x720, q=-1--1, pass 1, 6489 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc (default)
Metadata:
handler_name : VideoHandler
encoder : Lavc56.41.100 libvpx
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> vp8 (libvpx))
Press [q] to stop, [?] for help
frame= 3 fps=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A
frame= 5 fps=3.9 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A
frame= 7 fps=3.4 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A
frame= 9 fps=3.3 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A
[ ... Cut ... ]
frame= 120 fps=2.0 q=0.0 Lsize=N/A time=00:00:00.00 bitrate=N/A
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Output file is empty, nothing was encoded
$ ffmpeg -hide_banner -ss 0 -i in.mp4 -t 5 -c:v libvpx -b:v 6489k -speed 1 -auto-alt-ref 1 -lag-in-frames 25 -sn -c:a libopus -b:a 64k -ac 2 -an -pass 2 1.webm
[h264 @ 0x747b20] Warning: not compiled with thread support, using thread emulation
[aac @ 0x74ed10] Warning: not compiled with thread support, using thread emulation
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'in.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: isommp42
creation_time : 2013-12-23 17:25:06
Duration: 00:02:04.97, start: 0.000000, bitrate: 1916 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1264x720, 1721 kb/s, 23.98 fps, 23.98 tbr, 48k tbn, 47.95 tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 191 kb/s (default)
Metadata:
creation_time : 2013-12-23 17:25:06
handler_name : IsoMedia File Produced by Google, 5-11-2011
[libvpx @ 0x76d210] Warning: not compiled with thread support, using thread emulation
[libvpx @ 0x76d210] v1.4.0
Video 2 and Audio logs not attached as they seem to be typical (although Video 2 only got 80 frames into the encode)
The offending file: https://www.dropbox.com/s/8d5ua6ub2b1na36/ThisFileIsProblematic.mp4?dl=1
Hi, thanks for the report!
It seems to be (64M - 29M) memory is not enough for h264 decoder with 720p video and libvpx encoder. I currently bumped memory size to 80M, but I hope to fix issues with big files soon.
Could you please test again?
Issue seems to be resolved. Great work!
Btw, it took me 18 minutes to encode the entire video (2min, 720p). Not that bad.