Когда истекли не знаю. Но все патенты IBM уже истекли, остался только один патент компании Ricoh www.google.com/patents?vid=5272478
Но нынешние реализации его не нарушают.
Про анаморфный пиксель ничего особо интересного нет: прямоугольный он и в африке прямоугольный, кодек это не волнует, это уже забота устройства отображения.
Переменная частота кадров — зло. Но она полезна в системах видеонаблюдения. Кодек тоже не сильно частота кадров беспокоит, а вот рендеру с ней работать тяжело. Смысл в том что стоит камера, снимает в ночное время, снимает еще и шумы, а они меняются с течением времени, а других изменений нет => нет и смысла хранить кадры в которых только меняется шум, лишь будут место занимать.
Да — фильмы тупо ускоряются (почти все или замедляются европейские для американцев). Именно поэтому когда к западным блюреям приделывают русские звуковые дорожки с DVD их приходится перекодировать.
А против стандартов в киноиндустрии не попрешь, это сейчас уже Blu-Ray плееру без разницы какой из стандартов читать (но опять же «из стандартов»), а DVD должны быть совместимы с кинескопными телевизорами.
Насчет причины введения делителя однозначного мнения нет, но наиболее реалистичной кажется то что: в электросети США ровно 60 Гц, а старые телевизоры «моргали» в такт электросети, то частота смены кадров немного снижена для смещения синхронизации по времени. То есть чтобы телевизор не мерцал без конца, а лишь время от времени.
Насчет концерта, то для сохранения скорости выбрасывается часть кадров, но происходит это редко и зритель ничего не замечает.
С европейским PAL все намного хуже, фильмы ускоряют на 4% для европейских DVD. А вот теми же концертами прибегают к болезненным алгоритмам интерполяции частоты кадров. 24 и 25 — уже слишком большая разница, повторы кадров зритель заметит.
Это одна из интереснейших тем современности. А создание быстрых декодеров, терпимых к ошибкам — весьма нетривиальное искусство. Я пока сам не могу достаточно компетентно об этом написать. Но могу задать этот вопрос спецам в лаборатории и по наличию времени опубликовать.
Понял, почитаю — вникну
При поверхностном взгляде думаю, что это относится уже к уровню транспортировки сжатого потока (и его соответствующей упаковки), а не к самому сжатию видеопотока.
Со скринкастами много чего проще:
1) Нефотографичность картинки (интерфейс ОС) => легче жмется сама по себе
2) Проще детектировать движение по векторам кандидатам (о кандидатах в следующей статье) => ровно и красивое поле векторов движения
3) После компенсации движения разностный кадр почти весь серый
Но есть и свои проблемы, особенно когда дело касается передачи в реальном времени. И некоторые традиционные алгоритмы могут безвозвратно испортить документальность какого-нибудь графика на мониторе.
Пожалуйста! В качестве продолжения будет непосредственно «цикл» видеокодека, а потом и проблемы в которые сегодня все упираются и методы их решения, предпринимаемые в нашей лаборатории в том числе.
Но нынешние реализации его не нарушают.
Переменная частота кадров — зло. Но она полезна в системах видеонаблюдения. Кодек тоже не сильно частота кадров беспокоит, а вот рендеру с ней работать тяжело. Смысл в том что стоит камера, снимает в ночное время, снимает еще и шумы, а они меняются с течением времени, а других изменений нет => нет и смысла хранить кадры в которых только меняется шум, лишь будут место занимать.
90*60*1139 = {МБит/с * сек = МБит} = 6150600 МБит = {/8} = 768825 Мбайт = {/1024} = 750.8 Гигабайт.
А против стандартов в киноиндустрии не попрешь, это сейчас уже Blu-Ray плееру без разницы какой из стандартов читать (но опять же «из стандартов»), а DVD должны быть совместимы с кинескопными телевизорами.
Насчет концерта, то для сохранения скорости выбрасывается часть кадров, но происходит это редко и зритель ничего не замечает.
С европейским PAL все намного хуже, фильмы ускоряют на 4% для европейских DVD. А вот теми же концертами прибегают к болезненным алгоритмам интерполяции частоты кадров. 24 и 25 — уже слишком большая разница, повторы кадров зритель заметит.
При поверхностном взгляде думаю, что это относится уже к уровню транспортировки сжатого потока (и его соответствующей упаковки), а не к самому сжатию видеопотока.
Можно ссылку на то, что вы имели в виду?
1) Нефотографичность картинки (интерфейс ОС) => легче жмется сама по себе
2) Проще детектировать движение по векторам кандидатам (о кандидатах в следующей статье) => ровно и красивое поле векторов движения
3) После компенсации движения разностный кадр почти весь серый
Но есть и свои проблемы, особенно когда дело касается передачи в реальном времени. И некоторые традиционные алгоритмы могут безвозвратно испортить документальность какого-нибудь графика на мониторе.