If it turns out that the second defined for the is the one that gets used in this situation, then this may be the reason why this improves the cache issue. Presumably, the ATEM streaming engine will pick one of the two configurations to use, but I'm not sure how it decides which one. ![]() ![]() I am not exactly sure what happens if you specify two different sections with the same fps value in a particular streaming. The ATEM can easily pick which bitrate setting to use based on the video standard of the switcher and since each element for a given in the XML file specifies a different fps value. In the default version of the XML file, the lower bitrate target for each streaming profile is used for frame rates up to 30 fps, and the higher bitrate target is used for frame rates up to 60 fps. The reason that there are two different bitrate configurations for each streaming profile is to better accommodate different video frame rates, since higher frame rates typically require a higher video data rate. I've changed the profiles for high, medium, and low to now be a variable range (pictured) and we haven't had the cache issue since. My friend theorized that maybe those two bitrate values need to represent a range, rather than a single number. ![]() Then we would regularly have the cache problem. ![]() Previously, for "high" I had set both of those parameters as the same value (450000). GenePensiero wrote:In the streaming.xml file, when you tinker with the streaming profiles, it gives you two places per profile for bitrate.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |