» AviSynth

Ну и, само собой, можно уменьшить размер картинки. Скажем, взять не 704x380, а, скажем, 640x346. Поток тогда можно сделать существенно меньше. Если это для вывода на телевизор, то возможно, что особо существенно зрителя это не напряжёт.

Alex Dragon

А уменьшить размер картинки можно в скрипте от Abs62? Или нужно как-то по-другому делать?

P.S. Мда-а-а... Попробовал почитать информацию по Avisynth с оффсайта и с грустью констатировал для себя, что самому мне всего этого не одолеть. Как люди в этом разбираются - не могу понять. Как написать скрипт с нужной тебе командой?

P.P.S. Да, вспомнил - у меня к фильму еще имеются внешние субтитры. А можно их как-то зашить в фильм при конвертировании?

Criptozavr

Цитата:

А уменьшить размер картинки можно в скрипте от Abs62?

Можно. Просто прописать другие параметры в Lanczos4Resize, с сохранением соотношения ширина/высота. Надо только помнить, что эти значения должны быть кратны 16.

Цитата:

Как люди в этом разбираются - не могу понять. Как написать скрипт с нужной тебе командой?

Читать доки, пробовать, смотреть, что получается. Снова читать, пробовать, смотреть...

Цитата:

P.P.S. Да, вспомнил - у меня к фильму еще имеются внешние субтитры. А можно их как-то зашить в фильм при конвертировании?

Контейнер AVI не предусматривает хранение в нём субтитров. Обычно достаточно назвать файл субтитров так же, как и фильм, и положить рядом с avi (например "my_movie.avi" и рядом "my_movie.srt"). Большинство плееров правильно это понимают.

Цитата:

Как люди в этом разбираются - не могу понять. Как написать скрипт с нужной тебе командой?

Возьми AutoGK и отконвертируй на нём пару фильмов, а потом рядом с выходным файлом останется log файл , где всё записано. Включая и манипуляции с разрешением
А эти руководства пусть сами читают, пока чего-то не начнёшь понимать--они бесполезны, а посмотришь как всё делается не по книгам а на реальных примерах, то чему-то можно научится. Потом и в руковдствах можно понять что к чему, но не наоборот как все советуют



Добавлено:

Цитата:

