Этого треда уже нет.
Это копия, сохраненная 10 марта в 03:16.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
1611006410332.png72 Кб, 250x250
FFmpeg и общий кодирования видео тред №4 /ffmpeg/ Windows 10: Chromium based 3056070 В конец треда | Веб
FFmpeg и общий кодирования видео тред №4

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

FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают в ИТТ.

Скачать тут: https://www.ffmpeg.org/download.html

Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.

Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.

Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички в step-by-step how-to стиле для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.

Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.

Самые ходовые видео-кодеки на данный момент - VP9 и H.264. Подробный разбор их режимов кодирования читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.

Вики WebM-треда: https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s

ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.

Бонусом в треде обсуждается youtube-dl - утилита для нормального выкачивания видео с ютуба, вк, порнхаба и ещё миллиона других видеосервисов. Не совсем кодирование, но скорее всего ты тоже этим дерьмом занимаешься, если что-то делаешь с видео, так что давай осваивай тоже нормальную утилиту вместо просмотра рекламы и установки зондов. Тоже опенсорс подо всё, что способно выполнять AND NOT и XOR.

Тред №0: https://2ch.hk/s/arch/2020-08-05/res/2591244.html (М)
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html (М)
Тред №2: https://2ch.hk/s/arch/2021-09-23/res/2979843.html (М)
Тред №3: https://2ch.hk/s/res/3029626.html (М)
Windows 10: Firefox based 2 3056496
Как работает crf, когда я указываю конкретный битрейт?
Android: Mobile Safari 3 3056507
>>3056061 →

>Ав1 по битрейту не просто в два, раза в три лучше 264


Пруфы будут или как всегда?

>>056496
Зависит от библиотеки кодера. У тебя libx264, libx265 или libvpx?
Windows 10: Firefox based 4 3056509
>>056507
Интересно было бы услышать про все, ну или про libvpx.
Android: Mobile Safari 5 3056557
>>3056554 →
Ты вообще знаешь что-нибудь о запуске программ из командной оболочки?

>>056509
Ну, про libx264 попробую завтра с работы днëм рассказать.
meme.webm8 Мб, webm,
1280x720, 5:58
Windows 10: Яндекс браузер 6 3056573
>>056507

>Пруфы будут или как всегда?



Подобное видео ни в h265, ни в h264 тем более невозможно закодировать с читабельным текстом, для этого потребуется битрейт в десятки раз больше
Общий поток: 186 Кбит/сек
Windows 10: Яндекс браузер 7 3056574
Экстремальный пример, в реальных видео тоже будет выигрыш, но не такой большой конечно
Linux: Firefox based 8 3056625
>>056573>>056574

> Экстремальный пример


> Подобное видео


> с читабельным текстом


> 186 Кбит/сек


Спасибо за пример.
Четверть текста превратилась в нечитаемую размазню.
Выходит, что AV1 способен сгенерировать инфомусор с шириной потока втрое меньше, чем h.264. Если бы ты сразу уточнил такое, то я бы и спорить не стал. Большинство видеороликов содержат не такое.
Кстати, припоминаю, что ещё полтора десятка лет назад был такой кодек для телеконференций — VP7. Статическая картинка (это когда в кадре человек сидит почти неподвижно и болтает) у него выходили с очень маленькой шириной потока, но остальные сюжеты выходили очень сильно посредственно в смысле эффективности сжатия.
Windows 10: Firefox based 9 3056718
>>056573
Дык сравни с vvc.

>в десятки раз больше


Ты чет загнул, в 2-3 раза больше, но не в десятки раз.
doom.webm14,8 Мб, webm,
640x360, 41:48
Windows 10: Chromium based 10 3056729
Пытаюсь сделать вебм с кей фреймом в на всю длинну
умудрился 40 мин запихнуть в 360p на 50битрейта в 14мб.
Но можно ли лучше?
В идеале там вообще должно быть 5 кейфремов которые будут сменяться по таймингу песни, как в оригинальном видосе.
РАсскажите покажите как улучшить эту еботу.

использовал команду
ffmpeg -r 1 -loop 1 -i 1.jpg -i doomer.mp4 -t 00:41:47 output.mp4
получилось 41мб

потом прогнал через webm_for_retard сделал аудио битрейт 45кб и видео 10кб. Но видать битрейт ставится по максимальному параметру. Поэтому на выходе получил 50 битрейта в среднем
Android: Mobile Safari 11 3056739
>>056729
Ты ебанутый
Скинь оригинал картинки и аудио
out.webm20,1 Мб, webm,
1280x720, 41:49
Windows 10: Яндекс браузер 12 3056771
>>056729
Раз в 14 минут меняется картинка и лучше качество звука
Windows XP: Firefox based 13 3056810
>>056729

> В идеале там вообще должно быть 5 кейфремов которые будут сменяться по таймингу песни



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

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

Видеоформаты не очень подходят для такой оптимизации пустых кадров без изменений, в них обычно не предполагается теоретическая возможность пользоваться данными, расположенными за тысячу кадров, поскольку от декодера ожидается работа с локальным куском потока в буфере, а не с файлом целиком. Если тебе нужно совместить аудио и презентацию несколько картинок, возьми подходящий инструмент. Например, Flash.
(ха-ха-ха, возьмите меня в программу «Аншлаг»)
Если без шуток, то ты можешь использовать YTMND для такой демонстрации. Там, правда, перемотки вообще нет.
Android: Mobile Safari 14 3056890
>>056810
Ну я же сделал как он сказал, ровно три ключевых кадра для трёх картинок, работает нормально
Windows 10: Chromium based 15 3056926
>>056739
https://www.youtube.com/watch?v=wcaZcbain2s
>>056771
Охуенно анон, как сделал?
>>056810
Да все эти траблы меня не волнуют. Я просто хочу сделать 40 минутную легкую вебм чтобы форсить ее на дваче
Windows 10: Chromium based 16 3056938
>>056771
Кстати , ты слегка промахнулся с размером
двач почему то округляет рзамер видосов вверх и тип 20 мб округляет до 20.1
а вот 19.9 для него ровно 20. ПОэтому это говно влезет в /b/ а твой видик нет
out.webm19,5 Мб, webm,
1280x720, 41:49
Windows 10: Яндекс браузер 17 3056971
>>056926
>>056938
Держи
https://0bin.net/paste/aYClIoeL#a0YONiaykhQZwxjnIZ9r+MwIgEuzXpb+swjTDDGAncM
С помощью Mkvmerge файл уменшился на мегабайт, и теперь стало нормально
Windows 10: Chromium based 18 3057000
>>056971
Так а как ты ключевые кадры-то расставил?
Android: Mobile Safari 19 3057002
>>057000
Три разных видоса склеил, а кодировщик достаточно умный чтоб не пихать лишней информации с параметром -g 999999
Android: Mobile Safari 20 3057497
Привет анон. Можно ли как-то вырезать начало, конец и главное - середину видео (5 минут в обе стороны от середины) и слепить из этого отдельное видео? Было бы вообще хорошо, если это можно сделать без повторного кодирования.
Windows 10: Chromium based 21 3057658
>>057497
Не занимайся ерундой и скачай adobe premiere.
image.png25 Кб, 305x578
Windows 10: Chromium based 22 3057669
Есть BDшник японского мультика, чем мне рипать что бы сбавить маленько размер и разбить на эпизоды?
Windows 10: Chromium based 23 3057670
>>057658
losslesscut
Windows XP: Firefox based 24 3057680
>>057669
Инструкцией по рипам с BD, включающей автоматическую разбивку по главам.
Android: Mobile Safari 25 3057681
>>057497
>>057670
Avidemux то что тебе нужно
>>057669
Mkvtoolnix
Windows 10: Chromium based 26 3057753
>>057669
Зачем брать образ с няши, чтобы потом его рипать, когда я уверен рипа любого аниме в разных качествах хоть жопой жуй.
Windows 10: Chromium based 27 3057768
>>057753
Не могу найти нормальный рип Love Hina, если знаешь где, буду благодарен ссыли
Android: Mobile Safari 28 3057775
>>057753
>>057768
Говноеды, надо смотреть именно в Блю рей качестве, а не всякое пересжатое дерьмо. Вам места жалко, что за хуйня? 50 Гб экономить когда жёсткие диски на терабайты копейки стоят
Windows 10: Chromium based 29 3057779
>>057775
Я раздаю японские мультики своим знакомым по локальной сети, не каждый из них эстеты, как мы.
Android: Mobile Safari 30 3057780
>>057779
Тем более, по локальной сети по гигабиту за пару минут передастся
Не нужно быть эстетом, достаточно не жрать самое конченное пересжатое дерьмо
qbittorrent20211003140942846.png2 Кб, 232x50
Windows 10: Chromium based 31 3057782
>>057780
Мое уточнение было к тому, что не каждый имеет 200гб места на смартфоне/планшете/ноутбуке/компьютере что бы просто посмотреть Love Hina в хорошем качестве
Android: Mobile Safari 32 3057789
>>057782
Можно смотреть с твоего жёсткого диска без скачивания, в чём проблема. И там 200 Гб несколько фильмов занимают
Windows 10: Chromium based 33 3057828
>>057768
Чем тебе вот эти не нравятся вообще?
https://ny.iss.one/view/1154946
https://ny.iss.one/view/1412863 этот также уже с бд сделан
https://ny.iss.one/view/1215876 здесь меньше вес, но качество хуже наверное.
https://ny.iss.one/view/664955 720п
https://ny.iss.one/view/664960 720п спешлы
https://rutracker.org/forum/viewtopic.php?t=5080133
https://rutracker.org/forum/viewtopic.php?t=5081316
Пять секунд буквально найти.
>>057775
Сейчас качать bdremux будет только додик, когда уже давно можно смотреть их онлайн, не качая, если конечно не для коллекции.
Windows 10: Firefox based 34 3057831
>>057828

> когда уже давно можно смотреть их онлайн


Говноед обнаружен! Произвести дезинфекцию треда.
Windows 10: Chromium based 35 3057850
>>057831
Поясни или хрен соси.
Windows 10: Chromium based 36 3057858
>>057828

>https://ny.iss.one/view/1154946


Вот эту я заберу, пожалуй. Благодарю, почему-то не смог найти именно этот торрент.

>Чем тебе вот эти не нравятся вообще?


Мне нужен максимально непохеренный BDRip, что смог бы сохранить приличное качество и не весить как сам BD. Это легче и по структуризации папок, так и не сильно бьет по памяти, ведь у меня огромная датабаза из мультиков, фильмов и музыки на случай Чебурнета. Если же я скачаю 720p с битрейтом пенька, то это уже будет говноедство уровня прослушивания музыки в ВК, или ещё хуже, просмотра японских мультиков с японской озвучкой на shikimori.
Windows 10: Chromium based 37 3057859
>>057858

> с русской озвучкой


Совсем обдвачевался, извиняйте
Windows 10: Chromium based 38 3057874
>>057858
720п в hevc 10 bit отлично выглядит годно даже при минимальном битрейте. Не надо тут. Я так все 2 сезона Fate UBW посмотрел, каждая серия по 200мб всего весит, фуллхд уже по 300-400мб. С бдремуксом разницы не увидишь.
Windows 10: Chromium based 39 3057882
>>057874
Я соглашусь с тем, что 720п действительно смотрится неплохо на 1080p мониторе, сейчас Наруто Шиппуден смотрю и вполне неплохо, однако я стараюсь смотреть в будущее и прибираю к рукам самый оптимальный для меня вариант. 720x480 разрешение, что стандартное для DVD уже выглядит не очень даже на 1080p, про 4K я молчу. Никогда не будешь уверен, останутся ли нынешнии потребляди на 1080p разрешении мейнстримно или же будут продвигаться всё выше и выше с каждым десятилетием, потому лучше иметь наилучшее разрешение и, в идеале, с наиболее оптимальным битрейтом. Я бы скачиывал Remux, но не к каждому мультику/фульму такой найдётся, а самому рипать так на это ещё больше денег уйдет, так что я выбрал такой путь.
Android: Mobile Safari 40 3057897
>>057658
>>057670
>>057681
Ффмпегодрочеры соснули что ли?
Android: Mobile Safari 41 3057939
>>057897
Нет. Только ты.
Windows 8: Firefox based 42 3058207

>общий кодирования видео тред



тупой дебил на связи. нихуя не понимаю как настроить и пользоваться этим ffmpeg, клиника нахуй, поэтому юзаю xmedia recode. всё вроде бы устраивает, но есть проблема с субтитрами. если я хочу сделать хардсаб, то текст может быть слишком большой/маленький или вырвиглазного цвета/шрифта. настройку это параметра не могу найти. в общем подскажите, есть какое-то решение проблемы (кроме сaмoвыпилa), может там надо сочетание кодеков подбирать или загрузить отсутствующие шрифты/библиотеки/аллаха? ПАМАХИТЕ

вот два примера из разных роликов, как криво он может рендерить
Windows XP: Firefox based 43 3058217
>>058207
Обратитесь в службу поддержки xmedia recode.
Windows 10: Firefox based 44 3059662
Аноны, в чем разница между 8-bit и 10-bit? Это надо монитор с поддержкой 10bit цвета или можно как-то напердолить 6+FRC?
Windows 10: Firefox based 45 3059663
>>059662

>напердолить на монитор 6+FRC


фикс
Android: Mobile Safari 46 3059768
>>059662
10 бит лучше сжимается, лучше всегда его использовать, даже на 8 бит видео
Windows XP: Firefox based 47 3059811
>>059662
Если у тебя на входе видео с 8 битами на канал (в подавляющем большинстве случаев это так), то на выходе оно не увеличит разрядность, хоть ты его в формат с 16 битами запихни, хоть с 32. Картинка не изменяется, за исключением потерь от сжатия, и никакой особенный монитор не требуется для этого обычного видео.

Перевод в 10-битные значения позволяет улучшить сжатие и/или уменьшить визуальные искажения из-за повышения точности коэффициентов преобразований. В общем и целом, это просто такой промежуточный формат.
Windows 7: Chromium based 48 3059926
ffmpeg кириллицу не читает. Всякие бордюры и поребрики вместо букв. Что делать?
Android: Mobile Safari 49 3059957
>>059926
Поставь windows terminal
Android: Mobile Safari 50 3060296
>>059662
Вот эти двое >>059768>>059811 излагают близко к реальности. Попробую для интересующихся снова изложить в форме не очень короткого эссе. Заранее прошу прощения, что начинаю сильно издалека.

Основные понятия
1. Изображение в типичном цветном видоематериале представляет собой трëхкомпонентный растр прямоугольную плоскую таблицу из идентичных прямоугольных элементов (точек, пикселей), для каждого из которых определено значение яркости и цвет. Фактически каждой точке сопоставлено три числа, соответствующие трехкомпонентной аддитивной модели цветного зрения человека.
2. Цвет. Наиболее распространëнной моделью воспроизведения цветных изображений для светящихся устройств является аддитивная модель RGB. Иллюзия цветового ощущения для человека создаëтся путëм одновременного излучения (из источника, близкого к точечному) света всего трëх тонов, но варирующейся интенсивности. Значению интенсивности каждого из тонов можно сопоставить по числу, пропорциональному этому значению. Для удобства работы с сигналами преобразования информации и учëта особенностей зрения человека, чаще используется не аддитивная модель XYZ (CIE 1931) или RGB (красный, зелëный, синий), а модель YCbCr, получаемая линейным преобразованием из RGB, и содержащая три компонента - яркость (интенсивность) и два цветоразностных. Если использовать только яркостную составляющую, то из таких точек можно собрать «чëрно-белое» изображение, аналогичное тому, которое воспроизводит нецветной кинематограф. Математически линейное преобразование из RGB в YCbCr определено как система трëх линейных уравнений, где значение каждого из компонентов одной модели равно взвешенной сумме трëх компонентов другой модели. Линейная алгебра представляет такую систему как вектор, составленный из значений компонентов, например YCbCr [Y, U, V], являющийся результатом произведения вектора, например RGB [R, G, B], на некоторую матрицу преобразования M. Такие матрицы определены рядом стандартов, например в BT.709 или в BT.601.[/spoiler]

Изображение как функция
Для упрощения рассуждений, дальнейшее рассмотрение буду вести в отношении однокомпонентного изображения. Общность рассуждений это не нарушит, т. к. каждый из компонентов обрабатывается отдельно и почти единообразно. Допустим, что речь пойдëт только о изображении, составленном на основе только яркостной компоненты.
Итак, изображение (в том случае, который рассматривался изначально) - это дискретный составной объект, который можно представить в виде прямоугольной таблицы, в ячейки которой вписаны числа, пропорциональные яркости точки с соответствующими строке и столбцу координатами точки изображения. Можно взять, например, строку чисел из таблицы и построить зависимость значения из ячейки от порядкового номера ячейки. Зависимость эта для большинства изображений реальных сцен будет содержать избыточность. Так будут довольно обширные области, где значения изменяются в сравнительно небольших пределах, будут области с примерно повторяющимся характером зависимости и т. п. Возникает вопрос, заключающийся в том, можно ли представить информацию о имеющейся зависимости более компактно - использовать для воспроизведения меньше чисел, чем содержит сама последовательность.
Математика успела наработать довольно приличный аппарат для анализа и синтеза специальных объектов моделирующих связь между двумя множествами значений. Такими объектами являются функции. Функция как раз ставит в однозначную (у математиков есть и более суровые обобщения, но сейчас достаточно и школьного определения) зависимость два множества чисел: множество значений функции и множество значений аргумента функции. Для моделирования изображения аргументом функции будет номер ячейки, а значением функции - значение яркости.
Рассмотренная модель без проблем обобщается на функцию двух аргументов, когда моделировать нужно изображение из многих строк.

Анализ функций и изображения
Есть одно из фундаментальных преобразований функций в гильбертовом пространстве, определяемое через свëртку - это преобразование Фурье.
Если рассуждать по-проще, то пусть у нас будет некоторая функция из множества похожих на неë свойствами. Множества такого непростого, что любые функции из него можно складывать и перемножать между собой и ещë с какими-нибудь числами, допустим, действительными. И в результате сложений и перемножений получать тоже функцию, и из этого же множества. Допустим, что в множестве этом хитром допустим не только описанный чуть ранее синтез, но и обратное действие - анализ. Т. е. можно взять из множества любую функцию y(x), где x - это аргумент, который может принимать значение любого числа из множества X. Тогда X - это область определения функции y(x), если для всех элементов множества функция имеет смысл, т. е. значение. Теперь допустим, что мы нашли такое множество функций Z, каждая функция в котором имеет ту же область определения, что и y(x), а если взять и перемножить каждую функцию из Z на какое-нибудь действительное число, а потом такие произведения сложить, то в результате мы получим в точности значения функции y(x). Такая хитрая операция будет (при чтении уравнения в одну сторону) называться разложением функции y(x) на составляющие. Пространство функций, на котором допустимо всë описанное непотребство, у математиков называется гильбертовым. В математической литературе определение гораздо короче, но я надеюсь, что смог объяснить более доходчиво. Возвращаясь к разложению, хочу особо отметить те самые сомножетели, которые были не функциями, а просто числами. Это коэффициенты разложения. Если для разложения функции y(x) по наперëд заданному множеству функций Z (базису разложения) коэффициенты определяются единственным образом, то такое разложение называется ортогональным.
Итак, я напомнил понятия функции, пространства функций, разложения, коэффициентов разложения и ортогональности.
Среди всех известных школьникам элементарных функций есть весьма удобные для вот таких разложений базисные функции - тригонометрические. Синус и косинус. Меняются плавно, являются периодическими, определены и ограничены на всëм множестве действительных чисел, а любая пара таких функций ортогональна на интервале, содержащем целое натуральное число периодов каждой. Т. е. sin(x), sin(2x), sin(3x) и т. д. взаимно ортогональны.
Завтра попробую рассказать про спектры, ДКП-преобразование, интерполяцию и способ синтеза изображения сколь угодно высокого разрешения с отсчëтами сколь угодно высокой точности, если разложение производилось по конечному числу отстëтов с дискретным множеством значений (конечной точностью).
Android: Mobile Safari 50 3060296
>>059662
Вот эти двое >>059768>>059811 излагают близко к реальности. Попробую для интересующихся снова изложить в форме не очень короткого эссе. Заранее прошу прощения, что начинаю сильно издалека.

Основные понятия
1. Изображение в типичном цветном видоематериале представляет собой трëхкомпонентный растр прямоугольную плоскую таблицу из идентичных прямоугольных элементов (точек, пикселей), для каждого из которых определено значение яркости и цвет. Фактически каждой точке сопоставлено три числа, соответствующие трехкомпонентной аддитивной модели цветного зрения человека.
2. Цвет. Наиболее распространëнной моделью воспроизведения цветных изображений для светящихся устройств является аддитивная модель RGB. Иллюзия цветового ощущения для человека создаëтся путëм одновременного излучения (из источника, близкого к точечному) света всего трëх тонов, но варирующейся интенсивности. Значению интенсивности каждого из тонов можно сопоставить по числу, пропорциональному этому значению. Для удобства работы с сигналами преобразования информации и учëта особенностей зрения человека, чаще используется не аддитивная модель XYZ (CIE 1931) или RGB (красный, зелëный, синий), а модель YCbCr, получаемая линейным преобразованием из RGB, и содержащая три компонента - яркость (интенсивность) и два цветоразностных. Если использовать только яркостную составляющую, то из таких точек можно собрать «чëрно-белое» изображение, аналогичное тому, которое воспроизводит нецветной кинематограф. Математически линейное преобразование из RGB в YCbCr определено как система трëх линейных уравнений, где значение каждого из компонентов одной модели равно взвешенной сумме трëх компонентов другой модели. Линейная алгебра представляет такую систему как вектор, составленный из значений компонентов, например YCbCr [Y, U, V], являющийся результатом произведения вектора, например RGB [R, G, B], на некоторую матрицу преобразования M. Такие матрицы определены рядом стандартов, например в BT.709 или в BT.601.[/spoiler]

Изображение как функция
Для упрощения рассуждений, дальнейшее рассмотрение буду вести в отношении однокомпонентного изображения. Общность рассуждений это не нарушит, т. к. каждый из компонентов обрабатывается отдельно и почти единообразно. Допустим, что речь пойдëт только о изображении, составленном на основе только яркостной компоненты.
Итак, изображение (в том случае, который рассматривался изначально) - это дискретный составной объект, который можно представить в виде прямоугольной таблицы, в ячейки которой вписаны числа, пропорциональные яркости точки с соответствующими строке и столбцу координатами точки изображения. Можно взять, например, строку чисел из таблицы и построить зависимость значения из ячейки от порядкового номера ячейки. Зависимость эта для большинства изображений реальных сцен будет содержать избыточность. Так будут довольно обширные области, где значения изменяются в сравнительно небольших пределах, будут области с примерно повторяющимся характером зависимости и т. п. Возникает вопрос, заключающийся в том, можно ли представить информацию о имеющейся зависимости более компактно - использовать для воспроизведения меньше чисел, чем содержит сама последовательность.
Математика успела наработать довольно приличный аппарат для анализа и синтеза специальных объектов моделирующих связь между двумя множествами значений. Такими объектами являются функции. Функция как раз ставит в однозначную (у математиков есть и более суровые обобщения, но сейчас достаточно и школьного определения) зависимость два множества чисел: множество значений функции и множество значений аргумента функции. Для моделирования изображения аргументом функции будет номер ячейки, а значением функции - значение яркости.
Рассмотренная модель без проблем обобщается на функцию двух аргументов, когда моделировать нужно изображение из многих строк.

