rse
21st March 2008, 22:54
Hi!
Iīm writing my own Mediaplayer with Lazarus relying on DShow for playback. I now want to speed the playback up, what is possible through MediaSeeking.SetRate(newrate), but thereīs a catch:
For detecting playbacks that donīt progress (= nothing to hear or to see), Iīm watching the current playback-position every 50ms. If it doesnīt change for 20 times (= 1 second), I kick the just playing file from the playlist. That works fine for normal playback speed, but when the speed is reduced, there is a certain time (which is accordingly longer when the playback rate is slower), when the playback is resuming, where the position doesnīt change. It is long enough to kick a file, if the rate is low enough. Right after this time is over, the position is progressing correctly again.
I donīt know that much about the internals of the mp3-algorithm, but if there are GOP-like structures, then I could imagine whatīs going on. Speaking with words of video-compression it would be the following: If playback resumes (at the lower rate) in the middle of a GOP, then the audio starts playing at the preceding keyframe, while the position-counter just waits in the middle of the GOP till the real playback passes this point before counting on. Can somebody confirm or disprove this?
What could I possibly do to prevent this pause in the progress-counter, which is responsible for a file being kicked when the playback speed is set too low?
Edit: What must I do if I want the pitch to remain stable while changing the speed? Do I have to write my own DShow-filter which adjusts the pitch and put it manually into the filter chain?
Iīm writing my own Mediaplayer with Lazarus relying on DShow for playback. I now want to speed the playback up, what is possible through MediaSeeking.SetRate(newrate), but thereīs a catch:
For detecting playbacks that donīt progress (= nothing to hear or to see), Iīm watching the current playback-position every 50ms. If it doesnīt change for 20 times (= 1 second), I kick the just playing file from the playlist. That works fine for normal playback speed, but when the speed is reduced, there is a certain time (which is accordingly longer when the playback rate is slower), when the playback is resuming, where the position doesnīt change. It is long enough to kick a file, if the rate is low enough. Right after this time is over, the position is progressing correctly again.
I donīt know that much about the internals of the mp3-algorithm, but if there are GOP-like structures, then I could imagine whatīs going on. Speaking with words of video-compression it would be the following: If playback resumes (at the lower rate) in the middle of a GOP, then the audio starts playing at the preceding keyframe, while the position-counter just waits in the middle of the GOP till the real playback passes this point before counting on. Can somebody confirm or disprove this?
What could I possibly do to prevent this pause in the progress-counter, which is responsible for a file being kicked when the playback speed is set too low?
Edit: What must I do if I want the pitch to remain stable while changing the speed? Do I have to write my own DShow-filter which adjusts the pitch and put it manually into the filter chain?