Продолжаем отслеживать судьбу изменений, описанных в post/2015/03/29/avcpp_api-2_rework_vexa_pervaja.

Как обычно, объём работ отличается от того, что было запланировано. Итак, что сделано:

1. Работа со словарями и поддержка оных во всех местах, где только можно. Это вызвало необходимость разнести открытие входного потока и поиск информации о стриме ( post/2015/07/20/snova_ffmpeg_i_low-latency). Как следствие, добавился новый вызов: av::FormatContext::findStreamInfo(). Он может принимать коллекцию словарей для каждого стрима в потоке.
2. Начата работа над фильтрами. Уже появилась базовая инфраструктура. Но пока нет понимания в каком виде оно должно получиться на выходе.
3. В рамках чистки кода тотально переработана обработка ошибок. Теперь это делается через std::error_code, который передаётся опциональным аргументом в те функции фейл которых может приводить к неоднозначностям в будущем. Если переменная для кода ошибки не передана, будет выброшено исключение av::Exception которое будет содержать данный код. Планируется, что набор исключений расширится под каждую сущность. Данные изменений повлекли достаточно сильные изменений в API, требующие изменений в коде приложений, которые их используют. При обработке ошибок стоит учитывать категорию оных. На дынный момент используется, как минимум три: * avcpp_category() - для внутренних ошибок AvCpp * ffmpeg_category() - для ошибок, пришедших от FFmpeg * system_category() - для системных ошибок, в основном так рапортуются ошибки выделения памяти при помощи встроенных av_alloc() (когда владение принимается FFmpeg’ом и он сам освобождает, как следствие, использовать new/new[] нет возможности). Целесообразность использовать std::bad_alloc обдумывается.

Ну и главное, реорганизация бранчей:

• все наработки первой вехи выделены в отдельный бранч api-2.0 (исправляются только ошибки)
• старый мастер стал бранчем api-legacy (для совместимости, самостоятельно тут ничего не исправляется, только принимаются мерж-реквесты)
• вся разработка перемещена на бранч master

Что осталось:

1. Интерфейс опций
2. Доделать фильтры
3. Ревизия и чистка кода в т.ч. примеров.

Планируется, что это будет сделано в следующей, третье вехе.

Как обычно, за отзывы, багрепорты и пул-реквесты буду благодарен.

Для начала: создал репозиторий PPA, куда буду с разной периодичностью бубликовать снапшот QtC из master-бранча. Кроме того, туда же поместил свой плагин CMakeProjectManager2:

https://launchpad.net/~adrozdoff/+archive/ubuntu/qtcreator-git

Установка:

sudo add-apt-repository ppa:adrozdoff/qtcreator-git
sudo apt-get update
sudo apt-get install qtcrator-git qtcreator-git-plugin-cmake2

Для разработчиков плагинов будет полезен пакет qtcretor-git-dev который ставит в /usr/src/qtcreator-git заголовочники и .pri файлы. Пример использования можно поглядеть в спеках отстройки qtcreator-git-plugin-cmake2:

sudo apt-get install qtcrator-git-dev

Ну а теперь фичи.

Кодовая модель

Уже давно появились приятные дополнительные инструменты вроде “Reparse Externally Changed Files” (удобно при наличии внешних генераторов, тот же протобуф) и “Inspect C++ Code Model…”, позволяющая понять, что не так при парсинге и отослать более вменяемый отчёт.

Сравнительно же недавно появилась возможность задавать индивидуально для каждого файла дополнительные директивы препроцессора: “Additional Preprocessor Directives…”. Очень удобная штука, когда парсинг почему-то затыкается (например какая-то опция может подхватываться из переданных CXXFLAGS) - обозначил и вперёд! Или правишь код на одной системы, а нужно исправить блок для другой: определяем “#define WIN32” и пробуем что получилось. Для быстрого доступа служит иконка с “#” в верхнем правом углу рядом с номером строки и колонки.

GUI

Тоже появилось сравнительно давно, многие просили: открытие в новом окне (Window -> Open in New Window иди Ctrl+E,4). Удобно при навигации и рефакторинге при наличии нескольких мониторов.

CMake

Про свой плагин не пишу. В мейнстриме появилась возможность задавать не один фиксированный cmake, а разные для разных наборов инструментов (Kits).

External Tools

Данный функционал оооочень давно в QtC, но очень многие его не замечают. А ведь очень много проблем можно решить с его помощью. К примеру: править исходники локально, а потом засабмитить на билд-сервер и выполнить на нём процедуру билда. Если чуть поднапрячься, можно и парсинг ошибок разобрать.

