1

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:\Users\djcim\Videos\FFmpeg\FFmpeg.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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.