rdp
commented
9 years ago what if you use a different video codec?
On Fri, Sep 18, 2015 at 3:12 AM, Jake Barnes notifications@github.com wrote:
Hi, I've run into a weird issue.
Our situation: The client runs ffmpeg.exe and takes inputs from screen-capture-recorder, encodes with libx264, and outputs as mpegts (or matroska or flv, all show this issue) to a TCP socket over LAN. The server is a gstreamer pipeline on another machine listening on the TCP socket and decoding and playing the video.
The issue: Suppose the client machine is playing a fullscreen video, then pauses it. Or just goes to the desktop and leaves the mouse still. Anything which leaves the screen static. What happens while it's paused, is a delay gradually gets added to the stream. It seems to max out at exactly 10 seconds.
My analysis: I've configured gstreamer to just play frames as fast as it can as it receives them. If after the delay has started, I go to the command prompt ffmpeg is running in and press ctrl+c, ffmpeg sends out all of the delayed data, and the final 10 seconds plays extremely fast on gstreamer. Therefore, this seems like an issue internal to buffering in ffmpeg or screen-capture-recorder. I also wrote a quick script using netcat to print out a . for every 100 bytes received, and it completely freezes a few seconds after the screen stops changing, then resumes, not sure what's going on with that.
Here's the ffmpeg command line I'm using: .\ffmpeg.exe -framerate 10 -f dshow -i video=screen-capture-recorder:audio=virtual-audio-capturer -vf scale=1280:720 -r 10 -vcodec libx264 -pix_fmt yuv420p -tune zerolatency -preset ultrafast -crf 30 -async 1 -strict -2 -acodec aac -f mpegts tcp:// 192.168.2.230:12802 If the audio input is removed, or the screen is always changing, it works great with < 1 second delay.
Perhaps screen-capture-recorder doesn't output anything if the screen isn't changing? Otherwise something else weird affecting the muxers? I don't know enough about ffmpeg to really analyse this.
— Reply to this email directly or view it on GitHub https://github.com/rdp/screen-capture-recorder-to-video-windows-free/issues/66 .
DuBistKomisch
EzeKees
Hi, I've run into a weird issue.
Our situation: The client runs
ffmpeg.exeand takes inputs fromscreen-capture-recorder, encodes withlibx264, and outputs asmpegts(ormatroskaorflv, all show this issue) to a TCP socket over LAN. The server is agstreamerpipeline on another machine listening on the TCP socket and decoding and playing the video.The issue: Suppose the client machine is playing a fullscreen video, then pauses it. Or just goes to the desktop and leaves the mouse still. Anything which leaves the screen static. What happens while it's paused, is a delay gradually gets added to the stream. It seems to max out at exactly 10 seconds.
My analysis: I've configured gstreamer to just play frames as fast as it can as it receives them. If after the delay has started, I go to the command prompt ffmpeg is running in and press ctrl+c, ffmpeg sends out all of the delayed data, and the final 10 seconds plays extremely fast on gstreamer. Therefore, this seems like an issue internal to buffering in ffmpeg or screen-capture-recorder. I also wrote a quick script using
netcatto print out a.for every 100 bytes received, and it completely freezes a few seconds after the screen stops changing, then resumes, not sure what's going on with that.Here's the ffmpeg command line I'm using:
.\ffmpeg.exe -framerate 10 -f dshow -i video=screen-capture-recorder:audio=virtual-audio-capturer -vf scale=1280:720 -r 10 -vcodec libx264 -pix_fmt yuv420p -tune zerolatency -preset ultrafast -crf 30 -async 1 -strict -2 -acodec aac -f mpegts tcp://192.168.2.230:12802If the audio input is removed, or the screen is always changing, it works great with < 1 second delay.Perhaps screen-capture-recorder doesn't output anything if the screen isn't changing? Otherwise something else weird affecting the muxers? I don't know enough about ffmpeg to really analyse this.