我希望获得seekto()类的MediaPlayer方法所使用的字节偏移量。
我想知道是否有任何方式直接以某种方式检索此信息，如果没有，如果有自己计算它自己例如： 如果媒体文件在其元数据中具有已注册的比特率，并且我想寻求10秒，我可以使用以下计算：
10(secs)*(bit rate per second)/8
我可以假设MediaPlayer使用MediaMetadataRetriever类检索比特率信息吗？
我已阅读以下内容：
Accuracy of MediaPlayer.seekTo(int msecs)
我知道可变比特率的问题，但我不是在寻找seekto()方法的准确性，而是如何获取/计算它用于检索新数据的偏移量的值。
答案 0 :(得分：1)
您基于偏移实现seekTo()的目标是新颖的，但同样存在多个挑战。在进入seekTo()实施之前，请先澄清MediaPlayer和MediaMetadataRetriever。这两个类都在内部使用MediaExtractor对象来检索metadata信息。因此MediaPlayer 不包含MediaMetadataRetriever类。
首先，让我们考虑提取比特率。 MediaPlayer是一个通用实现，应该支持多种文件格式。因此，对于您的设计，您需要确保系统支持的所有文件格式都提取bitrate参数，例如MP4，MPEG-2 TS，{{1}等视听格式}，AVI等或音频格式只有Matroska，WAV等。在最新的Android实现中，我发现只有MP3通过{{1}暴露比特率}键。
接下来，在您的算法中，我发现基于大小的搜索附加了以下挑战。
MP3Extractor和kKeyBitrate个曲目以交错方式存储。因此，由于输入数据的交错特性，audio不会直接有用。
需要考虑起始偏移量。在文件中，文件的开头存储了一些video或time * bitrate (in bytes)，这些文件特定于文件格式。您还必须考虑这种偏移，这对于不同的格式也会有所不同。
如果您的输入包含更多数量的曲目，例如电影中的metadata，boxes，audio或更多video曲目，则问题将会出现变得更加复杂。
视频帧的大小通常不规则。即使采用恒定比特率模型，视频帧大小也可能根据帧的类型而显着变化。通常，与text或audio相比，I-frame / IDR-Frame in H.264会占用大量比特。这将为基于大小的P-frame实施带来实际困难。人们可以很容易地在I帧和P帧的帧大小方面观察到 1：5 比率
您已经承认的可变比特率模型有一定的影响。因此，我正在跳过这一点。
有了上述观点，在不劝阻你的情况下，我觉得基于B-frame的实施看起来很困难。