Так...скрин то я от 5й версии приложил, нехорошо получилось.
Вашему конвертеру.
Ну я ничего не трогал в программе, просто в настройках выбрал разрешение. да и конверчу я обычно, чтоб можно было и на компе с комфортом смотреть. Не люблю 2 одинаковых файла держать.
А сейчас стоит файл, с форума. Так что.... Может чтото не так встало. Про high не понял, сколько должно быть? а понял про профиль- у меня другие ошибки выдавали. не 2х проходное и тд. не работало. систему ремонтировал, все заработало. Поэтому такие данные. Но полосы исчезли. все нормально и с другими фильмами.
Вместо 9 в принципе можно 10 - немного выйграете в размере, но потеряете в скорости. Хотя это будет всё равно быстрее, чем было.
конечно исчезли, у вас видео 960х544 с неквадратным пикселем, откуда бы им взяться?
но в этом видео. зеленые полосы были. я к тому, что 960*408 оригинал то с зеленой полосой, а если выставить 960*544, то полосы зеленой нет, а видео на экране виты 960*544 выглядит как 960*408.Никаких искажений и тп даже на компьтере. Как то так
Другие консоли: PSOne, Денди c пистолетами >:D, iPod touch 5g 32Gb, iPad mini 16Gb
Регистрация: 20.07.2009
Адрес: Муром
Возраст: 32
Сообщений: 2,544
Вы сказали Спасибо: 1,046
Поблагодарили 1,042 раз(а) в 674 сообщениях
Сила репутации: 1
Репутация: 1042 (просто великолепная личность)
Сообщение от sectorm85
видео на экране виты 960*544 выглядит как 960*408
А я о чём?
В контейнере стоит флаг с параметрами, которые используются при воспроизведении. Не то, чтобы это было вредно, просто это влечёт либо перерасход битрейта, либо его недостаток, в зависимости от формы пиксела и реального разрешения.
Почерпнуть знаний можно здесь.
В вашем же случае целесообразнее добавить чёрных полос сверху+снизу (каюсь, 6ю версию не ковырял), что не повлечёт никакого сжатия (имеется ввижу сжатия аспекта с растянутых 2,35:1 до 16:9 у самого кадра с последующим растягиванием до 2,35:1 в проигрывателе) видео, + сделает результат меньше в размере, ввиду правильного распределения битрейта.
А я о чём?
В контейнере стоит флаг с параметрами, которые используются при воспроизведении. Не то, чтобы это было вредно, просто это влечёт либо перерасход битрейта, либо его недостаток, в зависимости от формы пиксела и реального разрешения.
Почерпнуть знаний можно здесь.
В вашем же случае целесообразнее добавить чёрных полос сверху+снизу, что не повлечёт никакого сжатия (имеется ввижу сжатия аспекта с растянутых 2,35:1 до 16:9 у самого кадра с последующим растягиванием до 2,35:1 в проигрывателе) видео, + сделает результат меньше в размере, ввиду правильного распределения битрейта.
Пытался, но зеленая полоса оставалась. хм делал по инструкции. Не помогло. Хотя может из-за предыдущих настроек...
SectorM
Последний раз редактировалось sectorm85; 08.04.2012 в 08:10.
Ваще нужно использовать переменный битрейт (Variable). Где требуется, будет выделяться даже больше битрейта, а где статичные кадры, туда меньше, т.к. не требуется без толку выделять указанный битрейт.
Ну это конечно работает только при 2-ух проходном кодировании. И требуется только для реальных фильмов, а не для аниме или рисованных мультфильмов.
ErikPshat, Не обязательно, хоть два проходя явно лучше, crf неплохо и с одним проходом справляется, в то же время когда значение битрейта нужно подбирать.
vitalikus, ну так я о том и говорю, что постоянный битрейт (Constant) делается в один проход, т.к. нет необходимости в специальном проходе, чтобы анализировать, куда и на какой кадр сколько битрейта выдавать, т.к. тут один *** постоянный битрейт тупо по чёрному.
Переменный битрейт просто подразумевает 2 прохода минимум, потому что на то он и переменный, что рационально подбирается битрейт на каждый кадр и явно для этого требуется дополнительный проход, чтобы это всё подсчитать и записать в лог.
Сообщение от vitalikus
Не обязательно
А вот это я совсем не понял.
Сообщение от vitalikus
хоть два проходя явно лучше, crf неплохо и с одним проходом справляется
Разве?
Мне кажется что или Вы меня или я Вас не понял.
И что? Это вы написали статью?
Тогда вопрос: "А почему так мало? И почему так узко, на уровне нехватки слов для склейки более расширенного освещения темы с сопровождающимися доказательствами?
Это типа аксиома, принимаемая без доказательств?
То есть, по вашему, постоянный битрейт имеет преимущество перед переменным (VBR - Variable)...
ErikPshat, Я о постоянном битрейте не говорил. Это Вы о нём заговорили, и потом вас COOLERbyPSP, поправил. Я всё это время говорил о CRF котрой не является constant bit rate, он есть Constant Rate Factor, и если CBR тянет один и тот же битрейт всю дорогу кодирования то CRF его изменяет в зависимости от параметра квантизации. (вроде бы как-то так) ТУТ более точно описано.
Другие консоли: PSOne, Денди c пистолетами >:D, iPod touch 5g 32Gb, iPad mini 16Gb
Регистрация: 20.07.2009
Адрес: Муром
Возраст: 32
Сообщений: 2,544
Вы сказали Спасибо: 1,046
Поблагодарили 1,042 раз(а) в 674 сообщениях
Сила репутации: 1
Репутация: 1042 (просто великолепная личность)
Даже битрейт режим в один проход не даёт CBR.
Возможно, раньше так было, но точно могу сказать, что проводится точно такой же анализ.
Насчёт якобы меньшего размера при двух проходах - при me=umh / subme=9 разница (кодировал динамичный отрезок из фильма) составила менее 1%. зато время вдвое увеличилось.
Другие консоли: PSOne, Денди c пистолетами >:D, iPod touch 5g 32Gb, iPad mini 16Gb
Регистрация: 20.07.2009
Адрес: Муром
Возраст: 32
Сообщений: 2,544
Вы сказали Спасибо: 1,046
Поблагодарили 1,042 раз(а) в 674 сообщениях
Сила репутации: 1
Репутация: 1042 (просто великолепная личность)
CRF
CRF(pass) [k0stix, @lolkin@, komisar666]
Constant Rate Factor есть модель, ориентированная в отличие от битрейта не на биты и байты, а на оптимизированные исходя из психовизуальных выкладок потери lossy кодирования, чем ниже, тем. меньше потери. Пропорциональная зависимость CRF от битрейта лишь следствие этого.
Есть общая тенденция, при подборе битрейта как правило близким к оптимальному будет битрейт при том значении CRF, при котором кванты I фреймов не упадут ниже 16-17 (более низкие значения обычно сигналят об откровенном перерасходе), а B-фреймов не подскочат выше 25-25.5 (более высокие значения как правило вызывают явно различимые артефакты). Всё что находится в промежутке между этими значениями - надо сравнивать глазами, чтобы оценить возможность/необходимость поднять кванты повыше/пониже. В большинстве случаев комбинация близкая к qi18-qp20-qb23 даст результат, максимально приближенный к оптимальному.
Если нужно выжать из объёма максимум, попав при этом в точный размер, не выходя за пределы левелов аппаратной поддержки, не жалея времени, то целесообразно делать мультипроходный CRF
Первый проход: --crf ??.? --pass 1 --stats "stats.txt"
Второй проход: --bitrate < битрейт, полученный на первом проходе, скорректированный под целевой > --pass 3 --stats "stats.txt" --vbv-...
Если аппаратная совместимость не актуальна (для SD разрешения она в том числе неактуальна), то тратить время на мультипроход из соображений часы/"выигрыш в качестве" не вполне целесообразно.
Если судить по квантам, уже 2-проходный на основе crf выигрывает в сравнении с однопроходным, даже без mbtree. Точно так же и на глаз.
crf никак не привязан к какому-то определенному битрейту, он дает битрейта ровно столько, сколько надо на данный отрезок видео. Т.е. надо, чтоб битрейт подскочил на 420 кбпс и сохранялся таким в течение 5 минут, crf столько и выделит. С кодированием в битрейт все вертится вокруг заданного битрейта, грубо говоря, на графике это выглядело б как кривая, постоянно ходящая вокруг оси координат (заданного битрейта), постоянно пытаясь вернуться к заданному значению. Помимо того, это и разные алгоритмы сжатия. crf, опять-таки, как я понял, больше внимания уделяет не слишком динамичным сценам, т.е. там, где действительно можно глазом уловить разницу во время просмотра. На ядреной такой динамике может что и пропустить.
При одинаковом битрейте 2-ой проход на основе статистики с crf дает ощутимое преимущество в сравнении с просто crf-ом, как по попугайчикам, так и визуально
1. Для quality-based кодирования вполне достаточно 1-Pass CRF. Нужно вписаться в ограничения хардварных декодеров?, CRF+VBV сейчас прекрасно работает.
2. Есть острая необходимость вписаться в конкретный битрейт/размер файла - 2-pass CRF. Причем первый с --slow-firstpass, вторым тюним если промахнулись.
Q: Есть ли ещё какие-либо критические моменты или рекомендации к CRF энкоду, в плане настроек, кроме --no-dct-decimate --no-fast-pskip --direct spatial ?
A: В остальном от мультипрохода твикинг однопроходного CRF'а не отличается, за исключением того, что при кодировании HD сигнала лучше делать тот же CRF, но в два прохода, чтобы не вылезти за пределы допустимого с точки зрения хардварных чипов VBV, особенно 1080p касается. )
Q: Если выбран crf 20, 20 это средний квант для P ?
A: Это значение RateFactor в понятии кодека, при котором получается некое "постоянное качество", но никак не квант.
ErikPshat,
Сообщение от лог MediaInfo
Frame rate mode : Constant
Последний раз редактировалось COOLERbyPSP; 08.04.2012 в 19:05.
08.04.2012, 06:46
(2)
Комбинированный вид
![C чего начать? ⇒ ⇒ ⇒ [ЧАВО] - ответы на ЧАсто задаваемые ВОпросы](../forum/images/panel_start.png "C чего начать? ⇒ ⇒ ⇒ [ЧАВО] - ответы на ЧАсто задаваемые ВОпросы")
