[des00 25]

Это как сравнить. При одинаковом битрейте качество mjpeg будет многократно ниже. То есть да — он хорош, но ценой толстого канала, для которого, условно, на тысячу бит приходится меньше информации.

 

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

 

То есть Вы понимаете, какой выигрыш можно получить в ОСШ при увеличении сжатия в 10-20 раз при сохранении качества. Я об этом.

UPD: имею в виду фильтр ПЧ и, соотв., чувствительность приемника.

Думаю что тут нужно договориться о терминах, а именно что сравнивать.

 

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

 

Если ставим во главу угла сравнить системы с одинаковым радиоканалом (полоса, индекс модуляции, кодирование и т.д.), то при одинаковом чутье, при работе в шумах, ИМХО кодер без контекстной зависимости между кадрами/битами в битстриме (как в 264) даст более качественную картинку. Как раз за счет того, что он менее чувствителен к выпадению бит. (в 264 ом что будет с P фреймом, если была куча ошибок в референсных фреймах, да еще и деблок постарается все это Г размазать). Именно про это я и говорил.

 

Если цель вашей диссертации 1, тогда моя фраза мимо кассы. Если 2, тогда обсуждаемо.

 

То есть Вы понимаете, какой выигрыш можно получить в ОСШ при увеличении сжатия в 10-20 раз при сохранении качества. Я об этом.

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

 

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

[x736C 0]

Вторая формулировка задачи выглидит слегка искусственной. Если мы имеем систему передачи данных с фиксированными параметрами, то выбор кодека мне представляется банальной задачей. При одинаковой ширине канала мы получим две совершенно разные по системным требованиям системы. Обычно все-таки от них и пляшут. То есть начинают синтез системы с оптимальными характеристиками от потребного качества. И меня как раз первый вопрос в Вашей формулировке интересует. Видимо, стоит провести дополнительное исследование зависимости качества видео от BER. Прежнее было очень общим. Тут играет роль даже плеер. Один дает зелень на весь экран, а на другом картинка тупо зависает.

Но у меня в соавторстве как раз создатель такого контекстного кодека, который описывает сцену, выдавая в результате исчезающе малое количество информации. Для кино не пойдет, а для телеуправления вполне.

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

 

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

Это уже было проделано (не мной), но случайным образом на разных BER. При условии «без передачи» могу Вам скинуть краткий отчет с картинками, если интересно.

[blackfin 23]

Если ставим во главу угла сравнить системы с одинаковым радиоканалом (полоса, индекс модуляции, кодирование и т.д.), то при одинаковом чутье, при работе в шумах, ИМХО кодер без контекстной зависимости между кадрами/битами в битстриме (как в 264) даст более качественную картинку. Как раз за счет того, что он менее чувствителен к выпадению бит. (в 264 ом что будет с P фреймом, если была куча ошибок в референсных фреймах, да еще и деблок постарается все это Г размазать).

H.264 кодер тоже можно настроить для работы "без контекстной зависимости между кадрами" в битстриме:

The H.264-MP-E core can be configured to operate on Intra-Only mode, offering compression efficiency superior than this of JPEG and competitive to this of JPEG2000.

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

Для "работы в канале с замираниями и пр." стандарт H.264 предлагает использовать режим "slice data partitioning". В этом режиме весь битстрим делится на три отдельных потока - partitions A,B и C.

 

Partitions A содержат заголовочную информацию для синтаксических элементов 2-ой категории: матрицы квантования и пр. служебную информацию о видео в целом. Эту информацию следует передавать в отдельном потоке с низким BER.

 

Partitions B содержат информацию для синтаксических элементов 3-ей категории: пикселы макроблоков типа I и SI. Эту информацию тоже можно передавать в отдельном потоке с низким BER, но не настолько низким как у Partitions A.

 

Partitions C содержат информацию для синтаксических элементов 4-ой категории: пикселы макроблоков типа P, SP и B. Эту информацию тоже можно передавать в отдельном потоке с высоким BER, имея ввиду, что декодер должен уметь обнаруживать факт потери пакета типа С и уметь замещать потерянный слайс типа P, SP или B слайсами из соседних фреймов.

 

Понятно, что дешевые H.264 кодеры/декодеры такими широкими возможностями, скорей всего, не обладают. Но это не означает, что H.264 хуже приспособлен для работы в канале с высоким BER, чем MJPEG.

[Plain 195]

Видимо, стоит провести дополнительное исследование зависимости качества видео от BER.

Звучит нескрываемо витиевато, потому как BER=1 никакое не "дополнительное", а самое что ни на есть основное.

[des00 25]

Но у меня в соавторстве как раз создатель такого контекстного кодека, который описывает сцену, выдавая в результате исчезающе малое количество информации. Для кино не пойдет, а для телеуправления вполне.

это как бы не 264 ый. судя по вашему описанию что-то типа вокодера? восстановление сцены из шума на приемном конце?

