07-02-04 Bus, сообщения и состояния пайплайна

В этом разделе мы познакомимся с двумя ключевыми концепциями, необходимыми для программного управления пайплайнами GStreamer: состояниями пайплайна и системой сообщений через bus («бус»). Эти механизмы позволяют приложению не просто запустить поток, но и реагировать на события — например, узнать, когда видео закончилось, произошла ошибка или изменилось состояние воспроизведения.

Это особенно важно, когда вы будете использовать GStreamer в Python или другом языке программирования, а не только через командную строку. Без понимания bus и состояний вы не сможете построить надёжное приложение.

---

Состояния пайплайна: от выключения до воспроизведения

Каждый пайплайн в GStreamer проходит через строго определённые состояния. Эти состояния управляют тем, как элементы взаимодействуют с данными и ресурсами системы.

Представьте пайплайн как сложный механизм — например, видеоплеер. Вы не можете сразу начать воспроизведение: сначала нужно включить устройство, загрузить диск, проверить готовность. То же самое делает GStreamer — он последовательно переводит пайплайн из одного состояния в другое.

Основные состояния

Существует четыре основных состояния, через которые проходит пайплайн:

1. NULL — начальное состояние.
   Пайплайн создан, но ничего не делает. Все ресурсы (например, сетевые соединения, устройства ввода) закрыты. Это как «выключенный» режим.

2. READY — подготовка.
   Пайплайн готов к работе, но не передаёт данные. В этом состоянии элементы могут резервировать ресурсы (например, открыть файл или камеру), но не начинают читать или декодировать.

3. PAUSED — пауза.
   Пайплайн начинает обработку, но не выводит данные наружу.
   Например, rtspsrc может начать принимать RTP-пакеты, декодер — обрабатывать первый кадр, но видеовыход (autovideosink) ещё не показывает изображение.
   Это состояние используется для буферизации начальных данных — например, чтобы накопить немного видео перед началом плавного воспроизведения.

4. PLAYING — воспроизведение.
   Пайплайн полностью активен: данные передаются от элемента к элементу, идёт вывод на экран, звук, запись и т.д.
   Это конечное рабочее состояние.

💡 Аналогия:
Представьте, что вы включаете проектор в кинотеатре:

• NULL — проектор выключен,
• READY — включён, но не показывает,
• PAUSED — лампа горит, диск вращается, но изображение «заморожено»,
• PLAYING — фильм идёт.

Переходы между состояниями

Переходы всегда происходят последовательно:

NULL → READY → PAUSED → PLAYING

И в обратную сторону:

PLAYING → PAUSED → READY → NULL

Вы не можете, например, перейти сразу из NULL в PLAYING — GStreamer сам пройдёт все промежуточные состояния.

Когда вы вызываете pipeline.set_state(Gst.State.PLAYING) в Python, GStreamer:

• сначала переведёт пайплайн в READY,
• затем в PAUSED,
• и только потом — в PLAYING.

Каждый переход может занимать время — особенно если элементу нужно открыть сетевое соединение или файл.

---

Bus: шина сообщений от пайплайна к приложению

Bus (или «бус») — это внутренняя очередь сообщений, через которую элементы пайплайна сообщают о важных событиях приложению. Это как «почтовый ящик»: если что-то произошло — письмо пришло, и приложение может его прочитать.

Без bus приложение не узнает, когда:

• видео закончилось (EOS),
• произошла ошибка,
• изменилось состояние,
• появилась информация о таймстемпах или буферизации.

Как работает bus

Каждый пайплайн имеет свою собственную bus. Элементы (например, rtspsrc, decodebin, autovideosink) могут посылать на bus сообщения, а приложение — «слушать» эту шину и реагировать.

📌 Важно: bus — это не поток данных, а поток управляющих сообщений.
Данные (видео, аудио) текут по пэдам от элемента к элементу.
Сообщения (ошибка, конец потока) идут по bus от элемента к приложению.

Основные типы сообщений

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