Кодируйте в два прохода (2-pass encoding, в настройках Xvid'а обозначен как «Twopass - 1st pass» для первого прохода и «Twopass - 2st pass» для второго

А можно как-нибудь с помощью скриптов задать ограничение нижнего и верхнего порога битрейдов, а то автоматом иногда слишком занижает в некотрых местах..На xvid это незаметно (хотя мне до 300 на некотрых сценах при общем среднем битрейде 1500 занижал) а на иксе начинает "мазать", поэтому я её и не люблю.

Ironcast

Цитата:

А эти руководства пусть сами читают, пока чего-то не начнёшь понимать--они бесполезны, а посмотришь как всё делается не по книгам а на реальных примерах, то чему-то можно научится. Потом и в руковдствах можно понять что к чему, но не наоборот как все советуют

Не соглашусь. Есть прекрасный док на русском языке, который устанавливается вместе с программой. Всю начальную информацию я почерпнул именно из него. Надо только знать что ты хочешь получить на выходе. А вот насчёт реальных примеров полностью согласен. Брал для экспериментов небольшие ролики, кодировал их с разными параметрами и смотрел что полуается. После этого и приходит полное понимание.

Ironcast

Цитата:

А можно как-нибудь с помощью скриптов задать ограничение нижнего и верхнего порога битрейдов

Нельзя, вестимо. AviSynth - это фрейм-сервер, его задача по запросу выдать нужный кадр. А управление битрейтом - это забота кодека.

Цитата:

А эти руководства пусть сами читают, пока чего-то не начнёшь понимать--они бесполезны

Я, всё что знаю по Ависинту, на 90% почерпнул из официального хелпа, который идёт вместе с программой. Там есть и русский вариант.


Цитата:

Надо только помнить, что эти значения должны быть кратны 16.

А что, у железячных плееров именно такие ограничения? У самого нету, так что про них ничего не знаю. Сам XVid'овский кодек мягче в этом отношении — достаточно кратности 2, во всяком случае 640x346 он кодировать не отказался.

Alex Dragon

Цитата:

А что, у железячных плееров именно такие ограничения? У самого нету, так что про них ничего не знаю.

У меня тоже нету.
Но не раз встречал упоминания, что кратность менее 8 существенно увеличивает вероятность глюков и тормозов при воспроизведении. А 16 - это рекомендуемая оптимальная величина. Так что если нет серьёзных причин уменьшать кратность, я бы выбрал 16.

Abs62
Ironcast
Alex Dragon

Спасибо за информацию. Буду пытаться применить на практике.

P.S. На всякий случай, если сюда забредет такой же чайник как и я, оставляю информацию по очень неплохому MKV-конвертеру, который называется OJOsoft MKV Converter. У него простой и понятный интерфейс, и что самое главное - софтина имеет режим конвертации для бытовых видеоплееров:



Т.е. не требуется устанавливать AVISynth, не нужен VirtualDub и не требуется конвертер AAC в MP3. Как говорится, все в одном флаконе. Эх, наткнулся бы на него раньше и не пришлось бы людям голову морочить с конвертацией...

P.S. Прошу прощения, если наоффтопил...

Мой плеер не брал разрешения по горизонтали > 720 пикселей и общий битрейт (видео+звук) выше 8 мегабит, кажется. Разрешения я как-то никогда не проверял, но думаю, что они у меня всегда кратны 16, это уже укоренившшаяся привычка.

По-хорошему, минимальная кратность разрешения видео для большинства современных кодеков равна 4, и это жёсткое ограничение цветового пространства YV12. А цифра 16 каким-то образом связана с макроблоками, которыми оперируют кодеки. И тут уже я не специалист, знаю только, что ограничение это не жёсткое, но всегда рекомендовалось его тоже соблюдать по мере сил.

Цитата:

А 16 - это рекомендуемая оптимальная величина.

В доке обо всём написано.

Цитата:

Обрезание YUY2/RGB32 изображения всегда кратно четырем байтам. Однако, при считывании X байтов (целого 32битного числа), операция проводится быстрее, когда читаемое выровнено по некоторому кратному значению. ММХ/SSE любят 8-байтовое выравнивание и SSE2 любит 16-байтовое выравнивание. Если данные НЕ выровнены, то каждая операция чтения/записи будет задерживаться на время не менее 4 тактов. Так что изображения всегда выровнены по кратному 16 адресу когда они создаются AviSynth.

Цитата:

Необходимо знать, что многие алгоритмы компреcсии с потерями недостаточно хорошо работают с границами однородного цвета, за исключением случая, когда ширина границы кратна размеру блока (16 пикселов для MPEG)

Есть там ещё где то упоминание об этом.

Цитата:

ММХ/SSE любят 8-байтовое выравнивание и SSE2 любит 16-байтовое выравнивание.

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

Кстати, в хелпе ниже есть прямое указание на ограничения при обрезке:


Цитата:

сообщений об ошибках не будет, но могут появиться странные искажения.

В RGB:
ширина без ограничения
высота без ограничения если видео прогрессивное
высота кратна 2 если видео чересстрочное

В YUY2:
ширина кратна 2
высота без ограничений если видео прогрессивное
высота кратна 2 если видео чересстрочное

В YV12:
ширина кратна 2
высота кратна 2 если видео прогрессивное
высота кратна 4 если видео чересстрочное

Надо заметить, что сообщения об ошибках Ависинтом всё же выдаются.


Цитата:

Необходимо знать, что многие алгоритмы компреcсии с потерями недостаточно хорошо работают с границами однородного цвета, за исключением случая, когда ширина границы кратна размеру блока (16 пикселов для MPEG)

Надо ли так понимать, что какие-то искажения будут только в пределах блоков на краю изображения?


Добавлено:

Цитата:

Т.е. не требуется устанавливать AVISynth, не нужен VirtualDub и не требуется конвертер AAC в MP3.

Зато приобрели опыт, который может пригодиться в других ситуациях. Как правило всякие автоконвертеры хороши для стандартных ситуаций и почти бесполезны, когда нужно что-то особенное под себя или шаг вправо-влево от пресетов тех конвертеров.

Alex Dragon


Цитата:

Как правило всякие автоконвертеры хороши для стандартных ситуаций и почти бесполезны, когда нужно что-то особенное под себя или шаг вправо-влево от пресетов тех конвертеров.

Согласен на все 100%

Alex Dragon

Цитата:

Надо ли так понимать, что какие-то искажения будут только в пределах блоков на краю изображения?

Этот случай описывает добавление бордюров, и искажения возможны при кодировании на стыке картинки и бордюра. Вобщем как я понимаю, всё зависит от кодировщика, которому "скармливаешь" скрипт. Но это только на стадии кодирования. Приходилось добавлять бордюры и делать перед этим ресайз исходного изображения. На выходе нужна была анаморфная картинка с соотношением сторон 1.66:1. И вот при экспериментах выяснилось, что сохранить пропорции смогу, но кратность в 16 пикселов при соотношении сторон 4х3 не могу сохранить. Попробовал, если не изменяет память сначала был ресайз картинки 674х576 (исходник был 1200х720), потом добавление бордюров справа и слева по 23 пиксела. Всё закодировалось без искажений, и воспроизводится тоже без искажений. Хотя про воспроизведение в принципе и так всё понятно, ведь уже считываться полный кадр вместе с чёрными полосами (бордюрами).

Добавлено:
Да, забыл указать, что "истинное" (с учётом аноморфирования) соотношение сторон картинки получилось 960х576, плюс бордюры по краям в 32 пиксела каждый. Общее 1024х576. Так что в итоге кратность в 16 пикселов соблюдена со всех сторон.

Alex Dragon
Я раньше задавал этот вопрос. Не могли бы ли вы попробовать ответить на него? Было бы здорово:

Есть такой файл
Общее
Полное имя : file.mkv
Формат : Matroska
Программа-кодировщик : mkvmerge v2.0.2 ('You're My Flame') built on Feb 21 2007 23:40:55
Библиотека кодирования : libebml v0.7.7 + libmatroska v0.8.1

Видео
Формат : AVC
Формат/Информация : Advanced Video Codec
Профайл формата : High@L5.1
Настройка CABAC формата : Да
Настройка ReFrames формата : 11 кадры
Режим смешивания : Container profile=Unknown@5.1
Идентификатор кодека : V_MPEG4/ISO/AVC
Битрейт : 3 629 Кбит/сек
Номинальный битрейт : 3 800 Кбит/сек
Ширина : 1 280 пикс.
Высота : 720 пикс.
Соотношение кадра : 16/9
Частота кадров : 29,970 кадр/сек
Разрешение : 24 бит
Колориметрия : 4:2:0
Тип развёртки : Прогрессивная
Бит/(Пиксели*Кадры) : 0.138

Если, не важно чем, перевожу в DVD, получается такое:

Там линия подачи (на ней особенно видно) все время мерцает. Я ничего в этом не понимаю, подскажите что это за эффект такой, как называется, и какой фильтр надо использовать и с какими параметрами для его устранения?

А что такое «линия подачи?» Вы бы кусочек видео отрезали да выложили, а то по статической картинке сложно понять, чего там мерцает.

Alex Dragon
Это единственная почти горизонтальная линия на рисунке

Вообще-то она должна быть сплошь белая

Alex Dragon

Я извиняюсь, ступил.
http://rapidshare.com/files/234439525/Test.avi.html
Здесь перекодировал Canopus ProCoder 3 c Xvid. Качество как бы другой разговор, а вот мерцание горизонтальной линии в середине каждой половины площадки - какая-то необоримая вещь. Если надо вырезать кусочек из mkv - только скажите чем. Заранее спсибо.

Да, исходник не мешало бы посмотреть. Вырезать можно Avidemux'ом. В принципе можно попробовать и VirtualDubMod'ом, но он mkv только открывает, а вывод у него в сугубо в avi. Причём версия фильтра там довольно старая и не все матрёшки он хочет кушать, кроме того не уверен, что AVC можно в авишник загнать.
Что касаемо мерцания, то я вижу на изображении два артефакта: линия при движении камеры как бы меняет толщину (при покадровом просмотре видно, что её изображение таки получается разной толщины, но не знаю это ли вы имели ввиду), и я вижу «расчёску» черезстрочности. Последняя, как я полагаю, взялась при изменении частоты кадров 29,970 -> 25, которая получается отбрасыванием лишних полей. Если вас достаёт именно эта расчёска, то я бы предложил кодировать не в PAL, а NTSC — это было бы логичнее.

Alex Dragon
Гребенка - это на вертикальных линиях? Если да, то спасибо за совет, но главное - это на горизонтальной линии. Извините за подробности, но чтобы не путаться: линии ограничивающие площадку и параллельные сетке - задние линии, они толще остальных (по правилам), а горизонтальная линия между сеткой и задней линией называется линией подачи. Она и мерцает - смотреть невозможно. Особенно именно, как Вы и заметили, при перемещении камеры. Расческа на вертикальных линиях, если переводить ConvertXtoDVD? на DVD9 - все приемлимо, а линия подачи ... C ней можно что-то сделать? Выложу исходник вечером (по часовому поясу сайта). И спасибо за помощь!
P.S. Во! может это мерцание тоже вызвано гребенкой, только она таким образом проявляется?

Мне так показалось, что гребёнка добавляет, но принципиально не меняет дела. Впрочем, надо исходник посмотреть. Так пока я в основном гадаю.

Alex Dragon
В любом случае спасибо. А, если переводить(оставлять) в NTSC, то и кадров в секунду надо ставлять 29?

Фреймрейт оставляете тем же. Я собственно и подумал об этом, потому что частота кадров сама за себя говорит. Размер кадра будет другим — для NTSC принято 720x480. Надо при этом не забыть про aspect ratio — в вашем исходном видео соотношение сторон 16:9. Когда будете в DVD перегонять, надо не забыть сказать про это кодирующей программе.

Alex Dragon
Спасибо, попробую, отпишусь.

Alex Dragon
Воспользовался Avidemux и вот что получил после открытия своего mkv:

H.264 detected
if the file is using B-frames as reference it can lead to crash or stuttering.
Avidemux cam use another mode whith is safe but YOU WILL LOSE FRAME ACCURACY.
Do you want to use thet mode?

Я ответил нет.
Она спросила:
Index is not up to date
You should use Toll->Rebuild frame/ Do it?

Я ответил, что да, сделал все COPY и получил вот это:
http://rapidshare.com/files/234893200/2.mkv.html

Посмотрел. Вы знаете, кажется тут ничего не поделаешь. «Мерцание» присутствует и в исходном видео, просто там разрешение больше и неоднородность толщины линии не так заметна. Это недостаток технологии съёмки в принципе, как я понимаю. Подобное и в обычной телепередаче можно заметить. Физически реальная полоса на корте не идеально ровная, а поскольку разрешение камеры не бесконечное, то она эти неоднородности воспроизводит дискретно. В принципе это тот же «эффект лесенки», который можно видеть на некоторых DVD на диагональных линиях. Здесь, видимо, примерно то же самое. Это, кстати, хорошо заметно на вот этом кадре.

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

Раз люди разбираются в таких деталях, хочу поинтересоваться нужно ли при перегонки ДВД в ави пользоваться какими либо фильтрами, шумодавами или (очевидно, если имеется в виду источник идеального качества) лучше обойтись вообще без них. Если да за счёт чего можно достигнуть выигрыш? А то я что-то сомневаюсь в таком мнении--от этих шумодавов
картинка мультяшная становится

Ironcast, а это сугубо по обстоятельствам. Если источник идеальный — то зачем фильтрация? Фильтры нужны, что бы подавить мешающие смотреть помехи и отчасти для снижения размера файла. Обычно проблемным бывает аналоговый захват, вот там приходится изголяться. А для DVD рипа напрягаться имеет смысл, если слишком уж требования у вас специфические или источник особенный. Скажем, бывает видно зерно киноплёнки, при кодировании такие шумы битрейт съедают впустую, поэтому если хочется максимально уменьшить размер файла, то имеет смысл какой-нить DeGrainMedian применить. И то, если совсем уж всё плохо, типа полтора-два часа на один CD впихнуть. Но сейчас народ обнаглел, семисотметровый рип ещё поискать надо, все по полтора гига лепят, с выскими битрейтами. Так мне кажется. Впрочем я не гуру, может у более опытных людей есть более другое мнение.

Alex Dragon
Спасибо огромное, что потратили на меня Ваше время. Наверно, к сожалению, Вы правы. Еще раз спасибо!

Люди. А как подцепить asf контейнер через avisynth?
DirectShowSource("D:\foo.wmv")
ChangeFPS(29.97)

или так:
DirectShowSource("d:\foo.wmv", fps=29.97, convertfps=true)

не проходит. аустой экран. слышен лишь звук. сам фильм воспроизводится через тот же wmp нативный.

vdubmod выдает следующее:
Could not locate decompressor for format "YV12" (unknown). Virtual Dub requires a Video for Windows (VFW) compatible codec to decompress video. Direct Show codecs, such as those used by Windows Media Player, are not suitable. Only 'Direct stream copy' is available for this video.