Продолжаем познавать тайны тестирования видеокодеков. На этот раз поговорим про энкодеры.
Ссылка на первую часть.
Сразу хочется отметить, что энкодеры это не декодеры, предопределенных наборов видеопоследовательностей, на которых принято тестироваться, здесь нет, что с самого начала усложняет весь процесс. Но есть общеупотребимые, обычно именно на них доказывают превосходство одних кодеков (или их реализаций) над другими.
Если говорить о сравнении, то можно выделить два критерия: качество (субъективное или объективное) и производительность. Редкий кодек способен победить в обеих номинациях сразу. Однако, речь пойдет о тестировании энкодеров.
Итак, на входе у нас разжатое видео и реализация какого-нибудь кодека (собственно энкодер), на выходе – сжатый клип. Немного про входные данные мы уже поговорили выше, но хочется отметить, что ограничены мы лишь своей фантазией и… лицензиями. Т.е. всегда можно снять видео самому и потом с помощью него издеваться над декодером/энкодером, и не всегда можно скачать кино из интернета для тех же целей. Кроме того, бывает полезно создавать искусственные последовательности: шумы, кадры одного цвета и т.д.
После длительного процесса сжатия мы получим строгими спецификациями выверенный сжатый поток. В нем есть почти все, что было в исходных данных (мы ведь про сжатие с потерями). Именно этот файл нам и предстоит исследовать. И раз уж речь зашла о спецификациях, то одна из важных проверок будет заключаться в том, чтобы убедиться, что наш клип соответствует стандарту.
Но инициатива не всегда наказуема: есть желание — можно и самим разобрать файл на составляющие и все перепроверить. Это следует делать еще и для того, чтобы удостовериться, что наш энкодер записал все параметры так, как мы хотели, а не как попало. Разумеется, в данном случае мы ограничены “ручками”, которые мы можем “подергать” в настройках энкодера.
Но вернемся к нашему закодированному файлу. Как оценить качество картинки, которую увидит пользователь? Все очень похоже на то, что было в первой части: нам нужен декодер,
с помощью которого мы получим разжатую видеопоследовательность, которую сможем сравнить с исходной с помощью уже знакомых нам метрик — PSNR и SSIM.
Однако, здесь мы приходим к важному вопросу: какие должны быть пороги “похожести” видео? Иначе говоря, какие значения PSNR/SSIM нас удовлетворят, а какие нет? В общем случае, хорошо — это когда не плохо, т.е. нет артефактов, искажений и всего прочего, что так не нравится глазу. И хорошо, если наши метрики это уловили. Не забудем записать нужную циферку в тайное место и использовать при следующей проверке — а вдруг что-то сломалось. Но вот “сломаться” может по-разному.
Итак, допустим вчера наш энкодер давал X dB при Y битрейте (кодировать будем с постоянным битрейтом)
сегодня наш же энкодер выдает X1 dB при том же битрейте. В чем дело? Бьем тревогу? Минуту, а X1 больше X? Если так, то все хорошо, энкодер стал работать лучше! Или нет? Не все так просто, как хотелось бы: при использовании постоянного битрейта нет гарантии, что он и правда будет постоянным — возможны небольшие отклонения (в обе стороны). Теперь представим, что якобы возросшее качество объясняется возросшим битрейтом. А это значит, что никакого реального улучшения нет: энкодер “схитрил”, забрав побольше бит, которые и использовал для улучшения качества. Так же и уменьшение значения X1 по сравнению с X не говорит об ухудшении энкодера — может, он нам битов сэкономил. Мораль: больше не значит лучше, меньше не значит хуже.
Но что мы все о качестве картинки? Пора и про декодеры подумать, им же потом всю эту закодированную муть разбирать. Положил ли энкодер все нужные параметры в поток? Правильно ли он их положил? Соблюдал ли все требования и предписания в стандарте описанные?
И вроде бы все, можно закончить на этом, но есть одно но: у нас же SDK! А значит, что все варианты работы с памятью, потоками и еще всем, что пользователю доступно изменять, надо проверить. В теории, в большинстве случаев, все способы использования SDK должны давать один и тот же результат.
А значит, мы можем очень хорошо протестировать некоторую наиболее используемую модель, а остальные сравнивать с ней. Так будет быстрее, ведь операции декодирования (для получения сырого видео) и подсчета метрик (как раз на основе сырых файлов) дешевыми не назовешь.
Подводя итог, хочется отметить, что если при тестировании декодера нам наиболее интересны входные данные (и чем разнообразнее, тем лучше), то при тестировании энкодеров важно все: и входные данные, и параметры кодирования, коих может быть очень и очень много. Да и сами проверки во втором случае должны быть более интеллектуальными.
UPD
Статью про обзор подходов к тестированию Video Pre-Processing'а можно почитать на ISN
Ссылка на первую часть.
Сразу хочется отметить, что энкодеры это не декодеры, предопределенных наборов видеопоследовательностей, на которых принято тестироваться, здесь нет, что с самого начала усложняет весь процесс. Но есть общеупотребимые, обычно именно на них доказывают превосходство одних кодеков (или их реализаций) над другими.
Замечательные сравнения делают ребята из МГУ, посмотреть можно тут: compression.ru
Если говорить о сравнении, то можно выделить два критерия: качество (субъективное или объективное) и производительность. Редкий кодек способен победить в обеих номинациях сразу. Однако, речь пойдет о тестировании энкодеров.
Итак, на входе у нас разжатое видео и реализация какого-нибудь кодека (собственно энкодер), на выходе – сжатый клип. Немного про входные данные мы уже поговорили выше, но хочется отметить, что ограничены мы лишь своей фантазией и… лицензиями. Т.е. всегда можно снять видео самому и потом с помощью него издеваться над декодером/энкодером, и не всегда можно скачать кино из интернета для тех же целей. Кроме того, бывает полезно создавать искусственные последовательности: шумы, кадры одного цвета и т.д.
После длительного процесса сжатия мы получим строгими спецификациями выверенный сжатый поток. В нем есть почти все, что было в исходных данных (мы ведь про сжатие с потерями). Именно этот файл нам и предстоит исследовать. И раз уж речь зашла о спецификациях, то одна из важных проверок будет заключаться в том, чтобы убедиться, что наш клип соответствует стандарту.
Это лучше делать сторонними инструментами — так доверие к оценке выше для сторонних пользователей.
Но инициатива не всегда наказуема: есть желание — можно и самим разобрать файл на составляющие и все перепроверить. Это следует делать еще и для того, чтобы удостовериться, что наш энкодер записал все параметры так, как мы хотели, а не как попало. Разумеется, в данном случае мы ограничены “ручками”, которые мы можем “подергать” в настройках энкодера.
Любителям x264 придется смириться с меньшим количеством переключателей
Но вернемся к нашему закодированному файлу. Как оценить качество картинки, которую увидит пользователь? Все очень похоже на то, что было в первой части: нам нужен декодер,
желательно сторонний, референсный, чтобы избежать двойных ошибок
с помощью которого мы получим разжатую видеопоследовательность, которую сможем сравнить с исходной с помощью уже знакомых нам метрик — PSNR и SSIM.
Однако, здесь мы приходим к важному вопросу: какие должны быть пороги “похожести” видео? Иначе говоря, какие значения PSNR/SSIM нас удовлетворят, а какие нет? В общем случае, хорошо — это когда не плохо, т.е. нет артефактов, искажений и всего прочего, что так не нравится глазу. И хорошо, если наши метрики это уловили. Не забудем записать нужную циферку в тайное место и использовать при следующей проверке — а вдруг что-то сломалось. Но вот “сломаться” может по-разному.
Итак, допустим вчера наш энкодер давал X dB при Y битрейте (кодировать будем с постоянным битрейтом)
все остальные параметры мы учитывать не будем, оставим их фиксированными
сегодня наш же энкодер выдает X1 dB при том же битрейте. В чем дело? Бьем тревогу? Минуту, а X1 больше X? Если так, то все хорошо, энкодер стал работать лучше! Или нет? Не все так просто, как хотелось бы: при использовании постоянного битрейта нет гарантии, что он и правда будет постоянным — возможны небольшие отклонения (в обе стороны). Теперь представим, что якобы возросшее качество объясняется возросшим битрейтом. А это значит, что никакого реального улучшения нет: энкодер “схитрил”, забрав побольше бит, которые и использовал для улучшения качества. Так же и уменьшение значения X1 по сравнению с X не говорит об ухудшении энкодера — может, он нам битов сэкономил. Мораль: больше не значит лучше, меньше не значит хуже.
Но что мы все о качестве картинки? Пора и про декодеры подумать, им же потом всю эту закодированную муть разбирать. Положил ли энкодер все нужные параметры в поток? Правильно ли он их положил? Соблюдал ли все требования и предписания в стандарте описанные?
Все это и многое другое необходимо проверить, перепроверить, а затем уточнить. И так каждый раз, с каждым энкодером. Но мы об этом уже немного говорили, заострять внимание не будем
И вроде бы все, можно закончить на этом, но есть одно но: у нас же SDK! А значит, что все варианты работы с памятью, потоками и еще всем, что пользователю доступно изменять, надо проверить. В теории, в большинстве случаев, все способы использования SDK должны давать один и тот же результат.
Ну правда, почему качество должно пострадать, если пользователь использует D3D память, вместо системной? Или глубину асинхронности поменяли. Или потоков решили побольше (или поменьше) использовать.
А значит, мы можем очень хорошо протестировать некоторую наиболее используемую модель, а остальные сравнивать с ней. Так будет быстрее, ведь операции декодирования (для получения сырого видео) и подсчета метрик (как раз на основе сырых файлов) дешевыми не назовешь.
Подводя итог, хочется отметить, что если при тестировании декодера нам наиболее интересны входные данные (и чем разнообразнее, тем лучше), то при тестировании энкодеров важно все: и входные данные, и параметры кодирования, коих может быть очень и очень много. Да и сами проверки во втором случае должны быть более интеллектуальными.
UPD
Статью про обзор подходов к тестированию Video Pre-Processing'а можно почитать на ISN