ORIGINAL: новик

А если серьёзно, то ответ очевиден - при недостатке информации (возможно, теряющихся из-за плохого кабеля) видеопроцессор приёмного устройства пытается из полученной информации выжать максимум, в том числе - и с помощью интерполяции информации от соседних пикселей. Как бы успешно он это не делал, потеря детализации (в большей или меньшей степени) неизбежна.

Тогда есть провокационный вопрос: если механизм передачи данных не предоставляет информации, какие именно биты испорчены и испорчены ли они вообще, то откуда об этом узнает видеопроцессор?

ORIGINAL: новик

Что значит не предоставляет? Как минимум, проверка контрольной суммы позволяет выявить, пришла ли информация в первоначальном виде или были искажения. Честно говоря, лень копаться, где-то (по моему, в STEREO&VIDEO) была интереснейшая статья об интерфейсе HDMI. Там подробно описывались, в том числе, и методы повышения устойчивости передачи информации через этот интерфейс.

Вызов принят. Мне не лень копаться и я уже скачал спецификацию HDMI, если там ничего такого нет, будет что-то страшное. Лучше для тебя, чтобы оно там было.

Какие угрозы, дорогой? Это мы по доброму выясняем факты.
Готовься, сейчас что-то будет. Сначала тебя обложу фактами, потом загрызу. Жди следующего поста, он будет немаленький.

Странный тогда у тебя юмор, МегаБи... не добрый какой-то..

На это я могу сказать одной известной фразой:

Не надо называть бабушку дурой, не потому что обзываться плохо, и не потому, что бабушка умная, а потому, что бабушка может озвереть.

МегаБи, что с тобой? Ты что, как в мультике про кота Леопольда, "озверина" объелся?
Не с кем я здесь грызться не собираюсь, так что можешь не волноваться и успокоиться.

ORIGINAL: новик

про кодирование с избыточностью - это понятно... но опять таки - если будет избытычность - то значит можно восстановить исходные данные... а у тебя получается что можно восстановить, но очень приблизительно... интересный алгоритм...

Про избыточность - согласен. Но и ты, полагаю, не будешь возражать, что 100% надёжного алгоритма восстановления утраченной информации до сих пор не изобретено. При больших количествах ошибок алгоритм восстановления просто не справляется.

Представляется, что при использовании менее качественного кабеля, количество ошибок при передаче данных увеличивается, алгоритм восстановления информации не может 100% устранить все ошибки, в результате на вход видеопроцессора поступают, в том числе, и информация с пометкой о её недостоверности.
На основании этой пометки видеопроцессор принимает решение восстановить параметры пикселя путём интерполяции параметров N-го количества соседних пикселей. С известным успехом это ему удаётся, но побочный эффект такой интерполяции - "замыленность" картинки.
Где-то так...

хм... небольшое кол-во ошибок исправятся... большое кол-во ошибок приведут к такому результату из которого просто не получится проинтеполировать нормальную картинку (тем более что соседние пиксели закодированны в том же битом блоке)...
значит у тебя слишком умный процессор в мониторе и слишком хреновый кабель был вначале... и вумный процессор просто скрыл от тебя брак кабеля... (хотя я таки больше склоняюсь варианту самовнушения =)

а насчет того что у меня не работало 1080 на 10ти метровом кабеле - так там вообще даже handshake не проходил... устройства друг друга не видели (кстати разницы между 720 на 10ти метровом и полутораметровом кабеле я опять таки не видел)

