форумы  помощь  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
Сообщение от opennews (??) on 28-Окт-16, 20:39
После четырёх месяцев разработки представлен (http://ffmpeg.org/download.html#release_3.2) мультимедиа-пакет FFmpeg 3.2 (http://ffmpeg.org/download.html#releases), включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Кроме изменений, созданных внутри проекта, в новую версию также включены все последние наработки, развиваемые в ветках ffmpeg-mt (http://gitorious.org/ffmpeg/ffmpeg-mt) (многопоточное декодирование) и libav (http://libav.org/) (форк FFmpeg). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer (http://www.mplayerhq.hu/). Из изменений (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=RELEASE_NOTES...), добавленных (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=Changelog;hb=...) в FFmpeg 3.2, можно выделить: -  Новые фильтры (https://ffmpeg.org/ffmpeg-filters.html): -  weave (https://ffmpeg.org/ffmpeg-filters.html#weave) - объединяет полукадры входного видео в один кадр, позволяя удвоить высоту клипа за счёт сокращения кадровой частоты; -  gblur (https://ffmpeg.org/ffmpeg-filters.html#gblur) - применение фильтра Гауссова размытия; -  avgblur (https://ffmpeg.org/ffmpeg-filters.html#avgblur) - размытие через усреднение; -  sobel (https://ffmpeg.org/ffmpeg-filters.html#sobel) и prewitt (https://ffmpeg.org/ffmpeg-filters.html#prewitt) - применение операторов Собеля (https://ru.wikipedia.org/wiki/%D0%9E%D0%...)  и Прюитта (https://ru.wikipedia.org/wiki/%D0%9E%D0%...) ко входному видеопотоку; -  vaguedenoiser (https://ffmpeg.org/ffmpeg-filters.html#vaguedenoiser) - подавитель шумов на основе вейвлетов (https://ru.wikipedia.org/wiki/%D0%92%D0%...); -  nlmeans (https://ffmpeg.org/ffmpeg-filters.html#nlmeans) - подавитель шумов на основе алгоритма Non-Local Means (https://en.wikipedia.org/wiki/Non-local_means); -  sidedata и asidedata (https://ffmpeg.org/ffmpeg-filters.html#sidedata_002c-asidedata) - удаление/выявлния кадров с уточняющими данными для видео и звука; -  crystalizer audio (https://ffmpeg.org/ffmpeg-filters.html#crystalizer) - простой алгоритм для расширения динамического диапазона звука; -  acrusher (https://ffmpeg.org/ffmpeg-filters.html#acrusher) - сокращение звукового разрешения через сокращения числа битов дискретизации; -  bitplanenoise (https://ffmpeg.org/ffmpeg-filters.html#bitplanenoise) - показ и измерение уровня шумов в форме Bit plane (https://en.wikipedia.org/wiki/Bit_plane); -  maskedclamp (https://ffmpeg.org/ffmpeg-filters.html#maskedclamp) - нормализует значение первого битового потока на основании параметров второго и третьего битовых потоков; -  hysteresis (https://ffmpeg.org/ffmpeg-filters.html#hysteresis) - определяет маску общих компонентов в первом и втором потоках; -  lut2 (https://ffmpeg.org/ffmpeg-filters.html#lut2) - создаёт и применяет таблицу поиска на основании двух входных видео; -  yuvtestsrc (https://ffmpeg.org/ffmpeg-filters.html#allrgb_002c-allyuv_00...) - генерирует тестовый шаблон в формате YUV; -  Обеспечена возможность использования механизмов аппаратного ускорения чипов MediaCodec для кодирования и декодирования H.264, HEVC, MPEG-4, VP8 и VP9; -  Реализована поддержка ускорения декодирования H.263, VP8, VP9 и 10-разрядного HEVC (Dithered) через использующий CUDA декодировщик CUVID (https://1f0.de/lav-cuvid/); -  Добавлены распаковщики медиа-контейнеров (demuxer) для трекерных форматов (https://ru.wikipedia.org/wiki/%D0%A2%D1%...), поддерживаемых в библиотеке libopenmpt (http://lib.openmpt.org/libopenmpt/); -  Добавлена поддержка протокола tee (https://www.ffmpeg.org/ffmpeg-protocols.html#tee) для разделения вывода на несколько потоков (например, "tee:file://path/to/local/this.avi|file://path/to/local/that.avi"); -  Реализован псевдоупаковщик fifo (https://www.ffmpeg.org/ffmpeg-formats.html#fifo), который можно использовать для отделения  кодирования и упаковки медиаконтейнера через использование FIFO-очереди с асинхронным запуском  упаковщика в отдельном потоке. Например, упаковщик fifo можно использовать совместно с упаковщиком tee для отправки потока в несколько обработчиков, принимающих данные с разной скоростью; -  Добавлен универсальный упаковщик для  Ogg Video (.ogv) и обеспечена возможность использования потоков VP8 в медиаконтейнерах  Ogg; -  Добавлена обвязка для декодирования через библиотеку OpenH264 (http://www.openh264.org/); -  Добавлен упаковщик медиа-контейнеров (muxer) для формата TTA (True Audio); -  В декодировщике als добавлена поддержка операций с плавающей точкой; -  Добавлен кодировщик для форматов MLP (Meridian Lossless Packing) и TrueHD; -  В утилите ffplay реализована поддержка вывода через sdl2. Поддержка вывода через sdl1 прекращена; -  Поддержка расширенных списков редактирования для формата MOD; -  Прекращена поддержка кодировщика libfaac; -  В упаковщике медиа-контейнеров Matroska по умолчанию включена запись контрольных сумм CRC32 для всех элементов первого уровня. URL: http://ffmpeg.org/download.html#release_3.2 Новость: http://www.opennet.dev/opennews/art.shtml?num=45387
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+3 +/–
Сообщение от Аноним (??) on 28-Окт-16, 20:39
энкодером AAC уже можно пользоваться?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+2 +/–
	Сообщение от Аноним (??) on 28-Окт-16, 20:59
	Конечно, покупаешь лицензию и пользуешься.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+1 +/–
	Сообщение от myc on 28-Окт-16, 21:02
	fdk_aac пользоваться религия не позволяет?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	32. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
	Сообщение от Аноимный Аноним. Избранное on 30-Окт-16, 19:39
	Это не так. Например nero aac codec позволяет кодировать AAC 525 кбит, а ffmpeg 320 кбит максимум.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	33. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-16, 23:27
	Осталось придумать нафига нужны файлы AAC с скоростью 500 кбитов, учитывая что уже на 128 люди их от оригинала отличить напрягаются, а 320 - уже злостный оверкилл с большим запасом. Сделать запас еще больше конечно можно, но при такой щепетильности к качеству можно наверное уже использовать FLAC какой-нибудь. Там вообще все бит в бит, что хорошо для обработки и т.п.. А так рулит OPUS - его даже на 64 кбитах двуногие почти не могут отличить от оригинала, да еще в вебе играется. Так что смысла плкупать или тем более пиратить у неры их софтину - чуть менее чем нихрена.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	41. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
	Сообщение от Аноним (??) on 01-Ноя-16, 12:18
	Не нужно сравнивать среднестатистические уши и чужие :), не говоря уже о том, что если сравнивать на недопищалке для айфона то разницы и в mp3 на 64 КБит можно не заметить
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	5. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+1 +/–
	Сообщение от Хряк on 28-Окт-16, 21:07
	С разморозкой!
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Выпуск мультимедиа-пакета FFmpeg 3.2"	–1 +/–
Сообщение от Аноним (??) on 28-Окт-16, 21:05
>Реализована поддержка ускорения декодирования H.263, VP8, VP9 и 10-разрядного HEVC (Dithered) через использующий CUDA декодировщик CUVID; все замечательно, забыт h.264, ссылка на сайт\бложик с последними новостями от 12, видимо по этома автор новости не в курсе, что все cuda из декодера\энкодера в нвидии выкнуты, за некоторыми исключениями и сейчас декодер нвидия именует NVDECODE API (formerly called NVCUVID API)  и да декодер нвидия не умеет 10бит ни в каком формате https://developer.nvidia.com/nvidia-video-codec-sdk
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Выпуск мультимедиа-пакета FFmpeg 3.2"	–1 +/–
	Сообщение от Аноним (??) on 28-Окт-16, 21:14
	мда, это в официальном чейнжлоге написал какой-та левый чел, качество ffmpeg новго кода последнее время падает
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	9. "Выпуск мультимедиа-пакета FFmpeg 3.2"	–1 +/–
	Сообщение от Stax (ok) on 29-Окт-16, 02:32
	> декодер нвидия не умеет 10бит ни в каком формате Э мм это ограничение ffmpeg или линуксовой версии nvdecode api? Потому что под оффтопиком нвидия аппаратно декодирует не только 10-разрядный HEVC (который идет на UHD блюриках), но и 12-ти разрядный, популярность которого для рипов нынче стремительно набирает обороты.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	12. "Выпуск мультимедиа-пакета FFmpeg 3.2"	–3 +/–
	Сообщение от sergio78 on 29-Окт-16, 09:23
	какой такой 12 битный внезапнопопулярный? опять это ~0,75% анимешников имеется в виду? ну так больные люди, в то время как на торрентах xvid рипов огромнейшее число, которые и про 10 битное не слышали.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	20. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
	Сообщение от Аноним (??) on 29-Окт-16, 12:07
	> ~0,75% Ну, это ты хватил. Там нужно третий знак после запятой теребить.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	27. "Выпуск мультимедиа-пакета FFmpeg 3.2"	–1 +/–
	Сообщение от Stax (ok) on 30-Окт-16, 06:21
	Устраивает xvid - смотрите xvid. Зачем другим советовать? Аналогичные аргументы по поводу 10-ти бит на пиксель говорили многие недалекие люди. "Да кому это нужно, мы xvid смотрим и будем смотреть, и вообще за углом продаются по 7 фильмов на диск, по фигу на разрешение и квадраты, зато 7 фильмов по цене одного диска!" И что вышло? Main 10 - рекомендованное представление для HEVC, и на UHD-дисках идет именно HEVC Main 10 (L5.0). В UHD TV тоже в основном будет он, т.к. примерно 5% уменьшение битрейта при том же качестве по сравнению с 8-ми битным. А люди.. люди массово смотрят то, что доступно. Сейчас Main 10 профиль HEVC - то, в чем идет новый 4K контент. Будете смотреть что есть, или перекодировать в 320x288 xvid? И я писал не "популярный", а "набирающий популярность". Потому что люди проверили и выяснили, что если делать рипы (этого исходного 10-ти битного потока), то при 12-ти битном кодировании артефактов на том же битрейте меньше. Main 10 HEVC при уменьшении битрейта лучше кодируется Main 12 профилем, только и всего. И вы можете мне не верить, но % 4K-рипов HEVC->HEVC с перекодированием, при котором берут Main 12 профиль будет побольше указанного вами процента. Разумеется, рипы без перекодирования остаются в Main 10. И, разумеется, это не относится к рипам старого контента - там пока нет такого большого резона менять формат, и от Main 12 толку скорее всего будет очень мало. А NV, собственно, вполне себе в теме, поэтому последнее поколение карт аппаратно декодирует Main 12 профиль.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	10. "Выпуск мультимедиа-пакета FFmpeg 3.2"	–2 +/–
	Сообщение от soarin (ok) on 29-Окт-16, 04:00
	> все замечательно, забыт h.264 Не забыт, он был добавлен в предыдущих версиях. Это изменения ТЕКУЩЕЙ версии.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	28. "Выпуск мультимедиа-пакета FFmpeg 3.2"	–1 +/–
	Сообщение от iPony on 30-Окт-16, 11:38
	> и да декодер нвидия не умеет 10бит ни в каком формате И да, в этом ты соврал тоже.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
