Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 109
Пожалуйста! В качестве продолжения будет непосредственно «цикл» видеокодека, а потом и проблемы в которые сегодня все упираются и методы их решения, предпринимаемые в нашей лаборатории в том числе.
Хотелось бы узнать также о том чем отличаются (алгоритмы, подходы) скринкасты от видео (с точки зрения кодирования) и какими практическими подходами стоит пользоваться при созданнии программ типа «удаленный рабочий стол»
Со скринкастами много чего проще:
1) Нефотографичность картинки (интерфейс ОС) => легче жмется сама по себе
2) Проще детектировать движение по векторам кандидатам (о кандидатах в следующей статье) => ровно и красивое поле векторов движения
3) После компенсации движения разностный кадр почти весь серый
Но есть и свои проблемы, особенно когда дело касается передачи в реальном времени. И некоторые традиционные алгоритмы могут безвозвратно испортить документальность какого-нибудь графика на мониторе.
1) Нефотографичность картинки (интерфейс ОС) => легче жмется сама по себе
2) Проще детектировать движение по векторам кандидатам (о кандидатах в следующей статье) => ровно и красивое поле векторов движения
3) После компенсации движения разностный кадр почти весь серый
Но есть и свои проблемы, особенно когда дело касается передачи в реальном времени. И некоторые традиционные алгоритмы могут безвозвратно испортить документальность какого-нибудь графика на мониторе.
Да, продолжение было-бы кстати, интересуют вещи которые получены практическим путем :-)
Меня аж передернуло от 1го скриншота, но статья интересная!
Спасибо, отличная статья.
Прочитал с большим удовольствием и интересом! Спасибо! Жду продолжения!
Расскажите, что такое NALU и почему они используются вместо понятных блоков?
Про NALU ничего не слышал. И гугл что-то тоже не сильно.
Можно ссылку на то, что вы имели в виду?
Можно ссылку на то, что вы имели в виду?
Это вот — en.wikipedia.org/wiki/Network_Abstraction_Layer
Network abstraction layer unit
Network abstraction layer unit
Понял, почитаю — вникну
При поверхностном взгляде думаю, что это относится уже к уровню транспортировки сжатого потока (и его соответствующей упаковки), а не к самому сжатию видеопотока.
При поверхностном взгляде думаю, что это относится уже к уровню транспортировки сжатого потока (и его соответствующей упаковки), а не к самому сжатию видеопотока.
Если это относится к сжатию — буду благодарен, если осветите.
Еще интересно описание балансировки между тремя параметрами: битрейт — качество — устойчивость к потерям в канале.
Конкретнее — возможно ли при зафиксированном качестве и битрейте изменять параметры сжатия/избыточности (и какие именно) кодеков H.263 и H.264 (для примера) так, чтобы при большом проценте потерь в канале качество страдало бы минимально.
Еще интересно описание балансировки между тремя параметрами: битрейт — качество — устойчивость к потерям в канале.
Конкретнее — возможно ли при зафиксированном качестве и битрейте изменять параметры сжатия/избыточности (и какие именно) кодеков H.263 и H.264 (для примера) так, чтобы при большом проценте потерь в канале качество страдало бы минимально.
Это одна из интереснейших тем современности. А создание быстрых декодеров, терпимых к ошибкам — весьма нетривиальное искусство. Я пока сам не могу достаточно компетентно об этом написать. Но могу задать этот вопрос спецам в лаборатории и по наличию времени опубликовать.
Вряд ли существует какое-то уникальное решение. Важно, какая задача решается, какой контент, какие задержки допустимы, и кто конечные получатели, а также насколько вероятны ошибки при передаче, и какого рода эти ошибки.
Как что-то более-менее общее можно рассмотреть увеличение частоты ключевых кадров. Ещё советую обратить внимание на опцию --intra-refresh у кодера x264.
Пост разработчика об этом: x264dev.multimedia.cx/archives/249
По идее, должны быть ещё какие-то механизмы добавления информации для восстановления бинарного потока в случае ошибок. Но тут я ничего не знаю.
Как что-то более-менее общее можно рассмотреть увеличение частоты ключевых кадров. Ещё советую обратить внимание на опцию --intra-refresh у кодера x264.
Пост разработчика об этом: x264dev.multimedia.cx/archives/249
По идее, должны быть ещё какие-то механизмы добавления информации для восстановления бинарного потока в случае ошибок. Но тут я ничего не знаю.
Формально есть три пути «помехозащищенности» для реалтаймового видеопотока:
1) На уровне транспорта потока — это всякие коды исправляющие ошибки (ECC) — Рида-Соломона, БЧХ и прочее.
2) На уровне формирования RTP пакетов — например, кладем каждый фрейм/GOB/slice в один пакет, чтобы при потере одного пакета не портились соседние «размазанные» GOB/slice.
3) На уровне кодека — уменьшение размера матриц квантования для уменьшения влияния потерь блоков коэффициентов.
Методы 2 и 3 работают для «блочных» кодеков до H.263, а начиная от H.264, где понятие кадра/GOB заменилось NALU, эти методы становятся неэффективными.
Вот мне и интересно было, может чего автор и напишет по этому поводу.
1) На уровне транспорта потока — это всякие коды исправляющие ошибки (ECC) — Рида-Соломона, БЧХ и прочее.
2) На уровне формирования RTP пакетов — например, кладем каждый фрейм/GOB/slice в один пакет, чтобы при потере одного пакета не портились соседние «размазанные» GOB/slice.
3) На уровне кодека — уменьшение размера матриц квантования для уменьшения влияния потерь блоков коэффициентов.
Методы 2 и 3 работают для «блочных» кодеков до H.263, а начиная от H.264, где понятие кадра/GOB заменилось NALU, эти методы становятся неэффективными.
Вот мне и интересно было, может чего автор и напишет по этому поводу.
Спасибо, хорошая статья. Читал и познавал, так сказать)
Кстати, при показе по американскому телевизору оригинальный поток 24 к/с замедляется на тысячную долю, чтоб потом частоты 3:2 совпали с 59.97 разверткой
ой и правда, прочитал между строк…
белка жжот — пара скриншотов, а какая популярность :)
Белка, кстати, кажется из Big Buck Bunny.
А мультфильм рекомендую посмотреть, тем более он бесплатный.
А мультфильм рекомендую посмотреть, тем более он бесплатный.
Открою секрет: 23.976 = 24/1.001, а 29.97 = 30/1.001, то есть в стандарт американского телевещания NTSC заложен делитель 1.001. Соответственно при показе киноленты произойдет совсем небольшое замедление, которое не будет заметно зрителю, но если это музыкальный концерт, то скорость показа настолько критична, что лучше изредка пропускать кадры и опять же зритель ничего не заметит
А причина, по которой ввели этот делитель? Ждал объяснения, а тут БАЦ и оборвалось. Также не очень понял пример с музыкальным концертом — скорость критична, но все равно зритель не заметит?
Справедливо только для американского NTSC?
А причина, по которой ввели этот делитель? Ждал объяснения, а тут БАЦ и оборвалось. Также не очень понял пример с музыкальным концертом — скорость критична, но все равно зритель не заметит?
Справедливо только для американского NTSC?
Насчет причины введения делителя однозначного мнения нет, но наиболее реалистичной кажется то что: в электросети США ровно 60 Гц, а старые телевизоры «моргали» в такт электросети, то частота смены кадров немного снижена для смещения синхронизации по времени. То есть чтобы телевизор не мерцал без конца, а лишь время от времени.
Насчет концерта, то для сохранения скорости выбрасывается часть кадров, но происходит это редко и зритель ничего не замечает.
С европейским PAL все намного хуже, фильмы ускоряют на 4% для европейских DVD. А вот теми же концертами прибегают к болезненным алгоритмам интерполяции частоты кадров. 24 и 25 — уже слишком большая разница, повторы кадров зритель заметит.
Насчет концерта, то для сохранения скорости выбрасывается часть кадров, но происходит это редко и зритель ничего не замечает.
С европейским PAL все намного хуже, фильмы ускоряют на 4% для европейских DVD. А вот теми же концертами прибегают к болезненным алгоритмам интерполяции частоты кадров. 24 и 25 — уже слишком большая разница, повторы кадров зритель заметит.
То есть все фильмы ускоряются на 4%, и этого никто не замечает? А к чему эти ускорения — если давно уже отошли от черезстрочной развертки и CRT кинескопов в сторону прогрессивной и LCD? Просто стандарты?
Да — фильмы тупо ускоряются (почти все или замедляются европейские для американцев). Именно поэтому когда к западным блюреям приделывают русские звуковые дорожки с DVD их приходится перекодировать.
А против стандартов в киноиндустрии не попрешь, это сейчас уже Blu-Ray плееру без разницы какой из стандартов читать (но опять же «из стандартов»), а DVD должны быть совместимы с кинескопными телевизорами.
А против стандартов в киноиндустрии не попрешь, это сейчас уже Blu-Ray плееру без разницы какой из стандартов читать (но опять же «из стандартов»), а DVD должны быть совместимы с кинескопными телевизорами.
А как же тогда можно посмотреть фильмы в оригинальной скорости? А то 4% как то грустно.
Можете ускорить в каком-нибудь плеере. А так вам 4% времени экономили.
Это очень слышно на вот этих двух видео:
www.youtube.com/watch?v=1l3HtodpBlU — оригинал
www.youtube.com/watch?v=9HGkSjLENa4 — русская лицензия(ntsc->pal, ускорение 4%)
www.youtube.com/watch?v=1l3HtodpBlU — оригинал
www.youtube.com/watch?v=9HGkSjLENa4 — русская лицензия(ntsc->pal, ускорение 4%)
а в чём заключается суть PAL или NTSC применительно к цифровому видеопотоку? разве что-то кроме частоты кадров/развёртки имеет значение?
на современном (цифровом) оборудовании (не беря в расчёт ПК) картинка всё-таки воспроизводится «as is» или непременно с преобразованиями?
на современном (цифровом) оборудовании (не беря в расчёт ПК) картинка всё-таки воспроизводится «as is» или непременно с преобразованиями?
PAL и NTSC породили подобные цифровые стандарты.
Ну приводить к 60 fps монитора то придется, все равно преобразование.
Ну приводить к 60 fps монитора то придется, все равно преобразование.
Вообще в ntsc и pal существенно по-разному кодируется изображение именно при радиопередаче, в особенности цвет. В ntsc вообще там очень красивая математика, которая на практике, однако, показала свои проблемы и возникла получили расшифровку nevet the same color.
В цифровом различаются во-первых размеры растра по вертикали (для PAL это 288 или 576 и для NTSC — 240 и 480). Это пришло из радиостандартов: PAL-625 строк, NTSC-525 строк, при этом видимых соответственно 575 и 479, и экран начинается с полу-строки (ну т.е. со строки, которая содержит изображение начиная с середины) и такой же полу-строкой заканчивается.
Во-вторых различается частота кадров: для PAL допустима частота 25, для NTSC — 27.97.
Другие различия уже чисто цифровые: скажем, некоторые типы pulldown не получится сделать в «чужом» стандарте, (типа 3:2, который переводит фильмы 24fps->30fps, и который имеет смысл только для PAL). На самом деле, это даже не ограничение формата, а ограничения логики кодировщика: какой-то определённый pulldown не указывается, а в потоке ставятся флаги: «поле закодировано непосредственно» или «поле является повторением другого поля», в результате чего для 3:2 фактически кодируется 24 кадра в секунду, а «добавление кадров» до 30 происходит непосредственно при распаковке потока.
С появлением HD разница полностью устранена — там нет понятий «PAL» или «NTSC». Стандарты просто описываются названием профиля: разрешение картинки, частота кадров и тип потока (кадры/поля). Разнообразные соотношения сторон, которые были раньше, тоже ушли в небытие: все HD-стандарты — 16:9
В цифровом различаются во-первых размеры растра по вертикали (для PAL это 288 или 576 и для NTSC — 240 и 480). Это пришло из радиостандартов: PAL-625 строк, NTSC-525 строк, при этом видимых соответственно 575 и 479, и экран начинается с полу-строки (ну т.е. со строки, которая содержит изображение начиная с середины) и такой же полу-строкой заканчивается.
Во-вторых различается частота кадров: для PAL допустима частота 25, для NTSC — 27.97.
Другие различия уже чисто цифровые: скажем, некоторые типы pulldown не получится сделать в «чужом» стандарте, (типа 3:2, который переводит фильмы 24fps->30fps, и который имеет смысл только для PAL). На самом деле, это даже не ограничение формата, а ограничения логики кодировщика: какой-то определённый pulldown не указывается, а в потоке ставятся флаги: «поле закодировано непосредственно» или «поле является повторением другого поля», в результате чего для 3:2 фактически кодируется 24 кадра в секунду, а «добавление кадров» до 30 происходит непосредственно при распаковке потока.
С появлением HD разница полностью устранена — там нет понятий «PAL» или «NTSC». Стандарты просто описываются названием профиля: разрешение картинки, частота кадров и тип потока (кадры/поля). Разнообразные соотношения сторон, которые были раньше, тоже ушли в небытие: все HD-стандарты — 16:9
Есть ошибки:
29.97, а не 27.97
3:2 pulldown имеет отношение только к NTSC а не к PAL как вы написали
и пулдаун не всегда делается флагами в потоке, чаще это делают ДО кодирования.
29.97, а не 27.97
3:2 pulldown имеет отношение только к NTSC а не к PAL как вы написали
и пулдаун не всегда делается флагами в потоке, чаще это делают ДО кодирования.
Мда, про 3:2 для PAL — это я просто ошибся, имелось ввиду как раз «не имеет смысла для PAL»
Про «пулдаун до кодирования» — не понял, что не так? Материал вообще смешаный film/video бывает, там половину фильма флаги есть, половину — флагов нет, и как их расставить — задача кодировщика, т.е. они на этапе кодирования расставляются.
Про «пулдаун до кодирования» — не понял, что не так? Материал вообще смешаный film/video бывает, там половину фильма флаги есть, половину — флагов нет, и как их расставить — задача кодировщика, т.е. они на этапе кодирования расставляются.
Не совсем. Есть два случая:
1) Кодируется 29.97 в чересстрочной разверткой и флагами показывается где уже поработал 3:2 pulldown. а где нет. А рендер в тех местах вернет обратно 23.976 и покажет все идеально, а где «чистые» 29.97 уже будет работать деинтерлейсер и качество снизится.
2) Кодируется 23.976, но флагами говорим что надо показать 29.97. Когда-то применялось на DVD.
1) Кодируется 29.97 в чересстрочной разверткой и флагами показывается где уже поработал 3:2 pulldown. а где нет. А рендер в тех местах вернет обратно 23.976 и покажет все идеально, а где «чистые» 29.97 уже будет работать деинтерлейсер и качество снизится.
2) Кодируется 23.976, но флагами говорим что надо показать 29.97. Когда-то применялось на DVD.
Я ни разу не видел проигрывателя, которые бы для «смешанных» видео рисовал бы 23.976 для мест, где были флаги («film») и 29.97 там, где их не было («video»).
По-моему все честно получают 29.97fps-поток, возможно, с повторяющимися полями и его уже стараются показать. Если показывают на экране компа — абсолютно весь поток деинтерлейсится, даже в тех местах, где в принципе изначально это film.
По-моему все честно получают 29.97fps-поток, возможно, с повторяющимися полями и его уже стараются показать. Если показывают на экране компа — абсолютно весь поток деинтерлейсится, даже в тех местах, где в принципе изначально это film.
А я когда заметил, что по телеку фильмы идут с повышенной скоростью, думал что они это делают, для экономии эфирного времени (впихивания больше рекламы). А оно вон как оказывается.
А почему на блюреях, если им уже без разницы, используется 23.976 fps, а не 24?
А почему на блюреях, если им уже без разницы, используется 23.976 fps, а не 24?
Дело не в черезстрочной развёртке, а в том, что у вас экран работает с одной частотой, а видео-поток идёт с другой. Из-за этого разные кадры проводят разное количество времени на экране. В итоге вместо плавной картинки видно дёрганное изображение. Я когда смотрю кино на компе, то у меня reclock ускоряет видео аж до 30 кадров в секунду, потому как дёрганую картинку мне смотреть неприятно.
Частота сети здесь не причем.
30/1.001 был введён при внедрении цвета в NTSC для уменьшения влияния несущей звука на цветовую поднесущую.
30/1.001 был введён при внедрении цвета в NTSC для уменьшения влияния несущей звука на цветовую поднесущую.
выходит, вся эта чехарда с различной частотой кадров — лишь ради совместимости с какой-то древней ЭЛТ техникой? вроде бы уже на цифровое ТВ в США переходят повсеместно, и всё равно…
25 кадров/с в Европе сугубо по той же причине применяется, из-за 50 Гц электросети?
25 кадров/с в Европе сугубо по той же причине применяется, из-за 50 Гц электросети?
Спасибо автору, не знал про цвета, прям глаза открыли :)
Спасибо. Отдельные вещи знал, но кое-что новое подчерпнул, да и вообще здорово увидеть все собранным в одном месте и структурированным.
Насколько я помню, с арифметическим кодированием есть какие-то проблемы с лицензией, поэтому и используется хаффман.
Насколько я помню, с арифметическим кодированием есть какие-то проблемы с лицензией, поэтому и используется хаффман.
Уже нет. Патент истек))
Тогда, видимо, по привычке :)
А давно истек? Может просто еще не успели реализовать?
А давно истек? Может просто еще не успели реализовать?
Когда истекли не знаю. Но все патенты IBM уже истекли, остался только один патент компании Ricoh www.google.com/patents?vid=5272478
Но нынешние реализации его не нарушают.
Но нынешние реализации его не нарушают.
Спасибо, некоторые вещи знал, но далеко не все. Жду продолжения!
Небольшой вопрос по поводу подсчётов, никак не могу сообразить:
В исходных данных у нас мегабиты, а в результате уже гигабайты. Можно небольшой ликбез по переводу этих величин? А то помню со школы, что 1 байт=8 бит, но как тут получилось, никак не соображу =/
1920*1080*24*24 = 1139 Мегабит/с, а если захотим записать 90 минутный фильм, то потребуется 90*60*1139 = 750 Гигабайт!
В исходных данных у нас мегабиты, а в результате уже гигабайты. Можно небольшой ликбез по переводу этих величин? А то помню со школы, что 1 байт=8 бит, но как тут получилось, никак не соображу =/
Спасибо, неплохая статья. Напишите ещё про анаморфный пиксель и переменную частоту кадров.
Про анаморфный пиксель ничего особо интересного нет: прямоугольный он и в африке прямоугольный, кодек это не волнует, это уже забота устройства отображения.
Переменная частота кадров — зло. Но она полезна в системах видеонаблюдения. Кодек тоже не сильно частота кадров беспокоит, а вот рендеру с ней работать тяжело. Смысл в том что стоит камера, снимает в ночное время, снимает еще и шумы, а они меняются с течением времени, а других изменений нет => нет и смысла хранить кадры в которых только меняется шум, лишь будут место занимать.
Переменная частота кадров — зло. Но она полезна в системах видеонаблюдения. Кодек тоже не сильно частота кадров беспокоит, а вот рендеру с ней работать тяжело. Смысл в том что стоит камера, снимает в ночное время, снимает еще и шумы, а они меняются с течением времени, а других изменений нет => нет и смысла хранить кадры в которых только меняется шум, лишь будут место занимать.
У нас в университете как раз был курс лекций по обработке видеосигналов, который читал Красильников Н.Н., один из прорадителей цифрового телевидения у нас. За статью спасибо, вспомнил былые годы…
acmer, вот подскажи. какие проги для конвертации умеют жать с 23.976 до 25 путем убыстрения видео? нашел в procoder'e фильтр pulldown, но сам прокодер очень медленно жмёт. Хотелось бы знать, какие галки в xilisoft video cobverter или mediacoder поставить надо. спс
Во-первых и в основных — зачем это вам частоту кадров менять? Это совершенно ненормальная задача, могла бы возникнуть только при редактировании видео, а при просмотре вообще-то совершенно пофигу, какая там частота кадров.
То есть, если вы просто поменять её хотите, ничего перекодировать не надо — надо взять и поменять флаг, указывающий на частоту кадров. Это можно сделать в проге ReStream, если речь о MPEG-файле или же в VirtualDubе, если речь об AVI. Для других форматов можно попробовать тот же VirtualDub, если он сможет, или virtualdubmod.
В любом случае, придётся самостоятельно чуть ускорить звук и подменить дорожку.
Да, и фильтр pulldown скорее всего делает совершенно другое. Он либо просто ставит периодически флажки в выходном файле, чтобы декодер показывал некоторые поля по два раза (так кодируется 24 кадра в сек, а показывается 30), либо он ещё перед этим сканирует поток, находит одинаковые поля и уже ставит флажки в зависимости от найденного (применяется для смешанного материала film/video, когда идёт то фильм-материал, для которого имеет смысл pulldown, то видео-материал, для которого pulldown смысла не имеет).
То есть, если вы просто поменять её хотите, ничего перекодировать не надо — надо взять и поменять флаг, указывающий на частоту кадров. Это можно сделать в проге ReStream, если речь о MPEG-файле или же в VirtualDubе, если речь об AVI. Для других форматов можно попробовать тот же VirtualDub, если он сможет, или virtualdubmod.
В любом случае, придётся самостоятельно чуть ускорить звук и подменить дорожку.
Да, и фильтр pulldown скорее всего делает совершенно другое. Он либо просто ставит периодически флажки в выходном файле, чтобы декодер показывал некоторые поля по два раза (так кодируется 24 кадра в сек, а показывается 30), либо он ещё перед этим сканирует поток, находит одинаковые поля и уже ставит флажки в зависимости от найденного (применяется для смешанного материала film/video, когда идёт то фильм-материал, для которого имеет смысл pulldown, то видео-материал, для которого pulldown смысла не имеет).
тут дело такое. у меня железка видит исключительно mpeg2 pal и никак иначе. приходиться всякие сериалы кодить с mpeg4 23.976.
Ну, вам не повезло с железкой :(
Но тут в любом случае перекодировать… Только вот автомат с ходу назвать затруднюсь. Точно могу сказать, что никакой pulldown не нужен.
Я кодировал видео для DVD при помощи HCenc или CinemaCraft Encoder SP. Это не самый тривиальный подход, но кодировщики эти очень быстрые.
HCenc бесплатный, но от вас потребуется AviSynth — он видео умеет брать только из него.
Звуковую дорожку готовить так: распаковать, ускорить в любом редакторе (хоть audacity) в 25*1.001/24 = 1.042708(3) раза и запаковать в mpeg1 layer2 (при помощи twolame) либо в ac3 (при помощи besweet, например).
Потом муксером собрать видео и аудио в програмный поток.
Но тут в любом случае перекодировать… Только вот автомат с ходу назвать затруднюсь. Точно могу сказать, что никакой pulldown не нужен.
Я кодировал видео для DVD при помощи HCenc или CinemaCraft Encoder SP. Это не самый тривиальный подход, но кодировщики эти очень быстрые.
HCenc бесплатный, но от вас потребуется AviSynth — он видео умеет брать только из него.
Звуковую дорожку готовить так: распаковать, ускорить в любом редакторе (хоть audacity) в 25*1.001/24 = 1.042708(3) раза и запаковать в mpeg1 layer2 (при помощи twolame) либо в ac3 (при помощи besweet, например).
Потом муксером собрать видео и аудио в програмный поток.
эх. радикально. а на какие контрольные фразы обращать внимание, копаясь в настройках «автоматов» нужно? pulldown отмели, как я понял.
Вы DVD-подобный (совместимый) поток хотите в итоге сделать, или железка играет любой pal mpeg2?
В общем, для PAL DVD — делайте размер картинки 720x576, ограничивайте битрейт видео 9800kbps (и на звук надо оставить, чтобы в сумме было не более 10000kbps); ещё нужно выставить правильное соотношение сторон картинки, на DVD допустимы 4:3 и 16:9. Вообще, часто есть пресет «DVD» — выбирайте его и не морочьте себе голову.
так при таком раскладе получаются рывки, раз в секунду, т.к. 25-23.976 — в это время кодер вставляет предыдущий кадр, насколько я понимаю. вот и хочется убыстрить все видео, чтобы оно было без рывков.
В общем, я боюсь, для такой задачи готового автомата нет. Ваш вот автомат — больно умный, кадры вставляет. Да и звук вам по-любому отдельно обрабатывать.
Если исходные файлы — avi, наиболее простой будет такая последовательность действий:
VirtualDubом открываем файл, делаем Audio->Save WAV.
Этот WAV подправляем в редакторе, ускоряем. Кстати, звук должен быть в итоге 48000 Гц для DVD.
в VirtualDubе ставим «брать звук из WAV», а в Video — меняем частоту кадров на 25 и ставим direct stream copy, после чего сохраняем всё как avi — это будет промежуточный файл.
Его уже скармливаем вашему автомату.
Если исходные файлы — avi, наиболее простой будет такая последовательность действий:
VirtualDubом открываем файл, делаем Audio->Save WAV.
Этот WAV подправляем в редакторе, ускоряем. Кстати, звук должен быть в итоге 48000 Гц для DVD.
в VirtualDubе ставим «брать звук из WAV», а в Video — меняем частоту кадров на 25 и ставим direct stream copy, после чего сохраняем всё как avi — это будет промежуточный файл.
Его уже скармливаем вашему автомату.
1920*1080*24*24*5400/8 = 806 215 680 000 байт ~ 750ГБ
Когда-то давно меня занимала мысль реализовать видеокодек путем разложения каждой линии кадра в ряд Фурье с сохранением коэффициентов гармоник. Смысл примерно тот же как и в стандартных кодеках — соседние кадры как правило очень похоже и сохранять можно изменяющиеся коэффициенты гармоник.
Но индустрия и без меня справилась и умудряется запихнуть 1080р фильм в 10-15 ГБ!
Хотя я бы с удовольствием почитал про предложенный метод, если его кто-то пытался делать.
Автору топика известны работы в этой области?
Но индустрия и без меня справилась и умудряется запихнуть 1080р фильм в 10-15 ГБ!
Хотя я бы с удовольствием почитал про предложенный метод, если его кто-то пытался делать.
Автору топика известны работы в этой области?
> Хотя я бы с удовольствием почитал про предложенный метод, если его кто-то пытался делать.
> Автору топика известны работы в этой области?
ШТО? Поставим вопрос так: кто из разработчиков всех действующих кодеков НЕ проводил работы в этой области?
> Автору топика известны работы в этой области?
ШТО? Поставим вопрос так: кто из разработчиков всех действующих кодеков НЕ проводил работы в этой области?
Эта область сейчас занята немного другими делами, я именно — 3D
Поэтому и проект интела по применению вейвлетов (про них я знаю очень мало) к видео почти не движется. H.264 очень хорошо справляется с поставленной задачей, но с 3D пока у него проблемы.
А приведенный в статье метод (естественно более сложный) реализован в XviD
Поэтому и проект интела по применению вейвлетов (про них я знаю очень мало) к видео почти не движется. H.264 очень хорошо справляется с поставленной задачей, но с 3D пока у него проблемы.
А приведенный в статье метод (естественно более сложный) реализован в XviD
Вау, очень познавательно )
Хоть и болван в математике, но общая теория очень понравилась.
Жду продолжение, спасибо
Хоть и болван в математике, но общая теория очень понравилась.
Жду продолжение, спасибо
О! Отличная тема! Автор, подскажите пожалуйста, а если бы я допустим хотел провести тесты разных кодеков по сжатию видео, как лучше всего посчитать (автоматически) уровень потерь качества? не отсматривать же вручную десятки видеороликов. Мне пока в голову приходит только брать какие-то кадры и посчитать сумму разностей между пикселями на них.
И есть ли где-то сравнительные таблицы кодеков, каким лучше сжимать, каким хуже?
И есть ли где-то сравнительные таблицы кодеков, каким лучше сжимать, каким хуже?
Надо использовать compression.ru/video/quality_measure/video_measurement_tool_en.html
compression.ru/video/codec_comparison/h264_2010/
Сравнение делали в МГУ.
Сравнение делали в МГУ.
У вас лицензия в статьях в Википедии кривая. Почему вы передаёте в PD кадры из cc-by-sa произведения?
Во-первых, вам не следует писать «собственная работа», а следует писать «производное от title, copyright by someone, original license cc-by-sa»
Во-вторых, саму лицензию следует выбрать из семейства cc.
Во-первых, вам не следует писать «собственная работа», а следует писать «производное от title, copyright by someone, original license cc-by-sa»
Во-вторых, саму лицензию следует выбрать из семейства cc.
Пусть с этим разбираются патрулирующие википедию, они лицензии лучше знают. Мне они претензии не предъявляли, хотя статья проверена.
Неправильный подход. «Пускай с этим разбирается редактор и корректор» — это можно сказать в обычном издании. В Википедии с большой вероятностью просто удалят вашу картинку из-за нарушений cc-by-sa лицензии оригинала. То есть сначала там повесят табличку о несоответствии лицензии, напишут вам, а потом удалят.
Кстати, в самой статье у вас стиль довольно сильно хромает.
Кстати, в самой статье у вас стиль довольно сильно хромает.
в этой серии было бы ещё уместно рассказать о структуре самих потоков, форматов контейнеров,
принципиальных различиях ts/ps, с выбором которых всем приходится сталкиваться в первую очередь.
принципиальных различиях ts/ps, с выбором которых всем приходится сталкиваться в первую очередь.
Очень интересно. Пожалуйста, пожалуйста: продолжение!
RGB -> YUV
Теперь понятно почему черно-белое (монохромное) видео при кодировании не занимает меньше места.
Не могу понять почему этот пост от января на главной странице в марте
Мы сделали виджет LiteVideo на NodeJs позволяющий работать с нашим оптимизатором видео
если интересно посмотреть можно тут
litevideo.7rtv.com/
если интересно посмотреть можно тут
litevideo.7rtv.com/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про сжатие видео — Введение