Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
- Subject: Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
- From: Heinrich Fink <email@hidden>
- Date: Wed, 21 Dec 2011 10:16:10 +0100
Brian, Ross, thanks for your input!
> I don't think you're being clear enough about what kind of host you're writing to discuss "customary" behavior. Is this a video editing tool, an movie player, a DAW..?
It’s a TV broadcast playout host where multiple movies and audio clips are scheduled on a global timeline (e.g. you can create the next week’s schedule for your TV station). At the moment we are always using a single device for video and audio output.
>> If you can ensure that your video rendering is tied to the
>> high-accuracy CoreAudio clock then there will be no disadvantage to
>> processing audio and video in separate paths.
>
> Assuming that you are not already trying to synchronise to a house clock source.
I have just recently joined this software project, but as far as I see it, we are keeping a project timeline which is advanced based on frame requests of the video output hardware. At the beginning/end of a clip we are optionally synchronizing the project timeline with an external LTC time source (by skipping frames or by inserting black frames).
> Without further info, in your context, using Varispeed just because you can't clock the video off the audio sound like a hack, and not a very pleasant one.. but perhaps I don't understand the requirements.
Sorry, I think I wasn’t clear enough about my question. I assume that A/V output is using the same clock domain anyway, because A/V is either played out by the same physical device, or two separate devices would be synchronized externally by hardware, which I guess you can expect in a prosumer/professional environment (please correct if I’m wrong). So even if separate software paths are used for A/V, I wouldn’t expect drift here since they are ultimately driven by the same clock.
So my actual question was if some hosts compensate for drift against the wall clock also during playback, so that the begin and end times of a longer clip would actually be accurate to a clock outside the device’s clock. But I guess that such decisions have to be accessible as user options (such as those from Logic as you mentioned). From your comments I understand that users would probably accept a slight time off or losing a few frames due to sync at the boundary of their clips in favor of bit-accurate and high-quality playout during the clip.
best,
Heinrich
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden