Заметки в категории «Система» (страница 5)

Конвертируем в ProRes с помощью FFmpeg

Когда я столкнулся с необходимостью обработать AVCHD видео , то мне пришлось его конвертировать в mp4. Копирование потоков в новый контейнер без обработки вызывало появление какие-то артефактов. Позже я выяснил, что они возникали только во время воспроизведения полученного видео. Когда оно проходит финальный рендеринг, то артефактов уже нет. Думаю, что на это не стоит полагаться. Ведь не понятно что получится в результате. Получить максимальное качество рабочего материала можно, если сконвертировать его в формат ProRes.

Начиная с версии 0.11 кодеки ProRes включены в стандартную сборку FFmpeg.


ffmpeg -i ~/Desktop/00000.MTS \
    -copyts -acodec copy -vcodec prores -profile 0 \
    ~/Desktop/out.mov

Качество видео, а значит и средний битрейт, регулируется параметром profile. Он может принимать значение от 0 до 3 включительно. Эти значения соответствуют профилям:

  • -profile 0 — Apple ProRes Proxy
  • -profile 1 — Apple ProRes LT
  • -profile 2 — Apple ProRes 422 for SD
  • -profile 3 — Apple ProRes HQ for HD

Ещё у FFmpeg есть альтернативная версия с нужными кодеками – FFMedia Broadcast.

Для сборки ffmbc может понадобится установить yasm, если его ещё нет. Я установил его через Homebrew.

brew install yasm

Затем распаковываем исходники ffmbc, конфигурируем их командой ./configure –enable-gpl, собираем make и инсталлируем sudo make install.

У кодека ProRes есть несколько ключей:

  • -qscale <значение> или -cqp <значение>

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

  • -profile <имя>

    Профиль может принимать одно из значений: proxy, lt, std, hq . Если не задан битрейт, то он выбирается автоматически на основании размера кадра и профиля.

  • -b <битрейт>

    Задает примерное значение постоянного битрейта.

Итак, для перекодирования исходного видео в ProRes нужно выполнить команду:


ffmbc -i ~/Desktop/00000.MTS \
    -copyts -acodec copy -vcodec prores -profile std \
    ~/Desktop/out.mov
Оставте свой комментарий

Конвертируем AVCHD для последующей обработки

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

Первое что пришло мне в голову – это пересобрать видео- и аудио-потоки в другой контейнер без перекодировки. Эксперимент закончился неудачей – полученные файлы (а были перепробованы и avi, и mpeg, и mov контейнеры) опять нормально воспроизводились, но либо не импортировались в редактор, либо видео оказывалось местами испорченное.

Тогда я решил полностью перекодировать файл с максимально возможным качеством.


ffmpeg -i 00001.MTS -copyts \
    -acodec libfaac -ar 48000 -ab 256k \
    -vcodec libx264 -crf 15 -coder 0 \
    -filter:v yadif,scale=1280:720 -r 25 \
    output.mp4

Поясню параметры, которые тут использовались:

  • copyts – копирует временные метки и нужен для правильной синхронизации видео и звука;
  • cfr – задает качество при однопроходном кодировании (меньше – лучше качество);
  • coder 0 – отключаем CABAC так как не требуется оптимальный битрейт.

А раз происходит полная перекодировка, то я решил сразу деинтерлейсить видео и немного уменьшить размеры картинки.

Полезная документация:

PS. Собрать свежую стабильную версию FFmpeg всегда можно с помощью Homebrew

brew install ffmpeg
Комментарии к заметке: 3

SPF и DomainKeys для «чайников»

В заголовках писем от CMS моего сайта я вижу такую строку


Authentication-Results: mxfront10h.mail.yandex.net; spf=softfail (mxfront10h.mail.yandex.net: transitioning domain of noteskeeper.ru does not designate 46.254.17.128 as permitted sender) smtp.mail=www-data@noteskeeper.ru

Казалось бы, правильный IP-адрес и домен, а принимающий сервер пишет, что не дозволенный отправитель. Я начал разбираться с этим вопросом и открыл для себя SPF (Sender Policy Framework), DomainKeys и DKIM (DomainKeys Identified Mail).

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

SPF

Особенностью моей ситуации было то, что вся почта обслуживается сервисом Яндекс.Почта для домена. Но и сам хост также может отправлять письма.

У меня уже была указана spf-запись, которая приводится в инструкции по настройке «Почты для домена». Мне нужно было как-то добавить IP адрес хоста в разрешенные отправители почты. Это на деле оказалось не так уж сложно:

@ IN TXT "v=spf1 a include:_spf.yandex.ru -all"

Эта конструкция предписывает считать хост, обозначенный записью A домена, как разрешенный и далее получить ещё дополнительные правила у Яндекса.

Синтаксис и масса других примеров описаны в документации к проекту Sender Policy Framework.

dkfilter

Я решил пойти дальше и настроить цифровую подпись всех писем, которые отсылаются с моего хоста. После недолгих поисков я нашел отличное решение для своей VPS под управлением Ubuntu — dkfilter . Не буду пересказывать принцип настройки этого фильтра. Автор достаточно подробно и точно описал, что нужно сделать.

От себя добавлю несколько изменений, которые мне потребовалось внести.

Конфигурация фильтра

