#11217(ffmpeg:new): -ss causing a substantial memory increase
#11217: -ss causing a substantial memory increase -------------------------------------+------------------------------------- Reporter: Bryce | Type: defect Chester Newman | Status: new | Priority: important Component: ffmpeg | Version: 7.1 Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: There appears to be a behavior change or bug introduced between FFmpeg 6.1 and 7.0/7.1 when using the “-ss” argument that is causing a substantial memory increase. Running the command below using FFmpeg 6.1 memory usage is about 500MB – which is expected. Running the command below using FFmpeg 7.0/7.1 memory usage is about 3GB – which is not expected. If I remove the “-ss” argument when running on FFmepg 7.0 or 7.1 the memory footprint is the same as 6.1. I can reproduce this on Linux(Ubuntu) and Apple M2. I can reproduce the memory increase using .mxf, mov and .mp4 as an input file. How to reproduce: {{{ ffmpeg -report -v 9 -loglevel 99 -y -i 1951279840.mov \ -filter_complex "[0:v:0]scale='768:432':force_original_aspect_ratio=decrease:force_divisible_by=2[jpg-600];[0:v:0]scale='1280:640'[mp4-640]" \ -map "[jpg-600]" -ss 67 -f image2 -q:v 5 -update 1 -frames:v 1 /tmp/jpg-600-123456.jpg \ -map "[mp4-640]" -map_metadata -1 -f mp4 -vcodec libx264 -profile:v main -level 3.1 -crf 23 -b:v 2500K -movflags faststart -refs 4 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -preset medium /tmp/mp4-640-23456.mp4 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: -ss causing a substantial memory increase -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by Bryce Chester Newman): * Attachment "ffmpeg-20241001-110152.log.zip" added. FFmpeg report log -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: -ss causing a substantial memory increase -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): I think you should be able to reproduce this using just about any video file, but please let me know if you need an example file. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: -ss causing a substantial memory increase -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Marton Balint): Are you using the -ss after the -i intentionally? Because the parameter position controls if ffmpeg seeks in the input file, or decodes the whole input up to the seek point. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:2> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
Are you using the -ss after the -i intentionally? Because the parameter
#11217: -ss causing a substantial memory increase -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): Replying to [comment:2 Marton Balint]: position controls if ffmpeg seeks in the input file, or decodes the whole input up to the seek point. Yes. We don't want to use the -ss before the -i, otherwise as you have stated, the behavior will skip to the position the in video stream that is after the start of the video and that will cause the video stream output -map "[mp4-640]" to start wherever -ss value was set. We have been using the -ss arg in "-map "[jpg-600]" -ss 67 -f image2 -q:v 5 -update 1 -frames:v 1 /tmp/jpg-600-123456.jpg" and the full example command in the same position for years, so something has changed in 7.x that is causing a 500% increase memory allocation. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: -ss causing a substantial memory increase -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): For now, we can't upgrade to 7.x until this issue is fixed. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:4> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by MasterQuestionable): * cc: MasterQuestionable (added) * keywords: => seek seeking * summary: -ss causing a substantial memory increase => Output "-ss" memory consumption regression Comment: ͏ Is it reproducible with? ͏ `ffmpeg -y -v debug -hide_banner -nostdin -nostats -i "1951279840.mov" -ss 67 -vframes 1 "!.jpg"` -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Gyan): A workaround for now is to ingest the input twice, once with a seek for the image output, and once without for the video, and drop the output ss, like this, {{{ ffmpeg -i 1951279840.mov -ss 67 -i 1951279840.mov \ -filter_complex "[1:v:0]scale='768:432':force_original_aspect_ratio=decrease:force_divisible_by=2[jpg-600];[0:v:0]scale='1280:640'[mp4-640]" \ -map "[jpg-600]" -f image2 -q:v 5 -update 1 -frames:v 1 /tmp/jpg-600-123456.jpg \ -map "[mp4-640]" ... /tmp/mp4-640-23456.mp4 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:6> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ It should also be possible to use "select" for the extraction of after 67 s: ͏ Though potentially less efficient than input "-ss". ͏ And in some cases less precise. ("-ss" alike shall match the nearest eligible frame) ͏ E.g. `"select='gte( t, 67 )'"` ͏ See also: https://trac.ffmpeg.org/ticket/11211#comment:1 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:7> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): I appreciate the workaround Gyan, but let's say that -ss is 3 seconds and the video was 30 minutes in duration, wouldn't ffmpeg try to read the rest of the remainder of the file? This is also seems like it would not be a good option for other workflows we have that stream the file. As for using "select='gte( t, 67 )'", what is "less efficient", cpu usage, memory, time, etc? Also, what are the cases that select would be less precise? Is using the -ss arg something that is planned to be fixed? I can wait for an upgrade to 7.x if -ss's usage is fixed. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:8> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ Try with the debug output: which should report the input reading statistics. ͏ "select" by definition may have to evaluate every input frame: ͏ Though didn't cause the trouble in my test case. ͏ Seeking by timestamp (instead of frame number) invariably encounters 1 problem: ͏ No frame at the exact time. ͏ Thus the most sensible approach would be "round" to the nearest frame. ͏ (similar to rounding in math) ͏ . ͏ Which the simple "gte" logic may misalign. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:9> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Gyan): Replying to [comment:8 Bryce Chester Newman]:
I appreciate the workaround Gyan, but let's say that -ss is 3 seconds and the video was 30 minutes in duration, wouldn't ffmpeg try to read the rest of the remainder of the file?
No. Once the output(s) which consume that input have terminated, that input is closed. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:10> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): Any chance this might be fixed in a future release or in master anytime soon? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:11> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ Need more precise regression window... -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:12> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): Is it reproducible with `ffmpeg -y -v debug -hide_banner -nostdin -nostats -i "1951279840.mov" -ss 67 -vframes 1 "!.jpg"`? No, but that is not the issue. That command has always worked as expected in FFmpeg 6 and 7. The issue is reproducible with `ffmpeg -report -v 9 -loglevel 99 -y -i 1951279840.mov \ -filter_complex "[0:v:0]scale='768:432':force_original_aspect_ratio=decrease:force_divisible_by=2[jpg-600];[0:v:0]scale='1280:640'[mp4-640]" \ -map "[jpg-600]" -ss 67 -f image2 -q:v 5 -update 1 -frames:v 1 /tmp/jpg-600-123456.jpg \ -map "[mp4-640]" -map_metadata -1 -f mp4 -vcodec libx264 -profile:v main -level 3.1 -crf 23 -b:v 2500K -movflags faststart -refs 4 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -preset medium /tmp/mp4-640-23456.mp4` The work around is not a viable work around as this comes with an additional cost for us to request the file two or more times when using streaming. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:13> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): Using the work around as shown here... `time ffmpeg -y -i 1951279840.mov -i 1951279840.mov \ -filter_complex "[0:v:0]scale='768:432':force_original_aspect_ratio=decrease:force_divisible_by=2[jpg-600];[1:v:0]scale='1280:640'[mp4-640]" \ -map "[jpg-600]" -ss 67 -f image2 -q:v 5 -update 1 -frames:v 1 /tmp/jpg-600-123456.jpg \ -map "[mp4-640]" -map_metadata -1 -f mp4 -vcodec libx264 -profile:v main -level 3.1 -crf 23 -b:v 2500K -movflags faststart -refs 4 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -preset medium /tmp/mp4-640-23456.mp4` ...there are some observations worth noting. 1) Memory is as expected when using the above command, but like I mentioned accessing the file more than once has a cost for us. 2) User Time. The CPU time outside the kernel increased by 35% compared to the original command in this issue. 3) System Time. Increased by 3% compared to the original command in this issue. 4) Time to execute increased by 30%(or 3 seconds) compared to the original command in this issue. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:14> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ That's the minimal reproducer derived from your origin command. ͏ Compare the behavior between FFmpeg 6, 7: is alike anomaly present? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:15> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): Are you asking if the substantial memory increase occurs in FFmpeg 6 given the original FFmpeg command and args from this issue? If so, then the answer is no, the substantial memory increase does not occur in FFmpeg version 6 or less. Or are you asking to run the command below on FFmpeg 6 and report on the observations? ``` `time ffmpeg -y -i 1951279840.mov -i 1951279840.mov \ -filter_complex "[0:v:0]scale='768:432':force_original_aspect_ratio=decrease:force_divisible_by=2[jpg-600];[1:v:0]scale='1280:640'[mp4-640]" \ -map "[jpg-600]" -ss 67 -f image2 -q:v 5 -update 1 -frames:v 1 /tmp/jpg-600-123456.jpg \ -map "[mp4-640]" -map_metadata -1 -f mp4 -vcodec libx264 -profile:v main -level 3.1 -crf 23 -b:v 2500K -movflags faststart -refs 4 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -preset medium /tmp/mp4-640-23456.mp4` ``` -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:16> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ I mean: ͏ If the command in comment:5, would cause alike resource consumption increase alike? ͏ (comparing FFmpeg 6 and 7) ͏ The minimal command shall of course consume much less resource than your original. ͏ But if alike problems present, there shall be alike resource consumption anomaly. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:17> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): I ran the command three times on 6.1 and 7.1. Notice FFmpeg 7.1 uses 24% more memory than 6.1. Notice FFmpeg 7.1 uses less real/user cpu than 6.1. Notice FFmpeg 7.1 uses less real/user cpu than 6.1. Notice FFmpeg 6.1 is very slightly faster than 7.1. **FFMPEG 7.1** ffmpeg -y -v debug -hide_banner -nostdin -nostats -i "1951279840.mov" -ss 67 -vframes 1 "\!.jpg" real 0m9.410s user 0m43.076s sys 0m2.538s mem 392.7MB real 0m9.617s user 0m43.191s sys 0m2.689s mem 392.5MB real 0m9.534s user 0m43.498s sys 0m2.688s mem 392.2MB **FFMPEG 6.1** ffmpeg -y -v debug -hide_banner -nostdin -nostats -i "1951279840.mov" -ss 67 -vframes 1 "\!.jpg" real 0m12.018s user 0m53.972s sys 0m2.495s mem 315.2MB real 0m11.919s user 0m54.095s sys 0m2.426s mem 315.6MB real 0m11.986s user 0m53.905s sys 0m2.461s mem 315.3MB -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:18> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Gyan):
Notice FFmpeg 6.1 is very slightly faster than 7.1.
7.1 takes an average of ~9.5s whereas 6.1 takes ~11.96s -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:19> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): wrt "7.1 takes an average of ~9.5s whereas 6.1 takes ~11.96s" that - in my opinion - is not at all important and is not relevant to the issue I reported when I opened this issue. I feel like the original issue I reported is somehow being contorted. I am really not sure what is being proven here by the observation or the latest comments about time while executing `ffmpeg -y -v debug -hide_banner -nostdin -nostats -i "1951279840.mov" -ss 67 -vframes 1 "\!.jpg"`. The original FFmpeg command I posted to this issue is the problem with memory and is very much reproducible. Where do we go from here? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:20> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ The memory consumption bloat. Alike observed. (though not as drastic) ͏ Which should more clearly hint the cause. ͏ Your original filter-chain probably somehow amplified the problem. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:21> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman):
The memory consumption bloat. Alike observed. (though not as drastic) ͏ Which should more clearly hint the cause.
Ah. Makes sense. Thank you for the explanation as to why you needed the example. Are there plans to fix this anytime soon? We are still using 6.1.2, but would like to move to 7.x so we can to take advantage of the speed improvements - among other great changes in 7.x. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:22> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ Does tweaking the threads related options help? ͏ I believe a major difference between FF-* 6 and 7, is the additional multi-threading on some extra things. (filters etc.) ͏ Try search this document: https://ffmpeg.org/ffmpeg.html ͏ (keyword "thread"; likely "-filter_threads", "-filter_complex_threads") ͏ . ͏ https://ffmpeg.org/ffmpeg-all.html ͏ ; for the full version: ͏ Though probably less relevant. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:23> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): Last I played around with "-filter_threads" and/or "-filter_complex_threads" transcode times slowed down in FFmpeg 6. I will try in 7. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:24> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): {{{ time ffmpeg -y -i 1951279840.mov -filter_threads 1 -filter_complex_threads 1 \ -filter_complex "[0:v:0]scale='768:432':force_original_aspect_ratio=decrease:force_divisible_by=2[jpg-600];[0:v:0]scale='1280:640'[mp4-640]" \ -map "[jpg-600]" -ss 67 -f image2 -q:v 5 -update 1 -frames:v 1 /tmp/jpg-600-123456.jpg \ -map "[mp4-640]" -map_metadata -1 -f mp4 -vcodec libx264 -profile:v main -level 3.1 -crf 23 -b:v 2500K -movflags faststart -refs 4 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -preset medium /tmp/mp4-640-23456.mp4 }}} All the above did was add an additional 10 seconds to the transcoding time and did not change the memory footprint. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:25> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ Maybe try "-v debug" and compare the output looking for anomaly? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:26> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by Bryce Chester Newman): * Attachment "results.txt" added. Diff results from adding "-filter_threads 1 -filter_complex_threads 1" and not adding "-filter_threads 1 -filter_complex_threads 1". -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): I added the diff results.txt. I am not sure what I am looking for. Do you? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:27> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ You missed the point... ͏ I mean try comparing the FFmpeg 6.1 vs. 7.1's. ͏ Note plain diff simply not gonna work for various causes. ͏ The apparent one: ͏ https://trac.ffmpeg.org/ticket/10998 ͏ And posting the separate output, instead of certain poorly arranged diff view: ͏ Tends to be more useful. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:28> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): Are you asking to compare 6.1 to 7.1 with output "-v debug" and with or without '-filter_threads 1 -filter_complex_threads 1'? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:29> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by MasterQuestionable): ͏ Just whatever that reproduced your issue + "-v debug": ͏ One for 6.1, one for 7.1. ͏ ; and compare. ͏ The just posted command is mostly identical to that in comment:description: ͏ Should be OK. ͏ Needless to bother too further: ͏ As "-filter_threads", "-filter_complex_threads" didn't matter in your FFmpeg 6 results. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:30> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by Bryce Chester Newman): * Attachment "ffmpeg6.log" added. FFmpeg 6 debug output. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by Bryce Chester Newman): * Attachment "ffmpeg7.log" added. FFmpeg 7 debug output. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Bryce Chester Newman): Sorry for the delay. FFmpeg 6 and 7 debug outputs are attached. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:31> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11217: Output "-ss" memory consumption regression (buffering caused?) -------------------------------------+------------------------------------- Reporter: Bryce | Owner: (none) Chester Newman | Type: defect | Status: new Priority: important | Component: ffmpeg Version: 7.1 | Resolution: Keywords: seek | Blocked By: seeking | Blocking: | Reproduced by developer: 0 Analyzed by developer: 1 | -------------------------------------+------------------------------------- Changes (by MasterQuestionable): * analyzed: 0 => 1 * summary: Output "-ss" memory consumption regression => Output "-ss" memory consumption regression (buffering caused?) Comment: ͏ Understandable, we may have other affairs. ͏ Spotted caveat: https://trac.ffmpeg.org/attachment/ticket/11217/ffmpeg7.log#L1258 ͏ [out_!#1:0] 100 buffers queued in out_!#1:0, something may be wrong. ͏ [out_!#1:0] 1000 buffers queued in out_!#1:0, something may be wrong. . ͏ Seems certain excessive buffering was enacted in FF-* 7: ͏ Causing the resource consumption bump. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217#comment:32> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
participants (1)
-
FFmpeg