Анализ функций и изображения
Есть одно из фундаментальных преобразований функций в гильбертовом пространстве, определяемое через свëртку - это преобразование Фурье.
Если рассуждать по-проще, то пусть у нас будет некоторая функция из множества похожих на неë свойствами. Множества такого непростого, что любые функции из него можно складывать и перемножать между собой и ещë с какими-нибудь числами, допустим, действительными. И в результате сложений и перемножений получать тоже функцию, и из этого же множества. Допустим, что в множестве этом хитром допустим не только описанный чуть ранее синтез, но и обратное действие - анализ. Т. е. можно взять из множества любую функцию y(x), где x - это аргумент, который может принимать значение любого числа из множества X. Тогда X - это область определения функции y(x), если для всех элементов множества функция имеет смысл, т. е. значение. Теперь допустим, что мы нашли такое множество функций Z, каждая функция в котором имеет ту же область определения, что и y(x), а если взять и перемножить каждую функцию из Z на какое-нибудь действительное число, а потом такие произведения сложить, то в результате мы получим в точности значения функции y(x). Такая хитрая операция будет (при чтении уравнения в одну сторону) называться разложением функции y(x) на составляющие. Пространство функций, на котором допустимо всë описанное непотребство, у математиков называется гильбертовым. В математической литературе определение гораздо короче, но я надеюсь, что смог объяснить более доходчиво. Возвращаясь к разложению, хочу особо отметить те самые сомножетели, которые были не функциями, а просто числами. Это коэффициенты разложения. Если для разложения функции y(x) по наперëд заданному множеству функций Z (базису разложения) коэффициенты определяются единственным образом, то такое разложение называется ортогональным.
Итак, я напомнил понятия функции, пространства функций, разложения, коэффициентов разложения и ортогональности.
Среди всех известных школьникам элементарных функций есть весьма удобные для вот таких разложений базисные функции - тригонометрические. Синус и косинус. Меняются плавно, являются периодическими, определены и ограничены на всëм множестве действительных чисел, а любая пара таких функций ортогональна на интервале, содержащем целое натуральное число периодов каждой. Т. е. sin(x), sin(2x), sin(3x) и т. д. взаимно ортогональны.
Завтра попробую рассказать про спектры, ДКП-преобразование, интерполяцию и способ синтеза изображения сколь угодно высокого разрешения с отсчëтами сколь угодно высокой точности, если разложение производилось по конечному числу отстëтов с дискретным множеством значений (конечной точностью).
Android: Mobile Safari 51 3060812
Скиньте какое нить видео которое нужно закодировать в маленький размер в охуенном качестве. Надоело видеть как шакалят в полный хлам. Сделаю вам вебм
Windows 7: Firefox based 52 3060853
>>056573

Музыка за душу берёт! Откуда музыка? Случайно не Hans Zimmer ли это?
Windows 7: Firefox based 53 3060855
Впрочем, чего это я >>060853 спрашиваю, в метаданных же написано, что это Thomas Bergersen «Empire of Angels» (из альбома «Sun» 2014 года, как я понимаю).
Windows 10: Chromium based 54 3061056
есть мп4 80мб, сжимаю чтобы уместилась в лимит 20мб

ffmpeg -i a.mp4 -vcodec libx265 -crf 24 b.mp4

в итоге на харкаче проигрывается только звук, а вместо шебм серый экран. чяднт?
Windows 10: Chromium based 55 3061091
>>061056
Браузеры не поддерживают hevc. У нас тут неспроста webm-культура на борде.
image92 Кб, 1366x738
Windows 10: Firefox based 56 3061122
>>061091

> Браузеры не поддерживают hevc.


Поддерживает, но только один браузер.
Windows 10: Chromium based 57 3061126
>>061122
А, ну это всё меняет.
Android: Mobile Safari 58 3061172
>>061122
Edge с расширенным тоже поддерживает
Windows 10: Firefox based 59 3061178
>>061172
Эдж, который эдж, а не хром. Там же сноска есть. Так и ишак тоже, не видишь, что ли? Ишак технологичнее большинства выходит. Если кто напишет про патенты, то при внедрении h.264 что-то вопроса о патентах не возникало.
Windows 10: Palemoon 60 3061185
>>061178

> то при внедрении h.264 что-то вопроса о патентах не возникало


Возникало, только там было не всё так анально огорожено и вроде как мпегла пошла на уступки, чтобы h264 распространился.
Windows 10: Firefox based 61 3061188
>>061185
Нужно было и в случае с H.265 так же сделать, а не городить сотни форматов, которым нужна и аппаратная поддержка. Сэкономили на отчислениях, но юзер соснул, так как его huishen9998 не поддерживает прогрессивный формат huipizda14.88, аппаратную поддержку которого завезут только в huishen9999, покупай, гой! А так можно было бы купить видяху и проц с поддержкой хевка и раскошелиться на новые только при выходе VVC, всё-таки универсальный стандарт это всегда ради общего блага.
Windows 10: Chromium based 62 3061193
>>061188

> покупай, гой


Так-то вся суть
Windows 10: Palemoon 63 3061195
>>061188

> Нужно было


Разрабатывай свой формат и раздавай, мой маленький грязноштанник, а причём тут поддержка? Поддержку пилить никто не запрещает, её не пилят потому что нет развития сервисов, использующих этот кодек, аппаратура тут не при чём, можно и софтом декодить, ну и гнилой ff отказался от h265 после продажи своего анала гуглу задёшево, если я правильно помню.
Windows 10: Firefox based 64 3061200
>>061195

> мой маленький грязноштанник


Грязноштанники это те, кто запиливает свои аналоговнеты (государственный капитализм с налётом социализма, например), я же следую стандарту. Стандарт это H.265, он везде применяется, особенно в кино. Аналоговнеты в данном случае это AV1, VP8 и VP9, которые поглотили браузеры. Раз существует практика принудить распространять, пойти на уступки, так её нужно применять дальше.
1633799370502.png242 Кб, 375x501
Windows 10: Palemoon 65 3061204
>>061200

> отобрать и поделить лицензирование


> Я НЕ ГРЯЗНОШТАННИК МАМ


Вам таблетосы с правой или с левой?
Android: Mobile Safari 66 3061223
>>061178
Тупой сука, последний тоже поддерживает
Windows 10: Firefox based 67 3061252
>>061223
Нiт.
Linux: Firefox based 68 3061341
Думаю вам интересно будет посмотреть

https://www.reddit.com/r/AV1/comments/p8l581/my_testing_with_av1_cpuused_1_to_8_at_crfs_253545/
Windows 10: Firefox based 69 3061350
>>061200

>это AV1, VP8 и VP9


Они хороши для потокового вещания (искл. АВ1, т.к. он литералли неюзабелен), когда очень важно ужать файлы, но во всем остальном это говно сравнивать с залупой от мпег как-то стыдно. Это совершенно разные уровни. Хотя свободные форматы разрабатывают нихуевые такие корпорации.
image.png2,3 Мб, 1534x772
Windows 10: Chromium based 70 3061383
image.png70 Кб, 700x508
Linux: Firefox based 71 3061385
>>061383
Что и следовало ожидать.
Windows 10: Palemoon 72 3061394
>>061350

> Они хороши для потокового вещания


Потому потоковое вещание идёт в h264? По крайней мере на ютуб(создателе этих кодеков) и твиче. Они хороши лишь тем, что ютубу за них не надо платить, в остальном это тотальный мусор, даже для хранения информации, если не ставишь целью смотреть 8к или 144p видео на ютубе, то лучше воспроизводить в h264 вообще всё >=360p и <=1080p, здоровее глаза будут.
image997 Кб, 1366x768
Windows 10: Firefox based 73 3061395
>>061385
Я вот так делаю в данном случае.
Android: Mobile Safari 74 3061416
>>061385
Яндекс браузер тоже открывает
Windows 10: Chromium based 75 3061871
>>061122
Слышал, что фурифокс тоже поддерживает.
Windows 10: Firefox based 76 3061874
>>061871
Только если в linux с кастомным ffmpeg собрать.
Windows 10: Firefox based 77 3061887
Аноны, libx265 поддерживает OpenCL? На одном процессоре скорость 0.025x - вообще пиздец.
Android: Mobile Safari 78 3061960
>>061887
Нет. Какой пресет? Медленнее чем slow нет смысла использовать
Windows 10: Firefox based 79 3061962
>>061960
Пресет влияет только на размер и скорость сжатия? На качество влияет CRF?
Android: Mobile Safari 80 3061966
>>061962
Он влияет только на качество сжатия, размер остаётся таким же (почти)
Windows 10: Firefox based 81 3062273
>>061394

>Потому потоковое вещание идёт в h264?


Где? На ютабе вп9/ав1 вперемешку. У твича vp9 в мп4 завернут. В онлайн-кинотеатрах, скорее всего, так же, как и на твиче.
Android: Mobile Safari 82 3062513
>>062273

>На ютабе вп9/ав1 вперемешку.


Подтверждаю. Не так давно обратил внимание на то, что батарейки ноута хватает всего лишь на час видео с ютуба. А там AV1, который на программном декодере грузит процессор под 50-75%. VP9 грузит под 30-50. Но это тоже не комильфо.
Android: Mobile Safari 83 3062515
>>062513
Нехуй пользоваться некроговном без поддержки блять кодека 2013 года, отнеси его в помойку
1633981055579.png116 Кб, 589x219
Windows 10: Chromium based 84 3062521
>>062273

> Где? На ютабе вп9/ав1 вперемешку


Запустил стрим на ютубе, например, где вп9?
1633981157535.jpg72 Кб, 780x585
Windows 10: Chromium based 85 3062524
>>062273

> vp9 в мп4 завернут


Можно подробнее кто и как завернул?
Android: Mobile Safari 86 3062526
>>062515
Альтернатива стоит от 160 тысяч рублей. Как-то не очень мне эта сумма нравится.
Windows 10: Firefox based 87 3062530
>>062521
Стримы только в h264
Windows 10: Chromium based 88 3062536
>>062530
А под "потоковым вещанием" имелись ввиду не стримы? Просто гугл на этот вопрос несколько теряется.
Android: Mobile Safari 89 3062637
>>062530
Стримы от 1440 в vp9
Windows 10: Chromium based 90 3062639
>>062637
Ну прогресс не стоит на месте, надеюсь к моменту когда массово платформы будут стримить от 1440 уже в ходу будет адекватный кодек, хотя у меня всё равно не будет достаточной пропускной способности канала, чтобы такой контент оценить.
Windows 7: Firefox based 91 3062763
>>062639
А какой кодек адекватный?
Android: Mobile Safari 92 3062835
>>062763
Av1 конечно же
Android: Mobile Safari 93 3062844
>>060812
Бамп, никому не нужна божественная вебмка?
Windows 10: Chromium based 94 3063322
Может ли webm for retards кодировать именно в мп4? Интерфейс и функционал устраивает полностью за исключением формата.
По дефолту там такая командная строка
-an -c:v libvpx -pix_fmt yuv420p -threads 4 -slices 2 -metadata title="Урок1" -minrate:v 900k -b:v 900k -maxrate:v 900k -bufsize 540k -rc_init_occupancy 3600k -qcomp 0
Windows 10: Firefox based 95 3063342
libaom-av1 вообще используется? Не умеет использовать 32 потока.
Попробовал SVT-AV1, тот и нагружает по максимуму, и быстро где-то 0.43x. Но не могу менять битрейт -b:v не воспринимает.
Что скажете за librav1e?
Linux: Firefox based 96 3063541
Решил посмотреть производительность кодеров intel QSV.
Вот эта бумага:
https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/cloud-computing-quicksync-video-ffmpeg-white-paper.pdf
говорит, что на Xeon E3-1285 (haswell) кодер h264_qsv должен дать под 100 кадров/с даже в режиме veryslow.
Я пробовал на Core i5 4460 с кодером h264_vaapi еле удаётся выдавить 25 кадров/с.
Материал везде 1920×1080, yuv444p.
Как-то слабовато со сходимостью.
Android: Mobile Safari 97 3063615
>>063342
Для этого нужен av1an лол
Android: Mobile Safari 98 3063616
>>063541
Под нормальной системой попробуй, а не пердольской
Android: Mobile Safari 99 3063744
>>063616
Ты whitepaper читал вообще? Там как раз под нормальной системой и пробуют. У меня почти такая же. Проблема очевидно не в этом.
Windows 10: Chromium based 100 3063758
>>063744
Пиши багрепорт.
4d9429cf44202bc08a842512c89dc47c.jpg107 Кб, 1024x680
Windows 10: Firefox based 101 3063812
Не знаю где спросить, спрошу здесь.

Имеется много музыки mp3 320, хочу перекодировать всё в opus 128 или 160 ещё не определился, естественно сначала перегоню mp3 в wav, а уже потом в opus. Это совсем плохая идея или норм?
Windows 10: Chromium based 102 3063907
>>063812

> opus 128


Из mp3 320 вполне достаточно.

> естественно сначала перегоню mp3 в wav


Зачем?

> Это совсем плохая идея или норм?


Норм, если на смартфоне или плеере не хватает места подо всё. А на пека нет смысла имхо.
Android: Mobile Safari 103 3063911
>>063812
Нет, музыку с потерями никогда нельзя конвертировать ещё раз. Тебе нужен нормальный источник flac. 2021, тебе жалко купить жёсткий диск на 2 Тб за 4000 р?
Linux: Firefox based 104 3064034
>>063911
Хорошая попытка, копираст.
Android: Mobile Safari 105 3064054
>>063758
Не факт, что баг. Вполне может быть, что так и должно быть для VA-API. Годные источники информации по этому вопросу либо сходу не гугляться, либо вовсе не существуют в открытых источниках. В whitepaper используется другой интерфейс для обмена данными с сопроцессором - используется вместо h264_vaapi h264_qsv, подключается через библиотеку libmfx. Судя по описанию, кодер на libmfx совершает существенно меньше транзакций. Плюс, пара постов (похоже, от инженеров intel) на форуме поддержки этого вашего intel вещает о том, что вариант интерфейсной прослойки VA-API менее производительный, чем QSV с libmfx.
По описанию пакета i965-va-driver, он предоставляет возможность использовать кодеры mpeg2, mjpeg, mpeg4asp и h264 через VA-API. При этом есть вариант этого пакета i965-va-driver-shaders с закрытыми прошивками в комплекте, которые позволяют кодировать через VA-API ещë и в h265 (и если я правильно помню, то и в VP9).
По справочным данным ffmpeg wiki и archwiki, haswell должен уметь в кодирование набора, перечисленного для i965-va-driver-shaders, как через VA-API, так и другим (не уточняется интерфейс) способом через QSV.
Если отталкиваться от содержания whitepaper, то они используют собственную сборочку прыщей с графическим стеком из ffmpeg с кодером h264_qsv, QSV-чипа и libmfx где-то между ними. Если посмотреть на описание этой самой libmfx, то там сказано, что haswell не поддерживается, а сопрягать эту ляпоту можно только с intel-media-va-driver-non-free, в котором haswell не поддерживается. Возможно поддержку haswell выкинули при очередном обновлении, а whitepaper отчитывается о работе исторического кода, но это нужно проверять.
Очень жаль, что у меня под рукой оказалось всего два камня, и оба haswell. Нет возможности проверить.
Установка i965-va-driver-shaders кодер h264_vaapi ожидаемо не ускорила. Установленный libmfx1 к драйверу i965 при попытке инициализации h264_qsv подключаться не желает и ожидаемо требует драйвер iHD из intel-media-va-driver-non-free, при инициализации которого возвращается ошибка о неготовности оборудования.
Пока такие дела.
Android: Mobile Safari 105 3064054
>>063758
Не факт, что баг. Вполне может быть, что так и должно быть для VA-API. Годные источники информации по этому вопросу либо сходу не гугляться, либо вовсе не существуют в открытых источниках. В whitepaper используется другой интерфейс для обмена данными с сопроцессором - используется вместо h264_vaapi h264_qsv, подключается через библиотеку libmfx. Судя по описанию, кодер на libmfx совершает существенно меньше транзакций. Плюс, пара постов (похоже, от инженеров intel) на форуме поддержки этого вашего intel вещает о том, что вариант интерфейсной прослойки VA-API менее производительный, чем QSV с libmfx.
По описанию пакета i965-va-driver, он предоставляет возможность использовать кодеры mpeg2, mjpeg, mpeg4asp и h264 через VA-API. При этом есть вариант этого пакета i965-va-driver-shaders с закрытыми прошивками в комплекте, которые позволяют кодировать через VA-API ещë и в h265 (и если я правильно помню, то и в VP9).
По справочным данным ffmpeg wiki и archwiki, haswell должен уметь в кодирование набора, перечисленного для i965-va-driver-shaders, как через VA-API, так и другим (не уточняется интерфейс) способом через QSV.
Если отталкиваться от содержания whitepaper, то они используют собственную сборочку прыщей с графическим стеком из ffmpeg с кодером h264_qsv, QSV-чипа и libmfx где-то между ними. Если посмотреть на описание этой самой libmfx, то там сказано, что haswell не поддерживается, а сопрягать эту ляпоту можно только с intel-media-va-driver-non-free, в котором haswell не поддерживается. Возможно поддержку haswell выкинули при очередном обновлении, а whitepaper отчитывается о работе исторического кода, но это нужно проверять.
Очень жаль, что у меня под рукой оказалось всего два камня, и оба haswell. Нет возможности проверить.
Установка i965-va-driver-shaders кодер h264_vaapi ожидаемо не ускорила. Установленный libmfx1 к драйверу i965 при попытке инициализации h264_qsv подключаться не желает и ожидаемо требует драйвер iHD из intel-media-va-driver-non-free, при инициализации которого возвращается ошибка о неготовности оборудования.
Пока такие дела.
Windows 10: Chromium based 106 3064057
>>064054
Для начала бы понять, где ты там вообще нашёл хасвелл.
Android: Mobile Safari 107 3064063
>>064034
Любитель пересжатого дерьма, спок
Windows 10: Chromium based 108 3064072
>>063812
Имеет смысл только кодировать из оригинала wav,flac.

>естественно сначала перегоню mp3 в wav, а уже потом в opus


Делать это идиотизм и излишняя трата времени. Зачем не пойму, качество это не улучшит.
Android: Mobile Safari 109 3064083
>>064057
Не вполне ясно, что ты пытаешься высказать.
Windows 10: Firefox based 110 3064164
Почему у меня на пресете medium в libx265 файл получается меньше, чем на veryslow? Что за наебалово, как выбирать эти параметры?
Android: Mobile Safari 111 3064207
>>064164
Так и должно быть, размер немного может отличаться, ничего страшного
Windows 7: Firefox based 112 3064210
ffmpeg может сделать, чтобы типа в одном mp3 файле было что-то вроде дорожек с возможностью выбирать между?
Android: Mobile Safari 113 3064215
>>064210
Можно запихнуть их в mkv
Windows 7: Firefox based 114 3064217
>>064215
Ну или там какой формат файла может, чтобы выбирать между дорожками, но был один файл
Android: Mobile Safari 115 3064220
>>064217
.cue обычно делают
Windows 7: Chromium based 116 3064226
>>064217
мп3 не умеет в такое. Делают cue или любого другого формата плейлист и кладут рядом с мп3 файлом.
Linux: Firefox based 117 3064396
>>064063
Ну ты там как? Уже посчитал недополученную прибыль из-за любителей lossy релизов на торрент трекерах?
Linux: Firefox based 118 3064399
>>064217
.mka, .ogg (opus наверно тоже), и даже главы в .m4a, ну и ещё flac с embeded cue.
Windows 10: Chromium based 119 3064829
А есть ли итт (((счастливые))) обладатели nvidia 3000 ampere? Отпишитесь, каково это вообще аппаратно vp9 энкодить, как качество и скорость по сравнению с программным кодированием?
Android: Mobile Safari 120 3065484
>>064829
Есть только Паскаль GP107, который умеет только h.264 или h.265, да последний без b-кадров.
Windows 10: Chromium based 121 3065855
>>064829
С каких пор у нвидии вообще есть vp9 encode. Там всегда только h264 и h265. Он вообще у интуля есть только.
Windows 10: Chromium based 122 3065897
>>065855

> Он вообще у интуля есть только.


Поподробнее?
Windows 10: Chromium based 123 3065911
>>065897
Intel QSV, SVT
Android: Mobile Safari 124 3065925
>>065911
SVT тут причём, это программный кодировщик, работает везде
>>065897
Если у тебя есть свежий процессор со встройкой, ты можешь делать vp9 видео очень быстро, с хуевым качеством. Как ютуб впринципе https://en.m.wikipedia.org/wiki/Intel_Quick_Sync_Video
1634614042434.jpg6 Кб, 247x204
Windows 10: Palemoon 125 3065926
>>065925

> делать vp9


> с хуевым качеством


А он способен выдавать другое качество?
Android: Mobile Safari 126 3065938
>>065926
Скажем так, он не предназначен для иного.
Android: Mobile Safari 127 3066175
>>065926
>>065938
Два долбоёба
Linux: Firefox based 128 3066188
>>066175
С чем ты не слогласен? Попробуй дать более развёрнутый ответ!
Linux: Palemoon 129 3066382
Пытаюсь нарезать вебмку из HEVC HDR фильма:
ffmpeg -i input.HDR.HEVC.mkv -ss 1:27:40.875 -to 1:28:19.333 -map 0:0 -map 0:3 -c:v libx264 -preset veryslow -crf 18 -c:a libmp3lame -q:a 5 output.mp4
ffmpeg зависает на стадии декодирования и пишет сообщения типа:
[hevc @ 0x56210338ddc0] Mastering Display Metadata:
[hevc @ 0x56210338ddc0] r(0.6800,0.3200) g(0.2650,0.6900) b(0.1500 0.0600) wp(0.3127, 0.3290)
[hevc @ 0x56210338ddc0] min_luminance=0.005000, max_luminance=4000.000000
[hevc @ 0x56210338ddc0] Content Light Level Metadata:
[hevc @ 0x56210338ddc0] MaxCLL=738, MaxFALL=157
[hevc @ 0x56210338ddc0] Output frame with POC 12.
[hevc @ 0x562103212c40] Decoding SEI
[hevc @ 0x562103212c40] Decoded frame with POC 6.
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
[hevc @ 0x562103212c40] nal_unit_type: 35(AUD), nuh_layer_id: 0, temporal_id: 0
[hevc @ 0x562103212c40] nal_unit_type: 34(PPS), nuh_layer_id: 0, temporal_id: 0
[hevc @ 0x562103212c40] nal_unit_type: 39(SEI_PREFIX), nuh_layer_id: 0, temporal_id: 0

