Сам все чаще выбираю пойти через x264, кодируя с пресетом stillimage и битрейтом 1-2 тысячи. Так получается добиться лучшего качества картинки по сравнению с кодированием через StillImageEncoder Сценариста. Места оно будет занимать чуть больше, но чаще просто нужно в размер фонового аудио сделать, а это минута, максимум — 3 минуты. В таком случае файл будет занимать по итогу до 100 мбайт. Ну и если делать интро для меню, как предлагает BD Studio (с фейдом какого-то элемента или полностью всей картинки, например), в таком случае по-другому и не получится в один плейлист поместить видео.
Цитата:
@
bbcby, Визуальное качество зависит от уровня шума/зерна в картинке.
Разумеется качество зависит от уровня шума/зерна, но в сравнении 00:00:01:00 / 00:00:00:01 - оно будет одинаковым.
Цитата:
но в сравнении 00:00:01:00 / 00:00:00:01 - оно будет одинаковым.
Нет. Визуально, при 00:00:00:01, могут быть артефакты, в сравнении с 00:00:01:00. Я сравнивал на большом экране ТВ. От картинки зависит.
@
maks8881, По вашему субъективному мнению.
Цитата:
@
maks8881, По вашему субъективному мнению.
Объективному мнению. Я не собираюсь с вами спорить, пользователи Сценариста нас рассудят.
@
maks8881, Сценарист тут ни при чем. Пользователи математики нас рассудят. :smile_az:
Здравствуйте, а как скачать сценарист 2.0.0, пишет сообщения нужны 30 шт, я раньше тут хорошо общался, или оно обнулилось, или не учитывается? Спасибо
Цитата:
Создал 2 варианта в .264, экспортировал из AvsPmod в Photoshop.
Из Photoshop оба варианта сохранил в PNG. Посчитал CRC-суммы этих картинок в формате SHA1.
Они полностью совпали.
Если напрямую сохранить из AvsPmod в файл - тоже самое, т.е. идентичны.
PNG, конечно, другие получаются, в сравнении с Photoshop, но это по причине другого алгоритма сжатия.
Еще момент. Файлы кодированные VBR / CBR .264 - полностью идентичны.
Цитата:
Пользователи математики нас рассудят.
Я не знаком с принципом работы AvsPmod так как никогда не использовал его но исходя из логики выше если файлы не отличаются при сравнении хеш-суммы то разницы в качестве конечно не должно наблюдаться, мне правда не совсем понятно зачем понадобилась конвертация в png для проверки их характеристик разве было бы не более правильно использовать файл .264 полученный на выходе сразу для непосредственного анализа или сравнения.
При использовании Still Image Encoder мы получаем на выходе .264 файлы отличающиеся по размеру в 2 раза при заданных выше условиях, вероятно это вызвано только дублированием основного кадра но тем не менее это может являться причиной разницы в качестве отображения на определенном оборудовании если она действительно на самом деле обьективно наблюдаема.
@
bbcby, Я не хочу с вами спорить, потому что всегда относился к вам хорошо. Поэтому я решил докопаться до истины, почему у вас так, а у меня так. У вас, наверное, был всего 1 .png для меню, а у меня 25 для слайд шоу. Вот
здесь я подробно описал вывод, но теперь понимаю, что это вывод только для моих конкретный 25-и .png, поэтому он не применим ко всем случаям. Как я понял, многое зависит не только от количества, но и от размера (не разрешения) .png. Мне тогда удалось сделать MUX без ошибки
Video buffer underflows только при битрейте 19Mbit, и качество большинства картинок было отстойное. С 1-им .png и битрейтом 40Mbit качество отличное и проблем при муксе нет.
Цитата:
При использовании Still Image Encoder мы получаем на выходе .264 файлы отличающиеся по размеру в 2 раза при заданных выше условиях, вероятно это вызвано только дублированием основного кадра но тем не менее это может являться причиной разницы в качестве отображения на определенном оборудовании если она действительно на самом деле обьективно наблюдаема.
Я вообще не вижу какой-то особой надобности делать именно 00:00:00:01, если только из упрямства.