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