Я не пойму в чем дело, он закончит это когда-нибудь? Или ему нужны дополнительные настройки.
Linux: Palemoon 130 3066388
>>066382
Закончил. Полчаса отжирает только на подготовку! Какого хуя!? Можно с этим что-то сделать? Есть гайды по перекодированию HDR?
Windows 10: Palemoon 131 3066392
>>066388

> Закончил. Полчаса отжирает только на подготовку! Какого хуя!? Можно с этим что-то сделать?


Можно, прочитать как пользоваться --ss в ffmpeg
Linux: Palemoon 132 3066396
>>066392
Спасибо. Не знал, что есть разница, где ставить -ss.
Linux: Palemoon 133 3066402
>>066396
Охуенно! Фильтр субтитров, оказывается, не работает с быстрым -ss.
Windows 10: Palemoon 134 3066411
>>066402
Укажи сдвиг в фильтре или воспользуйся внешним контейнером типа какого-нибудь synta
1634732251772.png875 Кб, 1131x1600
Windows 10: Palemoon 135 3066412
>>066402
Это же все в детских гадах есть https://hive.blasux.ru/webm/s как ты дожил до своих лет ничего не читая? Штанишки то хоть сам с утра надеваешь?
1564380864173.png232 Кб, 460x490
Linux: Palemoon 136 3066421
>>066412

>Штанишки то хоть сам с утра надеваешь?


Я их не надеваю.
Windows 10: Chromium based 137 3066448
>>066382

> вебмку


Значение знаешь?
Linux: Firefox based 138 3066691
>>066382
Внимание, вопрос:

Будут ли хоть какие-то улучшения в цветопередаче на SDR мониторе, если вместо апконверта 8 бит SDR в 10 бит SDR взять 10 бит HDR источник, и перекодировать его в 10 бит SDR? И если да, то насколько они значимые?
Android: Mobile Safari 139 3066783
>>066691

>взять 10 бит HDR источник


Где взять?
08.png76 Кб, 490x317
Windows 7: Chromium based 140 3066946
>>066382

>вебмку


>libx264


>output.mp4

изображение.png11 Кб, 917x33
Linux: Firefox based 141 3067012
>>066783
Например
Android: Mobile Safari 142 3067041
>>066691
Интересный вопрос, можешь сделать эксперимент? Мне кажется не будет разницы
Windows 10: Chromium based 143 3067207
Что значат значения, например, 4, 0, -4 в графе "скорость кодирования"? То есть как скорость может быть нулевой и отрицательной? Какое значение ставить, если качество приоритетнее времени?
Windows 10: Chromium based 144 3067857
Возможно ли 2-проходное кодирование с гпу-ускорением?
Windows 10: Firefox based 145 3067866
Windows 10: Chromium based 146 3067877
>>067866
Как?
Android: Mobile Safari 147 3067886
>>067857
nvenc не может
http://forum.doom9.org/showthread.php?t=175091

intel qsv тоже не может
https://community.intel.com/t5/Media-Intel-oneAPI-Video/2-Pass-Encoding/td-p/995261

и amd vce не может
https://forum.videohelp.com/threads/364197-Two-pass-encoding-How-hard-is-it

Расслабься! Это никому не нужно. Эти аппаратные кодеры нужны не для подготовки качественного материала, а для быстроляпа без большой загрузки ЦП.
Windows 10: Chromium based 148 3067890
>>067886
Спасибо :3
Windows 10: Firefox based 149 3068109
>>067886
Что тогда делает параметр 2pass у h264_nvenc и hevc_nvenc?
Windows 10: Firefox based 150 3068142
Где-то можно рассчитать примерную скорость кодирования в зависимости от ЦП? Думаю сделать из старого пека че-то типа сервера, который будет работать 24/7 и параллельно кодировать мои бдремуксы в AV1 (ну или не в AV1)
Windows 10: Palemoon 151 3068162
>>068142

> Думаю сделать из старого пека че-то типа сервера, который будет работать 24/7 и параллельно кодировать мои бдремуксы


И зачем тебе в таком случаем примерно рассчитывать время? Поставил и пусть кодируется месяцами.
Windows 10: Firefox based 152 3068165
>>068162

>Поставил и пусть кодируется месяцами.


Затраты на электроэнергию же. Там нихуя не энергоэффективный проц
Windows 10: Palemoon 153 3068166
>>068165

> Там нихуя не энергоэффективный проц


Зачем тебе в сервере не энергоэффективный проц?
Windows 10: Firefox based 154 3068167
>>068166
Для НАСа похуй, он все равно будет 99% времени в простое, а в простое он потребляет раз в 50 меньше, чем во время пиковой нагрузки
Android: Mobile Safari 155 3068525
>>068109
По первой ссылке объяснено, что это двухпроходный анализ кадра, а не двухпроходный режим работы всего контроллера ширины потока. Лучнее, что есть в nvenc - это режим без потерь. Конкретно мне трудно представить случаи применения, отличные от:
- говновидео для говностримов,
- быстрый захват без потерь для последующего монтажа.
Решения от Штеуд и Амуде годятся только под первый вариант. Может ли это измениться? Да, может, но пруфов я пока не видел.
Android: Mobile Safari 156 3068526
>>068167
Но ты же целевое назначение изменить хочешь. Теперь у тебя не NAS, а числодробилка. Теперь нужна энергоэффективность.

>>068142

>рассчитать примерную скорость кодирования в зависимости от ЦП?


Можно прикинуть экспериментально. Можно взять какой-нибудь средний контент, и закодировать, оценив скорость в кадрах/с. 4K-исходник «Tears of Steel» подойдëт, можешь качать png-шки.
Windows 10: Chromium based 157 3068736
>>056070 (OP)
Как там поживает аппаратное ускорение кодирования VP9 на винде? Если никак, то я лучше буду кодировать в Ав1, ибо интелловский кодер работает быстрее libvpx-vp9
kindzadza20mb.webm19,8 Мб, webm,
320x180, 127:23
Android: Mobile Safari 158 3068970
Аноны, я нашёл самую длинную шебм!
Windows 10: Firefox based 159 3071119
>>056070 (OP)
Подскажите видеофильтр ffmpeg, чтоб от краёв к центру экрана шёл чёрный полупрозрачный тон, чем ближе к центру тем более он прозрачный, пока совсем не исчезнет.
Ещё хотелось по такому же принципу (от краёв к центру) сделать увеличение насыщенности цветов.
Windows 10: Firefox based 160 3071167
>>068970
Зелёный слоник идет 2 часа 20 минут. Шебэмка с полным фильмом раньше здесь мелькала.
Windows 10: Firefox based 161 3071172
>>068970
Как сделать тоже, чтобы длинное видео занимало мало места? Как закодировать? Есть инструкция?
Android: Mobile Safari 162 3071275
>>071119
Делается не так. Создаëтся в любом удобном графическом редакторе соответствующий градиент от чëрного к белому в центре. Экспортируется в тонах серого одна картинка в размер кадра. В фильтрах наложения используется как маска. Делаешь т-фильтр, один из его выходов обесцвечиваешь, поверх последнего накладываешь второй выход т-фильтра с твоей картинкой в качестве маски. Могу попробовать через фильтры ffmpeg командную строчку собрать, если хочешь, но лучше бы в каком-нибудь avisynth/vapoursynth это делать.
Windows 10: Firefox based 163 3071293
>>071275

> Экспортируется в тонах серого одна картинка в размер кадра.


Я хочу использовать эту команду в mpv. У разных видео разное разрешение, нормально получится использовать только один файл маски.
Android: Mobile Safari 164 3071299
>>071293

>использовать эту команду в mpv.


Для mpv шейдер писать надо. Затея у тебя, мягко говоря, странная.

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


Можно масштабировать его фильтром.
Windows 10: Firefox based 165 3071308
>>071299
mpv поддерживает фильтры ffmpeg через vf=
Android: Mobile Safari 166 3071314
>>071308
И -filter_complex поддерживает?
Windows 10: Firefox based 167 3071316
Windows 10: Chromium based 168 3072019
Почему при склеивании без перекодирования размер выходит меньше, чем суммарный у склеенных частей?
Windows 10: Chromium based 169 3072068
>>072019
Хидеры.
Windows 10: Chromium based 170 3072089
>>072068
Что это?
Windows 10: Chromium based 171 3072097
>>072089
Заголовки файлов. Описание содержимого, структуры, вот это всё. Плюс, если мы говорим о сжатии, то это словари, которые должны объединяться, и повторяющиеся фрагменты - удаляться.
Windows 10: Chromium based 172 3072320
>>072097
Хорошо, я тоже подумал про особенности контейнера, но смутило то, что размер стал заметно меньше, процентов на 10, а не на байты-килобайты: 0,4гб + 9,7гб → 9,2 гб.
Windows 7: Firefox based 173 3073718
под линуксом есть программа подобная по функционалу sony dvd architect? чтобы скормить ей m2v, звуковые дорожки и субтитры а на выходе получить готовый для записи на диск фильм?
Windows 10: Chromium based 174 3073837
Почему кодировщик hevc_nvenc ругается на формат пикселя yuvj444p ?

>deprecated pixel format used, make sure you did set range correctly

Android: Mobile Safari 175 3074439
>>073718
dvdauthor
Linux: Firefox based 176 3075513
>>3075434 →

> на сайте вот что про mp4 пишет


Пишут, что MP4 и матьрёшка поддерживаются.
Значит, у нас два варианта развития событий:
1. Мы удалим packed bitstream из потока, сформированного кодером DivX, приведём поток к удобоваримому виду обычного MPEG4 ASP, который можно смело положить в матрёшку или MP4. Телевизор твой должен такое скушать.
2. Если не получится быстренько переделать по первому варианту, тогда перекодируем в h.264.

> Поэтому, буду признателен, если напишешь как, и я сам постараюсь там подшаманить.


Для этого мне нужен твой образец. Возьми любую из серий на твой выбор и ffmpeg.
Если у тебя Windows на x64, то FFmpeg возьми отсюда:
- windows, x64, без libxcb, vaapi, xlib, libdrm, libfdk-aac и frei0r — https://github.com/BtbN/FFmpeg-Builds/releases (бери тот файл, имя которого заканчивается на «-win64-gpl-4.4.zip»);
- windows, x64, без iconv, с libfdk-aac, frei0r, libgsm, libopenh264, libspeex, libsvthevc, libilbc, libvo-amrwbenc, libxavs, gnutls, libaribb24, libbs2b, libcaca, libflite, liblensfun, libmodplug, libmysofa, libsnappy и libtesseract в комплекте, с nvenc, nvdec вместо ffnvcodec — https://github.com/AnimMouse/ffmpeg-autobuild/releases (бери тот файл, имя которого заканчивается на «win64-nonfree.7z»).

Дальше нужно добавить путь к ffmpeg.exe в реестр, чтобы вызывыть короткой командой. Методичка здесь https://docs.microsoft.com/en-us/windows/win32/shell/app-registration
Можно без методички открыть ветку реестра «HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths». Там по аналогии можно догадаться, как сделать нужно.

Делаешь следующее в консолечке, которая у тебя есть:
ffmpeg -hide_banner -t 30 -i "c:\anime\rare things\oldfag tears episode 01.avi" -c copy output.avi
где «c:\anime\rare things\oldfag tears episode 01.avi» — полный путь к файлу с серией, «output.avi» — выходной файл, в котором ты для меня сделаешь 30-секундный кусочек твоего аниме.

Наш итоговый результат по сценарию варианта 1 должен изготавливаться примерно так:
ffmpeg -hide_banner -i "c:\anime\rare things\oldfag tears episode 01.avi" -c copy -bsf:v mpeg4_unpack_bframes episode_01.mp4
Linux: Firefox based 176 3075513
>>3075434 →

> на сайте вот что про mp4 пишет


Пишут, что MP4 и матьрёшка поддерживаются.
Значит, у нас два варианта развития событий:
1. Мы удалим packed bitstream из потока, сформированного кодером DivX, приведём поток к удобоваримому виду обычного MPEG4 ASP, который можно смело положить в матрёшку или MP4. Телевизор твой должен такое скушать.
2. Если не получится быстренько переделать по первому варианту, тогда перекодируем в h.264.

> Поэтому, буду признателен, если напишешь как, и я сам постараюсь там подшаманить.


Для этого мне нужен твой образец. Возьми любую из серий на твой выбор и ffmpeg.
Если у тебя Windows на x64, то FFmpeg возьми отсюда:
- windows, x64, без libxcb, vaapi, xlib, libdrm, libfdk-aac и frei0r — https://github.com/BtbN/FFmpeg-Builds/releases (бери тот файл, имя которого заканчивается на «-win64-gpl-4.4.zip»);
- windows, x64, без iconv, с libfdk-aac, frei0r, libgsm, libopenh264, libspeex, libsvthevc, libilbc, libvo-amrwbenc, libxavs, gnutls, libaribb24, libbs2b, libcaca, libflite, liblensfun, libmodplug, libmysofa, libsnappy и libtesseract в комплекте, с nvenc, nvdec вместо ffnvcodec — https://github.com/AnimMouse/ffmpeg-autobuild/releases (бери тот файл, имя которого заканчивается на «win64-nonfree.7z»).

Дальше нужно добавить путь к ffmpeg.exe в реестр, чтобы вызывыть короткой командой. Методичка здесь https://docs.microsoft.com/en-us/windows/win32/shell/app-registration
Можно без методички открыть ветку реестра «HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths». Там по аналогии можно догадаться, как сделать нужно.

Делаешь следующее в консолечке, которая у тебя есть:
ffmpeg -hide_banner -t 30 -i "c:\anime\rare things\oldfag tears episode 01.avi" -c copy output.avi
где «c:\anime\rare things\oldfag tears episode 01.avi» — полный путь к файлу с серией, «output.avi» — выходной файл, в котором ты для меня сделаешь 30-секундный кусочек твоего аниме.

Наш итоговый результат по сценарию варианта 1 должен изготавливаться примерно так:
ffmpeg -hide_banner -i "c:\anime\rare things\oldfag tears episode 01.avi" -c copy -bsf:v mpeg4_unpack_bframes episode_01.mp4
Windows 10: Chromium based 177 3076209
При -c copy первая секунда видеодорожки сплошной фриз, причём на неё даже перемотать нельзя, почему так и что делать?
Android: Firefox based 178 3076214
>>076209
Если что-то режешь, поставь -ss перед -i.
Windows 10: Chromium based 179 3076222
>>076214
Да, я так и сделал, чтобы лишних полтора часа не обрабатывать, но ведь дело не в этом.
>>076209
Сам вспомнил, что в предыдущих тредах уже поднималась это тема, дело в ключевых кадрах. Поставил -ss на секунду раньше, и секундный фриз пропал. Но всё равно расскажите, как резать в точное время без этих фризов.
Windows 7: Firefox based 180 3076252
Компиляция в 4 часа кодировать в av1 несколько дней. Само видео тормозит при быстрой перемотке. Ролик весит в 2 раза меньше исходника в h.264
Linux: Firefox based 181 3076272
>>076222

>как резать в точное время без этих фризов.


С перекодированием.
Тут есть кроме штуки с ключевыми кадрами ещё штука с прочими всякими потоками. Например, со звуком, продолжительность кадра у которого не просто не равна продолжительности кадра видео, а даже не кратна ей.

Если есть желание свободно монтировать, то добро пожаловать в перекодирование.
Windows 10: Chromium based 182 3076550
периодически пользуюсь командой "concat:1.ts|2.ts|3.ts|4.ts|5.ts"
количество файлов всегда варьируется и мне приходится вручную перепечатывать. это можно как-то автоматизировать, чтобы если например в папке n файлов начиная с 1 и до n ффмпег сам это определял
Windows 10: Chromium based 183 3076673
>>076550
Тут только скрипт писать.
1636840667198.jpg118 Кб, 750x936
Windows 10: Firefox based 184 3077013
Котаны, котелок уже не варит.
Есть файл.мп4 без звуковой дорожки. К нему хочу пришить звуковую дорожку flac.
Но ffmpeg все ругается.
Подскажите команду!
Пикча для привлечения внимания.
Windows 10: Firefox based 185 3077021
>>077013
Блин, скачал другой ффмпег, там получилось. Но при этом во время тишины в видео теперь какой-то электронный шум. В исходном флаке нет (или практически нет), а в видео почему-то на такой же громкости есть шум.
Использовал такую команду:
ffmpeg -i входной.mp4 -i входной.flac -codec copy -strict -2 выходной.mp4
Windows 7: Firefox based 186 3077022
>>077013
ffmpeg -i vid.mp4 -i vid.flac -c:v copy -c:a copy new.mp4 ?
69409.jpg163 Кб, 1280x856
Windows 10: Firefox based 187 3077023
>>077013

>Пикча для привлечения внимания


Очень милая пикча, где же ты её нашла поничка?
Windows 10: Firefox based 188 3077040
>>077022
Не. Похоже, это проблема с potplayer, в остальных аудио так не шакалит. Не замечал раньше за ним такого поведения. Наверно, попробую в самом аудио удалить эти тихие места или забить их нейтральным шумом.
Windows XP: Firefox based 189 3077078
>>077013
Если я правильно помню, FLAC не входит в официально поддерживаемые контейнером MP4 форматы содержимого. Пихнуть его туда можно, но за результат никто не отвечает. Тебе нужно просто сделать -acodec copy -vcodec copy в файл MKV.
Windows 8: Firefox based 190 3077084
>>077040
Если у тебя аудиодорожка флак и режим обработки дорожки copy, то с чего бы там ПОЯВИТЬСЯ некоему лишнему шуму, аудио ведь НЕ перекодируется?

Можешь залить куда-нибудь исходное аудио и получившийся видеофайл, если не конфиденциально? Я понимаю кой-чего в кодировании аудио (в кодировании видео не особо, кек, просто увидел твой коммент, скролля /s/), может быть, подскажу по поводу этого "электронного шума", если пришлешь.
Windows 8: Firefox based 191 3077085
>>077078

> FLAC не входит в официально поддерживаемые контейнером MP4 форматы содержимого.


А какие лосслесс-кодеки аудио поддерживаются в мп4?
Windows XP: Firefox based 192 3077095
>>077085
https://en.wikipedia.org/wiki/MPEG-4_Part_14#Data_streams
Уже поддерживается, в общем.

Ты не на спецификации смотри, а на проигрыватель, в который ты этот файл запихнёшь. Если ему десять лет, то и формат выбирай консервативный. Разницы между AAC с большим битрейтом и FLAC ты не услышишь.
Windows XP: Firefox based 193 3077098
А с шумом самое простое объяснение — что он всегда там был, просто тэг ReplayGain делал максимальную громкость меньше при воспроизведении, а после слияния в видеофайл он перестал работать. Я надеюсь, ты не на колонках Genius шумы во флаке слушаешь, и в видеоплеере автоматическая коррекция уровня аудио тоже не включена.
1636893115109.png75 Кб, 1586x677
Windows 10: Firefox based 194 3077260
>>077078
>>077084
>>077098
>>077095
Пардон, мужики. Дело оказалось в том, что в видеоплеере был включен нормализатор. Я не вырезал оставшийся после шумодава шум в местах тишины, лишь уменьшил громкость на этих местах с помощью огибающих. Вот на этот остаточный шум нормализатор и аггрился.
Windows 10: Chromium based 195 3077358
>>056070 (OP)
Наверно банальный вопрос - нужно три видосика mp4 объединить, обрезать по краям и сохранить желательно без перекодировки. Желательно с минимумом усилий. Виртуалдаб подошёл бы, но он не открывает мои mp4, хотя кодеки есть.
Windows 8: Firefox based 196 3077490
>>077358
Avidemux очень похож на VirtualDub, но умеет в mp4.
Windows 8: Firefox based 197 3077495
>>077095

>Разницы между AAC с большим битрейтом и FLAC ты не услышишь.


Всё так, я не аудиофил, заказывающий золотые провода.

Но с некоторых пор ютуб стал хорошо кодировать аудио, если в оригинальном видеофайле аудиодорожка хорошего качества. Ютуб теперь умеет добивать до ~20 кГц. Предположу, что они ввели это, когда запустили Youtube Music.

И вот я бы хотел свои собственные музыкальные заливки посылать ютубу в максимально возможном качестве. (не автоматические видео Artist Name - Topic, которые подсасываются из дистрибьюторов, а именно свои собственные видео на своем канале, в которых есть музыка). Хотя бы для того, чтобы избежать ещё одного прохода перекодирования в цепочке (исходник -> aac 256 в видеоредакторе -> aac на стороне ютуба). Мне не влом залить на ютуб видеофайл с лосслесс-дорожкой.
Android: Mobile Safari 198 3077498
>>077078
>>077085
Уже давно входит, заливай mp4 с flac
Windows 10: Chromium based 199 3077502
>>077490
Спасибо, анон, ровно то, что было нужно.
Windows 10: Firefox based 200 3077519
>>077495
Вот эта команда нормально работает у меня с последним скачанным ффмпегом.
ffmpeg -i Video.mp4 -i Audio.flac -c:v copy -c:a copy -strict -2 Output.mp4
Только -strict -2 нужно ставить, иначе ффмпег ругается.
Как ютуб там перекодирует, еще не знаю, еще не дообработал до конца видео.
Windows 8: Firefox based 201 3077527
>>077519
С .wav (обычная pcm вавка) делать точно так же?
Windows 8: Firefox based 202 3077528
>>077502
Пожалуйста. Учти, что для точного покадрового разрезания в virtualdub надо указывать в качестве точки B не последний кадр, а СЛЕДУЮЩИЙ за ним (первый кадр следующей сцены), а в avidemux - именно последний кадр, который тебе нужен. То есть virtualdub режет (A, B], а avidemux - (A, B).
Windows 8: Firefox based 203 3077538
>>076550

Делай так.

1. Используй имена исходных файлов, которые легко описываются некоей маской. Например, .ts, если в папке больше нет никаких ts-ок. Или _.ts, если все нужные тебе файлы начинаются с символа _. Или еще что-то подобное. И обязательно (!!) именуй их так, чтобы алфавитный их порядок был именно тем порядком, который тебе нужен.

2. Создай в папке с этими видеофайлами файл generatelist.bat со следующим содержимым:

(for i in (.ts) do @echo file 'i') > mylist.txt

(вместо
.ts подставь подходящую тебе маску)

3. Запусти этот батник, он тебе сгенерирует mylist.txt в этой же папке со строчками вида

file 'filename1.mp4'
file 'filename2.mp4'
file 'filename3.mp4'

4. Создай здесь же файл concatenate.bat с таким содержимым:

"C:\путь\к\файлу\ffmpeg.exe" -f concat -safe 0 -i mylist.txt -c copy concatenated.mp4

