MPMoviePlayerController MovieAccessLogEvent - 膨胀的observeBitrate [英] MPMoviePlayerController MovieAccessLogEvent - Inflated observedBitrate
问题描述
我目前正在使用 MPMoviePlayerController 并正在分析视频播放的指标。具体来说，分析自适应比特率。
I am currently working with the MPMoviePlayerController and am analysing metrics for video playback. Specifically, analysing adaptive bitrates.
作为测试的一部分，我以固定的比特率（ 995kbps ）加载视频的特定再现，但是从我的 MPMovieAccessLogEvent 的 observedBitrate 属性读取，这个值更加膨胀 - 大约 15mbps 。
As part of testing I load a particular rendition of the video at a fixed bitrate (995kbps), however when reading from the observedBitrate property of my MPMovieAccessLogEvent, this value is much more inflated - to the tune of around 15mbps.
是否有任何已知原因导致返回的比特率远高于播放的比特率？我已经仔细检查了所有值和所有回放，并且它绝对是夸大的 observedBitrate 。
Is there any known reason why this bitrate being returned is considerably higher than that of the playback? I have double checked all values, and all playback, and it is definitely the observedBitrate that is inflated.
根据到文档，这个值是：
According to the documentation, this value is:
为电影
播放器下载的所有媒体的经验吞吐量，以每秒位数为单位。
The empirical throughput across all media downloaded for the movie player, in bits per second.
更新
我发布了这个问题在开发者论坛上并且已经收到了答案，这仍然只是猜想但是认为它可能有助于这个问题并且可能引发更好的答案。
I posted this question on the developer forums and have received an answer, which is still just conjecture but thought it might aid the question anyway and maybe provoke a better answer.
使用mediastreamvalidator
检查您的HLS视频是值得的，它将下载并测量您的网段比特率。
It would be worth checking your HLS video with mediastreamvalidator which will download and measure your segment bit rates.
推荐答案
有一个简单的答案 - shownBitrate 的 MPMovieAccessLogEvent （或 AVPlayerItemAccessLogEvent for AVPlayer ）是当前播放列表的比特率，播放流所需的平均比特率也是如此。
There is a simple answer to this - the indicatedBitrate of a MPMovieAccessLogEvent (or AVPlayerItemAccessLogEvent for AVPlayer) is the bitrate from the current playlist, so is an average bitrate required to play the stream.
然而， observedBitrate 不是平均值 - 它是玩家在下载特定视频块时所达到的瞬时比特率（或下载速度）。
However, the observedBitrate is NOT averaged - it is the instantaneous bitrate (or download speed) which the player achieved while downloading a particular chunk of video.
示例：播放1000 Kb / s流的播放列表，每个播放10秒。该设备可通过WiFi实现超过10MB / s的下载，因此下载每个块需要不到1秒的时间。因此，播放器在每个块期间以超过10,000 Kb / s的速度下载。
我希望玩家返回（大约）这些值：
Example: Playing a playlist with a 1000 Kb/s stream, in chunks of 10 seconds each. The device can achieve over 10MB/s download over WiFi, so it takes less than 1 second to download each chunk. Therefore, the player is downloading at over 10,000 Kb/s during each chunk. I'd expect the player to return (approximately) these values:
shownBitrate ：1000 Kb / s
indicatedBitrate: 1000 Kb/s
observedBitrate ：10,000 Kb / s
observedBitrate: 10,000 Kb/s
我自己对这些巨大的价值观感到困惑，但我认为这解释了它。
I'd been mystified by these large values myself, but I think this explains it.
这只是为了说明 - 这些价值因为我们不是很有意义我真的知道下载一个块需要多长时间，或者确实知道每个块有多大。所有 observedBitrate 确实告诉你玩家是如何设法跟上播放流所需的比特率。如果前者比后者大10倍，那么它只使用10％的可用时间来下载每个块。该比率可以用作服务质量指标。
例如，如果 observedBitrate 小于 shownBitrate 那么玩家很可能会由于缓冲失速，但只要它更大，那么一切都很好，流可能会顺利播放。
This is just for illustration - these values are not very meaningful since we don't really know how long it takes to download a chunk, or indeed how big each chunk is. All the observedBitrate really tells you is how well the player is managing to keep up with the bitrate needed to play the stream. If the former is 10x bigger than the latter, then it is only using 10% of the available time to download each chunk. This ratio may be used as a quality-of-service indicator.
For example, if the observedBitrate is less than the indicatedBitrate then it is very likely that the player will stall due to buffering, but as long as it is greater, then all is well and the stream is likely to play smoothly.
这篇关于MPMoviePlayerController MovieAccessLogEvent - 膨胀的observeBitrate的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