Сообщение от Аноним (??) on 29-Окт-16, 00:07
Debian же давно пообещал вернуться на ffmpeg по дефолту. Так почему даже в Сиде до сих пор VLC и MPV собирают с поддержкой libav?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+2 +/–
	Сообщение от Аноним (??) on 29-Окт-16, 05:59
	Норкоман? Libav выкинули ещё в jessie. Библиотеки libavcodec, libavformat и др. — части ffmpeg'а.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	14. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+1 +/–
	Сообщение от yrii2121 (ok) on 29-Окт-16, 11:22
	> Норкоман? Libav выкинули ещё в jessie. Ты чутка не прав, Libav в jessie не выкидывали. Её выкинули в будущей версии. > Библиотеки libavcodec, libavformat и др. — части ffmpeg'а. https://packages.debian.org/jessie/libavformat56 >>This is the library for handling file formats from Libav. https://packages.debian.org/jessie/libavcodec56 >>This is the codec library from Libav (both encoding and decoding). Но, FFmpeg есть в jessie-backports. И уже: https://packages.debian.org/jessie-backports/libavformat57 >> FFmpeg is the leading multimedia framework, able to decode, encode, transcode, ... https://packages.debian.org/jessie-backports/libavcodec57 >> FFmpeg is the leading multimedia framework, able to decode, encode, transcode, ... и т.д. Libav форк же, названия оставили такое же. А так да, libavcodec, etc является частью пакета FFmpeg.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	15. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+1 +/–
	Сообщение от yrii2121 (ok) on 29-Окт-16, 11:29
	> Debian же давно пообещал вернуться на ffmpeg по дефолту. Так почему даже > в Сиде до сих пор VLC и MPV собирают с поддержкой > libav? libav (https://tracker.debian.org/pkg/libav) в testing и sid (на данный момент) нету. Собирается с ffmpeg.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	34. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
	Сообщение от Аноним (??) on 30-Окт-16, 23:31
	> Debian же давно пообещал вернуться на ffmpeg по дефолту. Так они и вернулись. По поводу чего пара свежих убунт уже вышли с ffmpeg'ом.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

13. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+9 +/–
Сообщение от Вопрос по видео on 29-Окт-16, 11:10
Ребят, можно вопрос специалистам? На том же Rutracker'е есть четкие ребята, спецы в своем деле - кодировании видео. Есть целые известные RG (Release Groups), которые "знают как надо". За многие годы они стали настоящими профи и делают шикарные рипы, которые весят очень мало, при этом имея превосходное качество. Я слышал для этого нужно мощное железо, которое позволяет кодировать в несколько проходов (и якобы чем больше, тем лучше) и все такое. Вобщем вопрос в чем - можно ли создавать такие "самые четкие рипы", прям топовые рипы - на Linux. Я ведь правильно понимаю - для этого они на винде используют ПО, которое является надстройкой все того же FFmpeg? Значит весь тюнинг и кодирование рипов можно делать и в Linux, если есть видеокарта nVidia? Или нет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
	Сообщение от EuPhobos (ok) on 29-Окт-16, 11:46
	Пример двух проходного кодирования https://trac.ffmpeg.org/wiki/Encode/H.264#twopass Что мешает взять кусок видео в 60 секунд и всячески с ним поиграться?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	18. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+1 +/–
	Сообщение от Вопрос по видео on 29-Окт-16, 11:57
	Так то ничего не мешает. Вопрос был чисто теоретический, сам когда-то 100 лет назад занимался кодированием под виндой, естесно через GUIшные проги, и не понимал как оно все работает, ничего не знал о начинке. В Linux не пользовался FFmpeg, ничего не кодировал, но видимо пора попробовать. Просто хотел мнения спецов.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	26. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
	Сообщение от EuPhobos (ok) on 29-Окт-16, 13:35
	Если в винде тот же ffmpeg как начинка, то всё будет одинаково. Единственное что, я пробовал ускорить кодирование через NVENC видеокартой GTX 680, прирост скорости раза в 4-5, но качество получается ужасным, улучшить никак не получилось. Т.е. качество не просто "хуче чем", а совсем плохое, "мыло и квадратики".
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	17. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+4 +/–
	Сообщение от yrii2121 (ok) on 29-Окт-16, 11:55
	> ... > Вобщем вопрос в чем - можно ли создавать > такие "самые четкие рипы", прям топовые рипы - на Linux. Я > ведь правильно понимаю - для этого они на винде используют ПО, > которое является надстройкой все того же FFmpeg? Значит весь тюнинг и > кодирование рипов можно делать и в Linux, если есть видеокарта nVidia? > Или нет? В большинстве случаев, к релизу прикладывают отчет MediaInfo. Посмотри какие используются опции кодирования (Encoding settings). И поиграйся по аналогии. Если используют "чистый" x264, то для ffmpeg есть аналогичные ключи... http://www.videorip.info/x264/81-analogi-kljuchej-kodirovani...
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	19. "Выпуск мультимедиа-пакета FFmpeg 3.2"	–1 +/–
	Сообщение от Вопрос по видео on 29-Окт-16, 12:01
	1. Mediainfo я так понял OpenSource, значит все хорошо. 2. Опции Encoding settings - это надо смотреть на Rutracker'е где-то в разделе для кодировщиков? 3. Она там используют x264/x265, а что насчет открытых кодеков? Они не такие хорошие?Есть ли конкурент x264/x265?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	21. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+2 +/–
	Сообщение от yrii2121 (ok) on 29-Окт-16, 12:08
	> 1. Mediainfo я так понял OpenSource, значит все хорошо. > 2. Опции Encoding settings - это надо смотреть на Rutracker'е где-то в > разделе для кодировщиков? > 3. Она там используют x264/x265, а что насчет открытых кодеков? Они не > такие хорошие?Есть ли конкурент x264/x265? 1. Да, программа есть под Linux. 2. Строчка "Encoding settings" есть в отчете Mediainfo. Там написаны опции кодирования конкретного файла. По поводу опций и что выбирать (тема обширная, в одном сообщение не расписать; да и в инете на эту тему много есть статей): http://www.videorip.info/x264/78-polnoe-opisanie-vseh-kljuch... https://rutracker.org/forum/viewtopic.php?t=1037661 3. Внимательно прочитай, как минимум это: https://ru.wikipedia.org/wiki/H.264 https://ru.wikipedia.org/wiki/X264
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	22. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
	Сообщение от Вопрос по видео on 29-Окт-16, 12:16
	Спасибо добрый человек, вижу тема просто хардкор, одним месяцем изучения тут не обойтись. Но надо... надо изучать, ведь хочется делать крутые рипы. Спасибо за ссылки!
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	23. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
	Сообщение от Вопрос по видео on 29-Окт-16, 12:21
	А можно полюбопытствовать? Возьмем обычный 1.5 часовой фильм (25 GB) на Bluray. Сколько времени займет перекодировать его в 8 гиговый рип максимального качества? Знаю зависит от многого, но чисто теоретически - рип на видеокарте GTX 600 Ti не одного фильма не может занимать больше 1 дня?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	24. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
	Сообщение от Вопрос по видео on 29-Окт-16, 12:22
	одного фильма*
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	25. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+1 +/–
	Сообщение от yrii2121 (ok) on 29-Окт-16, 12:53
	> А можно полюбопытствовать? Возьмем обычный 1.5 часовой фильм (25 GB) на Bluray. > Сколько времени займет перекодировать его в 8 гиговый рип максимального качества? > Знаю зависит от многого, но чисто теоретически - рип на видеокарте > GTX 600 Ti не одного фильма не может занимать больше 1 > дня? хз, я не проф. кодировщик. кодирую больше для себя и не часто. зависит от разных факторов: хар-ки ЭВМ, содержание видео... Я думаю, что если "порыться" по интернету, то какую-нибудь статистику найти можно будет.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	31. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-16, 17:36
	> А можно полюбопытствовать? Возьмем обычный 1.5 часовой фильм (25 GB) на Bluray. > Сколько времени займет перекодировать его в 8 гиговый рип максимального качества? > Знаю зависит от многого, но чисто теоретически - рип на видеокарте > GTX 600 Ti не одного фильма не может занимать больше 1 > дня? Видеокарта тут ни при чем - все качественные рипы кодируются только на CPU. Из практики, на моем разогнанном i7-2600K x265 на кодировании 1080p с битрейтом порядка 2000 kbit/s выдает порядка 1.5 fps, плюс-минус 0.3 в зависимости от контента. Качество при этом близко к оригиналу (SSIM ~ 0.98-0.99). При более высоком bitrate скорость еще больше падает. А дальше считайте сами. Учтите только, что кодировать надо как минимум два прохода.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	37. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+1 +/–
	Сообщение от Аноним (??) on 31-Окт-16, 00:03
	> Сколько времени займет перекодировать его в 8 гиговый рип максимального качества? А это зависит от того сколько ты готов ждать :). Чем больше ресурсов проца кодек может скушать тем лучше он может компенсировать движение и проч, достигая лучшего качества при меньшем размере или меньшего размера при равном качестве. И сколько это займет больше всего определяется мощностью проца и пределами толерантности. Скажем если жать в VP9 - он делает h.264 по битрейт/качество как с куста. Но на самых медленных режимах скорость кодирования может начать измеряться не в fps а в fpm. Frames per minute. И тогда кодирование может занять до-фи-га. В общем перфекционизм штука такая...
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	42. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+/–
	Сообщение от Аноним 80_уровня (ok) on 01-Ноя-16, 16:26
	Я бы не использовал видеокарту. Нафик. А так — 12-36 часов, в зависимости от степени перфекционизма и свежести процессора (x265, говорят, неплохо оптимизировали для AVX2).
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	38. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+1 +/–
	Сообщение от Аноним (??) on 31-Окт-16, 00:05
	> 3. Она там используют x264/x265, а что насчет открытых кодеков? Они не > такие хорошие?Есть ли конкурент x264/x265? Сами эти кодеки открытые. Но патентованные. В exUSSR на это можно и забить. Если забивать не хочется и например хочется в браузере смотреть - посмотри на VP9. Он легко обижает x264 по битрейт/качество и рубается на равных с x265. Но вот кодирует он медленно. То-есть это конечно же настраивается, но на уровнях максимального качества он таки слоупок.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	30. "Выпуск мультимедиа-пакета FFmpeg 3.2"	–1 +/–
	Сообщение от Аноним (??) on 30-Окт-16, 17:25
	Я в свое время занимался рипами (для собственного пользования и интереса; к профи себя не причисляю), и частенько использовал avisynth. Вроде бы, "профи" тоже в свое время считали его "правильным" инструментом. Так вот, под Linux достойного аналога нет и не предвидится, хотя многое из его арсенала есть и в ffmpeg. Также под Linux нет миллиона GUI, которые упрощают и делают более наглядным кодирование и позволяют визуально оценить результат. Но, конечно, главное - это грамотно подобрать кодек и параметры кодирования. Кодеки под Linux есть, и если не боишься командной строки и есть куча свободного времени, то всё возможно.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	36. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+1 +/–
	Сообщение от Аноним (??) on 30-Окт-16, 23:58
	> Но, конечно, главное - это грамотно подобрать кодек и параметры кодирования. Кодеки > под Linux есть, и если не боишься командной строки и есть > куча свободного времени, то всё возможно. В ffmpeg кодеки и есть, их там ДО-ХРЕ-НА. Найти формат который ffmpeg не прожует - еще суметь надо. И никакой маздайной возни с кодекпаками и конфликтами кодеков. То что человеку надо - грамотно параметры кодирования выбрать. Все это без проблем, особенно для штучных вещей. Если с ffmpeg не вломак повозиться - он умеет немеряно. Насколько я помню - гугель вроде как именно им транскодирует видео на ютубе, а для них все это - вопрос на миллион и даже не один.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	40. "Выпуск мультимедиа-пакета FFmpeg 3.2"	–1 +/–
	Сообщение от Аноним (??) on 31-Окт-16, 12:55
	>  ffmpeg кодеки и есть, их там ДО-ХРЕ-НА. Найти формат который ffmpeg не прожует - еще суметь надо. И никакой маздайной возни с кодекпаками и конфликтами кодеков. Речь была не о кодеках, а об обработке видео и звука.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	35. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+2 +/–
	Сообщение от Аноним (??) on 30-Окт-16, 23:50
	> имея превосходное качество. Я слышал для этого нужно мощное железо, которое > позволяет кодировать в несколько проходов (и якобы чем больше, тем лучше) Проходов делается два. В первом проходе кодек делает быстрое прикидочное кодирование для общего понимания насколько сложно те или иные кадры кодировать. Соотношение размера и качества при этом настолько ГЭ что результат обычно даже не сохраняют. Только статистику по кадрам. Хотя в ffmpeg можно и видео с первого прохода сохранить, но его соотношение размера и качества - полный трэш. Во втором проходе делается "настоящее" кодирование. За счет первого прохода кодек заранее знает что будет дальше. Поэтому может гораздо более грамотно раскинуть бюджет размера файла (или бандвиза). Потому что априори знает - насколько сложно (затратно по битам) кодировать то что будет дальше. > и все такое. Вобщем вопрос в чем - можно ли создавать > такие "самые четкие рипы", прям топовые рипы - на Linux. Да. Используй двухпроходное кодирование. Ffmpeg его умеет и там к тому же дофига параметров кодеков можно крутить. Все зависит только от твоих умений и знания работы кодека. > Я ведь правильно понимаю - для этого они на винде используют ПО, > которое является надстройкой все того же FFmpeg? Зачастую - да. Более того - нарисовать GUI на все опции FFMPEG - просто напряжно. Ты его полный help вообще видел? У ffmpeg больше опций чем в любой другой программе. Это швейцарский нож видеокодирования с 2500 лезвиями. Одним его help-ом можно зашибить, если распечатать. > Значит весь тюнинг и кодирование рипов можно делать и в Linux, > если есть видеокарта nVidia? Или нет? Можно и без видеокарты от нвидия, на CPU. Только CPU желательно помощнее. Но не обязательно. В крайнем случае будешь долго ждать результата, только и всего. Если тебе принципиален минимальный размер при максимуме качества, 1) Используй 2-проходное кодирование. 2) Затвикай кодеку параметры которые отвечают за cpu usage vs speed чтобы тот предпочитал медленное но качественное кодирование. Насколько? Зависит от соотношения твоего терпения, мощности проца и желаемого качества. 3) Изучи параметры кодека и попробуй покрутить наиболее обещающие из них. Тут в общем то весь фокус в том что ты должен получить некое ощущение инструмента и понимание его пределов возможностей и поведение в разных ситуациях. А дальше можно уже более осмысленно крутить параметры под ситуацию. Только имей в виду что стоит понимать некоторые основы. Ну там кто такие intra frame и inter frame ("I" и "P" в терминологии MPEG, в мпегах еще есть B-frames) и какие есть tradeoff по например i-frames vs время seek. Самый интересный кодек который попался мне - AOM: им я придавил FullHD последовательность до жалких 512Кбит и потом ... потом едва мог найти артефакты в паре сцен. Через какие-то полгодика у нас будет крутейшее видео в вебе.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	39. "Выпуск мультимедиа-пакета FFmpeg 3.2"	+2 +/–
	Сообщение от Аноним (??) on 31-Окт-16, 00:39
	> На том же Rutracker'е есть четкие ребята, спецы в своем деле - кодировании видео. Есть целые известные RG (Release Groups), которые "знают как надо". За многие годы они стали настоящими профи и делают шикарные рипы, которые весят очень мало, при этом имея превосходное качество. Значительная часть рипов на рутрекере до сих пор делается кодеком XviD, который устарел около 10 лет назад. При этом о «превосходном качестве» при минимальном размере, естественно, говорить не приходится. Сейчас мэйнстрим — формат H.264 и кодек x264, передовые технологии — форматы VP9 (кодек libvpx) и H.265 (x265), будущее — AoM. Всё это доступно в т.ч. и на Linux. > Я слышал для этого нужно мощное железо, Сойдёт любое железо, вопрос только в скорости кодирования. Каждое новое поколение кодеков жмёт медленней примерно на порядок. Для скорости libvpx-vp9 очень полезно наличие набора инструкций AVX2. > кодировать в несколько проходов (и якобы чем больше, тем лучше) Как правило, кодеки могут кодировать только в один или два прохода. В случае с кодеком x264 два прохода нужны исключительно для впихивания видео в заданный объём (режима ABR), если же выбран контроль ширины потока по качеству (CRF), который предпочтительно использовать при отсутствии жёстких лимитов на объём, то возможен только один проход. В отличие от x264, в libvpx-vp9 двухпроходный режим возможен и сrf, и его рекомендуется использовать, т.к. с ним доступно больше техник сжатия. > Вобщем вопрос в чем - можно ли создавать такие "самые четкие рипы", прям топовые рипы - на Linux. Можно. > Я ведь правильно понимаю - для этого они на винде используют ПО, которое является надстройкой все того же FFmpeg? Не обязательно: можно использовать, например, standalone x264 и mkvtoolnix. > если есть видеокарта nVidia Это вообще обычно не нужно: аппаратное сжатие видео всегда проигрывает по уровню сжатия программному, т.к. поддаётся параллелизации только в ущерб глубине поиска похожих блоков. Видеокарта может быть полезна, например, для восстановления чересстрочного видео до прогрессивного с удвоенной частотой кадров нейронными сетями (NNEDI3).
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема