Грамотный кодинг видео в Linux

[KukMan]

А как насчет кодирование клипав (видео вобще) для телефона? в формате 3gp или mp4. В венде мог использовать в 3gp не только amr звук,а и аас (вроде, точно не помню). Тут такой возможности не нашол, так что пока в mp4 конвертирую. Но кажется, что видео немножко дергается. Но заметно... Юзаю ffmpeg такой строкой ffmpeg -i input.avi -s 176x144 -r 25 -ac 2 -ar 44000 -ab 128 output.mp4 -mbd bits

[KonishchevDmitry]

Товарищи знатоки, ответьте, пожалуйста, на следующий вопрос:
Во многих руководствах проскальзывает рекомендация делать выходной файл таким, чтобы ширина изображения была кратна 32, а высота - 16. Чем вызвано данное требование и насколько оно актуально?

[sspphheerraa]

Это связано с кратностью масштабирования, а также с механизмом кодирования кодеков mpeg4-го семейства (AFAIK меньше артефактов получается)
Если есть возможность делать кратно - лучше делать.

зы В интерлейсном видео высоту вообще лучше не менять (сохранять интерлейс), иначе - потеря временного разрешения + фактическое разрешение по вертикали будет половинным.

[KonishchevDmitry]

Это связано с кратностью масштабирования, а также с механизмом кодирования кодеков mpeg4-го семейства (AFAIK меньше артефактов получается)

Понятно. Спасибо. А к x264 это тоже относится? Его стоит причислять к mpeg4 семейству?

[KonishchevDmitry]

Да, и еще один вопрос, если можно.

Делаю DVD Rip при помощи mencoder'a. В качестве видео кодека использую x264, в качестве контейнера - mkv. В конечном файле у меня разрешение 704х352, соотношение сторон 16/9. При воспроизведении в Linux никаких проблем нет. Изображение масштабируется как надо. Но в Windows большинство плееров не определяют, какое должно быть соотношение сторон и изображение получается сжатое по вертикали.

Пробовал при сливании видео в mkv при помощи mkvmerge флагом --aspect-ratio указать 16/9, но это не помогает.

Окажите, пожалуйста, помощь.

[minder]

Вот попало мне в руки HD 1080i видео. Весит 14 гигов файлик. Кодек - mpeg2. Сижу и ломаю голову как его правильно закодировать? так как оно i то при кодировании как прогрессивное получается кака. Есть желание сделать 720p рип на 1 ДВД болванку. Кодек, естественно, x264. Может кто нибудь подскажет как бороться с этим i ?

IMHO не стоит овчинка выделки...
В плане рипа - в качестве потеряете (причем серьезно!), ресурсов, времени и нервов займет очень много...
Насколько я понимаю, у Вас видео 1920х1080@25i т.е. разные строки имеют разный временной отпечаток. При переводе i->p потеряете временное разрешение (движения будут дерганными), а если одновременно с этим еще и разрешение уменьшите (с 1080 до 720) - потеряется информация о разных временных строках как таковых. Будут артефакты типа "волнистой" расчески, которые уже потом НИЧЕМ не уберешь.

ps Просто пережмите его, уменьшив битрейт (разрешение и флаг interpolated оставьте как в оригинале). Я бы сделал так.

А если это 30i (NTSC), то подобный формат использует 2-3 pulldown, а значит, преобразуется в 23,976p обратным телесином.
Но а настоящий i материал, действительно, лучше и кодировать с таким же параметром.

[minder]

Понятно. Спасибо. А к x264 это тоже относится? Его стоит причислять к mpeg4 семейству?

x264 всего лишь библиотека реализующая возможность кодирования в формат MPEG-4 part 10 (AVC).
Кратным 32 это уже архаизм, а вот кратным 16 (ширина и высота) стоит придерживаться.

Да, и еще один вопрос, если можно.

Делаю DVD Rip при помощи mencoder'a. В качестве видео кодека использую x264, в качестве контейнера - mkv. В конечном файле у меня разрешение 704х352, соотношение сторон 16/9. При воспроизведении в Linux никаких проблем нет. Изображение масштабируется как надо. Но в Windows большинство плееров не определяют, какое должно быть соотношение сторон и изображение получается сжатое по вертикали.

Пробовал при сливании видео в mkv при помощи mkvmerge флагом --aspect-ratio указать 16/9, но это не помогает.

Окажите, пожалуйста, помощь.

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

[KonishchevDmitry]

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

