Чем модно блюреи рипать?
Вау, спасибо.
Как-то слишком просто на первый взгляд.
Работает, не содержит троянов, использует видюху и бисплатна? Не верю
Как-то слишком просто на первый взгляд.
Работает, не содержит троянов, использует видюху и бисплатна? Не верю
Functionality to open DVD discs is free and will always stay free.
All features (including Blu-ray decryption and processing) are free during BETA.
http://www.makemkv.com/forum2/viewtopic.php?f=5&t=1053
установилась и запустилась прекрасно, теперь вот щас нужный образ докачаю.. Если выйдет, то это будет обалденно круто
О, даже вот как
Мне пока только несколько дисков сделать надо, спасибо еще раз за наводку.
Бедное мое железо
Мне пока только несколько дисков сделать надо, спасибо еще раз за наводку.
Бедное мое железо
Не стоит, однако, полагаться на рекомендуемые настройки. Профессиональные риперы имеют дохуядерные многогерцовые станции, охлаждаемые жидким азотом, однако даже на вполне щадящих настройках кодека x264 можно получить вполне приемлемый результат. Я советую посмотреть на стандартные настройки MeGUI, завоевывающего позиции в сфере как профессионального, так и любительского пережатия видео, как некогда VirtualDub.
я много раз их смотрел, как и на VirtualDub, но для меня они - как Brainfuck для пхп-шника, коим я и являюсь.
Это жутко печально. Может в продвижении к суровому брейнфаку заботать хотя бы плюсы? Я познавал тонкости пережатия видео когда вовсю рулил DVD2AVI, а для лохов существовал GordianKnot. Сейчас тонкостей немногим больше, усилие требуется небольшое и приносит РАДОСТЬ!
блеать!
Вот говорил же - где-то должен быть подъёб.
Я просил на выходе не BD-Remux, а BD-Rip с пережиманием.
Где там это?
BD-Remux и так прекрасно делается из m2ts при помощи mkvmerge
Вот говорил же - где-то должен быть подъёб.
Я просил на выходе не BD-Remux, а BD-Rip с пережиманием.
Где там это?
BD-Remux и так прекрасно делается из m2ts при помощи mkvmerge
То-то, как правильно отметил , создание рипа - это целая наука, а не пара щелчков мышкой.
Ботай это http://rutracker.org/forum/viewtopic.php?t=2660571
Ботай это http://rutracker.org/forum/viewtopic.php?t=2660571
Учимся, пока "Encoding Video 23.87%" ))
))Да, но зачем 
ну... три года как вместо монитора - телевизор 42". Заметно же.
Да ладно, ему же не DVD 10-летней давности кодеками 10-летней давности сжимать.
Скорее всего исходник на блюрее достаточно хороший, чтобы его не нужно было выправлять фильтрами. Сразу вся головная боль с обработкой отпадает.
Подбирать параметры кодека тоже не обязательно. Поскольку интернеты нынче быстрые а винты большие, можно особо не заморачиваться с параметрами, а просто влить чуть-чуть больше битрейта. У x264 есть неплохие пресеты на соотношение скорость кодирования vs. качество.
Плюс ко всему выше перечисленному, как я понял, образ у него уже декодированный. Есть очень хорошиие шансы, что у него нужный кусок видео просто одним файликом .m2ts там лежит. Тогда ему никакой софт для работы с блюреевским образом и структурой файлов там тоже не нужен.
Итого ему нужно:
1. Доставить видео на вход x264. Я не знаю, съест он .m2ts или нет. Раньше не мог, но там что-то делали в этом направлении. В худшем случае придется написать скрипт из 2 строк для avisynth:
2. Запустить x264 с двумя параметрами. Примерно так:
Вместо slower поставить что понравится. crf тоже подобрать какой хочется: чем больше crf, тем хуже качество и меньше размер.
3. Добыть аудио. Делает с помощью tsMuxer. Там гуи как у mkvmerge, запутаться сложно.
4. Сжать аудио своей любимо тулзой.
5. Собрать все вместе с помощью mkvmerge.
Однокнопочной тулзы для этого не знаю, но этот простой случай неплохо автоматизируется, так что она вполне может существовать.
Скорее всего исходник на блюрее достаточно хороший, чтобы его не нужно было выправлять фильтрами. Сразу вся головная боль с обработкой отпадает.
Подбирать параметры кодека тоже не обязательно. Поскольку интернеты нынче быстрые а винты большие, можно особо не заморачиваться с параметрами, а просто влить чуть-чуть больше битрейта. У x264 есть неплохие пресеты на соотношение скорость кодирования vs. качество.
Плюс ко всему выше перечисленному, как я понял, образ у него уже декодированный. Есть очень хорошиие шансы, что у него нужный кусок видео просто одним файликом .m2ts там лежит. Тогда ему никакой софт для работы с блюреевским образом и структурой файлов там тоже не нужен.
Итого ему нужно:
1. Доставить видео на вход x264. Я не знаю, съест он .m2ts или нет. Раньше не мог, но там что-то делали в этом направлении. В худшем случае придется написать скрипт из 2 строк для avisynth:
DirectShowSource("00002.m2ts")
ConvertToYV12()2. Запустить x264 с двумя параметрами. Примерно так:
x264 --preset slower --crf 18 input.avs -o output.mkv
Вместо slower поставить что понравится. crf тоже подобрать какой хочется: чем больше crf, тем хуже качество и меньше размер.
3. Добыть аудио. Делает с помощью tsMuxer. Там гуи как у mkvmerge, запутаться сложно.
4. Сжать аудио своей любимо тулзой.
5. Собрать все вместе с помощью mkvmerge.
Однокнопочной тулзы для этого не знаю, но этот простой случай неплохо автоматизируется, так что она вполне может существовать.
Именно:)
А однокнопочная тулза существует - мегуй. В нем есть кнопка "One-Click".
На моем A3850 фильм пересобрался в 7.95ГБ за 6 часов "без отрыва от производства".
А однокнопочная тулза существует - мегуй. В нем есть кнопка "One-Click".
На моем A3850 фильм пересобрался в 7.95ГБ за 6 часов "без отрыва от производства".
З.Ы. Сейчас запустил на пережим в 720p
З.З.Ы. Пересобираю "Джеймс Бонд - Живешь только дважды" 1967 года
http://rutracker.org/forum/viewtopic.php?t=4200434
Снимали его на очень хорошие стекла в свое время, так что качество рулез
http://rutracker.org/forum/viewtopic.php?t=4200434
Снимали его на очень хорошие стекла в свое время, так что качество рулез
З.Ы. Сейчас запустил на пережим в 720pзачем это, при 42"?
А однокнопочная тулза существует - мегуй. В нем есть кнопка "One-Click".Интересно, с какими параметрами оно жмет?
Для лучшего контроля за качеством и размером получающегося файла лучше не использовать однопроходные режимы crf.Пересобираю "Джеймс Бонд - Живешь только дважды" 1967 годаЯ то думал, там хоум видео...
Для массовых фильмов инструмент рипа с дисков не utorrent разве?
давно ведь всякие QuickSync и прочии куды есть, которые ускоряют процесс на порядок
неужели эти енкодеры их не используют?
неужели эти енкодеры их не используют?
а вот попробуй найди
давно ведь всякие QuickSync и прочии куды есть, которые ускоряют процесс на порядокМожет и используют. Однако
неужели эти енкодеры их не используют?
Quick Sync, так же как и другие технологии аппаратного кодирования видео, выдает качество хуже, чем при использовании только мощностей процессора[3].
качество хужеи намного хуже? есть сравнение?
кстати, если CUDA использовать, то не должно быть хуже, это ведь не аппаратное кодирование - там по сути та же программа, только исполняющаяся на видюхе
QuickSync может быть
и намного хуже? есть сравнение?Честно, не знаю, гугли. Также не знаю как понять, используются ли при перекодировании в MeGUI ускоряющие и аппаратные технологии. Заметил, однако, что на старом ноуте с GMA 4500 картинка была хуже при включении в MPC-HC аппаратного декодирования — видны были блоки и не со всяким видео декодер справлялся корректно. На новом ноуте с Intel HD Graphics 4000 вроде бы уже отличий заметно меньше и картинка поприятнее.
а логика где?
Какая? 
Для лучшего контроля за качеством и размером получающегося файла лучше не использовать однопроходные режимы crf.Если тебе не нужно получить наперед заданный размер файла, то лучше использовать CRF: он, в отличие от битрейта, не варьирует в зависимости от содержимого видео.
PS: x264 - это не xvid, который на однопроходном кодировании запарывал все активные сцены, он вполне и за один проход хорошее качество выдает.
CRF, 1pass, and 2pass all use the same bit distribution algorithm. 2-pass tries to approximate CRF by using the information from the first pass to decide on a constant quality factor. 1-pass tries to approximate CRF by guessing a quality factor over time and varying it to reach the target bitrate.
upd:
Нашел более правильную цитату.
Ссылка взята отсюда.
CRF and 2-pass use identical bit allocation algorithms. All 2-pass does is pick the CRF value that gives the filesize you want. It's still using the CRF algorithm.
кстати, если CUDA использовать, то не должно быть хуже, это ведь не аппаратное кодирование - там по сути та же программа, только исполняющаяся на видюхеНе совсем так. Ускорение идёт за счёт увеличения параллельных обработчиков. А один обработчик обладающий всеми данными может сжать данные лучше, чем несколько, которые имеют только часть данных. В принципе, наверное, можно было бы кормить этим обработчикам сильно разнесённые по времени фрагменты. Но это требует более сложной логики работы.
Это я написал как я всё это представляю в теории. На самом ли деле дела так обстоят — я не знаю.
Да все проще. Там подразумеваются две разные софтины: одна кодирует аппаратно, другая софтварно. Хороший софтварный энкодер без шансов рвет аппаратные в смысле качества результата (ну, просто реализация такая у аппаратных, без каких либо претензий что это принципиально так и быть иначе не может). Теоретически в аппаратной софтине часть работы можно отгрузить на GPU за счет CUDA/OpenCL. Вроде даже понятно какую, в x264 даже на GSoC это выносили, но это так ничем и закончилось.
http://sites.google.com/site/x264cuda/communications-with-x264-devs
http://sites.google.com/site/x264cuda/communications-with-x264-devs
Ах да, совсем забыл, если хочет совсем отличного качества, то нужно использовать профил High 10 Profile (также известный в интернетах как "10-bit"). С аппаратной поддержкой кодирования/декодирования у него никак, зато картинка получается отличная при гораздо меньшем битрейте (ну там раза в два можно битрейт снизить, а результат все равно будет лучше выглядеть).
Ах да, совсем забыл, если хочет совсем отличного качества, то нужно использовать профил High 10 Profile (также известный в интернетах как "10-bit").Это разве не для 10-битного цвета? Если исходник изначально 8-битный, то какой будет выигрыш?
И вообще дело не столько в битрейте, сколько в битах на пиксель. Для x264 этот параметр можно опустить до 0,1 и картинка все равно будет хорошая.Если исходник изначально 8-битный, то какой будет выигрыш?Меньше ошибки округления при преобразованиях внутри энкодера, меньше ошибки квантизации. В конечном итоге получается более высокое качество при том же битрейте плюс избавление от бандинга в темных областях, который преследует 8-битные энкоды.
ссылка в тему
И вообще дело не столько в битрейте, сколько в битах на пиксель.При фиксированном видео и разрешении они друг в друга линейно конвертятся, при не фиксированном - оба являются сферическими кобылами в вакууме. Так что один фиг.
Теоретически в аппаратной софтине часть работы можно отгрузить на GPU за счет CUDA/OpenCL.Так я и как раз про CUDA и говорили.
С аппаратными-то понятно.
Про это должна была быть вторая половина моего поста, но я ее как-то путано написал, видимо, да еще и опечатался. Суть: теоретически оно должно быть можно и должно работать не хуже, но пока не написали, так что и сравнивать там не с чем.
При фиксированном видео и разрешении они друг в друга линейно конвертятся, при не фиксированном - оба являются сферическими кобылами в вакууме. Так что один фиг.Параметр bit/pixel*frame чуть менее сферичен и вакуумирован, поскольку учитывает разрешение и фреймрейт.
Ты правда думаешь, что количество битов, нужных на кодирование изображения (причем с потерями) линейно зависит от площади изображения с коэффициентом 1?
И про фреймрейт: у тебя же не каждый кадр как отдельное изображение сжимается, а их разницы. Больше фреймрейт - меньше разницы, меньше нужно битов на каждый фрейм.
Т.е. учитывать он их конечно учитывает, но информации от этого больше не сообщает. Все тот же ноль.
И про фреймрейт: у тебя же не каждый кадр как отдельное изображение сжимается, а их разницы. Больше фреймрейт - меньше разницы, меньше нужно битов на каждый фрейм.
Т.е. учитывать он их конечно учитывает, но информации от этого больше не сообщает. Все тот же ноль.
Ты правда думаешь, что количество битов, нужных на кодирование изображения (причем с потерями) линейно зависит от площади изображения с коэффициентом 1?Почти ничто в этом мире не зависит от чего-то другого с коэффициентом 1.
Расслабься, чувак, я и не предлагал использовать этот параметр как универсальную меру "качества" видео. Слишком от многого это число зависит: от картинки, от кодека, от настроек кодека. Однако корреляция с качеством есть, и я, как любитель, посоветовал новичку на что следует обратить внимание при обычном кодировании вполне определенным кодеком с некими настройками, близкими к дефолтным. Накрутить настройки x264 можно и так, что даже фильм с bit/pixel*frame < 0,05 можно будет нормально смотреть. Мне такой файл попался недавно. Полуторачасовой 720p фильм был ужат на одну CD болванку. Качество картинки было замечательным, хотя bpf было 0,045.
Оставить комментарий
uncle17
Где-то через 5 лет после появления DVD появился софт и руководства, как рипать их по методу "сделать пиздато".Что сейчас модно для блюреев в таком же смысле?
На вход дал образ диска, на выходе получил .mkv размером ~10 ГБ