QtGstreamer: AppSink & tee

Question

Я написал специальную QtGStreamer appsink, которая отлично работает. У меня проблемы с попыткой разделить с тройником конвейер для обработки записи потока, потому что трубопровод начинает прервать, но никогда не переходит в состояние воспроизведения.

Мой трубопровод:

souphttpsrc location="%1" ! queue ! tee name=tp tp.! queue ! tsdemux ! h264parse ! splitmuxsink muxer=mpegtsmux location=/tmp/rec/video%02d.mov max-size-time=60000000000 max-size-bytes=100000000 tp.! queue ! appsink name="mysink" 

Если я прокомментировать любой из двух ветвей тройника ничего работает, как ожидалось.

Это также работает:

souphttpsrc location="%1" ! queue ! tee name=tp tp.! queue ! tsdemux ! h264parse ! splitmuxsink muxer=mpegtsmux location=/tmp/rec/video%02d.mov max-size-time=60000000000 max-size-bytes=100000000 tp.! queue ! decodebin ! autovideosink 

Почему мой AppSink работает только один?

Answer 1

Слишком большой для комментариев ..

Как вы обрабатывать appsink буферы? Его в основном потоке, и вы получаете буферы, блокируя вызовы или ожидаете сигналы нового образца/нового прералла (которые не блокируют - тип стиля push)?

Проверьте это за то, что я имею в виду (в appsink главу):

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-data-spoof.html

заблокирован ли ваше приложение?

Я подозреваю (возможно, ошибаюсь), что appsink заблокирован, потому что он затоплен множеством буферов .. тройник - очень сложный элемент. Если одна ветка после того, как tee хочет прервать, например, 100 буферов, то это вызывает 100 буферов также отправляются в другую ветку, которая может блокировать, например, appsink, которая блокирует весь конвейер, поскольку вы ожидаете воспроизведения состояния (или я не знаю, что вы делаете в своей логике приложения).

Вы можете попробовать несколько вещи, чтобы получить это выяснял:

1. добавить drop=true к appsink
2. попробуйте добавить параметр очереди leaky=2, чтобы проверить, помогает ли это (очень похоже на 1, только другая техника)
3. Анализ журналов отладки, с которых первая блокировка очереди. Используйте эту переменную env при запуске своего материала GST_DEBUG=3,queue_dataflow:5 (я думаю, что это было 5, и я надеюсь, что я правильно помню категорию отладки)
4. Попробуйте изменить splitmuxsink для фейклинка, который никогда не должен блокировать - просто чтобы проверить, кто является виновником. If это помогает это также может означать, что splitmuxsink - это тот, который запрашивает столько буферов.
5. В любом случае, если я все неправильно, то вы можете отлаживать с GST_DEBUG и настройки уровней 3,4,5 пока вы не найдете что-то интересное ..