[FFmpeg-user] Max rtbufsize Via dshow

[Roger Pack]

On Fri, Sep 14, 2018 at 10:33 AM Gabriel Balaich <roderrooder at gmail.com> wrote:
>
> Up until a few days ago I had been running two capture cards, 1x4K card and
> 1x1080P card, I would encode both streams with a
> GTX 1080 no dropped frames no issues. But just recently I replaced the
> 1080P capture card with another 4K capture card to prep
> for a new camera and can't get things working gracefully. On my first test
> encoding 2x4K60 streams simultaneously I dropped
> frames starting the recording *and *ending the recording, but nothing
> in-between.
>
> Errors displayed:
> [dshow @ 000001499bb17180] real-time buffer [Video (00 Pro Capture HDMI
> 4K+)] [video input] too full or near too full (62% of
> size: 2147480000 [rtbufsize parameter])! frame dropped!
> [dshow @ 00000149944e7080] real-time buffer [AVerMedia HD Capture GC573 1]
> [video input] too full or near too full (62% of
> size: 2147480000 [rtbufsize parameter])! frame dropped!
>
> The obvious answer, according to the warning, would be increasing rtbufsize
> but I seem to have hit the cap... If I try to increase
> rtbufsize passed 2147.48M I get another error:
> [dshow @ 00000250df6c7080] Value 3000000000.000000 for parameter
> 'rtbufsize' out of range [0 - 2.14748e+09]
> [dshow @ 00000250df6c7080] Error setting option rtbufsize to value 3000M.
> video=AVerMedia HD Capture GC573 1:audio=SPDIF/ADAT (1+2) (RME Fireface
> UC): Result too large
>
> Is this a baked in limitation of FFmpeg or dshow? And if it is, why impose
> said limitation?

The limits "max signed INT" I believe (2B).
Anyway this message typically means your system isn't keeping up with
encoding.  I'd think nvenc would be able to handle it but maybe not?

> Since then I've tried messing with other parts of my command and found that
> by re-arranging my inputs / outputs I can prevent
> frame drops upon starting a recording but I still can't end a recording
> without dropping a bunch of frames.
>
> Anyone know why re-arranging my inputs / outputs would prevent frames from
> dropping when starting a recording or affect
> anything? Is it possible to bypass the rtbufsize cap? Any other ideas?
>
> Here is my full command, Ignore the blank numbers next to -ss, will be used
> to sync outputs when everything is working:
> ffmpeg -y -hide_banner -thread_queue_size 9999 -indexmem 9999
> -guess_layout_max 0 -f dshow -rtbufsize 2147.48M `
> -i audio="Analog (1+2) (RME Fireface UC)" `
> -thread_queue_size 9999 -indexmem 9999 -guess_layout_max 0 -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=50x50 `
> -thread_queue_size 9999 -indexmem 9999 -guess_layout_max 0 -f dshow
> -video_size 3840x2160 -rtbufsize 2147.48M `
> -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 -guess_layout_max 0 -f dshow
> -video_size 3840x2160 -rtbufsize 2147.48M `
> -framerate 60 -pixel_format nv12 -i video="Video (00 Pro Capture HDMI
> 4K+)":audio="ADAT (3+4) (RME Fireface UC)" `
> -map 2,0 -map 0 -c:v libx264 -r 25 -rc-lookahead 50 -forced-idr 1
> -sc_threshold 0 -flags +cgop `
> -force_key_frames "expr:gte(t,n_forced*2)" -preset ultrafast -pix_fmt nv12
> -b:v 16K -minrate 16K -maxrate 16K -bufsize 16k `
> -c:a aac -ar 44100 -b:a 384k -ac 2 -af "aresample=async=250" -vsync 1 -ss
> 00:00:00.000 `
> -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\Main\Discord\Discord%02d.ts `
> -map 2,1 -map 1 -c:v libx264 -r 25 -rc-lookahead 50 -forced-idr 1
> -sc_threshold 0 -flags +cgop `
> -force_key_frames "expr:gte(t,n_forced*2)" -preset ultrafast -pix_fmt nv12
> -b:v 16K -minrate 16K -maxrate 16K -bufsize 16k `
> -c:a aac -ar 44100 -b:a 384k -ac 2 -af "aresample=async=250" -vsync 1 -ss
> 00:00:00.000 `
> -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\Main\Soundboard\Soundboard%02d.ts `
> -map 3:0,3:1 -map 3:1 -c:v h264_nvenc -r 60 -rc-lookahead 120 -forced-idr 1
> -strict_gop 1 -sc_threshold 0 -flags +cgop `
> -force_key_frames "expr:gte(t,n_forced*2)" -preset: llhp -pix_fmt nv12 -b:v
> 250M -minrate 250M -maxrate 250M -bufsize 250M `
> -c:a aac -ar 44100 -b:a 384k -ac 2 -af "pan=mono|c0=c0,
> aresample=async=250" -vsync 1 -ss 00:00:00.000 `
> -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\Main\Camera\Camera%02d.ts `
> -map 4:0,4:1 -map 4:1 -c:v h264_nvenc -r 60 -rc-lookahead 120 -forced-idr 1
> -strict_gop 1 -sc_threshold 0 -flags +cgop `
> -force_key_frames "expr:gte(t,n_forced*2)" -preset: llhp -pix_fmt nv12 -b:v
> 250M -minrate 250M -maxrate 250M -bufsize 250M `
> -c:a aac -ar 44100 -b:a 384k -ac 2 -af "atrim=0.086, asetpts=PTS-STARTPTS,
> aresample=async=250" -vsync 1 -ss 00:00:00.000 `
> -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\Main\Magewell\Magewell%02d.ts
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".