5. Запусти его, и ffmpeg конкатенирует твои файлы, используя в качестве источников содержимое mylist.txt.

Не выкидывай эти батники, они работают для любого другого набора исходных видеофайлов, если, конечно, их имена тоже описываются маской, которую ты указал в generatelist.bat.
Windows 8: Firefox based 204 3077541
>>077538
Ух бля, ебаное форматирование двача съело знаки процентов и хз что ещё. >>076550, Держи, залил текст моего поста на pastebin без форматирования: https://pastebin.com/emKbgXcX
Windows 10: Firefox based 205 3077549
>>077527
Не знаю. Вроде как, ютуб советует именно флак.
Windows 10: Chromium based 206 3077660
>>077013
Зачем flac пихать в не предназначенный для этого контейнер mp4? Ебнулся, дяд?
Windows 10: Chromium based 207 3077662
>>077538
Спасибо, анон. Схоронил.
мимо
Windows 10: Firefox based 208 3077663
>>077660
Работает же.
Windows 10: Chromium based 209 3077665
>>077663
Работать-то работает, но практического смысла нет. Тем более, дальше прочитал ты все равно на ютуб перезаливаешь, шиза конечно, один хуй на ютубе макс качество opus 160k. Для loseless форматов есть mkv контейнер.
Windows 8: Firefox based 210 3077676
>>077662
Пожалуйста. Только сохрани именно копию с pastebin, а не первое мое сообщение, в нем пропали звездочки и знаки проценты, и без них код скриптов превратился в тыкву.

>>077665
Ты путаешь, на ютуб заливать собирался я, а ты отвечаешь другому анону с другим юзер-агентом. Да, на ютубе максимальное качество - лосси, с этим я не спорил и не собираюсь заливать лосслесс аудио, чтобы получить на самом ютубе лосслесс аудио. Но, во-первых, это минус один проход лосси-кодирования (сначала у тебя в видеоредакторе при экспорте в файл, потом на серверах ютуба в разные форматы аудио, которые отдаются зрителям). Во-вторых, уже сейчас ютуб умеет в аудио довольно хорошего качества, в которое не умел еще 2-3 года назад. Всякие youtube-dl еще не научились выкачивать это и выкачивают fallback аудио предыдущего поколения (и наверняка даже в браузере зависит от клиента), но улучшения есть. Может, в будущем будет еще лучше. Почему бы не загрузить на ютуб лосслесс-исходник, не жалко же.

Это как с битрейтом видеопотока: несмотря на то, что ютуб отдает зрителям очень шакальный битрейт (сколько там, 1 мбпс для 1080p вроде?), лучше все-таки заливать на ютуб видеофайл с битрейтом получше. Два прогона кодирования, где первый - 8 мбпс, а второй - 1, всяко лучше, чем оба по 1.
Windows 10: Firefox based 211 3077678
>>077665
>>077676
Вроде как в рекомендациях ютуба указан флак, типа, после перекодирования будет лучше.
А про битрейт видеопотока есть еще хитрость - заливать чуть больше 1440p (например, 2720х1530), чтобы ютуб обработал профилем 4к. Но я хз, работает ли это еще.
Windows 8: Firefox based 212 3077684
>>077678

>заливать чуть больше 1440p (например, 2720х1530)


Звучит как готовый рецепт получить ебовейшее мыло и/или алиасинг от ресайза туда-сюда на "некрасивый" множитель. Особенно если у тебя исходники (из которых ты монтировал своё видео) 1920x1080, ты это при экспорте в редакторе ресайзнул в свою хуйню 2720x1530, а ютуб потом ресайзнул в 2560x1440.
Windows 10: Firefox based 213 3077686
>>077684
Так тут по ситуации смотреть надо. Может, тебе ютуб на FHD дает такие кодеки и битрейт, что алиасинг с ресайзингом на порядок лучше будут. Там же тоже своя внутренняя кухня, кому какие кодеки и битрейты давать.
Windows 8: Firefox based 214 3077688
>>077678

>типа, после перекодирования будет лучше



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

На правах оффтопа: абсолютно рядовая ситуация: музыкант долбоеб и ничего не понимает в технических аспектах кодирования аудио, кодирует свой трек в мп3, отдает лейблу, лейблу похуй, отдает мастеринг-инженеру, который поливает мп3шку готовыми пресетами улучшайзеров, результат отправляется в цифровые магазины и на стриминги, оттуда пиратится снова в мп3, горе-диджей берет эту спизженную мп3 и играет ее в миксе, по незнанию выставив неправильный режим key lock (или аналогичное), что еще сильнее ее шакалит, сохраняет свой микс как мп3, кидает в видеоредактор, чтобы сделать видео со статичной картинкой и этим аудио, сохраняет видеофайл (снова лосси конверт аудиодорожки), заливает это на ютуб, где на серверах еще один прогон лосси, и на выходе получается просто ПОЛНЕЙШАЯ БЛЯДЬ ПИЗДА. Если что, я полностью согласен, что дроч на лосслесс vs качественное лосси в контексте простого прослушивания трека абсолютно излишен и разницу слышит ничтожный процент населения на хорошем оборудовании. Но когда много шагов, как в этом примере (а это повсеместно), то адский шакалинг слышен даже глухому.

> Вроде как в рекомендациях ютуба указан флак



А можно ссылку именно на это? Вообще я предполагаю, что они написали флак как дефолтный пример известного обывателям кодека, из тех, что лосслесс. У них вся справка ориентирована на не особо технически подкованных пользователей. Что такое wav (или pcm), наверное, знают не так много людей. А разницы между исходником в виде wav и исходником в виде flac не должно быть, они хранят в себе буквально побитово идентичную волну.
Windows 10: Chromium based 215 3077689
>>077678
Покажи мне, где в рекомендованных flac лол, ютуб всегда говорил лейте 1080p 15mb h264 aac mp4, чтобы не кодировать видосики лярд лет. Ему вообще до пизды flac и прочие loseless.

>Но, во-первых, это минус один проход лосси-кодирования (сначала у тебя в видеоредакторе при экспорте в файл, потом на серверах ютуба в разные форматы аудио, которые отдаются зрителям).


А автогенерируемые видео по твоему кодируются из лосси получается.

>Во-вторых, уже сейчас ютуб умеет в аудио довольно хорошего качества, в которое не умел еще 2-3 года назад. Всякие youtube-dl еще не научились выкачивать это и выкачивают fallback аудио предыдущего поколения (и наверняка даже в браузере зависит от клиента), но улучшения есть.


Любой поток из ютуба можно выкачать, если в коде страницы найти прямую ссылку. Покажи мне что там может быть помимо aac 128k и opus 160k. Если бы такое было, в тот же youtube-dlp давно запихнули как нефиг делать. Чет мне кажется ты лапшу вешаешь.

>Почему бы не загрузить на ютуб лосслесс-исходник, не жалко же.


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

>Это как с битрейтом видеопотока: несмотря на то, что ютуб отдает зрителям очень шакальный битрейт (сколько там, 1 мбпс для 1080p вроде?)


Что ты несешь, не пойму? Какой еще 1мбпс. Там ютуб сам определяет битрейт в зависимости от контента, если статичная картинка ясен пень он не нужен большой. В обычных видосах от 7к до 9к, можешь увеличиваться если движений много.

>лучше все-таки заливать на ютуб видеофайл с битрейтом получше


С дуру можно и по 100к битрейта заливать, crf 18 более чем достаточно.

>А про битрейт видеопотока есть еще хитрость - заливать чуть больше 1440p (например, 2720х1530), чтобы ютуб обработал профилем 4к. Но я хз, работает ли это еще.


Работает, но почему-то додики забывают, что если оригинал не 2k, или хотя бы не апскейл по типу 4k instant, по качество выходит дерьмовее, чем нативное 1080п на ютубе. Таким можно лишь посочувствовать, потому что смотреть противно, особенно если мелкие детали есть.
Windows 10: Chromium based 215 3077689
>>077678
Покажи мне, где в рекомендованных flac лол, ютуб всегда говорил лейте 1080p 15mb h264 aac mp4, чтобы не кодировать видосики лярд лет. Ему вообще до пизды flac и прочие loseless.

>Но, во-первых, это минус один проход лосси-кодирования (сначала у тебя в видеоредакторе при экспорте в файл, потом на серверах ютуба в разные форматы аудио, которые отдаются зрителям).


А автогенерируемые видео по твоему кодируются из лосси получается.

>Во-вторых, уже сейчас ютуб умеет в аудио довольно хорошего качества, в которое не умел еще 2-3 года назад. Всякие youtube-dl еще не научились выкачивать это и выкачивают fallback аудио предыдущего поколения (и наверняка даже в браузере зависит от клиента), но улучшения есть.


Любой поток из ютуба можно выкачать, если в коде страницы найти прямую ссылку. Покажи мне что там может быть помимо aac 128k и opus 160k. Если бы такое было, в тот же youtube-dlp давно запихнули как нефиг делать. Чет мне кажется ты лапшу вешаешь.

>Почему бы не загрузить на ютуб лосслесс-исходник, не жалко же.


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

>Это как с битрейтом видеопотока: несмотря на то, что ютуб отдает зрителям очень шакальный битрейт (сколько там, 1 мбпс для 1080p вроде?)


Что ты несешь, не пойму? Какой еще 1мбпс. Там ютуб сам определяет битрейт в зависимости от контента, если статичная картинка ясен пень он не нужен большой. В обычных видосах от 7к до 9к, можешь увеличиваться если движений много.

>лучше все-таки заливать на ютуб видеофайл с битрейтом получше


С дуру можно и по 100к битрейта заливать, crf 18 более чем достаточно.

>А про битрейт видеопотока есть еще хитрость - заливать чуть больше 1440p (например, 2720х1530), чтобы ютуб обработал профилем 4к. Но я хз, работает ли это еще.


Работает, но почему-то додики забывают, что если оригинал не 2k, или хотя бы не апскейл по типу 4k instant, по качество выходит дерьмовее, чем нативное 1080п на ютубе. Таким можно лишь посочувствовать, потому что смотреть противно, особенно если мелкие детали есть.
chromehqD9fXXLwE.png48 Кб, 835x364
Windows 10: Chromium based 216 3077691
>>077689
Нашел, новую статью добавили. Только не понял, что значит

>Обратите внимание, что звуковая дорожка воспроизводится на YouTube только в том случае, если вы добавили ее в программу Звукозамены.

Windows 10: Firefox based 217 3077692
>>077688
>>077689
>>077691
Тэк, похоже, я вычитал это в требованиях отпечатков музыки для правообладателей. Не знаю, насколько это актуально для простых пользователей.
https://support.google.com/youtube/answer/6039860?hl=ru
Windows 10: Chromium based 218 3077693
>>077692
Я знаю, не успел дописать.
изображение.png1,1 Мб, 1374x541
Windows 8: Firefox based 219 3077695
>>077689
Ты явно ответил двум людям сразу, но реплайнул только одному. Отвечу на те слова, которые мне:

> А автогенерируемые видео по твоему кодируются из лосси получается.



Автогенерируемые видео (если ты про заливки вида Artist - Topic) кодируются из лосслесс, который присылается дистрибьютором. В большинстве типичных случаев это один и тот же источник для спотифая, для ютуба, для эппла и пр., это агрегаторы типа Labelworx или Distrokid или собственные сервера больших мейджор-лейблов. Они рассылают лосслесс. Ютуб автоматически генерирует видео в виде статичной картинки (квадратной обложки) и аудиодорожки, сделанной из этого исходника.

> Любой поток из ютуба можно выкачать, если в коде страницы найти прямую ссылку. Покажи мне что там может быть помимо aac 128k и opus 160k. Если бы такое было, в тот же youtube-dlp давно запихнули как нефиг делать. Чет мне кажется ты лапшу вешаешь.



Не вешаю.

https://www.youtube.com/watch?v=5k2cDFi3P1U - выглядит как приложенный скриншот. Это не совсем аац 256 и не мп3 320, но гораздо лучше, чем то, что выкачивается ютубдл'ом (и прочими savefrom.net и подобными вариантами). Ютубдл у меня выкачивает в качестве, которое было и раньше. Видимо, это fallback для некоторых устаревающих клиентов.

> Любой поток из ютуба можно выкачать, если в коде страницы найти прямую ссылку



Да, но эти куски потока (с хорошим аудио) с каким-то анальным дрм. Их можно скачать, но они не открываются ни браузером, ни сторонним плеером. А вот если открыть какое-нибудь древнее видео, доступное только в 480p с соответствующей дорожкой, то там аудио "предыдущего" уровня качества в кусках потока как раз открывается чем угодно.

Кстати, если какое-то видео является ЗАПИСЬЮ СТРИМА (т.е. стрима на сам ютуб в прошлом), то у него аудио отдается тоже только "предыдущего" качества.

> Авторские права дадут на твой видос, даже если он вообще скрыт ото всех.



Чего. Если моя аудиодорожка в лосслесс, то детект музыки сработает, а если в аац 384 кбпс, то нет? :)

> Что ты несешь, не пойму?



У ютуба очень плохо с битрейтом. Было всегда и есть до сих пор. Даже всякие трейлеры фильмов, где, казалось бы, большие студии могли бы договориться с гуглом по этому поводу. Мыло пиздец.

Последний вопрос ты задал не мне.
изображение.png1,1 Мб, 1374x541
Windows 8: Firefox based 219 3077695
>>077689
Ты явно ответил двум людям сразу, но реплайнул только одному. Отвечу на те слова, которые мне:

> А автогенерируемые видео по твоему кодируются из лосси получается.



Автогенерируемые видео (если ты про заливки вида Artist - Topic) кодируются из лосслесс, который присылается дистрибьютором. В большинстве типичных случаев это один и тот же источник для спотифая, для ютуба, для эппла и пр., это агрегаторы типа Labelworx или Distrokid или собственные сервера больших мейджор-лейблов. Они рассылают лосслесс. Ютуб автоматически генерирует видео в виде статичной картинки (квадратной обложки) и аудиодорожки, сделанной из этого исходника.

> Любой поток из ютуба можно выкачать, если в коде страницы найти прямую ссылку. Покажи мне что там может быть помимо aac 128k и opus 160k. Если бы такое было, в тот же youtube-dlp давно запихнули как нефиг делать. Чет мне кажется ты лапшу вешаешь.



Не вешаю.

https://www.youtube.com/watch?v=5k2cDFi3P1U - выглядит как приложенный скриншот. Это не совсем аац 256 и не мп3 320, но гораздо лучше, чем то, что выкачивается ютубдл'ом (и прочими savefrom.net и подобными вариантами). Ютубдл у меня выкачивает в качестве, которое было и раньше. Видимо, это fallback для некоторых устаревающих клиентов.

> Любой поток из ютуба можно выкачать, если в коде страницы найти прямую ссылку



Да, но эти куски потока (с хорошим аудио) с каким-то анальным дрм. Их можно скачать, но они не открываются ни браузером, ни сторонним плеером. А вот если открыть какое-нибудь древнее видео, доступное только в 480p с соответствующей дорожкой, то там аудио "предыдущего" уровня качества в кусках потока как раз открывается чем угодно.

Кстати, если какое-то видео является ЗАПИСЬЮ СТРИМА (т.е. стрима на сам ютуб в прошлом), то у него аудио отдается тоже только "предыдущего" качества.

> Авторские права дадут на твой видос, даже если он вообще скрыт ото всех.



Чего. Если моя аудиодорожка в лосслесс, то детект музыки сработает, а если в аац 384 кбпс, то нет? :)

> Что ты несешь, не пойму?



У ютуба очень плохо с битрейтом. Было всегда и есть до сих пор. Даже всякие трейлеры фильмов, где, казалось бы, большие студии могли бы договориться с гуглом по этому поводу. Мыло пиздец.

Последний вопрос ты задал не мне.
Windows 8: Firefox based 220 3077697
>>077692
Ну да, по твоей ссылке рекомендуют flac или pcm (wav, aiff и пр.), что логично, т.к. все они содержат исходную волну без изменений.
1526646162542.png74 Кб, 997x761
Windows 10: Firefox based 221 3077698
>>077695

> Ютубдл у меня выкачивает в качестве, которое было и раньше


Чел, там разное качество, и если ты youtube-dl не скажешь какое качать, он решит за тебя.

> Это не совсем аац 256 и не мп3 320


Это aac 128 и opus 115
Apple Mac: Firefox based 222 3077701
>>077695
Статс фор нердс выведет тебе текущие кодеки. Стримы на ютубе всегда х264+аац.
Windows 10: Chromium based 223 3077714
>>077695

>https://www.youtube.com/watch?v=5k2cDFi3P1U - выглядит как приложенный скриншот. Это не совсем аац 256 и не мп3 320, но гораздо лучше, чем то, что выкачивается ютубдл'ом (и прочими savefrom.net и подобными вариантами). Ютубдл у меня выкачивает в качестве, которое было и раньше. Видимо, это fallback для некоторых устаревающих клиентов.


Что ты черт возьми такое несешь? По волнам понял, что звук лучше? А может просто opus со временем лучше стал в сравнении с старыми версиями, не? Выше скрин с лоступными аудио выше.

> Это не совсем аац 256 и не мп3 320, но гораздо лучше


Opus 160k должен быть по качеству лучше, что тот, что другой. Включаешь статистику для сисадминов на видео, и смотришь какой кодек играет.

>Да, но эти куски потока (с хорошим аудио) с каким-то анальным дрм. Их можно скачать, но они не открываются ни браузером, ни сторонним плеером.


Открываются, если бы там был дрм, то никакой ytdl, ни savefrom не смог бы их подхватить, даже dash куски качаются ytdl. Короче какую-то шизу несешь. Так что показывай, если найдешь.

>Если моя аудиодорожка в лосслесс, то детект музыки сработает, а если в аац 384 кбпс, то нет? :)


Я ничего не говорил про аас, я говорил бессмысленность заливки на ютуб музыки с правами в общем, потому что рано изи поздно ее пидорнуть, а качество с офф. музыкой ютуба по сути нет, если это не говноремиксы залитые хрен знает кем.

>У ютуба очень плохо с битрейтом. Было всегда и есть до сих пор. Даже всякие трейлеры фильмов, где, казалось бы, большие студии могли бы договориться с гуглом по этому поводу. Мыло пиздец.


Всё нормально там с битрейтом, ютуб ставит настройки адекватные. Просто красноглазым дрочерам не нравится, что нельзя запилить их любимый пердеж и пустословие fullhd в 60мб/с.
16339632090260.jpg59 Кб, 712x712
Windows 10: Palemoon 224 3077732
Аудиофилы не люди, гоните их, насмехайтесь над ними. 64кб/с хватит всем!
Windows 10: Firefox based 225 3077734
>>077732
64 kbps это мало...
А вот 128 kbps с opus кодеком мне хватает.
Windows 10: Chromium based 226 3077753
>>077734
opus слушабелен вплоть до 17 кбпс, по моим ощущениям. Именно после 17 вообще плохой становится.
Windows 10: Firefox based 227 3077831
>>077753
Я взял с запасом для йоба-наушников, главное с ними не услышать разницу между lossless и lossy, а то опять придётся флак выкачивать и мои 50гб музыки превратятся в пол терабайта...
Windows 8: Firefox based 228 3077872
>>077714

> Открываются, если бы там был дрм, то никакой ytdl, ни savefrom не смог бы их подхватить, даже dash куски качаются ytdl. Короче какую-то шизу несешь. Так что показывай, если найдешь.


Из-под новейшей лисы (пишу для учёта клиента) открой то же самое видео, что обсуждалось выше, и посмотри в мониторе сети, какие куски тебе прилетают. Они содержат видео и аудио, но не открываются сторонними плеерами. А вот для видео на ютубе, которые являются записью стрима на ютуб, прилетают куски, которые открываются. И звучат похуже даже на слух (а не только на спектр).

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


Если какой-нибудь альбом Тейлор Свифт, то да, если менее известную музыку - по моей практике, всем похер. Максимум будет стоять монетизация в пользу правообладателя, да ради бога.

> Всё нормально там с битрейтом, ютуб ставит настройки адекватные.


Сравни любой кинотрейлер с динамичными сценами на ютубе и на trailers.apple.com (можно брать прямые ссылки на hd-trailers.net). Разница - небо и земля. Просто современный интернет потихоньку приучает людей к тому, что картинка плохого качества - это нормально. Что ютуб, что Нетфликс, что прочие стриминги. Сплошное мыло, темные области полностью заливаются однотонными полосами. У меня не йоба-монитор, но даже на самом обычном это прекрасно видно.
Windows 10: Chromium based 229 3077920
>>077872

>Из-под новейшей лисы (пишу для учёта клиента) открой то же самое видео, что обсуждалось выше, и посмотри в мониторе сети, какие куски тебе прилетают. Они содержат видео и аудио, но не открываются сторонними плеерами. А вот для видео на ютубе, которые являются записью стрима на ютуб, прилетают куски, которые открываются. И звучат похуже даже на слух (а не только на спектр).


Да, конечно. Гугловский ютуб не добавил "качественный звук" в свое детище хром, зато в лисе он появился откуда-то. Ты мне по факту принеси пруфы, а не свои какие-то предположения. Какой мониторинг сети нафиг.

>Просто современный интернет потихоньку приучает людей к тому, что картинка плохого качества - это нормально.


Нет. Просто гугл экономит место на серверах, использую самые оптимальные настройки.
Windows 8: Firefox based 230 3077928
>>077920

> Гугловский ютуб не добавил "качественный звук" в свое детище хром, зато в лисе он появился откуда-то.


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

> Ты мне по факту принеси пруфы, а не свои какие-то предположения. Какой мониторинг сети нафиг.


Я тебе "по факту" принес пруф с конкретным видео. Если тебе угодно общаться таким тоном, то продолжай делать это без меня.
Windows 10: Chromium based 231 3078033
>>077928
Найс жопой повилял и слился, манька шизоидная.
Windows 10: Chromium based 232 3079138
Почему при обрезке видео, оно начинается не с самого начала, а с 2-4 секундны? Конвертировал сначала из mkv в mp4, затем в webm. Если сразу напрямую, то ошибку выдает, что-то про звук 5.1 пишет, думаю что проблемы в нем.
Ну и аудио поток по шагам менялся так: eac3-->vorbis-->aac-->opus
Как правильно конвертировать такие вещи?
Windows XP: Firefox based 233 3079207
>>079138

> что-то про звук 5.1 пишет


Прочитай, что пишет, перемикшируй в стерео.
Apple Mac: Firefox based 234 3079345
>>077920

> гугл экономит место на серверах


Если бы это было так, то все видео кодировались бы только в h264, а аудио только в 140-й AAC.
Да, гугл экономит. Но не харды, а трафик.
Windows 10: Chromium based 235 3079473
>>079345
Двачую. Он вообще-то и оригинал видеофайла на серверах оставляет и производит перекодировку в av1 с набором большого количества просмотров.
Windows 10: Firefox based 236 3079501
Пардон, возможно, не по теме.
Как улучшить команду для yt-dlp, чтобы гарантированно брались лучшие видео и аудио?
А то я смотрю -help и ничего не понимаю.
Команду своровал из гуишной youtube-dlg, но в ней нет настроек, которые я там выбирал в гуи.

yt-dlp.exe --newline -i --all-subs -o "D:\Видео\%(title)s-%(id)s-%(height)sp.%(ext)s" --ignore-config --hls-prefer-native --embed-thumbnail --add-metadata "https://www.youtube.com/watch?v=что-то-там"
Windows 7: Firefox based 237 3079514
>>079501
bestvideo[ext=webm]+bestaudio[ext=webm]/bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo+bestaudio/best
ты можешь дальше сидеть в своих гуях, если переименуешь yt-dlp и в настройках и впишешь свои консольные приоритеты.
Android: Mobile Safari 238 3079556
>>079514
Что за дерьмо? Ютуб шакалит 1080 vp9, h264 выглядит лучше
>>079501
По умолчанию он и так берет лучшее возможное качество, намного лучше чем советуют тут дебилоиды. Главное ffmpeg рядом положить, в PATH
Windows 10: Chromium based 239 3079691
Windows 10: Chromium based 240 3081671
меня жаба душит потратить 200р на новую карту памяти, поэтому я решил вместо этого подрочить фф и набить свой говёный кирпич 2014 года кучей маняме.

1 эпизод 1080р весит около гига, но мне абсолютно похуй на качество, так как смотрю ссаные слайсы. на телефоне 16 гб и 12 из них забито музыкой и порнухой, поэтому есть 4гб на маняме. сконвертил хуйню вот таким вырвиглазным образом:

ffmpeg -i 2.mp4
-vf "scale=-2:480"
-c:v libx265 -crf 30 -preset slow
-bf 10
-c:a libopus -b:a 32k
2opus.mkv

на выходе получилось 47.3мб для 24 минут с битрейтом видео 200-300 и 32 аудио. казалось бы, получится ебучая каша из пикселей и аудио как из жопы осла, но смотрю на телефоне и разница не такая уж и большая. по сравнению с оригиналом кажется, что качество упало на 20-30% максимум (в основном потому, что телефон у меня 720р).

насколько же охуенен хевк+опус, при одинаковом качестве оно по размеру файла меньше раз в 10 по сравнению с стандартным х264+аас. и не настолько уж хевк требователен к железу, раз уж мой кирпич спокойно его тянет, а вот ебучий vp9 тормозит в 720р60, поэтому даже видосы с ютуба не могу в вебмах качать.

можно ли как то эволюционировать моё копрофильство и ужать видос ещё сильней при смотрибельном качестве?
Android: Mobile Safari 241 3081689
>>081671
Зачем так сильно сжимать звук, оно весит мало, а на просмотр влияет.
Можешь сжать в AV1, для твоих случаев он сожмёт намного лучше чем x265, только времени займет намного больше
Не надо понижать разрешение, кодек достаточно умный чтобы сам понизить разрешение в некоторых моментах, когда нужно, при одинаковом размере будет выглядеть лучше. только если хочешь быстрее закодировать.
Ещё нужно кодировать в 10 бит, лучше качество но дольше немного, и может не открыться на телефоне, допиши -pix_fmt yuv420p10le
image.png45 Кб, 1053x66
Windows 10: Chromium based 242 3082091
>>081689

>только времени займет намного больше

Windows 10: Chromium based 243 3082125
>>081671
Может. Играл в "Боль Максима"? https://yewtu.be/QUXUyItb1ys https://yewtu.be/alHZlAYUE7U ← лучший формат видео эвар. И весить будет очень-очень мало. Жми с 0.2 FPS, будешь такой же непревзойдённой элитой.
И нам скинь, что выдет, интересно
2.PNG24 Кб, 734x219
Windows 10: Chromium based 244 3082709
Подскажите, пожалуйста, какой командой можно узнать технические характеристики видео? Скачиваю yt-dlp видео, на выбор два формата в 1080p. Скачал оба, визуально одинаковые, но размер файла отличается. Хочу понять, какой из них лучше по техническим характеристикам.
1638039075544.png181 Кб, 1007x741
Windows 10: Firefox based 245 3082712
>>082709
Поставь программку MediaInfo.
Windows 10: Chromium based 246 3082726
>>082712
Скачал, спасибо.
Подскажи ещё, пожалуйста, сильно ли заметна разница между битрейтом 4400 и 3100? У этих видео только битрейт отличается.
Ну и размер файла, естественно.
Windows XP: Firefox based 247 3082738
>>082709
Первая ссылка на обычный файл на HTTP-сервере с аудио и видео для клиентов, не поддерживающих потоковую загрузку, вторая — на видеопоток в DASH. Сравнить битрейт и прочие базовые характеристики файлов можно просто посмотрев в их описание:

ffmpeg -i 1.mp4 -i 2.mp4

Если ты подозреваешь, что совместимый со старыми устройствами видеопоток закодирован с несколько более консервативными параметрами, чем у второго варианта, то либо смотри готовые утилиты, которые его проанализируют, либо гугли, в каком из миллиона режимов статистики ffprobe будет нужная тебе информация, скажем, о количестве опорных кадров для декодируемого, и grep'ай нужное.
Windows XP: Firefox based 248 3082743
>>082712
То есть опорные кадры и уровень H.264 покажет и MediaInfo, и ffprobe -show_streams, так что это пример негодный, а вот в отсутствие метаданных кодера о каких-то его параметрах догадываться можно только проанализировав всё видео.
Windows 10: Firefox based 249 3082757
>>082709
Поток hls - это же, вроде, эппловский аналог (прародитель?) dash. Это значит, оптимизировано для потоковой передачи. Что с качеством - хз, твои же глаза смотрят.
Android: Mobile Safari 250 3082760
Есть какой то дефолтный вариант, как перекодировать в шебм выкачанный с ютуба видос? Хочу фразы Епифанцева кидать :)
Android: Mobile Safari 251 3082838
>>082738
ебать ты душнила. челик даже не может увидеть разницу в vbr битрейте между двумя файлами, а ты тут ебанутый словарь терминологий высрал, который даже знатокам лень читать.

ответ на его пост проще некуда:
1) ниже битрейт - хуже качество
2) юзай ffprobe
Android: Mobile Safari 252 3082839
>>082760
видосы с ютуба кодировать смысла нет, т.к. они и так сконвертированы очень хорошо мощным железом. максимум сможешь потратить 24 часа и ужать 5% без потери качества

на харкач можешь кидать сразу как есть с ютуба, будь то вебм или мп4 (h264/vp9)
Android: Mobile Safari 253 3082840
>>082726
У Ютуба видео и так пересжаты в хлам. надо смотреть по кодеку, h264 выглядит немного лучше, у него наверное и размер побольше
Android: Mobile Safari 254 3082841
>>082839

> видосы с ютуба кодировать смысла нет, т.к. они и так сконвертированы очень хорошо мощным железом. максимум сможешь потратить 24 часа и ужать 5% без потери качества


у ютуба самые хуевые кодировщики которые стараются сделать как можно быстрее. Их нельзя кодировать потому что они и так сильно сжаты. Процессорный кодировщик может сделать файл в три раза меньше при таком же ужасном качестве, если закодировать исходник
Dash не Качайте, он в некоторых случаях выглядит намного хуже чем остальные. Лучше через браузер посмотреть какой поток отдаёт
Windows 10: Chromium based 255 3082848
>>082738
Друг, спасибо, конечно, но очень сложно.
Я просто скачиваю прон с порнхаба и yt-dlp почему то по умолчанию считать лучшим видео с более низким битрейтом. Вот я и пытался понять почему. Ему приходится всегда приписывать -F 1080p. А хотелось бы, чтобы он по умолчанию выбирал лучшее разрешение и лучший битрейт.
Windows 10: Chromium based 256 3082894
Хочу как можно сильнее пережать видео без заметной потери качества. Уже сэкономил более 50% занятого места вот такими настройками:

>ffmpeg -i "!n!" -c:v h264_nvenc -preset slow -loglevel warning -stats -y -qp 24 -c:a copy -max_muxing_queue_size 1024 "!n2!"



Сравнивал попиксельно под лупой, изменений не заметил. Сжимает порой до 15% от изначального размера. Но все равно попадаются видео, которые с такими настройками пережимаются в 200%. То есть, эти редкие видео закодированы еще лучшим способом.
Знаете способы? Предполагаю, что есть энкодеры в связке с ml. Подскажите.
unnamed.jpg41 Кб, 487x418
Linux: Firefox based 257 3082896
>>082894

>сильнее пережать видео без заметной потери качества


>nvenc

1574790991127.png8 Кб, 225x225
Windows 10: Chromium based 258 3082975
>>082894

> h264_nvenc


> Хочу как можно сильнее пережать видео

Windows 8: Chromium based 259 3083131
Полный ньюфаг начал вкатываться.

1) Есть ли легкий способ разделять и соединять обратно видео / вставлять в него другие части?

3 способами разделил видео на 3 части, а потом склеил их обратно:
ffmpeg -i video.mp4 -ss 00:01:00 -to 00:02:00 -c copy cut.mp4
ffmpeg -ss 00:01:00 -i video.mp4 -to 00:02:00 -c copy -copyts cut.mp4
ffmpeg -ss 00:03:00 -i video.mp4 -t 60 -c copy -avoid_negative_ts 1 cut.mp4

1 и 3 способ оказались почти одинаковыми: в Avidemux продолжительность соответствующих частей одинакова, но после склеивания частей из первого способа общая длительность - 44.389 секунд, а из третьего - 44.551 (у оригинала - 44.393). 1-ые части одинаковы по весу, 2я часть 1 способа меньше на 2кб (всего 4мб), а 3я часть 1 способа меньше на 3кб (всего 12мб), склейка 1сп также меньше на 5кб. 2 способ немного в другом месте делил, длительность склейки - 44.004. Во всех склейках в местах соединения видео где-то на секунду зависает и прыгает вперед, но в Avidemux, если не по-обычному смотреть, а поставить на паузу и нажимать на "следующий кадр", то после "прыжка" кадры тут же сменяют друг друга. По звуку разницы не заметил с оригиналом, но я на слух сравнивал.
Гуглил что делать, но там уже надо разбираться в матчасти, а с concat я просто копирую команду из гайда и все готово.

Алсо, длина видео - 44.393. Я опять отрезал 3 куска: 20-44с, 20-45с, 20-50с и по авидемаксу длительность всех трех оказалась 24.650

2) Правильно ли я понял, что эти команды ведут к одному результату:
ffmpeg -i test.ts test.mp4
ffmpeg -i test.ts -c:v libx264 -c:a aac test.mp4
?

Если конвертировать ts в mp4 через
ffmpeg -i test.ts -map 0 -c copy test.mp4
то весят файлы практически одинаково, на глаз разницы нет, в отличие от первых 2 команд. А если конвертировать через
ffmpeg -i test.ts -c:v libx264 -crf 0 -c:a copy LosslessVideo.mp4
то на глаз разницы тоже не заметно, но весит этот файл в несколько раз больше оригинала. Т.е. за редкими случаями этот лосслес не нужон?

3) Если оригинал скачанного видео в TS, стоит ли его перекодировать в MP4?
Когда-то бегло погуглил разницу и почему-то решил в таких случаях в mp4 перегонять, вроде он более универсален и поддерживаем.
Сейчас подумал что херней занимаюсь, у меня на ts воспроизводится, оригинал всяко лучше обработак, да и всегда в будущем можно перекодировать если нужно. Верно?
Windows 8: Chromium based 259 3083131
Полный ньюфаг начал вкатываться.

1) Есть ли легкий способ разделять и соединять обратно видео / вставлять в него другие части?

3 способами разделил видео на 3 части, а потом склеил их обратно:
ffmpeg -i video.mp4 -ss 00:01:00 -to 00:02:00 -c copy cut.mp4
ffmpeg -ss 00:01:00 -i video.mp4 -to 00:02:00 -c copy -copyts cut.mp4
ffmpeg -ss 00:03:00 -i video.mp4 -t 60 -c copy -avoid_negative_ts 1 cut.mp4

1 и 3 способ оказались почти одинаковыми: в Avidemux продолжительность соответствующих частей одинакова, но после склеивания частей из первого способа общая длительность - 44.389 секунд, а из третьего - 44.551 (у оригинала - 44.393). 1-ые части одинаковы по весу, 2я часть 1 способа меньше на 2кб (всего 4мб), а 3я часть 1 способа меньше на 3кб (всего 12мб), склейка 1сп также меньше на 5кб. 2 способ немного в другом месте делил, длительность склейки - 44.004. Во всех склейках в местах соединения видео где-то на секунду зависает и прыгает вперед, но в Avidemux, если не по-обычному смотреть, а поставить на паузу и нажимать на "следующий кадр", то после "прыжка" кадры тут же сменяют друг друга. По звуку разницы не заметил с оригиналом, но я на слух сравнивал.
Гуглил что делать, но там уже надо разбираться в матчасти, а с concat я просто копирую команду из гайда и все готово.

Алсо, длина видео - 44.393. Я опять отрезал 3 куска: 20-44с, 20-45с, 20-50с и по авидемаксу длительность всех трех оказалась 24.650

2) Правильно ли я понял, что эти команды ведут к одному результату:
ffmpeg -i test.ts test.mp4
ffmpeg -i test.ts -c:v libx264 -c:a aac test.mp4
?

Если конвертировать ts в mp4 через
ffmpeg -i test.ts -map 0 -c copy test.mp4
то весят файлы практически одинаково, на глаз разницы нет, в отличие от первых 2 команд. А если конвертировать через
ffmpeg -i test.ts -c:v libx264 -crf 0 -c:a copy LosslessVideo.mp4
то на глаз разницы тоже не заметно, но весит этот файл в несколько раз больше оригинала. Т.е. за редкими случаями этот лосслес не нужон?

3) Если оригинал скачанного видео в TS, стоит ли его перекодировать в MP4?
Когда-то бегло погуглил разницу и почему-то решил в таких случаях в mp4 перегонять, вроде он более универсален и поддерживаем.
Сейчас подумал что херней занимаюсь, у меня на ts воспроизводится, оригинал всяко лучше обработак, да и всегда в будущем можно перекодировать если нужно. Верно?
3x.gif230 Кб, 112x112
Windows 10: Chromium based 260 3083139
>>083131
didnt read
Android: Mobile Safari 261 3083150
>>083131

>Есть ли легкий способ разделять и соединять обратно видео / вставлять в него другие части?


Нет.

>3 способами разделил


Правильный только первый.

>длительность всех трех оказалась 24.650


А давно avidemux умеет в переменную частоту кадров?

>Правильно ли я понял, что эти команды ведут к одному результату:


Сегодня да. А завтра нет. Подстановки неявных параметров могут быть изменены когда-нибудь.

> -map 0


Ты точно уверен, что руководство прочитал?

>за редкими случаями этот лосслес не нужон?


Именно так. Но редкие исключения бывают.

>он [mp4] более универсален и поддерживаем.


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

>у меня на ts воспроизводится, оригинал всяко лучше обработак


Вот и хорошо.
Android: Mobile Safari 262 3083151
>>083150

>поддержки


поддержке.
Linux: Chromium based 263 3083893
>>081671
Ебани ещё -tune animation и -x265-params aq-mode=3 поможёт в тёмных сценах
Linux: Chromium based 264 3083898
>>077684
>>077678
248 webm 1920x1080 1080p 498k , webm_dash container, vp9@498k, 30fps, video only, 2.09MiB
137 mp4 1920x1080 1080p 1644k , mp4_dash container, avc1.640028@1644k, 30fps, video only, 6.89MiB

Да ютубу вообще похуй -- они на рандом кодируют.
Похоже, что vp9 круче h264 в 3.3 раза, по мнению ютуба.

271 webm 2560x1350 1440p 6663k , webm_dash container, vp9@6663k, 30fps, video only, 114.58MiB
313 webm 3840x2026 2160p 14795k , webm_dash container, vp9@14795k, 30fps, video only, 254.41MiB
571 mp4 5120x2700 2880p 11451k , mp4_dash container, av01.0.16M.08@11451k, 30fps, video only, 196.91MiB

Или вот это: 2880p кодируется только в AV1. h264 заканчивается на 1080p.
Или вот. Внимание на эти огромные скачки в битрейте. Они покроют любой оверхэд от апскейла: а иногда не покрывают
303 webm 1080x1920 1080p60 2506k , webm_dash container, vp9@2506k, 60fps, video only, 34.93MiB
308 webm 1440x2560 1440p60 8603k , webm_dash container, vp9@8603k, 60fps, video only, 119.88MiB

Или вот тут почему ютуб решил урезать видос в 60 кадров?
298 mp4 1280x720 720p60 1001k , mp4_dash container, avc1.4d4020@1001k, 60fps, video only, 81.12MiB
136 mp4 1280x720 720p 2048k , mp4_dash container, avc1.4d401f@2048k, 30fps, video only, 165.96MiB
Windows 10: Chromium based 265 3084223
>>082975
>>082896
че сказаать хотели амудедебилы?
Windows 10: Chromium based 266 3085326
Пытаюсь сделать лупу вижео длинной с аудио трек. Вот такая команда.
ffmpeg -y -stream_loop -1 -i Vid.mov -i "01. Depression Nap.mp3" -shortest -map 0:v:0 -map 1:a:0 -vf "scale=-1:720" -quality good -crf 50 -b:v 0 -c:v libvpx-vp9 -c:a libopus -pass 1 -an -f null NUL && ffmpeg -y -stream_loop -1 -i Vid.mov -i "01. Depression Nap.mp3" -shortest -map 0:v:0 -map 1:a:0 -vf "scale=-1:720" -quality good -crf 50 -b:v 0 -c:v libvpx-vp9 -c:a libopus -b:a 256k -pass 2 out.webm

Если отбросить двойной проход, то всё работает как надо. Если делать именно так, то -shortest игнорируется и первый проход длится вечность.
Windows XP: Firefox based 267 3085330
>>085326
У тебя там -an стоит. Аудио не заканчивается, потому что его нет. Видео крутится до бесконечности, как и заказано.
Windows 10: Chromium based 268 3085336
>>085330
Пиздец. Спасибо, анон. Я эту двупроходную хуйню собирал по кускам и что делает этот флаг даже не задумывался. Пиздец как логично же, что в первый проход аудио игнорируется.

Раз уж тред всё-таки живой то вот какой вопрос. Я в основном монтирую в премьере, а потом уже конвертирую в вебм чтобы залить в дискорд. Какой-то момент из игры например. И вот задумался что наверное надо бы делать вебм на с х264 а чего-то минимально сжатого. Стал использовать pro res 444hq. И конвертация вебм стала дольше, да и вес итогового файла немного увеличился. Значит ли это что можно немного crf убавить для такого же, условно, результата, как был на h264?
Windows XP: Firefox based 269 3085345
>>085336
При сжатии с потерями из картинки выкидываются малозаметные детали, она становится проще для последующих пережатий, если они будут. Изменение скорости кодирования, скорее всего, связано с переводом формата изображения в 4:2:0. Если у тебя битрейт не на уровне блюреев и разрешение не огроменное, то никакой заметной разницы перекодирование из студийных форматов по сравнению с промежуточным H.264 высокого качества не даст. И вообще, смотри глазами, а не гадай по циферкам.
Windows 10: Chromium based 270 3085433
>>085345
Вот короче длительность конвертации в вебм:
мов8bit.mov:0:05:52.664996
мов16bit.mov:0:06:05.906732
мп4.mp4:0:03:18.052003

Качество 16бит и 8бит идентичное, потому скриншот не прикладываю. Весят файлы одинаково. Но хэш суммы разные. Мп4 похуже всё-таки пережил конвертацию. А вот скриншоты оригинальных файлов различаются сильно меньше.
Windows 10: Chromium based 271 3085435
Windows 10: Chromium based 272 3085611
Поставил ​Ut Video - лослесс кодек, который рекомендуют на вики ffmpeg'а. Кодирует в премьере немного дольше, но всё равно не час на минуту видео, как в 2011 году.
Итак. Вебм из такого материала кодируется 3:18, как и из мп4. Второй раз отошёл от компа и было вообще 3:08. Что касается качества, то выглядит немного лучше вебм из мп4 (хотя хуй знает на самом деле) и хуже того, что сделано из pro res.
image.png89 Кб, 1061x853
Windows 10: Chromium based 273 3085616
В завершение скажу, что вебм из pro res почему-то багуются в мобильной версии дискорда на андроиде и отображают чёрный экран. С Ut и H264 таких проблем нет. Ну, вроде моё говноисследование закончено. Остановлюсь на Ut.
Android: Mobile Safari 274 3085664
>>085616
H264 и 265 тоже поддерживают без потерь, ещё и аппаратный кодировщик от нвидии поддерживает, очень быстро получается
Windows 10: Chromium based 275 3085701
>>085664
Попробую, спасибо.
Windows 10: Chromium based 276 3085716
>>085664
Хм, я в премьере не нашёл .
1596246823111.png137 Кб, 1473x672
Windows 10: Chromium based 277 3085738
>>085716
Потому что он напутал всё в кучу. Для кодирования без потерь надо отдельно скачивать форк x264vfw. x264 значит, что никакого аппаратного ускорения там нет, а vfw (video for windows) – что контейнер avi. Показываю на примере вегаса.
Android: Mobile Safari 278 3085754
>>085738
Ок. Ну да ладно, посижу на ut video наверное.
Windows 10: Chromium based 279 3085761
>>085754
x264vfw также входит в комплект K-Lite Codec Pack Full/Mega. Возможно, он у тебя уже установлен.
Windows 10: Chromium based 280 3085771
>>081671
Почему охуевший ютуб с недавного времени все 10+ мин видосы кодирует в dash формате, они там офигели. 6к битрейта h264 для 1080p, на некоторые вообще 3к всего дает. Я думаю чего все видосы мыльные стали последнее время тех кого смотрю, прочекал их все и буквально везде dash.
Windows 10: Chromium based 281 3085773
>>082894
Хочешь макс. качества и самый низкий размер, то кодируй через процессор, вот что хотели сказать.
Насчет редких видео тут сам высчитываешь средний битрейт в зависимости от фреймрейта и разрешения видео, и есть ли быстрые движения в видео.
Windows 10: Chromium based 282 3085777
>>085611
Смысл тебе вообще кодировать что-то в 4:2:2 или 4:4:4, если сам записанный оригинал видео все равно был 4:2:0 8bit? Только время тратишь на перекодировки.
Windows 10: Chromium based 283 3085779
>>085738
Юзать древний x264vfw вместо voukoder, проиграл.
Windows XP: Firefox based 284 3085891
>>085616
Так ты проверь, может там 4:4:4 без изменений, это хрен кто поддержит.
Linux: Firefox based 285 3085904
>>085777
Смысл в том, что у меня цепочка такая:
Футаж из OBS через NVENC -> Монтаж в премьере -> пережатие в вебм.
И вот хочется не терять качество из-за промежуточного звена в виде премьера. Это по большей части перфекционизм и повод попердолиться, нежели реальная какая-то задача практически важная. Что касается 4:2:2, то это не мой выбор, а особенность pro res. Потому я и отказался от него.
Собственно тут же даже нельзя сказать что "из вот такого кодека лучше сжимается вебм". Тут просто ффмпег выбирает разный битрейт при том же crf. Хотя, мне показалось, что таки при меньшем битрейте качество у вебм из ut video лучше чем из h264.
Windows 10: Chromium based 286 3085914
>>085904
Ставь voukoder и жми в webm сразу из премьера.
Linux: Firefox based 287 3085916
>>085914
Блин, спасибо, не знал про такое. На вики через avisynth предлагалют пердолить. Но как же мне себя чувствовать крутым праграмиздам? Я ведь хуитку на питоне родил чтобы массово конвертировать через ffmpeg все видео в папке.
Windows 10: Chromium based 288 3085918
>>085916
Можешь пердолиться, сколько хочешь, но в приоритете избавление от ненужного промежуточного кодирования, пускай даже без потерь. Кстати, у вокодера ффмпег на бэкэнде, если тебе от этого приятнее.
Linux: Firefox based 289 3085920
>>085918