Пробовал я под разными плеерами (Light Alloy, GOM Player, Windows Media Player) с установками по умолчанию из расчета на то, что они будут автоматически выбирать соотношение сторон, исходя из информации, содержащейся в видеофайле. Вручную, естественно, это соотношение можно поменять, но хотелось бы, чтобы у человека, скачивающего мой DVD Rip, не возникало в этом необходимости.

Команда:

Код: Выделить всё

mencoder dvd.vob -vf crop=720:360:0:60,scale=704:352 -ofps 25 -oac copy -ovc x264 -x264encopts pass=$pass:bitrate=800:me=umh:me_range=64:subq=7:partitions=all:8x8dct -o dvd_rip_video.avi

Mplayer выдает то, что есть на самом деле:

Код: Выделить всё

Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 704x352 => 704x396 Planar YV12

mkvinfo тоже говорит о том, что вся необходимая информация записана в mkv файле:

Код: Выделить всё

|  + Video track
|   + Pixel width: 704
|   + Pixel height: 352
|   + Interlaced: 0
|   + Display width: 704
|   + Display height: 396

[minder]

Непонятно, почему такое масштабирование используется(scale)? Ведь при этом соотношение сторон получается 2, а должно быть 1,778. Виндовые кодеки не понимают в большинстве случаев pixel aspect ratio. Для изменения размера лучше использовать так: scale=704:-2 (в данном варианте mencoder сам найдет нужную высоту исходя из пропорций)
У меня подобных проблем нет. Использую ffdshow кодек для декодирования, сплитер - MatroskaSpliter, или встроенный в MediaPlayerClassic. Размер картинки выбираю наиболее близко подходящий к оригинальным пропорциям.
Что значит "...большинство плееров не определяют,.."? Получается, в некоторых случаях воспроизводится правильно? В чем разница(плеер, кодек,...)?
PS: если не используется пробразования fps (а в PAL материале это точно не нужно делать), то при кодировании нет смысла указывать -ofps. Да и использовать avi для H.264 не вижу необходимости.

[KonishchevDmitry]

Непонятно, почему такое масштабирование используется(scale)? Ведь при этом соотношение сторон получается 2, а должно быть 1,778. Виндовые кодеки не понимают в большинстве случаев pixel aspect ratio. Для изменения размера лучше использовать так: scale=704:-2

Когда я говорил о соотношении сторон, я имел в виду именно pixel aspect ratio. Хм... А разве "другое соотношение сторон" имеет смысл? Его ведь всегда можно получить, поделив ширину на высоту... Или я что-то не понимаю...

Делаю я так потому, что в большинстве руководств по DVDRip'у не рекомендуют масштабировать изображение до "квадратных" пикселей, если в оригинале они "прямоугольные", т. к. от этого можно только потерять в качестве.

Вот, к примеру, отрывок из руководства к mencoder'у:

После всего выше сказанного и сделанного, Вы, вероятно, получите видео не точно формата 1:85.1 или 2.35:1, а с чем-то близким к этому. Вы можете вычислить новый коэффициент соотношения сторон вручную, но MEncoder предоставляет опцию для libavcodec, называемую autoaspect, которая сделает это для Вас. Ни в коем случае не увеличивайте размер этого видео с целью квадратизации пикселей, если Вы не желаете впустую потратить место на жёстком диске. Масштабирование должно выполняться при воспроизведении, и плеер использует коэффициент соотношения сторон, сохранённый в AVI, для определения правильного разрешения. К сожалению, не все плееры используют эту информацию автомасштабирования, поэтому Вам всё ещё может быть необходимо перемасштабирование.

Что значит "...большинство плееров не определяют,.."? Получается, в некоторых случаях воспроизводится правильно? В чем разница(плеер, кодек,...)?

Правильно воспроизводит, например, VLC, хотя его виндовым плеером можно назвать с натяжкой. Больше плееров я не ставил - только VLC и три указанных выше).

[minder]

Когда я говорил о соотношении сторон, я имел в виду именно pixel aspect ratio. Хм... А разве "другое соотношение сторон" имеет смысл? Его ведь всегда можно получить, поделив ширину на высоту... Или я что-то не понимаю...

pixel aspect ratio - это не соотношение сторон, а размер одного пикселя! И не правильно расчитывать его делением сторон картинки.
Например, видео HD 720p имеет размеры 1280x720. По-вашему, pixel aspect ratio получается 1,77778, а на самом деле 1:1.

Делаю я так потому, что в большинстве руководств по DVDRip'у не рекомендуют масштабировать изображение до "квадратных" пикселей, если в оригинале они "прямоугольные", т. к. от этого можно только потерять в качестве.

