Фреймворк GStreamer. Руководство разработчика плагинов. Интерфейсы

Оригинал: GStreamer Plugin Writer's Guide
Авторы: Richard John Boulton, Erik Walthinsen, Steve Baker, Leif Johnson, Ronald S. Bultje, Stefan Kost, Tim-Philipp Muller, Wim Taymans
Дата публикации: 19 июля 2014 г.
Перевод: А.Панин
Дата перевода: 29 июля 2014 г.

Глава 21. Интерфейсы

Раннее в главе под названием "Добавление свойств" мы рассмотрели концепцию свойств объектной модели GObject, позволяющую контролировать поведение элемента. Это очень мощная концепция, обладающая двумя большими недостатками: во-первых, она является очень обобщенной и во-вторых, она не является динамической.

Первый недостаток связан с возможностью приведения свойств в соответствие с интерфейсом для конечного пользователя, который будет создан для управления элементом. Некоторые свойства являются более важными, чем остальные. Лучшим вариантом использования некоторых свойств с целочисленными значениями является создание виджета для изменения целочисленных значений, в то время, как значения других свойств могут быть лучшим образом представлены с помощью виджета ползунка. Такие особенности не могут быть обозначены с помощью существующего механизма свойств, так как реализация пользовательского интерфейса на самом деле никак не связана с реализацией приложения. Виджет пользовательского интерфейса, выводящий значение свойства скорости потока, будет являться таким же виджетом, как и виджет пользовательского интерфейса, выводящий значение свойства размера видео, в том случае, если оба этих виджета использую объект типа GParamSpec для доступа к значениям свойств объектной модели GObject. Другая проблема состоит в том, что использование таких приемов, как группировка параметров, группировка функций или связывание параметров в реальности не представляется возможным.

Вторая проблема концепции свойств объектной модели GObject заключается в том, что они не являются динамическими. Во многих случаях набор корректных значений свойства не является ограниченным, а зависит от данных, которые могут быть получены только в процессе работы приложения. Например, названия входов TV-тюнера могут быть получены элементом для ввода данных video4linux исключительно от драйвера ядра операционной системы после открытия устройства; получение этой информации происходит только тогда, когда элемент переводится в состояние "готовности к работе" (READY). Это значит, что мы не можем создать свойство с перечислением значений для показа их пользователю.

Решение описанных проблем заключается в создании узкоспециализированных типов механизмов управления параметрами элементов для определенных часто используемых механизмов управления параметрами устройств. Для достижения этой цели мы используем концепцию интерфейсов. Базисом всех интерфейсов является тип интерфейса GTypeInterface, объявленный в рамках библиотеки GLib. Для каждого случая, в котором с нашей точки зрения использование интерфейса является обоснованным, нами были созданы интерфейсы, которые могут реализовываться элементами по усмотрению их разработчиков.

Одно важное замечание: интерфейсы не заменяют собой свойства. Наоборот, интерфейсы должны создаваться после свойств. Существуют две важных причины такого разделения. Во-первых, свойства гораздо проще подвергаются интроспекции. Во-вторых, доступ к свойствам может быть получен посредством интерфейса командной строки (при работе с утилитой gst-launch).

21.1. Как следует реализовывать интерфейсы

Реализация интерфейсов начинается с функции получения типа _get_type () вашего элемента. Вы можете зарегистрировать один или большее количество интерфейсов после регистрации типа самого элемента. Некоторые интерфейсы имеют зависимости от других интерфейсов или могут регистрироваться только определенными типами элементов. Вы будете уведомлены о неправильной регистрации интерфейса в ходе использования элемента: исполнение приложения завершится на функции проверки соответствия условию, средствами которой будет выведено описание ошибки. В таком случае вам придется зарегистрировать поддержку необходимого интерфейса перед регистрацией поддержки интерфейса, который вы хотите поддерживать. В примере ниже показана методика добавления поддержки простого интерфейса без дополнительных зависимостей.

Также может использоваться более простая запись:

21.2. Интерфейс URI

Работа над данным разделом пока не начата.

21.3. Интерфейс цветового баланса

Работа над данным разделом пока не начата.

21.4. Интерфейс видеооверлея

Элементу, осуществляющему прорисовку выходных кадров видеопотока на поверхности окна, на том или ином этапе понадобится доступ к этому окну. При работе в пассивном режиме плагину просто не предоставляется готового окна до наступления соответствующего этапа обработки мультимедийного потока, поэтому плагину приходится создавать окно своими силами. В этом случае плагин несет ответственность за уничтожение созданного им окна в момент, когда оно перестанет быть нужным, а также за информирование приложений о том, что окно было создано и может использоваться ими. Приложения информируются о новом окне с помощью сообщения have-window-handle, которое может отправляться со стороны плагина с помощью метода gst_video_overlay_got_window_handle.

Как вы уже наверняка догадались, в активном режиме плагину передается идентификатор окна для вывода видео, поэтому изображение выводится в окне, идентификатор которого был передан. Передача идентификатора окна осуществляется с помощью метода gst_video_overlay_set_window_handle.

Переход из одного режима в другой может осуществляться в любой момент, поэтому плагин, реализующий данный интерфейс, должен поддерживать все режимы. Существует только 2 метода, которые должны реализовывать разработчики плагинов и, скорее всего, реализации этих методов будут выглядеть следующим образом:

Также вам придется использовать методы интерфейса для передачи сообщений в случае необходимости, например, при получении события с информацией о возможностях CAPS, вы можете извлечь из него данные геометрии видео и, возможно, создать впоследствии новое окно.

21.5. Интерфейс навигации

Работа над данным разделом пока не начата.

---

Следующий раздел : Тэги (метаданные и информация о мультимедийном потоке).

---

---