Кто знает как можно увидеть сие чудо забугорной мысли?

Книгу Иана Ричардсона я уже прочитал. К сожалению изложенной там информации не достаточно для составления целостного представления о сжатии изображений при помощи H.264 - опущено очень много подробностей. В Интернете тоже можно найти некоторые разрозненные куски информации, страдающие тем же недугом, что и книга Хочется понять как H.264 добивается такого превосходства над MPEG4 по размеру сжатого файла.

Вот и вопрос - нет ли у кого копии стандарта на посмотреть?

могу выложить стандарт, но вот только врядли там нагляднее чем у Ричардсона описано:
см.табл.4.3 стр.129
а в общих деталях:
* уменьшение минимального размера блока компенсации движения в 4 раза по площади (в итоге получаем малое кол-во ненулевых коэффициентов - поскольку позволяет найти более "похожий" блок с для компенсации движения)
* четвертьпиксельная интерполяция (см. предыдущий)
* ну и наверное всякие CABACи свою работу делают: арифметическое сжатие наиболее сильно приближает степень компрессии к теоретическому пределу. Притом там на каждый случай (набор данных) свои таблицы, адаптированные к вероятностям появления тех или иных значений (коды Голомба, etc)

а стандарт же просто сухим языком излагает _как_ декодировать поток Н264

upd: не силён в мпег4, поэтому не в курсе есть ли там возможность предсказания по В-кадрам (как в Н264): т.е. возможность использовать для оценки и компенсации движения текущего кадра, кадры находящиеся до и после текущего.

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

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

Еще интересный вопрос по поводу деблокинга. Из того, что я видел выглядит очень интересно. Да и ресурсов требует немного. Ричардсон рассказывает много о том как это делается, однако не дает деталей.

Был бы дико благодарен за копию стандарта, если возможно.

по поводу прояснения тонкостей: есть в дополнении к стандарту (как часть его) т.н. Reference software т.е. си-код так сказать "проверочный" - для прогонки и сверки результатов со своими. полезная штука

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

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


Для MPEG4 в качестве референса я использовал реализацию XVID. C ней и сравнивал свои результаты по степени компрессии. А где такая штука берется для H.264? Существуют ли open-source кодеки, реализующие этот стандарт кодирования? На сколько я понимаю - референсная реализация включает только декодер - верно?

да, этот момент я что-то упустил.. не занимался еще этим подробно

"в качестве референса" - хорошо, а референс созданный ради такового и рекомендованный самим стандартом - еще лучше
Нажмите для просмотра прикрепленного файла
ЗЫЖ обратите внимание на язык документа))

Огромное спасибо за информацию Будет теперь чем заняться длинными зимними ночами

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

Декодер H264 в VLC не соответствует стандарту. По крайней мере в версии 8.5.
По стандарту перед преамбулой h.264 может быть "any leading zero bits".
Кодек (на DaVinci) который генерировал поток и в конец фрейма вставлял от 1 до 3 нулевых байтов (выравнивание на слово 32 бит), и VLC сбрасывал эти фреймы. JM и QT воспроизводят корректно.
Вставка этих нулей корректна по стандарту. Так как при рассмотрении с позиции потока, а не фреймов, эти нули является как раз "any leading zero bits" перед следующей преамбулой.
Да и производительность VLC по сравнению с QT на проигрывании RTSP потока с контентом H.264 хромает...

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

О H.264 знаю только на пользовательском уровне (смотрю и радуюсь, не более того).
Но был вопрос о open-source кодере, так вот он: x264

http://www.videolan.org/developers/x264.html
http://x264.nl/
Может кому-нибудь пригодится...