| 1 | | junogoose, |
| 2 | | |
| 3 | | I'm running on a i7-2600 3.4GHz, 6GB ram, Windows 7. I don't think ram or cpu is an issue in this. |
| 4 | | |
| 5 | | I am using a modified windows build based on ffmpeg-git-85f2c01 source. |
| 6 | | My test command line is |
| 7 | | |
| 8 | | |
| 9 | | {{{ |
| 10 | | -re -y -loglevel verbose -probesize 4096 -i "D:\Media\Clips\Studio Ghibli 25.mp4" -flags +global_header -c:v copy -c:a copy -f flv "rtmp://live-prg.twitch.tv/app/ playpath=live_<mystreamid>" |
| 11 | | }}} |
| 12 | | |
| 13 | | The video clip is h264/aac 720p 2.5mbps. This effectively eliminates the encoders. |
| 14 | | The main factor seems to be the ping time. |
| 15 | | Since I'm in Texas, the above url is far away and has an average ping of 143ms. |
| 16 | | If I stream to live-dfw.twitch.tv/app/ (Server is in Dallas TX), the ping time is 9ms, and works without modification. |
| 17 | | |
| 18 | | Your test may indicate that this is a windows specific socket's problem, but so far I haven't been able to confirm this. |
| 19 | | |
| 20 | | If anything it may be that Linux handles things differently. The main thing seems to be that many small sends with a large RTT stalls on Windows, but not Linux. |
| 21 | | |
| | 1 | sorry, duplicate comment. :( |
