I find when I stream out to some services like YouTube and Eventive, even though I’ve entered an amount in the ‘data rate’ field, the server (if that’s the right word) that’s receiving the RTMP data will throttle it down and reduce the frame rate when I have a still image onscreen, “thinking” I’m sending more data than is necessary. I can see the graph in mimoLive show the drop, and also the numbers. Then, when I cut back to moving image there’s not enough data/frames and it takes the receiving server several seconds or more to “realize” I’m back on a moving image and readjust the data and frame rate back up.
Is there any way to set a minimum in mimoLive so that the data rate does not drop below a certain amount, regardless of what YouTube’s or Eventive’s system perceives what I’m doing?
I show silent movies (with live music) on my streams, and as you can imagine this happens on most of my shows. (Except for Vimeo…for some reason Vimeo’s system is much better about this.)
Thanks for sharing, Ben. That’s an interesting phenomenon. I also have to watch this. (Could you please add your text to the MimoLive-Forum? => Edit title => Category. Thx.).
Hi Ben, Thanks for the report. This is a feature of the h.264 compression: If nothing changes in the image, it will be compressed to zero. The easiest workaround is to add an animation to the still image.
However, it is interesting that YouTube and Eventive may not be able to deal with big changes in data rates. We’ll have to investigate this.
I recognize this variable rate scenario from mpeg2 DVD compression; the difference is that with DVDs the rate changes just for that particular shot, and in the live-streaming setting it seems to be done ‘on the fly’ by the receiving server based on what’s being RTMP-ed up from mimoLive. YouTube, of course, cannot be contacted, but I am in touch with some IT people at Eventive about this to investigate, as – strangely – my 3 shows with Eventive had this variable rate throttling happen more severely than with YouTube! Vimeo livestreaming does not seem to have this issue, or at least doesn’t have it as severely.
re: the h264 compression – I currently have “Profile Level” at the default setting of “auto”. Would selecting one of the other options in the dropdown, such as “h264 High” help my situation?
@undercrank , please be careful. Try it at your own risk!! In the best case, the result increases, everything gets better. In worst case, no stream, no recording, just nothing. Currently, I do not know anything about the noticed sub-levels. I cannot connect this information (H.264 High Profile: Codec for Broadcast & Professional Video Application) with 3 0, 3 1, 4 0 and so on.
Yes, I have. I am using a setting that is 1.5-4.0MB but I have seen this drop below 1.0MB during a stream to YouTube, usually when I have a static graphic on screen. However, I have also seen the rate go above 4.0, if there’s a section of a film with a lot of action or movement.
However, I may give the next level up a go and see if it helps. We are streaming at 1280x720 and not 1980x1080 and at 30 fps.
Still this is on YouTube’s end, and I’ve seen the sliding down and up of the rate happen on YT, Eventive and on Vimeo, except that Vimeo’s servers don’t throttle the data as severely and are almost always great.
I’d still be curious to know from @Achim_Boinx or @Oliver_Boinx if they think selecting H264 High Auto in the “Profile Level” could cause a problem.
Not yet. I wanted to get some more info before trying a different setting, but I had a feeling one of the “h264 High ____” options might be better than the general “Auto” default. I’ve a feeling that even using “High AutoLevel” will at least set some sort of lower-end threshhold.
Oliver recommendet to place a rotating/moving/changing (tiny) overlay to the image, to force the receiving rtmp(s) server to not reduce the quality/frame rate. I think that planned bandwith saving seems to be a part of the standard, but I might be also wrong.
You could use some kind of moving “station”-id. “Heading with Object”, but without a Background and without additional Text. (The whole broadcast/stream).