P.S. 100% надежные алгоритмы восстановления ошибок давно существуют... но с ограничением кол-ва восстанавливаемых ошибок... =(

Передача информации, в частности, видео по интерфейсу HDMI.

Пионеры, в частности, могут для начала ознакомиться с текстом по ссылкам:
http://electronics.howstuffworks.com/hdmi.htm
http://electronics.howstuffworks.com/hdmi1.htm
http://electronics.howstuffworks.com/hdmi2.htm


Далее следует написанное по материалам спецификации: High-Definition Multimedia Interface Specification Version 1.3a (текст от 10 ноября 2006 года).

Логически, интерфейс HDMI представляет собой три канала передачи информации, и несколько других информационных соединений, к которым относятся сигнал тактирования ( clock), линия обмена мониторной информацией (DDC), линия передачи управляющих сигналов (CEC) и некоторые другие, которые нас также не интересуют.

Информация передается по трем основным каналам, используя TDMS - дифференциальный способ передачи сигнала по витым парам.

Физический уровень передачи рассматривать не имеет смысла, т.к. к коррекции ошибок (про которую наводится поклёп) он никакого отношения не имеет.

Переходим к канальному уровню (5 глава спецификации)
Что передается в этих каналах?
Читаем пункт 5.1.



Передаваемая информация бъется на пакеты, и подвергается преобразованиям, в зависимости от типа передаваемого.
Возможны варианты:
видео (Video Data Period), при этом передаются пиксели строки
данные (Data Island period), в этом режиме передаются аудио-пакеты и вспомогательная информация
управление (Control period), если передавать нечего, передача идет с этим типом, а также используется для разделения между первыми двумя типами (чтобы те шли не подряд).



В любом из этих режимов на выходе TDMS трансмиттера идут 10 бит информации на один такт (по каждой из трех линий).
Объем входа на такт зависит от типа передаваемых данных и для видео равен 8 бит на каждой из линий.
Для содержимого типа данных (в т.ч. аудио) данные преобразуются с избыточностью из 4 бит до 10.

Для видео предусмотрен защитный блок (Guard Band), он предназначен для более аккуратного отделения и определения различных видео компонент - G от R  и от B, а также видео от данных. Для пакетов данных тоже предусмотрены свои защитные блоки.

Преобразование аудио нас не интересует, т.к. по утверждениям обвиняемого он заметил глазом

Если описАть эффект в двух словах - такое впечатление, что взяли тряпку и протёрли экран от пыли. Качество изображения улучшилось практически по всем параметрам.
...
Тем не менее... Абсолютно точно улучшились резкость и детализация, мелкие детали на заднем плане стали менее "замыленными". Так же цвета стали более... не знаю...  "сочными" что ли.
...
А если серьёзно, то ответ очевиден - при недостатке информации (возможно, теряющихся из-за плохого кабеля) видеопроцессор приёмного устройства пытается из полученной информации выжать максимум, в том числе - и с помощью интерполяции информации от соседних пикселей. Как бы успешно он это не делал, потеря детализации (в большей или меньшей степени) неизбежна.
...
Что значит не предоставляет? Как минимум, проверка контрольной суммы позволяет выявить, пришла ли информация в первоначальном виде или были искажения. Честно говоря, лень копаться, ...

т.е. речь не идет о его ушах.

Заодно заметим, что утверждение

ORIGINAL: tch
http://forum.totaldvd.ru/fb.aspx?m=940085

Насколько я понимаю HDMI использует TERC4 для кодирования сигнала и этот способ не дает 100% гарантии от ошибок передачи при больших количествах ошибок.

В контексте обсуждения HDMI является полуправдой, т.к. используется только для аудио и данных, но не для видео.

Видео предваряется префиксом, содержащим, защитный блок и некоторую управляющую информацию (п. 5.2.1 текста).

Преобразования, осуществляемые в направлении 8 бит -> 10 бит , описаны в разделе 5.4.4.
Перед этим, в разделе 5.2.2 говорится, что после префиксов

During active video periods, 24 bits of pixel data are encoded using TMDS transition minimized
encoding during each TMDS clock period.

Имеются ввиду 3 канала, передающие по 8 бит чистой информации за один такт.

Сам этот способ преобразования (TMDS transition minimized encoding) и описан в п. 5.4.4.

Здесь придется привести три абзаца цитаты на английском

During video data, where each 10-bit character represents 8 bits of pixel data, the encoded
characters provide an approximate DC balance as well as a reduction in the number of transitions
in the data stream. The encode process for the active data period can be viewed in two stages.
The first stage produces a transition-minimized 9-bit code word from the input 8 bits. The second
stage produces a 10-bit code word, the finished TMDS character, which will manage the overall
DC balance of the transmitted stream of characters.

The 9-bit code word produced by the first stage of the encoder is made up of an 8-bit
representation of the transitions found in the input 8 bits, plus a one-bit flag to indicate which of
two methods was used to describe the transitions. In both cases, the LSb of the output matches
the LSb of the input. With a starting value established, the remaining 7 bits of the output word is
derived from sequential exclusive OR (XOR) or exclusive NOR (XNOR) functions of each bit of
the input with the previously derived bit. The choice between XOR and XNOR logic is made such
that the encoded values contain the fewest possible transitions, and the ninth bit of the code word
is used to indicate whether XOR or XNOR functions were used to derive the output code word.
The decode of this 9-bit code word is simply a matter of applying either XOR or XNOR gates to
the adjacent bits of the code, with the LSb passing from decoder input to decoder output
unchanged.

The second stage of the encoder performs an approximate DC balance on the transmitted stream
by selectively inverting the 8 data bits of the 9-bit code words produced by the first stage. A tenth
bit is added to the code word, to indicate when the inversion has been made. The encoder
determines when to invert the next character based on the running disparity between ones and
zeros that it tracks in the transmitted stream, and the number of ones and zeros found in the
current code word. If too many ones have been transmitted and the input contains more ones
than zeros, the code word is inverted. This dynamic encoding decision at the Source is simply
decoded at the Sink by the conditional inversion of the input code word based on the tenth bit of
the TMDS character. The TMDS code mapping is specified by Figure 5-7 with the definitions of
Table 5-35. The encoder produces one of 460 unique 10-bit characters. The encoder shall not
generate any other 10-bit character during a Video Data Period.

Фактически, преобразование состоит из двух шагов.
Сначала биты преобразуются в последовательность переключений (так делают во многих других стандартах), результатом является 9 бит, где 8 бит это преобразованные исходные данные и девятый бит говорит о том, какое из двух возможных логических преобразований использовалось.
Затем, на втором шаге, последовательность из 9 бит преобразуется в 10 бит. Здесь данные 9 бит или оставляются без изменений, или инвертируются. В зависимости от того, какое из действий было предпринято, 10й бит устанавливается в 0 или 1.

И всё, дальнейшие преобразования видео сигнала на этом закончены и символ из 10 бит уходит на передачу.

При приеме данных идет разбор, выясняется нужна ли инверсия, а затем, восстановив 9 бит промежуточного шага, выясняется, каким из двух методов биты были преобразованы в последовательность переключений битов на первом шаге передачи.

Теперь злые вопросы:

Где здесь контрольные суммы?
Как узнать, что какой-то из пикселей был передан с ошибкой?

Как догадаться, что именно нужно делать с картинкой.

На основании вышеизложенного считаю утверждение

Что значит не предоставляет? Как минимум, проверка контрольной суммы позволяет выявить, пришла ли информация в первоначальном виде или были искажения.

считаю, в контексте обсуждения передачи видео по HDMI безответственными, лживыми и вводящими в заблуждение.

Утверждение

Абсолютно точно улучшились резкость и детализация, мелкие детали на заднем плане стали менее "замыленными". Так же цвета стали более... не знаю...  "сочными" что ли.

считаю в контексте дискуссии субъективным, и попытку его оправдать техническими намёками (технических фактов не было) считаю грязной инсинуацией.

За свои слова отвечаю.

МегаБи, проведённая тобою работа внушает уважение.

Честно говоря, понял % на 60 (возможно, больше понять уже и не смогу - квалификация уже не та), и вникать глубже нет сил (целый день проторчал на таможне, всю душу вымотали).

Возникает один вопрос - не допускаешь ли ты, что информация, поступающая для преобразования 8  -> 10 бит уже избыточна, то есть содержит проверочные коды?

Или ты на полном серьёзе утверждаешь, что информация передаётся с нулевой избыточностью, т.е. вообще никак не защищена от возможного внешнего воздействия и искажения?
Знаешь, элементарная логика протестует против этого.

ЗЫ: кстати, если представить, что поток данных идёт по ХДМИ с нулевой избыточностью, тогда роль качества самого кабеля возрастает многократно и имеет сильнейшее влияние на качество картинки.

новик - я заканчивал ТРТУ

Я так и думал :-).

