[РЕШЕНО] Проблема с продолжительностью видео при сжатии DVD с помощью mencoder
_lexx_ 2 Августа, 2012 - 10:42
Добрый день!
Решил ужать целиком скопированый DVD-диск, он успешно скодировался в avi, успешно показывается, но большинство плееров видят время фильма равным 1 секунде (нормально показал только mplayer): по шкале времени доходят до 1 секунды и успешно показывают дальше. Но перемотать, например, можно только в этом промежутке от 0 до 1 секунды.
Кодирую след. образом:
mencoder dvd://1 -dvd-device "$input_path" -aid 128 -nosub -oac mp3lame -lameopts vbr=2:q=7 -af volnorm,volume=0:1 -ovc lavc -lavcopts vcodec=mpeg4:mbd=1:vpass=1:vbitrate=2000 -vf pp=hb/vb/dr/ci scale=720:576 -ffourcc DIVX -ofps 24 -of rawvideo -o /dev/null && / mencoder dvd://1 -dvd-device "$input_path" -aid 128 -nosub -oac mp3lame -lameopts vbr=2:q=7 -af volnorm,volume=0:1 -ovc lavc -lavcopts vcodec=mpeg4:mbd=1:vpass=2:vbitrate=2000 -vf pp=hb/vb/dr/ci scale=720:576 -ffourcc DIVX -ofps 24 -o film.avi
Версия Mpalyer: 1.0_rc4_p20110322-r1
Если кто сталкивался, подскажите, пожалуйста, куда копать?
»
- Для комментирования войдите или зарегистрируйтесь
Попробуйте добавить параметр
Попробуйте добавить параметр -idx.
Что бы не пережимать фильм заново поступите так:
Он поступил совсем хитро.
Он поступил совсем хитро:
Но при этом урезал весь фильм до этой имеющейся 1 секунды.
В мануале написано:
-idx (смотрите также -forceidx) Перестраивает индекс файла, если таковой не был найден, позволяя осуществлять перемещение. Полезно с испорченными/:не полностью скачанными или неверно созданными файлами. ЗАМЕЧАНИЕ: Опция работает только если лежащее в основе медиа позволяет перемещение (т.е. не с stdin, pipe, т.д.).
Замечание крайне интересно, но исходное видео вполне позволяет перемещение, вроде как, и подаётся не через pipe, хотя ХЗ, как он обрабатывает dvd://1 -dvd-device "$path".
Сейчас поставлю однопроходное кодирование с -idx,
вечером отпишу результаты.
Я с помощью mencoder DVD рипы
Я с помощью mencoder DVD рипы не делал, использовал оболочку DVD::rip, но насколько я вижу, у вас фильм сжимается в два прогона, на первом прогоне у вас выводом указан /dev/null (-o /dev/null), вторым прогоном уже собственно файл (-o film.avi).
Можете объяснить команду.
Вы её нашли или сами написали по man`у ?
Рекомендую почитать зачем
Рекомендую почитать, зачем нужно многопроходное кодирование.
В первом проходе видео только исследуется для увеличения эффективности при втором проходе. Т.к. в первом на выходе нам необходим только divx2pass.log, то выходом и объявлено /dev/null
Существует мнение, что
Существует мнение, что mencoder позаброшен. Не моё, но я стараюсь ffmpeg/avconv пользоваться.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Не разу не интересовался
Не разу не интересовался сабжем, может расскажете в двух словах:как он, по функционалу не уступает? А то при таких заходах хочется иметь альтернативные пути решения задач:)
Учитывая тот факт, что нынче
Учитывая тот факт, что нынче всё видео в линуксах работает через него, можно сказать, что очень вряд ли уступает, а скорее и превосходит. Но наверняка я не знаю.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
krigstask
Да, так и есть (обсуждалось на unix-форуме). К стати, форк mplayer2 уже идет без менкодера.
ffmpeg - достойная замена. О том как делать DVDRip, в мане есть подробное how-to.
sspphheerraa
А в чём выражается "позаброшенность"? Новые версии mplayer'а вроде выходят, видео с современными версиями кодеков вроде конвертит...
>А в чём выражается
>А в чём выражается "позаброшенность"?
баги не фиксят, с новыми кодеками могут быть грабли
Нейтральность - высшее достижение сознания!
_lexx_ написал(а):А в чём
[offtop]
Если коротко, то - Архитектура.
Менкодер на выходе, корректно, умеет делать только AVI (в манах чётко указано, что все остальные форматы работают через lavf, поддержка экспериментальная). Причина того, наверно в том, что целью создания менкодера было кодирование видео, которое без проблем будет проигрывать MPlayer. Время шло, начали появляться новые форматы/кодеки. MPlayer грэйдили, добавляли новые возможности проигрывания видео "из коробки". Все эти улучшения также переходили на Mencoder, но только для "входного" материала. Для "выхода" так и оставалось только AVI. Всё бы ничего, но появилось HD-видео, а также мощные алгоритмы его сжатия. Дело в том, что AVI по своей спецификации "не различает" P- и B-кадры. В Xvid разработали механизм, позволяющий обходить это ограничение (на уровне самого кодека), таким образом, в Xvid с AVI всё в порядке. Но для других кодеков не всё так шеколадно. В x264, к примеру, есть алгоритм использования пирамидальной предсказываемости В-кадров (B-pyramid). Если такой поток (кодированный с использованием опции B-pyramid) поместить в AVI контейнер, - будут проблемы с воспроизведением. Также AVI не может содержать в себе звук OGG Vorbis (а ведь это лучший звуковой кодек для видео, т.к. с ним никогда не возникает a-v-рассинхронизации, в монтаже/муксе).
Этим объясняется снижение популярности AVI, и увеличение - матрёшки (MKV).
Кроме того, Менкодер абсолютно не умеет обрабатывать видео с несколькими звуковыми дорожками. А т.к. почти всё нынешнее HD-видео (да и DVD тоже) имеет несколько оных, - менкодер посылается лесом окончательно.
[/offtop]
В ffmpeg слабый арсенал фильтров (пуллдауна вообще нет). А так... да, одни превосходства.
Насчёт фильтров не знаю
Насчёт фильтров не знаю (вообще в вопросе не очень силён), но, может, можно декодированный видеопоток гнать через фильтр (через stdin и спецпрограммку), а потом снова паковать? Но это я так, пальцем в небо.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
krigstask написал(а): Насчёт
IMHO слишком шаткий костыль.
Мда...
Есть другое мнение о "костылях" — http://ru.wikipedia.org/wiki/%D0%A4%D0%B8%D0%BB%D0%BE%D1%81%D0%BE%D1%84%D0%B8%D1%8F_UNIX#.D0.9C.D0.B0.D0.BA.D0.98.D0.BB.D1.80.D0.BE.D0.B9:_.D0.A7.D0.B5.D1.82.D0.B2.D0.B5.D1.80.D1.82.D1.8C_.D0.B2.D0.B5.D0.BA.D0.B0_UNIX
Костыль? Это почему же? И где
Костыль? Это почему же? И где шаткость?
Как раз можно оставить кодирование-декодирование видео ffmpeg/libav'у, а обработку — другим программкам.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
krigstask
Ну, первое, ffmpeg в stdout должен выдавать только видео, а не весь медиа-поток. Это возможно?
Второе, допустим, сторонняя программа получила видеопоток, наложила фильтры и тоже выдала в stdout. Как связать "первошаговый" ffmpeg, который обрабатывает звук и новую копию ffmpeg'а, которая будет принимать фильтрованное видео?
Связать две копии ffmpeg'а и получить рекурсию?
Или по вашей схеме, подразумевается видео разжимать в Uncompressed (RGB), а звук в PCM, затем накладывать нужные фильтры, делать обработку/монтаж, и после всего ужимать в конечный вариант?
Если так, - то да. Это работает, и очень даже качественно, и просто. Единственный недостаток - разжатое RGB видео занимает ОЧЕНЬ много места (для FullHD 1080p50 - 1 минута порядка 60-70 Гб).
В прочем, если у вас x86_64 архитектура системы и есть батарея ОЗУ объёмом хотябы от 16 Гб, - тогда tmpfs в зубы, и вообще никаких проблем :)
sspphheerraa написал(а): Ну,
Мне кажется, да, но точно не скажу. Только это уже обсуждение возможности и реализации, а не костыльности идеи.
Сбросить звук в отдельный файл, например. Потом сложить все потоки вместе с помощью какого-нибудь mkvtoolnix.
И опять же, это обсуждение не костылеватости, а конкретных возможных проблем.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
krigstask написал(а): Мне
Всё ясно. Попробуйте сделать для начала.
Очень удачно вы пальцем в
Очень удачно вы пальцем в небо :)
Лучший инструмент для фильтрации видео с почти безграничными возможностями работает именно как фрейм-сервер. Аvisynth зовется. Жаль под окна, но это критично только если архитектура процессора не совместима с х86, иначе можно выкрутиться :) Кроме того есть попытка портировать его — https://github.com/avxsynth/avxsynth
Как следует даже из названия,
Как следует даже из названия, главная задача менкодера — енкод. А не мукс. Используем -of rawvideo, а потом собираем чем угодно в что угодно.
Снижение популярности AVI объясняется тем что этот контейнер крайне убог. Вы описали лишь малую часть его недостатков.
Несколько звуковых дорожек можно обработать поочередно/раздельно, скрипты для автоматизации пишутся за минуту. Было бы желание.
Другое дело, что когда-то можно было обойтись одной командой для менкодера, а теперь нет, так как требования растут, а возможности менкодера — нет. Но, я считаю правильным, что разработчики бросили попытку сделать всемогущий комбайн. Философия юникс гласит — пишите программы, которые делают что-то одно, но делают это хорошо. Тут бы можно было вставить риторический вопрос "а что же делает менкодер лучше других?", но не будем о грустном.
LinuxDrom
ага, и получить рассинхрон, в случае если звук VBR.
Опции -idx и -forceidx не
Опции -idx и -forceidx не помогли.
Но в итоге всё решилось очень просто, если убрать "-ffourcc DIVX" (пробовал так же по совету с юниксфорума ставить DX50 - то же самое), то всё замечательно показывается:)