Либо вызвать cppcheck на текущий проект, либо… что в голову взбредёт.

Чего хотелось бы, но нет

1. Настройки лицензии (шапки для новых файлов) индивидуально для проекта.
2. Замена отдельных частей Kit индивидуально для проекта
3. Более гибкая система настройки устройств для Baremetal: сейчас устройство намертво привязано к Kit со своими настройками доступа к, примеру, OpenOCD и gdb. Вот для Cypress SDK нужно как минимум два: для основной прошивки и для Bootloader.

Засим пока всё.

В дополнение к моей прошлой заметке: post/2014/09/24/x264_low_latency пару статей на эту же тему, но без привязки к x264:

• Minimizing the initial delay - профилировка цепочки запуска входного потока
• Minimizing the latency in realtime communication

Стоит отметить, что в первой статье наихудшие показатели показала avformat_find_stream_info(), эта же функция не понравилась коллеге на работе, но без неё могут быть такие артефакты:

• ошибки при чтении фрейма (av_read_frame())
• может случаться примерно такое: https://github.com/h4tr3d/avcpp/pull/7#issuecomment-122670538
• может ещё чего.

В общем, согласно документации:

The above code attempts to allocate an AVFormatContext, open the specified file (autodetecting the format) and read the header, exporting the information stored there into s. Some formats do not have a header or do not store enough information there, so it is recommended that you call the avformat_find_stream_info() function which tries to read and decode a few frames to find missing information.

Суть: просто открыть файл не всегда достаточно, что бы делать предположения о некоторых параметрах файла. Походу, с этим нужно просто смириться или попытаться предпринять меры из ссылки 1, а именно зарезать параметры probesize и analyzeduration в 32 (минимально допустимое значение).

Слишком много параметров сборки появилось. Поэтому на досуге да под эгидой нового продукта наваял правила для сборки кода при помощи CMake: https://github.com/h4tr3d/fx3-cmake

Под виндой нужно обязательно указывать генератор: при использовании cs-make поставляемого вместе с SDK это “MinGW Makefiles”.

Сегодня для себя открыл:

1. http://habrahabr.ru/company/nerepetitor/blog/256317/
2. https://ru.wikipedia.org/wiki/%D0%A1%D0%BA%D0%BE%D0%BB%D1%8C%D0%B7%D1%8F%D1%89%D0%B0%D1%8F_%D1%81%D1%80%D0%B5%D0%B4%D0%BD%D1%8F%D1%8F

хотя, как оказывается, уже использовал раньше (в варианте простого скользящего). Только не знал, что это общеизвестный приём.

Для начала, что такое AvCpp - это C++ враппер над FFmpeg, позволяющий несколько упростить работу непосредственно с функциями FFmpeg.

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

Изначально структура классов опиралась на Xuggle API, ведь когда начинал его делать, многое не понимал - почему оно так. Со временем такой подход перестал мне нравится, начали вылазить всякие неприятные оверхеды, баги. Так появился подпроект API-2, цели которого:

1. Уйти где только можно от shared_ptr (это получилось почти везде).
2. Использовать по максимуму возможности новых версий FFmpeg, где появился reference-counting для AVFrame/AVPacket, при этом предоставить возможности создавать “тяжёлые” копии, где нужно.
3. Более логично организовать мапинг сущностей FFmpeg в AvCpp, к примеру, если раньше AVCodecContext мапился в av::StreamCoder, то теперь av::CodecContext, аналогично для AVFormatContext (av::Container vs av::FormatContext).
4. Корректно реализовать аудио-ресемплер
5. Добавить побольше примеров использования API2
6. Работа с av_options для поддерживаемых сущностей
7. Поддержка передачи параметров через словари
8. Тотальная переработка фильтров
9. Чистка кода, удаление ненужных сущностей

На текущий момент на бранче api-2 уже лежат почти все эти наработки. Нереализованными остались последние 4 пункта. Приэтому, попутно, устранено несколько багов, особенно связанных с последовательностью уничтожения разных объектов (например Stream2 и FormatContext: стримом владеет FormatContext, Stream2 только предоставляет доступ к нему, при этом, даже если уничтожить объект контекста, объект Stream2 может теперь корректно рапортовать, что он инвалидировался).

Вторая веха, судя по всему, будет реализация поддержки AVOptions/AVDict, третья веха - фильтры (к слову их сейчас нет вообще в рамках API-2). Последующие вехи пока не сформированы, скорее всего нужно будет подумать над возможностями использования аппаратного ускорения для декодирования (оно достаточно некрасиво и в самом FFmpeg реализовано - нужно делать много телодвижений).

