ds_akahane
2015年6月1日 16時39分
いつもお世話になります。
Armadillo-810 での H.264エンコードでの遅延に関してお伺いさせて下さい。
以前フォーラムにてお教えいただき、
GStreamer - acmh264enc - RTP のパイプラインにて
遅延時間（ラグ）が 0.5秒程度となることが確認できましたが、
この0.5秒程度の遅延は、acmh264encプラグイン又はH.264エンコードでの
仕様となっているのでしょうか？
確認しているなかで、これは感覚的なものなのですが、
H.264 エンコードでは最初に数フレーム（又はある時間）をバッファリング
してからエンコードが開始されているように思われるのですが
実際にこのような仕様になっていますでしょうか？
以上、よろしくお願いします。
コメント
ds_akahane
田村様
有難うございます。
確認させて下さい。
> 確認した 約70ms というのは「上流のプラグインが、acmh264enc プラグインに "エンコードするバッファ" を渡してから
> acmh264enc プラグインが、下流のプラグインに "エンコード結果のバッファ" を渡すまで」の時間です。
計測頂いた、約70ms とは、最初のフレームエンコードにかかる時間と考えてよろしいでしょうか？
それとも、その後の毎回のフレームエンコードにかかる処理時間でしょうか？
> パイプラインが以前フォーラムでお問い合わせ頂いたもの [1] と同じであれば、
> 0.5秒という遅延は H.264エンコーダ、ネットワーク、H.264デコーダ、それぞれの累計となります。
>
> つまり、0.5秒の遅延が acmh264enc プラグインのみで発生しているわけではありません。
>
> 弊社で以下に相当する GStreamer アプリケーションを作成し、
> acmh264enc プラグインの遅延時間を計測したところ、約 70ms の遅延を確認しました。
acmh264enc プラグインのみで約70ms の遅延だとのことですので
残りの約0.4秒は、Windows側でのH264デコード(avdec_h264)だと考えられるのですが
この受け側のH264デコードをArmadillo-840を使用してH/W デコードを使用した場合には
0.2秒未満位となると考えてよろしいでしょうか？
以上、よろしくお願い致します。
> 田村です。
>
> > この0.5秒程度の遅延は、acmh264enc プラグイン又はH.264エンコードでの
> > 仕様となっているのでしょうか？
>
> パイプラインが以前フォーラムでお問い合わせ頂いたもの [1] と同じであれば、
> 0.5秒という遅延は H.264エンコーダ、ネットワーク、H.264デコーダ、それぞれの累計となります。
>
> つまり、0.5秒の遅延が acmh264enc プラグインのみで発生しているわけではありません。
>
> 弊社で以下に相当する GStreamer アプリケーションを作成し、
> acmh264enc プラグインの遅延時間を計測したところ、約 70ms の遅延を確認しました。
>
>
> gst-launch-1.0 -v \ > v4l2src device=/dev/video1 \ > ! video/x-raw,width=640,height=480,framerate=30/1 \ > ! acmh264enc max-gop-length=1 b-pic-mode=0 bitrate=2000000 \ > ! video/x-h264, stream-format=avc \ > ! rtph264pay config-interval=3 \ > ! udpsink force-ipv4=true port=5555 host=127.0.0.1 >
>
> 確認した 約70ms というのは「上流のプラグインが、acmh264enc プラグインに "エンコードするバッファ" を渡してから
> acmh264enc プラグインが、下流のプラグインに "エンコード結果のバッファ" を渡すまで」の時間です。
>
> また、計測に使用した Gstreamer アプリケーションのソースコード (enctime.c) を添付しました。
> 参考にして頂ければ幸いです。
>
>
> > H.264エンコードでは最初に数フレーム（又はある時間）をバッファリング
> > してからエンコードが開始されているように思われるのですが
> > 実際にこのような仕様になっていますでしょうか？
>
> はい、バッファリングを行っています。
>
> H.264エンコードのバッファリング数は acmh264enc の b-pic-mode プロパティに依存します。
> b-pic-mode とバッファリング数の対応は以下の通りです。
>
> b-pic-mode=0: 1フレーム分バッファリング
> b-pic-mode=1: 1フレーム分バッファリング
> b-pic-mode=2: 2フレーム分バッファリング
> b-pic-mode=3: 3フレーム分バッファリング
>
> 参考情報
> [1]: https://users.atmark-techno.com/comment/1718#comment-1718
at_shota.tamura
> 計測頂いた、約70ms とは、最初のフレームエンコードにかかる時間と考えてよろしいでしょうか？
> それとも、その後の毎回のフレームエンコードにかかる処理時間でしょうか？
どちらでもなく、あるストリームを再生したときに計測した値の平均値です。
パイプライン化されているエンコード処理で、あるフレームがエンコーダーエレメントに
入ってから出てくるまでの値の平均です。
10フレームエンコードした時に 70ms * 10 かかるわけではありません。
> acmh264enc プラグインのみで約70ms の遅延だとのことですので
> 残りの約0.4秒は、Windows側でのH264デコード(avdec_h264)だと考えられるのですが
> この受け側のH264デコードをArmadillo-840を使用してH/W デコードを使用した場合には
> 0.2秒未満位となると考えてよろしいでしょうか？
どうでしょう？ Linux カーネルや Windows もネットワークパケットをバッファリングしますし、
ネットワークパケットから画像を取り出す、またはパケット化するにも時間はかかると思います。
なので、デコードだけではないように思います。
PC上で avdec_h264 を使って調べてみたところ、デコード自体には0.1秒しか
かかっていないにもかかわらず、全体ではそれ以上かかっているよう見えました。
Armadillo-840 で H/W デコードした時の遅延時間は調べてみます。
ただこの論理で行くと、仮にデコードが0秒になっても、全体的な遅延は何秒かありそうです。
H.264 のようにフレーム間圧縮する方式は、遅延時間を短くするのは難しく、それだけで特徴となるようです。[1][2]
なので、もし、リアルタイム性が強く要求される用途であれば、非圧縮で画質を落とした絵を
転送するなど、H.264 エンコード/デコード 以外を検討する必要がありそうです。
可能な範囲で用途を教えて頂ければ、別の方法を提案できるかもしれません。
参考情報
[1]: https://www.youtube.com/watch?v=X2H6ig3crgk
[2]: https://www.youtube.com/watch?v=dUXfgUk45ds
ds_akahane
詳しく確認して頂き、本当にありがとうございます。
> どうでしょう？ Linux カーネルや Windows もネットワークパケットをバッファリングしますし、
> ネットワークパケットから画像を取り出す、またはパケット化するにも時間はかかると思います。
> なので、デコードだけではないように思います。
>
> PC上で avdec_h264 を使って調べてみたところ、デコード自体には0.1秒しか
> かかっていないにもかかわらず、全体ではそれ以上かかっているよう見えました。
>
> Armadillo-840 で H/W デコードした時の遅延時間は調べてみます。
> ただこの論理で行くと、仮にデコードが0秒になっても、全体的な遅延は何秒かありそうです。
調査して頂き、感謝いたします。
> H.264 のようにフレーム間圧縮する方式は、遅延時間を短くするのは難しく、それだけで特徴となるようです。[1][2]
> なので、もし、リアルタイム性が強く要求される用途であれば、非圧縮で画質を落とした絵を
> 転送するなど、H.264 エンコード/デコード 以外を検討する必要がありそうです。
やはり、H.264の特徴になりますよね。
こちらにて、JPEGでの転送を行った場合では遅延時間は要求に入ることは確認できているのですが
その場合に通信帯域が要求に入らず、H.264での遅延時間短縮が可能か模索していました。
用途としては、カメラ映像を無線通信にてPCに転送するものなのですが
非常に小さい帯域（約300Kbps）の無線通信の使用になっています。
また、リアルタイム性も要求されています。
※現状の動作確認は有線通信で行っていますので無線通信機を使用する場合には中継されるため更に遅延が生じる可能性があります。
以上、よろしくお願い致します。
> > 計測頂いた、約70ms とは、最初のフレームエンコードにかかる時間と考えてよろしいでしょうか？
> > それとも、その後の毎回のフレームエンコードにかかる処理時間でしょうか？
>
> どちらでもなく、あるストリームを再生したときに計測した値の平均値です。
> パイプライン化されているエンコード処理で、あるフレームがエンコーダーエレメントに
> 入ってから出てくるまでの値の平均です。
> 10フレームエンコードした時に 70ms * 10 かかるわけではありません。
>
> > acmh264enc プラグインのみで約70ms の遅延だとのことですので
> > 残りの約0.4秒は、Windows側でのH264デコード(avdec_h264)だと考えられるのですが
> > この受け側のH264デコードをArmadillo-840を使用してH/W デコードを使用した場合には
> > 0.2秒未満位となると考えてよろしいでしょうか？
>
> どうでしょう？ Linux カーネルや Windows もネットワークパケットをバッファリングしますし、
> ネットワークパケットから画像を取り出す、またはパケット化するにも時間はかかると思います。
> なので、デコードだけではないように思います。
>
> PC上で avdec_h264 を使って調べてみたところ、デコード自体には0.1秒しか
> かかっていないにもかかわらず、全体ではそれ以上かかっているよう見えました。
>
> Armadillo-840 で H/W デコードした時の遅延時間は調べてみます。
> ただこの論理で行くと、仮にデコードが0秒になっても、全体的な遅延は何秒かありそうです。
>
> H.264 のようにフレーム間圧縮する方式は、遅延時間を短くするのは難しく、それだけで特徴となるようです。[1][2]
> なので、もし、リアルタイム性が強く要求される用途であれば、非圧縮で画質を落とした絵を
> 転送するなど、H.264 エンコード/デコード 以外を検討する必要がありそうです。
>
> 可能な範囲で用途を教えて頂ければ、別の方法を提案できるかもしれません。
>
> 参考情報
> [1]: https://www.youtube.com/watch?v=X2H6ig3crgk
> [2]: https://www.youtube.com/watch?v=dUXfgUk45ds
>
at_shota.tamura
先ほどの avdec_h264 を使用した場合のデコード時間について訂正です。
デコード自体に 0.1 秒かかると書きましたが、この値は FullHD の動画をデコードした場合でした。
640x480の動画をデコードした場合は、1ms 程度です。失礼いたしました。
また、acmh264dec で H/W デコードした場合の遅延時間は約 100ms でした。
> こちらにて、JPEGでの転送を行った場合では遅延時間は要求に入ることは確認できているのですが
> その場合に通信帯域が要求に入らず、H.264での遅延時間短縮が可能か模索していました。
なるほど、そういうことでしたか。
H.264 での遅延時間短縮の方法として、
カメラからのフレームを複製し、フレームレートを上げることを試してみました。
結果、全体の遅延時間をほんの少し (50msほど) 減らすことができましたが、
30fps の動画を 60fps にしているで、2倍近く帯域を使います。
ds_akahane 様の用途だと現実的ではありませんね...
試したパイプラインはこちらです。
gst-launch-1.0 v4l2src device=/dev/video1 ! videorate ! video/x-raw,width=640,height=480,framerate=60/1 \ ! acmh264enc ! video/x-h264,stream-format=avc \ ! rtph264pay config-interval=3 ! udpsink force-ipv4=true port=5555 host=192.168.0.2
H.264 エンコード/デコードでは、リアルタイム性を確保するのが難しいことから
JPEG を使った上で "帯域を節約する" アプローチはどうでしょうか?
すでに検討済みでしたらすいません。
videorate [1]というプラグインを使えば意図的にフレームレートを落とすことが出来ます。
なめらかな絵の動きは少々損なわれますが、帯域を節約しつつリアルタイム性も確保できるかと思います。
これに加え、acmjpegenc の quality プロパティにより、圧縮率を上げることでさらなる帯域の節約が可能です。
フレームレートを15fpsまで落とし、圧縮率を上げたパイプライン例
gst-launch-1.0 v4l2src device=/dev/video1 ! videorate ! video/x-raw,width=640,height=480,framerate=15/1 \ ! acmjpegenc quality=50 ! rtpjpegpay ! udpsink force-ipv4=true port=5555 host=192.168.0.2
参考情報
[1]: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-ba…
ds_akahane
毎回、詳しく調査して頂き、有難うございます。
> 先ほどの avdec_h264 を使用した場合のデコード時間について訂正です。
> デコード自体に 0.1 秒かかると書きましたが、この値は FullHD の動画をデコードした場合でした。
> 640x480の動画をデコードした場合は、1ms 程度です。失礼いたしました。
>
> また、acmh264dec で H/W デコードした場合の遅延時間は約 100ms でした。
調査して頂き、有難うございます。
H.264での遅延時間短縮は難しそうですね。
こちらでも、enctime を若干改造して確認してみましたが、
rtph264pay でも 約20ms の遅延が追加されていることが解りました。
> H.264 エンコード/デコードでは、リアルタイム性を確保するのが難しいことから
> JPEG を使った上で "帯域を節約する" アプローチはどうでしょうか?
>
> すでに検討済みでしたらすいません。
>
> videorate [1]というプラグインを使えば意図的にフレームレートを落とすことが出来ます。
> なめらかな絵の動きは少々損なわれますが、帯域を節約しつつリアルタイム性も確保できるかと思います。
>
> これに加え、acmjpegenc の quality プロパティにより、圧縮率を上げることでさらなる帯域の節約が可能です。
こちらでも、quality=0, FPS=10 にてJPEGエンコードで確認したのですが、
1フレーム分が約6.4KByte で要求帯域に入らないことが確認されました。
色々と調査して頂き、大変助かりました。
また、ご教授頂くこともあるかと思いますが、よろしくお願いします。
以上、よろしくお願いします。
ds_akahane
田村様
お世話になります。ds_akahane です。
こちらでも、enctime ツールを使用して確認を行いそのデータをまとめてみたのですが、
当初にお教えいただいた通り、acmh264enc にて発生する遅延は平均約70ms弱で
60ms強から80ms弱の遅延が繰り返されていることは分かりました。
ここで、1点気になる点があります。
上記の確認を3回行ってみてすべてにおいて同じ傾向なのですが、
先頭フレームのエンコードに約130msかかっています。
全体としては約0.5秒の遅延ですので、その他の要因（rtph246pay/udpなど）も
あるかと思いますが、
この先頭フレームでの約130msの遅延がその後も乗っているようみ思われます。
最初のこの遅延に関してなにか要因や回避方法などありましたお教えくださいませ。
※1計測の先頭部分の抜粋を添付させて頂きます。
また、enctime ツールですが、出力されるpts値（カメラからの入力時に付加されるタイムスタンプで
フレームの識別に利用）と
mono値（各ポイントの現在タイムスタンプ）とでタイムスタンプ形式（基準時刻）が異なるため
実際にカメラ入力されてから各処理後の出力までの時間差（遅延）が計測できないのですが
mono値に使用しているタイムスタンプを ptsと同じ形式のタイムスタンプにすることは可能なのでしょうか？
以上、よろしくお願いします。
| ファイル | ファイルの説明 |
|---|---|
| enctime_result_640x480_fps30_gop1_bit30000_after_6line.txt |
at_shota.tamura
田村です。
計測結果の添付ありがとうございます。
> 先頭フレームのエンコードに約130msかかっています。
こちらでも約130msのかかっていることは確認済みです。
> 最初のこの遅延に関してなにか要因や回避方法などありましたお教えくださいませ。
すいません。すぐにお答え出来るものを持っていません。
ですが、Element の STATE_CHANGE が関係するのでは? と考えているので調べてみます。
> また、enctime ツールですが、出力されるpts値（カメラからの入力時に付加されるタイムスタンプで
> フレームの識別に利用）と
> mono値（各ポイントの現在タイムスタンプ）とでタイムスタンプ形式（基準時刻）が異なるため
> 実際にカメラ入力されてから各処理後の出力までの時間差（遅延）が計測できないのですが
> mono値に使用しているタイムスタンプを ptsと同じ形式のタイムスタンプにすることは可能なのでしょうか？
mono値をptsと同じ形式に変換する方法ではありませんが、
Gstreamer アプリケーション上の時間 (absolute-time) を取得することで同様のことが可能です。
absolute-time は Gstreamer アプリケーション内の "Pipeline" というものが持っています。
enctime.c では、以下の変数です。
int main(int argc, char *argv[])
{
[..]
GstElement *pipeline;
[..]
}この変数を point1_handoff_handler() などに gpointer *data 経由で渡した後、
Pipeline から clock を取り出し[1]、time を表示してみてはいかかでしょうか[2]
# 場合によっては、base_time を引く必要があるかもしれません。
absolute-time など、Gstreamer の時間管理については、
Gstreamer Application Development Manual[3] に載っていますので、
そちらを参照してください。
今回質問いただいた内容とは異なりますが、
先日の調査結果から rtppay, rtpdepay が遅いのでは? という考えの元、
これらを使用しないストリーミングを試してみました。
結果、遅延を0.2秒程度抑えることが出来ました。
以下のパイプラインをお試しください。
A. Armadillo-810 (映像送信側) のパイプライン
gst-launch-1.0 -v \ v4l2src device=/dev/video1 \ ! queue \ ! video/x-raw,width=640,height=480,framerate=30/1 \ ! acmh264enc max-gop-length=1 b-pic-mode=0 \ ! udpsink force-ipv4=true port=5555 host=192.168.0.2
B. PC (映像受信側) のパイプライン
gst-launch-1.0 \
udpsrc \
caps="video/x-h264, \
codec_data=(buffer)0142e01effe100146742e01edc0a03da10000003001000000303c84001000568ce025880, \
stream-format=(string)avc, \
alignment=(string)au, \
framerate=(fraction)30/1, width=(int)640, height=(int)480" \
port=5555 \
! avdec_h264 \
! xvimagesinkudpsrc の caps に設定する codec_data の値は、
A のパイプラインを実行した時に表示される値を使用します。
※ codec_data の値を表示するには gst-launch の -v オプションを付ける必要があります。
codec_data の値は acmh264enc のプロパティ設定により変化するため、
max-gop-length や b-pic-mode 、bitrate などを変更した際には必ず変更してください。
ちなみに、A のパイプラインでは、acmh264enc のプロパティに
エンコード結果をすべてIフレームにする設定を付けているため、
要求帯域に収まらないかもしれません。
これらの設定を外した場合は、Bフレーム、Pフレームが
含まれるため、帯域は節約出来ますが、遅延が0.3秒ほどになりました。
参考情報
[1]: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html…
[2]: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html…
[3]: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/ch…
ds_akahane
田村様
お世話になります。ds_akahane です。
毎回、詳しく調査して頂き、有難うございます。
> > 先頭フレームのエンコードに約130msかかっています。
> こちらでも約130msのかかっていることは確認済みです。
>
> > 最初のこの遅延に関してなにか要因や回避方法などありましたお教えくださいませ。
> すいません。すぐにお答え出来るものを持っていません。
> ですが、Element の STATE_CHANGE が関係するのでは? と考えているので調べてみます。
宜しくお願いします。
> > また、enctime ツールですが、出力されるpts値（カメラからの入力時に付加されるタイムスタンプで
> > フレームの識別に利用）と
> > mono値（各ポイントの現在タイムスタンプ）とでタイムスタンプ形式（基準時刻）が異なるため
> > 実際にカメラ入力されてから各処理後の出力までの時間差（遅延）が計測できないのですが
> > mono値に使用しているタイムスタンプを ptsと同じ形式のタイムスタンプにすることは可能なのでしょうか？
> mono値をptsと同じ形式に変換する方法ではありませんが、
> Gstreamer アプリケーション上の時間 (absolute-time) を取得することで同様のことが可能です。
>
> absolute-time は Gstreamer アプリケーション内の "Pipeline" というものが持っています。
>
> enctime.c では、以下の変数です。
>
> int main(int argc, char *argv[])
> {
> [..]
>
> GstElement *pipeline;
>
> [..]
> }
> > この変数を point1_handoff_handler() などに gpointer *data 経由で渡した後、
> Pipeline から clock を取り出し[1]、time を表示してみてはいかかでしょうか[2]
> # 場合によっては、base_time を引く必要があるかもしれません。
>
> absolute-time など、Gstreamer の時間管理については、
> Gstreamer Application Development Manual[3] に載っていますので、
> そちらを参照してください。
お教えいただき有難うございます。
時間を見つけて試してみたいと思います。
> 今回質問いただいた内容とは異なりますが、
> 先日の調査結果から rtppay, rtpdepay が遅いのでは? という考えの元、
> これらを使用しないストリーミングを試してみました。
>
> 結果、遅延を0.2秒程度抑えることが出来ました。
有難うございます。
0.2秒は大きいですね。
こちらでも確認したいと思います。
以上、よろしくお願いします。
at_shota.tamura
ds_akahane 様
田村です。
先頭フレームのエンコードに約 130ms かかる要因がわかりました。
※ Element の STATE_CHANGE は関係ありませんでした
結論として「この時間を短縮するのは厳しい」です。
---
約 130ms の 90~100ms は acmh264enc の初期化処理、
残りの 30ms は下流のプラグインとのネゴシエーションなど、
さまざまな処理が積み重なったもの。という内訳です。
初期化処理の中でも、特に以下の2箇所で時間がかかっているようです。
A. acmh264enc プラグインが SH-4A とデータをやり取りするためのメモリ領域を確保する
B. acmh264enc プラグインが SH-4A から SPS/PPS を取得する
※ どちらも 50ms 前後かかっています
A、B どちらも acmh264enc プラグインを改造し、
この処理のタイミングをずらせば短縮できるかもしれません。
しかし、A がこのタイミングでメモリ領域の確保を行っている理由は、
入力された映像サイズに合ったメモリ領域を確保するためです。
したがって、タイミングをずらと、動的な確保ができなくなる。
または、別の方法を用いた実装が必要になる。などが考えられます。
以上のことから、先頭フレームのエンコード時間短縮は厳しいと考えます。
---
これらは GST_DEBUG=acmh264enc:5 を付け enctime を実行し、
その後、acmh264enc プラグインのコード追って確認したものです。
[root@armadillo810-0 (ttySC2) ~]# GST_DEBUG=acmh264enc:5 ./enctime
GST_DEBUG を使いデバッグレベルを上げると、
プラグイン内の様々な情報を得ることが出来ます。お試しください。
ds_akahane
田村様
お世話になります。ds_akahane です。
> 先頭フレームのエンコードに約 130ms かかる要因がわかりました。
> ※ Element の STATE_CHANGE は関係ありませんでした
>
> 結論として「この時間を短縮するのは厳しい」です。
詳しく調査して頂き、有難うございます。
初期の遅延に関する状況が判明し助かります。
> これらは GST_DEBUG=acmh264enc:5 を付け enctime を実行し、
> その後、acmh264enc プラグインのコード追って確認したものです。
>
> [root@armadillo810-0 (ttySC2) ~]# GST_DEBUG=acmh264enc:5 ./enctime >
> GST_DEBUG を使いデバッグレベルを上げると、
> プラグイン内の様々な情報を得ることが出来ます。お試しください。
貴重な情報を頂き有難うございます。
以上、よろしくお願いします。
> ds_akahane 様
>
> 田村です。
>
> 先頭フレームのエンコードに約 130ms かかる要因がわかりました。
> ※ Element の STATE_CHANGE は関係ありませんでした
>
> 結論として「この時間を短縮するのは厳しい」です。
>
> ---
> 約 130ms の 90~100ms は acmh264enc の初期化処理、
> 残りの 30ms は下流のプラグインとのネゴシエーションなど、
> さまざまな処理が積み重なったもの。という内訳です。
>
> 初期化処理の中でも、特に以下の2箇所で時間がかかっているようです。
>
> A. acmh264enc プラグインが SH-4A とデータをやり取りするためのメモリ領域を確保する
> B. acmh264enc プラグインが SH-4A から SPS/PPS を取得する
> ※ どちらも 50ms 前後かかっています
>
> A、B どちらも acmh264enc プラグインを改造し、
> この処理のタイミングをずらせば短縮できるかもしれません。
>
> しかし、A がこのタイミングでメモリ領域の確保を行っている理由は、
> 入力された映像サイズに合ったメモリ領域を確保するためです。
>
> したがって、タイミングをずらと、動的な確保ができなくなる。
> または、別の方法を用いた実装が必要になる。などが考えられます。
>
> 以上のことから、先頭フレームのエンコード時間短縮は厳しいと考えます。
> ---
>
> これらは GST_DEBUG=acmh264enc:5 を付け enctime を実行し、
> その後、acmh264enc プラグインのコード追って確認したものです。
>
> [root@armadillo810-0 (ttySC2) ~]# GST_DEBUG=acmh264enc:5 ./enctime >
> GST_DEBUG を使いデバッグレベルを上げると、
> プラグイン内の様々な情報を得ることが出来ます。お試しください。
>
>
at_shota.tamura
2015年6月2日 14時59分
田村です。
> この0.5秒程度の遅延は、acmh264enc プラグイン又はH.264エンコードでの
> 仕様となっているのでしょうか？
パイプラインが以前フォーラムでお問い合わせ頂いたもの [1] と同じであれば、
0.5秒という遅延は H.264エンコーダ、ネットワーク、H.264デコーダ、それぞれの累計となります。
つまり、0.5秒の遅延が acmh264enc プラグインのみで発生しているわけではありません。
弊社で以下に相当する GStreamer アプリケーションを作成し、
acmh264enc プラグインの遅延時間を計測したところ、約 70ms の遅延を確認しました。
gst-launch-1.0 -v \ v4l2src device=/dev/video1 \ ! video/x-raw,width=640,height=480,framerate=30/1 \ ! acmh264enc max-gop-length=1 b-pic-mode=0 bitrate=2000000 \ ! video/x-h264, stream-format=avc \ ! rtph264pay config-interval=3 \ ! udpsink force-ipv4=true port=5555 host=127.0.0.1確認した 約70ms というのは「上流のプラグインが、acmh264enc プラグインに "エンコードするバッファ" を渡してから
acmh264enc プラグインが、下流のプラグインに "エンコード結果のバッファ" を渡すまで」の時間です。
また、計測に使用した Gstreamer アプリケーションのソースコード (enctime.c) を添付しました。
参考にして頂ければ幸いです。
> H.264エンコードでは最初に数フレーム（又はある時間）をバッファリング
> してからエンコードが開始されているように思われるのですが
> 実際にこのような仕様になっていますでしょうか？
はい、バッファリングを行っています。
H.264エンコードのバッファリング数は acmh264enc の b-pic-mode プロパティに依存します。
b-pic-mode とバッファリング数の対応は以下の通りです。
b-pic-mode=0: 1フレーム分バッファリング
b-pic-mode=1: 1フレーム分バッファリング
b-pic-mode=2: 2フレーム分バッファリング
b-pic-mode=3: 3フレーム分バッファリング
参考情報
[1]: https://users.atmark-techno.com/comment/1718#comment-1718