Unable To Transcode 8 Sources In One Instance Real Time (FFmpeg)
Just the other day I posted about my inability to transcode a multitrack video real time, -rc-lookahead ended up being the solution. However this was when recording fairly static signals, when each capture card receives a more complex signal I am still unable to transcode real time with either command mentioned in that post.
Command:
ffmpeg -y `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3440x1440 -framerate 100 `
-pixel_format nv12 -i video="Video (Pro Capture)":audio="ADAT (3+4) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3840x2160 -framerate 60 `
-pixel_format nv12 -i video="AVerMedia HD Capture GC573 1":audio="SPDIF/ADAT (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 1920x1080 -framerate 60 `
-pixel_format yuv420p -i video="Game Capture HD60 Pro (Video) (#01)":audio="Game Capture HD60 Pro (Audio) (#01)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="Analog (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="ADAT (5+6) (RME Fireface UC)" `
-c:v h264_nvenc -preset: llhp -pix_fmt nv12 -rc-lookahead 100 -b:v 288M -minrate 288M -maxrate 288M -bufsize 288M `
-c:a aac -ar 44100 -b:a 384k -vsync 1 -max_muxing_queue_size 9999 `
-map 0:0,0:1 -map 0:1 -map 1:0,1:1 -map 1:1 -map 2:0,2:1 -map 2:1 -map 3 -map 4 `
C:UsersdjcimVideosFFmpegFFmpeg.ts
The goal is to record all sources simultaneously and synchronized, many options I use for synchronization are missing from this command for simplicity's sake. Bottom line, the above command does not transcode real time. The recording starts at about .5x speed and slowly creeps towards 1x, but once it gets around .9-.95x it stops moving up and eventually my system memory (32GB) is saturated causing frame drops, even worse transcoding speed, and general system sluggishness. I'm not sure what my system memory is actually being filled with as I only have a 2GB buffer on each input and the total should be around 11GB... but I digress.
Separating each input to its own output doesn't seem to help. If I remove any one of the sources, even just the audio streams linked to one of the video streams, I reach real time transcoding within a minute. If I remove one of the video sources I reach real time transcoding within 10 seconds. If I lower the video bitrate to 1M I can also reach real time transcoding within 1 minute, though you'd think this have a larger effect than removing one of the smaller audio sources.
So you'd think there'd be a bottleneck in my system somewhere, but there isn't a visible one. CPU and drive usage are below 30%, and my GPU's encoder usage is below 70%. Furthermore, if I separate each input / output to its own instance of Powershell / FFmpeg but still run them concurrently / simultaneously everything transcodes real time basically instantly which would seem to rule out a hardware bottleneck. Is it possible that this is simply a limitation of FFmpeg? Or is there and option out there that could possibly resolve the issue?
Any insight on the matter would be highly appreciated.
audio video ffmpeg transcode real-time
asked Jan 14 at 19:07
NimbleNimble
285
|
show 2 more comments
Just the other day I posted about my inability to transcode a multitrack video real time, -rc-lookahead ended up being the solution. However this was when recording fairly static signals, when each capture card receives a more complex signal I am still unable to transcode real time with either command mentioned in that post.
Command:
ffmpeg -y `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3440x1440 -framerate 100 `
-pixel_format nv12 -i video="Video (Pro Capture)":audio="ADAT (3+4) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3840x2160 -framerate 60 `
-pixel_format nv12 -i video="AVerMedia HD Capture GC573 1":audio="SPDIF/ADAT (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 1920x1080 -framerate 60 `
-pixel_format yuv420p -i video="Game Capture HD60 Pro (Video) (#01)":audio="Game Capture HD60 Pro (Audio) (#01)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="Analog (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="ADAT (5+6) (RME Fireface UC)" `
-c:v h264_nvenc -preset: llhp -pix_fmt nv12 -rc-lookahead 100 -b:v 288M -minrate 288M -maxrate 288M -bufsize 288M `
-c:a aac -ar 44100 -b:a 384k -vsync 1 -max_muxing_queue_size 9999 `
-map 0:0,0:1 -map 0:1 -map 1:0,1:1 -map 1:1 -map 2:0,2:1 -map 2:1 -map 3 -map 4 `
C:UsersdjcimVideosFFmpegFFmpeg.ts
The goal is to record all sources simultaneously and synchronized, many options I use for synchronization are missing from this command for simplicity's sake. Bottom line, the above command does not transcode real time. The recording starts at about .5x speed and slowly creeps towards 1x, but once it gets around .9-.95x it stops moving up and eventually my system memory (32GB) is saturated causing frame drops, even worse transcoding speed, and general system sluggishness. I'm not sure what my system memory is actually being filled with as I only have a 2GB buffer on each input and the total should be around 11GB... but I digress.
Separating each input to its own output doesn't seem to help. If I remove any one of the sources, even just the audio streams linked to one of the video streams, I reach real time transcoding within a minute. If I remove one of the video sources I reach real time transcoding within 10 seconds. If I lower the video bitrate to 1M I can also reach real time transcoding within 1 minute, though you'd think this have a larger effect than removing one of the smaller audio sources.
So you'd think there'd be a bottleneck in my system somewhere, but there isn't a visible one. CPU and drive usage are below 30%, and my GPU's encoder usage is below 70%. Furthermore, if I separate each input / output to its own instance of Powershell / FFmpeg but still run them concurrently / simultaneously everything transcodes real time basically instantly which would seem to rule out a hardware bottleneck. Is it possible that this is simply a limitation of FFmpeg? Or is there and option out there that could possibly resolve the issue?
Any insight on the matter would be highly appreciated.
audio video ffmpeg transcode real-time
asked Jan 14 at 19:07
NimbleNimble
285
First thing to try: simulate your command with file sources of similar properties but keep output parameters the same.
– Gyan
Jan 15 at 4:24
Do you mean just change the 5 live inputs to 5 file inputs?
– Nimble
Jan 15 at 17:14
Yes. With the same properties i.e. resolution, framerates..etc
– Gyan
Jan 15 at 17:22
So I ran the command above for a minute except with outputs for each input and then the above command again with those files as inputs. Performance was significantly worse than when encoding the live sources, below .5x for the duration of the conversion. It was also hitting my CPU pretty hard, which is something that doesn't happen with the live sources, adding -hwaccel nvdec relieved stress on the CPU but did not improve transcoding speed.
– Nimble
Jan 16 at 2:46
The file inputs are probably encodings. For a better simulation, they should be uncompressed or have lightweight compression. Using lavfi sources is also an option since that skips the disk I/O as well.
– Gyan
Jan 17 at 4:53
|
show 2 more comments
Just the other day I posted about my inability to transcode a multitrack video real time, -rc-lookahead ended up being the solution. However this was when recording fairly static signals, when each capture card receives a more complex signal I am still unable to transcode real time with either command mentioned in that post.
Command:
ffmpeg -y `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3440x1440 -framerate 100 `
-pixel_format nv12 -i video="Video (Pro Capture)":audio="ADAT (3+4) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3840x2160 -framerate 60 `
-pixel_format nv12 -i video="AVerMedia HD Capture GC573 1":audio="SPDIF/ADAT (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 1920x1080 -framerate 60 `
-pixel_format yuv420p -i video="Game Capture HD60 Pro (Video) (#01)":audio="Game Capture HD60 Pro (Audio) (#01)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="Analog (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="ADAT (5+6) (RME Fireface UC)" `
-c:v h264_nvenc -preset: llhp -pix_fmt nv12 -rc-lookahead 100 -b:v 288M -minrate 288M -maxrate 288M -bufsize 288M `
-c:a aac -ar 44100 -b:a 384k -vsync 1 -max_muxing_queue_size 9999 `
-map 0:0,0:1 -map 0:1 -map 1:0,1:1 -map 1:1 -map 2:0,2:1 -map 2:1 -map 3 -map 4 `
C:UsersdjcimVideosFFmpegFFmpeg.ts
The goal is to record all sources simultaneously and synchronized, many options I use for synchronization are missing from this command for simplicity's sake. Bottom line, the above command does not transcode real time. The recording starts at about .5x speed and slowly creeps towards 1x, but once it gets around .9-.95x it stops moving up and eventually my system memory (32GB) is saturated causing frame drops, even worse transcoding speed, and general system sluggishness. I'm not sure what my system memory is actually being filled with as I only have a 2GB buffer on each input and the total should be around 11GB... but I digress.
Separating each input to its own output doesn't seem to help. If I remove any one of the sources, even just the audio streams linked to one of the video streams, I reach real time transcoding within a minute. If I remove one of the video sources I reach real time transcoding within 10 seconds. If I lower the video bitrate to 1M I can also reach real time transcoding within 1 minute, though you'd think this have a larger effect than removing one of the smaller audio sources.
So you'd think there'd be a bottleneck in my system somewhere, but there isn't a visible one. CPU and drive usage are below 30%, and my GPU's encoder usage is below 70%. Furthermore, if I separate each input / output to its own instance of Powershell / FFmpeg but still run them concurrently / simultaneously everything transcodes real time basically instantly which would seem to rule out a hardware bottleneck. Is it possible that this is simply a limitation of FFmpeg? Or is there and option out there that could possibly resolve the issue?
Any insight on the matter would be highly appreciated.
audio video ffmpeg transcode real-time
asked Jan 14 at 19:07
NimbleNimble
285
Just the other day I posted about my inability to transcode a multitrack video real time, -rc-lookahead ended up being the solution. However this was when recording fairly static signals, when each capture card receives a more complex signal I am still unable to transcode real time with either command mentioned in that post.
Command:
ffmpeg -y `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3440x1440 -framerate 100 `
-pixel_format nv12 -i video="Video (Pro Capture)":audio="ADAT (3+4) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 3840x2160 -framerate 60 `
-pixel_format nv12 -i video="AVerMedia HD Capture GC573 1":audio="SPDIF/ADAT (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -video_size 1920x1080 -framerate 60 `
-pixel_format yuv420p -i video="Game Capture HD60 Pro (Video) (#01)":audio="Game Capture HD60 Pro (Audio) (#01)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="Analog (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147.48M -i audio="ADAT (5+6) (RME Fireface UC)" `
-c:v h264_nvenc -preset: llhp -pix_fmt nv12 -rc-lookahead 100 -b:v 288M -minrate 288M -maxrate 288M -bufsize 288M `
-c:a aac -ar 44100 -b:a 384k -vsync 1 -max_muxing_queue_size 9999 `
-map 0:0,0:1 -map 0:1 -map 1:0,1:1 -map 1:1 -map 2:0,2:1 -map 2:1 -map 3 -map 4 `
C:UsersdjcimVideosFFmpegFFmpeg.ts
The goal is to record all sources simultaneously and synchronized, many options I use for synchronization are missing from this command for simplicity's sake. Bottom line, the above command does not transcode real time. The recording starts at about .5x speed and slowly creeps towards 1x, but once it gets around .9-.95x it stops moving up and eventually my system memory (32GB) is saturated causing frame drops, even worse transcoding speed, and general system sluggishness. I'm not sure what my system memory is actually being filled with as I only have a 2GB buffer on each input and the total should be around 11GB... but I digress.
Separating each input to its own output doesn't seem to help. If I remove any one of the sources, even just the audio streams linked to one of the video streams, I reach real time transcoding within a minute. If I remove one of the video sources I reach real time transcoding within 10 seconds. If I lower the video bitrate to 1M I can also reach real time transcoding within 1 minute, though you'd think this have a larger effect than removing one of the smaller audio sources.
So you'd think there'd be a bottleneck in my system somewhere, but there isn't a visible one. CPU and drive usage are below 30%, and my GPU's encoder usage is below 70%. Furthermore, if I separate each input / output to its own instance of Powershell / FFmpeg but still run them concurrently / simultaneously everything transcodes real time basically instantly which would seem to rule out a hardware bottleneck. Is it possible that this is simply a limitation of FFmpeg? Or is there and option out there that could possibly resolve the issue?
Any insight on the matter would be highly appreciated.
audio video ffmpeg transcode real-time
audio video ffmpeg transcode real-time
asked Jan 14 at 19:07
NimbleNimble
285
asked Jan 14 at 19:07
NimbleNimble
285
edited Jan 14 at 19:12
Nimble
asked Jan 14 at 19:07
NimbleNimble
285
asked Jan 14 at 19:07
NimbleNimble
285
asked Jan 14 at 19:07
NimbleNimble
285
285
First thing to try: simulate your command with file sources of similar properties but keep output parameters the same.
– Gyan
Jan 15 at 4:24
Do you mean just change the 5 live inputs to 5 file inputs?
– Nimble
Jan 15 at 17:14
Yes. With the same properties i.e. resolution, framerates..etc
– Gyan
Jan 15 at 17:22
So I ran the command above for a minute except with outputs for each input and then the above command again with those files as inputs. Performance was significantly worse than when encoding the live sources, below .5x for the duration of the conversion. It was also hitting my CPU pretty hard, which is something that doesn't happen with the live sources, adding -hwaccel nvdec relieved stress on the CPU but did not improve transcoding speed.
– Nimble
Jan 16 at 2:46
The file inputs are probably encodings. For a better simulation, they should be uncompressed or have lightweight compression. Using lavfi sources is also an option since that skips the disk I/O as well.
– Gyan
Jan 17 at 4:53
|
show 2 more comments
First thing to try: simulate your command with file sources of similar properties but keep output parameters the same.
– Gyan
Jan 15 at 4:24
Do you mean just change the 5 live inputs to 5 file inputs?
– Nimble
Jan 15 at 17:14
Yes. With the same properties i.e. resolution, framerates..etc
– Gyan
Jan 15 at 17:22
So I ran the command above for a minute except with outputs for each input and then the above command again with those files as inputs. Performance was significantly worse than when encoding the live sources, below .5x for the duration of the conversion. It was also hitting my CPU pretty hard, which is something that doesn't happen with the live sources, adding -hwaccel nvdec relieved stress on the CPU but did not improve transcoding speed.
– Nimble
Jan 16 at 2:46
The file inputs are probably encodings. For a better simulation, they should be uncompressed or have lightweight compression. Using lavfi sources is also an option since that skips the disk I/O as well.
– Gyan
Jan 17 at 4:53
First thing to try: simulate your command with file sources of similar properties but keep output parameters the same.
– Gyan
Jan 15 at 4:24
First thing to try: simulate your command with file sources of similar properties but keep output parameters the same.
– Gyan
Jan 15 at 4:24
Do you mean just change the 5 live inputs to 5 file inputs?
– Nimble
Jan 15 at 17:14
Do you mean just change the 5 live inputs to 5 file inputs?
– Nimble
Jan 15 at 17:14
Yes. With the same properties i.e. resolution, framerates..etc
– Gyan
Jan 15 at 17:22
Yes. With the same properties i.e. resolution, framerates..etc
– Gyan
Jan 15 at 17:22
So I ran the command above for a minute except with outputs for each input and then the above command again with those files as inputs. Performance was significantly worse than when encoding the live sources, below .5x for the duration of the conversion. It was also hitting my CPU pretty hard, which is something that doesn't happen with the live sources, adding -hwaccel nvdec relieved stress on the CPU but did not improve transcoding speed.
– Nimble
Jan 16 at 2:46
So I ran the command above for a minute except with outputs for each input and then the above command again with those files as inputs. Performance was significantly worse than when encoding the live sources, below .5x for the duration of the conversion. It was also hitting my CPU pretty hard, which is something that doesn't happen with the live sources, adding -hwaccel nvdec relieved stress on the CPU but did not improve transcoding speed.
– Nimble
Jan 16 at 2:46
The file inputs are probably encodings. For a better simulation, they should be uncompressed or have lightweight compression. Using lavfi sources is also an option since that skips the disk I/O as well.
– Gyan
Jan 17 at 4:53
The file inputs are probably encodings. For a better simulation, they should be uncompressed or have lightweight compression. Using lavfi sources is also an option since that skips the disk I/O as well.
– Gyan
Jan 17 at 4:53
|
show 2 more comments
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1394234%2funable-to-transcode-8-sources-in-one-instance-real-time-ffmpeg%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1394234%2funable-to-transcode-8-sources-in-one-instance-real-time-ffmpeg%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
First thing to try: simulate your command with file sources of similar properties but keep output parameters the same.
– Gyan
Jan 15 at 4:24
Do you mean just change the 5 live inputs to 5 file inputs?
– Nimble
Jan 15 at 17:14
Yes. With the same properties i.e. resolution, framerates..etc
– Gyan
Jan 15 at 17:22
So I ran the command above for a minute except with outputs for each input and then the above command again with those files as inputs. Performance was significantly worse than when encoding the live sources, below .5x for the duration of the conversion. It was also hitting my CPU pretty hard, which is something that doesn't happen with the live sources, adding -hwaccel nvdec relieved stress on the CPU but did not improve transcoding speed.
– Nimble
Jan 16 at 2:46
The file inputs are probably encodings. For a better simulation, they should be uncompressed or have lightweight compression. Using lavfi sources is also an option since that skips the disk I/O as well.
– Gyan
Jan 17 at 4:53