Приведенная Вами выше вырезка из "Создание высококачественного MPEG-4 ("DivX") рипа из DVD фильма" говорит о том, что не нужно растягивать изображение, т.к. это приведет лишь к потере качества или увеличении результирующего рамера видео. Там ни слова нет о сохранении оригинального Pixel Aspect Ratio (PAR)!!! При кодировании, исходный материал декодируется в общепринятый промежуточный несжатый формат для подачи на кодировщик ( YUV 4:2:0).
Для просмотра используется DAR (Display AR), которое вычисляется исходя из Picture AR (размер изображения) и Pixel AR (размеры пикселя). Так вот, mencoder сам определит Pixel AR в зависимости от размеров картинки после использования фильтра scale и исходного DAR.
Изменяйте размер (scale) своего усеченного видео в соответствии с DAR оригинального видео. А если точного значения высоты нет, то выбирайте наиболее близкую, а mencoder уже сам определит PAR и запишет его в контейнер, и при проигрывании скодированного видео будет уже правильный, оригинальный DAR.
Прочтите более внимательно указанное Вам руководство - там все хорошо и детально изложено. Есть и вопрос о кратности сторон 16 и об изменении масштабирования и многое другое. В общем, RTFM!
PS: то что mplayer пишет "Movie-Aspect is xxx:1 - prescaling to correct movie aspect" и есть DAR. И еще, в mplayer/mencoder как и во многих софтовых плейерах DVD не верно берется PAR для данного формата - нужно следовать стандарту ITU-R BT.601. В результате, напр. для анаморфного (16/9) видео DAR должен быть не 1.778, а 1.823.

[linuxway]

Здравствуйте форумчане

У меня возникла небольшая проблема. Мне нужно содрать с DVD фильм, то есть у меня есть DVD диск и на нем записан один фильм в высоком качестве. Так вот - с инструментарием я определился этобудет mencoder. Кодировать буду как картинку так и звук. звук будет ogg а вот картинка будет семейством кодеков libavcodec. Собирать это все буду в mkv.

Вопросы:

1. DVD состоит из вобов, их собирать вмести и потом кодировать?
2. какими опциями пользоваться для достижения хорошего качества и размера файла в 1,5 Гб

Спасибо.

[sspphheerraa]

Какой у Вас дистрибутив?

По рипанью DVD есть отличная статья на вике:
HOWTO Rip DVD mencoder - Gentoo Linux Wiki
Для видео я бы выбрал x264 кодек.
На счет звука, стоит ли его жать в Vorbis... наверное не стоит, т.к. единственная софтина полностью поддерживающая этот формат/кодек является oggenc, а она на входе понимает только raw, WAV (PCM), AIFF, FLAC и Ogg FLAC. Если на Вашем DVD звук зажат в один из перечисленных форматов (что маловероятно), то просто выделите звук в отдельный файл, зажмите его в oggenc, затем смуксите с видеопотоком в mkvmerge.
В противном случае жмите звук в aac, как предложено в статье.

ps
Я надеюсь, Вы понимаете, что DVD сам по себе _уже_зажат_с_потерей_качества_.
Т.е. с точки зрения профессиональных кодеров, DVD - плохой первоисточник.

[linuxway]

Какой у Вас дистрибутив?

По рипанью DVD есть отличная статья на вике:
HOWTO Rip DVD mencoder - Gentoo Linux Wiki
Для видео я бы выбрал x264 кодек.
На счет звука, стоит ли его жать в Vorbis... наверное не стоит, т.к. единственная софтина полностью поддерживающая этот формат/кодек является oggenc, а она на входе понимает только raw, WAV (PCM), AIFF, FLAC и Ogg FLAC. Если на Вашем DVD звук зажат в один из перечисленных форматов (что маловероятно), то просто выделите звук в отдельный файл, зажмите его в oggenc, затем смуксите с видеопотоком в mkvmerge.
В противном случае жмите звук в aac, как предложено в статье.

ps
Я надеюсь, Вы понимаете, что DVD сам по себе _уже_зажат_с_потерей_качества_.
Т.е. с точки зрения профессиональных кодеров, DVD - плохой первоисточник.

Спасибо - суть в том что хранить фильм в 5 и выше гигов на жестком не особо охота, вот и необходимо пережать его. Прочитал вики, не особо хороший вики. У меня есть к Вам просьба: Показать просто пример как кодировать mencoder'ом. как Вы относитесь к вот такой вот опции: vcodec=mpeg4:mbd=2:mv0:trell:v4mv:cbp:last_pred=3:predia=2:dia=2:vmax_b_frames=2
:vb_strategy=1:precmp=2:cmp=2:subcmp=2:preme=2:qns=2