>ффмпег на бэкэнде


Да я даже не сомневался.
Windows 10: Chromium based 290 3086052
>>085904
Именно в 4:2:2 и 4:4:4 кодировать нет смысла вообще, только если ты изначально не запишешь видос в таком качестве, новых цветов там не появится. Это не говоря о том, что поддержки в инете массово этих почти форматов нет, чтобы поделится, либо для стриминга. Будет как дискорд крашится, либо не воспроизводить.
Также имеет смысл, если в фотошопе сделал картинку, гиф, анимацию и хочешь сохранить цвета, по крайней мере я так думаю. В пост скину как влияет пережатие из оригинального 4:4:4 в 4:2:0. vp9 как-то херово перегоняет в 420.
У тебя футаж через nvenc пишется 4:2:0 8 bit сто пудов. ProRes тебе вообще не нужен, h264 с максимальным битрейтом для 1080п 60000 кбпс хватит, чтобы потерь не было, как минимум для глаза, но тут от настроек кодировщика зависит еще конечно.
Я так и делаю.
Пишу видос>Монтаж в Premier/AfterEffects>а тут уже либо через Voukoder, но там меньше тонких настроек и всякие баги, крашы вылезают, либо h264 60mbps, потому что люблю держать ориг, а потом уже его как хочешь и во что хочешь кодируй.
Windows 10: Chromium based 291 3086058
>>086052
Так я говорю, что я специально в 4444 и 422 не кодировал и не собирался.
В voukodere не нравится что нет 2pass, хотя в фича реквестах помечена как Done. Ну и контейнер мп4, ёбнутые что ли? Качество выше значительно, как и размер файла.
Попробовал через avisynth + фреймсервер. Какой-то кринж на костылях, фреймсервер ещё и платный. Так и не звёл. Гайд протух кажется.
Windows 10: Chromium based 292 3086061
>>086058

>В voukodere не нравится что нет 2pass, хотя в фича реквестах помечена как Done


Это да, я так и не понял как его завести.

>Ну и контейнер мп4, ёбнутые что ли? Качество выше значительно, как и размер файла.


Не понял, что ты хотел сказать.

>Попробовал через avisynth + фреймсервер. Какой-то кринж на костылях, фреймсервер ещё и платный. Так и не звёл. Гайд протух кажется.


Да гайд ультрадревний и очень давно протух, тогда даже avisynth plus не было. Видел его обновленную версия, даже она протухла.
Windows 10: Chromium based 293 3086064
>>086061

>Не понял, что ты хотел сказать.


Ну я просто привык что vp9 = webm.

Меня ещё дрочит что кодируешься такой в формат, который типа "lossless", а из него получается мутная залупа, по сравнению в pro res или конвертацией прямо из премьера в вебм. Ну и где ваш ёбаный лосслесс блядь?
Windows 10: Chromium based 294 3086076
>>086064
Если ты про voukoder говоришь, так ты в настройках формата, 3 вкладка вроде. Там mp4, webm, mkv есть точно. Vp9 по идее вообще не поддерживает контейнер mp4. Звук на opus ты тоже не поменял, а у тебя aac там оказца.

>Меня ещё дрочит что кодируешься такой в формат, который типа "lossless"


Если ты про пресет, то они кастомные писанные фиг знает кем. Я ими никогда не пользовался, они трогают тонкие настройки. Можешь сам проверить во вкладке видео. Loseless в принципе не нужен.
Windows 10: Chromium based 295 3086087
>>086076

>Loseless в принципе не нужен.


У меня шиза, мне НАДО. ХОЧУ.

>Звук на opus ты тоже не поменял, а у тебя aac там оказца.


Блин. Поэтому и мп4.
Windows 10: Chromium based 296 3086090
Качество видео один хер такое же, что и в мп4.
Apple Mac: Chromium based 297 3086094
>>086090
Что за ебанутый мод на первую кваку
Android: Mobile Safari 298 3086101
>>086094
Это Cruelty Squad. Шизоидный феномен. Очень круто, но не для всех конечно. Визуал сам понимаешь. Вот хороший обзор.
https://youtu.be/pExqMxNEG1E
Windows 10: Chromium based 299 3086116
Ладно. Вот вам ещё скрины с CBR и хватит на этом.
Windows 10: Chromium based 300 3086129
>>086116
Ты слишком запариваешься имхо. Ставь x264 crf 14-18 и всё, если определенный размер 2pass vbr высчитываешь для каждого видео битрейт.
Если макс качество реально, то записывай в 4:4:4, если для себя, но смысла как говорил немного, в итоге для дискорда все равно сожмешь до шакалов и 4:2:0.
1502063626631.png60 Кб, 789x496
Windows 10: Chromium based 301 3086131
>>086058
Там есть и 2pass, и webm.
Windows 10: Chromium based 302 3086138
>>086131
Вебм уже нашли, не было из-за того что не поменял аудиокодек. А 2pass вот он где, понятно. Только для vbr. Но vbr это говно по сравнению с crf, а для crf 2pass отсутствует.
Windows 10: Chromium based 303 3086139
>>086129

>Ты слишком запариваешься имхо.


Да. Но я пока этой хернёй страдал чуть больше узнал про ffmpeg и сопутствующие вещи, подрочил питон немножко (кек) и вообще. Короче, развлекался как мог.
>>086129

>Ставь x264 crf 14-18 и всё


Не, ты что, х264 это сильно хуже vp9, зато быстрее. vp9 с crf35 оптимально. Если не лезет в 8мб, то заливаю на teknik.io, у меня там премиум (сейчас вроде только подписка, а я урвал вовремя). Там, в отличии от облаков всяких, ссылка на видео файл превращается в нормальный embed.
Windows 10: Chromium based 304 3086159
>>086139

>Да. Но я пока этой хернёй страдал чуть больше узнал про ffmpeg и сопутствующие вещи, подрочил питон немножко (кек) и вообще. Короче, развлекался как мог.


Да я пынемаю, сам в начале такой ерундой занимался, поэтому и говорю. А зачем тебе питон вообще?

>Не, ты что, х264 это сильно хуже vp9, зато быстрее. vp9 с crf35 оптимально.


Вот кстати не всегда, из-за некоторых тонких параметров можно сжать в маленький размер красиво с x264, но vp9 в большинстве случаев лучше конечно, но x265 равно или чуть лучше. Просто последнее время слишком долго кодирует у меня vp9 speed 0 с максимальные параметрами.
image.png7 Кб, 532x64
Windows 7: Chromium based 305 3086332
>>056070 (OP)
Анон, у меня простой вопрос. Я пока что новичек в теме енкодинга и вот провожу некоторые експерименты. Закодировал один и тот же видос с одинаковым присетом и размером выходного файла в mp4 и в mkv. Закинул в прогу, которая рассчитывает качество и она показывает пиздец какую разницу. Помотал немного оба видоса и вроде как на mp4 больше мыла на границах объектов.
Верно ли то что mp4 добавляет мыла? Просто я всегда думал что это такой же контейнер как вебм или матрешка, и разницы между ними нету, кроме поддержки самого контейнера на разных устройствах.
Windows 10: Chromium based 306 3086334
>>086159

>А зачем тебе питон вообще?


Питон круто! Мне нравится.
>>086159

> но x265 равно или чуть лучше.


Должен быть лучше, но сильно медленнее и, что главное, мало где поддерживается.
Windows 10: Chromium based 307 3086335
>>086332
Что за прога?
Windows 7: Chromium based 308 3086340
Linux: Firefox based 309 3086348
>>086340
Спасибо, вечером запробую.
Windows XP: Firefox based 310 3086356
>>086332
Нет, у тебя какая-то другая настройка всё портит, или ты что-то критичное не указал. Ты должен быть в состоянии вытащить поток видео из одного контейнера и вставить в другой, а потом наоборот, а потом ещё и ещё, и разницы с кодированием напрямую в них не должно быть.
Linux: Firefox based 311 3086358
>>086332
Надо было сразу скинуть строку которой конвертируешь.
Windows 10: Chromium based 312 3086525
>>086332
Как я понял, дело не в mkv или mp4, у тебя mkv видео в прогрессивной развертке 480p, а mp4 в черестрочной по англ. интерлейсед 480i. Можешь погуглить чем отличаются, но в кратце интерлейдед это когда 2 когда совмещаются один, особенно понятно когда смотришь видео на плоскостях появляются полосы в видео, в общем разрешение в 2 раза ниже по факту, поэтому такие результаты.
Можно также пример на старых консолях по типу ps2 реальное разрешение игры 320x240p, а выводит она картинку на телек в 480i.
Сегодня весь контент в прогрессивной развертке, поэтому пишут 1080p например, кроме телевизионных передач, записей, трансляций по типу k-pop концертов еще.
Windows 10: Chromium based 313 3086537
>>086525

>2 когда совмещаются один


2 кадра совмещаются в один
фикс
Windows 10: Firefox based 314 3086552
Есть двухминутное видео весом в 1Гб и битрейтом в 50kbps. Хочу сжать до вменяемого состояния. Хочу быстро, поэтому планирую использовать карту.
Какие параметры курить? Или просто ебануть битрейт в 500к и все?
Windows 10: Chromium based 315 3086563
>>086552
CRF всегда лучше, чем указание конкретного битрейта. Конечно, если это не дико огромный битрейт. Остальное пусть более опытные подскажут.
Windows 10: Firefox based 316 3086567
>>086552

>в 50kbps


50 000kbps фиксанул себя
Windows 10: Chromium based 317 3086581
>>086563
Почему он всегда лучше?
Windows 10: Chromium based 318 3086582
>>086581
Потому что сжимает исходя из ожидания куда человек смотрит на видео.
https://ru.wikipedia.org/wiki/Constant_Rate_Factor
ol3 (17).jpg3 Мб, 2160x3840
Windows 7: Chromium based 319 3086584
>>086356
>>086358
>>086525
Я для кодирования юзаю StaxRip. Уже некоторое время его использую, много функционала и настроек. Мне надо было пережать несколько видосов и я решил попробовать разные присеты. Вчера ебался долго с этим и никак не мог понять в чем разница, решил спросить, вдруг помогут, что и произошло

Чересстрочная развертка хуй знает как включилась, никогда такого раньше небыло. Посмотрел через mediainfo и везде пишет что прогрессивная. Может быть это баг. На днях проверю, так как сейчас нету времени. Всем спасибо
Windows 10: Chromium based 320 3086594
>>086159

>А зачем тебе питон вообще?


Я только сейчас понял что ты спрашивал зачем мне питон в этом всём занятии. Ну, я написал хуитку, которая по очереди конвертирует все файлы в папке. Можно было бы просто батник замутить, но я питон лучше знаю.
Windows 10: Chromium based 321 3086597
Записал два футажа 1080-60fps. Отрендерил премьером (медиа энкодером) в 720 - 30fps. В Ut Vid (avi), pro res, h264(в 50 и 62,5M/s) и vp9 через воукодер (crf35). Всё, кроме vp9 из воукодера пережал в vp9 crf35 в два прохода с помощью ffmpeg. Результаты FFmetrics.
Windows 10: Chromium based 322 3086608
>>086594
Ну если реально лучше знаешь, то в путь. Я через батники всё делаю.
Windows 10: Chromium based 323 3086609
Завтра ещё посмотрю то же самое для cbr в 6M. Надо было с самого начала это и сделать.
Android: Mobile Safari 324 3086817
>>086563
Если указать такой же битрейт как после сжатия crf то будет одинаковое качество. Crf просто сам вычитает битрейт
Windows 10: Chromium based 325 3086922
>>086597
Что это значит? Куда смотреть? Какие выводы?
Windows 10: Chromium based 326 3086933
>>086817
Нет, CRF использует психовизуальную модель. То есть субъективно качество будет выше, хотя объективно нет. Плюс, по моей практике, даже при vbr простые сцены не сжимаются сильно, в то время как cqp и тем более crf очень сильно реагируют на сложность картинки. Запись проводника виндовс и 3д шутера могут разительно отличаться по размеру, в то время как vbr просто стремиться уложиться в целевой битрейт и будет недостаточно экономить на простых сценах и недотрачивать на сложные.
Windows 7: Chromium based 327 3086934
>>086597
кстати еще бы размер файлов показывало, чет разработчик профукал этот момент
Windows 7: Chromium based 328 3086935
>>086934
Посмотрел, оно показывает битрейт. Надо потянуть столбец медиа инфо
Windows 10: Chromium based 329 3086938
>>086934
Да. Там отличие где-то в мегабайт.
>>086922
Да по большей части ничего не значит, ведь битрейт разный. Вот сейчас посмотрим при cbr.

Итак, вот сравнение вебм из разных промежуточных источников с cbr 6M/сек. Прилепил значение битрейта, ибо cbr конечно всё равно варьирует битрейт, просто в очень ограниченном диапазоне. У меня битрейт показывает только если навести мышкой.

Третий скрин это сравнение вебм по совершенно левому референсу. Кроме одной вебм. Поможет понять насколько важен нам вообще каждый параметр. VMAF разработана чтобы заменить собой все остальные метрики и, в целом, мне она действительно кажется наиболее хорошей метрикой. На неё я и буду смотреть.
Учитывая итоговый размер, я остановлюсь на h264 с максимально доступным в премьере битрейтом.
Windows 10: Chromium based 330 3086939
Блядь. Вот с битрейтом.
Windows 10: Chromium based 331 3086940
Скриншоты из вебм в данном случае неинформативны. в DRG мало движения и картинка неотличима, если не рассматривать кадлый пиксел. В CS нет каких-то нормальных ориентиров, ибо текстуры в области видимости сами с артефактами сжатия уже в игре.
Windows 10: Chromium based 332 3086942
Чтож. Этот >>086052 анон был прав.

>ProRes тебе вообще не нужен, h264 с максимальным битрейтом для 1080п 60000 кбпс хватит, чтобы потерь не было, как минимум для глаза, но тут от настроек кодировщика зависит еще конечно.


>Я так и делаю.



Теперь и я так делаю.
Windows 10: Palemoon 333 3086950
>>086933

> CRF использует психовизуальную модель


Да вроде всю жизнь использовал уровень качества, а за психовизуал отвечали различные aq-mode и psy-rd, если речь идёт о h264
Linux: Firefox based 334 3086952
>>086950
Вот эта строчка с википедии это оно и есть:
Метод же CRF сжимает похожие кадры неодинаково: это происходит за счёт того, что учитывается движение объектов. Визуально человек различает больше деталей в неподвижных объектах, чем в движущихся, поэтому программа сжатия видео может отбросить больше деталей (увеличить сжатие) на движущихся элементах и сохранить больше (увеличить детализацию) на неподвижных. Субъективно такое видео будет казаться качественней.
Windows 10: Chromium based 335 3086953
>>086933 >>086952
Это посты противоречат друг другу. Так crf больше сжимает динамику или наоборот статику?
Windows 10: Chromium based 336 3086956
>>086942
Он был прав не в том, что из h264 сжатие лучше по сравнению с lossless, а в том, что при высоком битрейте нет никакой разницы, если это всё равно будет неумолимо сжато во много раз. И это изначально очевидно любому человеку, не одурманенному пердолингом ради пердолинга, ибо хоть сколько-то значимая разница не всегда видна даже при покадровом сравнении с лупой.
Linux: Firefox based 337 3086957
>>086953
Противоречия нет. И crf и cqp гораздо лучше адаптируются под сложность картинки. Я не знаю как под капотом, но запись из OBS (nvenc cqp) может сильно отличаться по весу в зависимости от сложности картинки (игра vs проводник). Я давно очень с этим столкнулся, мне кажется разница была чуть ли не раз в 10, но боюсь напиздеть. Проверил бы, но я РАБотник, дома буду не скоро. Может того же самого можно добиться с огромным диапазоном vbr, не знаю. Но CRF, по сравнению с CQP, ещё и учитывает что человек смотрит на движущиеся предметы в кадре и потому сильнее сжимает статику, чтобы меньше сжимать объекты в фокусе внимания.
Linux: Firefox based 338 3086960
>>086956
Так я с этим и согласился.

>не одурманенному пердолингом ради пердолинга


Алло, этот тред не про шизиков, которые жмут 10 секунд два часа ради гомеопатической прибавки качества? Тогда зачем он нужен? Webm for retards скачал и погнали.

Забавно, что

>что из h264 сжатие лучше по сравнению с lossless


похоже на правду, если сильно захотеть и принять за истину что Ut Vid это lossless (а они утверждают что это так) и что VMAF всему голова и самая правильная метрика.

>разница не всегда видна даже при покадровом сравнении с лупой.


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

> неумолимо сжато во много раз


Очень шумные текстуры, да ещё и в движении, при сжатии превращаются в мыльные jpeg пятна. А вот prores в этом плане показал себя значительно лучше.
Но эти вебм нельзя было использовать в FFmetrix, ибо оригинал, нужный для референса, сильно длиннее итоговых вебм, а через copy выходит классическая проблема с ключевыми кадрами и первые пара секунд точно вырезанного фрагмента вышли статичной картинкой.
Записанные на второй стадии куски не столь показательны. Было бы разумно загрузить тот же уровень Cruelty Squad и попрыгать там под запись ещё раз, но, в принципе, уже не интересно. Потому что:

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


Уже указал с чем здесь не согласен, но вывод то тот же: кодировать в h264 с максимальным битрейтом и не ебать мозги. Это быстро в первичном рендере и при перекодировании в вебм и даёт почти топовый результат по некоторым метрикам в FFmetrix. По совокупности это победитель нашего конкурса! Ураааа! Поздравляю всех с докторской степенью в сжатиенауках. Возможно именно эти знания подарят на путь к бессмертию или, хотя бы, к лекарству от рака.
Linux: Firefox based 338 3086960
>>086956
Так я с этим и согласился.

>не одурманенному пердолингом ради пердолинга


Алло, этот тред не про шизиков, которые жмут 10 секунд два часа ради гомеопатической прибавки качества? Тогда зачем он нужен? Webm for retards скачал и погнали.

Забавно, что

>что из h264 сжатие лучше по сравнению с lossless


похоже на правду, если сильно захотеть и принять за истину что Ut Vid это lossless (а они утверждают что это так) и что VMAF всему голова и самая правильная метрика.

>разница не всегда видна даже при покадровом сравнении с лупой.


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

> неумолимо сжато во много раз


Очень шумные текстуры, да ещё и в движении, при сжатии превращаются в мыльные jpeg пятна. А вот prores в этом плане показал себя значительно лучше.
Но эти вебм нельзя было использовать в FFmetrix, ибо оригинал, нужный для референса, сильно длиннее итоговых вебм, а через copy выходит классическая проблема с ключевыми кадрами и первые пара секунд точно вырезанного фрагмента вышли статичной картинкой.
Записанные на второй стадии куски не столь показательны. Было бы разумно загрузить тот же уровень Cruelty Squad и попрыгать там под запись ещё раз, но, в принципе, уже не интересно. Потому что:

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


Уже указал с чем здесь не согласен, но вывод то тот же: кодировать в h264 с максимальным битрейтом и не ебать мозги. Это быстро в первичном рендере и при перекодировании в вебм и даёт почти топовый результат по некоторым метрикам в FFmetrix. По совокупности это победитель нашего конкурса! Ураааа! Поздравляю всех с докторской степенью в сжатиенауках. Возможно именно эти знания подарят на путь к бессмертию или, хотя бы, к лекарству от рака.
Windows 10: Chromium based 339 3086967
>>086957

> Я не знаю как под капотом, но запись из OBS (nvenc cqp) может сильно отличаться по весу в зависимости от сложности картинки (игра vs проводник). Я давно очень с этим столкнулся, мне кажется разница была чуть ли не раз в 10, но боюсь напиздеть.


У меня в OBS на AMD AMF настроен обычный VBR 20000-30000 kbit/s, но при этом при записи какого-нибудь статичного документа в ворде наблюдаю на мониторинге 500-1500 kbit/s.

> Противоречия нет.


>>086952

> Вот эта строчка с википедии


> отбросить больше деталей (увеличить сжатие) на движущихся элементах и сохранить больше (увеличить детализацию) на неподвижных


>>086957

> сильнее сжимает статику, чтобы меньше сжимать объекты в фокусе

Linux: Firefox based 340 3086968
>>086967
Да это просто я обосрался, да. Сломанный телефон в моём мозге. Понять, простить.

The human eye perceives more detail in still objects than when they’re in motion. Because of this, a video encoder can apply more compression (drop more detail) when things are moving, and apply less compression (retain more detail) when things are still.
изображение.png7 Кб, 935x69
Windows 10: Firefox based 341 3087044
>>086563
Почему h264_nvenc не умеет работать с crf? В чем подстава?
Windows 10: Chromium based 342 3087046
>>087044
Юзай Constant QP mode.
Windows 10: Firefox based 343 3087048
>>087046
Ну вот, опять гуглить.
Windows 10: Chromium based 344 3087051
>>087048
Подожди, аналог crf есть.
Пример
-c:v h264_nvenc -preset:v p6 -tune:v hq -rc:v vbr -cq:v 19 -b:v 0 -profile:v high
https://superuser.com/questions/1236275/how-can-i-use-crf-encoding-with-nvenc-in-ffmpeg
CQP с -qp тоже можно,но это чуть другое.
Windows 10: Firefox based 345 3087052
>>087051
Спасибо. Вообще я уже воспользовался CQP, но эти параметры тоже попробую для общего развития.