Что-то вы с МегаБи накинулись на меня так агрессивно... вот только с противоположных позиций.
Ты утверждаешь, что алгоритмы восстановления информации полностью компенсируют возможные ошибки, вносимые кабелем, и, как следствие, качество кабеля не имеет никакого значения.

МегаБи же утверждает, что сигнал не несёт вообще никаких проверочных кодов, т.е  фактически ничем не защищён.

Голова идёт кругом.[sm=be.gif]

ORIGINAL: новик

новик - я заканчивал ТРТУ

Я так и думал :-).

Что-то вы с МегаБи накинулись на меня так агрессивно... вот только с противоположных позиций.
Ты утверждаешь, что алгоритмы восстановления информации полностью компенсируют возможные ошибки, вносимые кабелем, и, как следствие, качество кабеля не имеет никакого значения.

МегаБи же утверждает, что сигнал не несёт вообще никаких проверочных кодов, т.е  фактически ничем не защищён.

Голова идёт кругом.[sm=be.gif]

Я не утверждал что алгоритмы полностью компенсируют... я утверждал что если видео кодируется с избыточностью то оно или полностью восстанавливается (если кол-во ошибок в пределах возможности алгоритма восстановления) или получим изображение сильно отличающееся от оригинала (а не замыленное и с потерянными деталями).
Как оказалось что оно без избыточности и даже без CRC (!) тогда и получим снег... (тем паче - тут уже от процессора на стороне экрана ничего не будет зависеть и он не сможет вытягивать из мусора картинку...)

