Recently this Github page, dedicated to bypassing Nvidia's encode limit, added windows support: https://github.com/keylase/nvidia-patch/tree/master/win
Up until now I've been encoding my 5 live streams across my GPU and CPU due to the encode limit imposed on consumer Nvidia GPUs, so 2 streams on my GPU and 3 streams on my CPU. But with the help of this patch I can now encode all 5 streams with just my GPU, which go me thinking - as opposed to encoding 5 separate output videos maybe I can encode all streams into 1 file.
It has been pretty difficult to create a command that keeps all 5 separate output files synchronized, due to the nature of segmentation. So I'm thinking that if I do everything in one file I can bypass some of those troubles and simplify my workflow / command. However, I've found that when I try to put everything in one output file I can't transcode real time.
Example command:
ffmpeg -y -hide_banner -thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147M -video_size 3840x2160 `
-framerate 60 -pixel_format nv12 -i video="Video (Pro Capture)":audio="ADAT (3+4) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147M -video_size 3840x2160 -framerate 60 -pixel_format nv12 `
-i video="AVerMedia HD Capture GC573 1":audio="Analog (1+2) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147M -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 2147M -i audio="ADAT (5+6) (RME Fireface UC)" `
-thread_queue_size 9999 -indexmem 9999 -f dshow -rtbufsize 2147M -i audio="SPDIF/ADAT (1+2) (RME Fireface UC)" `
-c:v h264_nvenc -preset: llhp -pix_fmt nv12 -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 -map 1 -map 2 -map 3 -map 4 `
-f segment -segment_time 600 -segment_wrap 9 -reset_timestamps 1 -segment_format_options max_delay=0 `
C:\Users\djcim\Videos\FFmpeg\FFmpeg%02d.ts
The above command does not transcode real time, sits at about .6x speed. However when I simply seperate everything to multiple outputs I transcode real time:
ffmpeg -y -hide_banner `
-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)" `
-thread_queue_size 9999 -indexmem 9999 -r 25 -f lavfi -rtbufsize 2147.48M -i color=c=black:s=256x120 `
-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 -video_size 3840x2160 -framerate 60 `
-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="Analog (1+2) (RME Fireface UC)" `
-map 2,0 -map 0 -c:v h264_nvenc -preset: llhp -r 25 -rc-lookahead 25 -pix_fmt nv12 -b:v 288M -minrate 288M `
-maxrate 288M -bufsize 288M -c:a aac -ar 44100 -b:a 384k -vsync 1 -max_muxing_queue_size 9999 `
-f segment -segment_time 600 -segment_wrap 9 -reset_timestamps 1 -segment_format_options max_delay=0 `
C:\Users\djcim\Videos\FFmpeg\CP\CP%02d.ts `
-map 2,1 -map 1 -c:v h264_nvenc -preset: llhp -r 25 -rc-lookahead 25 -pix_fmt nv12 -b:v 288M -minrate 288M `
-maxrate 288M -bufsize 288M -c:a aac -ar 44100 -b:a 384k -vsync 1 -max_muxing_queue_size 9999 `
-f segment -segment_time 600 -segment_wrap 9 -reset_timestamps 1 -segment_format_options max_delay=0 `
C:\Users\djcim\Videos\FFmpeg\SB\SB%02d.ts `
-map 3:0,3:1 -map 3:1 -c:v h264_nvenc -preset: llhp -r 60 -rc-lookahead 60 -pix_fmt yuv420p -b:v 288M -minrate 288M `
-maxrate 288M -bufsize 288M -c:a aac -ar 44100 -b:a 384k -vsync 1 -max_muxing_queue_size 9999 `
-f segment -segment_time 600 -segment_wrap 9 -reset_timestamps 1 -segment_format_options max_delay=0 `
C:\Users\djcim\Videos\FFmpeg\EL\EL%02d.ts `
-map 4:0,4:1 -map 4:1 -c:v h264_nvenc -preset: llhp -r 60 -rc-lookahead 60 -pix_fmt nv12 -b:v 288M -minrate 288M `
-maxrate 288M -bufsize 288M -c:a aac -ar 44100 -b:a 384k -vsync 1 -max_muxing_queue_size 9999 `
-f segment -segment_time 600 -segment_wrap 9 -reset_timestamps 1 -segment_format_options max_delay=0 `
C:\Users\djcim\Videos\FFmpeg\MW\MW%02d.ts `
-map 5:0,5:1 -map 5:1 -c:v h264_nvenc -preset: llhp -r 60 -rc-lookahead 60 -pix_fmt nv12 -b:v 288M -minrate 288M `
-maxrate 288M -bufsize 288M -c:a aac -ar 44100 -b:a 192k -vsync 1 -max_muxing_queue_size 9999 `
-f segment -segment_time 600 -segment_wrap 9 -reset_timestamps 1 -segment_format_options max_delay=0 `
C:\Users\djcim\Videos\FFmpeg\AM\AM%02d.ts
This is also not to mention that the above command is a much more simplified version of what I actually use, I typically add a myriad of synchronization options to each output, but that isn't really relevant to its ability to transcode real time.
Any idea why the single file solution struggles while the latter does not? And if possible, a solution?
