?

Log in

No account? Create an account
Previous Entry Share Next Entry
2016-01

поток сознания на тему information theory

в описаниях всяческих навороченных способах кодирования и передачи информации (Reed-Solomon и прочие FEC, торрент, progressive JPEG, rateless/fountain коды, LZ4, PAQ и прочие подобные) часто не хватает важной штуки - graceful degradation, или, в каком-то смысле, latency.

в целом вот понятно, что shannon capacity канала можно достигать сколь угодно эффективно, но при этом выходит, что чем ближе код к этой самой капасити - тем больше процентов (пакетов? ну положим что у нас erasure) надо получить, чтобы хоть что-то увидеть.

и если для arbitrary bitstream'ов это еще как-то обьяснимо (ну надо нам найти точное решение уравнения, никуда не денемся), то для картинок, звука и прочего очень часто хочется всякого graceful degradation, ну, как у того же прогрессивного жпега или FLIF (новый лосслесс кодек для картинок, гуглится)

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

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

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

This entry was originally posted at http://wizzard.dreamwidth.org/450177.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
lyuden October 22nd, 2015
Разлагать всю картинку на фичи (например шахматная доска, круг в центре экрана и т.д.), ну например разлагать всю картинку в ряд Фурье. При потере нескольких фич общий смысл картинки останется, но пойдут разные глючные артефакты.

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

jakobz October 22nd, 2015
Так так видео-кодеки и работают - сохраняют разницу с предыдущим кадром. Основываясь на предыдущем кадре, кадре до него, и прочих фазах луны.

Когда в кино с торрентов, или телеке на цифровом канале вылетает битик - прекрасно все видно как оно работает.

Viktor Sovietov October 22nd, 2015
это фрактальную сжимачку надо...

jakobz October 22nd, 2015
Вообще, я тоже принципиальных каких-то проблем не вижу, как дилетант.

Т.е. задача примерно такая: взять 5-ти секундный кусок видео, и всякое про детали - засунуть назад. А всякое важное - вперед. Чтобы если человек не успел докачать - проиграть что есть, без деталей. Хотя думаю что тут примерно история такая: усираться надо дохера, а визуально - будет заметно дергание туда-сюда. Юзер скажет что-то типа "включите мне уже мои честные 320p, или выключите этот цирк совсем".

Можно levgem-а позвать попробовать - он шарит.

Edited at 2015-10-22 09:48 pm (UTC)

wizzard0 October 22nd, 2015
ненене, у меня считай UDP, и пакеты проебываются, а не "файл не докачался"

jakobz October 22nd, 2015
Кстати, с тем что веб-страничка умеет грузиться потихоньку, дергаясь и конвульсируя - сейчас тоже ведь все борятся. Какими-нибудь там когнитивными анимациями, например. Ну или перформансом, у кого есть.

Т.е. современному юзеру надо application-feel, ему надо чтобы сначало было черное, потом сразу белое появилось, и в процессе глаза не ебло.

Короче даже для HTML идея progressive чото-там - обломалась.

sassa_nf October 22nd, 2015
ну тут-то вариант другой. Пришло изображение ногами вперед. Рид-Соломон задерживается. Если он не успевает до скольки-то милисекунд, показываем, что есть. Картинку не будем улучшать, т.к. через 40мс новую нужно рисовать. Никаких "дерганий" как с ХТМЛ не предвидится.

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

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

redreptiloid October 22nd, 2015
а почему не видно принципиальных причин ?
imho, навскидку интуитивно представить, если взять кубики (обычные детские) и выкладывать из них картинку то она займет в пространстве больший объем чем если кубики паковать плотно, из-за неявной информации хранящейся в "пустых местах". ну и "хоть какая то картинка+картинка в хорошем качестве" несут больше информации в кадре чем "картинка в хорошем качестве". цели оптимизации разные получаются.
я бы больше уделял внимание обработке на стороне передатчика, "векторизуя" картинку - позволит понимать суть фильма а отдельные детали передавая уже по указанию пользователя.