Сначала с помощью -vf fps снизил частоту кадров, получил 250Мб из 1Гб (с 48 кадров до 30). Затем с -qp 37 пожал материал до 50Мб и теперь вполне можно грузить куда захочу. Единственный минус - долгая обработка фильтром fps. Вот бы было что-нибудь побыстрее.
Windows 10: Chromium based 346 3087060
>>087052
Можно без фильтра, просто -r 30 сделай и всё в параметрах видео.
Windows 10: Chromium based 347 3087109
>>087052
В чём космический эффект -vf fps вместо православного -r и двукратного перекодирования?
Windows 10: Firefox based 348 3087146
>>087109
Не стану врать - я не знаю. Мне нужно было просто сократить fps ну я и написал в консоль что в интернете посоветовали. Что насчет двукратного кодирования?
Алсо >>087060 уже пробовал, скорость примерно та же - 0.5x

Не знаю, может быть я что-то неправильно делаю.
изображение.png1 Кб, 533x32
Windows 10: Firefox based 349 3087149
>>087146
Скриншот не захотел вставляться.
Windows 10: Palemoon 350 3087179
>>086952

> Вот эта строчка с википедии это оно и есть


В этой строчке описывается работа параметра qcomp, который присутствует далеко лишь не во всех энкодерах, потому рассказы про crf использует какую-то там модель, кроме модели постоянного уровня качества оставлю цитатерам википедии.
1639019416546.jpg255 Кб, 1080x1018
Windows 10: Palemoon 351 3087374
>>086952
Ты прав, я слишком узколобо воспринял слово "психовизуал", изменение уровня квантования в сценах подходит, независимо от наличия параметров подстройки этих изменений. Мне надо крепко думать, прежде чем строчить ответы.
Linux: Firefox based 352 3087421
Анон, два вопроса. Записываю в 1080п, 60фпс, потом монтирую, рендерю и перекодирую в вебм.
1. Лучше менять фпс и разрешение перед конвертацией в вебм или во время?
2. Что там за тема с -r. В чём отличие от фильтра fps?
изображение.png13 Кб, 999x305
Windows 10: Firefox based 353 3087503
А у меня такой вопрос - подходит ли вообще CQP для записи на лету? Слишком уж жирные файлы на выходе получаются.
Windows 10: Chromium based 354 3087546
>>087503
Ну то есть ты поставил 23 и файлы у него жирные. Ну не знаю, может ты качество снизишь? Я правда в 22 пишу и меня устраивает. Поставь 30, зайди в шутан какой-нибудь и резко води камерой. Посмотри что получилось. Двигайся в сторону меньшего размера/большего качества. Так найдёшь оптимальное качество. При 22 там сложно вообще встретить артефакты, есть куда двигаться. Вопрос уровня "я газ вдавил в пол, подходит ли моя машина чтобы не давить людей?"
Windows 10: Firefox based 355 3087642
>>087546
Спасибо.
Windows 10: Firefox based 356 3087657
>>086139

> vp9 с crf35 оптимально


Нет, это прям шакалы. Та даже на crf32 уже шакалы вылазят. Что-то оптимальное начинаеться где-то crf24 и меньше.

А хотя тебе всё равно в 8мб сжимать, а там шакалов не избежать.
Android: Mobile Safari 357 3087667
>>087421
Не надо записывать в вебм. Vp9 и старее это убогие кодеки, во всём проигрывают h264, h265
Android: Mobile Safari 358 3087668
>>087421
*Конвертировать а не записывать

> 1. Лучше менять фпс и разрешение перед конвертацией в вебм или во время?


Чё, какая разница

> Что там за тема с -r. В чём отличие от фильтра fps?


Фильтр именно преобразует частоту, а r можно использовать даже без перекодирования видео
Windows 10: Chromium based 359 3087678
>>087657
Ну не обязательно в 8мб, но да, мне надо сильно сжимать, так что 35 это оптимально под мои цели, а не вообще.
Linux: Firefox based 360 3087683
>>087668

>Чё, какая разница


Да хуй знает. Потому и спрашиваю. Вот, оказывается, что между """"""лосслесс"""""" кодеками есть разница.
>>087667

> Vp9 и старее это убогие кодеки, во всём проигрывают h264, h265


В каждом треде должен быть долбаёб, который с пеной у рта доказывает что чёрное это белое.
Linux: Firefox based 361 3087740
>>087683

>Вот, оказывается, что между """"""лосслесс"""""" кодеками есть разница.


Конечно между ними есть разница? То, что они не теряют информацию, не означает, что они абсолютно идентично её представляют для воспрозведения. Это означает, что между ними можно эту информацию переводить свободно, ничего не теряя. Или ты про какой-то лосслесс, который при перекодировании теряет, но всё равно лосслесс себя называет? Я, признаюсь, не специалист по ним.
Linux: Firefox based 362 3088521
Ммм, как же охуенно перегонять флак в 64кбит опус и наслаждаться тем что это даже можно слушать, кто сейм?
Windows XP: Firefox based 363 3088655
>>088521
Opus уже не модно, модно xHE-AAC.
Windows 10: Chromium based 364 3088727
>>088521

> 64кбит опус



Гонять музыку в телефонные кодеки это кек :)
Windows 10: Chromium based 365 3088734
>>088727
Свидетель святого предназначения, ты?
Linux: Firefox based 366 3088735
>>088727
В этом же и суть.
Windows 10: Chromium based 367 3089425
Анончик, подскажи самый лучший способ стриминга с Win10 на телевизор? Телевизор - LG C1. Интересует именно супер качество, HDR (Plex в него не умеет) и вот это всё. Или лучше не ебаться и кидать на внешний диск?
Windows 7: Chromium based 368 3089455
Windows 10: Chromium based 369 3089495
>>089455
Спасибо, настроил VLC, вроде пока полёт нормальный.
Windows 10: Chromium based 370 3089510
>>089425
Можно ли в VLC настроить трансляцию с аппаратным ускорением?
Windows 7: New Opera 371 3089535
>>056070 (OP)
Всем уважения.
Кодирую на некропеке с i7 четвертого поколения, соответственно 4\8 и квиксинк. Выиграю ли я время обработки, если "обновлюсь" на зион примерно такой же новизны, но в котором зато будет, например, 14\28 без квиксинка (и чуть ниже частоты)? Т.е. насколько зависит скорость кодирования на процессоре от количества ядер\потоков?
Если важно, я пользуюсь VapourSynth через Hybrid.
Linux: Firefox based 372 3089537
>>089535
Мне кажется важно какой ты кодек используешь.
Android: New Opera 373 3089542
>>089537
H.265 только, т.е. и сейчас и в случае апгрейда он программный.
Linux: Firefox based 374 3089546
>>089542
Програмный то програмный, но вроде у разных кодеков разные возможности по параллельному кодингу.
Linux: New Opera 375 3089613
>>089546
Ну ладно, и у хевка какие такие возможности, известно?
Windows 10: Chromium based 376 3089623
>>089613
Мне нет) Я спросил, потому что шарящим людям будет важна эта информация чтобы ответить тебе. Но сам я не знаю.
Windows 7: New Opera 377 3090369
>>089623
Жаль, шарящие люди не пришли. Тем временем в доках к h.265 я прочитал, что параллелиться-то он умеет неплохо, но это может негативно влиять на сжатие. Правда величину негатива ессно не узнать.
Windows 10: Chromium based 378 3090571
>>090369
Ну, в общем-то, как и остальные кодаки, как я понимаю.
Windows 7: New Opera 379 3090640
>>090571
Не, ну с h.264 он там прямо сравнивается и выигрывает, естественно. Про h.266 или уже доступный AV1 не читал, но вероятно в них еще оптимальнее многопоточность, т.к. они тупо новее.
Windows 10: Chromium based 380 3092779
Пытаюсь разобраться в этой теме. Вот я пишу ffmpeg -i 546.mp4 test.webm и файл не надйен. А если полностью прописать путь то находит и работает. А файл лежит рядом с ffmpeg.exe, дак почему требуется полный путь?
1622591443758.png12 Кб, 333x216
Windows 10: Chromium based 381 3092811
>>092779
Лучше либо прописывать в адресной строке проводника cmd (самый удобный вариант), чтобы консоль открылась сразу в текущей папке, либо в самой консоли переходить в папку с файлами с помощью команды cd (муторно), а не класть файлы рядом с ffmpeg.
Windows 7: Firefox based 382 3092885
>>092811

> прописывать в адресной строке проводника cmd (самый удобный вариант),


Shift + ПКМ по пустому месту в Проводнике, в Windows 7 переведено как "Открыть окно команд".
>>092779
Ты находишься не в этой папке. Сам ffmpeg находит потому, что путь к ffmpeg указан в PATH (напиши echo %PATH%, чтобы увидеть).
21312312312.png6 Кб, 831x120
Windows 10: Chromium based 383 3093073
Теперь у результата превью на дваче проебывается. Какой-то геморрой блин, почему так сложно.
Windows 10: Chromium based 384 3093077
>>093073
Чел, ты постишь кринж. Результат вообще нормально запускается?
Windows 10: Chromium based 385 3093083
>>093077
С результатом все абсолютно нормально, кроме того единственного, что макаба сжирает превью.
Не знаю где тут кринж, это взято из вики, только убрано зацикливание картинки, потому что неправильно общая длительность считалась и не фиксилось. И добавлен рейскейлинг с борама, тут тоже работает.
Windows 10: Chromium based 386 3093086
>>093083
Да короче пофиг, лучше в вегасе пилить, в пять раз больше весить будет, зато надежно.
Android: Mobile Safari 387 3093105
>>093073
Ебать дебил ты чё ввёл за говно
Windows 10: Chromium based 388 3093121
>>093105
Да шапку читай там написано, чего я тебе?
Входные файлы. Потом потоки - они не нужны, они были в вики примере чтобы прерывалось через shorten, но shorten некорректно работает, так что просто обозначение потоков осталось, можно стереть. Потом настройки звука - они для вебм, но процесс не крашат, может работают. Потом рескейлинг, тут чето надо чтоб картинка была в джипег, иначе рапидорасит. Потом какой-то костыль из вики, который должен фиксить превью, но не фиксит. И выходной файл. Все просто тут.
Меня все устраивает что только плохо вот - нет превью, это абу свинью подложил. А вегас выдает тяжелые файлы, либо шакалит картинку. Можно что из вегаса вываливается перегнать через борам, но будет вебм тогда, а не мп4. Пизда короче.
Windows 10: Chromium based 389 3093218
>>093083 >>093121
Так и подумал, что ты из шапки взял пример, только он протух лет 5 как и годится разве что для общего развития ньюфажек, и написан этот пример именно под вебм, и поэтому у тебя неверно работают команды. Иначе сложно объяснить, зачем пихать ворбис в мп4. Зачем тебе вообще мп4, если ты заливаешь на харкач? Что за борам и нахер он нужен? Кринжанул с тебя.
Android: Mobile Safari 390 3093317
>>093218
WebM стал не нужен когда в mp4 официально завезли поддержку opus, vp9, AV1. Vorbis тоже ненужен, устаревшее дерьмо.
Тебе нужно сделать аудио с картинкой?
Windows 10: Chromium based 391 3093321
>>093317

> WebM стал не нужен когда в mp4 официально завезли поддержку opus, vp9, AV1.


Когда? Где почитать про это?

> Vorbis тоже ненужен, устаревшее дерьмо.


Да я в курсе.

> Тебе нужно сделать аудио с картинкой?


Ему.
Android: Mobile Safari 392 3093326
Windows 10: Chromium based 393 3093365
>>093317

>WebM стал не нужен


А в чём принципиальная разница?
Windows 10: Chromium based 394 3093399
>>093218

>протух лет 5


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

>зачем пихать ворбис в мп4


Дак в шапке не написано как в мп4 звук настраивать по качеству. Ну а вдруг сработает. В худшем случае ничего не будет делать. Превью нет явно не от этого, а от загона картинки не в цикл, а просто на вход. Еще х пойми почему картинку пидорасит иногда, даже jpg нужно загонять в пейнт и делать jpg из снова jpg, видимо, что-то меняется.

>Что за борам


Народная прога с интерфейсом вырезать куски из видео делать вебм. Больше она не умеет.
Linux: Firefox based 395 3093509
>>093399
Борам с 19 года не обновляется. Я уже год назад из него не мог копировать некоторые команды потому что они были неактуальны.
А так да, ффмпег это как бы не очень простая штука, кроличья норма, где сдвинувшись чуть глубже попадаешь на новый уровень дополнительных опций, которые гомеопатически что-то меняют. И документация у них довольно ебаная. Хотя, они все такие.
Windows 10: Chromium based 396 3093513
>>093399
Народная прога с интерфейсом вырезать куски из видео делать вебм это AviDemux, HandBrake, XMedia Recode, а ты каким-то ноунейм кал принёс и возносишь его над ffmpeg.
Linux: Firefox based 397 3093524
>>093399

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


Не каждый инструмент молоток, чтобы, только взяв в руки, начать им махать. Да и даже молотком можно пользоваться неумело и зарядить себе по пальцам.
Linux: Firefox based 398 3094198
>>093513

>а ты каким-то ноунейм кал принёс и возносишь его над ffmpeg.


Как гуй для ффмпега можно вознести над ффмпегом.
Linux: Firefox based 399 3094199
Решил попробовать сконвертить в av1. 25 секунд 720п конвертилось больше часа (количество потоков не менял, по стандарту 1). Проц вообще не занят по датчикам, но звук пердел (из-за обработки звук пердит при нехватке процессора). И что в итоге? Дискорд не поддерживает кодек)))) Оно и к лучшему, а то я, как пердоля-перфекционист, конвертил бы свой одноразовый кал часами ради ничего.
Windows 10: Chromium based 400 3094287
>>094199

> Дискорд не поддерживает кодек))))


Ну вообще да, мог бы тут спросить. Я сам буквально полмесяца назад это проверял и тоже с дискордом обломался. А час для av1 – это ещё довольно быстро.
Linux: Firefox based 401 3094411
Сап, аноны. Пытаюсь замасштабировать видео, ffmpeg проёбывает начальные кадры.
Команда применил из официального мана:
ffmpeg -i file.mp4 -vf scale=-1:720 file_720.mp4

В начале конвертации пишет такое:
frame= 151 fps=0.0 q=31.0 size= 0kB time=00:00:02.62 bitrate= 0.1kbits/s dup=15
frame= 263 fps=0.0 q=31.0 size= 0kB time=00:00:04.48 bitrate= 0.1kbits/s dup=15
frame= 410 fps=394 q=31.0 size= 512kB time=00:00:06.96 bitrate= 602.2kbits/s dup=15

Вот эти строки с 0kB так и должны быть или это косяк? При проигрывании выходного файла звук идёт, но изображение стоит на месте в первую секунду-две. В выводе ffprobe видно, что исходник по длительности превышает результат кодирования на 50 мс.

Куда вообще смотреть, чтобы понять, что за хуета и почему эта поебень проёбывает кадры? Как зафиксить?
Android: Mobile Safari 402 3094422
>>094411
У тебя файл битый
Windows 10: Chromium based 403 3094486
>>094287
Да я хотел повозиться немного.
Windows 10: Chromium based 404 3094817
>>088727
Этот "телефонный" кодек ты слышишь во всех видео на ютубе, в том числе и музыкальных. И качество даже лучше будет чем обоссанные 128к асс саундклауда, да даже его платного 256 аас. Буквально лучший кодек для сжатия аудио сегодня, до 17к слушать можно.
Windows 10: Chromium based 405 3094819
>>089535
Я на 2678v3 12/24 кодирую 1080P 60fps h264 veryslow в 50 fps, иногда бывает до 25 падает, но это на каких-то редких видосах. А вапорсинк там уже от тебя зависит какие фильтры ты навесишь, никто же не знает.
Windows 10: Chromium based 406 3094821
>>092779
По дефолту используется папка пользователя, когда тупо открываешь командную строку. В принципе путь перед тобой, я как раз использую папку пользователя для работы с видео. Уже привык, быстро и удобно.
Windows 10: Chromium based 407 3094822
>>093073
Начнем с того, что превью на дваче не работает, и делается каким-то костыльным методом, которым со мной анон не поделился.
Windows 10: Chromium based 408 3094823
>>094411
Я вообще не парился насчет этой фигни, мне кажется ффмпег просто в начале буфер кадров набирает, а потом кодирует и 50мс погрешность.
Windows 10: Chromium based 409 3094838
Пользуюсь тут древним борамом, с тех пор как вернулся с японской локали на русскую, хотя как это может быть связано, борам перестал адекватно воспринимать шрифты, не распознает ни в качество вложения к контейнер видео, ни вшитые в файл сделанных мной субтитров. Херь в общем.

Stream #0:0 -> #0:0 (h264 (native) -> vp9 (libvpx-vp9))
[Parsed_subtitles_0 @ 0000000000788b40] Shaper: FriBidi 1.0.5 (SIMPLE)
[matroska,webm @ 000000000287a3c0] Could not find codec parameters for stream 3 (Attachment: none): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[matroska,webm @ 000000000287a3c0] Could not find codec parameters for stream 4 (Attachment: none): unknown codec

[Parsed_subtitles_0 @ 0000000000788b40] fontselect: (, 400, 0) -> ArialMT, 0, ArialMT
[Parsed_subtitles_0 @ 0000000000788b40] fontselect: (, 400, 0) -> ArialMT, 0, ArialMT
Windows 10: Chromium based 410 3094839
>>094838
Хуево конеш что борам не модульный и либы обеспечивающие его оч удобный GUI нельзя обновлять самостоятельно.
explorerWGGVqa25I7.png68 Кб, 1283x766
Windows 10: Chromium based 411 3094841
>>094839
А это что тогда?
Windows 10: Chromium based 412 3094849
>>094841
Откуда я могу достать libfribidi-0.dll?
Windows 10: Chromium based 413 3094858
>>094849
А зачем она тебе? Да любую либу можно скомпилить на изи самому если что.
Windows 10: Chromium based 414 3094911
>>094819
С h.264 всё понятно, он до 256 потоков параллелится. А у анона h.265, насчёт него не помню.
Windows 10: Chromium based 415 3094912
>>094841
Откуда вкладки в проводнике?
Windows 10: Chromium based 416 3094960
>>094912
qttabbar. Как поставишь, не сможешь больше жить без него. Средней кнопкой мыши новые вкладки открывать ес чо, как браузер почти короче, сам разберешься.
Windows 10: Chromium based 417 3094985
>>094911
Ну вот на 2678v3 12/24 тестовый видосик FinalFantasyVIIRemake минуту. В сцене нет дикого экшона, но постоянно движение и повороты камеры туда сюда. В итоге, в тяжелых сценах движения 15фпс, средние 20фпс, легкие почти без движения 25фпс. В среднем 17-20 где-то. Проц загружается на 70% в среднем по всем 24 потокам, у меня он без анлока турбобуста и обычного на всё хватает.
14/28 будет быстрее где-то на 10%-15% макс, даже с анлоком, потому что лимит ТДП 145ватт.
Этот же видосик в h264 кодируется в 70фпс, завершился за 55 секунд, считай в 4 раза быстрей h265. Загрузка уже постоянно на 100%.
Параметры:
ffmpeg -i FFVIIR.mp4 -t 1:00 -c:v libx265 -crf 26 -preset slow -c:a aac -b:a 128k outputh265.mp4

encoded 3600 frames in 241.35s (14.92 fps), 4474.59 kb/s, Avg QP:33.87

ffmpeg -i FFVIIR.mp4 -t 1:00 -c:v libx264 -crf 26 -preset slow -c:a aac -b:a 128k outputh264.mp4
21.png34 Кб, 473x476
Windows 10: Firefox based 418 3095103
двачик помоги инфузорному, почему не открывает видео что я делаю не так
Windows 10: Chromium based 419 3095111
>>095103
Ты с систем32 ролики кидаешь?
Windows 7: Firefox based 420 3095119
>>095103
пиши
cd путь_до_папки_с_видео
Если видео не на С, а, например, на D, то пишешь
D:
Windows 10: Firefox based 421 3095148
>>095103
Пиздец. Давно начал считать, что работа с командной строкой очень важна и даёт человеку более разностороннее понимание процесса и того, чем этот человек занимается. Только что убедился в этом вновь: юзера хотя бы можно научить понимать, в какой директории он находится.
Linux: Firefox based 422 3095190
>>094422
Я скачал весь стрим весом 19 Гб и вырезаю из него кусочек, а потом этот кусочек пытаюсь замасштабировать (и возникает проблема, описанная в посте).
В плеерах стрим играется и перематывается без каких-либо проблем, так что сомневаюсь, что файл битый.

>>094823
В итоговом файле изображение стоит на месте первые 2 секунды, а звук идёт, это какая-то косячная хуйня.
Windows 10: Chromium based 423 3095199
>>095190

> В итоговом файле изображение стоит на месте первые 2 секунды, а звук идёт, это какая-то косячная хуйня.


Это ключевые кадры..
Linux: Firefox based 424 3095200
>>095199

>Это ключевые кадры..


Если ты про I-фреймы, то это дело оно должно само разруливать.
Когда-то писал плеер на Qt+ffmpeg, когда делал функцию перемотки, просто отходил назад от места назначения (если в нём не было I-фрейма), пока не находил опорный кадр, после чего спокойно декодировал уже до места, куда происходит перемотка.
Windows XP: Firefox based 425 3095207
>>095190

> вырезаю из него кусочек


Кажется, команда сверху ничего не вырезает.

Без перекодирования воспроизведение вырезанного куска оригинального видео может начаться только с ключевого кадра (если не брать костыль, существующий в mov/mp4). Почитай обзорные статейки на тему. Если ты всё равно перекодируешь для изменения размера, просто делай это одной командой с указанного времени, тогда поток пойдёт кодироваться с нужного кадра.
Linux: Firefox based 426 3095210
>>095207

>Кажется, команда сверху ничего не вырезает.


Команду для вырезания я не постил. Пользуюсь этой:

ffmpeg -i file_in.mp4 -vcodec copy -acodec copy -ss 01:01:33 -to 01:02:00 -async 1 file_out.mp4

>Без перекодирования воспроизведение вырезанного куска оригинального видео может начаться только с ключевого кадра


Плохо. Я думал, авторы ffmpeg'a эту хуйню предусмотрели. Может как-то можно сказать ему, чтобы он нашёл ближайший ключевой кадр и обеспечил вставку I-фрейма в начало вырезаемого фрагмента, типа как я делал под спойлером >>095200 ?

>Если ты всё равно перекодируешь для изменения размера, просто делай это одной командой с указанного времени, тогда поток пойдёт кодироваться с нужного кадра.


Попробую. Но перекодирование нужно не всегда. Поэтому хотелось бы иметь возможность обойтись без него.
Windows 10: Chromium based 427 3095224
>>095190

>В итоговом файле изображение стоит на месте первые 2 секунды, а звук идёт, это какая-то косячная хуйня.


А, тогда всё правильно работает. Ты вырезал кусок видоса без прошлого ключевого кадра, чтобы такого не было надо перекодировать, либо находить прошлый ключевой кадр и с него вырезать.
Windows XP: Firefox based 428 3095226
>>095210
FFmpeg тут ни при чём. Видео в принципе так устроено, что рисовать картинку на экране имеет смысл только начиная с ключевого кадра. Начнёшь с промежуточных — у тебя будет каша, пока не придёт тот же ключевой и исправит её.

