Компания GoPro открыла (https://gopro.com/news/gopro-open-sources-the-cineform-codec) исходные тексты реализации видеокодека CineForm, применяемого в профессиональном оборудовании для видеосъемки. Исходные тексты CineForm SDK (https://gopro.github.io/cineform-sdk/) опубликованы (https://github.com/gopro/cineform-sdk) на gitHub под двумя лицензиями: Apache 2.0 и MIT. Кодек теперь можно свободно интегрировать в любые продукты без оплаты отчислений и расширять его функциональность, например, добавлять поддержку новых форматов изображений или вносить оптимизации. В ближайшее время ожидается интеграция CineForm в открытые видеопроигрыватели и пакеты перекодирования видео, без необходимости связывания с проприетарными бинарными библиотеками.CineForm предлагает 12-разрядный формат сжатия видео с использованием вейвлет-преобразования (https://ru.wikipedia.org/wiki/%D0%94%D0%.... Кроме полноценной реализации кодировщика и декдировщика, а также демонстраций для встраивания CineForm в приложения, в репозитории также опубликован код упрощённого варианта (WaveletDemo), который может применяться для изучения применения вейвлетов для сжатия видео или как отправная точка для создания новых кодеков. Реализация написана на языках C и C++ и включает ручные оптимизации с использованием инструкций SSE2. Работа SDK проверена в Linux (Ubuntu), Windows и macOS.
Кодек CineForm примечателен тем, что спроектирован для обеспечения высокой скорости кодирования и качества видео, в ущерб результирующему размеру (выбирая из набора "размер, скорость и качество", как правило, остальные кодеки отдают предпочтение связке "размер и качество", жертвуя скоростью кодирования). Высокая скорость кодирования и высокое качество позволило CineForm занять нишу первичного формата для сохранения материалов с видеокамер и для профессиональной обработки и монтажа видео.
Ближайшими конкурентами являются кодеки Avid DNxHD и Apple ProRES, которые, основаны на методе разбиения изображения на блоки с использованием дискретного косинусного преобразования (https://ru.wikipedia.org/wiki/%D0%94%D0%... (DCT), в то время как технология сжатия на основе вейвлетов оперирует изображением как единым целым, позволяя добиться более высокого визуального качества и сделать менее заметными артефакты при высоком уровне сжатия. Благодаря вейвлет-преобразованию, с ростом разрешений возрастает и эффективность работы CineForm. Особое место CineForm также занимает системах трансляции видео в режиме 360° (например, в камере Omni (https://shop.gopro.com/Marketing/virtualreality/) с работой в разрешениях 8Kp30 и 60Kp60 справляется только CineForm).
Кодек поддерживает работу с пиксельными форматами 8/10/16-bit YUV 4:2:2 (прогрессивное и чересстрочное кодирование), 8/10/16-bit RGB 4:4:4, 8/16-bit RGBA 4:4:4:4 и 12/16-bit CFA Bayer RAW. Для любого формата может применяться двухканальное кодирование для стереоскопического, 3D и 360°-контента с разрешением выше 4K. Без потери качества кодек оперирует уровнем сжатия в диапазоне между 10:1 и 4:1 - CineForm работает в режиме обеспечения постоянного качества, меняя битрейт в зависимости от типов сцен (большинство других кодеков удерживают битрейт, допуская изменение качества).URL: http://cineform.blogspot.ru/2017/10/cineform-goes-open-sourc...
Новость: http://www.opennet.ru/opennews/art.shtml?num=47452
Открытие исходных текстов это хорошо, но как там со связанными с кодеком патентами?
Чукча не читатель?
Ты про
>> Кодек теперь можно свободно интегрировать в любые продукты без оплаты отчислений?
А это прописано в лицензиях? Или ты из тех кто путает лицензии и патенты?
Apache 2.0 - конечно, прописано
ну да, ну да - через полтора года после того, как индус из ffmpeg добавил вполне работающую поддержку именно гoвнопро-версии этого кодека (понадобился reverse-engineering, в лучших традициях Белларда, ибо заявленному стандарту vc5 он соответствовал слабо), и она, видимо, уже попала в стабильные версии и во все ffmpeg-based проекты, они героически открыли свой ненужно-код.А что их до этого десять лет, блжад, уговаривали дать не код но хоть спецификации (без всяких патентных кунштюков, ffmpeg и без того запрещено использовать где-либо кроме антарктиды) - это так, цветочки.
Лучше поздно, чем никогда. Кодек то очень неплохой.
> Лучше поздно, чем никогда. Кодек то очень неплохой.и зачем он тебе нужен? У тебя есть какой-то исходный hd материал не в mp4/avchd формате ? Или у тебя настолько кривой софт монтажа и настолько дряхлое железо, что нужно трахаться с перекодировкой в слабо-сжатый формат только для этого?
единственное, зачем был большинству нужен этот формат - обрабатывать промежуточные файлы от gopro, для тех, кто с ней еще мучается.
с этим сегодня справляется ffmpeg без дополнительных деталей. encoder в него вообще низачем не нужен.
>>encoder в него вообще низачем не нужен.В dvr нужен, если меньше нагружает проц чем 264
> В dvr нужен, если меньше нагружает проц чем 264dvr-ы все на железе жмут.
У меня весь материал не в mp4/avchd. Даже не знаю где такой можно найти. У меня в основом ProRes, redcode, реже arriraw или dnxhd. Если материал изначально не пожат в prores или dnxhd, его вполне можно перегнать в cineform и работать с ним дальше в ffmpeg'е. Конечно с таким же успехом это можно сделать (сейчас я так и делаю) в ProRes, но все три реализации prores имеют свои косяки по скорости вывода, степени сжатия и работе с метаданными. Обработанным в ffmpeg prores'а нельзя, например, делать конформ, ибо метаданные для этого не прописаны.
> У меня весь материал не в mp4/avchd. Даже не знаю где такойаццкий ад. Ты где это взял - с dvb упер?
> можно найти. У меня в основом ProRes, redcode, реже arriraw или
> dnxhdне, не с dvb. иппонская порнуха, короче?
Я уверен, ее еще перевыпустят в чем-нибудь читаемом. То что существует только в cfhd - не перевыпустят, смысл в этом. "for they are hard to come by"
Это материал с площадки, с плейбека или прямо с камер. Собственно для такого типа материала и предназначен сабж.Я не понимаю, если не разбираешься и не понимаешь, зачем засорять мусором тему.
> Я не понимаю, если не разбираешься и не понимаешья, собственно, просто заинтересовался, откуда вообще у тебя эти форматы берутся.
сабж, к сожалению, не для этого. Ну, в смысле если читать его целиком, начиная с первого слова. У gopro вполне специфическая технология его использования (привет из древних времен, когда компьютеры были больш...тормозные), и вряд ли их кодек будет хорошо работать для чего-то еще. (хотя, он, в общем-то, не совсем их, шансы на полезные применения, действительно, есть)
К сожалению компьютеры и так тормозные сейчас. Стандартное видео с площадки 2k10bit 422, чисто по месту занимает офигенные массивы, за один сьемочный может уходить 4ТБ диск, а если это один из raw-форматов и того больше. Потом это надо смонтрировать, а главное, покрасить.Для большинства контента redcode или arriraw избыточны, все равно выход, это обычный кинозал с 2K проектором или телек, куда уходит (в наших широтах) 422 10bit 1080i50. Поэтому есть смысл использовать гораздо более экономные по месту и затрете ресурсов форматы типа ProRes. Монтажер зачастую вообще работает с ProRes proxy, потом на цветокоре проводят конформ и подтягивают оригиналы.
Поэтому бывают совершенно разные сценарии работы. Вот на последнем проекте (клип), все снимали в redcode, с редкода перегнали в prores proxy, монтажер собрал, таймлайн отправили в davinci и подтянули оригиалиные raw, которые потом покрасили.
На проекте до этого все сгонали сразу в prores hq, потому что так дешевле по хранению и часть материала необходимо было дополнительно обработать в ffmpeg (в основном фильтр minterpolate для некоторых сцен).
С GoPro всегда было очень много проблем, особенно на цветокоре. Тот материал, который можно было получать из них ранее, по сути, ужасно пережатое видео (420, 8 бит), которое очень трудно адекватно встроить в собранный материал.
А в итоге готовый продук конвертируется в:
* для киношки — DCP 2k/4k p24 (по сути loseless jpeg2000 в контейнере mxf)
* для телека — MXF Operational Pattern 1a (MPEG-2 по сути) 1080i50 (тут еще надо не забыть о том, что из-за конверсии частоты кадров 24p->25p->50i теряется хронометраж)
* h264/h265 — для интернетаНикакие cineform, prores или dxnhd к конечному пользователю никогда не попадают. Их цель быть чем-то средним между raw/uncompresed исходниками и выходным материалом для кастеров.
> С GoPro всегда было очень много проблем, особенно на цветокоре. Тот материал,
> который можно было получать из них ранее, по сути, ужасно пережатое
> видео (420, 8 бит), которое очень трудно адекватно встроить в собранный
> материал.Разве если половина планов ими и отснята, как бывало у друзей в Дамаске... спасибо за изложение, познавательно.
> К сожалению компьютеры и так тормозные сейчас.ну если именно с профессиональных железок видео обрабатывать, то да.
а у гоупры нынче "move to your phone and automatically transform into an awesome video".
Поэтому, возможно, они и выкинули кодек в опенсорс - им самим он стал без надобности.что вы хотите от компании, у которой три года как даже технических характеристик продукта толком нет на сайте, одна маркетоидная шелуха?
А с тем что у них было раньше, современные (им) компьютеры и так бы справлялись, этап перекодирования в общем-то был лишним.
> Их цель быть чем-то средним между raw/uncompresed исходниками и выходным материалом для
> кастеров.так у gopro-то не было raw, в том и дело - свой кодек они использовали не для этого, а как промежуточный формат на этапе монтажа - между mp4 из камеры и тем же mp4 для вываливания в ютуб.
Так что фиг его знает, будет ли с него толк при попытке использовать его другими способами и для других материалов.
jpeg2000 +/- = CineForm, разве не?
Как минимум нет, только из-за скорости рендеринга. И что сравнивать jpeg2000 loseless или lossy? В любом случае CineForm в раз 10 быстрее в энкодинге.
>У тебя есть какой-то исходный hd материал не в mp4/avchd формате ?Э... А поток с бытовой видеокамеры через HDMI на HDMI-input плату видеозахвата подойдет как пример?
>>У тебя есть какой-то исходный hd материал не в mp4/avchd формате ?
> Э... А поток с бытовой видеокамеры через HDMI на HDMI-input плату видеозахватано зачем?
> подойдет как пример?
чего-то очень странного - подойдет ;-) сочетание "бытовой видеокамеры" с hdmi-платой видеозахвата впечатляет. Боюсь представить, как выглядит "быт".
> чего-то очень странного - подойдет ;-) сочетание "бытовой видеокамеры" с hdmi-платой видеозахвата
> впечатляет. Боюсь представить, как выглядит "быт".Развитие Web камер остановилось лет семь назад на Лоджитеке 910, а скорости домашнего Интернета изрядно выросли.
Есть желание транслировать качественную картинку, первое что приходит в голову это хороший бытовой камкодер и HDMI плата видеозахвата.
Буду благодарен если посоветуете другие варианты.
Про использование DSLR в качестве Web камеры знаю, но там свои проблемы.
> (без всяких патентных кунштюков, ffmpeg и без того запрещено использовать
> где-либо кроме антарктиды)Да ладно, у нас он штатно в репозитории без всяких дискриминаций вроде non-us.
>> (без всяких патентных кунштюков, ffmpeg и без того запрещено использовать
>> где-либо кроме антарктиды)
> Да ладно, у нас он штатно в репозитории без всяких дискриминаций вроде
> non-us.там раньше (современных я давно нечитатель) в сопроводиловке немножко раскрывалась тема.
Смысл в том, что там мильен патентованных кодеков, и одна из идей Фабриса была как раз - наглядно показать что эти патенты гроша ломанного не стоят, поскольку это просто параметры обычного mpeg.
> Смысл в том, что там мильен патентованных кодеков, и одна из идей
> Фабриса была как раз - наглядно показать что эти патенты гроша
> ломанного не стоят, поскольку это просто параметры обычного mpeg.Спасибо.
Подозреваю, что индус осилил только декодер.
Кто пробовал, оно сильнее жмёт, чем DV, или слабее?
Интересует оцифровка архивов с VHS с минимальными потерями на первичном сжатии.
Контент соответствующий - характерный шум, артефакты.
> Кто пробовал, оно сильнее жмёт, чем DV, или слабее?оно жмет в зависимости от настроек, это не dv, где параметры гвоздиком прибиты.
> Интересует оцифровка архивов с VHS с минимальными потерями на первичном сжатии.
если оно очень-очень дорого твоему сердцу - используй mjpeg с низким уровнем сжатия. Надеюсь, у тебя есть чем его получить из аналогового сигнала.
Во всех остальных случаях не трать время, mp4/webm твое все. "качество" vhs картинки с почтовую марку после оцифровки непойми-чем и деинтерлейсинга все равно нулевое - никакого существенного ущерба ему сжатие не нанесет. Ну либо "dv", если я правильно понимаю, что ты имеешь в виду тупо подключить еще живую dv-камеру к еще живому древнему магнитофону и просто списать через нее в ее native-формате. Так просто меньше возни.CFHD придуман совершенно не для такого материала, буковки хе де как бы нам на это намекают.
При этом гарантированно работающий энкодер есть только у gopro, и это ни разу не то что они вывалили в опенсорсе.
mjpeg "квадратит". dv нет. вейвлеты не должны ведь тоже?
> mjpeg "квадратит""квадратит" сэмплинг. В dv он точно такой же, и тот же самый DCT для макроблоков - просто степень сжатия выбрана небольшая (зато цветовое никак не регулируется, а из некоторых mjpeg плат можно было достать 4:2:2... правда, потом эти файлы ничем не открываются ;-)
вейвлеты не должны, но в cfhd вейвлетам скармливаются все те же макроблоки, насколько я понимаю, а значит, если постараться, их границы могут стать видимыми.
> "квадратит" сэмплинг.Квадратят блоки, чудак. И тот факт что блоки кодируются независимо. Поэтому у одного блока цвет границ такой, а у другого - другой, кодек при кодировании оптимизировал макроблок но не парился совпадет ли декодированное с соседями. В результате границы блоков при достаточной степени сжатия становятся заметны. Потому что разный цвет.
Сильные кодеки по этому поводу регламентируют loop filter по границам блоков при декодировании. Для слабых кодеков формально не требуется но плееры могут делать "постпроцессинг" опционально. Аналогично на слабом проце для h.264 на loop filter можно забить.
А что до вэйвлетов, они могут получше DCT работать на некоторых типичных "фичах" картинок. Видимость границ будет зависеть от совпадения цвета границ блоков. Энкодер мог бы попытаться кодировать так чтобы отличия границ были бы минимальными, но это наверное тормознет кодирование.
> правда, потом эти файлы ничем не открываются ;-)
Ffmpeg наверное прожует. Я им даже какой-то амижный, чтоли, формат картинок который в диком виде сейчас почти не встречается в png перегонял. Попался исторический материалец, конца 90-х, аж с BBS. Вьюшки не понимают. Ну я и отдал это ffmpeg на удачу. Мигом получил png'шки.
> Квадратят блокиты собираешься сэмплинг делать не поблочный,а чохом картинку? Ну, все в принципе, здорово (как раз вейвлетное преобразование отлично работает в варианте 320x200, а больше для "VHS" не надо) - только вот как ты тут собрался transform обнаружить и закодировать?
А если нет - тогда это mpng какой-то получаетсо, с соответствующими затратами на кодирование и размером на выходе.> И тот факт что блоки кодируются независимо.
это вынужденная мера - для transform. для mjpeg ты размер блока можешь произвольно выбрать (правда, опять же, ничем не прочитается, ну и хрен с ним), у него траснформа нету.
квадратики, они не (только) от этого (на фото-jpeg'ах никаких квадратиков нет, обычное ровное мыло)
> А что до вэйвлетов, они могут получше DCT работать на некоторых типичных "фичах"
> картинок.мне что-то подсказывает, что на зашумленных аналоговым мусором картинках оно плохо работает.
> Энкодер мог бы попытаться кодировать так чтобы отличия границ были бы минимальными, но
> это наверное тормознет кодирование.для cfhd это пофигу, он не рилтаймовый по задумке. Но проблема в том, что он по задумке работает с уже разок закодированным блочным transform-кодеком, поэтому вроде бы не за что и бороться.
> Ffmpeg наверное прожует
он им мои mjpeg'и (4:2:0, но, видимо, что-то не так с avi header) не жует, падает с sigsegv. до примерно 2010го года жевал, а потом что-то "оптимизировали". Файлы, как ты понимаешь, сильно старше и ни разу не менялись. Да, vhc. Нет, это нельзя съездить и переснять, этого места больше нет.
> ты собираешься сэмплинг делать не поблочный,а чохом картинку?Поблочно, но учитывая существование соседей.
> Ну, все в принципе, здорово (как раз вейвлетное преобразование отлично работает
> в варианте 320x200, а больше для "VHS" не надо)Оно не только там нормально работает, Dirac британские броадкастеры делали для качественного HD и выше, под броадкастерские нужды. Но сейчас все хотят лить видео через инет, надо хорошую картинку при минимальном битрейте. Там Dirac звезд не хватает, больше всего работ в этом направлении досталось VP9. Ну и AV1 по наследству.
Кстати в Daala придумали фокус с блоками, lapped transform сделан так что блочность не образуется. Скрины с злой степенью сжатия очень убедительные.
> - только вот как ты тут собрался transform обнаружить и закодировать?
В смысле - обнаружить? Блок обычно кодируют пытаясь минимизировать размер закодированного при минимуме отличий от оригинала, если время позволяет. Детали выбранной конкретики transform кодер передает декодеру в битовом потоке. Я к тому что при кодировании блока можно попытаться целенаправленно минимизировать различия по границам с соседями, как дополнительный критерий. Но может подраться с минимизацией размера. Lapped transform выглядит логичнее - лучше результат и не выглядит как костыль.
> А если нет - тогда это mpng какой-то получаетсо, с соответствующими затратами
> на кодирование и размером на выходе.По ощущениям это прапрадедушка идей lapped transform-а, только кривее. Я не Монти :)
> это вынужденная мера - для transform. для mjpeg ты размер блока можешь
> произвольно выбрать (правда, опять же, ничем не прочитается, ну и хрен
> с ним), у него траснформа нету.Радость от произвольного размера блока умеренная. Позволяет лучше адаптироваться к характеру картинки, но лишь до некоторых пределов.
> квадратики, они не (только) от этого (на фото-jpeg'ах никаких квадратиков нет, обычное
> ровное мыло)Мыло оно наверное только если вьюшка сделала постпроцессинг. Иначе это скорее "ступеньки". И прочий ringing на резких границах.
> мне что-то подсказывает, что на зашумленных аналоговым мусором картинках оно плохо работает.
Шум и DCT карму портит. Высокачастотная составляющая, случайная. И на нее или придется извести море битов для правдоподобного кодирования, или сильно смешается с остальным, все испортится и получится характерная жуть. Я не возьмусь убрать сильный шум из фото если по нему jpeg-ом прошлись. В видео можно потрепыхаться третьим измерением.
> том, что он по задумке работает с уже разок закодированным блочным
> transform-кодеком, поэтому вроде бы не за что и бороться.Если до нас уже был кодек - пусть декодер делает loop filter, чтоли. Без этого есть шанс что границы блоков не состыкуются, поскольку decision making кодека может не совпасть. Кодировать чужой артефакт как фичу картинки явно фэйловая идея. Надо море битов извести чтобы сохранить... артефакт?! Кодек же не знает что это не фича картинки. А так то картинка лучше чем была не станет, кто бы сомневался.
> header) не жует, падает с sigsegv. до примерно 2010го года жевал,
> а потом что-то "оптимизировали".Если бы это было у меня, я бы глянул gdb'ом что там да и пнул причастных. Дел на 10 минут.
> Файлы, как ты понимаешь, сильно старше и ни разу не менялись. Да, vhc.
> Нет, это нельзя съездить и переснять, этого места больше нет.Да я понимаю. У меня тоже есть ряд таких цифровых артефактов, которые хрен переснимешь, но все-таки в более разумных форматах.
DV это же примитивный M-JPEG. Любой кодек жмет сильнее.>>Интересует оцифровка архивов с VHS с минимальными потерями на первичном сжатии.
AVID лучше если для монтажа, потом ренедерить в mp4.
> DV это же примитивный M-JPEG. Любой кодек жмет сильнее.ему не надо сильнее ,ему надо с минимумом потерь.
> AVID лучше если для монтажа, потом ренедерить в mp4.
современным монтажкам похрен.
> Интересует оцифровка архивов с VHS с минимальными потерями на первичном сжатии.Для таких целей есть losless-кодеки, например HuffYUV, но для оцифровки VHS вполне хватит и MotionJPEG
> Для таких целей есть losless-кодеки, например HuffYUV, но для оцифровки VHS вполнеему не светит loosless - ему надо _аналоговый_ сигнал как-то превратить в цифровой.
в _любом_ случае будут потери сэмплинга.> хватит и MotionJPEG
если он найдет плату 80х годов, способную преобразовывать композит или s-video в mjpeg - это неплохой вариант, в остальных случаях лучше оставить в том, в чем получилось. Например, таки в dv, камеру со сквозным трактом найти еще можно.
есть карта из 90х, способная отдавать raw поток, а потом жми чем хочешь.камеры, увы, нет.
> есть карта из 90х, способная отдавать raw потокони, обычно, фиговые.
Запиши raw, в конце-концов, что оно там у тебя отдает, YUV (вряд ли что другое)?
Пожмешь xz, сойдет для сельской местности, и потерь помимо АЦПшных не будет, и прочитать это, каким-нибудь mpeg-tool'ами тех же 90х всегда будет можно.
> Пожмешь xz, сойдет для сельской местности,Но какой-нибудь специализированный huffyuv и ему подобные может оказаться и быстрее и лучше.
> и прочитать это, каким-нибудь mpeg-tool'ами тех же 90х всегда будет можно.
Ffmpeg'ом. Он на раз жует raw yuv и прочие вещи. Только вот большинство инкарнаций yuv изначально lossy, весь смысл yuv был в уменьшении бандвиза относительно RGB и при том - ценой загрубления представления u и v составляющих. Из-за этого yuv изначально грохает много информации о цвете пикселей.
> Ffmpeg'ом. Он на раз жует raw yuv и прочие вещи. Только вотон у меня сдох на банальном mjpeg'е. Как раз с карты 90х годов.
> большинство инкарнаций yuv изначально lossy, весь смысл yuv был в уменьшении
> бандвиза относительно RGB и при том - ценой загрубления представления uоно и так уже никакое, это vhs, там цвета не только "примерные", но еще и попадают мимо контуров. Не о чем плакать.
Возможно, в XXII веке появятся алгоритмы, вгоняющие цветовые пятна обратно в яркостные контуры. Пока я ничего похожего не видел. Наверное нынешнее поколение должно сдохнуть, чтобы следующее или еще более следующее заинтересовалось видеоматериалами предков.
> он у меня сдох на банальном mjpeg'е.Видимо как раз был не банальный а какой-то экзотический субдиалект с необычным сочетанием параметров.
> Как раз с карты 90х годов.
(о котором все давно забыли)
> оно и так уже никакое, это vhs, там цвета не только "примерные",
> но еще и попадают мимо контуров. Не о чем плакать.Понятно, vhs это vhs.
> Возможно, в XXII веке появятся алгоритмы, вгоняющие цветовые пятна обратно в яркостные
> контуры. Пока я ничего похожего не видел. Наверное нынешнее поколение должно
> сдохнуть, чтобы следующее или еще более следующее заинтересовалось видеоматериалами предков.Черт его знает. Могу предположить что материалов с такими проблемами в цифровом формате просто мало, а обработка сложная. Их и не в цифровом формате мало, потому что в те времена камеры были пижонством и стоили кучу денег. К тому же они были громоздкие и неудобные. В результате народ вообще генерил мало видеоматериала. Это сейчас вынул из кармана смарт, нажал кнопку и вот тебе мегазы видео. А в эпоху vhs съемка видео была чуть ли не целым событием.
> Черт его знает. Могу предположить что материалов с такими проблемами в цифровом формате
> просто мало, а обработка сложная. Их и не в цифровом формате мало, потому что в те
> времена камеры были пижонством и стоили кучу денег.зато и количество видео "я и мой салатик" было существенно меньшим - камеру чаще использовали для событий, которые стоило сохранить. И уж тем более мало трэша, прошедшего следующий фильтр - "а ну-ка потрахайся это теперь оцифровать".
> зато и количество видео "я и мой салатик" было существенно меньшим -Мало кто с VHS камерой захочет в парашюте бултыхаться. И туториал по вышивке так снимать никто не станет. А кому-то и салатик поинтереснее чем твои "мегасобытия".
> ему не светит loosless - ему надо _аналоговый_ сигнал как-то превратить в цифровой.С этим справится любой АЦП. Простейший пример - TV-тюнер или плата видеозахвата. Подключаем к ней видео-магнитофон, на выходе карта отдает несжатый поток, который по желанию можно пожать любым имеющимся кодеком.
И при чем тут платы 80-х годов? Любая карта на каком-нибудь SAA7134 оцифрует сигнал, а чем его жать, забота ПО.
>> ему не светит loosless - ему надо _аналоговый_ сигнал как-то превратить в цифровой.
> С этим справится любой АЦП. Простейший пример - TV-тюнер или плата видеозахвата.и вот дальше ты на _его_ квантизацию - наложишь кодековую. И вот тут и будут квадратики, муар и прочие артефакты. Потом еще деинтерлейс - и получится полное бюэээ.
А хороших плат видеозахвата, к сожалению, уже сто лет как не делают.
> И при чем тут платы 80-х годов? Любая карта на каком-нибудь SAA7134
> оцифрует сигнал, а чем его жать, забота ПО.и сделает это плохо - уже можно не искать супер-лузлес-кодек, о том и речь.
60Kp60? где о таком почитать? почему не 64K? пока нашел только 16K
> 60Kp60Пока выглядит как опечатка от 6Kp60.
В кенотеатре посмотри. Тредэ.
Западные форумы давно воюют на тему 4K@4:2:0 -> FullHD@4:4:4 с помощью этого кодека. Подожду интеграции в ffmpeg и попробую. Если так, то keying и despill становятся несколько проще с более качественным результатом.
> Западные форумы давно воюют на тему 4K@4:2:0 -> FullHD@4:4:4у них диски безразмерные или бездонные?
4k монитор (не телевизор) обошелся мне в 400 евро. (промолчу, сколько потом пришлось платить за совместимую видеокарту)
>> Западные форумы давно воюют на тему 4K@4:2:0 -> FullHD@4:4:4
> у них диски безразмерные или бездонные?thunderbolt диски не так уж и дороги, если живешь на западе.
>>> Западные форумы давно воюют на тему 4K@4:2:0 -> FullHD@4:4:4
>> у них диски безразмерные или бездонные?
> thunderbolt диски не так уж и дороги, если живешь на западе.у них может и аплесинема не так и дорог. Но какой смысл уже пожатое 4k даунсэмплить в непожатое 1024p? Лучше выглядеть оно от этого уже не станет, если только диск не куплен на деньги, оставшиеся от продажи 4k монитора.
>Но какой смысл уже пожатое 4k даунсэмплить в непожатое 1024p?Наверное имелось в виду 1080p а не 1024p.
Народ на форуме изложил такое мнение:
http://protv.net.ua/viewtopic.php?f=15&t=14479
Утверждают что качество картинки резко возрастает.
> Наверное имелось в виду 1080p а не 1024p.угу. Мне кажется, у народа-с-форума обычные меломанские траблы, когда звук с кабеля из бескислородной меди отличают ;-)
собственно, ты всегда можешь 1080 пережать в какое-нибудь нестандартное 540x960 и попытаться увидеть примерно тот же эффект. Полагаю, фиг что увидишь ;-)
другое дело, что картинка, снятая приличной 4k камерой, может оказаться лучше, чем снятая hd-камерой - просто за счет оптики и матрицы нового поколения (или за счет unsharp mask в обработчике ;-)
А просто обзавестись 4k монитором, в общем-то, ныне не слишком дорогостоящее удовольствие.
> собственно, ты всегда можешь 1080 пережать в какое-нибудь нестандартное 540x960 и попытаться
> увидеть примерно тот же эффект. Полагаю, фиг что увидишь ;-)Есть способ проще. Берешь свои 320х240, разворачиваешь на 4K мониторе 30" на весь экран. Офигеваешь - на экране шевелящиеся квадратики!!!111 Блюешь. Сворачиваешь в оконный режим. Оно начинает занимать закуток в уголке экрана. Но зато теперь напоминает картинку и даже не очень плохо выглядит. Как вариант можно отойти от монитора метров на 5. Или смотреть на каком-нибудь телефоне, на экране дюйма в три пойдет на ура.
Крутая новость. В отличие от ProRes, Cineform поддерживает SMTPE стандарт. Умеет 10-bit 4:2:2 YUV и 12-bit 4:4:4 RGBA. Выходит, классный intermediate кодек стал open source