Re: SCAudioFillBuffer

On Sep 18, 2006, at 9:15 PM, David M. Cotter wrote:

I too am trying to write out a QT movie using SCAudioFillBuffer, i am being handed a (video) frame and a frame's worth of uncompressed audio (44k, 16 bit big endian int, interleaved stereo)

How do I calculate how many packets to ask for, that results in exactly N bytes of uncompressed audio getting sucked thru?

There's no exact way to do this. (Believe me I've tried!). The AudioConverter uses a pull model, not a push model. That said, the AudioConverter contract is much more lax than AudioUnits'. No matter how much you ask for, in your input proc, you can provide ALL the samples you have, and it will internally copy and buffer them if your output isn't going to consume all of them on the current pull.

In general, it's a good idea to err on the "pull for a little too much" side, rather than pull for too little. SCAudio is not obligated to provide all the packets you pulled for. It can provide none, fewer than you asked for, or exactly the number you asked for (but never more, since that would overrun your output buffer).

If you know how many packets of input you've got, and your input format is not variable-frames-per-packet (i.e. it has a non-zero mFramesPerPacket), and your output format is not variable-frames per packet (i.e. it also has a non-zero mFramesPerPacket), then you can compute how many packets to pull for.

for example: i need to pull exactly 2940 (uncompressed audio) samples per (video) frame (it's 15 fps).

going from what you said below:

numCompressedPackets = 2940 / asbd.mFramesPerPacket;

Unfortunately, that is a float number: 2.87109 "compressed" packets is what I apparently need to request, in order to pull out exactly 2940 uncompressed samples on this frame.

If I round up, i run out of audio before i run out of video, they're supposed to finish at the same time.

It's a bad idea to try to consume exactly 1 video frame's worth of audio through SCAudio (or AudioConverter for that matter), unless you're going to a PCM format. If you're going to a compressed format, you're not going to be able to make them line up exactly. But as I said above, SCAudio will internally buffer anything you don't use up in the current pull round, and give it to you the next time.

Then i think, well i'll only return 2940 samples no matter how many they ask for, yeah that'll show 'em!
But, what happens is, SCAudioFillBuffer()doesn't just return to the caller if, in my input callback, i say "i'm only going to give you 2940 samples", what happens is my input callback is called *repeatedly* until SCAudioFillBuffer() is satisfied, and THEN it returns.

Is there some setting i've missed?

Whenever your input proc is called, provide all the input you currently have available. If your input proc is called and you are currently dry (but not permanently out of data), simply return an error from your input proc. If you are out of data and won't be getting any more, set *ioNumPackets to zero, and all the ioData mData's to NULL.

-Brad Ford

QuickTime Engineering

should i just accumulate my audio and wait until there's at least an even multiple and THEN process it?

Begin forwarded message:

Yes, I have been following the scaudiocompress sample. However, when
our app publishes it sends me one video frame and that frame worth of
audio at a time, and specifies the buffer size. So for PCM output I
calculate ioOutputDataPacketSize as numPackets =
bufferSize/asbd.mBytesPerPacket which works. For Apple Lossless output
I get MaximumOutputPacketSize, but it's larger then the sound buffer I'm
given. In this case what should numPackets be?

MaximumOutputPacketSize tells you the maximum size (in bytes) that a single packet might be. In the case of Apple Lossless, if you look at the asbd, it should tell you how many pcm frames are in one packet by inspecting the mFramesPerPacket field.

I've tried numPackets =
1 but then SCAudioFillBuffer returns a PacketDescription with all the
members = 0.

I just tried "scaudiocompress -i /path/to/an_audio_file.aiff -o /path/to/a_quicktime_movie.mov -pullpackets 1

Then in the dialog, I specified Apple Lossless, and it worked perfectly. So you can definitely pull for just 1 packet of lossless at a time, if you so desire.

On Sep 7, 2006, at 12:22 PM, Joe Honoroff wrote:

Where are the error return codes defined for SCAudioFillBuffer and
QTSetComponentProperty?

I get uncompressed PCM 44100Khz, 16bit, stereo from our app and I'm
using the new SCAudioFillbuffer. I got it to work using the same
output format, but now I'm trying to ouput Apple Lossless and
SCAudioFillBuffer returns 0x77686174.

_______________________________________________
Do not post admin requests to the list. They will be ignored.
QuickTime-API mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quicktime-api/email@hidden

This email sent to email@hidden

References:
	>RE: SCAudioFillBuffer (From: "Joe Honoroff" <email@hidden>)
	>Fwd: SCAudioFillBuffer (From: Brad Ford <email@hidden>)
	>Re: SCAudioFillBuffer (From: "David M. Cotter" <email@hidden>)