Question / Help Mixer FTL help

W

wrice4

Member
To start off, here is my log, https://obsproject.com/logs/evwQs64qmLrgN8s1 ,and my upload speed is 10k.


Hello, I just recently switched to FTL instead of RTMP. I went from a 7500k bitrate on RTMP to a 4k bitrate on FTL. My stream was running fine, so I changed it to 5k bitrate around the 18-20 minute mark during the stream. Then my stream starting freezing and stuttering every 5 seconds or so for half a second each time. After about 15-20 minutes I changed it back down to 4k bitrate and was told the stream ran fine again. I contacted the discord help and was wondering why I couldn't get to 5k bitrate. I was told by someone that this was an unknown error to them "[3] Video queue full, dropping packets until next key frame". It seemed to happen a lot after the switch of bitrate.

During this first FTL stream, I did not have bframes=0 inputted into x264 options and I did not have my keyframe interval set to 1 (it was at 2). I have read that both of these items are a NEED. Also, I will say that this stream was 1080p 60fps and my cpu preset was on medium. I don't know if the preset needs to be on veryfast for FTL or not.

During this entire stream OBS showed me at 0 dropped frames the entire time, even when I was experiencing stutters on the viewers end. So my question is, is there anyway to up my bitrate with different settings or am I basically capped at 4k bitrate? Sucks going from RTMP at 7500 to 4k on FTL.

Here is the stream: https://mixer.com/12ice?vod=RD-UgKW2dUyJyxgJdsHiUQ
Around 18:15 I changed my bitrate up to 5k (then the stuttering starts) and then turn it back down to 4k bitrate around 35:15.
 
The video queue is the buffer within OBS, where OBS stores the outgoing stream data. If the buffer gets full, it means OBS is producing more data than the connection between your machine and the mixer server is able to send out. So yes, it seems your internet connection seems limited. At least if it comes to the ingest server of Mixer. Actually, according to the log you started your stream with bitrate 3000, not 4000. Although OBS didn't report many dropped frames due to bandwidth issues for you, the detailed log says otherwise - I assume the frames are dropped within the output module of OBS without telling the OBS GUI about this.

I did not know you are able to change the bitrate mid-stream. Even if it is available within OBS, I would try to stop the stream, then change bitrate, then start the stream again. This way the ingest server knows exactly which bitrate you intend to stream for the whole duration of the stream, since bitrate settings are usually negotiated at the start of the stream, not mid-session.
 
Thanks for responding. I will try a set bitrate and not change during stream. Do you think that putting the bframes=0 and keyframe interval to 1 will make enough difference at all? Also, I would assume you would recommend streaming on FTL at 720p vs 1080p at 4k bitrate yes?
 
Keyframe interval becomes important if you have lots of lost frames, because a viewer has to wait for the next keyframe to restart display of a stalled stream. If the interval is too long, users have to wait longer, if the interval is too short, you consume and waste bandwidth. I would use interval 2 or 3 to conserve bandwidth. Keyframes are 10 times the size of all the other frames, so it's quite an impact if you have limited bandwidth.

I recommend nothing, because I never know the exact technical constraints of someone at his home. I'd always refer to the streaming service's recommendations. Here are the mixer recommendations:
watchbeam.zendesk.com

Help Center Closed - Zendesk

watchbeam.zendesk.com watchbeam.zendesk.com

Don't skip over that page, check also all the linked sub-pages. They're full of valuable information. However, understand that is not a "set this and you're fine" documentation. It's a discussion and explanation of the different parts of a streaming configuration. How the parameters apply to your situation is something you have to decide.

If you just want to enter some values without the need of understanding them, refer to the Twitch encoding recommendations:

Twitch Streamers - Twitch Video Encoding/Bitrates/And Stuff

stream.twitch.tv stream.twitch.tv
 
Thanks, but keep in mind both of those links refer to RTMP settings so the recommended bitrates, keyframe interval, etc is not what it is supposed to be. Thanks for trying to help though. I just continuously do some testing.
 
ftl is just a different transfer protocol, it doesn't change the encoding or quality of the video. The encoding is still h.264, and all that applies to h.264 applies to both rtmp as well as ftl. As far as I know, ftl is advertised as sub-second low latency, while rtmp has a latency of a few seconds. Is there any other notable difference?
 
Just silly as mixer's recommended 1080p 60fps bitrate for FTL is 2500-3500. I am running 4000 bitrate at 720p 60fps and its soo pixelated.
 
Sorry, but according to ftl help, the recommended bitrate for 1080p 60 fps for ftl is 7000. If you use 4000, it's no wonder why it appears pixelated.
See here: https://watchbeam.zendesk.com/hc/en-us/articles/360038140511
Common recommendation for that resolution+fps combination for high motion video is about 8000.
If your internet line doesn't support a bitrate that high, use an fps of 30 and tune down the resolution to 1280x720 or even lower.
 
They contradict themselves then because I was looking at their FTL setup instructions here(recommended by mixer support):
Capture.PNG


I have been in contact with mixer support and have ran 4-5 different test streams with them with different settings, listed below:
All 4000 bitrate base
720p 60fps
1080p 30fps
1080p 60fps
port forwarding UDP 8000-9000 ports

Now they are trying to get me to drop my bitrate to 3000 and go to 1080p for better quality from 720p 4000 bitrate. Makes zero sense to me.
 
I think I have decided to just quit testing it and just stream at 720p 60fps 4000 bitrate with medium x264 preset. I'm wasting my time.
 
You don't need to upload anything to make quality comparisons for bitrate. You can just record with all of the resolution and bitrate combinations and compare the recordings. I did this in some old thread, first post of that thread is a rating table and this is a convenient table for visually comparing the several resulting videos: https://obsproject.com/forum/posts/252221

ps. your chosen combination is ok. Use it.
 
https://obsproject.com/logs/Kn4IpJ-wbhYaQ-Mf

Curious, of your opinion on this. They are telling me:


"We're seeing a lot of high MS delay times in each log.

What this typically means, is that your signal to the ingest servers is not optimal.

It's usually indicative of network delay, or packet loss. Which we see both in your logs.

Can you please run a stream with the 3k bitrate. ^_^ "
 
That is consistent with what I see.

23:55:28.770: Output 'adv_stream': Number of dropped frames due to insufficient bandwidth/connection stalls: 1316 (2.4%)
 
Narcogen said:
That is consistent with what I see.

23:55:28.770: Output 'adv_stream': Number of dropped frames due to insufficient bandwidth/connection stalls: 1316 (2.4%)
Click to expand...
Must have been a wonky stream because I have not changed my bitrate in the past 6-8 tests and it is usually 0.0%
 
Just got this response from them. Going to test and see:



We were originally seeing higher ms response times, but each log shows they're getting lower, and lower. When you stream on the FTL protocol, if you hit a bump in speed or jitter, in this case, the packet data is dropped. Since the FTL protocol runs in real time, these packets are not recovered, and this causes compression to kick in, and take over handling a blend of the colors in your broadcast. This is done so that the broadcast does not go down, or suffers a drop. As a result of this process, this causes artifacting, and distortion on your live broadcast. If you hit too much jitter, for an extended period of time, this can cause your broadcast to go down completely. You won't see these kinds of issues on RTMP, because of the delay associated with it, and the protocol it was designed on. When packets are dropped, they can be recovered because of this delay.

The goal is to find optimal settings that reduce the ms delay for packets from your network, to our ingest servers, so that you drop as few frames as possible. Ideally, you'd want to drop less than 0.5% of your total frames during a broadcast. Within these specifications, your viewers won't notice any issues on their end. In retrospect, higher quality, with fewer dropped frames requires a very strong, and stable upload.

Once we hit a low, stable benchmark, we can tune up from there, until we hit the ceiling. This will provide you with the most stable, and optimal connection on the FTL protocol.

Lowering the bitrate helps us to achieve that low benchmark, so that we can slowly move back up, based on what your connection, and hardware can handle. Ultimately, even with a low bitrate, you can still broadcast to the FTL ingest servers, but you will experience higher delays.

Since every set up is different, and ISPs are different, we have to take a measured approach to fine tune each setting until we've hit the right marks.

We understand that quality, and speed are important to you and your viewers, and we'll do our best to assist you in obtaining the highest quality broadcast you can have, but without logs, and testing this will become increasingly difficult as we continue to troubleshoot.

We'd like to take a slightly different approach. Can you please try these settings, and let us know how things go? Can you also send us the log?

  • 720p, 30 FPS
  • Downscale Filter: Bicubic
  • If you have "Enable new networking code" enabled, please disable it.
  • If you've modified any audio settings, please set them to default values.
  • Rate Control: CBR
  • Enforce Streaming Service Encoder Settings: Unchecked
  • Bitrate: 3000
  • Keyframe Interval: 2
  • CPU Usage Preset: Faster
  • Profile: main
  • Tune: zerolatency
  • x264 options for FTL (required): bframes=0 scenecut=0
 
Last edited:
You must log in or register to reply here.
Back
Top