为什么MediaPlayer.seekTo(int msec)如此不准确？
它有时提前30秒（使用可变和恒定比特率的mp3）！寻求音频固有问题还是这种方法被打破了？是缓冲还是什么呢？
我还注意到总运行时间getDuration()可能是错误的（这不是一个大问题）我已经测试getCurrentPosition()是否足够准确（如每n秒钟一次）播放，它增加了n千）。我在Android 2.2上。
最后，是否有人知道哪些格式实际上是一致的（最好是wav以外的其他格式）？
编辑：
我主要听播客。即使在转换/重新编码为CBR之后，smodcast和Thinking Allowed也会出现多次问题。文件没有损坏。
QuickMediaConverter（Windows）似乎工作正常，但Sound Converter（Ubuntu）已生成一些狡猾的文件。我会尝试坚持前者......
更新：QuickMediaConverter工作得很好，但不知道为什么。没问题！
答案 0 :(得分：31)
多媒体框架有两种方式在多媒体（AV）文件上执行搜索操作。
寻找关键帧 - 编码时的视频通常会被称为I帧或关键帧，这意味着该帧具有大量信息，可用于整体解码帧。为了减少空间量，所有帧都不被编码为关键帧，而是将它们编码为P（预测）帧或预测帧，这意味着您可以在关键帧的帮助下解码P帧。
因此，在搜索操作期间，在这种情况下，在给定的持续时间内对最近的关键帧进行搜索。例如，如果用户寻求40秒并且最接近的关键帧是在第35秒，则搜索到第35秒而不是第40秒。
寻求时间 - 这是寻求用户要求的准确时间。
搜索仍在最近的关键帧处完成，否则您将看到视频的绿色斑点或像素化，这是非常不受欢迎的。因此，对关键帧进行搜索，然后解码帧直到所需的时间，但是这些帧被丢弃并且不向用户显示。在上面的例子中，第35秒到第40秒的所有解码帧都被丢弃，只有超过40秒的帧被显示给用户。
对于仅音频文件，可能有两种情况（如果没有解析器或解析器不构建时间戳表 - 那么
CBR - 恒定比特率 - 由于比特率是常数，我们可以跳过给定时间内必需的字节数（比特率* timeToSeek =要跳过的字节数）
VBR - 可变比特率 - 比特率不是恒定的，它会保持变化。所以在这种情况下，找出文件的平均比特率，然后使用上面的方法，在这种情况下，搜索将不准确。
现在回到你的问题，我可以自信地说，它运作良好，并且对大多数媒体文件都是准确的。
您遇到此类问题的唯一原因是媒体文件本身已损坏。 （在搜索期间不可能有30秒的差异+你说的是没有正确地返回持续时间。并且没有任何媒体播放器API在Android 2.2中被破坏）
有关Android支持的格式，请参阅此link
那你可以试试另一个mp3文件吗？
答案 1 :(得分：0)
我对Android没有任何了解。但我知道，在大多数媒体文件格式中，有一个规定称为搜索条目或提示条目。 这个特定的时间从这里显示视频＆amp;音频应该开始播放
如果低于时间有提示输入
10秒
12秒
14秒
更好的搜索文件应该与高提示条目复用..