wizzard0 October 22nd, 2015
> а почему не видно принципиальных причин ?
скажем так, можно закодировать высокий битрейт (это то что есть), можно низкий избыточно + высокий, а хочется низкий избыточно + (высокий на базе низкого).

pound_sterling October 22nd, 2015
имхо
решение такой проблемы - это прорыв, научное достижение как теория относительности,
потому что поток информации (видео, аудио, графику, текст и тд)
нужно будет научиться резать
не поперек а вдоль.

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

...

wizzard0 October 22nd, 2015
да, что-то в таком духе. его не делают еще и потому, что обычно кодек работает поверх надежного канала, который доставляет таки все биты, и кусочки из него не пропадают просто так.

sab123 October 22nd, 2015
Ну, сермяжное решение через избыточность может быть таким:

Перевести картинку в низкое разрешение/битрейт. Закодировать. Условно говоря, положить в сторону. Теперь вычесть эту картинку из полной. Закодировать отдельно. Взять положенную в сторону картинку в низком разрешении и присобачить каждый ее пакет к скажем трем или десяти пакетам высокого разрешения. Эти сборные пакеты послать. Ну или не присобачивать, а просто посылать данные низкого разрешения отдельно во многих экземплярах. На приемной стороне раскодировать обе части и сложить. Показать полученное.

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

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

wizzard0 October 22nd, 2015
тут надо учитывать, что baseline, который мы пытаемся обогнать - это h.263/h.265, state of the art видеокодеки :)

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

sergey_cheban October 22nd, 2015
Как вариант: кодируем ч/б изображение с большой избыточностью, а цветность - с маленькой. При увеличении уровня шума изображение деградирует до ч/б.
Но вообще-то в таких ситуациях обратная связь рулит: она позволяет при снижении качества канала перенастроить кодек на более низкую скорость, а оставшиеся биты пустить на избыточность.

wizzard0 October 22nd, 2015
а вот нету обратной связи, увы.

livejournal October 23rd, 2015
Здравствуйте! Ваша запись попала в топ-25 популярных записей LiveJournal для Украины. Подробнее о рейтинге читайте в Справке.

justy_tylor October 23rd, 2015
Я пока не очень проснулся, но поймал мысль: а какова вероятность того, что именно дропнутся хвосты первого кадра, но дойдёт голова второго?

wizzard0 October 23rd, 2015
ну вот голову мы можем закодировать с большей избыточностью

serbod October 23rd, 2015
Простое решение - каждый кадр представить как N частей размером не более MTU (1200 байт, например), при этом каждая часть содержит каждый N-ый пиксель кадра. Получив даже один пакет кадра, уже имеем картинку размером с иконку, растянув ее на весь экран. И чем больше пакетов получим, тем подробнее будет кадр.


thedeemon October 24th, 2015
Качество говно будет. Ибо намеренно теряется использование корреляций между близкими точками, а она дает львиную долю всего сжатия. А если корреляции использовать, то теряется независимость блоков, потеря одного отразится на внешнем виде других.

murkt October 23rd, 2015
Привет, прочти вот этот пост x264: the best low-latency video streaming platform in the world, может он натолкнёт тебя на нужные мысли. Цитата для затравки:

Without keyframes, it’s feasible to make every frame capped to the same size. With each frame split into packet-sized slices and the image constantly being refreshed by the magic intra refresh column, packet loss resilience skyrocketed, with a videoconference being “watchable” at losses as absurd as 25%.

No longer does 200ms seem out of reach. If anything, it’s now far more than we need. Because with –tune zerolatency, single-frame VBV, and intra refresh, x264 can achieve end-to-end latency (not including transport) of under 10 milliseconds for an 800×600 video stream.

wizzard0 October 23rd, 2015
Пост хороший, да.

Видео, правда, совсем другое, но мысли появились. Спасибо :)

thedeemon October 24th, 2015

wizzard0 October 25th, 2015
Нууууууу, скажем так, гораздо ближе вот это - https://en.wikipedia.org/wiki/Hierarchical_modulation, но то что это именно так называется - я не знал, так что спасибо за ссылку :)

  • 1