Тип сообщения	Что означает	Пример использования
EOS (End of Stream)	Поток данных завершён.	Видеофайл закончился, камера отключилась.
ERROR	Произошла ошибка.	Не удалось подключиться к RTSP, сбой декодирования.
WARNING	Предупреждение.	Потеря пакетов, но воспроизведение продолжается.
STATE_CHANGED	Элемент или пайплайн изменил состояние.	Полезно для отладки и синхронизации.
BUFFERING	Идёт буферизация.	Например, при старте потока или потере сети.
TAG	Получены метаданные.	Название трека, автор, разрешение.

---

Как приложение узнаёт о событиях: пример с Python

Представим, что вы запустили пайплайн, который читает RTSP-поток. Как вы узнаете, что:

• соединение потеряно?
• поток закончился?
• произошла ошибка?

Только через bus.

Вот как это делается в Python:

bus = pipeline.get_bus()  # Получаем шину пайплайна

while True:
    msg = bus.timed_pop_filtered(100 * Gst.MSECOND, 
                                 Gst.MessageType.ERROR | Gst.MessageType.EOS)
    if msg:
        if msg.type == Gst.MessageType.EOS:
            print("Поток завершён.")
            break
        elif msg.type == Gst.MessageType.ERROR:
            err, debug = msg.parse_error()
            print(f"Ошибка: {err} | Детали: {debug}")
            break

Что происходит в этом коде?

1. pipeline.get_bus() — получаем доступ к шине.
2. timed_pop_filtered() — ждём сообщение до 100 миллисекунд, но только интересующих нас типов: ERROR или EOS.
3. Если пришло сообщение:
   • EOS — значит, поток закончился (например, файл дошёл до конца).
   • ERROR — произошла ошибка (например, камера недоступна).
4. В обоих случаях цикл завершается, и можно корректно остановить пайплайн.

💡 Почему timed_pop?
Мы не хотим блокировать приложение навсегда.
timed_pop — это «мягкое» ожидание: если сообщения нет, через 100 мс управление вернётся в цикл, и можно, например, проверить другие события или обновить интерфейс.

---

Пример: что происходит при старте RTSP-потока

Рассмотрим реальную последовательность событий при запуске пайплайна:

gst-launch-1.0 rtspsrc location=rtsp://cam/stream latency=0 ! decodebin ! autovideosink

1. Пайплайн переходит из NULL → READY → PAUSED.
2. rtspsrc пытается подключиться к камере.
3. Если подключение успешно — приходит сообщение STATE_CHANGED на bus.
4. Если ошибка (например, камера не отвечает) — приходит ERROR.
5. Когда видео начинает поступать — decodebin декодирует первый кадр.
6. Пайплайн переходит в PLAYING.
7. Если камера внезапно отключится — rtspsrc отправит EOS.
8. Приложение, слушающее bus, получит EOS и может переподключиться или завершить работу.

---

Зачем это нужно: связь с Python и автоматизацией

Понимание bus и состояний — ключ к созданию живых приложений, а не просто одноразовых команд.

Когда вы пишете код на Python:

• Вы можете реагировать на ошибки и перезапускать пайплайн.
• Вы можете отслеживать конец потока и переключаться на другую камеру.
• Вы можете выводить уведомления, менять интерфейс, логировать события.

🔄 Без bus ваше приложение будет «слепым» — оно не узнает, работает ли пайплайн, или завис где-то между состояниями.

---

Итог: карта понятий

Понятие	Описание
Состояния	NULL → READY → PAUSED → PLAYING. Управляют жизненным циклом пайплайна.
Bus	Шина сообщений. Через неё элементы сообщают приложению об ошибках, завершении, изменениях.
EOS	Конец потока. Нужно для корректного завершения.
ERROR	Ошибка в элементе. Требует реакции приложения.
STATE_CHANGED	Сигнал о смене состояния. Полезен для отладки.

---

Заключение

Теперь вы понимаете, что пайплайн — это не просто «труба» для данных, а живой объект, который:

• проходит через чётко определённые состояния,
• может посылать уведомления о своих действиях,
• требует от приложения внимания и реакции.

Эти механизмы — состояния и bus — являются основой для построения надёжных, программируемых медиа-приложений. В следующих разделах мы увидим, как использовать их на практике в Python, чтобы создавать гибкие системы с RTSP-камерами, OBS и другими инструментами.