amarao (amarao_san) wrote,
amarao
amarao_san

avinfo [fukatsu!]

Во мне проснулась робкая жажда программирования.

Заодно, пришло понимание, что я начал там писать полную хрень (в ранних альфах, с кешем, сложными фильтрами, шаблонами и т.д.).

Попробую изложить тезисы, почему avinfo всё ещё имеет право на жизнь:

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

Код чтения avi, по моей памяти, кажись, 6кб, OGM - около 4, MKV - около 3, MPG (включая теги MP3 и апроксимацию битрейта) - около 8 . Это всё без единой внешней библиотеки (вычитаем libc). Работал этот код по моим ощущениям тоже быстро (быстрее полноценных парсеров), в первую очередь, потому что пропускалась вся лишняя информация.

В вопросах индексирования это может быть интересным. Всё ещё.

2) АПИ для получения информации о файле (в случае наличия оного АПИ) может быть сильно (на порядок, а то и на полтора) проще АПИ для работы с MM-файлом.

3) Возможность дампа информации в примитивной форме в пайп может быть очень удобна для скриптов (например, поиск LQ файлов).


Что есть лишнего (из того, что было сделано)
1) Скриптовый недоязык. Питона я всё равно не напишу, остальное есть быть мрак и бред. Возможно, сохранение printf подобного языка форматирования строк, но без циклов и прочих LR(1) грамматик.
2) Всякие кеширования и прочие прелести. Дали файл - выдали результат. Просто и незатейливо.
3) Рекурсия каталогов. Холодно и цинично - find, xargs. //Обсуждабельно для счастья виндов
4) Сбор статистики. find и awk справится с задачей куда как лучше и проще.

Итого, как выглядит примерная модель fukatsu avinfo:

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

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

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

Наверное, работу стоит начать с проработки интерфейса.

Какую информацию о мультимедиа файле мы можем получить? Или, правильнее, какие типы мультимедиа-файлов мы можем знать?

1) mkv/avi/ogm/mpeg - один или несколько потоков аудио, видео и текстовой информации.
2) VOB'ы, в которых чёрт ногу сломит (и как их описывать не понятно).
3) музыкальные файлы (mp3/flac/ape/ogg/etc) - в принципе, их можно воспринять как мультимедиа файл с числом видео-потоков=0

Дополнительную головную боль добавляют теги. В 99% случаев они не составляют проблем. Оставшийся 1% - это id3v2, с какими-то дикими вещами, вроде embedded pictures, gzip'ом и т.д. Сей вопрос я предлагаю отложить.

4) Файл может иметь сопровождающие файлы (являющиеся неотъемлимой частью), например, субтитры. Это сложный вопрос, потому что нам придётся сильно выпрыгивать за модель "на входе файл, на выходе инфо". Откладываем. Вероятнее всего, с вобами аналогично. Если я таки не дочитаю, как выяснить мультимедиа информацию из idx-файла.

Итак, интерфейс на входе:

1 вариант: имя файла, глубина парсинга.
2 вариант: файловый хэндл, глубина парсинга. Очевидно, что первый интерфейс оболочка вокруг второго.

Интерфейс на выходе:

общие данные о файле (только для первого варианта: имя, размер), тип.
Число потоков каждого типа (типы потоков: аудио, видео, текст, прочее)
наличие описания
время воспроизведения (как максимум из времён каждого из потоков)
обобщённый битрейт
флаг, указывающий на то, является ли информация точной.

Для каждого потока возможная информация:
* Длина потока (время)
* фрейм/частота оцифровки
* Средний битрейт
* Тип битрейта (постоянный или меняющийся)
* битность (цвета, звука)
* геометрические размеры (для видео)
* тип (кодека, субтитров и т.д.)
* язык
Данные возвращаются в виде пяти структур: первая, фиксированного формата - базовые данные о файле
вторая, фиксированного формата - обобщённые данные о файле (с опущениями и огрублениями)
третья, представляющая из себя список фисксированных структур для каждого потока (включает в себя помимо вышеперечисленного тип потока (видео/аудио) и порядковый номер.
четвёртая - описание фиксированного формата (с огрублениями)
пятая - список элементов описаний для всех потоков, все (включая нестандартные) элементы описания, которые были найдены.

как-то так?
Tags: avinfo
Subscribe

  • Проблемы от ipv6

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

  • А вот вам пост об исторической нелогичности

    Вот есть у меня файл /etc/default/grub.d/unified.cfg для включения unified cgroups для systemd. А вот вопрос (ответ на который я хорошо знаю, но…

  • (no subject)

    Я тут, внезапно, обзавёлся ноутбуком. Я хотел было взять всякое разное свободное (purism/system76 и т.д.), но оказалось, что у них ничего нет…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 16 comments

  • Проблемы от ipv6

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

  • А вот вам пост об исторической нелогичности

    Вот есть у меня файл /etc/default/grub.d/unified.cfg для включения unified cgroups для systemd. А вот вопрос (ответ на который я хорошо знаю, но…

  • (no subject)

    Я тут, внезапно, обзавёлся ноутбуком. Я хотел было взять всякое разное свободное (purism/system76 и т.д.), но оказалось, что у них ничего нет…