Это уже было проделано (не мной), но случайным образом на разных BER. При условии «без передачи» могу Вам скинуть краткий отчет с картинками, если интересно.

думаю что это будет интересно посмотреть всем %)

 

кодер тоже можно настроить для работы "без контекстной зависимости между кадрами" в битстриме:

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

Для "работы в канале с замираниями и пр." стандарт H.264 предлагает использовать режим "slice data partitioning". В этом режиме весь битстрим делится на три отдельных потока - partitions A,B и C.

..............

вы представляете реализацию модема который обеспечит вам 2 (положим что А и B передаются по одному каналу) канала с разным качеством? Тут либо делать пакетную передачу с разными видами модуляции, либо делать двухканальный модем. В любом случае нужно будет подготавливать потоки для передачи, выравнивать их на приеме и т.д. При этом как вы сами отметили не на любом декодере вы сможете проиграть такой стрим. Цена решения получается достаточно высокая.

 

Но это не означает, что H.264 хуже приспособлен для работы в канале с высоким BER, чем MJPEG.

Если обсуждать попугаи то да, 264 ый можно заставить работать на плохих каналах. Весь вопрос в цене итогового решения. Думаю что тем кто выбрал mjpeg решение нужно было чем быстрее тем лучше, а 264 ый энкодер/декодер можно пилить годами добиваясь качества.

 

[x736C 0]

Звучит нескрываемо витиевато, потому как BER=1 никакое не "дополнительное", а самое что ни на есть основное.

Речь выше шла о том, что прежнее исследование кодеков было проведено на каких-то средних параметрах. Менялись степень сжатия, кодеки и BER. На серьезное исследование вопроса не тянет. Но дает возможность сравнить h.264 и mjpeg между собой. А что такое BER=1?

 

это как бы не 264 ый. судя по вашему описанию что-то типа вокодера? восстановление сцены из шума на приемном конце?

Это что-то вроде распознавания речи и передачи ее в символьном виде. С h.264 это не связано. Просто желание попробовать новое в телеуправлении.

 

думаю что это будет интересно посмотреть всем %)

На всеобщее обозрение смогу выложить свое. Сами понимаете, чужое есть чужое. По головке не погладят. :)

 

Думаю что тем кто выбрал mjpeg решение нужно было чем быстрее тем лучше, а 264 ый энкодер/декодер можно пилить годами добиваясь качества.

Да, что-то такое. Важно было, чтоб можно было легко реализовать перемотку назад-вперед, покадровое воспроизведение. С h.264 надо повозиться. :)

 

UPD: Статьи по теме из открытых источников. Иерархическая QAM модуляция для более устойчивой передачи h.264, сравнение jpeg2000 с h.264 и т.д.

Video_for_UAV.zip

 

Изменено 10 июля, 2012 пользователем x736C

[Impartial 0]

А WiMAX, как вариант, не подходит?

[blackfin 23]

Если обсуждать попугаи то да, 264 ый можно заставить работать на плохих каналах. Весь вопрос в цене итогового решения. Думаю что тем кто выбрал mjpeg решение нужно было чем быстрее тем лучше, а 264 ый энкодер/декодер можно пилить годами добиваясь качества.

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

 

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

 

Ну и, естественно, полученный в результате этого ОКР'а "хай-тек" потом принято сравнивать по цене и параметрам с Predator'ом, но в отличие от General Atomics, свой БПЛА СтартАперы любезно готовы продавать по цене Мерседеса...

 

Time-To-Market рулИт..

[x736C 0]

blackfin, в Вашем сообщении почему-то читаются аллюзии к моей скромной персоне.

 

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

 

Но бывает еще так. Фирма интегратор покупает у крупной российской компании мега-супер камеру за дикие деньги, оплачивая фактически ОКР, и получает такие технические требования: «У нас свой собственный проприетарный mjpeg кодер». А системный подход — слабая сторона. Хотите h.264? Еще несколько миллионов и год разработки оплатите/подождите.

[MIkler 0]

Немного не так. Камера работает отдельно. Цифровой поток кодируется отдельным устройством с лучшим качеством и меньшим битрейтом чем h.264. Зачем переделывать, что то в другой формат не очень понятно. В аппаратной можно всегда поставить декодер сервер под этот закрытый кодек.

[x736C 0]

Mihail Gluhowchenko, почему меньшим битрейтом, чем h.264? Вообще фраза «с лучшим качеством и меньшим битрейтом, чем h.264» у меня вызывает сомнения. Может Вы оговорились. Или я неправильно Вас понял.

Повторюсь, целесообразность выбора кодека и его параметров может быть выяснена только исследованием. Может оказаться, что лучше h.264 для радио канала. Радиоканал тут вообще имеет определяющее значение, имхо.

[MIkler 0]

http://www.streambox.com/avenir/avenir.html вот такая штука достаточно эффективна.