Guided reclock interface

[alexmarsev]

Design and implement.

[alexmarsev]

First draft

// This interface is queried from graph clock, preferably in IMediaFilter::SetSyncSource()
IGuidedReclockDraft : IUnknown
{
    // Returns the average amount of adjustment per second below which audio renderer is
    // guaranteed to use high quality sample rate conversion instead of time stretching.
    // Usually, audio renderer allows short bursts of larger adjustments before
    // switching to time stretching.
    //
    // The value is guaranteed to stay the same until a new graph clock is
    // set by IMediaFilter::SetSyncSource()
    STDMETHOD(GetTimestretchingThreshold)(REFERENCE_TIME* pThreshold) = 0;

    // Instantly offsets graph clock by requested amount. When the method returns, the clock
    // is guaranteed to be adjusted already. Audio renderer is responsible for smoothing out
    // the values and catches up to adjustment after some time.
    STDMETHOD(OffsetClock)(REFERENCE_TIME offset) = 0;
};

[alexmarsev]

@zachsaw This is what I meant by "new public interface". Will it be useful? Do video renderers need something more?

[zachsaw]

This is perfect! Very very useful and won't take much time to add to MPDN at all!

BTW, would it be possible to do pitch shift via the same interface too? For example, someone might want to correct PAL speedup by lowering framerate along pitch.

[zachsaw]

Actually, thinking of this a bit more, I think OffsetClock needs to be against system clock (i.e. QPC) and not relative to the default reference clock derived from audio card. There's no way for a video renderer to know what the exact drift is to make a correction until it's gone about 4 minutes into the playback without pausing.

I believe to make this useful without user having to wait 4 minutes to fine tune each media type of different FPS, offset needs to be made relative to QPC clock - this is how reclock does it too. With reclock, you can see MPDN's refclk deviation is always 0%. The only trouble is, there's no way to change this refclk deviation via an interface. Even if it's relative to system time, a video renderer still has to figure out what the actual FPS is of the source before setting the offset. Once it knows what the actual FPS is, it's quite easy then for the video renderer to change the refclk deviation so it speeds up or slows down to match FPS to display refresh rate.

[zachsaw]

BTW this would not work if we're bitstreaming right?

[alexmarsev]

BTW, would it be possible to do pitch shift via the same interface too? For example, someone might want to correct PAL speedup by lowering framerate along pitch.

0.1% difference in pitch is not perceivable. I think it makes more sense to just slave to monitor rate, and if the drift is low enough audio renderer will adjust with pitch (not time stretching).

BTW this would not work if we're bitstreaming right?

Yes, I can't do much there. Reclock and bitstreaming just can't work together. Decoding and re-encoding is not really an option.

Actually, thinking of this a bit more, I think OffsetClock needs to be against system clock (i.e. QPC) and not relative to the default reference clock derived from audio card.

Resolution of graph clock is already the same as QPC. I receive audio position in conjunction with QPC for that position, then "overclock"/extrapolate with current QPC value.

IGuidedReclock::OffsetClock() is intended to be called repeatedly. If graph clock drifts slightly, video renderer just corrects it repeatedly. Like, at every frame. I don't really see why video renderer can't assume in the beginning that graph clock will be the same as QPC, make initial decisions based on that and then correct the clock later?

[zachsaw]

It's definitely possible for the video renderer to do all of that but wouldn't it be better if it's implemented in the audio renderer then it saves all of us having to write our own version of it?

IGuidedReclock::SlaveToSystemClock()
IGuidedReclock::OffsetClock() repeatedly as refresh rate gets detected to higher precision.

If you don't provide us with the SlaveToSystemClock() method, we'll just be doing exactly that before calling OffsetClock().

[alexmarsev]

I thought video renderer could drop clock smoothing entirely with IGuidedReclock. The amount of drift is abysmal and can't affect immediate presentation logic.

[alexmarsev]

I just need to be sure we're not complicating the interface needlessly.

[zachsaw]

Yes that's the goal, but in order to do that, we'll need to call OffsetClock with a value to correct the drift. But what is the drift? We need something to detect the drift first don't we? Otherwise what value do we call OffsetClock with?