Можно вместо указанного времени прыгнуть на предыдущий или следующий ключевой кадр и обрезать по нему, в интернете решения описаны не один раз.
Linux: Firefox based 429 3095231
>>095226

>Видео в принципе так устроено, что рисовать картинку на экране имеет смысл только начиная с ключевого кадра.


Я в курсе, спасибо. Речь о том, чтобы как раз этот момент разрулить.
>>095224

>либо находить прошлый ключевой кадр и с него вырезать.


Есть ли способ попросить ffmpeg сделать это за меня прямо в команде вырезания фрагмента?
Linux: Firefox based 430 3095286
В общем, вроде получилось с перекодированием. Нагуглил такой вариант:

ffmpeg -ss 01:07:00 -i video.mp4 -ss 00:01:30 -t 00:00:28 -vf scale=-1:720 cut_720.mp4

Алсо, есть ли вариант перекодирования, но с полным сохранением настроек кодирования оригинала? Раз уж оно само i-frame в начало не вставляет, но надо сохранить настройки оригинала, чтобы не проебать качество исходника?
Windows XP: Firefox based 431 3095290
>>095286
Для примерного сохранения качества (если с изображением ничего не происходит) при повторном сжатии с потерями надо брать даже больший битрейт, чем на первом шаге. Не тривиальные алгоритмы не «синхронизируют» потери, а выкидывают по новой что-то ещё.
Windows 10: Chromium based 432 3095332
>>095210
>>095286

> Команду для вырезания я не постил. Пользуюсь этой:


Мы так и думали, что копи, это было очевидно.. В твоём случае нет смысла делать это в 2 команды, когда можно всё сделать 1..
Меня только смущает, что у тебя -сс перед -ай при использовании видеофильтра.. Разве это работает как надо, или как если бы -сс было после -ай?
Linux: Firefox based 433 3095334
>>095332

>Разве это работает как надо, или как если бы -сс было после -ай?


Исходил из этой хуйни https://superuser.com/questions/138331/using-ffmpeg-to-cut-up-video:

Basically you put -ss before AND after the -i, just make sure to leave enough time before where you want to start cutting to have another key frame. Example: If you want to make a 1-minute clip, from 9min0sec to 10min 0sec in Video.mp4, you could do it both quickly and accurately using:
ffmpeg -ss 00:08:00 -i Video.mp4 -ss 00:01:00 -t 00:01:00 -c copy VideoClip.mp4
The first -ss seeks fast to (approximately) 8min0sec, and then the second -ss seeks accurately to 9min0sec, and the -t 00:01:00 takes out a 1min0sec clip.
Windows 10: Chromium based 434 3095364
>>095231

>Есть ли способ попросить ffmpeg сделать это за меня прямо в команде вырезания фрагмента?


Вот фиг знает, я через potplayer находил, тк там есть перемотка по ключевым кадрам. Да и сам фрагмент у тебя уже по сути с ключевого режется, на сколько секунд нет изображения настолько и надо прибавить. Также говорят, что типо mp4 можно все равно резать правильно без перекодировани, но я хз как.

Вот чел со стакфлоу пишет.

>With the mp4 container it is possible to cut at a non-keyframe without re-encoding using an edit list. In other words, if the closest keyframe before 3s is at 0s then it will copy the video starting at 0s and use an edit list to tell the player to start playing 3 seconds in.


>If you are using the latest ffmpeg from git master it will do this using an edit list when invoked using the command that you provided. If this is not working for you then you are probably either using an older version of ffmpeg, or your player does not support edit lists. Some players will ignore the edit list and always play all of the media in the file from beginning to end.


>If you want to cut precisely starting at a non-keyframe and want it to play starting at the desired point on a player that does not support edit lists, or want to ensure that the cut portion is not actually in the output file (for example if it contains confidential information), then you can do that by re-encoding so that there will be a keyframe precisely at the desired start time. Re-encoding is the default if you do not specify copy.



Попробуй еще помимо этого команду в конце добавлять -avoid_negative_ts make_zero, когда используешь -c copy, может поможет.
>>095286
Просто ставь пресет какой-нибудь veryfast или slower и crf 18, либо такой битрейт как у оригинала, будет близко.
>>095334
Второй вариант внутри параметров кодирования безопаснее и будет правильнее, но ему придется проанализировать всё до врмени нужного отрезка. А ss в начале сразу режет с этого момента, что кстати может также быть причиной почему у тебя обрезается начала, либо наоборот появляется. Но ты же не будешь например часовой стрим анализировать, чтобы там с 40 минуты отрезать.
Windows 10: Chromium based 434 3095364
>>095231

>Есть ли способ попросить ffmpeg сделать это за меня прямо в команде вырезания фрагмента?


Вот фиг знает, я через potplayer находил, тк там есть перемотка по ключевым кадрам. Да и сам фрагмент у тебя уже по сути с ключевого режется, на сколько секунд нет изображения настолько и надо прибавить. Также говорят, что типо mp4 можно все равно резать правильно без перекодировани, но я хз как.

Вот чел со стакфлоу пишет.

>With the mp4 container it is possible to cut at a non-keyframe without re-encoding using an edit list. In other words, if the closest keyframe before 3s is at 0s then it will copy the video starting at 0s and use an edit list to tell the player to start playing 3 seconds in.


>If you are using the latest ffmpeg from git master it will do this using an edit list when invoked using the command that you provided. If this is not working for you then you are probably either using an older version of ffmpeg, or your player does not support edit lists. Some players will ignore the edit list and always play all of the media in the file from beginning to end.


>If you want to cut precisely starting at a non-keyframe and want it to play starting at the desired point on a player that does not support edit lists, or want to ensure that the cut portion is not actually in the output file (for example if it contains confidential information), then you can do that by re-encoding so that there will be a keyframe precisely at the desired start time. Re-encoding is the default if you do not specify copy.



Попробуй еще помимо этого команду в конце добавлять -avoid_negative_ts make_zero, когда используешь -c copy, может поможет.
>>095286
Просто ставь пресет какой-нибудь veryfast или slower и crf 18, либо такой битрейт как у оригинала, будет близко.
>>095334
Второй вариант внутри параметров кодирования безопаснее и будет правильнее, но ему придется проанализировать всё до врмени нужного отрезка. А ss в начале сразу режет с этого момента, что кстати может также быть причиной почему у тебя обрезается начала, либо наоборот появляется. Но ты же не будешь например часовой стрим анализировать, чтобы там с 40 минуты отрезать.
Windows 10: Chromium based 435 3096044
Кто-нибудь находил расширение для хрома или javasript как форк youtube-dl/dlp, чтобы под видео был быстрый выбор с номерами потоков и скачать. Задолбался постоянно открывать консоль и писать по 3 строчки комманд.
Windows 10: Chromium based 436 3096148
>>096044
savefrom )
Android: Mobile Safari 437 3096188
>>096044
Этот мусор не умеет скачивать в нормальном качестве из-за ограничений Ютуба
Ставь это и всё https://github.com/jely2002/youtube-dl-gui
Windows 10: Chromium based 438 3096202
>>096148
Сэйвфром очень ограничен в плане выбора качеств, только дефолтные. Еще там баг иногда бывает с неправильными отметками времени видео.
>>096188
Да не, мне гуй не всрался, его еще долже запускать и юзать. Я говорю именно ты смотрик видосик, хочешь скачать и под ним выбираешь галочками качество со звуком нужным. Я бы сам запилил, если бы разбирался в программировании. Не знаю почему никто не может нормальный гуи форк сделать, либо расширение. Только был 4kdownloader из юзабельных и вот этот новый вышел недавно, который ты сикнул.
Android: Mobile Safari 439 3096205
>>096202
Потому что невозможно скачивать видео полностью через браузер, это очень сложная задача, нужно склеивать два потока. Одной кнопкой только если это выполнится на чьем то компьютере
1519241254664.png13 Кб, 127x602
Windows 10: Chromium based 440 3096265
>>096202
Каких качеств тебе не хватает?
Windows 10: Chromium based 441 3096330
>>094822
У меня вышло делать с превью. Правда не помню как, я уже удалил эту хуйню ффмпег.
Ну вот конкретно с музыкальной картинкой вроде дело было что обязательно надо в поток картинку пускать, как в примере в шапке, а не просто на вход. Из-за этого пердолинг с длительностью не избежать, но превью выходит зато на дваче. Удалил все потому что пошли косяки со звуком, кодеки разные пробовал и качество, все равно звук с артефактами на высоких, прям слышло.
Android: Mobile Safari 442 3096340
>>096265
4к где, еблан?
Windows 7: Firefox based 443 3096440
Впадлу читать огромную ветку на ixbt. Может кто подскажет гайд как оцифрованное с VHS прогнать через фильтры, чтоб убрать интерлейс и цветовой шум.
Windows 10: Chromium based 444 3096504
>>096205
А невозможно присобачить ffmpeg в виде расширения?
Windows 10: Chromium based 445 3096550
>>096340

>видео в fullhd


>4к где


Срыгни в /b/ или откуда ты вылез, поридж
Android: Mobile Safari 446 3096558
>>096550
Там и 1080 нет, овощ. Сейчас бы смотреть мусорный контент которое не выложили в 4к
1601200214969.png16 Кб, 127x602
Windows 10: Chromium based 447 3096571
>>096558
Хуесосный пиздоглазый дваждыобоссаный всемивыебанный зумерогнойный пориджедебил, ты? Да, ты.
Дилемма при ремуксе bluray mkv Windows 10: Firefox based 448 3096583
>>056070 (OP)
Качаю только оригинальные копии bluray-дисков. Чужие ремуксы весят в полтора-два раза меньше, что просто не может быть без ебаного пережатия, а зачастую о пережатии написано прямо в шапке раздачи.
Смотреть оригинальные ts-видеофайлы невозможно, во всех плеерах они вызывают проблемы, поэтому приходится ремуксировать в mkv.
Здесь то и возникает главная проблема - дилемма. Если это многосерийное аниме, то там по несколько серий на диске. MovieObject.bdmv тоже один на все эти серии. И если в программу-ремуксер загнать MovieObject.bdmv, то он из допустим 4 видеофайлов с диска выдаст 1 mkv. Но субтитры делятся не по дискам, а по сериям, поэтому в видеофайле с 4-мя сериями нельзя будет использовать все субтитры, можно будет только к первой серии.
Очевидное решение - импортировать в программу ts-файлы, а не MovieObject.bdmv. Но тогда теряются главы, хранящиеся в том злосчастном файле. А мне нужны главы.

Как быть? Что делать, чтобы из исходного bluray получить раздельные видеофайлы с сохранением глав?
Android: Mobile Safari 449 3096596
>>096583

> Качаю только оригинальные копии bluray-дисков. Чужие ремуксы весят в полтора-два раза меньше, что просто не может быть без ебаного пережатия, а зачастую о пережатии написано прямо в шапке раздачи.


Надо качать bdremux, там никогда ничего не сжато, в отличии bdrip. Создать remux можно одним кликом с помощью mkvtoolnix
Windows 10: Firefox based 450 3096597
>>096596
Ты дальше первой строки не читал?
Windows 10: Chromium based 451 3096599
>>096583
Вот объясните зачем быть таким шизоидом, как этот и самому себе ебать мозги, когда качество bdrip буквально не отличается от ремукса. Сравнивал и на монике с 24 дюйма, и на телике 4к 50+, и на ультравайд 32.
Windows 10: Firefox based 452 3096604
>>096599
Я не окр-шизик, чтобы перед просмотром каждого фильма сравнивать remux и rip, а потом на протяжении всего фильма трястись и постоянно думать "а нет ли здесь разницы", "а не накосячил ли автор"? Намного проще и удобнее использовать то, что по определению не может быть испорчено. И главы, нужные мне, есть не в каждом рипе.
Windows 10: Chromium based 453 3096610
>>096604
Большинство бдрипов наоборот с помощью фильтров vapoursynth улучшают, особенно аниме. Не учитывая, что сами авторы могли накосячить, либо херово апскейлить.
Windows 10: Firefox based 454 3096611
>>096610
Есть новые аниме, которые улучшать не нужно.
Всё-равно это тёмные дебри васянства, в которых может спокойно существовать очень много гадостей, не хочу туда лезть. Что задумал автор bd-диска - то и должно быть. Остальное может испортить просмотр своими подводными камнями.
Windows 10: Chromium based 455 3096613
>>096611
Автор диска заинтересован как бы быстрее с минимально возможными тратами высрать апскейл и побольше продать.
Windows 10: Firefox based 456 3096618
>>096613
Если думать в таком ключе - то да, это имеет смысл.
Но в новых фильмах и аниме апскейл неактуален, там рипы не имеют никаких преимуществ кроме размера. Как быть с новыми?
Windows 10: Chromium based 457 3096621
>>096583
Ремуксы не могут быть сжаты, иначе это рипы, а не ремуксы.
Windows 10: Chromium based 458 3096622
>>096618
Все 4к апкейл, порой даже фуллхд. Тут от бюджета студии зависит.
Windows XP: Firefox based 459 3096637
>>096611

> Что задумал автор bd-диска - то и должно быть.


То-то эту мазню все пытаются спасти дополнительными говнофильтрами поверх.

https://slow.pics/c/0GyP0yZi
https://slow.pics/c/hGj4a7WU
Windows 10: Firefox based 460 3096642
>>096613
>>096610
Спасибо, очень вкусные "улучшения". Скачал один тайтл в mkv, так в нём временные метки поломаны, и перемотка либо долгая (с задержкой), либо неточная, перематывает не на столько секунд на сколько я настроил.
Android: Mobile Safari 461 3096645
>>096597
Блять, нигде никогда не выкладывают сжатые релизы под пометкой bdremux
Windows 10: Firefox based 462 3096647
>>096645
Ошибся в терминах. Сори.
Windows 10: Chromium based 463 3096830
>>096642
А я ебу какой ты тайтл и от какого релиера скачал? Беатриче Равс вообще свои фильтры на гитхабе в общем доступе держат можно посмотреть что там, плюс как они кастомные маски прогоняют.
1637655205155.png274 Кб, 1341x698
Windows 10: Chromium based 464 3096952
Амуде на презентации пикрил показала. Это только декодирование?
akira16mb.webm16 Мб, webm,
320x180
Android: Mobile Safari 465 3097046
Смотрите, как ужал даже без хвалёных ав1
Windows 10: Firefox based 466 3097052
>>096830
К этому тайтлу не так много раздач, другие весят намного меньше, что говорит о вероятной потере качества. Сжатие ведь не резиновое, даже если remux оригинального диска сжат плохо и очень раздут. К тому же в других релизах могут быть свои проблемы.
Короче буду скачивать оригинальный remux вместе с rip'ом по-приличнее. Из remux'а возьму видео и оригинальное аудио, из рипа возьму главы, субтитры и дубляж. Потом удалю исходники. Буду ебаным пердоликом-конпелятором от мира медиа. Лишь бы диска хватило.
С говном мамонта придётся попердолиться, но да хуй с ним. Пошарюсь по раздачам, выберу релиз с апскейлом и отзывами. Буду надеяться, что раз уж у релизера хватило прямоты рук сделать нормальный апскейл - хватит и на рабочие временные метки. Если нормальный апскейл сделали за бугром - скачаю иностранный рип и в добавок русский рип ради сабов.
Windows 10: Chromium based 467 3097078
>>096952
Презентация только про ноуты были, и процы новые и будущие. Сами rx6000 еще в 20 году вышли с только декодированием естественно.
Android: Mobile Safari 468 3097164
>>097046
Настройки в студию
1618022774257.png6 Кб, 301x145
Windows 10: Chromium based 469 3097508
Почему при рендере вукодером левая кнопка остаётся серой и файл не появляется в папке?
Android: Mobile Safari 470 3097575
>>097508
Сассируй бабу потомучто
Windows 10: Chromium based 471 3097743
>>097508
МБ потому что ты 2pass юзаешь, я так и не поняял, работает он там или нет.
Windows 10: Chromium based 472 3097786
>>097743
Да, 2pass. На всю ночь оставлял, так и стоит.
mistake.jpg939 Кб, 1136x198
Windows 10: Firefox based 473 3099930
салют ффмпг бродяги.
Есть видео, и есть два файла с одинаковыми сабами в срт и асс формате. Мне нужно было добавить их в видео, без разницы какой.
Я использовал синтаксис ffmpeg -i input.mp4 -i input.srt -map 0:0 -map 0:1 -map 1:0 -c:s mov_text output.mp4 и у меня все получилось, за исключением того что сабы начали дублироваться, одна строка повторялась два раза.
Потом сделал ffmpeg -i infile.mp4 -i infile.srt -c copy -c:s mov_text outfile.mp4 результат тот же самый.
Пробывал через -vf ass, результат ошибки на пикрейлтид, что я упускаю подскажите пожалуйста?
Android: Firefox based 474 3099940
Ананасы, возможно ли в ffmpeg делать бесконечно запись экрана, но чтобы при ctrl+c пото из ram сохранились последние 10 секунд?
Windows 10: Chromium based 475 3099958
>>099930
Не понял, тебе софтсабы нужны или хардсабы, из твоего поста вообще нихуя непонятно.
Windows 10: Firefox based 476 3099966
>>099958
мне нужны хардсабы
Windows 10: Chromium based 477 3099969
>>099966
Ты бы хоть бы нормальный вовыод скинул, всё скрылл. Скриншот дублирования сабов не прислал, люди не экстрасенсы.
https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo
Windows 10: Chromium based 478 3099996
>>099930
А чё ты замазал названия? Чё стесняешься?
Apple GayPhone: Safari 479 3100133
>>097052
Ты бля ебанутый? Ремукс это исходные, никак не сжатые данные с блюрей диска. Эту всю хуйню можна как минимум в 2, а то и в 4 раза сжать без видимых потерь качества, что и делают рипперы. Или ты думаешь что сделаешь лучше за великие пиндосские умы человечества? И да, на рутрекере в основном очень хуево сжимают, на няшке есть релизы где норм сжимают, там просто по особенному эта вся хуйня делается и не одним человеком, и не на одном компе рендерится зачастую, а сразу по сетке на нескольких компах.
Linux: Firefox based 480 3100187
>>099940
В обс можно прикрутить ffmpeg. Поищи в эту сторону. Запись в оперативку, захват и сохранение будет типа на стороне обс, а алгоритм рендера будет от ффмпег.
Ну или просто пиши обс и всё? Зачем тебе именно ффмпег?
Windows 10: Firefox based 481 3100197
>>100187

>Зачем тебе именно ффмпег?


Мне нужен минимальный консольный вариант для мониторинга краша, а точнее происходящего за секунды до краша сторонней программы.
Linux: Firefox based 482 3100204
>>100197
Можешь подробнее объяснить? Типа ты хочешь чтобы оно само сохранилось при краше?
Android: Firefox based 483 3100209
>>100204

>Можешь подробнее объяснить?


Есть gui программа, она раз в неделю крашится. Есть небольшой велосипед на autoit, он отслеживает этот краш и делает дамп памяти, вот я хочу ещё добавить запись экрана за несколько секунд до краша, чтобы проще было понять где проблема
Android: Firefox based 484 3100212
>>100204
>>100209
Я в принципе могу сделать кольцевой буфер в autoit, но всеже надеюсь на наттвное решение данной задачи.
Linux: Firefox based 485 3100229
>>100212
У OBS есть api, можно с консоли ему сказать сохранить запись. В ффмпег я не нагуглил реализации быстрого повтора. Даже запись в оперативку не нашёл.
Windows 10: Firefox based 486 3100240
Когда AV1 в ffmpeg будет кодироваться с резонной скоростью на 2500K?
Linux: Firefox based 487 3100248
>>100240
Никогда? С чего это вообще должно произойти?
Android: Mobile Safari 488 3100281
>>100240

> 2500K?


Нормальный процессор не пробовал купить?
Windows 10: Firefox based 489 3100282
>>100281
Посоветуй проц с аппаратным кодированием ав1.
>>100248
Не знаю, должно или не должно.
В чем прогресс-то?
Android: Mobile Safari 490 3100284
>>100282
Интел последнего поколения
Windows 10: Firefox based 491 3100286
>>100284
Это который Alder Lake?
12xxx?
Windows 10: Firefox based 492 3100287
>>100286
Но он только декодит.
Android: Mobile Safari 493 3100291
>>100287
А, нету значит. Аппаратное кодирование говно без задач
Windows 10: Firefox based 494 3100321
>>100291
Согласен, в целом как и ADL
Windows 8: Chromium based 495 3100566
Склеиваю файлы, пока идут файлы с картинкой и звуком - все в порядке, когда очередь доходит до файлов без звука - начинается пик 1, где написано в т.ч. "missing picture in access unit with size 18", после них опять все в порядке. Гуглеж показал, что такой баг был в старых версиях и он давно пофикшен. У меня версия, которая была 2 месяца назад самой свежей. Output нормально проигрывается, на вид с видеорядом все в порядке. Это какой-то баг или реальная проблема?

Алсо:
1. Отдельно склеил 5 беззвучных файлов - пик 2 сверху; 4 файла со звуком - нет ошибок, потом к беззвучным приделал нормальные - пик 2 снизу.
2. Склеил 1 беззвучный файл + 3 нормальных - пик 3. НО: звука нет во всем output, а не только в первой части.
3. Склеил отдельно нормальные файлы без ошибок, потом склеил беззвучный и норм склейку - пик 4, этих ошибок столько, что нельзя прокрутить до их начала. Output проигрывается до конца беззвучной части и зависает.
Windows 10: Chromium based 496 3100590
>>100566
Пользоваться нормальным редактором по типу premiere, а не пердолится и фиксить таймкоды, которые ломаются.
Windows 10: Palemoon 497 3100599
>>100566
А может не заниматься хуетой и пустить тишину, чтобы ему было к чему приклеивать звуковые дороги?
Windows 8: Chromium based 498 3100628
>>100590

> Пользоваться нормальным редактором по типу premiere


Да я тут уже разобрался с тем, что мне нужно.

> а не пердолится и фиксить таймкоды, которые ломаются


Эти фрагменты рассчитаны на склеивание, программа, которая обычно это делает, похоже именно ффмпегом пользуется.
>>100599

> пустить тишину


Чего?

> чтобы ему было к чему приклеивать звуковые дороги


Нужно оставить все как есть, только склеить. Когда я склеил все с самого начала, вроде все получилось как надо, на вид и слух проигрывается нормально. Но эти цветные ошибки меня напрягают.
Android: Mobile Safari 499 3101645
>>071167
Может скинет кто?
Алсо почему >>097046
Не перематяывается??
1555055069206.png154 Кб, 512x427
Windows 10: Chromium based 500 3101683
Тред утонул или удален.
Это копия, сохраненная 10 марта в 03:16.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /s/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски