Как бы это банально ни звучало, я считаю, что разработку видеокодека нужно начинать с изучения английского языка. Если вы не владеете английским языком, хотя бы на уровне, достаточном для прочтения технических текстов, сколько-нибудь приемлемый для практического использования видеокодек не разработать. В этой связи я хотел бы посоветовать один из лучших, на мой взгляд, сервисов, для изучения английского - http://www.lingualeo.ru Причем, я думаю, один из лучших не только в России, но и в мире, и это при том, что он является бесплатным. В своё время мне тоже его посоветовали, также как и я посоветовал его своим друзьям. Все мы сошлись во мнении, что это идеальное место для обучения английскому.

Почему английский язык так важен для разработки видеокодека? Такими вещами в России никто не занимается, ну может быть разве что компания Элекард, краткому анализу продукции которой и её сравнению с аналагоми я посвятил отдельную заметку - инструментарий разработчика системы онлайн телевидения. Но никакой технической информации, которая бы помогла нам в нашем нелегком деле от Элекарда я не видел, поэтому её можно не брать в расчет. Вся же техническая документация, которая нам потребуется, присутствует исключительно на английском языке. Читать же перевод документации на русском - это только запудрить себе мозги, в очередной раз убедиться, что мы взялись не за то дело, и забросить данную затею подальше.

Но почему бы не использовать перевод всей документации? Резонный вопрос. Как-то я читал русский перевод стандарта Mpeg-2, iso 13818-1, 2 и 3. Я по пять раз перечитывал одни и те же предложения, стараясь понять, что же тут написано - всё безрезультатно. Тогда я отбросил русский вариант и взялся за исходный - англоязычный. И тут же всё, как по мановению волшебной палочки, встало на свои места. Проблема с переводами в том, что переводить их должен тот, кто отлично понимает, о чем идет речь. Таких переводчиков не то, что мало, я думаю, в данном случае их просто нет.

В качестве примера приведу слова одного из разработчиков, который тоже, как и я, пытался совладать с русским переводом документации. Речь шла о документации к одной из микросхем, в которой было указано, что при распайке выводов, один из выводов нужно оставить слева. Не найдя абсолютно никакого логического объяснения, почему именно слева, а не справа, он решил посмотреть в исходную англоязычную документацию. Оказалось, там использовалось слово left, которое, помимо наречия “слева” может быть переведено как глагол “оставлять”. И такие ляпы присутствуют в технических переводах повсеместно. Поэтому, если переводчик не понимает, что переводит, такой перевод лучше сразу выкинуть.

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

Во-первых, это сам стандарт H.264 Part 10. Стандарт довольно объемный, более 600 страниц. Придется читать, вникать, разбираться. По-другому никак.

Во-вторых, это книга Яна Ричардсона “Видеокодирование. H.264 и MPEG-4 - стандарты нового поколения”. Здесь, кстати, перевод выполнен очень корректно, я не встретил ни одного ляпа, всё доходчиво объяснено. Также вышло второе издание этой книги, но без перевода на русский язык. В общем-то, если у вас есть второе издание, то первое можно не читать.

В-третьих, это референсный кодек h264, который доступен по адресу http://iphome.hhi.de/suehring/tml/ Кодек можно скомпилировать как под Windows, так и под Linux. Именно он служил основой для всей моей разработки.

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

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

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

Одной из особенностей алгоритма кодирования H264 является тот факт, что стандартизован только процесс декодирования видеопотока, процесс кодирования каждый разработчик волен выбирать в соответствии со своими предпочтениями. Этим объясняется наличие разных кодеров, обладающих разными характеристиками по битрейту, качеству и вычислительным ресурсам. Соответственно, было разработано множество различных алгоритмов оптимального кодирования. В процессе работы над видеокодеком я прочитал, несколько десятков, если не сотен научных работ, в которых авторы предлагали разные варианты выбора оптимальных алгоритмов кодирования. Здесь я хотел бы отметить один интересный момент.

Раньше я был уверен, что все основные разработки, в том числе и в области видеокодирования проводятся в США. Действительно, у всех на слуху Google, Microsoft, Intel, Apple и прочие компании, известные своими достижениями в области высоких технологий. Так вот, в процессе прочтения научных работ в области видеокодирования, я не встретил практически ни одной американской фамилии, ни одного американского научного центра или института. Если что-то и попадалось из заслуживающего внимания, то это относилось примерно к началу или середине 90-х годов. Большая же часть разработок была выполнена индусами. Далее шли Южная Корея и Китай, возможно, еще Япония. Для меня это стало настолько неожиданным, что я невольно задумался - а за счет чего тогда живет США, как так получается, что США считаются пионерами в высоких технологиях, а все реальные разработки (по крайней мере в области вдеообработки) осуществляются в Индии и других азиатских странах? Ответ здесь - патенты. Именно патентами сильны США. Т.е. разработки осуществляются в той же Индии, но патент на технологию уже принадлежит США. К слову, Россию я вообще не встретил ни разу. Хотя, как известно, количество научных работ обратно пропорционально прогрессу в науке.

Зачем мне было читать все эти разработки? Поняв базовые подходы к построению данных алгоритмов, ознакомившись с экпериментальными результатами, приводимыми авторами, я реализовал некоторые из них, посмотрел, выбрал лучшие. Потом посидел, подумал, посчитал мух на потолке, съездил с женой и дочкой на речку поплавать, сходил за грибами, и вывел свою технологию, которая в ряде проведенных мною тестов обошла по эффективности алгоритмы, приведенные в научных работах. Однако, это отнюдь не означает, что мой видеокодек кодирует лучше других профессиональных видеокодеков. Действительно, это было бы странно, если бы видеокодек, разработкой которого я занимался примерно полгода, кодировал бы лучше видеокодеков, которые разрабатывались десятилетиями. Конечно же нет. Лишь в одном из немногочисленных режимов работы кодера я получил более высокие параметры. С учетом того, что я реализовал лишь малую часть всех возможностей стандарта H264, профессиональные кодеки, конечно же, работают лучше. Так, в моде Intra я задействовал только блоки 4x4 и 16x16, а в моде Inter - только 16x16. Также я абсолютно не оптимизировал алгоритм кодирования с постоянным битрейтом, поэтому на быстрых сценах заметна потеря качества изображения. В общем, фронт работ здесь у меня еще большой.

Было бы неправильно не затронуть те технологии, которые задействованы в open source видеокодеке x264. Безусловно, я ознакомился с ними. Что меня здесь несколько удивило. Если подавляющая часть научных разработок, которые я читал, основываются на математических алгоритмах и вычислениях, т.е. в качестве базы используют теоретические данные и затем переходят к практике, то в x264 всё не так. Такое впечатление, что либо теоретические исследования, предшествовашие практическим, там засекречены и не подлежат оглашению, либо их не было вовсе. Это ни в коей мере не говорит о плохом качестве x264, как раз таки наоборот, я считаю этот кодек одним из лучших, просто это его особенность. Все критерии выбора алгоритмов кодирования, принятия тех или иных решений о ветвлении процесса кодирования основываются на голых цифрах, которые в большей части никак не подкрепляются теоретически. В тех редких случаях, когда разработчик x264 прояснял вопросы обоснования этих цифр, он говорил, что использовались результаты экспериментов. Т.е. что было проведено множество экспериментов, в результате которых было выбрано такое-то значение такого-то параметра как оптимальное.

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

Игорь, Октябрь 2012.