Why is MediaPlayer.seekTo(int msec) so inaccurate?
为什么MediaPlayer.seekTo(int msec)如此不准确?
It's sometimes 30 seconds early (with mp3's of both variable and constant bitrates)! Is seeking with audio inherently problematic or is this method broken? Is it to do with buffering or what?
它有时提前30秒(使用可变和恒定比特率的mp3)!寻求音频固有问题还是这种方法被打破了?是缓冲还是什么?
I've also noticed that the total runtime getDuration() can be wrong (which isn't a big issue) and I've tested that getCurrentPosition() is accurate enough (as in every n seconds of playback, it increases by n thousand). I'm on Android 2.2.
我还注意到总的运行时getDuration()可能是错误的(这不是一个大问题)我已经测试过getCurrentPosition()足够准确(因为在每n秒播放时,它增加了n000 )。我在Android 2.2上。
Finally, does anybody know which formats if any it actually works consistently for (preferably other than wav which presumably it does)?
最后,是否有人知道哪种格式实际上是一致的(最好不是wav,大概是这样)?
EDIT:
I mainly listen to podcasts. smodcast and Thinking Allowed have been problematic several times, even after being converted/re-encoded to CBR. The files aren't corrupted.
我主要听播客。即使在转换/重新编码为CBR之后,smodcast和Thinking Allowed也会出现多次问题。文件未损坏。
QuickMediaConverter (Windows) seems to work ok but Sound Converter (Ubuntu) has generated some dodgy files. I'll try sticking to the former...
QuickMediaConverter(Windows)似乎工作正常,但Sound Converter(Ubuntu)已生成一些狡猾的文件。我会尝试坚持前者......
UPDATE: QuickMediaConverter works really well but no idea why. No problems since!
更新:QuickMediaConverter工作得很好,但不知道为什么。没问题了!
2 个解决方案
#1
29
There are two ways in which a multimedia framework will perform a seek operation on a multimedia (AV) file.
多媒体框架有两种方式在多媒体(AV)文件上执行搜索操作。
-
Seek to Key frame - The video when encoded will usually have something called as the I frame or the Key frame, it means that this frame has lot of information and can be used to decode a frame in its entirety. To reduce the amount of space all the frames are not encoded as key frames instead they are encoded as P (Predicted) frames or predicted frames, meaning you can decode a P frame with the help from the key frame.
寻找关键帧 - 编码时的视频通常会被称为I帧或关键帧,这意味着该帧具有大量信息,可用于整体解码帧。为了减少空间量,所有帧都不被编码为关键帧,而是将它们编码为P(预测)帧或预测帧,这意味着您可以在关键帧的帮助下解码P帧。
So during the seek operation, in this case the seeking is done to the closest key frame for a given time duration. For example if the user seeks to 40secs and the closest key frame is at 35th sec then seeking is done to the 35th sec and not to the 40th second.
因此,在搜索操作期间,在这种情况下,在给定的持续时间内对最近的关键帧进行搜索。例如,如果用户寻求40秒并且最接近的关键帧是在第35秒,则搜索到第35秒而不是第40秒。
-
Seek to Time - This is seeking to the accurate time that the user demands.
寻求时间 - 这是寻求用户要求的准确时间。
The seeking is still done at the closest key frame since otherwise you will see green patches or pixelation of the video which is highly undesirable. So instead the seeking is done to the key frame and then frames are decoded until the required time but these frames are dropped and are not shown to the user. In above example, all the decoded frames from the 35th to 40th second are discarded and only the frames beyond 40th sec are shown to the user.
搜索仍在最近的关键帧处完成,否则您将看到视频的绿色补丁或像素化,这是非常不受欢迎的。因此,相反,对关键帧进行搜索,然后解码帧直到所需的时间,但是这些帧被丢弃并且不向用户显示。在上面的例子中,丢弃了从第35秒到第40秒的所有解码帧,并且仅向用户显示超过40秒的帧。
In case of audio only files there can be two cases (If there is no parser or a parser that doesnot build the timestamp table then -)
在仅音频文件的情况下,可能有两种情况(如果没有解析器或解析器不构建时间戳表,那么 - )
-
CBR - Constant Bit Rate - Since the bit rate is constant we can skip necessary number of bytes to a given time (Bitrate * timeToSeek = bytes to be skipped)
CBR - 恒定比特率 - 由于比特率是常数,我们可以跳过给定时间内必需的字节数(比特率* timeToSeek =要跳过的字节数)
-
VBR - Variable Bit rate - The bit rate is not constant it keeps varying. So in this case the find out the average bitrate of the file and then use the above method, in this case seeking will not be accurate.
VBR - 可变比特率 - 比特率不是恒定的,它会保持变化。所以在这种情况下找出文件的平均比特率然后使用上面的方法,在这种情况下寻求将不准确。
Now coming back to your question, I can tell with confidence that it works well and is accurate for the majority of the mediafiles.
现在回到你的问题,我可以自信地说,它运作良好,并且对于大多数媒体文件都是准确的。
The only reason why you could be facing such issues is becuase the media file is itself corrupted. (It is just not possible to have a difference of 30seconds during seek + you are saying the duration is not returned correctly. And none of the mediaplayer API's are broken for Android 2.2)
您可能遇到此类问题的唯一原因是因为媒体文件本身已损坏。 (在搜索期间不可能有30秒的差异+你说的是没有正确地返回持续时间。并且Android 2.2都没有破坏媒体播放器API)
As to which formats is supported by Android see this link
至于Android支持的格式,请参阅此链接
So can you try with an another mp3 file?
你可以试试另一个mp3文件吗?
#2
0
i dont know anything about android. But i know that in most of media file format there is a one provision that called seek entries or cues entry.. that shows for this particular time from here video & audio should be start to play
我对android没什么了解。但我知道在大多数媒体文件格式中都有一个调用搜索条目或提示条目的条款..从这里显示此特定时间视频和音频应该开始播放
if below time has cues entry 10 sec
12 sec
14 sec
如果低于时间提示进入10秒12秒14秒
then if you seek to 11 sec then it will always play from 10 second if you seek to 12 sec then it will always play from 12 second
然后,如果你寻求11秒,那么如果你寻求12秒,它将始终从10秒开始,然后它将始终从12秒开始
for better seek file should be muxed with high cues entry..
为了更好的搜索文件应该与高提示条目复用..
#1
29
There are two ways in which a multimedia framework will perform a seek operation on a multimedia (AV) file.
多媒体框架有两种方式在多媒体(AV)文件上执行搜索操作。
-
Seek to Key frame - The video when encoded will usually have something called as the I frame or the Key frame, it means that this frame has lot of information and can be used to decode a frame in its entirety. To reduce the amount of space all the frames are not encoded as key frames instead they are encoded as P (Predicted) frames or predicted frames, meaning you can decode a P frame with the help from the key frame.
寻找关键帧 - 编码时的视频通常会被称为I帧或关键帧,这意味着该帧具有大量信息,可用于整体解码帧。为了减少空间量,所有帧都不被编码为关键帧,而是将它们编码为P(预测)帧或预测帧,这意味着您可以在关键帧的帮助下解码P帧。
So during the seek operation, in this case the seeking is done to the closest key frame for a given time duration. For example if the user seeks to 40secs and the closest key frame is at 35th sec then seeking is done to the 35th sec and not to the 40th second.
因此,在搜索操作期间,在这种情况下,在给定的持续时间内对最近的关键帧进行搜索。例如,如果用户寻求40秒并且最接近的关键帧是在第35秒,则搜索到第35秒而不是第40秒。
-
Seek to Time - This is seeking to the accurate time that the user demands.
寻求时间 - 这是寻求用户要求的准确时间。
The seeking is still done at the closest key frame since otherwise you will see green patches or pixelation of the video which is highly undesirable. So instead the seeking is done to the key frame and then frames are decoded until the required time but these frames are dropped and are not shown to the user. In above example, all the decoded frames from the 35th to 40th second are discarded and only the frames beyond 40th sec are shown to the user.
搜索仍在最近的关键帧处完成,否则您将看到视频的绿色补丁或像素化,这是非常不受欢迎的。因此,相反,对关键帧进行搜索,然后解码帧直到所需的时间,但是这些帧被丢弃并且不向用户显示。在上面的例子中,丢弃了从第35秒到第40秒的所有解码帧,并且仅向用户显示超过40秒的帧。
In case of audio only files there can be two cases (If there is no parser or a parser that doesnot build the timestamp table then -)
在仅音频文件的情况下,可能有两种情况(如果没有解析器或解析器不构建时间戳表,那么 - )
-
CBR - Constant Bit Rate - Since the bit rate is constant we can skip necessary number of bytes to a given time (Bitrate * timeToSeek = bytes to be skipped)
CBR - 恒定比特率 - 由于比特率是常数,我们可以跳过给定时间内必需的字节数(比特率* timeToSeek =要跳过的字节数)
-
VBR - Variable Bit rate - The bit rate is not constant it keeps varying. So in this case the find out the average bitrate of the file and then use the above method, in this case seeking will not be accurate.
VBR - 可变比特率 - 比特率不是恒定的,它会保持变化。所以在这种情况下找出文件的平均比特率然后使用上面的方法,在这种情况下寻求将不准确。
Now coming back to your question, I can tell with confidence that it works well and is accurate for the majority of the mediafiles.
现在回到你的问题,我可以自信地说,它运作良好,并且对于大多数媒体文件都是准确的。
The only reason why you could be facing such issues is becuase the media file is itself corrupted. (It is just not possible to have a difference of 30seconds during seek + you are saying the duration is not returned correctly. And none of the mediaplayer API's are broken for Android 2.2)
您可能遇到此类问题的唯一原因是因为媒体文件本身已损坏。 (在搜索期间不可能有30秒的差异+你说的是没有正确地返回持续时间。并且Android 2.2都没有破坏媒体播放器API)
As to which formats is supported by Android see this link
至于Android支持的格式,请参阅此链接
So can you try with an another mp3 file?
你可以试试另一个mp3文件吗?
#2
0
i dont know anything about android. But i know that in most of media file format there is a one provision that called seek entries or cues entry.. that shows for this particular time from here video & audio should be start to play
我对android没什么了解。但我知道在大多数媒体文件格式中都有一个调用搜索条目或提示条目的条款..从这里显示此特定时间视频和音频应该开始播放
if below time has cues entry 10 sec
12 sec
14 sec
如果低于时间提示进入10秒12秒14秒
then if you seek to 11 sec then it will always play from 10 second if you seek to 12 sec then it will always play from 12 second
然后,如果你寻求11秒,那么如果你寻求12秒,它将始终从10秒开始,然后它将始终从12秒开始
for better seek file should be muxed with high cues entry..
为了更好的搜索文件应该与高提示条目复用..