1 Jun 2012 06:44
Re: soundtouch filter?
Pavel Koshevoy <pkoshevoy <at> gmail.com>
2012-06-01 04:44:55 GMT
2012-06-01 04:44:55 GMT
On 05/31/2012 08:37 AM, Nicolas George wrote: > Le primidi 11 prairial, an CCXX, Pavel Koshevoy a écrit : >> I have some concerns regarding timestamps. In my opinion this >> filter should not change the timestamps. > Timestamps should be, as far as possible, consistent with playback duration. > If the filter is set up to change the pitch and not the speed, the > timestamps should be unchanged. If the filter is set up to change the speed, > the timestamps should be scaled accordingly, IMHO. > This filter will consume N samples and output N/tempo samples, without affecting pitch. So, at 0.5 tempo twice as many samples are output. I am not planning on implementing pitch shifting in this filter. If only audio timestamps are adjusted audio will no longer be in sync with video and subtitles. This may be intentional (perhaps the user is trying to correct a lip-sync error caused by a telecine conversion). However, if the users intention is to slow down or speed up everything (not just the audio) and keep audio/video sync then the timestamps of all streams need to be transformed according to the current tempo. Frankly, I am not at all well versed in avfilter APIs to know how to do that yet -- I am still trying to figure out what an AVFilterPad is. Regarding my preference to not change the timestamps -- I am simply concerned about the effect that this would have on video player time-line if the user varies tempo continuously during playback. As far as I can see there are only a couple of options available for updating the timestamps: 1. Timestamps can be calculated with reference to previous frame. This ensures that the transformed timestamps remain monotonically increasing. However, it complicates calculation for time-line duration and seeking, because the timestamp mapping function is non-linear. 2. Timestamps can be calculated from the beginning of the stream. This means the entire timeline is linearly transformed according to current tempo. This also means that timestamps will not be monotonically increasing if the user jumps from 0.5 tempo to 2.0 tempo. This is a problem for audio/video renderers that expect monotonically increasing timestamps. If a renderer sees a timestamp from the past (as far as the renderer is concerned) it may simply drop the "stale" frame. Given these options, in my player instead of changing timestamps I added a tempo field to the decoded frame. This way the time-line duration and seeking are not affected at all, and video/audio renderers can trivially adjust the frame duration and maintain synchronization. Thank you, Pavel.