P.S. может у тебя на мониторе постоянно включен адаптивный шумодав который на плохом кабеле размывает снег и ты видешь замыленную картинку, а на хорошем кабеле для него работы меньше ? хотя этот вариант достаточно абсурден (потому что результаты шумодава будут видны даже на идеальной картинке).

Насчет преобразования 8->10 бит.
Оно, теоретически, добавляет некоторую избыточность, но по способу построения двух дополнительных бит и по способу использования их при декодировании, нет никакой возможности эту избыточность использовать.
Это связано и с примитивным характером преобразования, и тем, что преобразование преследует совсем другую цель, а именно нормализацию сигнала по энергии в канале связи.

Теперь по поводу защищённости от помех:
Видео (в HDMI, и в DVI тоже) не защищено от помех никак, whatsoever.
Аудио защищено алгебраическим кодом TERC4, который из 4 бит делает 10. Стоит думать, что по способу построения кода (это можно уточнить в спецификации) он не выполняет функции верификации.
Это означает, что он справляется, если количество ошибок меньше порогового и не справляется, если ошибок больше. Различить эти ситуации (превышение порога ошибок) нельзя.
Тем не менее избыточность есть и она помогает.
Для служебных данных, помимо TERC4, дополнительно может применяться контрольная сумма, а для аудио ситуация зависит от того, сжатое ли оно изначально.
Если несжатое, то ничего больше не проверяется. Если же имеет место сжатие, то может быть возможность (надо смотреть стандарты соотв. форматов) в заголовок фрейма загнать контрольную сумму и уже декодер звука будет сам разбираться, что делать с фреймом, у которого разрушена структура.

Отсюда следует характер разрушения сигнала при наличии помех.
При умеренных помехах для видео возможно появление видимых артефактов типа снега или искрения отдельных точек, а для аудио при слабом уровне помех вообще ничего не будет заметно, а при повышении следует ожидать заикания сжатых форматов, или щелчков-треска для несжатых.
При более сильных уровнях помех будет разрушена синхронизация и тогда сигналу придёт капец.