Reading desktop stream from rtmp server initializes very slowly with 3.4.1

Questions involving a Windows version of FFmpeg.
Post Reply
mahon5763
Posts: 4
Joined: Fri Jun 24, 2016 7:14 pm

Reading desktop stream from rtmp server initializes very slowly with 3.4.1

Post by mahon5763 » Mon Feb 12, 2018 11:57 pm

This is fixed in the latest nightly build (as of Feb 11th, 2018), but I want to note this here in case anyone else encounters this problem.

I stream my desktop with the command:

Code: Select all

ffmpeg -f gdigrab -i desktop -f dshow -i audio="Microphone (Realtek High Definition Audio)" -c:v h264_nvenc -rtbufsize 1M -vf scale=854:480 -frag_duration 2 -force_key_frames expr:gte(t,n_forced*2) -preset fast -pix_fmt yuv420p -c:a aac -f flv rtmp://localhost:1935/live
And read the RTMP stream into DASH content with:

Code: Select all

ffmpeg -i rtmp://localhost:1935/live -r 30 -c:v libx264 -rtbufsize 1M -b:v 500000 -preset veryfast -frag_duration 2 -force_key_frames expr:gte(t,n_forced*2) -c:a aac -f dash -min_seg_duration 2000 -use_template 1 -use_timeline 1 -init_seg_name init-$RepresentationID$.m4s -media_seg_name seg-$RepresentationID$-$Number$.m4s D:\videos\test\liveStream.mpd -f image2 -vf fps=1/2,scale='-1:-1' thumbnail%04d.jpeg
This worked fine with ffmpeg v3.3.1. When I upgraded to 3.4.1, the second command to read the RTMP stream would take 1-2 minutes before writing out the DASH content. I tried the latest nightly build, and that build writes out the content within a few seconds.

mahon5763
Posts: 4
Joined: Fri Jun 24, 2016 7:14 pm

Re: Reading desktop stream from rtmp server initializes very slowly with 3.4.1

Post by mahon5763 » Tue Feb 27, 2018 2:57 pm

I ended up testing this more, and realized the problem is using the h264_nvenc encoder with desktop streams. I guess whatever optimizations the NVIDIA encoder has doesn't work well when capturing the desktop stream. When I use the libx264 encoder, the stream initializes 3x faster (about 10s vs 30s) across all the builds I tested. I must have switched up the encoder by accident when testing different builds the first time.

I also noticed that streaming the desktop with no audio initializes slowly (30s), even with the libx264 encoder. I believe the second ffmpeg instance that reads the stream scans the stream looking for audio until the "max_analyze_duration" is exceeded. This can be worked around by adding "-analyzeduration 1000000" arguments to the command.

I am confused that the parameter is supposed to be in microseconds, so the default value of 5000000 is only 5 seconds. I don't know why that causes an additional 20 seconds of delay.

Post Reply