Как искать аудио / видео данные с переменным битрейтом (VBR)? - PullRequest
2 голосов
/ 18 января 2010

Это может быть слишком общий вопрос, но каков общий подход для поиска в медиафайлах (видео или аудио любого вида / формата), если данные имеют переменную скорость передачи данных (VBR)?

Кажется, что это легко сделать, если поток имеет постоянный битрейт (CBR). Например. если вы знаете, что это 256 кбит / с, и вы хотите искать вперед / назад на 30 секунд, просто подсчитайте, сколько (приблизительно) битов, конвертируйте их в байты и ищите столько байтов вперед / назад в файле. Наконец, продолжайте чтение и анализ до следующего заголовка / block-start / keyframe / чего бы то ни было и продолжайте воспроизведение оттуда.

Хорошо, но что вы будете делать, если битрейт сильно варьируется? Например. это может быть что-нибудь от 32 до 512 кбит / с и постоянно меняется? Я знаю, что это может зависеть от аудио / видео формата. Некоторые форматы файлов имеют индексные таблицы в начале / конце, которые вы можете использовать, а некоторые файлы содержат указатели в потоке, сколько байтов пропустить для пропуска следующих X секунд. В этом случае вы можете работать с этой информацией, однако, что если в формате нет такой таблицы или указателей?

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

Хотя приведенный выше алгоритм может работать, он звучит довольно плохо и, вероятно, очень медленно на практике. Так как это на самом деле сделано? Кто-нибудь когда-нибудь писал медиаплеер / плеер-плагин какого-то рода? Или просто так, что каждый «приличный» формат, поддерживающий VBR, должен иметь какие-то индексные таблицы или указатели пропуска в потоке, если он ожидает, что программное обеспечение будет корректно искать, а не просто воспроизводить от начала до конца?

Ответы [ 3 ]

2 голосов
/ 18 января 2010

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

2 голосов
/ 18 января 2010

Именно поэтому (например) DVD используют файлы VOB вместо необработанных битовых потоков. С файлом VOB вы получаете не только сам битовый поток, но и указатели на последовательные кадры, поэтому вы можете быстро и легко перейти к другому кадру.

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

1 голос
/ 18 января 2010

Вы можете сохранить грубый индекс в вашем файле в начале, с расположением фиксированного количества точек поиска в файле. В каждой такой точке поиска вы можете хранить субиндекс индекса точек поиска в этом разделе файла и т. Д. Рекурсивно. Вы можете рассматривать это как своего рода дерево B +, но с узлами, хранящимися непосредственно перед данными, которые они индексируют.

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

...