[sspphheerraa]

не особо хороший

что не понравилось?

как Вы относитесь к вот такой вот опции: vcodec=mpeg4:mbd=2:mv0:trell:v4mv:cbp:last_pred=3:predia=2:dia=2:vmax_b_frames=2
:vb_strategy=1:precmp=2:cmp=2:subcmp=2:preme=2:qns=2

Ну, битрейт я не вижу, чтоб Вы указали (не помню какой там по умолчанию в mpeg4). И еще, IMHO, не стоит использовать b-кадры, т.к. avi контейнер (только он полностью поддерживается mencoder'ом) может глючить при воспроизведении видео содержащего b-кадры. Кроме того avi не могут содержать OGG Vorbis звука.
mp4 контейнер, не имеет этих недостатков, но mencoder'ом он полностью не поддерживается


Повторюсь, что я предпочитаю x264 кодек. И как ни странно настройки по умолчанию являются наилучшими в большинстве случаев (для DVD рипа - точно).
Единственное что я добавляю, так это interlaced. В результате видео кодируется с сохранением полей (временное разрешение). Если поля смешивать или использовать какие-нибудь другие (не BOB) фильтры деинтерлейсинга, то движения будут дерганными и видео потеряет ту живость которая есть при просмотре на штатном плеере. При просмотре таких фильмов на компьютере используйте BOB-подобные деинтерлейс-фильтры (из 25 черезстрочных кадров будет налету составляться 50 прогрессивных), я использую yadif=1. Процессор будет нагружать хорошо, но IMHO качество движений того стоит.
Еще иногда добавляю опцию log=3 - для вывода более детальной информации на экран (удобно при тестовых сжатиях, т.е. при подборе битрейта/квантователя).
Вот один из примеров:

Код:

mencoder video.dv -nosound -of rawvideo -aspect 4:3 -ovc x264 -x264encopts interlaced:log=3:crf=25 -o final.264

В данном случае, кодируется DV-видео (звук отбрасывается), соотношение сторон - 4:3, выходное видео будет в сыром формате (для последующего мультиплексирования со звуком).
Опция crf (Constant Rate Factor) - задает соотношение размера/качества. Т.к. для меня не имеет значения точный размер выходного файла, я использую ее. В Вашем же случае (нужен размер 1,5 Гб) используйте опцию bitrate.
В вике, по-моему, опции составлены как раз для ваших требований.


ps Так какой же у Вас дистрибутив?

[kreator]

На счет звука, стоит ли его жать в Vorbis... наверное не стоит, т.к. единственная софтина полностью поддерживающая этот формат/кодек является oggenc

Ну не единственная Скорее наоборот: mplayer - одна из немногих софтин, которая использует альтернативную реализацию из FFmpeg. Практически весь остальной софт использует libvorbis (avidemux, cinelerra, vlc, audacity, все аудио плееры, etc).

Ну, битрейт я не вижу, чтоб Вы указали (не помню какой там по умолчанию в mpeg4). И еще, IMHO, не стоит использовать b-кадры, т.к. avi контейнер (только он полностью поддерживается mencoder'ом) может глючить при воспроизведении видео содержащего b-кадры.

Плохо без b-кадров - очень качество теряется (или размер растёт).

Единственное что я добавляю, так это interlaced. В результате видео кодируется с сохранением полей (временное разрешение). Если поля смешивать или использовать какие-нибудь другие (не BOB) фильтры деинтерлейсинга, то движения будут дерганными и видео потеряет ту живость которая есть при просмотре на штатном плеере. При просмотре таких фильмов на компьютере используйте BOB-подобные деинтерлейс-фильтры (из 25 черезстрочных кадров будет налету составляться 50 прогрессивных), я использую yadif=1. Процессор будет нагружать хорошо, но IMHO качество движений того стоит.

Думал точно также, но на практике 50 fps не понравилось - оставляет ощущение репортажной/сериальной съёмки. В добавок часто попадаются dvd с псевдо черезстрочностью - с yadif=1 имеем два одинаковых кадра подряд.

Опция crf (Constant Rate Factor) - задает соотношение размера/качества. Т.к. для меня не имеет значения точный размер выходного файла, я использую ее. В Вашем же случае (нужен размер 1,5 Гб) используйте опцию bitrate.

Тоже использую crf - качество всех рипов получается одинаковым, а размер разный.

Если кому интересно, могу выложить пресет с настройками (имхо оптимальными по соотношению скорость/качество) x264(crf)+vorbis+ogm для avidemux и написать краткий howto.

[linuxway]

2 MAA

Спасибо за столь широкий ответ, дистрибутив у меня opensuse. Есть к Вам просьба, вывести 3 строчки кода

1-Самое высокое качество с x264
2- Среднее качество с x264
3-Низкое качество с х264

Звук кодировать действительно нет смысла =))

[sspphheerraa]

Ну не единственная Скорее наоборот: mplayer - одна из немногих софтин, которая использует альтернативную реализацию из FFmpeg. Практически весь остальной софт использует libvorbis (avidemux, cinelerra, vlc, audacity, все аудио плееры, etc).

Я когда-то пытался кодировать в ogg с помощью ffmpeg. И удивился, что он не умеет делать звук с одним каналом (mono).
Согласен на счет остального перечисленного Вами софта. Признаю, не уточнил, - я имел в виду консольные программы.

Плохо без b-кадров - очень качество теряется (или размер растёт).

Честно говоря не замечал. Мой первоисточник DV-видеокамера. Я стараюсь снимать как можно более low-motion кадры (штатив, минимум зумов и т.д.).
Может для high-motion видео b-кадры будут координально что-то решать. Но в моем случае (как наверное и с DVD), от них IMHO лучше отказаться.
Да и к тому же, по умолчанию их использование отключено. Наверно ж разработчики это сделали не просто так.

Думал точно также, но на практике 50 fps не понравилось - оставляет ощущение репортажной/сериальной съёмки. В добавок часто попадаются dvd с псевдо черезстрочностью - с yadif=1 имеем два одинаковых кадра подряд.

Не ну, проигрывать с yadif=1 или с kerndeint, или... с linear blend - дело личных предпочтений.
Я за то, чтобы везде при кодировании поля сохранять (временное разрешение). Вдруг на стационарном плеере захочется посмотреть, или с тем же yadif=1. А убить поля всегда можно успеть

Если кому интересно, могу выложить пресет с настройками (имхо оптимальными по соотношению скорость/качество) x264(crf)+vorbis+ogm для avidemux и написать краткий howto.

Давай, я думаю многим пригодится.
Но сам я уже привык к консоли.

1-Самое высокое качество с x264
2- Среднее качество с x264
3-Низкое качество с х264

Это все условности.
1. Вы переделываете видео одного кодека в другой. Любая переделка - сама по себе потеря в качестве.
2. Вы снижаете битрейт (чтоб получить меньший размер) - еще раз теряете качество.

Какой смысл имеют понятия "Самое высокое качество", "Среднее качество", "Низкое качество", если Вы задаете конкретный размер в 1,5Гб? Качество будет таким, каким оно будет для данного размера файла.
Можно конечно долго играться с дополнительными опциями, подбирая их под особенности данного видео (например, много темных кадров или много/мало движений), но опять же как показывает опыт, настройки по умолчанию являются оптимальными в большинстве случаев.

Другой момент. Можно не менять кодек и кодировать в тот же MPEG-2 (не будете терять качество по пункту 1). Битрейт только понизить до нужного значения и все. Звук копировать.

[kreator]

Честно говоря не замечал. Мой первоисточник DV-видеокамера. Я стараюсь снимать как можно более low-motion кадры (штатив, минимум зумов и т.д.).
Может для high-motion видео b-кадры будут координально что-то решать. Но в моем случае (как наверное и с DVD), от них IMHO лучше отказаться.

Опять таки наоборот b-кадры дают выигрыш только на low-motion сценах.

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

На high-motion сценах снижается качество, поэтому решили перестраховаться. Но с b_adapt это проявляется редко. У них в планах есть улучшение по более точному определению таких ситуаций. Но imho даже сейчас выигрыш в соотношении размер/качество велик. Избегать b-кадров стоит если делается промежуточное сохранение видео (для дальнейшей обработки) или нужно очень высокое качество (crf менее 18).

http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html

bframes: If you are used to encoding with other codecs, you may have found that B-frames are not always useful. In H.264, this has changed: there are new techniques and block types that are possible in B-frames. Usually, even a naive B-frame choice algorithm can have a significant PSNR benefit. It is interesting to note that using B-frames usually speeds up the second pass somewhat, and may also speed up a single pass encode if adaptive B-frame decision is turned off.

