Комментарии 10
Спасибо за сравнение.
Есть еще одна библиотека libAV
Для LibAV есть биндинги на Python github.com/mikeboers/PyAV
Как будто руки развязали, если до этого пользовался opencv
К примеру можно получить не декодированный фрейм.
Есть еще одна библиотека libAV
Для LibAV есть биндинги на Python github.com/mikeboers/PyAV
Как будто руки развязали, если до этого пользовался opencv
К примеру можно получить не декодированный фрейм.
Спасибо. Почему-то я ее не нашел когда искал.
Я в следующей статье хотел расписать еще одну ключевую особенность gstreamer. Можно сделать несколько выходов из одного пайплайна. В итоге кадр декодируется один раз, а обрабатывается по разному. Например можно вырезать 3 небольших области из одного кадра и отдать разным модулям по сети.
Я в следующей статье хотел расписать еще одну ключевую особенность gstreamer. Можно сделать несколько выходов из одного пайплайна. В итоге кадр декодируется один раз, а обрабатывается по разному. Например можно вырезать 3 небольших области из одного кадра и отдать разным модулям по сети.
VLC как и OpenCV используют FFMPEG, не вижу смысла сравнивать эти 3… даже не библиотеки а frameworks (opencv) и аппликацию (VLC)
Gstreamer тоже не являеться библиотекой для декодирования видео, а целым framework-ом
через который можно выбрать ffmpeg или на прямую виде декодер x264/265 например…
которые в свою очередь используються в ffmpeg
а использование разных цветовых форматов вообще не имеет отношение к видео декодерам…
видео всегда кодируеться в YUV формате и чаше всего 4:2:0 или (что одно и тоже ) 4:1:1
сравнение мягко говоря странное
Gstreamer тоже не являеться библиотекой для декодирования видео, а целым framework-ом
через который можно выбрать ffmpeg или на прямую виде декодер x264/265 например…
которые в свою очередь используються в ffmpeg
а использование разных цветовых форматов вообще не имеет отношение к видео декодерам…
видео всегда кодируеться в YUV формате и чаше всего 4:2:0 или (что одно и тоже ) 4:1:1
сравнение мягко говоря странное
а использование разных цветовых форматов вообще не имеет отношение к видео декодерам…
видео всегда кодируеться в YUV формате и чаше всего 4:2:0 или (что одно и тоже ) 4:1:1
См. здесь:
1.
Термин Y'UV относится к аналоговой схеме кодирования, в то время как Y'CbCr ссылается на цифровые схемы кодирования. Одно из различий между ними в том, что набор коэффициентов компонентов цветности U, V и Cb, Cr различен. Однако термин YUV часто используется ошибочно, обращаясь к кодировке Y'CbCr. Следовательно, выражения типа «4:2:2 YUV» всегда относятся к 4:2:2 Y'CbCr, так как просто нет такого понятия, как 4:x:x в аналоговой кодировке (например, YUV).
2. 4:2:0 ≠ 4:1:1
3. Нагрузка на декодер зависит от цветового формата.
.
.
Статью нужно сильно дорабатывать.
Вы правы в том что термин YUV родом из аналогового телевидиния, но этот термин применим и к цифровому, в основном как собирательный для всех подобных форматов.
а на практике используется следующее преобразование
Y = Y
U = Cb + 128
V = Cr + 128
и кстати I420 и YUV420p это одно и тоже…
2. Действительно 4:2:0 ≠ 4:1:1, но количество информации одинаково, так что для данного теста не важно, ну кроме того что добавляет работы аппликации или фраймворку перед экодером, так как… смотрим следущий пункт
3. Все видео энкодеры используют для сжатия только цветовую схему YUV и по умолчанию 4:2:0 (сегодня) а во времена MPEG2 4:2:2
в дополнение стандарты поддерживают 4:4:4 и больше чем 8 бит для каждой компоненты
что и применяется для HDR
то есть да конечно увеличенная резолюция цветовой составляющей повлияет на декодер
но это никак не связано с YUV<->RGB
The scope of the terms Y′UV, YUV, YCbCr, YPbPr, etc., is sometimes ambiguous and overlapping. Historically, the terms YUV and Y′UV were used for a specific analog encoding of color information in television systems, while YCbCr was used for digital encoding of color information suited for video and still-image compression and transmission such as MPEG and JPEG. Today, the term YUV is commonly used in the computer industry to describe file-formats that are encoded using YCbCr.
а на практике используется следующее преобразование
Y = Y
U = Cb + 128
V = Cr + 128
и кстати I420 и YUV420p это одно и тоже…
2. Действительно 4:2:0 ≠ 4:1:1, но количество информации одинаково, так что для данного теста не важно, ну кроме того что добавляет работы аппликации или фраймворку перед экодером, так как… смотрим следущий пункт
3. Все видео энкодеры используют для сжатия только цветовую схему YUV и по умолчанию 4:2:0 (сегодня) а во времена MPEG2 4:2:2
в дополнение стандарты поддерживают 4:4:4 и больше чем 8 бит для каждой компоненты
что и применяется для HDR
то есть да конечно увеличенная резолюция цветовой составляющей повлияет на декодер
но это никак не связано с YUV<->RGB
> Библиотеки для декодирования видео. Сравнение на Python и Rust
Спасибо за статью.
Правда, зашёл почитать именно сравнение Python и Rust в области декодирования, а через пару абзацев понял, что тут сравнение обёрток на тех же языках для чего-то написанного на С/С++. Хотя, не спорю, и это тоже полезная информация для тех, кто выбирать будет инструмент.
С другой стороны, писать с нуля декодер на Python/Rust — я тоже этого в статье не так уж и ожидал :)
Спасибо за статью.
Правда, зашёл почитать именно сравнение Python и Rust в области декодирования, а через пару абзацев понял, что тут сравнение обёрток на тех же языках для чего-то написанного на С/С++. Хотя, не спорю, и это тоже полезная информация для тех, кто выбирать будет инструмент.
С другой стороны, писать с нуля декодер на Python/Rust — я тоже этого в статье не так уж и ожидал :)
А если нам нужно извлекать из видео не только фото-поток, но и аудио-поток, какие из библиотек подходят и как это делать? Насколько я помню, OpenCV не умеет, а GStreamer должен уметь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Библиотеки для декодирования видео. Сравнение на Python и Rust