Так что масштабировать кадр в бОльшую сторону это не наш путь. Во всяком случае так утверждает мой опыт рипа.
Не скажите, при наличии свободного времени и мощного железа, а так же соответствующего софта можно поизвращаться, благо алгоритмов оптимизации видео полно
Цитата (Yamiko)
Его редко вытаскивают на поверхность в мордах, но и у x264 и у RMEncoder вроде бы как есть ключи, задающие максимальный битрейт.
Кто в лес кто по дрова, мда... Я говорил о конкретных прогах, а не о библиотеках в целом Реализация данного момента попросту не нужна в морде, благо конвертеры пишут не дураки, и разброс среднего битрейта ограничивается в весьма небольших рамках от задаваемого изначально, т.е. изобретать велосипед нет нужды. Иначе бы мы с вами имели на выходе весьма разбросанную по качеству картинку каждый раз От максимального п качеству до минимально допустимого исходной библиотекой...
Временно не обновляю онгоинги, не перезаливаю битые материалы, не беру заказы на дорамы. Релизы будут, но не часто и не факт.
Иначе бы мы с вами имели на выходе весьма разбросанную по качеству картинку каждый раз tongue От максимального п качеству до минимально допустимого исходной библиотекой...
Скорее всего Вы правы, да. Окончательную точку может поставить эксперимент. KMPlayer по нажатию клавиши <TAB> показывает разные данные о видео, в том числе текущий битрейт. Достаточно запустить в нём притормаживающий ролик и посмотреть как скачут циферки.
Скорее всего Вы правы, да. Окончательную точку может поставить эксперимент. KMPlayer по нажатию клавиши <TAB> показывает разные данные о видео, в том числе текущий битрейт. Достаточно запустить в нём притормаживающий ролик и посмотреть как скачут циферки.
Я никогда подробно кодом подробных прог не интересовался, но данных ограничений требует банальная логика. Интересно будет глянуть на результаты Только учитываете, что в том же Kmp есть встроенные алгоритмы оптимизации, как отключаемые, так и нет. Как впрочем и в известном большинстве подобного софта. Поэтому итог будет весьма относительный
Временно не обновляю онгоинги, не перезаливаю битые материалы, не беру заказы на дорамы. Релизы будут, но не часто и не факт.
Итак, дамы и господа аплоадеры и те кто просто читает что тут написано.
Цитата
Размер файла (для файлов продолжительностью ~23 минуты) более 50Мб. Видео: Разрешение не менее 700 пкс в ширину; Фреймрейт не менее 24 кадров в секунду; Видео битрейт не менее 200 Кбит/с. Аудио: Аудио битрейт не менее 96 Кбит/с; Дискретность 44 КГц.
----------------------------------------------- Чем вызваны подобные требования? ----------------------------------------------- С самого простого - аудио: 96Кбс - необходимый минимум битрейта для исключения электронного шума вызванного артефактами сжатием с потерями звуковой дорожки. 44КГц - минимум комфортного восприятия звуков широкого диапазона. Я думаю приятней на слух качественно различать трели цикад от тяжёлого низкого баса взрывов, чем слушать звук сливающийся в неразборчивую мешанину средних частот. Более того граница чувствительности человеческого слуха как раз примерно равна 44КГц. Тем более снижение дискретности звука не даёт ощутимого изменения фактического веса звуковой дорожки. ----------------------------------------------- Теперь по сложнее - о качестве видео: К сожалению сейчас не существует доступных средств и возможностей для определения требований к видео, хотя бы по критериям резкость, чёткость, наличие графических артефактов вызванных опять же пресловутым сжатием с потерями. Поэтому были введены основные критерии: Разрешение по горизонтали. Не надо говорить что разрешение не влияет на качество изображение. При увеличении фрэйма в два раза, сколько бы не было бит на пиксел в единицу времени (в сумме образующие видео битрейт), смазывания картинки не избежать. Как многие знают, смазывание происходит из-за метода интерполяции применяемого при увеличении изображения (два пиксела превращаются в три, при этом третий пиксел получает усредненное значение цвета рядом стоящих пикселей). Нельзя увеличить качество изображения не повысив его разрешение. Фреймрейт (количество кадров в секунду) - как опять многие знаю, человеческий глав видит с частотой примерно 39-42 "кадра" в секунду (так называемая "верхняя пороговая частота мерцания", т.е. частота мерцания, которую мозг может воспринять). Для комфортного восприятия, частота кадров должна быть чем выше - тем лучше, ведь в обычных условиях, т.е. в жизни, частоты кадров не существует. Однако, фактически, для восприятия оказывается достаточно ~30 кадров, частота ниже указанной становится зрительно заметной и движения становятся зрительно отрывистыми как череда слайдов. Но! Вес файла находится в прямой зависимости от количества кадров секунду. Упрощённо: видео длиной 20 минут (1200сек), с фреймрейтом 30 и весом одного кадра 100кб = 1200 * 30 * 100 = 3 600 000кб (3,6 Мб), или тоже видео но с частотой 35 кадров = 1200 * 35 * 100 = 4 200 000кб (4,2Мб), таким образом мы за счёт использование 30 кадров позволяет выиграть около 20% объёма файла, без потери качества, однако как я уже говорил, использование частоты меньше 30, повлечёт понижение качество видео, за счёт алгоритмов восстановления видео - картинка в движении будет смазываться там - где смазываться не должна. (для тех кто хочет сверкнуть умом оговорюсь - частота не может быть равна целому число 30, а равна ~29.97, влияние кратности, вызванной алгоритмом развёртки). Подавляющее большинство видео использует частоту 23,97-29,97 ниже указанной частоты (частоты исходника) крайне не рекомендуется. Битрейт - бит в секунду, или упрощённо какое количество информации кодирует 1 секунду видео. В малоподвижных моментах информации меньше, в динамичных - больше. Использование статичного битрейта позволяет существенно выйграть в объёме файла, но в динамические момент, качество видео резко ухудшится, но в статичном весь - лишний объём будет занят пустыми значениями. Упрощённо: а) динамичный битрейт (битрейт динамически меняется): статичный момент - 100кбс (необходимо мало информации для обновления каждого следующего кадра), среднединамичный момент - 300кбс (требуется нормальное количество информации для обновления неспешного движения), динамичный момент 1500кбс (каждый новый кадр может существенно отличаться от предыдущего, требуется очень много информации для его отображения), б) статичный битрейт (скажем 300кбс): статичный момент - 100кбс (данные о пустых 100 кбс всё равно хранятся в файле), среднединамичный момент - 300кбс (как раз наш выбранный битрейт, т.е. вся хранящаяся в файле информация используется для отображения видео), динамичный момент - 1500кбс (но наш лимит 300кбс, соответственно вся информация 1500кбс принудительно сжимается до 300кбс, конечно мы выигрываем 4/5 объёма, но в тоже время мы теряем 4/5 информации, а значит 4/5 качества изображения). Опытным путём установлено что битрейт для видео в диапазоне 0,5 мегапиксел (т.е. разрешения примерно 800*600 или с иным соотношение сторон) минимальный битрейт в средней 200кбс, естественно динамический (нижний предел и верхний предел выбирается либо автоматически либо выставляется вручную опытным путём). Средний битрейт ниже 200 обычно привод к резкому ухудшению качества, выше 200 - необоснованное увеличение вес файла. ---------------------------------------------- Хочу особо отметить - нельзя добить оптимального соотношения качество видео к размеру файла, повышая или понижая определённый параметр. Все приведенные параметры находятся в прямой зависимости друг от друга. Только правильное и с умом корректируя эти параметры можно добиться качественной картинки при небольшом размере файла. ----------------------------------------------- Также - из видео плохого качества сделать хорошее очень сложно (в рамках этого сайта даже не пытайтесь), а вот из отличной равки fullHD можно легко сделать файл 200мб, смотреть которое будет невозможно. Приведенные в требованиях ограничения - оптимальные для сохранения качества видео, оставаясь в рамках небольших файлов. ----------------------------------------------- Видео в формате реал медиа хоть и уступает в качестве сжатия флагманским кодекам типа h264AVC, но весьма не требователен к аппаратным ресурсам, и при этом выдаёт приемлемую картинку при небольшом размере файла. Именно поэтому сайт был и будет rmvb ориентированным. ----------------------------------------------- И да. Я не требую искать исходники высокого качества для аниме 70х годов, однако видео с начала 95х в DVD качестве найти не так сложно. Тем более онгоинги - все должны быть в нормальном качестве, все онгоинги есть в fullHD, так что правильная конвертация дело прямоты рук и совести аплоадера.
Для комфортного восприятия, частота кадров должна быть чем выше - тем лучше, ведь в обычных условиях, т.е. в жизни, частоты кадров не существует. Однако, фактически, для восприятия оказывается достаточно ~30 кадров, частота ниже указанной становится зрительно заметной и движения становятся зрительно отрывистыми как череда слайдов.
Не умничанья ради, а точности для: это справедливо для фильмов. В анимации гораздо важнее сколько картинок на секунду рисуют аниматоры. Если просматривать видео покадрово, то для "дешёвых" студий заметно как два-три кадра картинка одна, а следующие два-три кадра - резко другая. В этих случаях что-то делать с частотой кадров готового видео не только бесполезно, но и вредно: появляются промежуточные кадры с суммой двух картинок, изображение очень неприятно для глаза двоится.
Вот пример американского релиза SMR с SMC:
Не знаю, произошло это при переходе от японского стандарта DVD к американскому или позже, но факт, как говорится, налицо. Так этот кадр выглядит в японском релизе:
В данном случае я имею ввиду не частоту фактического изображения, а частоту обновления изображения на выводе на экран. К примеру, весь видео поток может содержать всего одну картинку (по сути один кадр), при этом отображаться в фреймрейте 30ГЦ на мониторе с частотой обновления 60Гц. Необходимый порог комфортного восприятия изображения обеспечивает монитор (60Гц). В этом примере частота фреймрейта как бы значения не имеет. Но, в случае анимации, комфортное восприятие движения монитор естественно обеспечить не может. Тут соответственно имеет значение частота обновления фактических кадров + фреймрейт (который в идеале должен быть не меньше фактического обновления), только в этом случае можно избежать
Цитата (Yamiko)
промежуточные кадры с суммой двух картинок
К чему я веду. К тому же о чём писал выше - настоятельно не рекомендую изменять фреймрейт относительно исходного файла, потому что это с большой степень вероятности ухудшит видео. (оговорка, правильно подобранное изменение фреймрейта может не ухудшить видео, но в данном случае подбор частоты довольно тонкий - всё дело в соблюдении некоей кратности кадров, в этом случае сложения изображения кадров происходить не будет или сложение будет не столь заметно. видео сохранит исходную точность). По поводу приведенных скринов. Судя по всему имеет место быть грубая конвертация между стандартами PAL/SECAM/NTSC. Между этими стандартами есть серьёзная разница в разрешении, алгоритмами сохранения чёткости и стандартом цветопередачи.Таким образом, при грубой конвертации возможно существенное падение чёткости и искажение цвета (про то что в возможно изменён битрейт не в лучшую сторону говорить не имеет смыла).
Поэкспериментировал пару недель с конверсией и теперь осмелюсь предложить пополнить требования обязательным применением двухпроходного кодирования и "тяжёлых" настроек. Убивает кучу времени и процессорной мощности, но результат того стоит: примерно в полтора раза меньший файл и картинка без бросающихся в глаза дефектов даже в динамических сценах.
Yamiko, вот уж обязательного не надо Слишком долго. Очень слишком долго. При наличии мощного железа хорошо, а вот средненькое уже ощутит всю "прелесть" (я например вообще на планшетке чаще всего пережимаю, когда на работе) А порекомендовать порекомендуйте, благо у кого голова на плечах есть и так при наличии возможности мультипроходным кодированием пользуется
Временно не обновляю онгоинги, не перезаливаю битые материалы, не беру заказы на дорамы. Релизы будут, но не часто и не факт.
D_R_, Думаю все пользователи это сайта как и я поддерживают тебя с в видением новых правил т.к хочется смотреть и видеть все что хотели показать афторы в аниме а не только слушать один звук с непонятной белибердой на экране
Я не жалею о том что зделал так как не делаю того о чем могу пожалеть
Опыт показывает, что можно вполне успешно добиваться качественной картинки и звука с размером файла 60-70мб на 24 минуты видео. Надо лишь приложить немного усилий для первичной настройки.
Убивает кучу времени и процессорной мощности, но результат того стоит
Прям пугает данное предложение: куча времени и мощности.... Кто интересно захочет идти на такие жертвы? Лично у меня и так достаточно времени уходит, совсем что ли тогда не вылазить из-за компа... И то это при том, что спасибо все равно ни кто не скажет... *мысли вслух*
До сих пор не залазила в эту тему. Причин много - спорить бесполезно, объяснять иногда тоже, рассуждать техническими терминами и разводить болтовню не охота и нет смысла ..у всех свое мнение. В технические моменты вобще не лезу( на это есть D_R_) Требования к видео создали после ваших же жалоб на качество. В итоге все равно мы оказались не правы.
Просто все пользователи хотят слишком много от ужатого формата рмвб и чтоб весил мало (40-50), да чтоб качество было зашибись как на HD DVD или Blu-ray. Простите, конечно, давайте по логике человеческой: ДА ГДЕ ВЫ ТАКОЕ ВИДАЛИ? ВСЕ И СРАЗУ?
Не можете качать с торентов уж извините должны принимать рмвб формат таким как он есть. Аплоадеры стараются как могут. От себя добавлю кое что зависит не только от конвертера А от кодеков стоящих на винде и самой винды. Новую Восьмерку конвертер не очень то любит. Я пытаюсь приспособится и эксперементирую. Но на старую возвращаться не хочу. И комп свой "мощными настройками" убивать не хочу. Как и многие. Нам за нашу энтузиазм заливку никто не платит.
Лично у меня и так достаточно времени уходит, совсем что ли тогда не вылазить из-за компа...
Не понял. Конверсия вещь такая: поставил в очередь пачку клипов и работает оно в фоне. Пять часов (на моём недобуке) и эпизод готов к контролю качества и заливке без какого-либо человеческого вмешательства.
Может, WinAvi такого и не умеет, а вот FormatFactory (и тем более утилиты командной строки к которым он всего лишь удобный гуй) - запросто.
Пять часов (на моём недобуке) и эпизод готов к контролю качества и заливке без какого-либо человеческого вмешательства.
5 часов на одну серию? Или количество серий 12? Ладно онгоинг серии заливать, а остальное? И то у некоторых в неделю по 5 онгоингов. А сколько еще надо перезаливать каждому отдельно аплоадеру вы представляете? Комп не выключать сутками? И что с ним будет через несколько месяцев такой эксплуатации? Или я что то не понимаю.
Эксперементировал пару дней и заметил что винави11 конвертирует одну серию ~70-90 мегов минут 12-17 , но при динамичных сценах затормаживает видео даже если ставишь 30fps ,кто то посоветует что делать с ним ? . FormatFactory конвертирует без тормозов, но очень долго , и тут встает вопрос - что лучше ?