With adaptive B-frame decision turned off (x264encopts's nob_adapt), the optimal value for this setting is usually no more than bframes=1, or else high-motion scenes can suffer. With adaptive B-frame decision on (the default behavior), it is safe to use higher values; the encoder will reduce the use of B-frames in scenes where they would hurt compression. The encoder rarely chooses to use more than 3 or 4 B-frames; setting this option any higher will have little effect.

b_adapt: Note: This is on by default.

With this option enabled, the encoder will use a reasonably fast decision process to reduce the number of B-frames used in scenes that might not benefit from them as much. You can use b_bias to tweak how B-frame-happy the encoder is. The speed penalty of adaptive B-frames is currently rather modest, but so is the potential quality gain. It usually does not hurt, however. Note that this only affects speed and frametype decision on the first pass. b_adapt and b_bias have no effect on subsequent passes.

Не ну, проигрывать с yadif=1 или с kerndeint, или... с linear blend - дело личных предпочтений.
Я за то, чтобы везде при кодировании поля сохранять (временное разрешение). Вдруг на стационарном плеере захочется посмотреть, или с тем же yadif=1. А убить поля всегда можно успеть

ИМХО лучше сразу определится с предпочтениями и не тратить битрейт зря Да и в наш век прогрессивной развертки это только осложняет жизнь, да и не все плееры имеют деинтерлейс с качеством yadif или kerndeint.

Давай, я думаю многим пригодится.
Но сам я уже привык к консоли.

avidemux2_cli ?


Сохраняем пресет в ~/.avidemux/custom/ и распаковываем.

Данный пресет был сделан исключительно для моих нужд и выставляет разные параметры для аудио:
1. Если есть несколько аудио дорожек, то выбирается та, где меньше каналов.
2. Если каналов более двух, то они сводятся в стерео и сжимаются vorbis.
3. Если исходный битрейт аудио менее 96 kbit на канал, то звук копируется.

Как использовать:
1. Загружаем файл подлежащий сжатию в avidemux (на данный момент лучше использовать версию 2.4 для gtk)
2. Выбираем меню custom->x264+vorbis.js
3. По желанию срезаем лишние заставки и смотрим наличие черезстрочности.
4. Открываем видео фильтры и настраиваем crop.
5. Если был выявлена черезстрочность, то добавляем yadif (лучше перетащить его на первое место) с режимом bob. Закрываем настройки, переключаем вид в режим 'Вывод' и проигрываем: если видны сильные рывки, значит нужно изменить порядок в yadif на 'Bottom field first'. Ещё раз проверяем, если рывков нет, возращаем режим в yadif на первый пункт.
6. Сохраняем файл в ogm. Можно попробовать сразу сохранить в mkv, но могут быть проблемы с синхронизацией звука.
7. После сохранения в ogm перегоняем в mkv (mkvmerge), проверяем синхронизацию звука и aspect ratio.

[sspphheerraa]

Честно говоря не замечал. Мой первоисточник DV-видеокамера. Я стараюсь снимать как можно более low-motion кадры (штатив, минимум зумов и т.д.).
Может для high-motion видео b-кадры будут координально что-то решать. Но в моем случае (как наверное и с DVD), от них IMHO лучше отказаться.

Опять таки наоборот b-кадры дают выигрыш только на low-motion сценах.
...
http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html
...

В теории одно, на практике - другое. У меня с b-кадрами выглядит хуже.

Избегать b-кадров стоит если делается промежуточное сохранение видео (для дальнейшей обработки) или нужно очень высокое качество (crf менее 18).

У меня как раз этот случай. Нормально mencoder умеет делать только avi. А avi не может содержать Vorbis (патчи и хаки не в счет), да и сам mencoder не умеет кодировать в Vorbis. В результате еще один этап мукса.

Не ну, проигрывать с yadif=1 или с kerndeint, или... с linear blend - дело личных предпочтений.
Я за то, чтобы везде при кодировании поля сохранять (временное разрешение). Вдруг на стационарном плеере захочется посмотреть, или с тем же yadif=1. А убить поля всегда можно успеть

ИМХО лучше сразу определится с предпочтениями и не тратить битрейт зря

В смысле? Суммарное количество строк/пикселей все равно одинаковое. Просто в разное время показываются.
Или по полям алгоритм сжатия работает хуже?

Давай, я думаю многим пригодится.
Но сам я уже привык к консоли.

avidemux2_cli ?

dvgrab/mencoder/ffmpeg/arecord/oggenc/lame/mp4creator/mkvmerge
Гуевые Cinelerra/Audacity использую только для репозиции фрагментов и a-v синхрона.
В avidemux не хватает на входе поддержки сырых_потоков, PNG_sequens'ов.

[Snupt]

2. Выбираем меню custom->x264+vorbis.js

Жму на Custom в меню - ничего не происходит.

[kreator]

После выбора x264+vorbis.js слева должны изменится кодеки на x264 и vorbis вместо 'Копировать'. Пресет может не работать со старыми версиями avidemux.

[kreator]

В теории одно, на практике - другое. У меня с b-кадрами выглядит хуже.

При том же размере выходного файла?

В смысле? Суммарное количество строк/пикселей все равно одинаковое. Просто в разное время показываются.
Или по полям алгоритм сжатия работает хуже?

Практически все алгоритмы расчитаны на прогресивную развертку. Соответственно приходится обрабатывать каждый полукадр отдельно.

Дабы не быть голословным провел некоторые эксперименты и получил следующее:
Без yadif размер файла вырос на 42%.
Без yadif, но с опцией interlace в x264 размер файла вырос на 9%.
C yadif и минимальным шумодавом (mphqdenoise3d 4,3,6) размер уменьшился на 17%.
Учитывая что применять шумодав на черезстрочной развёртке нельзя, конечная разница составит 26%. Конечно, эти цифры условны и будут меняться в зависимости от материала, но общая тенденция видна.

[sspphheerraa]

В теории одно, на практике - другое. У меня с b-кадрами выглядит хуже.

При том же размере выходного файла?

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

В смысле? Суммарное количество строк/пикселей все равно одинаковое. Просто в разное время показываются.
Или по полям алгоритм сжатия работает хуже?

Практически все алгоритмы расчитаны на прогресивную развертку. Соответственно приходится обрабатывать каждый полукадр отдельно.

264 вообще-то является выбором для HDTV, одиним из стандартов которого является 1080i (почему от черезстрочки вообще не отказались?)
MPEG-2 - тоже выбор для черезстрочного DVD.
DV - тоже черезстрочный...

Так что Ваше утверждение о том, что практически все алгоритмы расчитаны на прогресивную развертку выглядит как-то не правдоподобно.

Дабы не быть голословным провел некоторые эксперименты и получил следующее:
Без yadif размер файла вырос на 42%.
Без yadif, но с опцией interlace в x264 размер файла вырос на 9%.
C yadif и минимальным шумодавом (mphqdenoise3d 4,3,6) размер уменьшился на 17%.
Учитывая что применять шумодав на черезстрочной развёртке нельзя, конечная разница составит 26%. Конечно, эти цифры условны и будут меняться в зависимости от материала, но общая тенденция видна.

Ну, дык...
Этож не "пустая" разница. Вы уменьшаете количество информации в 1/4 раза (не в 1/2 т.к. преобразуете не 50p -> 25p, а 50i -> 25p) - вот они эти Ваши 25-26% выиграша в размере и есть. Хотя согласен с Вами, что все тесты условны и напрямую зависят от контента самого видео.
Не любите живость/репортажность (в отличие от рывков?). Я люблю.
Но даже не смотря на вкусы, мое преимущество в том, что при желании я смогу проиграть видео и на плеере, и на компьютере, и с живостью, и без, а Вы - только без.

IMHO это все равно, что уменьшить разрешение самой картинки, мотивируя тем, что размер будет меньше.

[Snupt]

Пресет может не работать со старыми версиями avidemux.

Не работает под версию 2.4.1. После того как кликаю в "x264+vorbis.js" программа падает. Файл crash.js прилагаю к посту.

crash.tar.bz2

(10 КБ) 22 скачивания

[kreator]

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

Полностью согласен. Я подразумевал конечное сжатие.

264 вообще-то является выбором для HDTV, одиним из стандартов которого является 1080i (почему от черезстрочки вообще не отказались?)

Сугубо для совместимости с ЭЛТ телевизорами.
http://en.wikipedia.org/wiki/1080i
1080i is directly compatible with CRT-based HDTV sets. 1080i is compatible with newer 720p- and 1080p-based televisions but must be deinterlaced first in order to be displayed on those sets.

MPEG-2 - тоже выбор для черезстрочного DVD.
DV - тоже черезстрочный...

Это довольно старые форматы.

Так что Ваше утверждение о том, что практически все алгоритмы расчитаны на прогресивную развертку выглядит как-то не правдоподобно.

Попробуй представить алгоритм устранения шума или изменение разрешения без потери черезстрочности и без промежуточного преобразования в прогресив Весьма нетривиальная задача ...

Этож не "пустая" разница. Вы уменьшаете количество информации в 1/4 раза (не в 1/2 т.к. преобразуете не 50p -> 25p, а 50i -> 25p) - вот они эти Ваши 25-26% выиграша в размере и есть.

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

Но даже не смотря на вкусы, мое преимущество в том, что при желании я смогу проиграть видео и на плеере, и на компьютере, и с живостью, и без, а Вы - только без.

Если так рассуждать, то вообще ничего сжимать ненужно - одни приимущества, вот только размер ... Каждому своё. Тебе черестрочность, а я мне не нравится если crf больше 23

ИМХО не многие аппаратные плееры (если такие вообще есть) смогут сделать 50 честных кадров прогрессивной развертки из черезстрочной.

p.s. Давай всё же на ты.

Не работает под версию 2.4.1. После того как кликаю в "x264+vorbis.js" программа падает. Файл crash.js прилагаю к посту.

Странно. Выглядит как проблемы при установке аудио настроек. Можно ли выбрать vorbis после загрузки видео файла?

[Nerr]

Интересная тема. Подскажите как перекодировать 1080p->720p (h.264, mkv)

[sspphheerraa]

Сугубо для совместимости с ЭЛТ телевизорами.

Вот-вот. Мои мотивы сохранения полей отчасти такие же.

MPEG-2 - тоже выбор для черезстрочного DVD.
DV - тоже черезстрочный...

Это довольно старые форматы.

И тем не менее в MPEG-2 жмут многие современные HDV-видеокамеры.

Так что Ваше утверждение о том, что практически все алгоритмы расчитаны на прогресивную развертку выглядит как-то не правдоподобно.

Попробуй представить алгоритм устранения шума или изменение разрешения без потери черезстрочности и без промежуточного преобразования в прогресив Весьма нетривиальная задача ...

Согласен, не тривиальная.
Хоть я и не знаю работу кодеков изнутри, представляю себе так. Идет преобразование в 50p с уменьшением вертикального разрешения в половину. Выполняются фильтры/ресайзы и пр. Затем 50p интерполируется обратно.
Это осложняет работу кодека, и возможно ему понадобится больше времени для обработки. Но почему от этого размер должен страдать, мне не понятно...

Несжатое видео будет одного размера в независимости от наличия черезстрочности.

Но ведь качества разного
Хотя опять же, смотря на каком(их) дисплее(ях) оценивать.

А вот сжатию черезстрочность очень мешает, что и видно из моих замеров - без специальных алгоритмов в кодеке размер вырос на 42%.

Все правильно. Кодек интерпретирует расческу как собственные элементы объектов. В результате "по честному" сравнивть "i" и "p" нельзя, потому, как для кодека - это все равно что разные видео.
Ему нужно указать, что расческа - это те же самые объекты, но снятые в другой момент времени. После этого все становится более-менее на свои места.

Но даже не смотря на вкусы, мое преимущество в том, что при желании я смогу проиграть видео и на плеере, и на компьютере, и с живостью, и без, а Вы - только без.

Если так рассуждать, то вообще ничего сжимать ненужно - одни приимущества, вот только размер ... Каждому своё. Тебе черестрочность, а я мне не нравится если crf больше 23

Не совсем так... Мое мнение, - сжимать надо потуда, покуда нет визуальных (субъективно) изменений на экране, на котором предполагается видео потом смотреть. Деинтерлейс делает приличные изменения с движениями (на ВСЕХ дисплеях). Так что IMHO его при кодировании делать не стоит. А вот с crf, - тот случай когда значение подбирается под характер самого видео. На одном моем видео я не вижу изменений при crf 24 и 25 (выбираю в пользу меньшего размера). На другом - иногда бывает и 23 мало (ну чтож мало так мало).
IMHO с выбором значений crf/qp/bitrate нет четких правил применения.

ИМХО не многие аппаратные плееры (если такие вообще есть) смогут сделать 50 честных кадров прогрессивной развертки из черезстрочной.

Да нет, речь не про такие плееры. Речь про самые, что ни на есть обычные плееры, которые вообще деинтерлейсить не будут. А будут выводить черезстрочку на черезстрочный дисплей (телевизор).
И, к стати, деинтерлейснутое видео на черезстрочных дисплеях выглядит еще хуже, чем нативное 25p.
А делать 50 честных будет yadif на компе.


ps. Может когда-нибудь производители видеокамер откажутся от черезстрочки вообще и будут выпускать, скажем 1920x1080@50p / 1920x1080@25p. Хотите, берите 50p - будет живость, не хотите - береите 25p, будет кинематографический motion blur.
И всем будет жить легче, и людям, и кодекам, и железу

[sspphheerraa]

Подскажите как перекодировать 1080p->720p (h.264, mkv)

...чего проще
Resize в том же avidemux2 (kreator, что означает двойка? почему Avidemux2?).
Хотя IMHO, стоит ли? Может просто уменьшить битрейт (подогнать под нужный размер)?

[Nerr]

avidemux'ом и делаю, но может есть какой более правильный вариант?

Хотя IMHO, стоит ли?

да, 1080p комп не тянет