onlySummaryBBufferConsumerは、BBufferProducerクラスと対になるものです—自分に接続されたBBufferProducerからBBufferを受け取り、なんらかの方法でそれを(バッファの内容を一部改変するか、スピーカーやスクリーンでデータを演奏・表示するかのいずれかで)操作し、(もしそのnodeがBBufferProducerから派生している場合)可能ならそれを他のBBufferConsumerに渡します。このクラスの関数はアプリケーションまたは他のnodeからは呼び出されません。Kitから排他的に呼び出されます。BBufferConsumerはcertain_inputを発行します。それはmedia_destination構造体によって識別され、クライアントアプリケーションによって接続が要求されます。consumerType)BBufferConsumerのコンストラクタ。BBufferConsumerが受け入れるデータの型をconsumerTypeに指定します。4.5.2及びそれ以前のconsumerTypeはデフォルト値を持っています。typeを実際に指定しなければなりません。~BBufferConsumerprotected:~BBufferConsumer()BBufferConsumerのデストラクタ。nodeが必要とする終了時の動作を扱うために、これを増やすことができます。nodeが生成され、任意のproducerに対してBBufferGroupを設定するならば、それらをデストラクタ中で削除して下さい。0指定されたformatが指定されたdestinationに対して妥当であるかチェックし、あなたのBBufferConsumerが持つ特定の要求に対するワイルドカードフィールドを満たすように、このフック関数を実装して下さい。formatが妥当でなければ(あるいはdestとして不適当なクラスであれば)、B_MEDIA_BAD_FORMATを返します。Kitは、フォーマットの不適合による失敗なしに、指定されたformatによるdestinationへの接続が要求されると予想します。フォーマットに関して上流のproducerに問い合わせないで下さい。producerは同期的にあなたの反応を待ち、それはデッドロックの原因となります。0BBufferProducerがBBufferConsumerの入力の一つにバッファを送ったとき、バッファは結局ここ、(HandleMessage()によって通常最初にディスパッチされる)BufferReceived()関数に辿り着きます。内部的なキューの再生を行うためにbufferを追加したり、あるいはなんであれバッファを消費する必要がある場合、このフック関数をオーバーライドして下さい。BBufferProducer及びBBufferConsumerの両方を実装した場合、bufferのデータを検証して改変した後、なにか他のものにそれを送るためBBufferProducer::SendBuffer()を呼び出します。bufferの内容とtiming要求に関する情報は、バッファのBBuffer::Header()を呼び出すことで得られます。あなたがnodeを書いて、バッファにB_SMALL_BUFFERフラグをセットするなら、関数が戻る前にバッファを再利用(recycle)しなければなりません。producerからdestinationの入力へ接続が確立される時に呼び出されます。接続は指定されたformat(以前にAcceptFormat()経由で受け取ったもの)によって形作られます。Connected()には、接続のデータ入力を扱うのに必要となる準備を全て実装し、またoutInputバッファをnodeの視点による接続の情報で埋めるよう実装して下さい。destinationが接続の交渉に使用され、その後実際のデータストリームを扱う新しい入力を作りだす様な接続を確立している広域の入力なら、destinationとは異ったoutInputフィールドを設定することができます。BBufferConsumerにはすでに指定されたformatを拒絶する機会が与えられているため、この関数でエラーを返すのは貧弱なやり方です。エラーを返すのは、接続を確立するのに必要なリソースがConnected()の呼び出しより前に使用できなくなった場合だけにして下さい。fieldには、producerによって接続に与えられた名前が収められています(もしproducerが名前を割り当てていなければ、空の文字列となります)。名付けられていない接続があることは悪いことであり、またproducerがこれに書込むという保証がないため、consumerは常に正しい名前があることを確認しなければなりません。3」といった)接続の名前をユニークにするnodeの名前と番号を含むべきです。buffers);もし接続が安全に開始されたならB_OKを返し、そうでなければ適切なエラーコードを返して下さい。0このフック関数は、接続が終了する時に呼び出されます。将来whichInputによって示されるmedia_inputに接続されたmedia_sourceの問い合わせがmedia_source::nullを参照すると保証するために必要なことを全て実装して下さい(または、もし後に他の接続がその入力に確立されたら、そのproducerを)。nodeがproducerに対してBBufferGroupを生成して設定するならば、ここでそれを削除または改善しないで下さい。producerは、同じバッファを参照するBBufferGroupの複製を持っているからです。BBufferGroupを削除すると、これらのバッファが自由になり、producerがデッドロックの状態に置かれます。する代りに、デストラクタ中でConnected()が再度呼び出されたときにそれを削除し、かならず残りのBBufferGroupを削除して下さい。0もしGetNextInput()で返されるcookieの値が、反復処理が完了する際に削除を必要とするオブジェクトのポインタであれば、かならずそれを行うためにDisposeInputCookie()を実装して下さい。0forWhomで指定されるmedia_destinationのlatency(遅延時間)の合計を計算し、その結果をoutLatencyに入れるには、このフック関数を実装して下さい。sourceを返して下さい。sourceに従属し、下流に存在する指定された任意の接続の遅延時間を含めて下さい。latencyの計算がうまくいけばB_OKを返し、そうでなければ適切なエラーを返して下さい。0最初にクライアントがこの関数を呼び出すとき、cookieによって示される値は0です。outInputによってポインタの示されるバッファに最初の入力に関する情報を格納し、cookieの値を、次回GetNextInput()が呼び出された時に何が返されるか追跡できる(ゼロ以外の)なんらかの値を設定して下さい。GetNextInput()を連続して呼び出すと、cookieに、最後にそのクライアントによって関数が呼び出された際にcookieに返した値が返されます。outInputに次の入力に関する情報を収め、入力を通して進行の追跡を継続するためにcookieに新しい値を入れて下さい。この関数がcookieがゼロの値で呼び出されたときはいつでも、最初の入力から開始しなければなりません。最後の入力に辿り着いた時、もう入力がないことを示すためにB_BAD_INDEXを返して下さい。size)BBufferConsumerから派生しているnodeが制御ポートにメッセージを受け取ったら、BBufferConsumer::HandleMessage()を呼び出してディスパッチを試みて下さい。BBufferConsumerがそのメッセージを理解できなければB_ERRORを返すか、nodeが派生している他のクラスのためにディスパッチを試みるか、あるいはそれを自分自身で扱うことができます。この関数がB_OKを返したら、メッセージは取り扱われたことになります。performanceTime)howLateマイクロ秒遅れて動作し、sourceによって指定されるBBufferProducerを通知します。通知は指定されたperformanceTimeの調子を整えます。mode)がB_DECREASE_PRECISION、B_INCREASE_LATENCYまたはB_DROP_DATA(いずれも適切な時間を維持するためにメディアの再生を調節することが許されている)の時、この関数を呼び出して下さい。producerは、この通知を直ちに処理し、適切な動作を取るべきです。0このフック関数は、入力であるdestinationに接続されたproducerからのバッファの能力の変化をconsumerに報告するために呼び出されます。引数statusはどんな変更が生じたかを指定し、atPerformanceTimeはいつ変化が起こったか(あるいはいつ起こるか)を示します。これによって、データを待っている入力がバッファの追跡を維持できるようにします。consumerが4つのproducerから到着したデータを処理しており、そのうちの一つがconsumerに対してバッファの送信を停止したとすると、停止したproducerはもはやバッファを待つ必要がないということをconsumerに知らせるためにProducerDataStatus()を呼び出します。この方法により、consumerは他の3つの入力からバッファがいつ到着するかを知り、バッファの処理を開始することができます。producerが使用可能なデータを全く持っていない。producerが使用可能なデータを持っている。producerは停止した。Kitで内部的に使用されるクリッピングフォーマットに変換します。RegionToClipData()を呼ぶより前に、dataポインタによって指定されるバッファのサイズにioSizeが設定されます。戻る際には、formatがクリップされているデータのフォーマットになり、ioSizeが返されたデータの実際のバイト長に変更され、そしてdataには実際のクリッピングデータが格納されます。Clipping"の85ページに記載されています。クリップされたデータがエラーなしに返された。dataバッファが十分に大きくなかった。NULL)sourceによって指定される上流のproducerに対して、適切な時間まで待つかわりに、直ちに次のバッファを送るよう要請します。この関数が最も明確に使用されるのは、出力のフレームをデコードするために、codecが複数のバッファを要求する場合です(MPEGがよい例です)。要求されたバッファは、バッファが要求された時間を示すstartTimeパラメータでも、要求されているバッファより以前のバッファを指定するpreviousBufferでも識別することができます。この関数は、producerのAdditionalBufferRequested()関数が呼ばれる原因となります。変更の要求はうまくいった。sourceが不正である。previousBufferポインタがNULLであった。Serverへの要求が時間切れになった。Serverとの交信中にエラーが生じた。sourceに対して、それが提供するフォーマットをtoFormatで指定されるフォーマットに変更するよう要求します。Kitは、変更が有効になる際にRequestCompleted()が受け取るタグの値をchangeTagに返します。変更タグはこの要求によって、RequestCompleted()呼び出しをうまく調和させます。この関数は、userData及びchangeTagによって示されるmedia_request_infoを受け取ります。FormatChanged()は、nodeが変更を受け取っているメディアフォーマットに変化が生じた際、上流のproducerによって呼び出されます。newFormatに新しいフォーマットを、changeTagに新しいフォーマットが有効になる変更タグの値を示します。FormatChanged()がproducerによって呼び出されるため、新しいフォーマットが受け入れられるかどうかを尋ねる必要はありません。フォーマットの変化が不可能であれば、FormatChanged()から適切なエラーが返されます。このエラーは、新しいフォーマットの交渉を最初に行ったproducerに返されます。指定されたsourceが不正であった。指定されたdestinationが不正であった。*outFlags)この関数は、タイミング情報を供給しない外部のカプセル化されたレイヤーのメディアフォーマットのサポートを援助するために提供されます。producerはseekタグによって生成されるバッファにタグをつけます。これらのタグは、メディアデータのキーフレームを見つけだすために使用できます。timeでseekタグを協調させることはconsumerの仕事です。timeをキャッシュします。timeに最も近い時間を知る必要がある時、この関数はその情報を返すことで反応します。