こんにちは。Ianです。
今、C++を使用してH3上でGSTREAMERのPLAYBACK機能を開発していますが、以下の問題に遭遇しています:
1. filesrc location=%s ! queue ! decodebin use-dmabuf=true ! appsink name=VideoOutputを再生パイプラインとして使用していますが、appsink側で受信されるデータが予想されていたDMAバッファではなく、CPUデータであることがわかりました。2. 再生中に、g_main_loopと異なるスレッドで以下の指令gst_element_seek_simple(instance_->pipeline, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_ACCURATE | GST_SEEK_FLAG_FLUSH), time * GST_SECOND);実行すると、必ずデッドロックが発生しています。
関連する情報または解決策をご存知の方はいますでしょうか?お願いします。
こんにちは、Ianです。
状況を更新します
https://github.com/renesas-rcar/gst-omx(TAG:1.16.3)をコンパイルして、正常にGStreamerに読み込まれていることを確認しでいました。
以下はサンプルコード:
1.の状況の説明:
実行時に、omx/gstomxvideodec.cのuse_dmabufがtrueであることを確認しました。
gst_is_dmabuf_memoryがtrueであることを確認しました
テスト時にはGstVideoMetaのデータが出力され、その解像度とストライドはビデオデータに一致しており、gst_dmabuf_memory_get_fdはそれぞれ97および100を取得しており、正常に見える。
main.cppでテクスチャを描画する際、"got black"の部分が異常な部分であり、描画されるのは完全に黒い画像です。
同じパイプラインが他のプラットフォームで正常に動作することを確認しているため、EGLイメージをGLテクスチャに変換する部分は正常だと思います。
上記の状況に基づいて、appsinkが受信したdmabufがこの方法をサポートしていないか、または取得したdmabufのIDが実際にはデコーダーの出力するdmabufではないかを確認したいと思います。
2.の状況の説明:
avdec_h264を使用してソフトデコードする場合、seekはデッドロックを引き起こしません。
omxh264decスレッドのデッドロックが以下のスタックで発生していることを確認しました: gst_omx_port_acquire_buffer:2219 → gstomx.c:487
この状況は、未処理のメッセージがあるかどうかを確認する必要がありそうです。確認していただけると助かります。
よろしくおねがいします。