В любом случае, я уже настоятельно рекомендую начинать использовать ветку api-2. В скором времени она заместит master-ветку, а текущий мастер переедет на ветку legacy.

За отзывы, багрепорты и пул-реквесты буду благодарен.

В Qt 5.4.1 вернули рендеринг шрифтов в Linux а-ля Qt4. Поставил Qt 5.4.1 ( отсюда), собрал Qt Creator из git, запустил, шрифты явно не похожи на то, что используется в системе (Linux Mint 17.x/Cinnamon).

Поиск в инетрнетах привёл на ссылку: https://forum.manjaro.org/index.php?topic=14931.0

Если коротко, то установка переменной окружения: export XDG_CURRENT_DESKTOP=GNOME

волшебным образом преобразует внешний вид приложения. Будет хорошим тоном прописать это в qtcreator.sh или аналогичный враппер для приложения, а не делать общесистемным параметром.

По умолчанию этот параметр для Cinnamon содержит: X-Cinnamon, что соответствует спекам XDG.

Стоить отметить, что после перезагрузки всё стало на свои места и без этого параметра. Но если проблема будет проглядываться - попробуйте такой вариант.

Очередная порция изменений в развитие post/2015/01/22/cmakeprojectmanager2_uluchshenija_v_dialoge_konfigurirovanija:

1. Исправлен креш при создании конфигурации, при указании тулчейн файла, когда он лежит в директории исходников. Изредка креш проявлялся при переключении уже готовых конфигураций.
2. Добавлена кнопка обзора для выбора тулчейн-файла. По умолчанию открывается в дереве исходников проекта, если тулчейн выбран в другом месте (к примеру, у вас коллекция тулчейнов независимых от проекта), то открывается в месте, где лежит тулчейн. В быстрые закладки добавляется ссылка на дерево проекта, что бы было можно быстро туда перейти. Закрыта задача #2.
3. Добавлена возможность очищать кеш при запуске CMake, что бывает необходимо при изменении некоторых параметров, одним из них, к примеру, является CMAKE_TOOLCHAIN_FILE, другим популярным (особенно при выборе разных версий Qt) является CMAKE_PREFIX_PATH. Изменение этих параметров без удаления кеша ни к чему не приводит, поэтому добавил параметр “Reset cache on CMake run”. Стоит отметить, что при изменении тулчейна это действие обязательно, поэтому, если тулчейн поменялся, но этот параметр не включен, то будет выдаваться вопрос: “You change toolchain. This action requires CMake cache reset. Continue?”. Закрыл задачу #1
4. При встроенном редактировании тулчейна теперь открывается не пустое окно, если ничего не было, а пример тулчейна для Mingw. Можно оставлять только опции, задающие компилятор, что бы выбрать нужную версию оно в системе, если их стоит несколько.
5. Небольшое косметическое изменение: кнопка Edit стала поменьше.

Бывает нужно, часто забываю:

• R0–R15 and r0–r15
• c0–c15 coprocessor registers
• p0–p15 coprocessor registers
• a1-a4 scratch registers, synonymous with r0-r3
• v1-v8 variable registers, synonymous with r4-r11
• sb and SB stack base, synonymous with r9
• sl and SL stack base, synonymous with r10
• fp and FP frame pointer, synonymous with r11
• ip and IP intra-procedure call scratch register, synonymous with r12
• sp and SP stack pointer, synonymous with r13
• lr and LR link register, synonymous with r14
• pc and PC program counter, synonymous with r15
• s0-s32 VFP single precision registers
• d0-d16 VFP double precision registers
• fpsid VFP system ID register
• fpscr VFP status and control register
• fpexc VFP exception register
• wr0-wr16 WMMX SIMD data registers
• wc0-wc16 WMMX status and control registers
• wcid WMMX coprocessor ID register, synonymous with wc0
• wcon WMMX control register, synonymous with wc1
• wcssf WMMX saturation SIMD flags, synonymous with wc2
• wcasf WMMX arithmetic SIMD flags, synonymous with wc3
• wcgr0-wcgr3 WMMX control general purpose registers, synonymous with wc8-wc11

В дополнение - хороший справочник (armv7tdmi):

• http://www.gaw.ru/html.cgi/txt/doc/micros/arm/index.htm, в частности системы команд
  • ARM: http://www.gaw.ru/html.cgi/txt/doc/micros/arm/asm/asm_arm/index.htm
  • Thumb: http://www.gaw.ru/html.cgi/txt/doc/micros/arm/asm/arm_thumb/index.htm

