Ситуация с лицензированием патентов, пересекающихся с технологиями сжатия видео HEVC/H.265, приобрела неожиданный поворот. Кроме занимающейся сбором отчислений организации MPEG LA (http://www.mpegla.com) (MPEG Licensing Authority), на арену вышла (http://www.cnet.com/news/patent-group-raises-new-fees-uncert.../) альтернативная организация HEVC Advance (http://www.hevcadvance.com/), которая также намерена брать отчисления за отдельно сформированный патентный пул, охватывающий некоторые технологии, используемые в HEVC/H.265.Сообщается, что патентный пул HEVC Advance насчитывает более 500 связанных c HEVC/H.265 патентов, полученных от таких компаний, как GE, Technicolor, Dolby, Philips и Mitsubishi Electric. В свою очередь патентный пул MPEG LA сформирован на основе патентов от 27 компаний, среди которых Apple, Microsoft, Hitachi, Fujitsu, NEC, Kenwood, Samsung, Siemens. Таким образом складывается ситуация, когда сразу несколько организаций от лица владеющих патентами компаний будут собирать отчисления за реализацию поддержки HEVC/H.265. Так как производителям оборудования и владельцам видеосервисов платить придётся в два кармана, стоимость лицензирования HEVC/H.265 будет значительно больше, чем ожидалось ранее.
Подобное развитие событий идёт на руку компании Google, продвигающей свободную технологию сжатия видео VP9 (https://www.opennet.ru/opennews/art.shtml?num=37195), не требующую от производителей выплаты отчислений за использование запатентованных технологий. VP9 развивается в качестве конкурента H.265/HEVC, по сравнению с которым обеспечивает более высокий уровнь сжатия. О намерении интегрировать в свои продукты поддержку VP9 ранее уже объявили (https://www.opennet.ru/opennews/art.shtml?num=38786) такие компании, как ARM, Intel, NVIDIA, Samsung, Broadcom, LG, Marvell, MediaTek, Panasonic, Philips, Qualcomm, RealTek, Sigma, Sharp, Sony и Toshiba.
Несколько дней назад началось тестирование (https://groups.google.com/a/webmproject.org/forum/#!topic/co...) кандидата в релизы версии 1.4.0 библиотеки libvpx, в рамках которой развивается реализации свободных видеокодеков VP8 и VP9. В новом выпуске добавлены дополнительные средства управления кодеком VP9, значительно улучшены алгоритмы кодирования VP9, добавлена поддержка цветовых пространств YUV 4:2:2 и 4:4:4, проведена дополнительная оптимизация функций кодирования и декодирования VP9, по умолчанию включен режим многопоточного кодирования.
URL: http://xiphmont.livejournal.com/66047.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=41939
Совсем озверели, окаянные.
Да пусть собираю, пусть тролят, - быстрее сдохнут. Viva la Daala.
> Да пусть собираю, пусть тролят, - быстрее сдохнут. Viva la Daala.Это навряд ли .Повторяется ситуация с кодеком MP3 -M$ сперва нагнул институт Томсона ,а затем MP3 Альянс .После этого 5 лет не было кроме wma никаких встроенных от M$ кодеков под Винду .
Но браузеры в результате играют Vorbis и Opus... :)
> Это навряд ли .Повторяется ситуация с кодеком MP3 -M$ сперва нагнул институт
> Томсона ,а затем MP3 Альянс .После этого 5 лет не
> было кроме wma никаких встроенных от M$ кодеков под Винду .Подковерные игры могут завести куда угодно, но все же не думаю, что какой-нибудь крупный сервис на это завяжется, потому что это тупо при существовании бесплатных альтернатив, а производители, ну эпл сразу подпишется, да и другие наверняка,в конечном счете давным давно цена телефона или планшета оторвана от реальных затрат на производство и определяется из цены аналогов, куда там эти 5 баксов спрячут сути не имеет.
китайцы если положат болт на эти отчисления, то и остальным придется, как обладатель китайского телефона который не тупит и не рассыпается, да у него пленка на экране до сих пор заводская, без намека на отслоение - с осени держится, и всего 12к, на кой черт нужен гэлакси за 20 или , прости господи, айфон, я даже не представляю.
Хотя тут рядом открылся ресторанчик, так там все официанты с айфонами и туда заказ пишут, уж не знаю рабочие выдают или это критерий работодателя, но динамика на лицо, айфоны де факто норма для сирых и убогих, ну есть еще те кому подарили)).
> и всего 12к, на кой черт нужен гэлакси за 20 или , прости господи, айфон, я даже не представляю.Ну тебя жестоко поимели, китаец стоит 50$ http://ru.aliexpress.com/item/5-Android-4-4-2-MTK6572-Dual-C...
Ну или 6500 руп. за 8-ядыр и 4 гига http://ru.aliexpress.com/item/New-Lenovo-phone-MTK6592-octa-...
А я и не утверждал, что у меня самый дешевый вариант, у моего самая большая батарейка.
> Совсем озверели, окаянные.Дык надо ж из какого-то пальца GDP высосать.
Разбойники они только не с большой дороги а с большой цифры.
Похоже на противостояние корпорации, но Samsung фигурирует везде.
> добавлена поддержка цветовых пространств YUV 4:2:2 и 4:4:4Что там с 10битным цветом?
И 10, и 12.
Примерно то же самое что и с проводами из бeскиcлородной меди: бaззвopд, пoнты и прoмывкa мoзгa xoмякaм.
Вообще-то разница в качестве картинки часто «на лицо». Особенно если речь идёт о мультипликации, где есть большие области с плавными переходами цвета. Естественно можно обойтись и dithering-ом, но тогда размер файла вырастает во много раз.
Проблема алгоритма сжатия, а не битности: на png (8 бит) переходы плавные.
> Проблема алгоритма сжатия, а не битности: на png (8 бит) переходы плавные.Ну строго говоря цвет в любом случае у нас 8-битный - экраны такие. В смысле по 8 бит на канал. Загвоздка в том, что для получения качественного цветоперехода нам нужно смешивать области с двумя цветами, а иначе мы получаем такую поганую штуку, как color banding и png от него вообще никак не защищает. Единственный бонус в том, что мы можем применить dithering и сохранить как есть — сжатие без потерь гарантирует нам то, что точки со своих мест никуда не уползут, но это же приведёт к возрастанию объёма файла в разы. В случае же с видео у нас сжатия без потерь нет вовсе так-как видео без потерь занимает совсем уж конские размеры, а это означает, что эффективно хранить информацию о точном местоположении точек не получится. Дополнительные два бита возлагают задачу отображения на декодер и позволяют не хранить данные о том, как именно должны располагаться точки близких цветов в блоке. Т.е. color banding у нас никуда не пропадает, а просто вычисляется с большей точностью, чем мы можем отобразить. В результате это становится проблемой отображения дополнительных двух бит, а не проблемой хранения данных и её можно решать уже самыми разными способами, включая тот же dithering в реальном времени.
з.ы. Люди, знающие толк в извращениях, могут ещё дополнить мои слова тем, что 8 бит на канал даже на современных экранах это часто тоже миф и на самом деле их там нет.
Все верно, но реально color banding заметен лишь при малой битности (либо из-за артефактов сжатия с потерями качества). Есть реальные примеры когда не хватает 8 бит на канал?
Да пожалуйста:
http://i.imgur.com/g5EL2B0.pngОбрати внимание на переход синий-голубой-зелёный-желтый. Во всей красе, так сказать. Сделал через инструмент градиента выключив в нём dithering.
А теперь поверх этого добавим артефактов сжатия от jpeg 90%:
http://i.imgur.com/3TK3GT9.jpgКрасота, не правда ли? Артефакты сжатия подчеркнули color banding даже там, где его не было заметно.
> Обрати внимание на переход синий-голубой-зелёный-желтый. Во всей красе, так сказать. Сделал через инструмент градиента выключив в нём dithering.Согласен - видно, но не критично. Теперь нужен тот же случай, но с дитерингом, что бы понять: проблема монитора или нехватки бит.
> Артефакты сжатия подчеркнули color banding даже там, где его не было заметно.
С jpeg все понятно - там местами синий через два значения прыгает.
Без dithering:
http://s304.photobucket.com/user/Lain_InVerse/media/color-ba...С ним:
http://s304.photobucket.com/user/Lain_InVerse/media/color-ba...Для сравнения лучше скачай оригинальные файлы. Они там доступны из меню-шестерёнки (мышку на картинку наведи) > Download. При просмотре прямо с сайта даже если нажать кнопку показа во весь экран реально покажет во всё окно браузера и в дело может вклиниться алгоритм масштабирования от которого полоски вылезают даже на картинке с dithering-ом, пусть и не столь заметные.
И в качестве бонуса вот что со второй картинкой сотворил imgur, когда я попытался её туда залить:
http://i.imgur.com/qC91IAV.jpgКстати, немного ниже Stax сделал ещё одно важное замечание на счёт преобразования из и в RGB (видео ведь не в нём).
> Для сравнения лучше скачай оригинальные файлы. Они там доступны из меню-шестерёнки (мышку
> на картинку наведи) > Download. При просмотре прямо с сайта даже
> если нажать кнопку показа во весь экран реально покажет во всё
> окно браузера и в дело может вклиниться алгоритм масштабирования от которого
> полоски вылезают даже на картинке с dithering-ом, пусть и не столь
> заметные.Облачные технологии ... Там на странице direct link был, лучше сразу его выкладывать.
В общем смотрел на DELL S2740L, настроен и откалиброван (X-Rite ColorMunki Display + Argyll). Без профиля полосы есть только в темной части синего. С дитирингом примерно в два раза менее заметны. С профилем полосы появляются и на светлой части, но другие по форме и размеру - профиль сдвигает некоторые цвета и образуются плашки.
ИМХО все же проблема в мониторе - его погрешность больше, чем ошибка округления до 8 бит на канал, поэтому и дитеринг не работает на все 100%. В теории, если увеличить округление до 7 бит и при этом использовать дитеринг, то мы получим чуть более шумное изображение, но без полос.
Там такие прямые ссылки, что в половине случаев тебя вываливает на ту же страницу, а во второй тебе вываливает картинки странного размера. Я не просто так порекомендовал скачать оригиналы и смотреть на них предварительно убедившись в том, что они отображаются без масштабирования. Полосок на картинке с dithering-ом не должно быть заметно… разве что на 27-дюймовом экране этому как-то способствует собственно физический размер точек. У меня ноут с 19-дюймовым экраном. Но если картинка хоть немного будет уменьшена или увеличена, то будет как-раз «С дитирингом примерно в два раза менее заметны». Этот метод устранения полосатости крайне чувствителен к способу масштабирования и к масштабированию вообще.
Больше на этот "сервис" не заливай - я действительно первый раз накачал фиг что. Сделай себе лучше аккаунт на каком-нибудь бесплатном хостинге (я bplaced.net использую, так как он позволяет по ftp заливать).В общем действительно дитеринг решает проблему. На ноуте с ТN тоже работает, но там видны пятна собственного дитеринга монитора - не умеет он честные 8 бит на канал.
Так что твои труды небыли напрасными, спасибо ;)
> но там видны пятна собственного дитеринга монитора - не умеет он
> честные 8 бит на канал.Честные 8 бит обычно только у качественных топовых мониторов. А некоторые до 8 битов догоняются проблемными полужульническими методами, ведущими к куче пробдем.
А уж TN... дяденька, если вас TN устраивает - значит вас цветопередача совсем не интересовала. Ну и смысл то там на какие-то добавочные биты дергаться тогда? У TN в общем то только 2 достоинства: относительная дешевизна и как правило приличные времена отклика. Все остальное - недостатки. По поводу чего юзер планшета за 1.5 килобакса может завистливо смотреть на планшет в 10 раз дешевле, где IPS матрица - куда как более приличная.
> А уж TN... дяденька, если вас TN устраивает - значит вас цветопередача
> совсем не интересовала.Где я сказал, что меня ТN устраивает? DELL S2740L, настроен и откалиброван (X-Rite ColorMunki Display + Argyll). Устраивает на 90%.
Ну это еще куда ни шло - IPS все-таки не TN. Но у него ж при FullHD пикселы размером должны быть с воробья при 27"?! Впрочем, тем хуже для вас - "dithering" шумами должен довольно злобно глаза мозолить, если там не налажали в электронике (что было бы достаточно странно для монитора с IPS матрицей).На модельке постарше - этот ваш dither от камеры очень видно и он порядком бесит, потому что небо с плавным градиентом, но уже в крапинку - выглядит совсем не так как это было в природе (там никаких крапинок, знаете ли). А калибровка у старших моделей делла - прямо с фабрики, делл дает определенные гарантии + кладут распечатку с результатами калибровки. Хорошо придумано, но практикуется только для дорогих старших моделей.
> Ну это еще куда ни шло - IPS все-таки не TN. Но
> у него ж при FullHD пикселы размером должны быть с воробья
> при 27"?!Мне лично 27" нужны, что бы изменить фокусное расстояние глаз, а то близорукость начала проявляться.
> Впрочем, тем хуже для вас - "dithering" шумами должен
> довольно злобно глаза мозолить, если там не налажали в электронике (что
> было бы достаточно странно для монитора с IPS матрицей).Вроде нормально там все - была куча обзоров со всевозможными замерами. Но шума дитеринга не вижу.
> На модельке постарше - этот ваш dither от камеры очень видно и
> он порядком бесит, потому что небо с плавным градиентом, но уже
> в крапинку - выглядит совсем не так как это было в
> природе (там никаких крапинок, знаете ли).Вы уверены, что бесит именно изменение на одну еденицу (как это происходит при дитеринге), а не на несколько (тепловой шум/артефакты сжатия/другие баги камеры)?
На этой растяжке вас тоже дитеринг бесит?
knk.bplaced.net/color-banding-dither-on.png (c) Lain_13
> близорукость начала проявляться.А, теперь понимаю нафиг вам пикселы с кулак размером.
> Вроде нормально там все - была куча обзоров со всевозможными замерами. Но
> шума дитеринга не вижу.Да он не должен быть сильно заметен, если алгоритм dithering качественный. К тому же у меня монитор с повышенным DPI. Так что на вашей картинке - dithering как таковой явно в этом случае не видно. Но "нелинейность" переходов на моем мониторе в некоторых местах очень даже видна, по поводу чего это смахивает на какой-то набор сегментов кольца, хоть у них и не идеально резкие границы (dithering же), но это - не воспринимается как плавный градиент, хоть ты тресни. Какие-то куски разноцветных колец с размытыми границами.
> Вы уверены, что бесит именно изменение на одну еденицу (как это происходит
> при дитеринге), а не на несколько (тепловой шум/артефакты сжатия/другие баги камеры)?Может и на несколько, специально не замерял, если попадется - проверю на сколько битов отличается. Однако ж переходы без dithering видно. Т.е. технически проблема как бы есть. А dithering - вообще совершенно левый костыль, для начала. И он лишь пытается замаскировать проблему, а не устраняет ее. И
Понятно что профессионалы и 256 цветами отлично нарисуют, с адаптивной палитрой. Ну вон первый старкрафт - никто и не думал что там на все и вся 256 цветов. Но это затраты усилий и уйма места для проблем на ровном месте. И залет на тот факт что просто картинки без заморочки технологическими ограничениями средств отображения, отстающих от возможности глаза будут порой выглядеть "не очень".
> На этой растяжке вас тоже дитеринг бесит?
Нет, меня там бесит распадение якобы непрерывного градиента (я так понимаю, изначальная идея такая?) на ... сегменты кольца. С вполне ощутимой дискретностью, хоть и нерезкими границами. Маскировка недостачи битов под пенька не получилась - проблемы отображения видоизменились, но не пропали.
> Однако ж переходы без dithering видно. Т.е.
> технически проблема как бы есть. А dithering - вообще совершенно левый
> костыль, для начала. И он лишь пытается замаскировать проблему, а не
> устраняет ее.Технически это называется ошибка квантования. И будет она всегда - такова суть цифры. Вопрос только в ее размере и значимости при восприятии человеком. При переходи на 10 бит мы уменьшим ошибку в четыре раза. Особо придирчивые (как тут собравшиеся ;) все равно ее увидят на мониторе с большим динамическим диапазоном.
Есть и другой способ - увеличивать количество сэмплов. Например в Super Audio CD используется DSD - всего 1 бит (против 16 бит у CD), но частота дискретизации 2822.4 кГц (в 64 раза больше, чем у CD). Фактический этот 1 бит и есть сплошной дитеринг.
В теории 16 бит CD дают нам 96dB разрешения по громкости, но на реальном сигнале у нас возникают ошибки при округлении и мы получаем THD -80dB, что очень далеко от обещанных 96dB - тихие фрагменты звучать будут очень жестко. Но если добавить дитеринг, то мы получим обещанное разрешение в 96dB. Более того, если использовать noise shaping (разновидность дитеринга), то мы можем пожертвовать мало значимой областью высоких частот (находящимися фактически за пределом слышимости) в пользу средних (наиболее значимых для человека) частот и получить на них более 100dB.
Немного отвлекся, но на примере аудио мне легче конкретизировать - добавлял/исправлял дитеринг в открытых проектах. Тем не менее, основы теории цифровых сигналов едины, вне зависимости от области применения.
Для монитора мы можем увеличивать dpi и получить тот же эффект. Еще один способ FRC (frame rate control).
У каждого решения есть свои плюсы и минусы, но правильно комбинируя их можно получить отличный результат.
> Нет, меня там бесит распадение якобы непрерывного градиента (я так понимаю, изначальная
> идея такая?) на ... сегменты кольца. С вполне ощутимой дискретностью, хоть
> и нерезкими границами. Маскировка недостачи битов под пенька не получилась -
> проблемы отображения видоизменились, но не пропали.Это не проблема дитеринга, просто сам градиент построен не линейно относительно человеческого глаза. Но темно синяя часть практически линейна и на ней не должно быть явных артефактов.
> с дитерингом, что бы понять: проблема монитора или нехватки бит.А когда я фотографирую или снимаю сцену на видео - это ничего что там никто dithering делать специально не будет, не? :)
Там аналоговый дитеринг - от теплового шума матрицы :)ИМХО в нормально фотоаппарате этим должен заниматься DSP, ведь в матрице больше 8 бит, не логично просто обрезать не влезшие биты.
> Там аналоговый дитеринг - от теплового шума матрицы :)
> ИМХО в нормально фотоаппарате этим должен заниматься DSP, ведь в матрице больше 8 бит, не логично просто обрезать не влезшие биты.Какая разница сколько там чего если в фотоаппарате, даже после этого самого DSP с шумодавом, шумы прекрасно видны даже на 8 разрядном жпеге.
И кстати смотреть на скриншоты видео в поисках дефектов особого смысла нет. Т.к. при просмотре самого видео многие из них эффективно усредняются глазом за несколько кадров.
> шумы прекрасно видны даже на 8 разрядном жпеге.Более того, жпег к шуму относится плохо и может не только сделать его более видимым, но и обеспечить много радости при попытке вырубить это шумодавом в софте.
А фотоаппарат при таких заморочках должен делать то что попросишь. Ну то-есть если юзерь хочет равку, дело фотика записать то что он с матрицы получил в файло. Дальше фотограф как-нибудь сам. Без хз каких алгоритмов на слабом проце питаемом от батарейки и подпертого реалтаймом (фотографа не пропрет ждать сохранения 1 кадра минуту, да и аккумулятор при мало-мальски мощном проце сядет моментально).
> Т.к. при просмотре самого видео многие из них эффективно усредняются глазом
> за несколько кадров.Глаз не различает мелкие объекты в движении :). Но, правда, хороший стопкадр - тоже сойдет за фичу.
> Там аналоговый дитеринг - от теплового шума матрицы :)Единственная проблема - портит картинку и бывает заметен. В том числе и на градиентах типа неба/облаков/etc. Никогда не видели на фотографиях небо с облаками, которое как будто посыпано чем-то? Оно и есть. Правда, чтобы это увидеть - надо нормальный монитор. На ноуте с TN это врядли разглядишь. А вот на хорошем мониторе с IPS/PVA - захочется объяснить фотографу что он лох и не умеет пользоваться denoise-ом ;)
> ИМХО в нормально фотоаппарате этим должен заниматься DSP,
Никому никто ничего не должен. Реалтайм же. И у проца есть еще 100500 дел.
А по нормальному - при таких заморочках со стороны фотографа вообще ожидается серия отсчетов с матрицы в RAW, "как она есть". А дальше - фотограф как-нибудь сам, в характерном софте (по типу DarkTable и еще некоторых). Потому что одно дело относительно маломощный проц который от батареечки кормится, да еще реалтайм жмет, и совсем другое - вон тот мощный писюк, которые может вволю попахать. Понятно где можно будет больше алгоритмов крутить и оптимизировать по качеству, а не времени выполнения.
А битность (а точнее, динамический диапазон) по жизни фотографы при помощи камеры повышают, делая серию кадров с разной экспозицией (автоматически и быстро). Чтобы и слабый сигнал нормально померять но и сильный не исказить. При этом в разных кадрах информация с разных участков сигнала, что ведет к повышению динамического диапазона, о сигнале доступно больше информации (и это не лезет в битность 1 кадра).
> в матрице больше 8 бит
Битность матрицы - вообще довольно интересный вопрос. Пусть у нас 8 битов на составляющую. Но - байеровский формат пикселей. Когда зеленый - шарится на 2 ячейки. Ну и сколько там у нас битов получается? Для конверсии в RGB половину зеленых пикселей надо вообще буквально "взять с потолка" - на матрице их нет! :)
Я посмотрел все ваши картинки на TN-матрице с ноута, через браузер, и всё собака-за*бяка. Ну если оочень уж сильно присматриваться, через лупу, можно косячки заметить на jpg-e 90%, и там где хостинг цвета исказил. Выкладывайте на свой ftp или сайт лучше. Тут не ЛОР, эффекта ДДОС не будет ;-)
А если это пустить со скоростью 30-60 fps (привет 3D очкам), отсесть на 3 метра, и включить бодрый трек, типа как я сейчас слушал "Deep Purple - Highway Star", то фиг Вы что заметите.
> Я посмотрел все ваши картинки на TN-матрице с ноута, через браузер, и всё собака-за*бяка.Вот только это баг а не фича. Потому что свидетельствует в основном о гунявости матрицы. Поскольку битов там реально не хватает. И если ты это не видишь - то только потому что у твоего железа еще бОльшие проблемы.
Кроме всего прочего - на таком железе совершенно дохлый номер заниматься обработкой фотографий: ты не заметишь массу дефектов, а народ с более качественными мониторами - захлебнется в блeвотине и ты узнаешь много нового о своей кривизне рук.
> А если это пустить со скоростью 30-60 fps (привет 3D очкам), отсесть
> на 3 метра, и включить бодрый трек, типа как я сейчас
> слушал "Deep Purple - Highway Star", то фиг Вы что заметите.На TN матрице? Может быть. Ну так у тебя поди и mp3 на 64 Кбит звучит нормально на твоем оборудовании - на встроенных в ноут бухтелках от 128 фиг отличишь :). А так - в видео проблеам менее злободневна, НО например на computer-generated картинках (рендеры, скринкасты, аниме всякое, ... ) - может быть видно.
на кинескопе да, через аналоговый выход да, с дизерингом да, в остальных случаях с хорошим зрением переходы видно
> на кинескопе да, через аналоговый выход да, с дизерингом да,...но только потому что точность всей этой конструкции хуже 8 битов на канал и оно "хардварно сглаживает". Но это баг, а не фича.
Только вот png содержит RGB информацию, использовать которую в видео - дикое расточительство. В видео YUV (еще и с сабсэмплингом). 8-ми битный YUV содержит меньше информации (более грубый), чем 8-ми битный RGB. Т.е. если делать преобразование
8-bit RGB -> 8-bit YUV -> 8-bit RGB, то потеря точности в итоговом RGB будет ощутимо больше, чем если бы YUV был 10-ти битный. Поэтому сравнивать битность YUV и RGB в лоб некорректно.Что касается переходов, нужно еще учитывать, что там не просто 10 бит данных, но и вычисления идут с большей точностью.
> Только вот png содержит RGB информацию, использовать которую в видео - дикое
> расточительство. В видео YUV (еще и с сабсэмплингом).При сабсэмплинге плавного градиента не будет по определению.
> 8-ми битный YUV
> содержит меньше информации (более грубый), чем 8-ми битный RGB. Т.е. если
> делать преобразование
> 8-bit RGB -> 8-bit YUV -> 8-bit RGB, то потеря точности в
> итоговом RGB будет ощутимо больше, чем если бы YUV был 10-ти
> битный. Поэтому сравнивать битность YUV и RGB в лоб некорректно.А если так:
16-bit RGB -> 8-bit YUV -> 16-bit RGB
против
16-bit RGB -> 8-bit RGB -> 16-bit RGBИМХО если переводить 8-bit YUV -> 8-bit RGB + dithering, то визуально мы много не потеряем.
В любом случае основной проблемой остается не количество бит на канал и не цветовые модели, а битрейт. ИМХО без использования lossless кодеков все эти факторы несущественны.
> При сабсэмплинге плавного градиента не будет по определению.Эм, это неправда. Разумеется, нужно правильно интерполировать, а не дублировать цветность между пикселями.
> 16-bit RGB -> 8-bit YUV -> 16-bit RGB
Где взять 16 bit RGB?
Проблема не в формате RGB и точности вычислений, а в том, что (с очень большими допущениями, которые делают это утверждение некорректным, но это не относится к теме :) - 8-bit RGB теряет много информации при переводе в 8-bit YUV, и не так много при переводе в 10-bit YUV. Поэтому второе - лучше.
(на всякий случай, основные допущения тут - это слишком абстрактно, в реальности нужно говорить не про YUV, а конкретный формат, напр. 4:2:2 Y'Cb'Cr с конкретным цветовым форматом, напр. RGB стандарта sRGB и YUV стандарта BT.709; также нужно понимать, что в видео используется ограниченный диапазон, уровень яркости 16 при переводе в RGB будет "черным", а 240 "белым". Но в YUV представимы 16 уровней "темнее черного" и 16 "светлее белого", эта информация будет потеряна при переводе в RGB)Но с некоторой точки зрения можно сказать, что 8-ми битный RGB содержит более точный цвет, чем даже 10-ти битный YUV. Поэтому не нужен какой-то специальный монитор с выводом 10-bit RGB, чтобы увидеть преимущество 10-bit YUV перед 8-bit YUV. Последний точнее даже при преобразовании к 8-bit RGB.
> ИМХО если переводить 8-bit YUV -> 8-bit RGB + dithering, то визуально мы много не потеряем.
Хорошим dithering'ом можно убрать плохие градиенты. Но хороший - это дорого. Это *очень* дорого делать в реальном времени. 10-ти битное декодирование намного дешевле.
> В любом случае основной проблемой остается не количество бит на канал и не цветовые модели, а битрейт. ИМХО без использования lossless кодеков все эти факторы несущественны.
Видео - это очень сложная штука, алгоритмы нынче продвинутые, на ключевые кадры может идти очень большой битрейт, и качество практически loseless. Во всяком случае, сохраняется больше информации, чем у JPEG'а с его 4:2:0 кодированием.
Что касается 10-ти бит, в том-то и дело, что они позволяют сохранить идеальность градиентов с битрейтом на 20-30% меньше, чем требуется у 8-ми битного кодирования. Да, и там, и там можно сделать качественный результат. Но с 10-ти битным - экономичнее.
Надо понимать, что например 1-битная ошибка в 8-ми битных данных эквивалентна 3-х битной ошибке в 10-ти битных, поэтому нужно сильно более жесткое квантование, чтобы исказить 10-ти битный сигнал до того же визуального непотребства, как и 8-ми битный.
> Где взять 16 bit RGB?Делаешь несколько фото одного и того же но с разной экспозицией. Получаешь серию кадров под HDR. Склеиваешь характерным софтом. Получаешь RGB повышенной битности, с повышенным динамическим диапазоном. При этом могут быть хорошо проработаны и очень темные и очень светлые места. Правда вот потом на монитор это вывести уже проблема. В лучшем случае монитор умеет 10 битов на канал. Ну то-есть tonemapping во все поля...
> Эм, это неправда. Разумеется, нужно правильно интерполировать, а не дублировать цветность
> между пикселями.Как мы узнаем в каком месте нам нужна интерполяция, а в каком однородная заливка?
> Где взять 16 bit RGB?
Что-то мне подсказывает, что кино не в 8 бит на канал снимают.
В 3D - 16/32 бита на канал - норма.>[оверквотинг удален]
> не относится к теме :) - 8-bit RGB теряет много информации
> при переводе в 8-bit YUV, и не так много при переводе
> в 10-bit YUV. Поэтому второе - лучше.
> (на всякий случай, основные допущения тут - это слишком абстрактно, в реальности
> нужно говорить не про YUV, а конкретный формат, напр. 4:2:2 Y'Cb'Cr
> с конкретным цветовым форматом, напр. RGB стандарта sRGB и YUV стандарта
> BT.709; также нужно понимать, что в видео используется ограниченный диапазон, уровень
> яркости 16 при переводе в RGB будет "черным", а 240 "белым".
> Но в YUV представимы 16 уровней "темнее черного" и 16 "светлее
> белого", эта информация будет потеряна при переводе в RGB)Что 10 бит лучше 8 бит это понятно.
> Но с некоторой точки зрения можно сказать, что 8-ми битный RGB содержит
> более точный цвет, чем даже 10-ти битный YUV.Почему?
>> ИМХО если переводить 8-bit YUV -> 8-bit RGB + dithering, то визуально мы много не потеряем.
> Хорошим dithering'ом можно убрать плохие градиенты. Но хороший - это дорого. Это
> *очень* дорого делать в реальном времени. 10-ти битное декодирование намного дешевле.Вроде не очень накладно - промодулировать шум ошибкой округления, самое дорогое в этой операции - random, но можно предварительно заполнить его значения в буфер и циклично брать из него. Если реализовать как шейдер, то вообще отлично должно получится.
> Что касается 10-ти бит, в том-то и дело, что они позволяют сохранить
> идеальность градиентов с битрейтом на 20-30% меньше, чем требуется у 8-ми
> битного кодирования. Да, и там, и там можно сделать качественный результат.
> Но с 10-ти битным - экономичнее.
> Надо понимать, что например 1-битная ошибка в 8-ми битных данных эквивалентна 3-х
> битной ошибке в 10-ти битных, поэтому нужно сильно более жесткое квантование,
> чтобы исказить 10-ти битный сигнал до того же визуального непотребства, как
> и 8-ми битный.Если так все хорошо, чего все подряд жмут в yuv420p?
(что-то мы в совсем оффтопик ушли. Надеюсь, модератор не сотрет это слишком быстро :)> Как мы узнаем в каком месте нам нужна интерполяция, а в каком однородная заливка?
Для каналов цветности всегда нужна интерполяция по горизонтали, т.к. например в Full HD кадре выводим на 1920x1080 пикселей, а по цветности у нас 960 значений, по одному на каждые два. Собственно, без (хотя бы линейной) интерполяции по горизонтали это никто не выводит. Хотя есть более качественные варианты. За примерами можно посмотреть картинки на http://forum.doom9.org/showthread.php?t=146228
> Что-то мне подсказывает, что кино не в 8 бит на канал снимают.
Снимают на разное (можно предположить, что там и 8 бит, а может и больше - но не суть важно. В конце концов, можно и разрешением скомпенсировать, по цветам главное чтобы на динамический диапазон хватило). Обрабатывают в большей глубине, разумеется.
В любом случае, энкодеры там обычно старые и принимают на вход именно 8-ми битный RGB. А на выходе только 8-ми битный YUV. Стандарты DVD, а потом Blu-ray не предусматривают большей глубины цвета. Они вообще принимались достаточно давно, тогда не задумывались про это настолько ;) А с тех пор ситуация стала лучше, но они больше были заняты улучшениями поинтереснее. Напр. цветовое пространство BT.2020 для UHD это просто нечто по сравнению с BT.709 для HD, диапазон воспроизводимых цветов расширили ОЧЕНЬ сильно.
> Вроде не очень накладно - промодулировать шум ошибкой округления, самое дорогое в этой операции - random, но можно предварительно заполнить его значения в буфер и циклично брать из него. Если реализовать как шейдер, то вообще отлично должно получится.
В madvr есть дайзеринг error diffusion, выполняемый на GPU. Ресурсов жрет, прямо скажем, немало. Т.е. работает, но требует мощной видяхи (определенно не интеграшки). random или ordered dithering тоже есть, но дают не такой хороший результат.
> Почему?
Я плохо выразился. Имелось ввиду, оставаться в RGB лучше, чем переходить даже в 10-ти битный YUV. Потеря точности происходит даже при такой конвертации (и наоборот). Могу предложить самому поиграться с формулами и убедиться :)
Это к тому, что если бандинга нет в RGB, то он потенциально может появиться при переходе даже в 10-ти битный YUV без субсэмплинга и потом назад в RGB. (на практике, думаю, нет, т.к. переходы между значеними пикселей, где теряется точность размазаны по пространству).Для решения этой проблемы изобрели 12-ти и даже 16-ти битные YUV, но это совсем экзотика :)
> Если так все хорошо, чего все подряд жмут в yuv420p?
Бывшие стандарты (Blu-ray) не поддерживали более продвинутые форматы. В H.264 закодировать можно было, но плееры бы не играли. Вы посмотрите на год, когда эти стандарты разрабатывались и все станет понятно. Это было *ДАВНО*.
В текущем стандарте UHD есть требование по поддержке 10-ти битного представления. Собственно, с увеличенной глубиной цвета в BT.2020 без этого было бы туго - бандинг будет во все края!
Но далеко не любой материал, даже сейчас выпускаемый для UHD делается для BT.2020 - снимали и мастерили-то под более узкие цветовые пространства! Так что материал, который выпущен в 4K разрешении вполне может быть под BT.709 (любой релиз текущего фильма, если мастер для домашнего просмотра делался под BT.709, откуда там взяться более глубоким цветам? Пересканировать или сконвертировать без уменьшения до HD-разрешения это одно, а полный ремастер, да еще с цветами, которые не факт, что там есть - совсем другое..). А в этом случае *острой* необходимости в 10-ти битном кодировании нет. Да, бандинга меньше, битрейт можно уменьшить с сохранением качества. Но Blu-ray - не DVD, там битрейта хватает с большим запасом, никаких артефактов сжатия (а не мастеринга) лично я там никогда не видел. Поэтому весь этот материал даже для UHD может выпускаться пусть в 4K разрешении, но с 8-ми битным кодированием без особых проблем.
Картинка по стандартам есть тут http://www.safe.fr.cr/Temp/Hifi/standards.jpg
Да, в 2006 году (это релиз для рынка - а придумали, что там будет году где-то в 2000-2001) поддерживали только 8-ми битный цвет. Несколько лет назад начали использовать 10-ти битное кодирование, и вот стандарт Ultra HD Blu-ray 2015 года уже требует его поддержки.
> Для каналов цветности всегда нужна интерполяция по горизонтали, т.к. например в Full
> HD кадре выводим на 1920x1080 пикселей, а по цветности у нас
> 960 значений, по одному на каждые два. Собственно, без (хотя бы
> линейной) интерполяции по горизонтали это никто не выводит.А если 4:4:4 ?
> Хотя есть более
> качественные варианты. За примерами можно посмотреть картинки на http://forum.doom9.org/showthread.php?t=146228Не впечатлило - границы сильно размазаны.
>> Что-то мне подсказывает, что кино не в 8 бит на канал снимают.
> В любом случае, энкодеры там обычно старые и принимают на вход именно
> 8-ми битный RGB. А на выходе только 8-ми битный YUV.Там на выходе даже из старых камер raw есть:
https://ru.wikipedia.org/wiki/%D6%E8%F4%...У новых так и вообще 14 бит:
https://en.wikipedia.org/wiki/List_of_large_sensor_interchan...Для цифровых кинотеатров стандарт 12 бит на канал и CIE XYZ.
https://en.wikipedia.org/wiki/Digital_Cinema_Initiatives> В madvr есть дайзеринг error diffusion, выполняемый на GPU. Ресурсов жрет, прямо
> скажем, немало. Т.е. работает, но требует мощной видяхи (определенно не интеграшки).
> random или ordered dithering тоже есть, но дают не такой хороший
> результат.Ape тоже ест в десять раз больше flac, а сжимает только на 10% лучше.
Ну для 4:4:4, разумеется, не нужно :) Я про реальное видео, соответствующее стандартам. С 4:4:4 пока только эксперименты бывают. Стандарты UHD также не поддерживают 4:4:4.> Не впечатлило - границы сильно размазаны.
Это был всего лишь пример, что можно масштабировать половину разрешения до полного не теряя плавности переходов, а только четкость (некоторая потеря четкости неизбежна, если мы потеряли половину разрешения, потеря информации уже произошла до нас). Нужно понимать, что в реальном видео кроме как в титрах таких сцен не бывает (где канал яркости фактически не несет информации, и четкость настолько зависит от канала цветности), и что это просто пример, бикубическое масштабирование с мягкими коэффициентами действительно мажет, но это далеко не единственный способ масштабирования. Для тех, кто хочет без пикселизации, но почетче и без размазанности, существуют интерполяции с фильтром Ланцоша или функцией sinc (madvr их поддерживает) - это более приближенные PSF (https://en.wikipedia.org/wiki/Point_spread_function) к пикселю и лучше восстанавливающие потери данных.
> Для цифровых кинотеатров стандарт 12 бит на канал и CIE XYZ.
Это все супер, но кино - это кино. Если мы потом загоняем в 8-ми битный YUV 4:2:0, уже особо без разницы, что там было на входе. А мы загоняем, потому что такое стандарт. Я не знаю, может энкодеры, которыми пользуются при мастеринге блюриков и принимают 10-ти или 12-ти битный RGB. Тогда результат будет точнее. Но это не меняет сути, что дальше 8-ми битный YUV, а реальная панель обычно будет выводить 8-ми битный RGB.
> Ape тоже ест в десять раз больше flac, а сжимает только на 10% лучше.
Это все довольно субьективные вещи - кому интересно выжать из системы все, те используют.
Могу предложить синтетические сравнения, на них видно, что random добавляет много шума и снижает четкость картинки, а error diffusion этого не делает, такой dithering делает свою работу, ничего не ухудшая.
ED: http://forum.doom9.org/showthread.php?p=1666263
random: http://s23.postimg.org/kg2kjoyob/RD_0s.png (ссылка из поста)http://forum.doom9.org/showthread.php?p=1668270
Но это синтетика, во втором примере, например, они работали с 3-х битным сигналом и dither'или до 8 бит :) Когда речь только про 8-мой бит, это все не настолько явно.
Но, в общем, не суть. dithering (на какой хватает ресурсов) в любом случае лучше делать, и 10-ти битное кодирование дает большее качество либо экономит битрейт по сравнению с 8-ми битным. Это не связанные вещи, хотя оба могут улучшить качество.
> В любом случае основной проблемой остается не количество бит на канал и
> не цветовые модели, а битрейт.Для видео - возможно, с оговоркой что вы не хотите смотреть на стопкадры и тем более делать из стопкадров обоину на десктоп. Для статичных картинок цветовая модель достаточно важна.
> ИМХО без использования lossless кодеков все эти факторы несущественны.
Так их есть. В том числе у VP9 есть lossless режим.
> Проблема алгоритма сжатия, а не битности: на png (8 бит) переходы плавные.Весьма зависит от. Иногда мало даже 24-битного PNG. Берем плавный градиент, то же небо например зачастую. И там даже 8 битов на весь blue (==256 вариантов градаци) оказывается мало для того чтобы не было характерных полос по градиенту, там где битики переключаются. Потому что в этом мире больше чем 256 оттенков синего и человеческий глаз их вполне себе отличает.
На хорошем мониторе - все это прекрасно видно. Поэтому для серьезной работы с графикой хорошие мониторы нынче умеют и 10 бит на составляющую, равно как и видеокарты(даже в открытом драйвере запилено, хоть и не активировано по дефолту). Более того - и форматы передачи данных есть. Даже просто фото из RAW в PNG без потерь не сохраняется, из-за разных представлений пикселов и шкал. А уж если несколько снимков с разной экспозицией объединять в HDR - там битов на пиксель явно более 8. Потому что DAC делает отсчет в разных точках, с разным предусилением и мы получаем намного больше информации о сигнале чем "единоразовое" разрешение DAC. По этому поводу нынче есть такая штука как OpenEXR например (формат повышенной битности - для хранения HDR).
В общем если вам кажется что 8 битов дофига - идете и пробуете сфотографировать рассвет или закат. Или иную контрастную сцену с градиентами. В видео это конечно несколько менее актуально, там сжатие строится (еще начиная с аналоговых телевизионщиков) на довольно своеобразном и дурном представлении цвета. Которое однако занимает меньше места (и требует меньше полосы эфира, бандвиза в случае кодека и прочая).
>> Проблема алгоритма сжатия, а не битности: на png (8 бит) переходы плавные.
> Весьма зависит от. Иногда мало даже 24-битного PNG. Берем плавный градиент, то
> же небо например зачастую. И там даже 8 битов на весь
> blue (==256 вариантов градаци) оказывается мало для того чтобы не было
> характерных полос по градиенту, там где битики переключаются. Потому что в
> этом мире больше чем 256 оттенков синего и человеческий глаз их
> вполне себе отличает.Lain_13 уже подготовил различные варианты градиента.
> На хорошем мониторе - все это прекрасно видно.
Модель своего монитора я озвучил, не про, но вполне нормальный.
Пока я склоняюсь к мнению, что вижу погрешности монитора, так как часть цветовых градиентов я вижу непрерывными.> Поэтому для серьезной работы
> с графикой хорошие мониторы нынче умеют и 10 бит на составляющую,
> равно как и видеокарты(даже в открытом драйвере запилено, хоть и не
> активировано по дефолту). Более того - и форматы передачи данных есть.ИМХО подобные мониторы нужны для увеличения динамического диапазона и работы с расширенными цветовыми пространствами. Соответственно 10 бит нужны, чтобы компенсировать большую контрастность между полутонами.
> В общем если вам кажется что 8 битов дофига
Мне кажется, что средний монитор показывает меньше цветов, чем влезает в 8 бит на канал.
> Модель своего монитора я озвучил, не про, но вполне нормальный.
> Пока я склоняюсь к мнению, что вижу погрешности монитора, так как часть
> цветовых градиентов я вижу непрерывными.Ты ещё погрешности своих собственных глаз видишь и мозг вносит свои коррективы. Порой он видит один и тот же предмет на разном или неоднозначном фоне совершенно по-разному (знаменитый пример «какого цвета платье»). И градиенты у меня были не равномерные. Именно потому во втором, например, полоски в тёмной части шире полосок в светлой. А если говоришь про первый набор градиентов, то там ещё сильную роль играет контраст. При перехоже от яркого к светлому бандинг более заметен, чем при переходе от тёмного к тёмному.
Кстати, вот ещё градиент: http://i.imgur.com/4TRJ8Hl.png
На сей раз равномерный. Вверху - dithering, внизу — без оного.Попробуй ещё проверить на других мониторах, если есть под рукой. У меня на LG M2794D картинка всегда хуже была, чем на 19-дюймовом ноуте.
> Lain_13 уже подготовил различные варианты градиента.Ога. И там можно вполне себе ощутить все вышесказанное.
> Модель своего монитора я озвучил, не про, но вполне нормальный.
Ну да, по крайней мере не TN. Не понимаю, вы никогда не видели фото с небом и облаками в крапинку? Присмотритесь - на IPS наверное увидите, если там электроника не полное г.
> Пока я склоняюсь к мнению, что вижу погрешности монитора, так как часть
> цветовых градиентов я вижу непрерывными.Возможно. У себя на более старшем dell я периодически вижу "dither" на плавных переходах типа неба/облаков. Если фотограф делал обработку на абы каком мониторе - там это можно и не заметить наверное. А по факту - надо шумодава было вызывать...
> цветовыми пространствами.
Спасибо, капитан :). Правда под динамическим диапазоном тоже понимают разные величины. И все те циферки типа 100500:1 обычно получают еще и с учетом управления подсветкой. А реально у LCD динамический диапазон довольно умеренный в плане возможных отличий между самым темным и самым светлым участком картинки.
> Соответственно 10 бит нужны, чтобы компенсировать большую контрастность
> между полутонами.Реально LCD обладают технологическими проблемами по поводу динамического диапазона (сложно поглотить свет на ровно 100% при хорошей максимальной яркости). Так что отличие самой яркой и самой темной области - достаточно компромиссная величина. У IPS в частности черный цвет обычно не такой уж и полностью черный. Вроде разновидности *VA и прочих, на основе затей самсуня в этом получше. Но там свои грабли. А какие-нибудь OLED например - по мере эксплуатации выцветают неравномерно (что наверное очень доставляло бы работающим с графикой, если б их делали большими).
> Мне кажется, что средний монитор показывает меньше цветов, чем влезает в 8 бит на канал.
Однако неидеальность картинки при смене значений битов вы вполне можете увидеть. А цель - видеть все-таки картинку. А не пикселы или биты составляющих.
нормально там все. H265 это, утрируя - H264/AVC "облагороженный" кодом из X264, который те позволили использовать. отчасти в обмен на обещание не докапываться до них по поводу патентов.
Надо больше паразитов, кормящихся с патентов. Чтобы производители аппаратных кодеров и декодеров семь раз подумали и один раз реализовали поддержку открытых форматов.
Иначе толку от VP9 и Daala без аппаратной поддержки видеопроцессорами очень мало.
> Иначе толку от VP9 и Daala без аппаратной поддержки видеопроцессорами очень мало.Большинство новых SoC поддерживают VP8, а самые новые и VP9, довольно массово. А Daala поддерживать сейчас - извините, это PoC а не готовый кодек пока, по поводу чего его никто не будет в железо сейчас пихать. Это начнется не ранее того как формат данных будет финализирован и будет гарантия что генеримый железкой поток - понимаем декодерами этого формата. А то сделаете вы железок, а они возьмут да и изменят кодирование. И придется вам кучу чипов под пресс, да? :)
> О намерении интегрировать в свои продукты поддержку VP9 ранее уже объявили такие компании, какДа, да, да... А только что-то не видно этих продуктов. Даже самые дешёвые видеорегистраторы и платы видеозахвата - с поддержкой H.264. Потому что производителю железки проще заплатить производителю чипа надбавку за патентные отчисления, чем перерисовывать схемы и переписывать прошивку под свободный кодек.
Кто не успел - тот опоздал, увы.
Потому что производители этих самых дешевых плат, скорее всео, вообще никому ничего не платили. Тоже неплохой подход, в общем-то, но в большом масштабе, к сожалению, не прокатывает.А новость просто отличная. Они теперь будут год разираться и договариваться, а за это время свободные кодеки хорошо h.265 потеснят.
с разморозкой. HEVC уже год как встраивается во все новые мобильные SoC, а вот VP9 и тем более Daala там днем с огнем не сыщешь. Учитывая "невероятную" скорость кодирования libvpx - не исключено что это к лучшему.
> Учитывая "невероятную" скорость кодирования libvpxЭто скорее следствие, а не причина.
> HEVC уже год как встраивается во все новые мобильные SoC, а вот VP9Вот это - наглое вранье. Почти все SoC умеющие HEVC умеют и VP9. Гугель сильно постарался - они не только кодек подогнали, но и бесплатно раздают IP-блок кодера/декодера VP8/9. По поводу чего VP9 нынче есть даже у последних китайцев.
> и тем более Daala там днем с огнем не сыщешь.
А у этих еще нет финальных спеков - в железо им еще рано.
> Учитывая "невероятную" скорость кодирования libvpx - не исключено что это к лучшему.
Вот что-что, а когда вопрос в максимально удачном соотношении битрейта и качества - скорость кодирование все-таки не главное. Кодируется то 1 раз. А с сервака потом отгружается дофига. И лучше пусть кодер поднапряжется 1 раз чем потом сервак потом постоянно напрягается. Но если что - гугл в этой будущей версии очень серьезно налег на скорость кодирования и многопоточность, так что вы еще не успели высказать недовольство, а гугель уже поработал над этим :).
Ничего что речь идёт про новые кодеки h265 и VP9. И так и этак переделывать схему.
Ну поддержка h265 уже есть в новых нвидиях
> Ну поддержка h265 уже есть в новых нвидияхЗамечательно. И как, сильно вам это помогло? :)
> Да, да, да... А только что-то не видно этих продуктов.Почти все новые SoC, повально.
> Кто не успел - тот опоздал, увы.
А H.265 - он вообще где? :) Покозырять прошлой версией - не того. А VP9 - вот он, играется браузерами. В многих новых гуглофонах - SoC с аппаратной поддержкой оного. А H.265 - в основном на бумаге...
Можно поподробнее про более высокий, чем у H265 уровень сжатия у VP9?
Мне казалось, он едва у H264 выигрывает.
Да, как то желто, нужны ссылки на четкие сравнения. То что я нахожу показывает незначительное превосходство h265 над vp9
> Мне казалось, он едва у H264 выигрывает.Насчет "едва" - на медленном сжатии он запросто делает H.264 и по размеру файла и по качеству картинки. И это уже играется в браузере. А H.265 - он вообще где?
Он в стандарте Ultra HD Blu-ray этого года, а также в любом UHD телевизоре (цифровое вещание может идти в этом формате, любой телевизор обязан принимать).
Аппаратно декодируется последними видяхами NVidia, в этом году AMD обещает добавить поддержку в свои APU.Он ощутимо лучше H.264 на большом кадре (4K). На меньшем *острой* необходимости в нем нет, хотя то же качество при битрейте на 30% меньше он может дать.
> Он в стандарте Ultra HD Blu-ray этого года,Круто. Правда у меня нет ни единого привода блурэя. Я думаю что этот ультра-блюв будет ждать еще более фееричный провал чем оригинальный блюрэй. Время пластмассовых блинчиков закончилось - половина девайсов идет просто без привода. А матрица в планшетке - получше большинства ноутов и дешевых мониторов...
> а также в любом UHD телевизоре (цифровое вещание может идти в этом формате,
> любой телевизор обязан принимать).Ога, красиво было на бумаге.
> Аппаратно декодируется последними видяхами NVidia, в этом году AMD обещает
> добавить поддержку в свои APU.Да пусть себе обещают. Где вы с ним сталкиваться то собираетесь?
> Он ощутимо лучше H.264 на большом кадре (4K).
Ну во первых - мониторы и телевизоры все все-таки менять не побегут. А самое популярное в вебе вообще вроде как ноутбучное 1366х768, или как его там.
Ну вот от VP9 - мы все выигрываем уже сейчас: он есть в лисе и хроме, сайты могут выкладывать видео в VP9 и при меньшем битрейте получить более хорошее качество. В том числе обставив H.264. А HEVC мне где вообще брать то? Нет, у меня нет блюрэй приводов и не планируется :)
> меньше он может дать.
Может. Но это актуально в основном в вебе. Где скотские условия сабжевых контор ставят крест на внедрегии - там то лоха не кинешь на пяток баксов на патенные отчисления с каждого телека за килобакс, где в килобаксе не очень заметны эти 5 баксов.
> сайты могут выкладывать видео в VP9Могут, но не делают так. Есть одна проблема - несвободные кодеки поддерживают по сути все браузеры. А свободные кодеки - нет. Поэтому сайты выбирают несвободные.
>> сайты могут выкладывать видео в VP9
> Могут, но не делают так.Ютубу это расскажешь, да? Который и VP8 и VP9 использует и является чуть ли не монополистом в своей нише :)
> Есть одна проблема - несвободные кодеки поддерживают по сути все браузеры.
Не вижу браузеров поддерживающих H.265, а VP9 - вижу. Такая фигня.
> сайты выбирают несвободные.
Что-то не вижу выбирающих H.265...
Ну и жуй дальше зондовый гугл, я могу сходу ещё два (но малоизвестных) сервиса назвать, которые используют свободные кодеки. Остальная гора сервисов используют несвободные.
> Не вижу браузеров поддерживающих H.265Я в общем говорил про несвободные кодеки, H.265 недавно появился, поэтому пока не используется. Но твой любимый гугл уже встроил его поддержку в ведроид лолипоп, ну и запиливание в хромиум в процессе.
PS: "кококо, не нужно" - не меняют реальной картины
PSS: может помнишь как в 2011 году все говорили, что гугл удалит поддержку h.264 из хрома. Тогда и опера с мозилой поддерживали только свободные кодеки, но потом прогнулись - рынок...
Зачем оно все нужно, когда есть ASCII video.
И ссылка на ютуб который гонит vp9.
А также ASCII прекрасно сжимается.
> Зачем оно все нужно, когда есть ASCII video.А сам сослался на ютуб, где оно в VP8/9 и H.264. И, заметим, никакого H.265 :)
> Так как производителям оборудования и владельцам видеосервисов придётся платить в два кармана, стоимость лицензирования HEVC/H.265 будет значительно больше, чем ожидалось ранееПлатить двум правообладателям не означает платить в 2 раза больше. Может так получиться, что платить придётся в 20 раз меньше.
Думаешь MPEG LA решат уменьшить свои аппетиты на порядок лишь из-за того, что к этой кормушке решил присосаться кто-то ещё? С какой бы это радости? Максимум на половину, да и то крайне сомнительно.
> Платить двум правообладателям не означает платить в 2 раза больше. Может так
> получиться, что платить придётся в 20 раз меньше.В любом случае, в 2 раза больше гемора с лицензированием. Вот хочу я поставить сервер и гнать с него видео, транскодируя на ходу, допустим. А хотя-бы даже и в штатах, где бандвиза хоть залейся и вычислительные мощности дешевые. Мне вообще нафиг не упало при этом с какими-то мпеглами что-то утраясать, а с двумя - и подавно.
> Мне вообще нафиг не упало при этом с какими-то мпеглами что-то утраясатьНу тогда или свободные кодеки (и то остаётся риск успешных попыток торпедирования мпеглами), или ворочайтесь ночами в ожидании демократического иска...
> Ну тогда или свободные кодеки (и то остаётся риск успешных попыток торпедирования
> мпеглами), или ворочайтесь ночами в ожидании демократического иска...Это лучше чем платить в 10 раз больше, получая мизерные ресурсы и кучу проблем типа неадекватного стаффа, произвола силовиков, всеобщего по...изма на участь клиента, ВНЕЗАПНОсти типа потери питания ДЦом невзирая на троекратное резервирование, падучий роутинг и выходки совком-телекома, хакающего трафф. Даже транзитный.
Я уже писал о моем опыте решения проблем маршрутизации с совком-телекома. Добавки я не хочу. Меня совершенно не прельщает перспектива конвертировать чужое раздолбайство в мои проблемы.
> Я уже писал о моем опытеДа дело-то всё так же Ваше, только потом не плачьтесь в том же стиле, что не предупреждали ;-)
HEVC/H.265, покойся с миром...
> HEVC/H.265, покойся с миром...И не надейтесь. Некрофилия нынче в тренде.
> И не надейтесь. Некрофилия нынче в тренде.И где он применяется? VP9 вот например играется в большинстве браузеров. Сейчас. Так что если эти горе-стандартизаторы и дальше будут так себя вести - инициативу перехватит гугл.
