Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
Беспроводные выключатели nooLite купить дешевый 
компьютер родом из Dhgate.com

Lines Club

Ищем достойных соперников.

Библиотека сайта или "Мой Linux Documentation Project"

Фреймворк GStreamer. Руководство разработчика приложений. Портирование приложения на основе GStreamer 0.10 для работы с GStreamer 1.0

Оригинал: GStreamer Application Development Manual
Авторы: Wim Taymans, Steve Baker, Andy Wingo, Ronald S. Bultje, Stefan Kost
Дата публикации: 21 мая 2014 г.
Перевод: А.Панин
Дата перевода: 23 июня 2014 г.

Глава 25. Портирование приложения на основе GStreamer 0.10 для работы с GStreamer 1.0

В данной главе описываются некоторые изменения, которые должны быть внесены в существующие приложения на основе версии фреймворка GStreamer-0.10 для работы с GStreamer-1.0. Если вам нужен полный и актуальный список изменений, обратитесь к отдельному документу "Портирование приложений для работы с фреймворком версии 1.0".

Процесс поритирования простых приложений для работы с версией фреймворка GStreamer-1.0 должен занимать менее одного дня.

25.1. Список изменений

  • Все устаревшие методы были удалены. Повторно скомпилируйте использующее версию фреймворка 0.10 приложение с объявлением макроса GST_DISABLE_DEPRECATED (например, добавив параметр -DGST_DISABLE_FLAGS к параметрам компилятора) и устраните все проблемы перед тем, как приступать к портированию приложения для работы с фреймворком версии 1.0.
  • Элемент "playbin2" был переименован в "playbin", при этом API элемента остался аналогичным.
  • Элемент "decodebin2" был переименован в "decodebin", при этом API элемента остался аналогичным. Учтите, что сигнал "new-decoded-pad" более недоступен и вместо него следует просто использовать сигнал "pad-added" объекта элемента типа GstElement (при этом не забудьте удалить аргумент 'gboolean last' из объявления вашей старой функции обратного вызова для обработки сигналов).
  • Имена некоторых "отформатированных" шаблонов точек соединения изменены, например, имя "src%d" изменено на "src%u" или "src_%u" или аналогичное, так как мы не хотим видеть отрицательные числа в именах точек соединения. Это изменение главным образом влияет на работу приложений, которые создают с помощью запросов точки соединения для элементов.
  • Некоторые элементы, которые имели единственную динамическую выходную точку соединения, теперь имеют обычную выходную точку соединения. Примеры: wavparse, id3demux, iceydemux, apedemux. (Это изменение никоим образом не затрагивает приложения, использующие элементы decodebin или playbin).
  • Элемент playbin на данный момент реализует интерфейс GstVideoOverlay (ранее известный, как GstXOverlay), поэтому в большей части приложений может быть просто удален синхронный обработчик сигналов шины сообщений, с помощью которого устанавливался идентификатор окна, а вместо него этот идентификатор окна может передаваться непосредственно элементу playbin из главного потока приложения перед началом воспроизведения.
    Элемент playbin также реализует интерфейсы GstColorBalance и GstNavigation, поэтому приложениям, использующим их возможности, больше не придется подбирать реализующие их элементы, а следует при любых обстоятельствах использовать элемент playbin.
  • Элементы multifdsink, tcpclientsink, tcpclientsrc, tcpserversr, используемые для доступа к данным посредством отдельных протоколов, были удалены; вместо них следует использовать элементы gdppay и gdpdepay.
  • Механизм сериализации с использованием формата XML был удален.
  • Механизмы зондов и блокирования точек соединения объединены в рамках нового механизма зондов для точек соединения.
  • Функции позиционирования, определения продолжительности потока и преобразования форматов больше не используют указатель на параметр, позволяющий установить результирующий формат.
  • Механизм возможностей обработки видео- и аудиопотоков был упрощен. Вместо типов мультимедийных потоков audio/x-raw-int и audio/x-raw-float используется тип мультимедийного потока audio/x-raw. Аналогично, вместо типов video/x-raw-rgb и video/x-raw-yuv используется тип video/x-raw.
  • Элемент ffmpegcolorspace удален и заменен на элемент videoconvert.
  • Интерфейсы GstMixerInterface/GstTunerInterface были удалены без замены.
  • Интерфейс GstXOverlay был переименован в GstVideoOverlay и на данный момент является частью библиотеки для обработки видеопотоков, расположенной в пакете gst-plugins-base, так как библиотеки интерфейсов больше не существует.
    Имя сообщения "prepare-xwindow-id" от интерфейса GstXOverlay было изменено на "prepare-window-handle" (и интерфейс GstXOverlay был переименован в GstVideoOverlay). Код, в котором осуществлялось непосредственное сравнение типа сообщения со строкой, должен быть изменен с целью использования вместо функции сравнения строк функции gst_is_video_overlay_prepare_window_handle_message(message).
  • Интерфейс GstPropertyProbe был удален. На данный момент замены не существует, но запланирована разработка более функционального аналога для поиска устройств и получения информации об их возможностях, подробнее о котором можно узнать, перейдя по ссылке https://bugzilla.gnome.org/show_bug.cgi?id=678402
  • Функция gst_uri_handler_get_uri() и виртуальная функция get_uri на данный момент возвращают копию строки URI.
    Функция gst_uri_handler_set_uri() и виртуальная функция set_uri на данный момент принимают дополнительный аргумент типа GError, позволяющий обработчику уведомить вызывающую функцию о причине, по которой переданная строка URI не была принята.
    Функция gst_uri_handler_set_uri() на данный момент проверяет, является ли переданный в составе строки URI протокол одним из протоколов, о поддержке которых сообщил обработчик строк URI, поэтому реализации виртуальной функции set_uri также больше не должны проверять это соответствие.
  • GstTagList на данный момент является прозрачным мини-объектом, а не структурой типа GstStructure, как это было ранее. Хотя раньше не возникало никаких проблем с преобразованием от типа GstTagList к типу GstStructure (а в некоторых случаях оно даже требовалось из-за отсутствующего API для работы со списком тэгов) или с использованием API gst_structure_* для доступа к данным списков тэгов, вы не можете впредь использовать подобные техники. Описанные действия могут привести к аварийному завершению приложения.
    Также списки тэгов теперь являются объектами с подсчетом ссылок и, следовательно, не могут более свободно модифицироваться. Убедитесь в том, что вы вызываете функцию gst_tag_list_make_writeable (taglist) перед добавлением, удалением или изменением тэгов из списка.
    GST_TAG_IMAGE, GST_TAG_PREVIEW_IMAGE, GST_TAG_ATTACHMENT: многие тэги типа GstBuffer на данный момент имеют тип GstSample (который на самом деле представлен структурой, содержащей буфер вместе с идентификаторами возможностей и некоторой дополнительной информацией).
  • Функции класса GstController перенесены в класс GstObject. Данный класс больше не существует, поэтому вы не сможете создать отдельный объект на его основе. В дополнение ядро фреймворка содержит базовый класс GstControlSource и класс GstControlBinding. Реализации самих источников команд больше не находятся в библиотеке контроллеров. Второе большое изменение заключается в том, что источники команд генерируют последовательность значений с плавающей точкой типа gdouble, которые приводятся к типам свойств и к их диапазонам значений средствами классов GstControlBinding.
    Весь API gst_controller_* переработан и доступен в упрощенной форме в виде API gst_object_*. Источники команд теперь соединяются со свойствами с помощью функций классов GstControlBinding. Аргументы типа GValue больше не используются при работе с источниками команд.

Следующий раздел : Интеграция.


Эта статья еще не оценивалась
Вы сможете оценить статью и оставить комментарий, если войдете или зарегистрируетесь.
Только зарегистрированные пользователи могут оценивать и комментировать статьи.

Комментарии отсутствуют