Для тех, кто не в курсе, что такое CMakeProjectManager2, вот ссылка на статью 2012 года: post/2012/10/17/cmakeprojectmanager2_-_poslednie_izmenenija. Собственно тогда и были сделаны последние крупные изменения, которых мне хватало до сегодняшнего дня. В остальном была работа по синхронизации кодовой базы с апстримом, что бы плагин продолжал собираться и радовать глаз. Код располагается на GitHub: https://github.com/h4tr3d/cmakeprojectmanager2. Инструкции по сборке приложены в README.txt

Итак, как бы ни хотелось, но времени заниматься реализацией TODO листа нет и не предвидится (суть списка: сделать парсер и обойтись без генерации файла для CodeBlocks, а всё остальное уже на это опирается). Но есть и другие задачи. В частности, в сегодняшнем обновлении несколько изменён вид окна “Run CMake” мастера, а именно:

1. Добавлена возможность выбирать тип сборки
2. Добавлена возможность назначать тулчейн (это файл с настройками среды сборки, особенно актуально для кросс-сборки: http://www.vtk.org/Wiki/CMake_Cross_Compiling#The_toolchain_file).

По сути, эти параметры служат для задания в более дружественной формы параметров для CMake: -DCMAKE_BUILD_TYPE= и -DCMAKE_TOOLCHAIN_FILE= соответственно.

Про тулчейн немного подробнее. Изначально планировалось три способа его задания:

1. Автоматическое конструирование на основе Qt Creator Kit
2. Ручное задание файла (пока сделано без возможности открытия диалога поиска, только ручной ввод: issue #2)
3. “Инлайн” тулчейн: редактирует во встроенном редакторе, при запуске контент сохраняется в директории отстройки под именем QtCreator-toolchain-override.cmake

Пока вариант на основе Qt Creator Kit выключен. Будет время - доделаю.

Плюс есть нюанс: согласно документации CMake, смена тулчейна возможно только на новой конфигурации либо на полной очистке текущей (удаления CMakeFiles и CMakeCache.txt), поэтому, если замечены изменения настроек тулчейна, производится полное переконфигурирование без использования кеша. Планирую добавить диалог с предупреждением ( issue #1).

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

Ну и картинка:

Переосмысление реализации паттерна Transaction, опубликованного в “Inside C++”, в рамках стандарта C++11 с блек… variadict templates и хранением данных на стеке.

Lightning_(ПО)|Lightning мощный календарь для Thunderbird . Вкупе с Exchange EWS Provider может явиться полноценной заменой Outlook.

Беда которую заметил буквально сегодня - сдвинутое время в календаре. Из за нашего перехода на перманентное зимнее время. Оказалось, что расширение содержит свою базу описания временных зон (руки отбить за такое, не даёт им покоя слава Java). И обновляться оно пока не собирается. Решил посмотреть сам.

Недавно наткнулся на эту книжку на GitBook: http://arobenko.gitbooks.io/bare_metal_cpp/

Доступна для онлайн-чтения, в виде форматов ePUB, MOBI и PDF. Рассматриваются вопросы уменьшения размера приложений, написания своих реализаций ABI функций, что позволяет более детально понимать, а что там вообще внутри происходит, что бывает полезно и обычных приложениях. Вместе с ней обязательно ознакомиться с post/2013/03/28/scott_meyers._effective_c_in_an_embedded_environment.

Книга больше ориентирована на ARM, в частности Raspberry PI, но идеи адаптировать к другим платформам труда не составит.

На Thinkpad T530 есть два порта для подключения внешних мониторов: VGA и miniDP (Display Port). Если ноутбук с дискретной графикой, то DP разведён на дискретную карту nVidia, соответственно без шаманства графику туда не выведешь.

Полное и законченное описание подключения и вывода по ссылке:
http://www.unixreich.com/blog/2013/linux-nvidia-optimus-on-thinkpad-w520w530-with-external-monitor-finally-solved/

Так сложилось, что в нашей компании используется SVN для внутренних нужд. Но делать локальные эксперименты, или вообще проверки, бранчевания и т.п. значительно удобнее используя git. Естественно и логично для индивидуальной работы использовать git-svn. В статье подробно рассмотрен вопрос экспорта своего нового проекта из git в svn с сохранением истории. Это случай, когда вы делаете локальный проект, отлаживаете его и, по результату, выкладываете в центральный SVN репозиторий.

Подкатом вольный пересказ при использовании стандартного размещения каталогов: ProjectName/{trunk,tags,branches}, для нестандартного - в статье.