Мне потребовалось руками указать домен noteskeeper.ru, так как скрипт фильтра не мог его правильно определить. Подозреваю, что это последствия какой-то ошибки конфигурирования системы. Пока я остановился на этом варианте.

Ещё я указал метод генерации подписи simple вместо nofws . Если я правильно понял, то это только влияет на то, как будет преобразован текст письма с заголовками прежде, чем будет вычислена сигнатура.

DNS-запись

В инструкции указано, что открытый ключ домена нужно вводить в формате

selector1._domainkey IN TXT "k=rsa; p=MHwwDQYJK ... OprwIDAQAB; t=y"

Из RFC 4870 я узнал, что вместо селектора selector1 может быть любая строка. Главное, чтобы такой же селектор был указан в конфигурации dkfilter.

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

sendmail

Чтобы посылать тестовые сообщения я использовал sendmail. Они, к сожалению, шли в обход фильтра. В FAQ приведены настройки, которые нужно добавить в конфигурацию postfix .

Валидируем подпись домена

Гугл доверяет почте, отправленной с хоста noteskeeper.ru


Received-SPF: pass (google.com: domain of mista_k@noteskeeper.ru designates 46.254.17.128 as permitted sender) client-ip=46.254.17.128;
DomainKey-Status: good
Authentication-Results: mx.google.com; spf=pass (google.com: domain of mista_k@noteskeeper.ru designates 46.254.17.128 as permitted sender) smtp.mail=mista_k@noteskeeper.ru; domainkeys=pass header.From=mista_k@noteskeeper.ru
Received: from noteskeeper.localdomain (localhost.localdomain [127.0.0.1])
    by noteskeeper.localdomain (Postfix) with ESMTP id 997CD2A78003
    for <mistakster@gmail.com>; Mon,  9 Apr 2012 12:57:55 +0400 (MSK)
DomainKey-Signature: a=rsa-sha1; h=Received:To:Subject:Message-Id:Date:From
    b=dQHTHUU8sQCij/EDk+sv5aR8SJRuI51BBgM7LCxfihd1xNm33zUbvGo6/Csk
    spYLkwaAGGINjETWGwe0qaCZJ7AEkyZYbmNcLG2xewRGZCXyIjiygZIVyqqE
    L63lhDnwEzkG5aYyxPOQciVwmWuBExBTwNFKX0Q7p8s4eWUmyIM=;
    c=simple; d=noteskeeper.ru; q=dns; s=email

Подпись успешно проверена.

Комментарии к заметке: 9

Блоговский движок под системой контроля версий Git

Все файлы блоговского движка я храню в Git. Я не стану всем и каждому советовать сразу переходить на систему контроля версий. Очевидно, что для её развертывания потребуется как минимум VPS, навыки администрирования и, собственно, умение пользоваться ею. Иначе все плюсы обратятся в сплошные минусы.

Однако, преодолев все эти трудности можно получить некоторые преимущества.

Редактирование темы и плагинов

Благодаря Git редактировать файлы можно как на домашнем компьютере, так и прямо на сервере. При этом точно знаю, что ничего не «случайно» не потеряется или перезатрется.

Если один и тот же файл был изменен в разных местах, то система сама попробует решить конфликт. А если её это окажется не под силу, то предоставит вам эту возможность.

Обновление версии движка

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

Чтобы сохранить свои исправления я выработал такую схему работы

Дерево коммитов Git

В одной ветке (wp31 ) я храню исходные файлы дистрибутива и все новые версии разворачиваю только туда. А свои правки делаю в основной ветке (master).

После обновления я объединяю эти ветки. Если повезет, то никаких конфликтов не появляется, и в основной ветке я получаю новую версию движка. Чаще всего конфликты в коде все же есть. Но они, как правило, не значительные и легко решаются с помощью соответствующих утилит.

Развертывание изменений на сервере

Все действия сводятся к одной простой команде.

git pull

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

Резервное копирование

Каждый Git-репозиторий может стать резервной копией для других. Фактически у меня 3 идентичных копии: продакшин, внешний репозиторий и локальный репозиторий на домашнем компьютере. В случае повреждения одной из них, восстановить её можно будет из двух других копий.

54307730.19286420.1324395758.c7d8ac3d6d9658c7c572ebaca98a9ceb

Комментарии к заметке: 1

Работа с тегами в Git

Тегами в git-репозитории можно отмечать коммиты или, в общем случае, любые объекты . В нашей команде мы отмечаем тегами релизы, которые уходят в продакшин.

Создание тега

  1. Помечаем локальный коммит

    git tag 12345
    
  2. Отправляем его во внешний репозиторий

    
    git push origin 12345
    

Удаление тега из репозитория

  1. Удаляем тег локально

    git tag -d 12345
    
  2. Удаляем его во внешнем репозитории

    git push origin :refs/tags/12345
    
    
  3. Оповещаем каким-либо способом коллег, чтобы они сделали у себя команду

    git fetch --tags
    

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

Перемещение тега на другой коммит

  1. Принудительно перезаписываем тег

    
    git tag -f 12345
    
  2. Отправляем во внешний репозиторий с принудительной перезаписью

    
    git push --force origin 12345
    
  3. Оповещаем коллег как и в случае удаления тега.

Дополнение

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

git tag 12345 6ff87c4664981e4397625791c8ea3bbb5f2279a3

Отправить во внешний репозиторий все теги текущей ветки можно одной командой.

git push --tags
Комментарии к заметке: 4