Двач.hk не отвечает.
Вы видите копию треда, сохраненную 8 июня в 19:32.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 8 июня в 19:32.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
400 Кб, 2000x2000FFmpeg и общий кодирования видео тред №11
В прошлый раз мы обсуждали азы и тонкости сжатия, а также срались и шитпостили.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
https://www.youtube.com/watch?v=9kaIXkImCAM
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Подробный разбор режимов кодирования основных кодеков читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда (частично устарело): https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
Актуальный гайд по кодированию от анона из треда №5 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
P.S. Для проверки отображения на дваче вашего нестандартного медиаконтента специально существует аж целая доска: https://2ch.hk/test/ (
М)
Тред №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/arch/2021-11-13/res/3029626.html (М)
Тред №4: https://2ch.hk/s/arch/2022-03-10/res/3056070.html (М)
Тред №5: https://2ch.hk/s/arch/2022-06-29/res/3101682.html (М)
Тред №6: https://2ch.hk/s/arch/2022-09-16/res/3144406.html (М)
Тред №7: https://2ch.hk/s/arch/2022-11-14/res/3181555.html (М)
Тред №8: https://2ch.hk/s/arch/2023-04-27/res/3205384.html (М)
Тред №9: https://2ch.hk/s/arch/2023-07-25/res/3239508.html (М)
Тред №10: https://2ch.hk/s/res/3301315.html (М)
В прошлый раз мы обсуждали азы и тонкости сжатия, а также срались и шитпостили.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
https://www.youtube.com/watch?v=9kaIXkImCAM
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Подробный разбор режимов кодирования основных кодеков читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда (частично устарело): https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
Актуальный гайд по кодированию от анона из треда №5 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
P.S. Для проверки отображения на дваче вашего нестандартного медиаконтента специально существует аж целая доска: https://2ch.hk/test/ (
М)Тред №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/arch/2021-11-13/res/3029626.html (
М)Тред №4: https://2ch.hk/s/arch/2022-03-10/res/3056070.html (
М)Тред №5: https://2ch.hk/s/arch/2022-06-29/res/3101682.html (
М)Тред №6: https://2ch.hk/s/arch/2022-09-16/res/3144406.html (
М)Тред №7: https://2ch.hk/s/arch/2022-11-14/res/3181555.html (
М)Тред №8: https://2ch.hk/s/arch/2023-04-27/res/3205384.html (
М)Тред №9: https://2ch.hk/s/arch/2023-07-25/res/3239508.html (
М)Тред №10: https://2ch.hk/s/res/3301315.html (
М)Закодировался в тредик.
579 Кб, 2048x2500На пике норм гайд? Пытаюсь сделать первую шебм по нему, но почему-то не кодируется и встаёт процесс на пункте 3.2
vb посчитал, получилось 311, нормально?
vb посчитал, получилось 311, нормально?
Как обстоят дела с VVC? Нормальный энкодер доступен? Почему mpv его не поддерживает официально?
>>365343 (OP)
Как можно сделать спектрум на ffmpeg? Ну там же с помощью мат преобразований не обойтись? Тут уже начал смотреть в сторону вегаса хуегаса.
Как можно сделать спектрум на ffmpeg? Ну там же с помощью мат преобразований не обойтись? Тут уже начал смотреть в сторону вегаса хуегаса.
>>365343 (OP)
Как дать av1an отрезок видео? В ffmpeg есть -ss и -t, а тут от ffmpeg можно использовать только фильтры.
Как дать av1an отрезок видео? В ffmpeg есть -ss и -t, а тут от ffmpeg можно использовать только фильтры.
>>365605
Понял. А как в showwaves поменять амплитуду максимальную?
Понял. А как в showwaves поменять амплитуду максимальную?
Вот я рендерю с таким параметром
-b:v 1300k
А потом с таким
-b:v 1300k -maxrate 1800k -bufsize 1800k
В итоге файлы одинакового размера. И качества одинаковое (довольно херовое).
Эти параметры дополнительные вообще на что-то влияют? Или просто забить хер на них.
-b:v 1300k
А потом с таким
-b:v 1300k -maxrate 1800k -bufsize 1800k
В итоге файлы одинакового размера. И качества одинаковое (довольно херовое).
Эти параметры дополнительные вообще на что-то влияют? Или просто забить хер на них.
>>366258
Ты эти числа с потолка взял что ли?
Если ты не знал, то твои битрейты примерно подходят для 480p и ниже.
Влияют, если ты пишешь свой клон ютуба или подстраиваешься под скорость считывания данных дисководом с диска.
Для webm на двач они не нужны.
Для домашнего транскода не нужен даже -b:v. Всё что тебе нужно для домашнего транскода это подобрать -crf.
> 1300k
> 1800k
Ты эти числа с потолка взял что ли?
Если ты не знал, то твои битрейты примерно подходят для 480p и ниже.
> Эти параметры дополнительные вообще на что-то влияют?
> -maxrate 1800k -bufsize 1800k
Влияют, если ты пишешь свой клон ютуба или подстраиваешься под скорость считывания данных дисководом с диска.
Для webm на двач они не нужны.
Для домашнего транскода не нужен даже -b:v. Всё что тебе нужно для домашнего транскода это подобрать -crf.
>>366341
На лицензию нужно смотреть.
На лицензию нужно смотреть.
>>365387
VP8/9 устарели уже
VP8/9 устарели уже
Как вшивать хардсаб в поток?
>>365343 (OP)
Посоветуйте музыку, на которой можно проверить потери аудиокодеков.
Посоветуйте музыку, на которой можно проверить потери аудиокодеков.
>>366841
В смысле, эффективно проверить. Чтобы в одном треке были все возможные проблемы для кодека и я мог убедиться в их отсутствии.
В смысле, эффективно проверить. Чтобы в одном треке были все возможные проблемы для кодека и я мог убедиться в их отсутствии.
>>366915
Слишком простая музыка, такую любой кодек сожмёт без проблем.
Слишком простая музыка, такую любой кодек сожмёт без проблем.
>>366841
У тебя на компе музыки подходящей нет, что ли?
https://files.catbox.moe/q2aqun.mp3
https://files.catbox.moe/v1x3h8.mp3
https://files.catbox.moe/86jt6r.flac
https://files.catbox.moe/0xu8rl.mp3
https://files.catbox.moe/5fult8.flac
Только ты копаешься с давно решённым вопросом. Уже десять лет назад ничего интересного не было в кодировании аудио, потому что везде был Opus, и куча результатов профессиональных и любительских тестов со готовыми значениями битрейтов для той или иной ситуации. Поскольку для аудио ширины каналов в подавляющем большинстве случаев хватает, теоретические вопросы запихивания целого оркестра в 32 кб/с при помощи каких-нибудь перспективных методов кодирования индустрию не особо волнуют. По идее, многопользовательские игры с передачей не только голоса (вроде VR-чатов) всё ещё могут желать значительно уменьшить объём пересылаемого всем присутствующим аудио или поднять его качество, но это, как мне кажется, не слишком большой рынок.
У тебя на компе музыки подходящей нет, что ли?
https://files.catbox.moe/q2aqun.mp3
https://files.catbox.moe/v1x3h8.mp3
https://files.catbox.moe/86jt6r.flac
https://files.catbox.moe/0xu8rl.mp3
https://files.catbox.moe/5fult8.flac
Только ты копаешься с давно решённым вопросом. Уже десять лет назад ничего интересного не было в кодировании аудио, потому что везде был Opus, и куча результатов профессиональных и любительских тестов со готовыми значениями битрейтов для той или иной ситуации. Поскольку для аудио ширины каналов в подавляющем большинстве случаев хватает, теоретические вопросы запихивания целого оркестра в 32 кб/с при помощи каких-нибудь перспективных методов кодирования индустрию не особо волнуют. По идее, многопользовательские игры с передачей не только голоса (вроде VR-чатов) всё ещё могут желать значительно уменьшить объём пересылаемого всем присутствующим аудио или поднять его качество, но это, как мне кажется, не слишком большой рынок.
>>366994
А как же xHE AAC v2? Я всё не могу решить, лучше ли он опуса или хуже. У него есть оптимизация для стерео, если звук в обоих каналах не сильно отличается друг от друга. Ещё, почему-то, на всех сайтах советуют кодировать opus указывая битрейт вместо vbr.
>Уже десять лет назад ничего интересного не было в кодировании аудио, потому что везде был Opus
А как же xHE AAC v2? Я всё не могу решить, лучше ли он опуса или хуже. У него есть оптимизация для стерео, если звук в обоих каналах не сильно отличается друг от друга. Ещё, почему-то, на всех сайтах советуют кодировать opus указывая битрейт вместо vbr.
>>367420
Ну смотри
https://hydrogenaud.io/index.php/topic,120997.0.html
https://hydrogenaud.io/index.php/topic,121099.0.html
https://hydrogenaud.io/index.php/topic,120936.0.html
https://hydrogenaud.io/index.php/topic,120081.0.html
https://hydrogenaud.io/index.php/topic,119333.0.html
На сверх низких битрейтах преимущество однозначно на стороне xHE AAC, он же USAC.
На низких битрейтах (в раёне 64 kbps) уже не так однозначно, но всё ещё на стороне USAC.
Но ты скорее всего будешь кодировать на битрейтах повыше, от 96 kbps. И тут разница в звуке сходит на нет но проявляются проблемы нового кодека, такие как:
— слабая совместимость. Мало какой софт умеет его декодировать. Про аппаратную совместимость я вообще молчу. ffmpeg не умеет например.
— Контейнер mp4. Это проблема, потому что та же Apple придумывала костыли в тегах просто чтобы заставит воспроизводить его в gappless режиме. Работает только в их экосистеме и в фубаре.
— Интеграция декодера в ffmpeg это тот ещё глючный костыть из-за которого сам фубар вылетает.
Ну смотри
https://hydrogenaud.io/index.php/topic,120997.0.html
https://hydrogenaud.io/index.php/topic,121099.0.html
https://hydrogenaud.io/index.php/topic,120936.0.html
https://hydrogenaud.io/index.php/topic,120081.0.html
https://hydrogenaud.io/index.php/topic,119333.0.html
На сверх низких битрейтах преимущество однозначно на стороне xHE AAC, он же USAC.
На низких битрейтах (в раёне 64 kbps) уже не так однозначно, но всё ещё на стороне USAC.
Но ты скорее всего будешь кодировать на битрейтах повыше, от 96 kbps. И тут разница в звуке сходит на нет но проявляются проблемы нового кодека, такие как:
— слабая совместимость. Мало какой софт умеет его декодировать. Про аппаратную совместимость я вообще молчу. ffmpeg не умеет например.
— Контейнер mp4. Это проблема, потому что та же Apple придумывала костыли в тегах просто чтобы заставит воспроизводить его в gappless режиме. Работает только в их экосистеме и в фубаре.
— Интеграция декодера в ffmpeg это тот ещё глючный костыть из-за которого сам фубар вылетает.
>>367420
>>367431
Говорю же, нету спроса на новый универсальный формат с заметным скачком в скорости и качестве, пропускная способность аудио в типичных применениях не ограничивает. Посмотрите, где используется (x)HE-AAC, AAC-BSAC: цифровая радиотрансляция, сотовые сети, спутниковое вещание. Везде, где эфир общий, поделен на каналы фиксированного размера, и больше, чем есть, тебе не дадут (либо для этого требуются огромные инвестиции, государственная поддержка и планирование на десять и более лет), поэтому для увеличения числа потоков или их качества приходится изощряться. Не знаю, что нужно, чтобы высококачественное аудио (а не речеподобные передачи) от «на 128 кб/с можно кодировать чем угодно, средний слушатель не заметит» перескочило на «на 64 кб/с можно кодировать кодеком X, средний слушатель не заметит». Какой-нибудь европейский канал решит через спутник сразу 20 языковых дорожек слать, и захочет кодировать только отличия? Но для этого нужно иметь что показать с 20 вариантами дубляжа. Кроме того, существует интернет, в котором связь двусторонняя, и пользователь может переключаться между независимыми дорожками высокого битрейта столько раз, сколь надо.
>>367431
Говорю же, нету спроса на новый универсальный формат с заметным скачком в скорости и качестве, пропускная способность аудио в типичных применениях не ограничивает. Посмотрите, где используется (x)HE-AAC, AAC-BSAC: цифровая радиотрансляция, сотовые сети, спутниковое вещание. Везде, где эфир общий, поделен на каналы фиксированного размера, и больше, чем есть, тебе не дадут (либо для этого требуются огромные инвестиции, государственная поддержка и планирование на десять и более лет), поэтому для увеличения числа потоков или их качества приходится изощряться. Не знаю, что нужно, чтобы высококачественное аудио (а не речеподобные передачи) от «на 128 кб/с можно кодировать чем угодно, средний слушатель не заметит» перескочило на «на 64 кб/с можно кодировать кодеком X, средний слушатель не заметит». Какой-нибудь европейский канал решит через спутник сразу 20 языковых дорожек слать, и захочет кодировать только отличия? Но для этого нужно иметь что показать с 20 вариантами дубляжа. Кроме того, существует интернет, в котором связь двусторонняя, и пользователь может переключаться между независимыми дорожками высокого битрейта столько раз, сколь надо.
>>365343 (OP)
Правильно ли я понимаю, что контейнер nut не поддерживает av1?
Правильно ли я понимаю, что контейнер nut не поддерживает av1?
Почему иногда (а может быть, теперь - всегда), когда я кодирую webm в vp9 через xmediarecode, файл получается без видео, только звук, и превьюха в винде не отображается? Хотя процесс кодирования обычный и по всем остальным показателям тоже получается обычный файл, с видео дорожкой.
>>368507
Так кодируй ffmpeg-ом! С ним хоть какая-то диагностика будет.
>Почему иногда (а может быть, теперь - всегда), когда я кодирую webm в vp9 через xmediarecode
Так кодируй ffmpeg-ом! С ним хоть какая-то диагностика будет.
Анон привет, я с одной самодельной железки граблю данные, делаю из них фотки, вывожу в виджет - получаю видео.
И тут у меня появилась задача сделать видеопоток, что-бы видео выводилось не только у меня в софтине, а можно было бы к нему еще каким-нибудь плеером прицепится. Как это вобще делается? Как из пачки фоток постоянно идущих друг за другом сделать видеопоток? Мне сказали что ffmpeg умеет все, но я знатно так прихуел читая его доку. Может анон занимался +- чем-то похожим и архивную статью какую-нибудь подкинет.
И тут у меня появилась задача сделать видеопоток, что-бы видео выводилось не только у меня в софтине, а можно было бы к нему еще каким-нибудь плеером прицепится. Как это вобще делается? Как из пачки фоток постоянно идущих друг за другом сделать видеопоток? Мне сказали что ffmpeg умеет все, но я знатно так прихуел читая его доку. Может анон занимался +- чем-то похожим и архивную статью какую-нибудь подкинет.
>>368655
https://ffmpeg.org/ffmpeg-formats.html#image2-1
https://ffmpeg.org/ffmpeg-formats.html#image2-1
> Image file demuxer.
>This demuxer reads from a list of image files specified by a pattern. The syntax and meaning of the pattern is specified by the option pattern_type.
> A sequence pattern may contain the string "%d" or "%0Nd", which specifies the position of the characters representing a sequential number in each filename matched by the pattern. If the form "%d0Nd" is used, the string representing the number in each filename is 0-padded and N is the total number of 0-padded digits representing the number. The literal character ’%’ can be specified in the pattern with the string "".
> For example the pattern "img-%03d.bmp" will match a sequence of filenames of the form img-001.bmp, img-002.bmp, ..., img-010.bmp, etc.; the pattern "im%%g-%d.jpg" will match a sequence of filenames of the form i%m%g-1.jpg, i%m%g-2.jpg, ..., i%m%g-10.jpg, etc.
>>368677
> 3.12.1 Examples
>
> Use ffmpeg for creating a video from the images in the file sequence img-001.jpeg, img-002.jpeg, ..., assuming an input frame rate of 10 frames per second:
>
> ffmpeg -framerate 10 -i 'img-%03d.jpeg' out.mkv
>
> As above, but start by reading from a file with index 100 in the sequence:
>
> ffmpeg -framerate 10 -start_number 100 -i 'img-%03d.jpeg' out.mkv
>
> Read images matching the ".png" glob pattern , that is all the files terminating with the ".png" suffix:
>
> ffmpeg -framerate 10 -pattern_type glob -i ".png" out.mkv
>>368681
Этот тред про ffmpeg. Мы не должны разбираться в твоих гуях, которые в большинстве случаев надстройка над ffmpeg.
Этот тред про ffmpeg. Мы не должны разбираться в твоих гуях, которые в большинстве случаев надстройка над ffmpeg.
>>368655
>>368677
Спасибо анон. Для 10 гц получается мне нужно сейвать 10 фоток, делать видос, удалять 10 фоток. сейвать следующие 10 фоток и так по кругу? А как будет работать ffmpeg, когда 10 фоток удалены, а новые я еще не сохранил? + mkv файл же будет разрастаться. В любом случае больше спасибо, буду вчитываться и ставить эксперименты.
>>368677
Спасибо анон. Для 10 гц получается мне нужно сейвать 10 фоток, делать видос, удалять 10 фоток. сейвать следующие 10 фоток и так по кругу? А как будет работать ffmpeg, когда 10 фоток удалены, а новые я еще не сохранил? + mkv файл же будет разрастаться. В любом случае больше спасибо, буду вчитываться и ставить эксперименты.
>>368686
Нет. Ты устанавливаешь фреймрейт такой каким он был в исходнике.
Сейвать тебе надо все кадры.
В итоге у тебя будет видос, ну допустим у тебя 10 кадров в секунду, и всего кадров 1000. Тогда у тебя будет видос на 100 секунд с кадровой частотой 10 гц.
Нет. Ты устанавливаешь фреймрейт такой каким он был в исходнике.
Сейвать тебе надо все кадры.
В итоге у тебя будет видос, ну допустим у тебя 10 кадров в секунду, и всего кадров 1000. Тогда у тебя будет видос на 100 секунд с кадровой частотой 10 гц.
>>368686
Может ты удаляешь кадры потому что у тебя места мало на диске. Тогда делай порционно.
Во первых, определись с размером GOP. Для максимального сжатия ставят 10 секунд. Для быстрой перемотки 1 секунду.
Во вторых, определи кадровую частоту исходника.
Теперь вырази размер GOP в кадрах по формуле: размер GOP (в секундах) * количество кадров в секунду.
Затем определись с остальными параметрами кодирования видео: кодек, битрейт/crf, пресет/cpu-used. Сохраняй во временный файл сегмента, допустим segment001.mkv
Также создай файл segments.txt и запиши в него:
file segment001.mkv
Повторить по мере прохождения увеличивая номер сегмента в названии.
Для склейки введи команду:
ffmpeg -f concat -i segments.txt -map 0 -c copy видос.mkv
Если всё получится, сегменты можно удалять.
Может ты удаляешь кадры потому что у тебя места мало на диске. Тогда делай порционно.
Во первых, определись с размером GOP. Для максимального сжатия ставят 10 секунд. Для быстрой перемотки 1 секунду.
Во вторых, определи кадровую частоту исходника.
Теперь вырази размер GOP в кадрах по формуле: размер GOP (в секундах) * количество кадров в секунду.
Затем определись с остальными параметрами кодирования видео: кодек, битрейт/crf, пресет/cpu-used. Сохраняй во временный файл сегмента, допустим segment001.mkv
Также создай файл segments.txt и запиши в него:
file segment001.mkv
Повторить по мере прохождения увеличивая номер сегмента в названии.
Для склейки введи команду:
ffmpeg -f concat -i segments.txt -map 0 -c copy видос.mkv
Если всё получится, сегменты можно удалять.
>>368690
Бесконечный поток кадров идёт, в этом вся соль, не нужно записывать видео. Нужно что-бы кадры куда-то шли, но нигде не сохранялись, а когда мне нужно я бы открывал какой-нибудь плеер типа vlc и мог просматривать что там вот сейчас льется.
Что-то типа usb-камеры, подключаешь ее - открываешь плеер и смотришь. Может я конечно вообще думаю не в ту сторону и нужно обмазываться написанием драйверов, чтобы самодельная железка определялась как камера, но мне кажется это вобще убийство )
Бесконечный поток кадров идёт, в этом вся соль, не нужно записывать видео. Нужно что-бы кадры куда-то шли, но нигде не сохранялись, а когда мне нужно я бы открывал какой-нибудь плеер типа vlc и мог просматривать что там вот сейчас льется.
Что-то типа usb-камеры, подключаешь ее - открываешь плеер и смотришь. Может я конечно вообще думаю не в ту сторону и нужно обмазываться написанием драйверов, чтобы самодельная железка определялась как камера, но мне кажется это вобще убийство )
>>368703
само собой я могу хранить какое-то количество кадров на диске, в пределах разумного.
само собой я могу хранить какое-то количество кадров на диске, в пределах разумного.
32 Кб, 532x508>>368703
Тогда тебе нужно считывать кадры с самого устройства непосредственно.
Во первых VLC сам по себе умеет открывать потоки и устройства для воспроизведения. ffmpeg тебе для этого не нужен. Просто покопайся в менюшках
Тогда тебе нужно считывать кадры с самого устройства непосредственно.
Во первых VLC сам по себе умеет открывать потоки и устройства для воспроизведения. ffmpeg тебе для этого не нужен. Просто покопайся в менюшках
>>368706
так тоже не получится, пакеты с устройства идут с самописной шапкой, своей софтиной я уже их разбираю и делаю пикчи png bmp tiff, вобщем всё могу.
так тоже не получится, пакеты с устройства идут с самописной шапкой, своей софтиной я уже их разбираю и делаю пикчи png bmp tiff, вобщем всё могу.
>>365343 (OP)
Доложите состояние аппаратного кодирования в AV1 в 2023 году.
Доложите состояние аппаратного кодирования в AV1 в 2023 году.
>>368710
Тогда придумай как вывести твои кадры в pipe. Ну чтобы можно было сделать так: прога | mpv -
У ffmpeg оно называется image2pipe. Сделай так чтобы вывод соответствовал формату. Тогда может и VLC и MPV откроют.
Тогда придумай как вывести твои кадры в pipe. Ну чтобы можно было сделать так: прога | mpv -
У ffmpeg оно называется image2pipe. Сделай так чтобы вывод соответствовал формату. Тогда может и VLC и MPV откроют.
>>368711
Последнее поколение карточек от nvidia, amd и intel умеет кодировать AV1. Это всё что я могу сказать по этому поводу.
Последнее поколение карточек от nvidia, amd и intel умеет кодировать AV1. Это всё что я могу сказать по этому поводу.
>>369124
Ну так бери помогай тому анону с его гуёвиной. А я с ней не работал и желания разбираться с ней не имею.
Ну так бери помогай тому анону с его гуёвиной. А я с ней не работал и желания разбираться с ней не имею.
>>369333
Для комического эффекта.
Для комического эффекта.
141 Кб, 370x283Хочу сжать отшакалить и перекодировать свою маняме каллекцию в хевк.
Есть ли для этого однокнопочный гуй или надо курить пердольные гайды? Для отшакаливания надо качать ремуксы или уже отшакаленные x264рипы пойдут?
Есть ли для этого однокнопочный гуй или надо курить пердольные гайды? Для отшакаливания надо качать ремуксы или уже отшакаленные x264рипы пойдут?
>>369548
Попробуй просто масштабнуть видос в разрешении с дополнительными пикселями.
Попробуй просто масштабнуть видос в разрешении с дополнительными пикселями.
>scale=iw2:ih2:flags=neighbor
86 Кб, 238x212>>369553
>>369555 (Del)
Вы думаете я про однокнопочной гуй просто так спросил чтоль? Что вы сходу грузите-то?
>>369555 (Del)
Вы думаете я про однокнопочной гуй просто так спросил чтоль? Что вы сходу грузите-то?
17 Кб, 293x360>>369560
Тебе доверено слушаться, а не морозиться.
Тебе доверено слушаться, а не морозиться.
>>369548
Очевидно нет.
там не сложно на самом деле. Гайд здесь https://kokomins.wordpress.com/2019/10/10/anime-encoding-guide-for-x265-and-why-to-never-use-flac/
> уже отшакаленные x264рипы пойдут
Очевидно нет.
> или надо курить пердольные гайды
там не сложно на самом деле. Гайд здесь https://kokomins.wordpress.com/2019/10/10/anime-encoding-guide-for-x265-and-why-to-never-use-flac/
12,8 Мб, mp4,320x180, 3:43
Надеюсь, я зашёл туда, а не туда ли. Суть такова.
Мне безумно понравился видосик с крутящейся кассетой. Я клею на него разную музыку в вегасе (да, можно через ffmpeg, но я добавляю название в видеопоток).
Есть ли кодеки, которые сами залупят маленький повторяющийся фрагмент видео, чтобы семиминутный трек не весил 20 метров?
Если это можно сделать вручную через ffmpeg - то какой командой?
Мне безумно понравился видосик с крутящейся кассетой. Я клею на него разную музыку в вегасе (да, можно через ffmpeg, но я добавляю название в видеопоток).
Есть ли кодеки, которые сами залупят маленький повторяющийся фрагмент видео, чтобы семиминутный трек не весил 20 метров?
Если это можно сделать вручную через ffmpeg - то какой командой?
>>369722
А как же тогда все эти хевк релиз группы на няхе делают своим релизы? Они там в источниках указывают релизы от сабсплиз, ерай, етк. А сабсплиз и ерай просто рипают кранчи в х264, не?
>Очевидно нет.
А как же тогда все эти хевк релиз группы на няхе делают своим релизы? Они там в источниках указывают релизы от сабсплиз, ерай, етк. А сабсплиз и ерай просто рипают кранчи в х264, не?
>>369733
Неожиданно, но самые первые мультимедийные решения начала девяностых годов вроде QuickTime как раз имели возможности по склейке фрагментов в нужном порядке, наложению на часть кадра с нужными координатами, вставке статичных картинок в нужный момент и так далее. На основе этого делались всякие приложения и игры. В MOV/MP4 есть edit lists, позволяющие нарезать, сдвинуть, зациклить куски видео или аудио, но их никто не поддерживает, кроме видеоредакторов и Apple'овских программ.
Само собой, название наложить можно фильтром в ffmpeg, хоть это и не важно.
Неожиданно, но самые первые мультимедийные решения начала девяностых годов вроде QuickTime как раз имели возможности по склейке фрагментов в нужном порядке, наложению на часть кадра с нужными координатами, вставке статичных картинок в нужный момент и так далее. На основе этого делались всякие приложения и игры. В MOV/MP4 есть edit lists, позволяющие нарезать, сдвинуть, зациклить куски видео или аудио, но их никто не поддерживает, кроме видеоредакторов и Apple'овских программ.
Само собой, название наложить можно фильтром в ffmpeg, хоть это и не важно.
>>369886
Перечитай реквест и перепроверь, что ты принёс.
Перечитай реквест и перепроверь, что ты принёс.
>>369548
Хуйня затея. Кодируй в svt-av1 - намного лучше соотношение размера и качества. Я сжал примерно в 12 раз, сохранив визуальную прозрачность (без потерь) качества, за исключением потерянного зерна пленки (шума).
Единственная проблема - некоторые серии одного из тайтлов не хотят сжиматься в svt-av1, начиная с какой-то минуты значительно проседает скорость и раздувается размер. Их я кодировал в vvc, и там прозрачное качество занимает примерно в 8 раз меньше оригинала.
>в хевк
Хуйня затея. Кодируй в svt-av1 - намного лучше соотношение размера и качества. Я сжал примерно в 12 раз, сохранив визуальную прозрачность (без потерь) качества, за исключением потерянного зерна пленки (шума).
Единственная проблема - некоторые серии одного из тайтлов не хотят сжиматься в svt-av1, начиная с какой-то минуты значительно проседает скорость и раздувается размер. Их я кодировал в vvc, и там прозрачное качество занимает примерно в 8 раз меньше оригинала.
>>370393
Чтобы вырезать и сжать с привычными параметрами кусок только что снятого видео для отправки по телеграму, например.
Чтобы вырезать и сжать с привычными параметрами кусок только что снятого видео для отправки по телеграму, например.
>>370897
Кому это может понадобится?
Телеграм сам сжимает твоё видео перед отправкой.
Телефоны в принципе не предназначены для обработки больших объёмов данных. Они греются, разряжают батарею и никак не охлаждаются.
Кому это может понадобится?
Телеграм сам сжимает твоё видео перед отправкой.
Телефоны в принципе не предназначены для обработки больших объёмов данных. Они греются, разряжают батарею и никак не охлаждаются.
Вопрос не по ффмпегу, ибо он вряд ли так умеет хотя кто знает, этот софт меня ни раз удивлял: надо из аудио файлов делать видео, желательно как будто проигрывается войс в телеге/вотсаппе/вк/etc или просто как будто плеер играет в реальном времени. Думаю, все такие видосы видели. Ну или просто красивая визуализация.
Естественно фо фри и желательно, чтобы это был софт, хотя можно онлайн-сервис и даже с рекламой, но с каким-то вменяемым количеством.
Естественно фо фри и желательно, чтобы это был софт, хотя можно онлайн-сервис и даже с рекламой, но с каким-то вменяемым количеством.
>>371357
Есть в ffmpeg фильтры для визуализации аудио. Добавишь сверху фильтр с тенью, говноблюр, выберешь цвета неоновые под ретро, и готово.
Есть в ffmpeg фильтры для визуализации аудио. Добавишь сверху фильтр с тенью, говноблюр, выберешь цвета неоновые под ретро, и готово.
>>371368
Готового примера нет %%для тупых и ленивых?
Готового примера нет %%для тупых и ленивых?
4 Кб, 678x37В гайде от анона с треда №5 при кодировании в AV1 написано:
Что-то не могу найти инфу по этой фигне, как оно работает, у меня выдаёт ошибку (см.пик)
Подскажите плиз чо не так делаю.
>Можно ещё указать film-grain=8 если у вас в видео есть шумы, перед сжатием они будет применён алгоритм убирающий шумы, и в видео записана информация как их воссоздать, за счёт чего степень сжатия и качество видео возрастает очень сильно.
Что-то не могу найти инфу по этой фигне, как оно работает, у меня выдаёт ошибку (см.пик)
Подскажите плиз чо не так делаю.
>>371683
ffmpeg -i "1.mp4" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 5000k -svtav1-params tune=0:irefresh-type=1 film-grain=8 svt.mkv
Да вот как-то так прописал, без команды film-grain=8 норм работает.
ffmpeg -i "1.mp4" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 5000k -svtav1-params tune=0:irefresh-type=1 film-grain=8 svt.mkv
Да вот как-то так прописал, без команды film-grain=8 норм работает.
>>371700
Должно быть так:
ffmpeg -i "1.mp4" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 5000k -svtav1-params tune=0:irefresh-type=1:film-grain=8 svt.mkv
Должно быть так:
ffmpeg -i "1.mp4" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 5000k -svtav1-params tune=0:irefresh-type=1:film-grain=8 svt.mkv
>>371710
Спасибо тебе анончик, так всё работает
Спасибо тебе анончик, так всё работает
>>371811
А я теперь просто гопоте велю мне команды составлять.
А я теперь просто гопоте велю мне команды составлять.
>>365343 (OP)
А сейчас?
>Актуальный гайд по кодированию от анона из треда №5
>libsvtav1
>Два прохода пока не поддерживается в ffmpeg
А сейчас?
>>365343 (OP)
Как сделать, чтобы под виндой ффмпег по умолчанию запускался с приоритетом процесса ниже среднего?
Как сделать, чтобы под виндой ффмпег по умолчанию запускался с приоритетом процесса ниже среднего?
>>373119
Использовать вызов /start /belownormal ffmpeg.exe -a -b -c -d.
Если программа не позволяет это настроить, использовать ffmpeg.bat, который будет вызывать ffmpeg-real.exe и передавать ему все параметры (или по крайней мере пытаться, учитывая экранирование). Или простенькая программа-обёртка, которая будт делать то же самое.
Использовать вызов /start /belownormal ffmpeg.exe -a -b -c -d.
Если программа не позволяет это настроить, использовать ffmpeg.bat, который будет вызывать ffmpeg-real.exe и передавать ему все параметры (или по крайней мере пытаться, учитывая экранирование). Или простенькая программа-обёртка, которая будт делать то же самое.
Есть адекватный метод рендера в премьере через ффмпег? Воукодер не предлагать.
Кто нить объяснит куда деваются субтитры на дваче?
>>375564
Никуда они не деваются. Просто от проигрывателя в браузере - огрызок (странно, да?) который не умеет в несколько дорожек в файле и во встроенные субтитры.
Никуда они не деваются. Просто от проигрывателя в браузере - огрызок (странно, да?) который не умеет в несколько дорожек в файле и во встроенные субтитры.
>>375582
Подожди, я думал что я вшил субтитры в само видео. А это оказывается в mp4 формате есть место под субтитры? А как тогда наложить субтитры?
Подожди, я думал что я вшил субтитры в само видео. А это оказывается в mp4 формате есть место под субтитры? А как тогда наложить субтитры?
Ну вот как на видео имею ввиду
22 Кб, 960x314>>375585
Желтым на видео - хардсаб - когда прямо на картинку намазано. Чтобы добавить нужно перекодировать с фильтром. С потерей качества, натурально. Убрать - никак.
https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo
Белые сабы - софтсаб, это просто дорожка сабами в виде текста встроенная в контейнер. Можно добавить еще, можно убрать, можно отображать, можно не отображать - видеопотоку от этого ни горячо ни холодно.
Желтым на видео - хардсаб - когда прямо на картинку намазано. Чтобы добавить нужно перекодировать с фильтром. С потерей качества, натурально. Убрать - никак.
https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo
Белые сабы - софтсаб, это просто дорожка сабами в виде текста встроенная в контейнер. Можно добавить еще, можно убрать, можно отображать, можно не отображать - видеопотоку от этого ни горячо ни холодно.
>>375589
Cложна, а есть более простой путть без всяких консолей? Просто кинуть видео и субтитры, и чтоб видео сшилось одной кнопкой?
Cложна, а есть более простой путть без всяких консолей? Просто кинуть видео и субтитры, и чтоб видео сшилось одной кнопкой?
>>375750
Ну а как сделать по нормальному? Почему нет программ где можно просто сшить файлы
Ну а как сделать по нормальному? Почему нет программ где можно просто сшить файлы
1,7 Мб, mp4,360x360, 0:47
Вроде щас получилось нормально
Как сохранить ту же миниатюру при конвертации?
Например я записал видео в формате mp4 H.264, хочу его выложить тут, но оно слишком большое по размеру. Есть универсальный скрипт который будет видео любого размера сжимать например до 40 мб в наилучшем качестве?
>>377466
Да, сжатие в два прохода
Да, сжатие в два прохода
Я как понимаю все программы которые конвектируют или сжимают делают оболочку под ffmpeg?
>>377758
Da.
Da.
>>378259
Если прямо га твой вопрос отвечать, то
ffmpeg -i infile.webm -c copy outfile.mp4
Имена файлов подставлять шелл-скриптом по вкусу. Возможно, понадобится что-нибудь вроде
ffmpeg -fflags +genpts -i...
Но ты учти, что сегодня mp4-контейнер - это такой mov на стероидах, пытающийся в универсальность уровня матрëшки. Быстрее всего, не все программы и устройства смогут в vp9 и opus внутри mp4.
Если прямо га твой вопрос отвечать, то
ffmpeg -i infile.webm -c copy outfile.mp4
Имена файлов подставлять шелл-скриптом по вкусу. Возможно, понадобится что-нибудь вроде
ffmpeg -fflags +genpts -i...
Но ты учти, что сегодня mp4-контейнер - это такой mov на стероидах, пытающийся в универсальность уровня матрëшки. Быстрее всего, не все программы и устройства смогут в vp9 и opus внутри mp4.
25 Кб, 290x631Увожаемые программисты, подскажите пожалуйста на что влияет Mux Rate и Buffer Size.
И ещё, как влияет Keyframe interval и Max B-Frame на размер\качество видео ?
Что-то внятной инфы на русском найти не могу в интернетах.
И ещё, как влияет Keyframe interval и Max B-Frame на размер\качество видео ?
Что-то внятной инфы на русском найти не могу в интернетах.
Почему у ффмпега нет параметра target size? Почему я должен городить костыли скрипты вместо ffmpeg -i 1.mp4 --target-size=4096k 2.mp4 ?
>>379680
Почему откуда я качаю видео в формате мп4?
Почему откуда я качаю видео в формате мп4?
скачал ффмпег на телефон и на дауничах выдаёт мне такую ошибку в лог при конвертации, что не так делаю
ffmpeg -hwaccel auto -y -i "/storage/emulated/0/Movies/video.mp4" -vn -q:v 5 -c:a copy -ab 128k -ar 44100 -strict experimental "/storage/emulated/0/Download/video.webm"
ffmpeg -hwaccel auto -y -i "/storage/emulated/0/Movies/video.mp4" -vn -q:v 5 -c:a copy -ab 128k -ar 44100 -strict experimental "/storage/emulated/0/Download/video.webm"
Новокек в треде. Допустим хочу ужать видео до 10мб - вычисляю нужный битрейт и кодирую с ним (допустим -b:v 1024k), но размер полученного файла имеет погрешность в пару мегабайт. Как закодировать чтобы было ровно 10мб, ну или без такой относительно большой погрешности?
>>381263
Ну вот анончик где я ебусь в глаза потому что до этого я нормально черезо него гонял и все работало, потом начала вылезать эта ошибка
Скачал с плеймаркета через форку gspace на моего китайца
Ну вот анончик где я ебусь в глаза потому что до этого я нормально черезо него гонял и все работало, потом начала вылезать эта ошибка
Скачал с плеймаркета через форку gspace на моего китайца
>>381337
Говно, спок. Без тебя уже нашел решение
-b:v 1000k
-minrate 1000k
-maxrate 1000k
-bufsize 1000k
Говно, спок. Без тебя уже нашел решение
-b:v 1000k
-minrate 1000k
-maxrate 1000k
-bufsize 1000k
Есть один стерео аудиопоток с пустым правым каналом. Можно ли без перекодирования скопировать левый канал на место правого или просто удалить правый, сделав поток моно?
>>381649
Нет. Без перекодирования нельзя.
Проблема в том, что lossy кодеки преобразуют обычное стерео во всякие там joint stereo, mix side stereo. Там нет отдельного потока данных для левого и правого каналов.
Нет. Без перекодирования нельзя.
Проблема в том, что lossy кодеки преобразуют обычное стерео во всякие там joint stereo, mix side stereo. Там нет отдельного потока данных для левого и правого каналов.
Есть один mp4 файл длительностью ~5 минут и весом около 400мб. Запись с камеры телефона. Как мне его сжать до 20мб сохранив при этом максимально возможное качество для данного размера? Во всех гайдах из шапки подробные гайды по всему функционалу ffmpeg, мне нет особого смысла изучать всё это если я просто хочу сжать один видос
Не по теме, но может знаете, как максимально удобно замазать в видео лица рандомных людей?
>>383098
5 минут на 20 мб это 559 kbps на весь поток.
Если без звука, то на видео все 559 и уйдут.
Если звук моно, то 559 - 32 = 527 kbps.
Если звук стерео, то 559 - 64 = 495 kbps.
Далее вопрос каким кодеком ты собираешься сжимать.
Выбор аудио кодека зависит от формата контейнера. Если webm, то просто выбирай libopus. Если MP4, то тебе надо кодировать в AAC.
А вот с кодеком AAC у ffmpeg всё сложно. ААС с профилем LC посредственно справляется с выбранными мной битрейтами (32 на моно, 64 на стерео). А ещё у дефолтного в ffmpeg AAC есть баги по психоакустике. Тебе нужен профиль HE-AAC, кодировать в который могут только qaac и fdk-aac.
Выбор видеокодека тоже зависит от контейнера. Если MP4, то libx264. А ещё пропиши "-vf scale=-2:360" (если видео горизонтальное, или "-vf scale=360:-2" если вертикальное). А ещё поставь "-preset veryslow" чтобы максимально сохранить качество. Можешь даже плацебо поставить, я разрешаю.
Если WEBM, то тебе надо выбирать между libvpx-vp9, libaom-av1, однопроходным libsvtav1 или через pipe загнать видеопоток в SvtAv1EncApp чтобы оно кодировало в 3 прохода. Но взамен ты можешь поднять разрешение до 480p.
Ты хотел готовый commandline. Я тебе дам 3, для случая когда звука нет, когда звук моно и когда звук стерео. Рассматривать я буду только WEBM/VP9. AV1 изучай сам.
Без звука:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 550k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 550k -cpu-used 4 -pass 2 -an output.webm
Моно:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 2 -ac 1 -c:a libopus -b:a 32k output.webm
Стерео:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 490k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 490k -cpu-used 4 -pass 2 -c:a libopus -b:a 64k output.webm
5 минут на 20 мб это 559 kbps на весь поток.
Если без звука, то на видео все 559 и уйдут.
Если звук моно, то 559 - 32 = 527 kbps.
Если звук стерео, то 559 - 64 = 495 kbps.
Далее вопрос каким кодеком ты собираешься сжимать.
Выбор аудио кодека зависит от формата контейнера. Если webm, то просто выбирай libopus. Если MP4, то тебе надо кодировать в AAC.
А вот с кодеком AAC у ffmpeg всё сложно. ААС с профилем LC посредственно справляется с выбранными мной битрейтами (32 на моно, 64 на стерео). А ещё у дефолтного в ffmpeg AAC есть баги по психоакустике. Тебе нужен профиль HE-AAC, кодировать в который могут только qaac и fdk-aac.
Выбор видеокодека тоже зависит от контейнера. Если MP4, то libx264. А ещё пропиши "-vf scale=-2:360" (если видео горизонтальное, или "-vf scale=360:-2" если вертикальное). А ещё поставь "-preset veryslow" чтобы максимально сохранить качество. Можешь даже плацебо поставить, я разрешаю.
Если WEBM, то тебе надо выбирать между libvpx-vp9, libaom-av1, однопроходным libsvtav1 или через pipe загнать видеопоток в SvtAv1EncApp чтобы оно кодировало в 3 прохода. Но взамен ты можешь поднять разрешение до 480p.
Ты хотел готовый commandline. Я тебе дам 3, для случая когда звука нет, когда звук моно и когда звук стерео. Рассматривать я буду только WEBM/VP9. AV1 изучай сам.
Без звука:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 550k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 550k -cpu-used 4 -pass 2 -an output.webm
Моно:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 2 -ac 1 -c:a libopus -b:a 32k output.webm
Стерео:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 490k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 490k -cpu-used 4 -pass 2 -c:a libopus -b:a 64k output.webm
>>383098
5 минут на 20 мб это 559 kbps на весь поток.
Если без звука, то на видео все 559 и уйдут.
Если звук моно, то 559 - 32 = 527 kbps.
Если звук стерео, то 559 - 64 = 495 kbps.
Далее вопрос каким кодеком ты собираешься сжимать.
Выбор аудио кодека зависит от формата контейнера. Если webm, то просто выбирай libopus. Если MP4, то тебе надо кодировать в AAC.
А вот с кодеком AAC у ffmpeg всё сложно. ААС с профилем LC посредственно справляется с выбранными мной битрейтами (32 на моно, 64 на стерео). А ещё у дефолтного в ffmpeg AAC есть баги по психоакустике. Тебе нужен профиль HE-AAC, кодировать в который могут только qaac и fdk-aac.
Выбор видеокодека тоже зависит от контейнера. Если MP4, то libx264. А ещё пропиши "-vf scale=-2:360" (если видео горизонтальное, или "-vf scale=360:-2" если вертикальное). А ещё поставь "-preset veryslow" чтобы максимально сохранить качество. Можешь даже плацебо поставить, я разрешаю.
Если WEBM, то тебе надо выбирать между libvpx-vp9, libaom-av1, однопроходным libsvtav1 или через pipe загнать видеопоток в SvtAv1EncApp чтобы оно кодировало в 3 прохода. Но взамен ты можешь поднять разрешение до 480p.
Ты хотел готовый commandline. Я тебе дам 3, для случая когда звука нет, когда звук моно и когда звук стерео. Рассматривать я буду только WEBM/VP9. AV1 изучай сам.
Без звука:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 550k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 550k -cpu-used 4 -pass 2 -an output.webm
Моно:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 2 -ac 1 -c:a libopus -b:a 32k output.webm
Стерео:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 490k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 490k -cpu-used 4 -pass 2 -c:a libopus -b:a 64k output.webm
5 минут на 20 мб это 559 kbps на весь поток.
Если без звука, то на видео все 559 и уйдут.
Если звук моно, то 559 - 32 = 527 kbps.
Если звук стерео, то 559 - 64 = 495 kbps.
Далее вопрос каким кодеком ты собираешься сжимать.
Выбор аудио кодека зависит от формата контейнера. Если webm, то просто выбирай libopus. Если MP4, то тебе надо кодировать в AAC.
А вот с кодеком AAC у ffmpeg всё сложно. ААС с профилем LC посредственно справляется с выбранными мной битрейтами (32 на моно, 64 на стерео). А ещё у дефолтного в ffmpeg AAC есть баги по психоакустике. Тебе нужен профиль HE-AAC, кодировать в который могут только qaac и fdk-aac.
Выбор видеокодека тоже зависит от контейнера. Если MP4, то libx264. А ещё пропиши "-vf scale=-2:360" (если видео горизонтальное, или "-vf scale=360:-2" если вертикальное). А ещё поставь "-preset veryslow" чтобы максимально сохранить качество. Можешь даже плацебо поставить, я разрешаю.
Если WEBM, то тебе надо выбирать между libvpx-vp9, libaom-av1, однопроходным libsvtav1 или через pipe загнать видеопоток в SvtAv1EncApp чтобы оно кодировало в 3 прохода. Но взамен ты можешь поднять разрешение до 480p.
Ты хотел готовый commandline. Я тебе дам 3, для случая когда звука нет, когда звук моно и когда звук стерео. Рассматривать я буду только WEBM/VP9. AV1 изучай сам.
Без звука:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 550k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 550k -cpu-used 4 -pass 2 -an output.webm
Моно:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 2 -ac 1 -c:a libopus -b:a 32k output.webm
Стерео:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 490k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 490k -cpu-used 4 -pass 2 -c:a libopus -b:a 64k output.webm
>>383167
Заебись, спасибо. Да, там без звука слава богу. Буду пробовать, а то я сколько не конвертил, качество в полном говне выходило
Заебись, спасибо. Да, там без звука слава богу. Буду пробовать, а то я сколько не конвертил, качество в полном говне выходило
>>383167
Молодца. Теперь всё правильно сказал. Горжусь тобой!
>А вот с кодеком AAC у ffmpeg всё сложно. ААС с профилем LC посредственно справляется с выбранными мной битрейтами (32 на моно, 64 на стерео). А ещё у дефолтного в ffmpeg AAC есть баги по психоакустике. Тебе нужен профиль HE-AAC, кодировать в который могут только qaac и fdk-aac.
Молодца. Теперь всё правильно сказал. Горжусь тобой!
Есть проблема с конвертацией в VLC. Собственно, пытаюсь снизить битрейт порнухи и на ПК все работает замечательно. Однако на мобильных устройствах первые 5-10 секунд видео тупо не показываются, не важно стримлю я его с пк или перекидываю на хранилище смартфона. Как эту хуйню фиксить? инб4 конвертировать через ffmpeg
>>383234
Давай рассуждать логически. Возможно, VLC куда-то теряет ключевой кадр в начале или пишет его в том формате, который декодер на устройстве (вероятно, аппаратный) не понимает. Это странно, но стоит проверить, какой профиль выбирается, какие размеры буферов и так далее, и сравнить с тем, что поддерживается на смартфоне.
Более вероятно, что у тебя выдаётся в MP4 голый поток пакетов аудио и видео, как при вещании по сети, а плеер просто несколько секунд пытается найти в файле каталог или хоть какие-то опорные точки, либо индексирует его от начала и до конца. Смотри, как выбрать файловый формат, содержащий метаданные о длине и индекс.
Давай рассуждать логически. Возможно, VLC куда-то теряет ключевой кадр в начале или пишет его в том формате, который декодер на устройстве (вероятно, аппаратный) не понимает. Это странно, но стоит проверить, какой профиль выбирается, какие размеры буферов и так далее, и сравнить с тем, что поддерживается на смартфоне.
Более вероятно, что у тебя выдаётся в MP4 голый поток пакетов аудио и видео, как при вещании по сети, а плеер просто несколько секунд пытается найти в файле каталог или хоть какие-то опорные точки, либо индексирует его от начала и до конца. Смотри, как выбрать файловый формат, содержащий метаданные о длине и индекс.
>>383823
Тебя забанировали. Это всё из-за адблок детекторов мать их.
Тебя забанировали. Это всё из-за адблок детекторов мать их.
11 Кб, 200x223>>383344
Ну я не стал ебаться со всем этим, закодировал в Handbrake с теми же настройками и проблема пропала.
Ну я не стал ебаться со всем этим, закодировал в Handbrake с теми же настройками и проблема пропала.
>>383823
Error 1337: wrong thread
Error 1337: wrong thread
Как заставить ффмпег без потери качества обрезать видос хотя бы с точностью до полусекунды? Вбиваю какие-нибудь 39 секунд - получается на 4!!! раньше чем надо. Вбиваю 40 - теперь на долю секунды ПОЗЖЕ!
>>384449
ffmpeg -i input.mp4 -force_key_frames 00:00:09,00:00:12 tmp.mp4
ffmpeg -i tmp.mp4 -ss 00:00:09 -t 00:00:03 -c:v copy -c:a copy out.mp4
ffmpeg -i input.mp4 -force_key_frames 00:00:09,00:00:12 tmp.mp4
ffmpeg -i tmp.mp4 -ss 00:00:09 -t 00:00:03 -c:v copy -c:a copy out.mp4
>>384456
Так и делою. Не попадает куда надо, нужно точно перед первым словом песни.
Пережимать заново начинает, хуйня какая-то. И так уже пережатое до квадратов.
> -ss 00:00:09 -t 00:00:03 -c:v copy -c:a copy out.mp4
Так и делою. Не попадает куда надо, нужно точно перед первым словом песни.
> ffmpeg -i input.mp4 -force_key_frames 00:00:09,00:00:12 tmp.mp4
Пережимать заново начинает, хуйня какая-то. И так уже пережатое до квадратов.
>>384671
Ключевые кадры независимые, остальные кадры зависят от них. Если ты без перекодирования режешь не по ключевому кадру, то все кадры от начала до ближайшего ключевого кадра сломаются, потому что они зависимы от отсутствующего ключевого кадра. Так что надо либо перекодировать, либо резать начало по ключевому кадру, а их расстановка зависит от настроек предыдущей итерации энкодирования.
Ключевые кадры независимые, остальные кадры зависят от них. Если ты без перекодирования режешь не по ключевому кадру, то все кадры от начала до ближайшего ключевого кадра сломаются, потому что они зависимы от отсутствующего ключевого кадра. Так что надо либо перекодировать, либо резать начало по ключевому кадру, а их расстановка зависит от настроек предыдущей итерации энкодирования.
>>384814
Почему нельзя перекодировать только начало и конец, а потом склеить с незатронутой серединой?
Почему нельзя перекодировать только начало и конец, а потом склеить с незатронутой серединой?
>>386124
Можно. Ты просто не знаешь, что прячется за словом «склеить».
https://superuser.com/questions/1644273/how-to-cut-video-in-multiple-place-and-combine-them-without-re-encoding-using-ff
Чтобы декодер не сошёл с ума, стыкуемые куски видео должны иметь не только одинаковое разрешение и прочие параметры и механизмы кодирования, но и использовать совпадающий интервал внутренних отметок времени, помещаться в заданный размер буфера, и так далее. При кодировании видео целиком кодировщик за всем этим следит. При кодировании куска видео следить за тем, что происходит в момент стыка, придётся тебе. Кроме того, синхронизацию аудио и видео надо настраивать так же, как в оригинале (но тут легче обрезать под финальную длину и разделить на отдельные дорожки, а потом собрать).
Фактически, ты должен понимать, из каких элементов состоит видео, закодированное в выбранном формате, и как оно хранится в выбранном контейнере, чтобы всё это проверить при склейке и указать правильные циферки.
Картинки в JPEG технически тоже можно пытаться сохранять только в отредактированных местах, чтобы не шакалить нетронутые блоки. Теперь попробуй найти графические редакторы, которые такое развлечение предлагают.
Можно. Ты просто не знаешь, что прячется за словом «склеить».
https://superuser.com/questions/1644273/how-to-cut-video-in-multiple-place-and-combine-them-without-re-encoding-using-ff
Чтобы декодер не сошёл с ума, стыкуемые куски видео должны иметь не только одинаковое разрешение и прочие параметры и механизмы кодирования, но и использовать совпадающий интервал внутренних отметок времени, помещаться в заданный размер буфера, и так далее. При кодировании видео целиком кодировщик за всем этим следит. При кодировании куска видео следить за тем, что происходит в момент стыка, придётся тебе. Кроме того, синхронизацию аудио и видео надо настраивать так же, как в оригинале (но тут легче обрезать под финальную длину и разделить на отдельные дорожки, а потом собрать).
Фактически, ты должен понимать, из каких элементов состоит видео, закодированное в выбранном формате, и как оно хранится в выбранном контейнере, чтобы всё это проверить при склейке и указать правильные циферки.
Картинки в JPEG технически тоже можно пытаться сохранять только в отредактированных местах, чтобы не шакалить нетронутые блоки. Теперь попробуй найти графические редакторы, которые такое развлечение предлагают.
>>384814
Разве любой видеокодек это не сжатие каждого кадра а-ля жпег? В мп3 ещё бы "ключевые фреймы" какие засунули, чтобы директкат не мог обрезать ровно.
Разве любой видеокодек это не сжатие каждого кадра а-ля жпег? В мп3 ещё бы "ключевые фреймы" какие засунули, чтобы директкат не мог обрезать ровно.
Кодек av1 теперь стандарт или нинужное говно? Очень давно не следил. Сабж так и кодирует в него со скоростью улитки, загружая 0.5 ядра из 1024?
>>386305
Как ты думаешь, почему это вдруг Apple в последний момент присоединилась к альянсу Open Media?
Очевидно же, что если бы AV1 был бы таким же говном как и его предшественники, ни Apple, ни Nvidia, ни AMD, ни Intel и шагу бы не сделали для аппаратной поддержки этих кодеков.
Как ты думаешь, почему это вдруг Apple в последний момент присоединилась к альянсу Open Media?
Очевидно же, что если бы AV1 был бы таким же говном как и его предшественники, ни Apple, ни Nvidia, ни AMD, ни Intel и шагу бы не сделали для аппаратной поддержки этих кодеков.
Я перекодирую mp3 файлы в mp3 файлы (не спрашивайте зачем) батником, и битрейт у файлов меняется. Какой параметр можно указать для -b:a, чтобы он брал значение из оригинального файла (там у всех либо 256, либо 320). Может существует какой-нибудь default параметр?
>>387440
Зачем?
Зачем?
>>387440
Не имеет смысла. Лучше просто перепакуй их в нужный контейнер при помощи -c copy.
Не имеет смысла. Лучше просто перепакуй их в нужный контейнер при помощи -c copy.
67 Кб, 978x1094Как ни старался закодировать из ремукса в AV1 - всё говно.
Использовал svt-av1 -preset 2, -crf 10, tune=0,scd=1,enable-overlays=1 и все равно картинка не дотягивает до простого рипа h264, который практически идентичен оригиналу до пикселя. Даже HEVC можно добиться такой картинки, если отключить sao, intra-smoothing и снизить crf. С libaom еще хуже качество вышло. AV1 удаляет много деталей, мылит, предлагает какие-то хаки с фейковым грейном на уровне декодера. Ну его нахуй, лучше использовать старый скуфский x264, который прослужил 20 лет и прослужит еще столько же. AV1 чисто сделан, чтобы занизить битрейт и нагрузку на сеть для больших компаний и смотреть на каком-нибудь телефоне или планшете. Даже не знаю, что там будет с VVC и AV2.
Использовал svt-av1 -preset 2, -crf 10, tune=0,scd=1,enable-overlays=1 и все равно картинка не дотягивает до простого рипа h264, который практически идентичен оригиналу до пикселя. Даже HEVC можно добиться такой картинки, если отключить sao, intra-smoothing и снизить crf. С libaom еще хуже качество вышло. AV1 удаляет много деталей, мылит, предлагает какие-то хаки с фейковым грейном на уровне декодера. Ну его нахуй, лучше использовать старый скуфский x264, который прослужил 20 лет и прослужит еще столько же. AV1 чисто сделан, чтобы занизить битрейт и нагрузку на сеть для больших компаний и смотреть на каком-нибудь телефоне или планшете. Даже не знаю, что там будет с VVC и AV2.
>>387689
Чё ты ноешь? Мы тут сжимаем AV1 чтобы битрейты уместить до 5 мегабит на Full HD. Для нас некритично если какая-то мелкозернистая деталька пропадёт в процессе сжатия. Всё равно в движении некогда их рассматривать.
Но если тебе важен pixel perfect и visually lossless, и ты готов тратить гигабайты чтобы всё это сохранить, то специально для тебя господа с торрент трекеров разработали методологию сжатия в x264. Короче, тебе даже сжимать ничего не надо, просто качай BDRip.
Чё ты ноешь? Мы тут сжимаем AV1 чтобы битрейты уместить до 5 мегабит на Full HD. Для нас некритично если какая-то мелкозернистая деталька пропадёт в процессе сжатия. Всё равно в движении некогда их рассматривать.
Но если тебе важен pixel perfect и visually lossless, и ты готов тратить гигабайты чтобы всё это сохранить, то специально для тебя господа с торрент трекеров разработали методологию сжатия в x264. Короче, тебе даже сжимать ничего не надо, просто качай BDRip.
>>387970
Так и сделал.
Так и сделал.
594 Кб, 600x483Вечер добрый. Мне нужно обрезать видео, сжать и иногда конвертировать в другой формат. Это просто сделать с помощью ffmpeg или подыскать что-нибудь другое?
>>387983
Можно и с помощью ананаса, если на кнопки любишь нажимать.
Можно и с помощью ананаса, если на кнопки любишь нажимать.
364 Кб, 1280x1308>>387983
Как же мне по нраву масонские символы: циркуль и наугольник, есть в них что-то тайное, великое, нашедшее отражение даже на официальной геральдике, вроде той же ДДР.
Как же мне по нраву масонские символы: циркуль и наугольник, есть в них что-то тайное, великое, нашедшее отражение даже на официальной геральдике, вроде той же ДДР.
>>387985
Работаю в шараге мухосранска на 20к рыл. Так там офф. символ этой шараги - циркуль с наугольником. Основана эта шарага, как полагается, жидом.
Работаю в шараге мухосранска на 20к рыл. Так там офф. символ этой шараги - циркуль с наугольником. Основана эта шарага, как полагается, жидом.
Фильм Зеленый Слоник Маяк, снят на плёнку, много зернистости, естественного освещения, темных кадров, всё как надо чтобы протестить AV1. И уже с первых минут он начинает серить под себя.
1. Исходник.
2. preset 2, crf 20 что уже считается оверкиллом для 1080p. Зернистость полностью пропадает, а её остатки превращаются в дерганные артефакты.
3. То же самое только с film-grain=20:film-grain-denoise=0, уже лучше, но если увеличивать grain, то начинает резать глаза и будет виден искусственный паттерн, как будто по экрану кто-то тряпкой водит.
1. Исходник.
2. preset 2, crf 20 что уже считается оверкиллом для 1080p. Зернистость полностью пропадает, а её остатки превращаются в дерганные артефакты.
3. То же самое только с film-grain=20:film-grain-denoise=0, уже лучше, но если увеличивать grain, то начинает резать глаза и будет виден искусственный паттерн, как будто по экрану кто-то тряпкой водит.
>>388000
Ну основал и основал, деньги платит, рабочим местом обеспечиват.
Ну основал и основал, деньги платит, рабочим местом обеспечиват.
>>386302
Нет. Есть кодеры без компенсации и поиска движения. Самые растространëнные бытовые из них — это mjpeg и dv. Но они всем классом уже лет двадцать как сданы в утиль — не выдержали конкуренции. Из современных вариантов того же класса в живых остался только DCP — один из вариантов применения контейнера MXF с несжатым звуком (PCM) и последовательностью отдельных кадров изображения, сжатых jpeg2000. Применяется DCP, чтобы доставлять фильмы в imax-кинотеатры.
mpeg layer 3 поток можно разделять тоже не «ровно», а по кадрам. В кадре mpeg layer 3 помещается 1152 отсчëта.
Добро пожаловать в реальный мир!
>Разве любой видеокодек это не сжатие каждого кадра а-ля жпег?
Нет. Есть кодеры без компенсации и поиска движения. Самые растространëнные бытовые из них — это mjpeg и dv. Но они всем классом уже лет двадцать как сданы в утиль — не выдержали конкуренции. Из современных вариантов того же класса в живых остался только DCP — один из вариантов применения контейнера MXF с несжатым звуком (PCM) и последовательностью отдельных кадров изображения, сжатых jpeg2000. Применяется DCP, чтобы доставлять фильмы в imax-кинотеатры.
>В мп3 ещё бы "ключевые фреймы" какие засунули, чтобы директкат не мог обрезать ровно.
mpeg layer 3 поток можно разделять тоже не «ровно», а по кадрам. В кадре mpeg layer 3 помещается 1152 отсчëта.
Добро пожаловать в реальный мир!
>>383167
Это в шапку надо спасибо
тут немного не понял поясни пожалуста
какое различие принципиальное однопроходный быстрее?
Это в шапку надо спасибо
> pipe загнать видеопоток в SvtAv1EncApp чтобы оно кодировало в 3 прохода.
тут немного не понял поясни пожалуста
> между libvpx-vp9, libaom-av1, однопроходным libsvtav1
какое различие принципиальное однопроходный быстрее?
63 Кб, 1079x258>>381499
будь добр помоги поебаться скачал пакет отсюда https://github.com/tanersener/mobile-ffmpeg
В термуксе написал сначало pkg update
Затем pkg install ffmpeg выдало пик
нужно разархивировать или куда? Как первый раз залез в эти блудни
будь добр помоги поебаться скачал пакет отсюда https://github.com/tanersener/mobile-ffmpeg
В термуксе написал сначало pkg update
Затем pkg install ffmpeg выдало пик
нужно разархивировать или куда? Как первый раз залез в эти блудни
>>388872
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Ffmpeg.md#piping-from-ffmpeg-into-the-standalone-encoder
Да, но он не может адекватно распределить битрейт по времени.
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Ffmpeg.md#piping-from-ffmpeg-into-the-standalone-encoder
> какое различие принципиальное однопроходный быстрее?
Да, но он не может адекватно распределить битрейт по времени.
mediainfo показывает какой-то булшит вместо битрейта.
Кодирую hevc_nvenc с заданием качества через "-cq:v", в консоле пишется битрейт, которому я склонен доверять, ибо он блять меняется в зависимости от значения cq.
А в mediainfo все время какой-то сильно завышенный битрейт, причем он почти не меняется при измеении cq.
Что это за хуйня?
Кодирую hevc_nvenc с заданием качества через "-cq:v", в консоле пишется битрейт, которому я склонен доверять, ибо он блять меняется в зависимости от значения cq.
А в mediainfo все время какой-то сильно завышенный битрейт, причем он почти не меняется при измеении cq.
Что это за хуйня?
>>389742
Очевидно, битрейт одного потока не может превышать битрейт всех потоков целиком, написанного выше (или просто получаемого делением размера файла на продолжительность).
Дело в том, что форматы контейнеров в общем случае никак не взаимодействуют с потоками с переменным битрейтом. (Хотя могут иметь индекс опорных точек, по которым можно догадаться, в районе какого примерно смещения находится нужный элемент. В потоках с постоянным битрейтом все элементы одного размера, так что при декодировании можно просто вслепую поделить пропорционально объём файла и начать искать в окрестностях полученного адреса начало кадра. Это конечно, технология девяностых годов и годится разве что для AVI.) Кроме того, большинство кодеков выдаёт формат потока, ориентированный на вещание по сети или в эфире (а не исключительно на чтение из файла с произвольным доступом), и поэтому делит его на множество независимо декодируемых элементов, чтобы начать это делать можно было в любой момент (с незаметной на практике задержкой). В результате, чтобы вычислить какие-то характеристики всего потока (например, средний битрейт), его требуется просканировать от начала до конца, обработав каждый. Именно поэтому для видеопотока MediaInfo часто не показывает битрейт или размер данных: таких метаданных в файле просто нет, а для их вычисления требуется прочесть весь файл, что чаще всего совсем не нужно пользователю.
В твоём случае может быть два варианта:
— Это поле на практике можно (или рекомендуется) использовать для того, чтобы сообщить декодеру, какой пиковый объём данных может к нему попасть, чтобы тот заранее выделил себе нужный объём памяти. Тогда ошибка в названии, и следует писать «максимальный битрейт».
— MediaInfo берёт значения первого элемента или нескольких, и дальше в файл не смотрит. Вероятно, количество информации там отличается в большую (ключевой кадр и обилие движения заставки) или меньшую (просто чёрный экран) сторону от среднего.
Точно то же самое было при появлении VBR MP3, многие программы показывали битрейт только первого фрейма или неправильно считали какие-то другие цифры. Там пришли к нестандартному хаку, когда дополнительная информация о потоке внедряется прямо в аудио в виде фрейма, не влияющего на воспроизведение.
Очевидно, битрейт одного потока не может превышать битрейт всех потоков целиком, написанного выше (или просто получаемого делением размера файла на продолжительность).
Дело в том, что форматы контейнеров в общем случае никак не взаимодействуют с потоками с переменным битрейтом. (Хотя могут иметь индекс опорных точек, по которым можно догадаться, в районе какого примерно смещения находится нужный элемент. В потоках с постоянным битрейтом все элементы одного размера, так что при декодировании можно просто вслепую поделить пропорционально объём файла и начать искать в окрестностях полученного адреса начало кадра. Это конечно, технология девяностых годов и годится разве что для AVI.) Кроме того, большинство кодеков выдаёт формат потока, ориентированный на вещание по сети или в эфире (а не исключительно на чтение из файла с произвольным доступом), и поэтому делит его на множество независимо декодируемых элементов, чтобы начать это делать можно было в любой момент (с незаметной на практике задержкой). В результате, чтобы вычислить какие-то характеристики всего потока (например, средний битрейт), его требуется просканировать от начала до конца, обработав каждый. Именно поэтому для видеопотока MediaInfo часто не показывает битрейт или размер данных: таких метаданных в файле просто нет, а для их вычисления требуется прочесть весь файл, что чаще всего совсем не нужно пользователю.
В твоём случае может быть два варианта:
— Это поле на практике можно (или рекомендуется) использовать для того, чтобы сообщить декодеру, какой пиковый объём данных может к нему попасть, чтобы тот заранее выделил себе нужный объём памяти. Тогда ошибка в названии, и следует писать «максимальный битрейт».
— MediaInfo берёт значения первого элемента или нескольких, и дальше в файл не смотрит. Вероятно, количество информации там отличается в большую (ключевой кадр и обилие движения заставки) или меньшую (просто чёрный экран) сторону от среднего.
Точно то же самое было при появлении VBR MP3, многие программы показывали битрейт только первого фрейма или неправильно считали какие-то другие цифры. Там пришли к нестандартному хаку, когда дополнительная информация о потоке внедряется прямо в аудио в виде фрейма, не влияющего на воспроизведение.
>>389742
Очевидно, битрейт одного потока не может превышать битрейт всех потоков целиком, написанного выше (или просто получаемого делением размера файла на продолжительность).
Дело в том, что форматы контейнеров в общем случае никак не взаимодействуют с потоками с переменным битрейтом. (Хотя могут иметь индекс опорных точек, по которым можно догадаться, в районе какого примерно смещения находится нужный элемент. В потоках с постоянным битрейтом все элементы одного размера, так что при декодировании можно просто вслепую поделить пропорционально объём файла и начать искать в окрестностях полученного адреса начало кадра. Это конечно, технология девяностых годов и годится разве что для AVI.) Кроме того, большинство кодеков выдаёт формат потока, ориентированный на вещание по сети или в эфире (а не исключительно на чтение из файла с произвольным доступом), и поэтому делит его на множество независимо декодируемых элементов, чтобы начать это делать можно было в любой момент (с незаметной на практике задержкой). В результате, чтобы вычислить какие-то характеристики всего потока (например, средний битрейт), его требуется просканировать от начала до конца, обработав каждый. Именно поэтому для видеопотока MediaInfo часто не показывает битрейт или размер данных: таких метаданных в файле просто нет, а для их вычисления требуется прочесть весь файл, что чаще всего совсем не нужно пользователю.
В твоём случае может быть два варианта:
— Это поле на практике можно (или рекомендуется) использовать для того, чтобы сообщить декодеру, какой пиковый объём данных может к нему попасть, чтобы тот заранее выделил себе нужный объём памяти. Тогда ошибка в названии, и следует писать «максимальный битрейт».
— MediaInfo берёт значения первого элемента или нескольких, и дальше в файл не смотрит. Вероятно, количество информации там отличается в большую (ключевой кадр и обилие движения заставки) или меньшую (просто чёрный экран) сторону от среднего.
Точно то же самое было при появлении VBR MP3, многие программы показывали битрейт только первого фрейма или неправильно считали какие-то другие цифры. Там пришли к нестандартному хаку, когда дополнительная информация о потоке внедряется прямо в аудио в виде фрейма, не влияющего на воспроизведение.
Очевидно, битрейт одного потока не может превышать битрейт всех потоков целиком, написанного выше (или просто получаемого делением размера файла на продолжительность).
Дело в том, что форматы контейнеров в общем случае никак не взаимодействуют с потоками с переменным битрейтом. (Хотя могут иметь индекс опорных точек, по которым можно догадаться, в районе какого примерно смещения находится нужный элемент. В потоках с постоянным битрейтом все элементы одного размера, так что при декодировании можно просто вслепую поделить пропорционально объём файла и начать искать в окрестностях полученного адреса начало кадра. Это конечно, технология девяностых годов и годится разве что для AVI.) Кроме того, большинство кодеков выдаёт формат потока, ориентированный на вещание по сети или в эфире (а не исключительно на чтение из файла с произвольным доступом), и поэтому делит его на множество независимо декодируемых элементов, чтобы начать это делать можно было в любой момент (с незаметной на практике задержкой). В результате, чтобы вычислить какие-то характеристики всего потока (например, средний битрейт), его требуется просканировать от начала до конца, обработав каждый. Именно поэтому для видеопотока MediaInfo часто не показывает битрейт или размер данных: таких метаданных в файле просто нет, а для их вычисления требуется прочесть весь файл, что чаще всего совсем не нужно пользователю.
В твоём случае может быть два варианта:
— Это поле на практике можно (или рекомендуется) использовать для того, чтобы сообщить декодеру, какой пиковый объём данных может к нему попасть, чтобы тот заранее выделил себе нужный объём памяти. Тогда ошибка в названии, и следует писать «максимальный битрейт».
— MediaInfo берёт значения первого элемента или нескольких, и дальше в файл не смотрит. Вероятно, количество информации там отличается в большую (ключевой кадр и обилие движения заставки) или меньшую (просто чёрный экран) сторону от среднего.
Точно то же самое было при появлении VBR MP3, многие программы показывали битрейт только первого фрейма или неправильно считали какие-то другие цифры. Там пришли к нестандартному хаку, когда дополнительная информация о потоке внедряется прямо в аудио в виде фрейма, не влияющего на воспроизведение.
14 Кб, 220x227>>383167
И как ты это расчитал кстати? Помню формула была какая-то
> 5 минут на 20 мб это 559 kbps на весь поток.
И как ты это расчитал кстати? Помню формула была какая-то
>>390464
20 x 2^20 x 8 / (5 x 60) / 1000
20 x 2^20 x 8 / (5 x 60) / 1000
>>390464
1 Мегабайт это 1024 Килобайта
1 Килобайт это 1024 байта.
1 байт это 8 бит.
1 килобит это 1000 бит.
(20102410248)/1000 = 167772.16 килобит.
1 минута это 60 секунд.
167772.16 / (560) = 559,24 килобит в секунду.
1 Мегабайт это 1024 Килобайта
1 Килобайт это 1024 байта.
1 байт это 8 бит.
1 килобит это 1000 бит.
(20102410248)/1000 = 167772.16 килобит.
1 минута это 60 секунд.
167772.16 / (560) = 559,24 килобит в секунду.
>>390464
У меня поплыла разметка, поэтому пощу заново.
1 Мегабайт это 1024 Килобайта
1 Килобайт это 1024 байта.
1 байт это 8 бит.
1 килобит это 1000 бит.
(20 1024 1024 8) / 1000 = 167772.16 килобит.
1 минута это 60 секунд.
167772.16 / (5 60) = 559,24 килобит в секунду.
У меня поплыла разметка, поэтому пощу заново.
1 Мегабайт это 1024 Килобайта
1 Килобайт это 1024 байта.
1 байт это 8 бит.
1 килобит это 1000 бит.
(20 1024 1024 8) / 1000 = 167772.16 килобит.
1 минута это 60 секунд.
167772.16 / (5 60) = 559,24 килобит в секунду.
>>390464
Как же мне надоела эта разметка.
(20 х 1024 х 1024 х 8) / 1000 = 167772.16 килобит.
167772.16 / (5 х 60) = 559,24 килобит в секунду.
Как же мне надоела эта разметка.
(20 х 1024 х 1024 х 8) / 1000 = 167772.16 килобит.
167772.16 / (5 х 60) = 559,24 килобит в секунду.
>>390791
Да, видео не перекодировано. Аудио в основном тоже, по возможности, как минимум в оригинале и официальных дубляжах. В одном контейнере может быть собрано много разных озвучек и субтитров.
Да, видео не перекодировано. Аудио в основном тоже, по возможности, как минимум в оригинале и официальных дубляжах. В одном контейнере может быть собрано много разных озвучек и субтитров.
61 Кб, 615x322>>390769
Это уже нюансы. Но если тебе интересно подушнить, давай подушним.
Есть кило-/мега-/гига-/тера- байты. А есть киби-/меби-/гиби-/теби- байты.
На самом деле килобайт соответствует православным 1000 байт. А Кибибайты соответствуют как раз таки 1024 байтам. И так далее.
Причина по которой я не использовал название приставок МЭК в посте в том что я их не помню наизусть, и без википедии и не вспомнил бы. А ещё так не модно. Корпорация Microsoft ввела моду в своей винде называть кибибайты килобайтами, и так оно в массы и пошло.
Это уже нюансы. Но если тебе интересно подушнить, давай подушним.
Есть кило-/мега-/гига-/тера- байты. А есть киби-/меби-/гиби-/теби- байты.
На самом деле килобайт соответствует православным 1000 байт. А Кибибайты соответствуют как раз таки 1024 байтам. И так далее.
Причина по которой я не использовал название приставок МЭК в посте в том что я их не помню наизусть, и без википедии и не вспомнил бы. А ещё так не модно. Корпорация Microsoft ввела моду в своей винде называть кибибайты килобайтами, и так оно в массы и пошло.
>>390850
А само видео блюрей в каком формате идет? Разве видео не зашифровано, чтобы не копировали?
А само видео блюрей в каком формате идет? Разве видео не зашифровано, чтобы не копировали?
>>390866
Так ключи декодирования можно спереть из лицензионных программ и устройств при желании. Ты не в курсе, что в интернете существует большая открытая энциклопедия?
https://en.wikipedia.org/wiki/Blu-ray#Digital_rights_management
https://en.wikipedia.org/wiki/Advanced_Access_Content_System
Так ключи декодирования можно спереть из лицензионных программ и устройств при желании. Ты не в курсе, что в интернете существует большая открытая энциклопедия?
https://en.wikipedia.org/wiki/Blu-ray#Digital_rights_management
https://en.wikipedia.org/wiki/Advanced_Access_Content_System
>>390855
Майкрософт тут не при чём. Мебибайты были удобны погромистам, потому что кратны степеням двойки. Мегабайты/мегабиты были удобны телекомщикам, потому что кратны мегагерцам. Универсальной единицы нет.
То ли телекомщики оказались весомее, то ли в те времена считать передачу данных была важнее, чем хранение, но прижились именно десятичные приставки. Битрейт, кстати, чисто телекомовский термин, там десятичные килобитывсеки.
>Корпорация Microsoft
Майкрософт тут не при чём. Мебибайты были удобны погромистам, потому что кратны степеням двойки. Мегабайты/мегабиты были удобны телекомщикам, потому что кратны мегагерцам. Универсальной единицы нет.
То ли телекомщики оказались весомее, то ли в те времена считать передачу данных была важнее, чем хранение, но прижились именно десятичные приставки. Битрейт, кстати, чисто телекомовский термин, там десятичные килобитывсеки.
Какой ублюдок эти опции придумывал? Это блять нереально без постоянного курения документации использовать.
>>391094
Примерно так. У меня для того, чтобы не лезть в документацию каждый раз есть
$ history | grep "^ffmpeg"
Документация должна быть под рукой, да, но и запомнить то, что не шпаргалке, нетрудно — но, конкретно в моëм случае, лишено смысла.
>Это блять нереально без постоянного курения документации использовать
Примерно так. У меня для того, чтобы не лезть в документацию каждый раз есть
$ history | grep "^ffmpeg"
Документация должна быть под рукой, да, но и запомнить то, что не шпаргалке, нетрудно — но, конкретно в моëм случае, лишено смысла.
>>391145
Посмотри на раздачи DVD-дисков, там просто копируют содержимое VIDEO_TS целиком. Другое дело, что MPEG2 далеко не новый кодек, и тот же уровень качества можно достичь при меньшем объёме, закодировав современным. Другое дело, что некоторые видео настолько плохи, что лучше их вообще не пережимать, чтобы не портить дальше, поэтому они хранятся как есть.
Там аналоговый сигнал, алло.
Впрочем, как с лазердисков оцифровывают читаемый сигнал прямо с датчика с большим запасом при помощи Domesday Duplicator, а потом декодируют картинку программно ld-decode (а не аналоговой схемой в проигрывателе), так и для кассет есть vhs-decode. Для профессионально записанных кассет получается очень хорошо:
https://odysee.com/@therewinding:4/wdw-epcot-center-souvenir-program-1983:b
Только надо помнить, что шум на изображении — фикция, артефакт формата хранения, а не часть оригинала. Если его убрать, видео станет более замыленным (и более соответствующим тому, что показывали реальные телевизоры), но тогда мы потеряем часть реальных данных, прячущихся в шуме.
В YouTube-телевизоре популярный видеоблогер как раз видео выпустил на эту тему.
> dvdremux
Посмотри на раздачи DVD-дисков, там просто копируют содержимое VIDEO_TS целиком. Другое дело, что MPEG2 далеко не новый кодек, и тот же уровень качества можно достичь при меньшем объёме, закодировав современным. Другое дело, что некоторые видео настолько плохи, что лучше их вообще не пережимать, чтобы не портить дальше, поэтому они хранятся как есть.
> vhsremux
Там аналоговый сигнал, алло.
Впрочем, как с лазердисков оцифровывают читаемый сигнал прямо с датчика с большим запасом при помощи Domesday Duplicator, а потом декодируют картинку программно ld-decode (а не аналоговой схемой в проигрывателе), так и для кассет есть vhs-decode. Для профессионально записанных кассет получается очень хорошо:
https://odysee.com/@therewinding:4/wdw-epcot-center-souvenir-program-1983:b
Только надо помнить, что шум на изображении — фикция, артефакт формата хранения, а не часть оригинала. Если его убрать, видео станет более замыленным (и более соответствующим тому, что показывали реальные телевизоры), но тогда мы потеряем часть реальных данных, прячущихся в шуме.
В YouTube-телевизоре популярный видеоблогер как раз видео выпустил на эту тему.
>>391390
Рад за них. Речь про удобный контейнер же, а не портянка с диска, которую хуй знает как проигрывать.
Удалить там мусор всякий, меню. Разве не то же самое и в бдремукс делают?
При любой перекодировке качество падает. Хочу оставить видео как есть.
VHS оцифровывают. Судя по гайдам c digitalfaq, для максимального качества используют профессиональный видеомаг. с внутренним TBC + внешний TBC + особая карта захвата и комп под winxp для нее, видео идеальное, без помех. Видео весит как блюрейник. Стоит билд несколько тысяч баксов. Конечно качество видео также зависит от состояния видика и кассеты.
Но я имел ввиду цифровые кассеты, с которых по идее можно просто скопировать файлы.
>Посмотри на раздачи DVD-дисков, там просто копируют содержимое VIDEO_TS целиком
Рад за них. Речь про удобный контейнер же, а не портянка с диска, которую хуй знает как проигрывать.
Удалить там мусор всякий, меню. Разве не то же самое и в бдремукс делают?
> закодировав современным
При любой перекодировке качество падает. Хочу оставить видео как есть.
>vhs-decode
VHS оцифровывают. Судя по гайдам c digitalfaq, для максимального качества используют профессиональный видеомаг. с внутренним TBC + внешний TBC + особая карта захвата и комп под winxp для нее, видео идеальное, без помех. Видео весит как блюрейник. Стоит билд несколько тысяч баксов. Конечно качество видео также зависит от состояния видика и кассеты.
Но я имел ввиду цифровые кассеты, с которых по идее можно просто скопировать файлы.
>>391427
DV или какой-либо аналогичный формат. Подключают камкодер с кассетой через 1394 или usb. Дальше варианты — на прыщах есть dvgrab. У последнего на выходе либо raw, который ffmpeg, вроде бы, разбирает, либо avi с dv и звуком pcm. avi такой есть почти любой редактор. Но dv - это штуковина уровня mjpeg: предсказания и компенсации движения нет, компрессия около 5:1. Ширина потока данных ограничена у dv жëстко. Съëмка с высоты роста человека превратит лужайку травы в месиво из блоков.
>цифровые кассеты, с которых по идее можно просто скопировать файлы.
DV или какой-либо аналогичный формат. Подключают камкодер с кассетой через 1394 или usb. Дальше варианты — на прыщах есть dvgrab. У последнего на выходе либо raw, который ffmpeg, вроде бы, разбирает, либо avi с dv и звуком pcm. avi такой есть почти любой редактор. Но dv - это штуковина уровня mjpeg: предсказания и компенсации движения нет, компрессия около 5:1. Ширина потока данных ограничена у dv жëстко. Съëмка с высоты роста человека превратит лужайку травы в месиво из блоков.
>>391427
Там, говорят, техника дошла уже до того, чтобы краткие содержания генерировать. Фильм, следовательно, сам становится «мусором», его можно и не смотреть.
20 лет назад, действительно, могло быть сложно обычному пользователю DVD-диск воспроизвести, если он не в реальном или виртуальном приводе. Ну и объём по тогдашним временам был ого-го. С тех пор много воды утекло, попробуй более свежие версии программ.
Мощное заявление. Вот я использую кодирование без потерь, «качество» упало? Нет, это буквально те же самые данные. Вот я использую кодирование с потерями, «качество» упало? Нет, если настройки таковы, что визуально средний (вариант: самый придирчивый) человек отличий не заметит. Вся индустрия кодирования с потерями стоит на том, что человек не является идеально воспринимающим механизмом, а ты тут шатаешь основания.
Просто если на картинке каша из макроблоков, то кодировать их (без обработки), задирая битрейт, нет никакого смысла.
Ну так запихни нужную дорожку в любой другой контейнер, вот тебе и ремукс. Только особых преимуществ по сравнению с копированием диска нет.
О, потёк аудиофильский эякулят. «Такого больше не делают», «специалисты высшей пробы», «уникальный экземпляр, повторить невозможно».
Я уже назвал проект, в котором никаких секретов нет, просто АЦП (недешёвый, с частотой и разрядностью дискретизации, достаточной для работы с сигналом прямо с датчика) и дальнейший разбор в цифре с любой необходимой точностью и любыми методиками интерпретации.
Если ты про DV, то по FireWire это делается чуть ли не встроенными в ОС средствами. Есть и специальные программы, которые реагируют на ошибочные блоки и несколько раз пытаются прочесть нужные места. Принцип тот же самый, что и в ddrescue, поскольку это тоже цифровое устройство хранения данных.
https://www.youtube.com/watch?v=YGPIqJ4_ssI
> мусор всякий, меню
Там, говорят, техника дошла уже до того, чтобы краткие содержания генерировать. Фильм, следовательно, сам становится «мусором», его можно и не смотреть.
> хуй знает как проигрывать
20 лет назад, действительно, могло быть сложно обычному пользователю DVD-диск воспроизвести, если он не в реальном или виртуальном приводе. Ну и объём по тогдашним временам был ого-го. С тех пор много воды утекло, попробуй более свежие версии программ.
> При любой перекодировке качество падает.
Мощное заявление. Вот я использую кодирование без потерь, «качество» упало? Нет, это буквально те же самые данные. Вот я использую кодирование с потерями, «качество» упало? Нет, если настройки таковы, что визуально средний (вариант: самый придирчивый) человек отличий не заметит. Вся индустрия кодирования с потерями стоит на том, что человек не является идеально воспринимающим механизмом, а ты тут шатаешь основания.
Просто если на картинке каша из макроблоков, то кодировать их (без обработки), задирая битрейт, нет никакого смысла.
> Хочу оставить видео как есть.
Ну так запихни нужную дорожку в любой другой контейнер, вот тебе и ремукс. Только особых преимуществ по сравнению с копированием диска нет.
> особая карта захвата и комп под winxp для нее
О, потёк аудиофильский эякулят. «Такого больше не делают», «специалисты высшей пробы», «уникальный экземпляр, повторить невозможно».
Я уже назвал проект, в котором никаких секретов нет, просто АЦП (недешёвый, с частотой и разрядностью дискретизации, достаточной для работы с сигналом прямо с датчика) и дальнейший разбор в цифре с любой необходимой точностью и любыми методиками интерпретации.
> Но я имел ввиду цифровые кассеты, с которых по идее можно просто скопировать файлы.
Если ты про DV, то по FireWire это делается чуть ли не встроенными в ОС средствами. Есть и специальные программы, которые реагируют на ошибочные блоки и несколько раз пытаются прочесть нужные места. Принцип тот же самый, что и в ddrescue, поскольку это тоже цифровое устройство хранения данных.
https://www.youtube.com/watch?v=YGPIqJ4_ssI
>>391427
Там, говорят, техника дошла уже до того, чтобы краткие содержания генерировать. Фильм, следовательно, сам становится «мусором», его можно и не смотреть.
20 лет назад, действительно, могло быть сложно обычному пользователю DVD-диск воспроизвести, если он не в реальном или виртуальном приводе. Ну и объём по тогдашним временам был ого-го. С тех пор много воды утекло, попробуй более свежие версии программ.
Мощное заявление. Вот я использую кодирование без потерь, «качество» упало? Нет, это буквально те же самые данные. Вот я использую кодирование с потерями, «качество» упало? Нет, если настройки таковы, что визуально средний (вариант: самый придирчивый) человек отличий не заметит. Вся индустрия кодирования с потерями стоит на том, что человек не является идеально воспринимающим механизмом, а ты тут шатаешь основания.
Просто если на картинке каша из макроблоков, то кодировать их (без обработки), задирая битрейт, нет никакого смысла.
Ну так запихни нужную дорожку в любой другой контейнер, вот тебе и ремукс. Только особых преимуществ по сравнению с копированием диска нет.
О, потёк аудиофильский эякулят. «Такого больше не делают», «специалисты высшей пробы», «уникальный экземпляр, повторить невозможно».
Я уже назвал проект, в котором никаких секретов нет, просто АЦП (недешёвый, с частотой и разрядностью дискретизации, достаточной для работы с сигналом прямо с датчика) и дальнейший разбор в цифре с любой необходимой точностью и любыми методиками интерпретации.
Если ты про DV, то по FireWire это делается чуть ли не встроенными в ОС средствами. Есть и специальные программы, которые реагируют на ошибочные блоки и несколько раз пытаются прочесть нужные места. Принцип тот же самый, что и в ddrescue, поскольку это тоже цифровое устройство хранения данных.
https://www.youtube.com/watch?v=YGPIqJ4_ssI
> мусор всякий, меню
Там, говорят, техника дошла уже до того, чтобы краткие содержания генерировать. Фильм, следовательно, сам становится «мусором», его можно и не смотреть.
> хуй знает как проигрывать
20 лет назад, действительно, могло быть сложно обычному пользователю DVD-диск воспроизвести, если он не в реальном или виртуальном приводе. Ну и объём по тогдашним временам был ого-го. С тех пор много воды утекло, попробуй более свежие версии программ.
> При любой перекодировке качество падает.
Мощное заявление. Вот я использую кодирование без потерь, «качество» упало? Нет, это буквально те же самые данные. Вот я использую кодирование с потерями, «качество» упало? Нет, если настройки таковы, что визуально средний (вариант: самый придирчивый) человек отличий не заметит. Вся индустрия кодирования с потерями стоит на том, что человек не является идеально воспринимающим механизмом, а ты тут шатаешь основания.
Просто если на картинке каша из макроблоков, то кодировать их (без обработки), задирая битрейт, нет никакого смысла.
> Хочу оставить видео как есть.
Ну так запихни нужную дорожку в любой другой контейнер, вот тебе и ремукс. Только особых преимуществ по сравнению с копированием диска нет.
> особая карта захвата и комп под winxp для нее
О, потёк аудиофильский эякулят. «Такого больше не делают», «специалисты высшей пробы», «уникальный экземпляр, повторить невозможно».
Я уже назвал проект, в котором никаких секретов нет, просто АЦП (недешёвый, с частотой и разрядностью дискретизации, достаточной для работы с сигналом прямо с датчика) и дальнейший разбор в цифре с любой необходимой точностью и любыми методиками интерпретации.
> Но я имел ввиду цифровые кассеты, с которых по идее можно просто скопировать файлы.
Если ты про DV, то по FireWire это делается чуть ли не встроенными в ОС средствами. Есть и специальные программы, которые реагируют на ошибочные блоки и несколько раз пытаются прочесть нужные места. Принцип тот же самый, что и в ddrescue, поскольку это тоже цифровое устройство хранения данных.
https://www.youtube.com/watch?v=YGPIqJ4_ssI
64 Кб, 1121x803Написал скриптец для управления перекодировкой папок с видео.
Обнаружил забавную хуйню, что можно вычислить примерный размер будущего видео еще на ранних стадиях кодирования.
Даже если битрейт переменный, он все равно в рамках файла примерно одинаковый.
Обнаружил забавную хуйню, что можно вычислить примерный размер будущего видео еще на ранних стадиях кодирования.
Даже если битрейт переменный, он все равно в рамках файла примерно одинаковый.
>>391552
-vcodec copy
Главное чтобы там уже было что-то совместимое с матрёшкой. А то есть тут неподалёку индивидуумы, которые хевк в мп4 пихают и жалуются что половина браузеров не открывает это говно.
-vcodec copy
Главное чтобы там уже было что-то совместимое с матрёшкой. А то есть тут неподалёку индивидуумы, которые хевк в мп4 пихают и жалуются что половина браузеров не открывает это говно.
>>391554
разве мкв это контейнер, в который можно что угодно запихнуть?
разве мкв это контейнер, в который можно что угодно запихнуть?
>>391554
Назови мне браузер, который поддерживает hevc, но не открывает hevc в mp4.
Назови мне браузер, который поддерживает hevc, но не открывает hevc в mp4.
34 Кб, 900x192>>365343 (OP)
Я слишком тупой или это и правда бессмысленный набор символов? Как из этого понять, какой битрейт мне нужен для того, чтобы получить файл 25 МБ продолжительностью 11 секунд?
Я слишком тупой или это и правда бессмысленный набор символов? Как из этого понять, какой битрейт мне нужен для того, чтобы получить файл 25 МБ продолжительностью 11 секунд?
>>391832
В байте 8 бит. В кило-хрени 1000 хреней (или 1024, если используются бинарные префиксы). В мега-хрени 1000×1000 хреней (или 1024×1024). Можно не гадать, как округлять, а написать точное значение в битах в секунду. Потом вычитаешь из общего битрейта на весь файл битрейт аудио, остаток остаётся для видео.
Метры в километры и мили переводить умеешь?
В байте 8 бит. В кило-хрени 1000 хреней (или 1024, если используются бинарные префиксы). В мега-хрени 1000×1000 хреней (или 1024×1024). Можно не гадать, как округлять, а написать точное значение в битах в секунду. Потом вычитаешь из общего битрейта на весь файл битрейт аудио, остаток остаётся для видео.
Метры в километры и мили переводить умеешь?
>>391835
И правда, ларчик просто открывался. Спасибо.
И правда, ларчик просто открывался. Спасибо.
ffmpeg не убирает метаданные из файла через -map_metadata -1, а также не убирает главы через -map_metadata -1
ffmpeg -ss 0.0 -i input -map_metadata -1 -map_chapters -1 -c:a copy -to 406.0 output
ffmpeg -ss 0.0 -i input -map_metadata -1 -map_chapters -1 -c:a copy -to 406.0 output
>>391964
Это рядом с -map_metadata -1 ДО настроек кодировщика: -map_chapters -1
Это в конце перед указанием выходного файла:
-movflags disable_chpl
Причина: главы пишутся в 2 разных форматах, второй - для пидорасов на эппле, пиздец просто.
>не убирает главы
Это рядом с -map_metadata -1 ДО настроек кодировщика: -map_chapters -1
Это в конце перед указанием выходного файла:
-movflags disable_chpl
Причина: главы пишутся в 2 разных форматах, второй - для пидорасов на эппле, пиздец просто.
298 Кб, 1071x1009>>383167
Делал по этому подогнал формулу под своего видео, ффмпег просто встал ничего делает чяндт
> Моно:
> ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 1 -an -f null /dev/null && \
> ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 2 -ac 1 -c:a libopus -b:a 32k output.webm
Делал по этому подогнал формулу под своего видео, ффмпег просто встал ничего делает чяндт
Выдрал ффмпегом из movierip1.mkv нужную мне аудиодорожку audio.ac3 и пытаюсь вклеить её в movierip2.mkv (все потоки через copy, конечно). Длительность movierip1.mkv, movierip2.mkv и audio.ac3 совпадают. Итоговый combo.mkv содержит обе необходимые дорожки (0:0 - видео из movierip2, 0:1 - audio.ac3, 0:2 - аудио из movierip2, 0:3 и т.д. - субтитры), запускается через mpc-hc, но зависает при попытке перемотать в любое место.
При этом, если запустить его, поставить на паузу, выбрать дорожку, кот. была копирована из movierip2.mkv вместо добавленной - тогда перемотка работает нормально и ничего не виснет.
ЧЯДНТ?
При этом, если запустить его, поставить на паузу, выбрать дорожку, кот. была копирована из movierip2.mkv вместо добавленной - тогда перемотка работает нормально и ничего не виснет.
ЧЯДНТ?
>>392925
Хм, а вот через mkvtoolnix всё получилось нормально. Непонятно...
Хм, а вот через mkvtoolnix всё получилось нормально. Непонятно...
24 Кб, 266x625После кодирования через FFMPEG в AV1 (1920Х1080), видео тормозит при перемотке, проц нагружается довольно сильно, во время воспроизведения на 5%, а при перемотке на 40-60% и задержка секунды по 2 когда тыкаешь в случайное место таймлайна.
Раньше кодировал в blender, как я понял туда встроен тот же FFMPEG (см.пик) и при этом видосы закодированные в AV1 там не тормозят при перемотке, в любую точку видео перескакивает моментально.
Так вот можно как-то оптимизировать кодирование через FFMPEG ?
Раньше кодировал в blender, как я понял туда встроен тот же FFMPEG (см.пик) и при этом видосы закодированные в AV1 там не тормозят при перемотке, в любую точку видео перескакивает моментально.
Так вот можно как-то оптимизировать кодирование через FFMPEG ?
>>392999
У тебя не должно быть таких лагов. Попробуй обновить libdav1d до последней версии.
Сколько fps у твоего видео? Если 24, то поставь такой-же Keyframe interval. Если 30, оставь как есть.
Вопрос не по теме: зачем тебе realtime пресет? Если нужно срочно видео, у тебя есть h264. Если комп не тянет AV1, юзай h265.
И если речь о встроенном в ffmpeg aac, повысь битрейт до 320.
У тебя не должно быть таких лагов. Попробуй обновить libdav1d до последней версии.
Сколько fps у твоего видео? Если 24, то поставь такой-же Keyframe interval. Если 30, оставь как есть.
Вопрос не по теме: зачем тебе realtime пресет? Если нужно срочно видео, у тебя есть h264. Если комп не тянет AV1, юзай h265.
И если речь о встроенном в ffmpeg aac, повысь битрейт до 320.
>h265 для рендеров
Пощади, оставь хотя бы h264
>>393002
Ну даже реалтайм пресет AV1 выдаёт результат заметно лучше, чем H264, поэтому и юзаю его.
А вот на счёт ключевых кадров было подозрение, т.к. по дефолту FFMPEG вроде ставит 160.
Попробую ставить такой же keyframe как и у фпс, спасибо.
Ну даже реалтайм пресет AV1 выдаёт результат заметно лучше, чем H264, поэтому и юзаю его.
А вот на счёт ключевых кадров было подозрение, т.к. по дефолту FFMPEG вроде ставит 160.
Попробую ставить такой же keyframe как и у фпс, спасибо.
>>392999
Если ты не указываешь явно интервал ключевых кадров, то он может быть настроен под видосики времён DivX. Ещё настройки упаковки в контейнер или создания индекса могут быть непонятно какими.
Если ты не указываешь явно интервал ключевых кадров, то он может быть настроен под видосики времён DivX. Ещё настройки упаковки в контейнер или создания индекса могут быть непонятно какими.
Попробовал ради теста поставить keyframe 24 в обоих роликах, один отрендерен в blender, другой в ffmpeg. Всё равно при перемотке
в ролике отрендереном в ffmpeg задержка в секунду, а второй вообще без задержки.
С чем это связано не могу понять.
в ролике отрендереном в ffmpeg задержка в секунду, а второй вообще без задержки.
С чем это связано не могу понять.
>>393102
Начни с того, что возьми командную строку, с которой ffmpeg запускается из Blender, выбери все содержательные параметры, повтори и посмотри на результат. Вон там что-то про размеры блоков в muxing, ты у себя это указываешь?
Начни с того, что возьми командную строку, с которой ffmpeg запускается из Blender, выбери все содержательные параметры, повтори и посмотри на результат. Вон там что-то про размеры блоков в muxing, ты у себя это указываешь?
>>393105
Короче нашел проблему, если кодировать c CRF - видео перематывается с задержкой, хз как работает этот режим битрейта, а вот с постоянным битрейтом такой проблемы нет, всё шустро летает.
Короче нашел проблему, если кодировать c CRF - видео перематывается с задержкой, хз как работает этот режим битрейта, а вот с постоянным битрейтом такой проблемы нет, всё шустро летает.
Парни, а объясните дебилу, как УДОБНО организовать работу с ffmpeg?
То есть ну бля, вы прям руками каждый раз прописываете имя файла и путь к нему? Это ж обосраться как неудобно. Или видео, с которыми работаете, надо предварительно складывать в папку куда установлен сам ffmpeg?
Я не троллю, я правда не понимаю. У меня лежит там штук сорок видео с ютуба, допустим, мне их надо перекодировать чтобы сраный премьер про их принимать начал (хули дебилы из адоба поддержку vp9 сами не сделают, блядь, заебали) - мне их надо туда-сюда по папкам таскать или названия им всем поменять на короткие, чтобы точно не опечататься забивая их в ffmpeg? Я просто не понимаю нахуй, вы это делаете за пять минут левой ногой попивая кофе, как?
То есть ну бля, вы прям руками каждый раз прописываете имя файла и путь к нему? Это ж обосраться как неудобно. Или видео, с которыми работаете, надо предварительно складывать в папку куда установлен сам ffmpeg?
Я не троллю, я правда не понимаю. У меня лежит там штук сорок видео с ютуба, допустим, мне их надо перекодировать чтобы сраный премьер про их принимать начал (хули дебилы из адоба поддержку vp9 сами не сделают, блядь, заебали) - мне их надо туда-сюда по папкам таскать или названия им всем поменять на короткие, чтобы точно не опечататься забивая их в ffmpeg? Я просто не понимаю нахуй, вы это делаете за пять минут левой ногой попивая кофе, как?
>>393213
В kde можно перетащить иконку файлика мышкой, чтобы имя под указатель в консолечке вставилось. В шиндошс 10 так в кмд.езе тоже можно.
Плюс, есть подсказки интерпретатора по tab.
Да. На прыщах к исполняшке ffmpeg путь всегда известен, т. к. она лежит в системном каталоге для исполняшек. На шиндошс с незапамятных времëн в реестре есть веточка
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
В неë можно ffmpeg добавить, чтобы как в прыщах запускать ffmpeg в любом текущем каталоге.
А ещë в прыщах в kde и в других средах, как правило в файловых менеджерах есть возможность в текущем просматриваемом каталоге запустить командную оболочку. Удобно сделано, для людей.
Коммерческий интерес у них. Используешь коммерчнское ПО — привыкай к интересам барина и чувству ранга!
Можно запускать ffmpeg в каталоге с этими последовательностями. Кстати, а современный Премьер кушает avisynth/vapoursynth хотябы через что-нибудь, чтобы тебе не перекодировать последовательности?
Вот это хорошая мысль. Даже вне зависимости от ffmpeg и командных интерфейсов. Способ именования файлов — великая вещь, если способ этот вдумчивый.
Да. При определëнном навыке это делается легко и просто. Даже несложные регулярные выражения сходу сочиняются после практики. Люди, вообще, обучаемые — это их видовая особенность.
>То есть ну бля, вы прям руками каждый раз прописываете имя файла и путь к нему?
В kde можно перетащить иконку файлика мышкой, чтобы имя под указатель в консолечке вставилось. В шиндошс 10 так в кмд.езе тоже можно.
Плюс, есть подсказки интерпретатора по tab.
>обосраться как неудобно
>предварительно складывать в папку куда установлен сам ffmpeg?
Да. На прыщах к исполняшке ffmpeg путь всегда известен, т. к. она лежит в системном каталоге для исполняшек. На шиндошс с незапамятных времëн в реестре есть веточка
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
В неë можно ffmpeg добавить, чтобы как в прыщах запускать ffmpeg в любом текущем каталоге.
А ещë в прыщах в kde и в других средах, как правило в файловых менеджерах есть возможность в текущем просматриваемом каталоге запустить командную оболочку. Удобно сделано, для людей.
>хули дебилы из адоба поддержку vp9 сами не сделают, блядь, заебали
Коммерческий интерес у них. Используешь коммерчнское ПО — привыкай к интересам барина и чувству ранга!
>мне их надо туда-сюда по папкам таскать
Можно запускать ffmpeg в каталоге с этими последовательностями. Кстати, а современный Премьер кушает avisynth/vapoursynth хотябы через что-нибудь, чтобы тебе не перекодировать последовательности?
> или названия им всем поменять на короткие
Вот это хорошая мысль. Даже вне зависимости от ffmpeg и командных интерфейсов. Способ именования файлов — великая вещь, если способ этот вдумчивый.
>Я просто не понимаю нахуй, вы это делаете за пять минут левой ногой попивая кофе, как?
Да. При определëнном навыке это делается легко и просто. Даже несложные регулярные выражения сходу сочиняются после практики. Люди, вообще, обучаемые — это их видовая особенность.
171 Кб, 888x7081,Свойства в виндовс показывают правдивый битрейт?
2,Если при конвертации поставить битрейт больше, чем у оригинала, произойдет что со звучанием? Не ухудшится?
3,Моно нужно меньше битрейта, нежели стерео, или я ошибаюсь?
2,Если при конвертации поставить битрейт больше, чем у оригинала, произойдет что со звучанием? Не ухудшится?
3,Моно нужно меньше битрейта, нежели стерео, или я ошибаюсь?
17 Кб, 529x503>>393216
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
В неë можно ffmpeg добавить, чтобы как в прыщах запускать ffmpeg в любом текущем каталоге.
Есть переменные окружения, а про ветку реестра я впервые слышу.
> На шиндошс с незапамятных времëн в реестре есть веточка
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
В неë можно ffmpeg добавить, чтобы как в прыщах запускать ffmpeg в любом текущем каталоге.
Есть переменные окружения, а про ветку реестра я впервые слышу.
>>393213
Какие батники павершеллы и питоны используют
Какие батники павершеллы и питоны используют
89 Кб, 353x332мимокрокодил на связи
ладно, вот вам всем задачка.
есть "несжатые" хромакейные сурсы, но слишком уж большой размер у этих синих шакалов.
жму handbrakом, все здорово, размер меньше в десятки и сотни раз, новых шакалов не прибавляется, но на границах между синевой и обектом повялется ттакая темно-синяя рамка. я не эксперт, наверно дело в цветовом пространстве?
lagarith и Ut Video, вроде в RGB, нужно сжать в любой формат и кодек, уменьшив рамер и не проебав цвета
ладно, вот вам всем задачка.
есть "несжатые" хромакейные сурсы, но слишком уж большой размер у этих синих шакалов.
жму handbrakом, все здорово, размер меньше в десятки и сотни раз, новых шакалов не прибавляется, но на границах между синевой и обектом повялется ттакая темно-синяя рамка. я не эксперт, наверно дело в цветовом пространстве?
lagarith и Ut Video, вроде в RGB, нужно сжать в любой формат и кодек, уменьшив рамер и не проебав цвета
>>393224
Сосач образовательный
https://learn.microsoft.com/en-us/windows/win32/shell/app-registration
>Есть переменные окружения, а про ветку реестра я впервые слышу.
Сосач образовательный
https://learn.microsoft.com/en-us/windows/win32/shell/app-registration
>>393332
Вероятно, у тебя разрешение каналов цветности становится в два раза меньше, потому что ты не указываешь иное.
https://ru.wikipedia.org/wiki/%D0%A6%D0%B2%D0%B5%D1%82%D0%BE%D0%B2%D0%B0%D1%8F_%D1%81%D1%83%D0%B1%D0%B4%D0%B8%D1%81%D0%BA%D1%80%D0%B5%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F
Видео в 4:2:0 годится только для финального продукта (трансляции, файла), потому что дальше с ним ничего не сделать из-за потери чёткости. Многие каналы и студии просто запрещают использовать такие материалы.
Кроме того, артефакты сжатия никуда не деваются, даже если тебе их не видно, и будут портить чёткие границы. Если ты уверен, что они никогда не вылезут (например, объекты всегда будут гораздо меньшего размера), то можешь экономить. Если там будет какое-нибудь автоматическое выделение контуров или оценка позиции объектов, то работать проще будет с оригинальными циферками. Само собой, и цветокоррекция никакого сжатия не позволяет.
Конечно, во многих случаях сжатие с потерями с высоким битрейтом нормально закроет проблему, но если ты не понимаешь, что потребуется от материалов, не порти их.
Вероятно, у тебя разрешение каналов цветности становится в два раза меньше, потому что ты не указываешь иное.
https://ru.wikipedia.org/wiki/%D0%A6%D0%B2%D0%B5%D1%82%D0%BE%D0%B2%D0%B0%D1%8F_%D1%81%D1%83%D0%B1%D0%B4%D0%B8%D1%81%D0%BA%D1%80%D0%B5%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F
Видео в 4:2:0 годится только для финального продукта (трансляции, файла), потому что дальше с ним ничего не сделать из-за потери чёткости. Многие каналы и студии просто запрещают использовать такие материалы.
Кроме того, артефакты сжатия никуда не деваются, даже если тебе их не видно, и будут портить чёткие границы. Если ты уверен, что они никогда не вылезут (например, объекты всегда будут гораздо меньшего размера), то можешь экономить. Если там будет какое-нибудь автоматическое выделение контуров или оценка позиции объектов, то работать проще будет с оригинальными циферками. Само собой, и цветокоррекция никакого сжатия не позволяет.
Конечно, во многих случаях сжатие с потерями с высоким битрейтом нормально закроет проблему, но если ты не понимаешь, что потребуется от материалов, не порти их.
>>393332
Как последовательность организована? Контейнер? Кодек? Цветовое пространство? Колориметрия? Каналы?
Если ты делаешь, не думая, то почему удивляешься чудесам?
Так сведи сначала, а потом жми! Или у тебя другая задача?
>есть "несжатые" хромакейные сурсы, но слишком уж большой размер у этих синих шакалов.
Как последовательность организована? Контейнер? Кодек? Цветовое пространство? Колориметрия? Каналы?
>жму handbrakом, все здорово
>на границах между синевой и обектом повялется ттакая темно-синяя рамка.
Если ты делаешь, не думая, то почему удивляешься чудесам?
>нужно сжать в любой формат и кодек, уменьшив рамер и не проебав цвета
Так сведи сначала, а потом жми! Или у тебя другая задача?
1,5 Мб, 320x240>>393370
оказался прав, на 4:4:4 границ нет, либо почти незаметные глазу. фон правда светлее становится, с остальными цветами непонятно.
>>393483
яж написал
Ut Video ULRG
Lagarith Lossless (LAGS)
бывает еще какой то 24 bits RGB (RV24)
пара сотня таких файлов размером 2-40+мб в 480р в среднем и продолжительность до 1-7 секунд. считаю такой размер слишком уж избыточным, учитывая исходники.
да лослесс все дела, но если на границах артефактов не вылезет то один хуй никто и не заметит разницы
оказался прав, на 4:4:4 границ нет, либо почти незаметные глазу. фон правда светлее становится, с остальными цветами непонятно.
>>393483
> Контейнер? Кодек? Цветовое пространство?
яж написал
Ut Video ULRG
Lagarith Lossless (LAGS)
бывает еще какой то 24 bits RGB (RV24)
пара сотня таких файлов размером 2-40+мб в 480р в среднем и продолжительность до 1-7 секунд. считаю такой размер слишком уж избыточным, учитывая исходники.
да лослесс все дела, но если на границах артефактов не вылезет то один хуй никто и не заметит разницы
>>393673
разобрался. в .avi похоже нет данных о цв пространстве и handbrake автоматом лепит своё. если выбрать кастом но ничего не вписывать, то норм
> фон правда светлее
разобрался. в .avi похоже нет данных о цв пространстве и handbrake автоматом лепит своё. если выбрать кастом но ничего не вписывать, то норм
>>393673
Попробуй монтажные/промежуточные кодеки, вроде prores 4444 или DNxHS с соосветсвующим профилем.
> пара сотня таких файлов размером 2-40+мб в 480р в среднем и продолжительность до 1-7 секунд. считаю такой размер слишком уж избыточным, учитывая исходники.
> да лослесс все дела, но если на границах артефактов не вылезет то один хуй никто и не заметит разницы
Попробуй монтажные/промежуточные кодеки, вроде prores 4444 или DNxHS с соосветсвующим профилем.
>>393685
ffmpeg последних версий умеет кодировать и то и другое.
Но документация по DNxHD получше будет, мне так кажется. Я только prores пробовал выводить.
ffmpeg последних версий умеет кодировать и то и другое.
Но документация по DNxHD получше будет, мне так кажется. Я только prores пробовал выводить.
>>393686
эх, ну пошел шапчку читать от корки до корки
эх, ну пошел шапчку читать от корки до корки
>>393673
А ответ на 2×2=? ты тоже будешь голосованием определять? Тут не догадываться надо, а просто знать.
> оказался прав
> оказался
А ответ на 2×2=? ты тоже будешь голосованием определять? Тут не догадываться надо, а просто знать.
>>393746
Удваиваю
Удваиваю
119 Кб, 238x298Увожаемые программисты, а можно ли как нибудь с помощью этой приблуды добавить эффект дизеринга как на гиф анимациях ?
>>393931
Ты можешь тупо сохранить видос в гиф и обратно. Можешь по умному прогнать видос через palettegen. https://stackoverflow.com/questions/60477430/create-256-color-palette-video
Ты можешь тупо сохранить видос в гиф и обратно. Можешь по умному прогнать видос через palettegen. https://stackoverflow.com/questions/60477430/create-256-color-palette-video
>>393942
Спасибо, буду разбираться как сделать качественную гифку.
Нашел гайд по гифкам, мб кому пригодится, оставлю тут:
http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
Спасибо, буду разбираться как сделать качественную гифку.
Нашел гайд по гифкам, мб кому пригодится, оставлю тут:
http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
>>393931
Так тебе только визуальный эффект нужен, или чтобы GIF хорошо сжимался? Во втором случае лучше пользоваться редакторами и руками выделять статичный фон. Мельтешение пикселей, выдаваемое автоматическими конвертерами, вообще никак не сжимается, глупо делать идиотского размера файлы.
Так тебе только визуальный эффект нужен, или чтобы GIF хорошо сжимался? Во втором случае лучше пользоваться редакторами и руками выделять статичный фон. Мельтешение пикселей, выдаваемое автоматическими конвертерами, вообще никак не сжимается, глупо делать идиотского размера файлы.
Нашел команду для дизеринга - dither=bayer:bayer_scale=2 , куда её пихать не могу найти инфу. Может кто подсказать ?
Так не работает:
ffmpeg -y -i 1.mp4 -i palette.png -filter_complex "[0][1]paletteuse , dither=bayer:bayer_scale=2" output.gif
Так не работает:
ffmpeg -y -i 1.mp4 -i palette.png -filter_complex "[0][1]paletteuse , dither=bayer:bayer_scale=2" output.gif
>>394014
Разобрался методом научного тыка:
ffmpeg -y -i 1.mp4 -i palette.png -filter_complex "[0][1]paletteuse=dither=bayer:bayer_scale=2" output.gif
Разобрался методом научного тыка:
ffmpeg -y -i 1.mp4 -i palette.png -filter_complex "[0][1]paletteuse=dither=bayer:bayer_scale=2" output.gif
>>394012
Если ты делаешь что-то в видеоредакторе, то просто наложи такой фильтр на нужный объект.
В ffmpeg совсем не обязательно делать GIF, ты можешь и видео сохранить. Только сжатие эти пиксели размажет, поэтому надо либо несжатый формат брать, либо в том же filter_complex добавлять увеличение в 2-3-4 раза (само собой, исходник высокого разрешения можно перед приведением к меньшему числу цветов уменьшить во столько же раз).
Bayer даёт регулярную сеточку, остальные алогритмы (из представленных) — случайные точки. Между кадрами видео они могут распределяться по-разному, одни — двигаться, другие — стоять на месте.
Источником палитры может служить не только само видео, но и любой файл с любой другой палитрой, например, стандартные 16 цветов или набор оттенков одного или нескольких цветов.
Если ты делаешь что-то в видеоредакторе, то просто наложи такой фильтр на нужный объект.
В ffmpeg совсем не обязательно делать GIF, ты можешь и видео сохранить. Только сжатие эти пиксели размажет, поэтому надо либо несжатый формат брать, либо в том же filter_complex добавлять увеличение в 2-3-4 раза (само собой, исходник высокого разрешения можно перед приведением к меньшему числу цветов уменьшить во столько же раз).
Bayer даёт регулярную сеточку, остальные алогритмы (из представленных) — случайные точки. Между кадрами видео они могут распределяться по-разному, одни — двигаться, другие — стоять на месте.
Источником палитры может служить не только само видео, но и любой файл с любой другой палитрой, например, стандартные 16 цветов или набор оттенков одного или нескольких цветов.
137 Кб, webm,720x406, 0:01
>>394028
Ну вобщем конвертнул сначала в гифку с дизерингом, потом гифку обратно в AV1 при этом дизеринг почти полностью сохранился при низком битрейте. Каефная штука этот ваш FFMPEG, а ещё сегодня попробовал как работает стабилизация, результат шикарный.
Спасибо анончики.
Видос ради теста.
Ну вобщем конвертнул сначала в гифку с дизерингом, потом гифку обратно в AV1 при этом дизеринг почти полностью сохранился при низком битрейте. Каефная штука этот ваш FFMPEG, а ещё сегодня попробовал как работает стабилизация, результат шикарный.
Спасибо анончики.
Видос ради теста.
>>394108
Вот эти точечки на большинстве устройств и в большинстве ситуаций люди даже не заметят. Либо в 2-4-8 раз меньше цветов делай, либо пиксели крупнее и очевиднее.
Вот эти точечки на большинстве устройств и в большинстве ситуаций люди даже не заметят. Либо в 2-4-8 раз меньше цветов делай, либо пиксели крупнее и очевиднее.
>>394186
Да так же думаю, сначала рендерить в низком разрешении и апскейлить в два раза с flags=neighbor, а вот как кол-во цветов уменьшить пока не догнал.
Да так же думаю, сначала рендерить в низком разрешении и апскейлить в два раза с flags=neighbor, а вот как кол-во цветов уменьшить пока не догнал.
>>394211
Ну ты хоть параметры для palettegen просмотри разочек.
Ну ты хоть параметры для palettegen просмотри разочек.
Есть что-то типа boram? Где можно визуально обрезать кадр, выбрать дорожки и при необходимости (например pgs сабы) отредактировать ffmpeg строку? И почему разраб умер? И почему никто не продолжает разрабатывать эту годноту?
63 Кб, 1004x683>>394808
Глянь HandBrake, помоему похожая штука.
Глянь HandBrake, помоему похожая штука.
14 Кб, 967x156Порекомендуйте какой билд FFMPEG скачать, в гайде что выше анон пишет что не стоит брать стандартные билды.
Какие преимущества в этих Nonfree билдах ?
Какие преимущества в этих Nonfree билдах ?
>>396232
Ну, смотри. Лицензии разных кодеков внутри ffmpeg и доступных в виде статически скомпонованных с ffmpeg сторонних библиотек неоднородны. Если соответственно варианты сборки:
- GPL-совместимый, включающий только куски кода, которые по условиям GPL можно компоновать и поставлять,
- не совместимый с GPL вариант сборки, всë ещë отвечающий более широкому пониманию «свободного ПО», и содержащий больше кодеков,
- несвободные варианты сборки, при которой в ffmpeg включаются несвободные кодеки — из актуального это libfdkaac (aac-кодер от института им. Франнофера).
Это всë очень актуально, если сборка у тебя была для шиндошс в один исполняемый файл. Бери в этом случае сборку от animouse. На прыщах зачастую ffmpeg из репозиттория сделан в виде кучи файлов и библиотек с динамической компоновкой — и там бывает достаточно из того же репозитория установить libfdkaac, чтобы ffmpeg его подхватил.
Ну, смотри. Лицензии разных кодеков внутри ffmpeg и доступных в виде статически скомпонованных с ffmpeg сторонних библиотек неоднородны. Если соответственно варианты сборки:
- GPL-совместимый, включающий только куски кода, которые по условиям GPL можно компоновать и поставлять,
- не совместимый с GPL вариант сборки, всë ещë отвечающий более широкому пониманию «свободного ПО», и содержащий больше кодеков,
- несвободные варианты сборки, при которой в ffmpeg включаются несвободные кодеки — из актуального это libfdkaac (aac-кодер от института им. Франнофера).
Это всë очень актуально, если сборка у тебя была для шиндошс в один исполняемый файл. Бери в этом случае сборку от animouse. На прыщах зачастую ffmpeg из репозиттория сделан в виде кучи файлов и библиотек с динамической компоновкой — и там бывает достаточно из того же репозитория установить libfdkaac, чтобы ffmpeg его подхватил.
>>396311
Спасибо тебе анончик.
Спасибо тебе анончик.
Для hls стриминга видео как лучше сделать: разбивать его на ts сегменты по запросу, или заранее разбить видео на сегменты и на клиент отдавать сразу готовый m3u8 файлик?
>>396886
Планирую сделать стриминговый сервис, так что клиентов может быть много(от 1 до 3). Зачем? Для себя.
Планирую сделать стриминговый сервис, так что клиентов может быть много(от 1 до 3). Зачем? Для себя.
>>396912
Всё равно ничего не понятно. Зачем тебе стриминг для себя? Почему нельзя предварительно транскодировать в один .mp4 или .webm файл? Зачем городить костыли из кучи фрагментированных ts файлов в перемешку с плейлистами, которые откроются только у яблочных? Браузеры так-то поддерживают только mp4 и webm контейнеры.
Реально все эти HLS, MPEG DASH применимы только в двух случаях: когда тебе нужна адаптация к меняющейся пропускной способности канала передачи данных, и когда тебе надо готовить разные версии одного видео для широкой аппаратной поддержки и высокого качества.
Всё равно ничего не понятно. Зачем тебе стриминг для себя? Почему нельзя предварительно транскодировать в один .mp4 или .webm файл? Зачем городить костыли из кучи фрагментированных ts файлов в перемешку с плейлистами, которые откроются только у яблочных? Браузеры так-то поддерживают только mp4 и webm контейнеры.
Реально все эти HLS, MPEG DASH применимы только в двух случаях: когда тебе нужна адаптация к меняющейся пропускной способности канала передачи данных, и когда тебе надо готовить разные версии одного видео для широкой аппаратной поддержки и высокого качества.
>>396936
Ясно, ты явно не разбираешься в теме. Этот HLS буквально везде: twitch, netflix, goodgame и так далее, он абсолютно везде используется.
>которые откроются только у яблочных
Ясно, ты явно не разбираешься в теме. Этот HLS буквально везде: twitch, netflix, goodgame и так далее, он абсолютно везде используется.
>>396944
Это ты не понял.
HSL, MPEG DASH это протоколы, работающие внутри HTTP.
А я говорю про контейнеры. Ты говорил что собираешься паковать сегменты в TS. Этот контейнер поддерживают только яблочные устройства.
Браузеры поддерживают mp4, а если быть точнее то фрагментированный mp4.
А ещё ты так до сих пор и не дал внятного ответа на вопросы которые я задал тебе ранее.
Это ты не понял.
HSL, MPEG DASH это протоколы, работающие внутри HTTP.
А я говорю про контейнеры. Ты говорил что собираешься паковать сегменты в TS. Этот контейнер поддерживают только яблочные устройства.
Браузеры поддерживают mp4, а если быть точнее то фрагментированный mp4.
А ещё ты так до сих пор и не дал внятного ответа на вопросы которые я задал тебе ранее.
>>396961
Если посмотреть в запросах браузерных, то сервер возвращает .ts файлы, все работает и везде поддерживается.
Не знаю что тебе ответить на твой вопрос. Для себя хочу сделать, чтобы просто было, научиться, какая разница?
>А я говорю про контейнеры. Ты говорил что собираешься паковать сегменты в TS. Этот контейнер поддерживают только яблочные устройства.
>TS
Если посмотреть в запросах браузерных, то сервер возвращает .ts файлы, все работает и везде поддерживается.
>А ещё ты так до сих пор и не дал внятного ответа на вопросы которые я задал тебе ранее.
Не знаю что тебе ответить на твой вопрос. Для себя хочу сделать, чтобы просто было, научиться, какая разница?
>>396961
И кстати ты так сам и не ответил на мой изначальный вопрос, а развел допросы какие-то, которые вообще к сути дела отношения не имеют. В общем можешь не отвечать, я не ту доску выбрал для вопроса(надо было к погромиздам идти) + уже сам разобрался как мне сделать лучше.
И кстати ты так сам и не ответил на мой изначальный вопрос, а развел допросы какие-то, которые вообще к сути дела отношения не имеют. В общем можешь не отвечать, я не ту доску выбрал для вопроса(надо было к погромиздам идти) + уже сам разобрался как мне сделать лучше.
>>396969
Чем я тебе помогу, если я не знаю что я делаю и зачем я делаю?
Тебе для локального видеохостинга достаточно контейнера mp4. А webm сам по себе умеет в стриминг. Нужно только вывести выхлоп из ffmpeg в браузер клиенту.
Пока что я вижу использование HLS как пердолинг ради пердолинга.
Чем я тебе помогу, если я не знаю что я делаю и зачем я делаю?
Тебе для локального видеохостинга достаточно контейнера mp4. А webm сам по себе умеет в стриминг. Нужно только вывести выхлоп из ffmpeg в браузер клиенту.
Пока что я вижу использование HLS как пердолинг ради пердолинга.
Я могу какой-то командой в ffmpeg добавить в начало ролика 3-5 секунд чёрного экрана? В общем есть видосы в prores. Мне нужно добавить 5 секунд в начало.
Я пробовал конечно через Adobe Premiere Pro. Я не ебу, хз почему, у него ультраубогий кодировщик. На градиентах черного и серого становятся более чёткие границы.
Как вообще с ним профи работают? Хули он там убого рендерит? Там и настроек толком нет.
Я пробовал конечно через Adobe Premiere Pro. Я не ебу, хз почему, у него ультраубогий кодировщик. На градиентах черного и серого становятся более чёткие границы.
Как вообще с ним профи работают? Хули он там убого рендерит? Там и настроек толком нет.
696 Кб, webm,632x388, 0:01
Как сделали такое видео? с пк в бразуре хром оно меняет разрешение
а в винде оно не только меняет разрешение но еще и окно плеера движется по экрану
в хроме показывает продолжительность 1 секунду хотя по факту воспроизводится почти 3
в телеге на пк в чате оно воспроизводится просто в рамках одного размера кадра, когда уменьшается то пустота заполняется блюром, а вот в при полноэкранном воспрозивдеении почти ничего не меняется лишь небольшие помехи добавляются и еще телега видит что там не 1 секунда, а пишет как по факту
а в винде оно не только меняет разрешение но еще и окно плеера движется по экрану
в хроме показывает продолжительность 1 секунду хотя по факту воспроизводится почти 3
в телеге на пк в чате оно воспроизводится просто в рамках одного размера кадра, когда уменьшается то пустота заполняется блюром, а вот в при полноэкранном воспрозивдеении почти ничего не меняется лишь небольшие помехи добавляются и еще телега видит что там не 1 секунда, а пишет как по факту
>>397499
Вебм поддерживает динамическую смену разрешения. Видео нарезали на кадры, каким-то скриптом изменили их разрешение, потом обратно склеили.
Вебм поддерживает динамическую смену разрешения. Видео нарезали на кадры, каким-то скриптом изменили их разрешение, потом обратно склеили.
>>397510
А движение окна видеоплеера тож поддерживает? Если поставить зацикливание в мпв то окно движется. кино и тв не дает ему двигаться. или это связано с изменением кадра, а потом переопределением его позициноирования относительно нового размера кадра?
А движение окна видеоплеера тож поддерживает? Если поставить зацикливание в мпв то окно движется. кино и тв не дает ему двигаться. или это связано с изменением кадра, а потом переопределением его позициноирования относительно нового размера кадра?
>>397512
Разные плееры могут реагировать по-разному, и это проблемы реализации конкретного плеера, а не возможностей вебм.
Разные плееры могут реагировать по-разному, и это проблемы реализации конкретного плеера, а не возможностей вебм.
>>397512
У меня не двигается, только размер меняется, левый верхний угол остается на том же месте.
У меня не двигается, только размер меняется, левый верхний угол остается на том же месте.
106 Кб, 247x254Подскажите пожалуйста как вырезать из видео два фрагмента и объеденить их в один, допустим надо вырезать 5-ти секундный фрагмент начиная с 00:01:00 и 5-ти секундный фрагмент с 00:03:00
>>397941
Нашел способ через Concatenation, но это довольно геморно, сначала отдельно напилить видос, потом склеить.
Есть ли способ чтобы сразу указать интервалы в видео которые надо вырезать и склеить ?
Нашел способ через Concatenation, но это довольно геморно, сначала отдельно напилить видос, потом склеить.
Есть ли способ чтобы сразу указать интервалы в видео которые надо вырезать и склеить ?
Как я понял, из-за такой вещи как keyframe невозможно вырезать из видео кусок длительностью 23 секунды начиная с какой-то секунды? При условии что мы не попадаем сразу в ключевой кадр. Потому что когда я пытаюсь вырезать кусок длительностью 8 секунд, он то 7 вырезает, то 9, иногда вообще 15 может. Как с этим бороться и возможно ли вообще?
>>399470
P.S. Все значения условные. По поводу
Возможно, но интервалы будут неточные, мне же надо, чтобы до секунды всё было.
P.S. Все значения условные. По поводу
>невозможно вырезать из видео кусок длительностью 23 секунды начиная с какой-то секунды
Возможно, но интервалы будут неточные, мне же надо, чтобы до секунды всё было.
>>399475
Тебе надо не до секунды, а, скорее всего, до кадра. Это только с перекодированием. И я бы предпочëл это делать не голым ffmpeg-ом, а каким-нибудь редактором, который в явном виде готовит индекс кадров, и явно заботится о синхронизации. В качестве редактора я бы рассматривал avisynth+, vapoursynth, avidemux.
>мне же надо, чтобы до секунды всё было.
Тебе надо не до секунды, а, скорее всего, до кадра. Это только с перекодированием. И я бы предпочëл это делать не голым ffmpeg-ом, а каким-нибудь редактором, который в явном виде готовит индекс кадров, и явно заботится о синхронизации. В качестве редактора я бы рассматривал avisynth+, vapoursynth, avidemux.
>>399587
Нет, мне надо как раз на секунды. Но я уже понял что без перекодировки это нереально сделать, нужно перекодировать, чтобы ffmpeg вставлял свои keyframe'ы.
Вот параметр, если кому-то -force_key_frames "expr:gte(t,n_forced*N)",
где N - интервал ключевых кадров.
С -c:v copy работать не будет, он вам даже не выплюнет что ничего не изменится, он просто проигнорит -force_key_frames
Нет, мне надо как раз на секунды. Но я уже понял что без перекодировки это нереально сделать, нужно перекодировать, чтобы ffmpeg вставлял свои keyframe'ы.
Вот параметр, если кому-то -force_key_frames "expr:gte(t,n_forced*N)",
где N - интервал ключевых кадров.
С -c:v copy работать не будет, он вам даже не выплюнет что ничего не изменится, он просто проигнорит -force_key_frames
>>399600
Это будет работать только для постоянной частоты кадров. Формально, мельчайшей единицей видеопоследовательности будет кадр или поле (в случае чересстрочной развëртки). Разделить последовательность можно с точностью до мельчайшей единицы. Частота кадров не всегда постоягнная и даже из вариантов с постоянной частотой эта частота нк всегда является целым числом. Т. о. не всегда временные метки кадров или полей выражаются в целых числах секунд.
>force_key_frames "expr:gte(t,n_forced*N)",
Это будет работать только для постоянной частоты кадров. Формально, мельчайшей единицей видеопоследовательности будет кадр или поле (в случае чересстрочной развëртки). Разделить последовательность можно с точностью до мельчайшей единицы. Частота кадров не всегда постоягнная и даже из вариантов с постоянной частотой эта частота нк всегда является целым числом. Т. о. не всегда временные метки кадров или полей выражаются в целых числах секунд.
>>399626
Ошибся. Для остальных тоже будет работать, т. к. gte — это «больше или равно», т. е. ключевой кадр встанет в момент, кратный N (в секундах), если в этот момент есть соответствующий кадр, или ключевым станет следующий за указанным моментом кадр, если кадр точно в момент не попадает.
>Это будет работать только для постоянной частоты кадров.
Ошибся. Для остальных тоже будет работать, т. к. gte — это «больше или равно», т. е. ключевой кадр встанет в момент, кратный N (в секундах), если в этот момент есть соответствующий кадр, или ключевым станет следующий за указанным моментом кадр, если кадр точно в момент не попадает.
>>399626
Я добавляю -r 24 -g N,
где N меняется в зависимости от длины куска.
>Это будет работать только для постоянной частоты кадров.
Я добавляю -r 24 -g N,
где N меняется в зависимости от длины куска.
25 Кб, 455x192https://www.phoronix.com/news/FFmpeg-CLI-MT-Merged
Попробовал, ровно те же самые опции, но новый многопоточный ffmpeg.
На 30% быстрее, но жрет в полтора раза больше процессорного времени.
Попробовал, ровно те же самые опции, но новый многопоточный ffmpeg.
На 30% быстрее, но жрет в полтора раза больше процессорного времени.
>>399720
Упс, я забыл, что у меня taskset стоит для ффмпега.
Старая версия выдает примерно те же числа, что и новая:
User time (seconds): 427.72
System time (seconds): 1.58
Percent of CPU this job got: 1682%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:25.52
Упс, я забыл, что у меня taskset стоит для ффмпега.
Старая версия выдает примерно те же числа, что и новая:
User time (seconds): 427.72
System time (seconds): 1.58
Percent of CPU this job got: 1682%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:25.52
>>365343 (OP)
Подскажите, если делать захват экрана, чтобы скопировать таким образом онлайн-видео, можно ли таким методом добиться идентичного качества 1:1?
Или в любом случае необходимы оригинальные файлы?
Подскажите, если делать захват экрана, чтобы скопировать таким образом онлайн-видео, можно ли таким методом добиться идентичного качества 1:1?
Или в любом случае необходимы оригинальные файлы?
>>399983
Идентичного чему? Тому, что ты видишь на экране? Ну запиши без сжатия с максимальной частотой кадров, потом удали повторяющиеся и нормализуй результат под частоту кадров оригинала. Будешь сжимать — сжимай с большим запасом битрейта, чтобы визуально отличия незаметны были. Только вот с экрана писать само по себе неграмотное решение.
Если ты видео без DRM собираешься записывать, то лучше просто копию исходника сохранять по мере получения. Если с DRM, то тебе записывать просто так система не даст.
Идентичного чему? Тому, что ты видишь на экране? Ну запиши без сжатия с максимальной частотой кадров, потом удали повторяющиеся и нормализуй результат под частоту кадров оригинала. Будешь сжимать — сжимай с большим запасом битрейта, чтобы визуально отличия незаметны были. Только вот с экрана писать само по себе неграмотное решение.
Если ты видео без DRM собираешься записывать, то лучше просто копию исходника сохранять по мере получения. Если с DRM, то тебе записывать просто так система не даст.
>>400019
Транслеруемому видео.
А как грамотно?
В этом и вопрос. Записывают в этом случае экран, web-dl качество получается.
>Идентичного чему?
Транслеруемому видео.
>с экрана писать само по себе неграмотное решение.
А как грамотно?
>Если с DRM, то тебе записывать просто так система не даст.
В этом и вопрос. Записывают в этом случае экран, web-dl качество получается.
>>400024
Хорошо, попробуй просто так записать экран при выводе HDCP-потока без китайских HDMI-сплиттеров и прочих внешних хаков.
Хорошо, попробуй просто так записать экран при выводе HDCP-потока без китайских HDMI-сплиттеров и прочих внешних хаков.
>>365343 (OP)
Можно ли какой-то командой сконвертировать все файлы в папке .m4a в mp3 разом?
Можно ли какой-то командой сконвертировать все файлы в папке .m4a в mp3 разом?
>>401313
Нет.
Нет.
>>401450
Так и раньше можно было энкодить на вк, не?
Так и раньше можно было энкодить на вк, не?
>>401193
Попробовал.
Без RADV_PERFTEST была ошибка:
Скорость та же, что и с:
Попробовал.
> export RADV_PERFTEST=video_decode
> ffmpeg -init_hw_device "vulkan=vk:0" -hwaccel vulkan ...
Без RADV_PERFTEST была ошибка:
> Device does not support the VK_KHR_video_decode_queue extension!
Скорость та же, что и с:
> -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
>>403086
HEVC + xHE-AAC. Контейнер .mp4. Осваивают HEVC (дабавляют в браузеры), через 10-ть лет может и VVC освоят.
HEVC + xHE-AAC. Контейнер .mp4. Осваивают HEVC (дабавляют в браузеры), через 10-ть лет может и VVC освоят.
>>403103
Ты блядь нашей смерти хочешь. Мало того что продвигаешь заведомо проблемный проприетарный видео кодек (хотя к гуглу у меня тоже есть вопросы, куда они смотрят). Так ещё и продвигаешь никем и ничем не поддерживаемый аудиокодек. До такого могли додуматься только эффективные менеджеры из Apple. Ну они всегда так делают, ну ты то чё?
Ты блядь нашей смерти хочешь. Мало того что продвигаешь заведомо проблемный проприетарный видео кодек (хотя к гуглу у меня тоже есть вопросы, куда они смотрят). Так ещё и продвигаешь никем и ничем не поддерживаемый аудиокодек. До такого могли додуматься только эффективные менеджеры из Apple. Ну они всегда так делают, ну ты то чё?
>>403192
Все актуальные ОС уже поддерживают (Windows 11, Android, macOS).
xHE-AAC:
https://www.audioblog.iis.fraunhofer.com/xhe-aac-windows11
https://www.audioblog.iis.fraunhofer.com/adaptive-bitrate-audiocodec-xheaac-apple-amazon-android
>>403192
Да, к Гуглу обратись, они ещё один копрокодек с мылом высрут, создав плюс один никому не нужный копроформат.
Я же, взываю к здравому смыслу: взгляните на стабильность H.264, сколько он беспроблемно просуществовал. И вот, внедряют эффективного наследника, который столько же в потребительском сегменте просуществует. Без VP8, VP9, AV1 и прочего недолговечного пердоцирка.
HEVC, HEIC, xHE-AAC делают в институте Фраунгофера, яббло никакого отношения к данному институту не имеет.
> Так ещё и продвигаешь никем и ничем не поддерживаемый аудиокодек
Все актуальные ОС уже поддерживают (Windows 11, Android, macOS).
xHE-AAC:
https://www.audioblog.iis.fraunhofer.com/xhe-aac-windows11
https://www.audioblog.iis.fraunhofer.com/adaptive-bitrate-audiocodec-xheaac-apple-amazon-android
>>403192
> Мало того что продвигаешь заведомо проблемный проприетарный видео кодек (хотя к гуглу у меня тоже есть вопросы, куда они смотрят).
Да, к Гуглу обратись, они ещё один копрокодек с мылом высрут, создав плюс один никому не нужный копроформат.
Я же, взываю к здравому смыслу: взгляните на стабильность H.264, сколько он беспроблемно просуществовал. И вот, внедряют эффективного наследника, который столько же в потребительском сегменте просуществует. Без VP8, VP9, AV1 и прочего недолговечного пердоцирка.
> До такого могли додуматься только эффективные менеджеры из Apple.
HEVC, HEIC, xHE-AAC делают в институте Фраунгофера, яббло никакого отношения к данному институту не имеет.
>>403103
Почему twitch и youtube не на них? Я же попросил АКТУАЛЬНОЕ, ну почему вы такие тупые? Просиш гавно, а тебе конфетку суют.
Почему twitch и youtube не на них? Я же попросил АКТУАЛЬНОЕ, ну почему вы такие тупые? Просиш гавно, а тебе конфетку суют.
>>403198
В чём его открыть? Пердолиться с плагином под фубар чтобы тот ещё и вылетал? И это ты называешь поддержкой?
Так внедряют, что не могут даже лицензию на HEVC купить, чтобы сделать софтварную имплементацию декодирования. И это Гугл блядь, а не спонсируемые на донаты энтузиасты из Mozilla.
Лучше бы не внедряли. А то блядь пытаются на двух стульях усидеть. И HEVC продвигать стандартом для видео в интернете, и за лицензию не платить.
И главное ведь нахуя? Там же ведь за горизонтом VVC маячит. Неужели нельзя просто пропустить поколение?
Да я про внедрение. Это ведь их бизнес стратегия: внедрять у себя никем не поддерживаемые форматы, чтобы держать своих потребителей на коротком поводке своей экосистемы.
В чём его открыть? Пердолиться с плагином под фубар чтобы тот ещё и вылетал? И это ты называешь поддержкой?
> И вот, внедряют эффективного наследника, который столько же в потребительском сегменте просуществует.
Так внедряют, что не могут даже лицензию на HEVC купить, чтобы сделать софтварную имплементацию декодирования. И это Гугл блядь, а не спонсируемые на донаты энтузиасты из Mozilla.
Лучше бы не внедряли. А то блядь пытаются на двух стульях усидеть. И HEVC продвигать стандартом для видео в интернете, и за лицензию не платить.
И главное ведь нахуя? Там же ведь за горизонтом VVC маячит. Неужели нельзя просто пропустить поколение?
> делают в институте Фраунгофера, яббло никакого отношения к данному институту не имеет.
Да я про внедрение. Это ведь их бизнес стратегия: внедрять у себя никем не поддерживаемые форматы, чтобы держать своих потребителей на коротком поводке своей экосистемы.
>>403203
Что?
>>403086
А это и так всем известно.
Для mp4: h264 + aac.
Для webm: (AV1, VP9, VP8) + (Opus, Vorbis)
В теории ты можешь запихать кодеки из webm, например опус в mp4. В стандарт добавили, но лучше не надо, а то у меня в firefox может не открыться.
Для AV1: https://gitlab.com/AOMediaCodec/SVT-AV1
Для VP9 тоже есть свой SVT, но он только для зеонщиков. libvpx-vp9 жмёт медленно и плохо. Для себя кодировать не рекомендую. Единственная альтернатива это HEVC, но он не для WEBM, а скорее для MPV.
VP8 сейчас актуален только внутри картинок в WEBP. В видео H264 его победил.
По поводу Opus можно порекомендовать только одно: ffmpeg -i audio.flac -ac 2 -c:a libopus -b:a ПОДСТАВЬ_БИТРЕЙТ audio.opus
Многоканальные дорожки лучше кодировать через opusenc.
Vorbis не особо актуален. Если нужна инфа, проси отдельно.
Про AAC мне надоело повторять. Вкратце, если у тебя в ffmpeg нет libfdk_aac, а у тебя его скорее всего нет, то ты сосёшь.
А прям таблички табличной у меня нет. И я не знаю где мне её брать.
> табоичка
Что?
>>403086
> Скиньте табличку что щас актуально в видео и звуке
А это и так всем известно.
Для mp4: h264 + aac.
Для webm: (AV1, VP9, VP8) + (Opus, Vorbis)
В теории ты можешь запихать кодеки из webm, например опус в mp4. В стандарт добавили, но лучше не надо, а то у меня в firefox может не открыться.
Для AV1: https://gitlab.com/AOMediaCodec/SVT-AV1
Для VP9 тоже есть свой SVT, но он только для зеонщиков. libvpx-vp9 жмёт медленно и плохо. Для себя кодировать не рекомендую. Единственная альтернатива это HEVC, но он не для WEBM, а скорее для MPV.
VP8 сейчас актуален только внутри картинок в WEBP. В видео H264 его победил.
По поводу Opus можно порекомендовать только одно: ffmpeg -i audio.flac -ac 2 -c:a libopus -b:a ПОДСТАВЬ_БИТРЕЙТ audio.opus
Многоканальные дорожки лучше кодировать через opusenc.
Vorbis не особо актуален. Если нужна инфа, проси отдельно.
Про AAC мне надоело повторять. Вкратце, если у тебя в ffmpeg нет libfdk_aac, а у тебя его скорее всего нет, то ты сосёшь.
А прям таблички табличной у меня нет. И я не знаю где мне её брать.
>>403203
Что?
>>403086
А это и так всем известно.
Для mp4: h264 + aac.
Для webm: (AV1, VP9, VP8) + (Opus, Vorbis)
В теории ты можешь запихать кодеки из webm, например опус в mp4. В стандарт добавили, но лучше не надо, а то у меня в firefox может не открыться.
Для AV1: https://gitlab.com/AOMediaCodec/SVT-AV1
Для VP9 тоже есть свой SVT, но он только для зеонщиков. libvpx-vp9 жмёт медленно и плохо. Для себя кодировать не рекомендую. Единственная альтернатива это HEVC, но он не для WEBM, а скорее для MPV.
VP8 сейчас актуален только внутри картинок в WEBP. В видео H264 его победил.
По поводу Opus можно порекомендовать только одно: ffmpeg -i audio.flac -ac 2 -c:a libopus -b:a ПОДСТАВЬ_БИТРЕЙТ audio.opus
Многоканальные дорожки лучше кодировать через opusenc.
Vorbis не особо актуален. Если нужна инфа, проси отдельно.
Про AAC мне надоело повторять. Вкратце, если у тебя в ffmpeg нет libfdk_aac, а у тебя его скорее всего нет, то ты сосёшь.
А прям таблички табличной у меня нет. И я не знаю где мне её брать.
> табоичка
Что?
>>403086
> Скиньте табличку что щас актуально в видео и звуке
А это и так всем известно.
Для mp4: h264 + aac.
Для webm: (AV1, VP9, VP8) + (Opus, Vorbis)
В теории ты можешь запихать кодеки из webm, например опус в mp4. В стандарт добавили, но лучше не надо, а то у меня в firefox может не открыться.
Для AV1: https://gitlab.com/AOMediaCodec/SVT-AV1
Для VP9 тоже есть свой SVT, но он только для зеонщиков. libvpx-vp9 жмёт медленно и плохо. Для себя кодировать не рекомендую. Единственная альтернатива это HEVC, но он не для WEBM, а скорее для MPV.
VP8 сейчас актуален только внутри картинок в WEBP. В видео H264 его победил.
По поводу Opus можно порекомендовать только одно: ffmpeg -i audio.flac -ac 2 -c:a libopus -b:a ПОДСТАВЬ_БИТРЕЙТ audio.opus
Многоканальные дорожки лучше кодировать через opusenc.
Vorbis не особо актуален. Если нужна инфа, проси отдельно.
Про AAC мне надоело повторять. Вкратце, если у тебя в ffmpeg нет libfdk_aac, а у тебя его скорее всего нет, то ты сосёшь.
А прям таблички табличной у меня нет. И я не знаю где мне её брать.
>>403283
Щас 2024 на дворе, а ты мне втираеш кодеки и контейнеры которым лет 10 уже, я же попросил актуальные
Щас 2024 на дворе, а ты мне втираеш кодеки и контейнеры которым лет 10 уже, я же попросил актуальные
>>403283
Эта информация устарела на несколько лет
>если у тебя в ffmpeg нет libfdk_aac, а у тебя его скорее всего нет, то ты сосёшь.
Эта информация устарела на несколько лет
>>403287
Так они актуальные и есть. Ну знаешь, VP9 существует уже давно, а я только недавно купил телефон с аппаратным декодированием VP9. Точно так же будет и с AV1.
Ты просил новые, а не актуальные. Нет смысла рассказывать про JPEG Xl, когда его ни хром ни firefox не поддерживают.
>>403291
Ну и где коммиты которые допиливают vbr режим или метод кодирования anmr у встроенного в ffmpeg кодека AAC?
Всё что я видел это минорные файнтюны на базе того же кодека что и был.
Так они актуальные и есть. Ну знаешь, VP9 существует уже давно, а я только недавно купил телефон с аппаратным декодированием VP9. Точно так же будет и с AV1.
Ты просил новые, а не актуальные. Нет смысла рассказывать про JPEG Xl, когда его ни хром ни firefox не поддерживают.
>>403291
Ну и где коммиты которые допиливают vbr режим или метод кодирования anmr у встроенного в ffmpeg кодека AAC?
Всё что я видел это минорные файнтюны на базе того же кодека что и был.
70 Кб, 900x1324>>365343 (OP)
Зачем перекодировать видео, если собираешься хранить оригинал?
Я сейчас не имею в виду юзкейсы типа "хурррр, а я перекодирую и удалю оригинал, дуррррр" или "чтобы запостить на Двач". Речь идёт про перекодирование видео и хранение на харде.
Зачем его перекодировать, если есть оригинал? Зачем перекодировать в AV1, если завтра выйдет AV2? И что, потом всё заново перекодировать? Зачем перекодировать в H265, если оригинал в H264?
Только сегодня задумался над этим вопросом, а до этого слепо перекодировал коллекцию в VP9. А вот аудио я без сожаления кодирую в Opus и удаляю подлинники.
Зачем перекодировать видео, если собираешься хранить оригинал?
Я сейчас не имею в виду юзкейсы типа "хурррр, а я перекодирую и удалю оригинал, дуррррр" или "чтобы запостить на Двач". Речь идёт про перекодирование видео и хранение на харде.
Зачем его перекодировать, если есть оригинал? Зачем перекодировать в AV1, если завтра выйдет AV2? И что, потом всё заново перекодировать? Зачем перекодировать в H265, если оригинал в H264?
Только сегодня задумался над этим вопросом, а до этого слепо перекодировал коллекцию в VP9. А вот аудио я без сожаления кодирую в Opus и удаляю подлинники.
>>405022
Ну выйдет AV2, который будет кодироваться со скоростью меньше 1 fps, и чё? Улучшения в качестве не бесплатны. Чем сильнее сжатие, тем мощнее должен быть CPU чтобы такое вывозить. А у чипмейкеров там какие-то проблемы с выпуском новых техпроцессов. Утоньшать литографию становится всё сложнее.
Короче, AV2 врят-ли кому то нужен без аппаратного ускорения. Ну может ютуб видео миллионники в него перекодирует, на том и ограничатся.
Ну тут скорее вопрос почему это должен быть именно h265.
Зачем перекодировать вообще? Ну смотри. Допустим у тебя этот h264 в 20, если не в 40 мегабит. И ты хочешь уменьшить до приемлемых тебе 5 мегабит. Каким кодеком это лучше делать? Старым h264, или выбирать между h265 или AV1?
> Зачем перекодировать в AV1, если завтра выйдет AV2?
Ну выйдет AV2, который будет кодироваться со скоростью меньше 1 fps, и чё? Улучшения в качестве не бесплатны. Чем сильнее сжатие, тем мощнее должен быть CPU чтобы такое вывозить. А у чипмейкеров там какие-то проблемы с выпуском новых техпроцессов. Утоньшать литографию становится всё сложнее.
Короче, AV2 врят-ли кому то нужен без аппаратного ускорения. Ну может ютуб видео миллионники в него перекодирует, на том и ограничатся.
> Зачем перекодировать в H265, если оригинал в H264?
Ну тут скорее вопрос почему это должен быть именно h265.
Зачем перекодировать вообще? Ну смотри. Допустим у тебя этот h264 в 20, если не в 40 мегабит. И ты хочешь уменьшить до приемлемых тебе 5 мегабит. Каким кодеком это лучше делать? Старым h264, или выбирать между h265 или AV1?
>>405413
Но что именно делает 40 мегабит неприемлемыми, а 5 мегабит приемлемыми? Я хикка, я не буду стримить этот видеофайл для совместного просмотра. Телевизора у меня тоже нет, и все фильмы я смотрю с монитора. Есть ли в таком случае смысл перекодировать видео из родного H264?
Если AV1 и H266 станут вершиной развития видеокодеков, ну хотя бы лет на 15, то тогда это снимает многие мои вопросы. Всё-таки одно дело — перекодировать свою видеоколлекцию раз в 5 лет, и другое — раз в 15 лет. Но всё ещё непонятно, зачем это делать, если я точно собираюсь хранить подлинник.
А, ну и неужели сложно сделать асик для кодирования и декодирования новых кодеков? Просто немного места в процессоре или в видеочипе, которое будет заниматься только одним: кодировать и декодировать видео.
> Допустим у тебя этот h264 в 20, если не в 40 мегабит. И ты хочешь уменьшить до приемлемых тебе 5 мегабит.
Но что именно делает 40 мегабит неприемлемыми, а 5 мегабит приемлемыми? Я хикка, я не буду стримить этот видеофайл для совместного просмотра. Телевизора у меня тоже нет, и все фильмы я смотрю с монитора. Есть ли в таком случае смысл перекодировать видео из родного H264?
> Ну выйдет AV2, который будет кодироваться со скоростью меньше 1 fps, и чё? Улучшения в качестве не бесплатны. Чем сильнее сжатие, тем мощнее должен быть CPU чтобы такое вывозить. А у чипмейкеров там какие-то проблемы с выпуском новых техпроцессов. Утоньшать литографию становится всё сложнее.
> Короче, AV2 врят-ли кому то нужен без аппаратного ускорения. Ну может ютуб видео миллионники в него перекодирует, на том и ограничатся.
Если AV1 и H266 станут вершиной развития видеокодеков, ну хотя бы лет на 15, то тогда это снимает многие мои вопросы. Всё-таки одно дело — перекодировать свою видеоколлекцию раз в 5 лет, и другое — раз в 15 лет. Но всё ещё непонятно, зачем это делать, если я точно собираюсь хранить подлинник.
А, ну и неужели сложно сделать асик для кодирования и декодирования новых кодеков? Просто немного места в процессоре или в видеочипе, которое будет заниматься только одним: кодировать и декодировать видео.
>>405416
Если не хочешь заниматься кодированием, можешь не кодировать. Каждый сам определяет, какой битрейт для него приемлем, исходя из свободного пространства, желаемого уровня качества и личных предпочтений.
Тогда не кодируй. Вопрос только сколько часов ты будешь хранить и где ты возьмёшь столько места.
Nvidia смогла сделать свой асик только в последней серии RTX 40. Тридцатая только с декодером. Маркетинг ли это, или у них там были трудности, не знаю.
> Есть ли в таком случае смысл перекодировать видео из родного H264?
Если не хочешь заниматься кодированием, можешь не кодировать. Каждый сам определяет, какой битрейт для него приемлем, исходя из свободного пространства, желаемого уровня качества и личных предпочтений.
> Но всё ещё непонятно, зачем это делать, если я точно собираюсь хранить подлинник.
Тогда не кодируй. Вопрос только сколько часов ты будешь хранить и где ты возьмёшь столько места.
> А, ну и неужели сложно сделать асик для кодирования и декодирования новых кодеков? Просто немного места в процессоре или в видеочипе, которое будет заниматься только одним: кодировать и декодировать видео.
Nvidia смогла сделать свой асик только в последней серии RTX 40. Тридцатая только с декодером. Маркетинг ли это, или у них там были трудности, не знаю.
>>405431
H.264, VP9. AV1.
На нетфликсе. Но после проёба в суде Броадкому, судя по всему перешли на гугловский копрокодек.
> Ютуб
H.264, VP9. AV1.
> где свежак
На нетфликсе. Но после проёба в суде Броадкому, судя по всему перешли на гугловский копрокодек.
>>405487
Он соснул при зачатии. Так уж вышло, что гугл высирает форматы, которые проигрывают уже имеющимся аналогам. Взять тот же хевц: хевц лучше сжимает, качественнее сжимает, весит почти столько же, сколько и AV1. Но жадность гугла и нежелание платить патентные отчисления кошмару всех пердоликов — Броадкому, создаёт ситуацию, в которой имеем то, что имеем.
Он соснул при зачатии. Так уж вышло, что гугл высирает форматы, которые проигрывают уже имеющимся аналогам. Взять тот же хевц: хевц лучше сжимает, качественнее сжимает, весит почти столько же, сколько и AV1. Но жадность гугла и нежелание платить патентные отчисления кошмару всех пердоликов — Броадкому, создаёт ситуацию, в которой имеем то, что имеем.
>>405497
Но это же не так, AV1 сжимает лучше на всём диапазоне битрейтов. А хевк, в свою очередь, может проигрывать h264 на более высоком битрейте.
>Взять тот же хевц: хевц лучше сжимает, качественнее сжимает, весит почти столько же, сколько и AV1.
Но это же не так, AV1 сжимает лучше на всём диапазоне битрейтов. А хевк, в свою очередь, может проигрывать h264 на более высоком битрейте.
>>405500
Так это ты заявляешь что хевк лучше AV1, ты и тащи свои сравнения. Если погуглить av1 vs hevc, все говорят что AV1 лучше.
Так это ты заявляешь что хевк лучше AV1, ты и тащи свои сравнения. Если погуглить av1 vs hevc, все говорят что AV1 лучше.
>>405644
Вы не понимаете. Поддержку добавили на стриминговую платформу. А то что стримеры стримлят со старой 1650 и у них нет такого кодека, как и денег на новую карточку, это другое.
Вы не понимаете. Поддержку добавили на стриминговую платформу. А то что стримеры стримлят со старой 1650 и у них нет такого кодека, как и денег на новую карточку, это другое.
>>405671
40-я серия, у Intel arc вроде есть, ну ещё можешь радеоны проверить.
40-я серия, у Intel arc вроде есть, ну ещё можешь радеоны проверить.
Дано
Есть фильм, нужно из него вырезать несколько эпизодов, и слить в один файл, уменьшив размер и качество.
Этот редактор сможет это сделать?
Есть фильм, нужно из него вырезать несколько эпизодов, и слить в один файл, уменьшив размер и качество.
Этот редактор сможет это сделать?
>>405850
Сможет, но чем больше эпизодов нужно будет вырезать, тем больнее будет попочке.
Сможет, но чем больше эпизодов нужно будет вырезать, тем больнее будет попочке.
>>405671
Декодирование: нвидиа 3000 / радеон 6000. Энкодирование: нвидиа 4000 / радеон 7000.
Декодирование: нвидиа 3000 / радеон 6000. Энкодирование: нвидиа 4000 / радеон 7000.
Я видел в инете всякие гайды по добавлению ватермарок к видео и фото через ffmpeg, скажите возможно ли ему на вход подать текстовый файл, а на выходе получить к примеру картинки в заданном разрешении и с текстом из каждой строки?
>>405850
./ffmpeg -ss 70.72 -t 20.30 -i xxx.webm -y -c copy xxx.mp4
-ss 70.72
начинаем с 70 секунды и 720 милисекунды
-t 20.30
заканчиваем вырезать через 20 секунд и 300 милесекунд
./ffmpeg -ss 70.72 -t 20.30 -i xxx.webm -y -c copy xxx.mp4
-ss 70.72
начинаем с 70 секунды и 720 милисекунды
-t 20.30
заканчиваем вырезать через 20 секунд и 300 милесекунд
>>407317
Нашел покачто
ffmpeg -f lavfi -i color=blue:size=1280x720 -frames:v 1 -vf drawtext="fontsize=100:fontcolor=yellow:text='Hello World':x=(w-text_w)/2:y=(h-text_h)/2" -y output.jpg
надо будет батник пилить походу под это дело
>а на выходе получить к примеру картинки в заданном разрешении и с текстом из каждой строки?
Нашел покачто
ffmpeg -f lavfi -i color=blue:size=1280x720 -frames:v 1 -vf drawtext="fontsize=100:fontcolor=yellow:text='Hello World':x=(w-text_w)/2:y=(h-text_h)/2" -y output.jpg
надо будет батник пилить походу под это дело
На сколько логических процессоров может масштабироваться svt-av1 на низких пресетах без потери качества сжатия?
87 Кб, 902x558>>407325
Бля, у меня чето шрифты указаные не подгружаются, а все остальное вроде нормально пашет. Че делать то?
Бля, у меня чето шрифты указаные не подгружаются, а все остальное вроде нормально пашет. Че делать то?
>>407417
ебучая винда со своими путями ебет мозги, вот так прописал
./ffmpeg -f lavfi -i color=0xFFFFFF:size=300x100 -frames:v 1 -vf "drawtext=fontfile=C\\:/Users/Nobi/AppData/Local/Microsoft/Windows/Fonts/NotoSansMono_ExtraCondensed-Black.ttf:fontsize=40:fontcolor=0x7F7F7F:text=huipizda:x=(w-text_w)/2:y=(h-text_h)/2" -y test.png
>ля, у меня чето шрифты указаные не подгружаются
ебучая винда со своими путями ебет мозги, вот так прописал
./ffmpeg -f lavfi -i color=0xFFFFFF:size=300x100 -frames:v 1 -vf "drawtext=fontfile=C\\:/Users/Nobi/AppData/Local/Microsoft/Windows/Fonts/NotoSansMono_ExtraCondensed-Black.ttf:fontsize=40:fontcolor=0x7F7F7F:text=huipizda:x=(w-text_w)/2:y=(h-text_h)/2" -y test.png
>>409053
ffprobe даст тебе подробнейшую информацию по всем кадрам в потоке. Есть для фильтрации еë вывода в интернете скрипты.
Если хочется интерактивное средство, то бери avidemux.
Но я даже представить себе не могу, зачем тебе потребовалось то, что ты спрашиваешь.
ffprobe даст тебе подробнейшую информацию по всем кадрам в потоке. Есть для фильтрации еë вывода в интернете скрипты.
Если хочется интерактивное средство, то бери avidemux.
Но я даже представить себе не могу, зачем тебе потребовалось то, что ты спрашиваешь.
7 Кб, 123x125>>409067
Спасибо. Ну мне это нужно чисто в познавательных целях, для сравнения результата кодирования разных кодеков.
Спасибо. Ну мне это нужно чисто в познавательных целях, для сравнения результата кодирования разных кодеков.
>>405850
Вроде да, но заёбно конечно, особенно если сотня кусков надо.
Вроде да, но заёбно конечно, особенно если сотня кусков надо.
Нужно уменьшить разрешение видосов для старой мобилки до 640х360. Исходники абсолютно разные, вплоть до квадратных 1:1. Как заставить ффмпег сохранять пропорции оригинала? Желательно отдельно варианты:
- обрезать "лишнее" видео сверху и снизу
- добавить чёрные полосы слева и справа
Пробовал и -s 640x360, и -vf scale=640:360 - и то и это "расплющивает" квадратные видосы под прямоугольные 16:9.
а ещё есть исходники не просто вертикальные с разрешением типа 1080х1920, а обычное фуллхд, но по факту вертикальное 600х1080, а огромные куски слева и справа - чёрные квадраты. Тут только вручную вырезать -vf crop=600:1080:650:0 нужный вертикальный кусок из центра и потом уже его поворачивать -vf transpose=2 и ресайзить до 640х360
- обрезать "лишнее" видео сверху и снизу
- добавить чёрные полосы слева и справа
Пробовал и -s 640x360, и -vf scale=640:360 - и то и это "расплющивает" квадратные видосы под прямоугольные 16:9.
а ещё есть исходники не просто вертикальные с разрешением типа 1080х1920, а обычное фуллхд, но по факту вертикальное 600х1080, а огромные куски слева и справа - чёрные квадраты. Тут только вручную вырезать -vf crop=600:1080:650:0 нужный вертикальный кусок из центра и потом уже его поворачивать -vf transpose=2 и ресайзить до 640х360
>>410957
Запердоль скрипт на питоне.
Масштабирование с сохранением соотношением сторон ещё можно реализовать одним командлайном. Но детектинг наличия чёрных полос и где обрезать уже требует пердолинга.
Запердоль скрипт на питоне.
Масштабирование с сохранением соотношением сторон ещё можно реализовать одним командлайном. Но детектинг наличия чёрных полос и где обрезать уже требует пердолинга.
Специфический запрос.
Есть "кинотеатральная" widescreen версия фильма (2.35:1) в виде нетронутого видеопотока с блюрея (ремукс), то есть 1920x1080 с черными полосами.
Есть open matte 16:9 версия в виде hdtv-рипа в 720x576 с неквадратными пикселями (...зачем...), с другим фпс (25 против 23.976) и интерлейс вместо прогрессива. Open matte - это более полный кадр по вертикали по сравнению со стандартным релизом. Такие версии крайне редко выходят официально, они обычно для hdtv или иногда стримингов.
Хочу взять конкретную сцену из фильма и:
1) подложить open matte под widescreen, совместив содержимое кадра, чтобы по центру было максимальное качество с ремукса, а сверху и снизу - LQ куски опен матте, которые были бы "над" черными полями кадра 1920x1080, но естественно не заслоняли осмысленное содержимое кадров ремукса посередине. Готов поебаться вручную в пейнте и выдрочить правильное расположение опен матте кадра прямо пиксель-в-пиксель.
2) экспортнуть результат в набор кадров в пнг
И всё это - в один проход, без перекодирований во всякие h264 десять раз в процессе.
Мнения? Я ебанулся? Возможно, мне лучше перегнать сами исходные видео в наборы кадров пнг, а уже потом как-то наколхозить batch обработку этих синхронизированных друг с другом наборов пнгшек (кроп и прочее)?
Есть "кинотеатральная" widescreen версия фильма (2.35:1) в виде нетронутого видеопотока с блюрея (ремукс), то есть 1920x1080 с черными полосами.
Есть open matte 16:9 версия в виде hdtv-рипа в 720x576 с неквадратными пикселями (...зачем...), с другим фпс (25 против 23.976) и интерлейс вместо прогрессива. Open matte - это более полный кадр по вертикали по сравнению со стандартным релизом. Такие версии крайне редко выходят официально, они обычно для hdtv или иногда стримингов.
Хочу взять конкретную сцену из фильма и:
1) подложить open matte под widescreen, совместив содержимое кадра, чтобы по центру было максимальное качество с ремукса, а сверху и снизу - LQ куски опен матте, которые были бы "над" черными полями кадра 1920x1080, но естественно не заслоняли осмысленное содержимое кадров ремукса посередине. Готов поебаться вручную в пейнте и выдрочить правильное расположение опен матте кадра прямо пиксель-в-пиксель.
2) экспортнуть результат в набор кадров в пнг
И всё это - в один проход, без перекодирований во всякие h264 десять раз в процессе.
Мнения? Я ебанулся? Возможно, мне лучше перегнать сами исходные видео в наборы кадров пнг, а уже потом как-то наколхозить batch обработку этих синхронизированных друг с другом наборов пнгшек (кроп и прочее)?
>>410978
Я не очень понял вопрос. Но ffmpeg позволяет делать композицию видео. Там для этого есть фильтр overlay. Вот можешь почитать на тему: https://stackoverflow.com/questions/42519757/ffmpeg-compositing-a-video-within-a-video-in-the-centre
Для подгонки fps можешь использовать фильтры fps или framerate.
Для кропа чёрных полос есть фильтр crop. Для ресайза scale.
Твоя задача загнать всё это в filter complex в правильном порядке и подобрать параметры так чтобы выполнить задачу 1.
По поводу PNG секвенций читай тут https://natron.readthedocs.io/en/rb-2.5/guide/tutorials-imagesequence.html#ffmpeg
Но я бы тебе не советовал бы тебе использовать PNG sequence если ты не знаешь зачем тебе секвенция и почему именно в PNG. Есть lossless видео кодеки, есть монтажные кодеки. Сжатие видео не ограничивается просмотровыми кодеками, вроде упомянутого тобой h264.
Я не очень понял вопрос. Но ffmpeg позволяет делать композицию видео. Там для этого есть фильтр overlay. Вот можешь почитать на тему: https://stackoverflow.com/questions/42519757/ffmpeg-compositing-a-video-within-a-video-in-the-centre
Для подгонки fps можешь использовать фильтры fps или framerate.
Для кропа чёрных полос есть фильтр crop. Для ресайза scale.
Твоя задача загнать всё это в filter complex в правильном порядке и подобрать параметры так чтобы выполнить задачу 1.
По поводу PNG секвенций читай тут https://natron.readthedocs.io/en/rb-2.5/guide/tutorials-imagesequence.html#ffmpeg
Но я бы тебе не советовал бы тебе использовать PNG sequence если ты не знаешь зачем тебе секвенция и почему именно в PNG. Есть lossless видео кодеки, есть монтажные кодеки. Сжатие видео не ограничивается просмотровыми кодеками, вроде упомянутого тобой h264.
>>411028
Спасибо!
Чтобы гифки нарезать.
Да, само собой.
Спасибо!
>Но я бы тебе не советовал бы тебе использовать PNG sequence если ты не знаешь зачем тебе секвенция и почему именно в PNG.
Чтобы гифки нарезать.
>Есть lossless видео кодеки, есть монтажные кодеки. Сжатие видео не ограничивается просмотровыми кодеками
Да, само собой.
>>411028
Ну типа вот пикрил:
1 пик - блюрей
2 пик - опен матте вебдл с более полным кадром, но заметно более хуевым качеством
3 пик - гибридный рип, сделанный добрым человеком с прямыми руками, который наложил блюрей (без полос, естественно) на опен матте вебдл
При этом, обрати внимание, опен матте не накладывается на вайдскрин совсем наивно, типа пиксель-в-пиксель с раскрытием блюрейной/кинотеатральной версии вверх и вниз до 1920x1080, а лежит как-то примерно как пик 4, по техническим и художественным причинам.
>Я не очень понял вопрос.
Ну типа вот пикрил:
1 пик - блюрей
2 пик - опен матте вебдл с более полным кадром, но заметно более хуевым качеством
3 пик - гибридный рип, сделанный добрым человеком с прямыми руками, который наложил блюрей (без полос, естественно) на опен матте вебдл
При этом, обрати внимание, опен матте не накладывается на вайдскрин совсем наивно, типа пиксель-в-пиксель с раскрытием блюрейной/кинотеатральной версии вверх и вниз до 1920x1080, а лежит как-то примерно как пик 4, по техническим и художественным причинам.
>>411031
Перед -i пиши -ss и время начала. А потом перед именем гифки пиши -t и указывай продолжительность.
А ещё там надо пердолиться с палитрой.
Вот тут поподробнее https://superuser.com/questions/556029/how-do-i-convert-a-video-to-gif-using-ffmpeg-with-reasonable-quality
>>411033
Если эти картинки и есть твоё видео, то я ни виду существенных отличий от обрезанного по центру ремукса.
Там алгоритм простой:
1. Обрезаешь чёрные полосы у ремукса фильтром crop.
2. Из обрезанного видео создаём 2 одинаковых обрезанных видео фильтром split.
3. Масштабируешь одну копию видео так чтобы она заполнила весь холст фильтром scale, после чего обрезаешь его по центру фильтром crop.
4. Объединяешь эти 2 видео в одно фильтром overlay.
> Чтобы гифки нарезать.
Перед -i пиши -ss и время начала. А потом перед именем гифки пиши -t и указывай продолжительность.
А ещё там надо пердолиться с палитрой.
Вот тут поподробнее https://superuser.com/questions/556029/how-do-i-convert-a-video-to-gif-using-ffmpeg-with-reasonable-quality
>>411033
Если эти картинки и есть твоё видео, то я ни виду существенных отличий от обрезанного по центру ремукса.
Там алгоритм простой:
1. Обрезаешь чёрные полосы у ремукса фильтром crop.
2. Из обрезанного видео создаём 2 одинаковых обрезанных видео фильтром split.
3. Масштабируешь одну копию видео так чтобы она заполнила весь холст фильтром scale, после чего обрезаешь его по центру фильтром crop.
4. Объединяешь эти 2 видео в одно фильтром overlay.
>>411039
Если честно, я пока что для гифок из наборов пнг/жпг/бмп использую онлайн-тулзы (да, знаю, зря), которые делали норм.
gifmaker.me делал охуенные цвета ценой не раздражающего дизеринга, который тем более очень уместен для фотографического/киношного материала, потому что похож на киношный ламповый шум. Первые два пикрила.
Но он умер (вот потому и зря), а ezgif ебашит цвета бандингом (пикрил 3), еще и без темпоральной стабильности этого бандинга, что заставляет меня грустить.
А сами пнг для кадров гифки вырезаю из видео с помощью VirtualDub'а, где можно выдрочить с точностью до кадра, сразу указать пропуск каждого второго (если слишком тяжеловесно хуярить все 24/30 родных кадров в секунду), кропнуть содержимое кадра как надо и т.д. Все-таки гуи в этом деле в сто раз удобнее (ну хотя бы для референса, чтобы заранее посмотреть, по каким цифрам резать), чем консоль.
Не, это готовый пример под рукой. Отличия - в большей наполненности кадра сверху и снизу. Автор "гибридного рипа" выбрал вариант взять за основу расположение опен матте версии и поэтому чуть-чуть укрупнить / zoom in блюрейную картинку, чуточку потеряв в пиксель-перфект четкости, но также, бывает, делают как на пикрил 4 в моем сообщении выше, оставляя по углам черные прямоугольники или заливая их градиентом интерполяции с краев двух исходных кадров.
>А ещё там надо пердолиться с палитрой.
Если честно, я пока что для гифок из наборов пнг/жпг/бмп использую онлайн-тулзы (да, знаю, зря), которые делали норм.
gifmaker.me делал охуенные цвета ценой не раздражающего дизеринга, который тем более очень уместен для фотографического/киношного материала, потому что похож на киношный ламповый шум. Первые два пикрила.
Но он умер (вот потому и зря), а ezgif ебашит цвета бандингом (пикрил 3), еще и без темпоральной стабильности этого бандинга, что заставляет меня грустить.
А сами пнг для кадров гифки вырезаю из видео с помощью VirtualDub'а, где можно выдрочить с точностью до кадра, сразу указать пропуск каждого второго (если слишком тяжеловесно хуярить все 24/30 родных кадров в секунду), кропнуть содержимое кадра как надо и т.д. Все-таки гуи в этом деле в сто раз удобнее (ну хотя бы для референса, чтобы заранее посмотреть, по каким цифрам резать), чем консоль.
> Если эти картинки и есть твоё видео, то я ни виду существенных отличий от обрезанного по центру ремукса.
Не, это готовый пример под рукой. Отличия - в большей наполненности кадра сверху и снизу. Автор "гибридного рипа" выбрал вариант взять за основу расположение опен матте версии и поэтому чуть-чуть укрупнить / zoom in блюрейную картинку, чуточку потеряв в пиксель-перфект четкости, но также, бывает, делают как на пикрил 4 в моем сообщении выше, оставляя по углам черные прямоугольники или заливая их градиентом интерполяции с краев двух исходных кадров.
>>411823
Имагинировал ебало чела который сидит не спит и ждёт когда ему ровно в 00:00 принесут батник на двачи.
Имагинировал ебало чела который сидит не спит и ждёт когда ему ровно в 00:00 принесут батник на двачи.
Так, стоп, выходит я всё время неправильно и неоптимально жал шебмки с видосами? С аудиокодеками заморачивался, а тут как-то забил. Просто вводил какой-то битрейт для конкретного разрешения и выходили либо огромные файлы, либо шакально. В параметрах оказывается есть пресеты качества и по дефолту далеко не самый крутой, профили, всякие cq, crf, opencl, подстройки под сам видос - слайдшоу/кинцо/плёнка, и даже кодирование в два прохода. Ещё и сам ффмпег могу юзать нитакой, всегда качал отсюда: https://www.gyan.dev/ffmpeg/builds/ffmpeg-git-full.7z . Или можно небось видюхой жать в xx раз быстрее, а не только процом. Задача в общем-то проста - получить мммаксимально малюсенький mp4-файл (видео x264, аудио aac) нужного разрешения (например 640х360 или fullhd) с любым фпс до 60, лишь бы выглядело чисто и без квадратов на быстро меняющихся сценах. Двухпроходный вариант с crf есть или только на vp9? Какими настройками можно выжать всё-превсё по максимуму, а не просто -c:v libx264?
Вот есть видео, 1000 кадров, 100 мегабайт.
Почему нельзя просто отрезать 500 кадров и оставить только остальные 500, и чтоб при этом видео весило 50 мг? Какого хуя видео вырастает до 300 мб?
Почему нельзя просто отрезать 500 кадров и оставить только остальные 500, и чтоб при этом видео весило 50 мг? Какого хуя видео вырастает до 300 мб?
>>411889
Можно отрезать по ближайшему ключевому кадру, это ты зачем-то всё перекодируешь.
Можно отрезать по ближайшему ключевому кадру, это ты зачем-то всё перекодируешь.
>>411870
Выбери одно.
H264 уже давно не про максимальное сжатие. А оптимальное пожатие aac требует компиляции своего билда ffmpeg, потому что libfdkaac не входит в публично распространяемые исполняемые файлы по причинам лицензионных ограничений.
Такая вещь не является нормой. Это порождение ограничений libvpx и libaom.
libsvtav1 умеет жать в crf не требуя второго прохода, подобно тому как это происходит в x264 и x265.
Ты ждёшь от меня универсальных гайдов, но таких нет. Но одно я могу сказать наверняка: vp9 устарел, vp8 засохшее говно мамонта.
Причина по которой vp9 устарел заключается даже не в наличии AV1, а в отсутствии надлежащей поддержки. Референсный libvpx-vp9 жмёт медленно и плохо паралелится. Отсутсвуют аналоги не то что x264/5, но даже аналоги svt av1. Тот svt vp9 что есть работает только на некоторых зеонах (то есть на твоём райзене не запустится), не умеет жрать вход из пайпа, и никто даже не чешется улучшать этот самый svt vp9. Аппаратного ускорения сжатия нет и не предвидеться.
В сфере сжатия аудио opus вытесняет aac. Сейчас это серебрянная пуля. Пользоваться им проще простого: -c:a libopus -b:a 64k. Ну можешь битрейт повыше поставить, если у тебя в лимит влезет. Из ограничений только то что в ffmpeg для libopus поддержку многоканала вроде как не завезли и неизвестно когда завезут.
В сфере сжатия видео идёт соперничество между h265 и AV1. H265 берёт широкой аппаратной поддержкой, в том числе и кодирования, а также наличием кодировщика x265. AV1 берёт открытостью, местами лучшим сжатием, поддержкой со стороны браузеров, и перспективами дальнейшего повсеместного внедрения. Уже есть аппаратная поддержка декодирования AV1 во флагманских смартфонах и у карточек nvidia c 3000-й серии. С 4000-й серии добавили аппаратное кодирование.
Какие-то гайды есть, но выбирать параметры кодирования тебе придётся самому, под твои предпочтения.
https://kokomins.wordpress.com/2019/10/10/anime-encoding-guide-for-x265-and-why-to-never-use-flac/
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/README.md?ref_type=heads
> мммаксимально малюсенький mp4-файл
> (видео x264, аудио aac)
> шебмки с видосами
Выбери одно.
H264 уже давно не про максимальное сжатие. А оптимальное пожатие aac требует компиляции своего билда ffmpeg, потому что libfdkaac не входит в публично распространяемые исполняемые файлы по причинам лицензионных ограничений.
> Двухпроходный вариант с crf есть или только на vp9?
Такая вещь не является нормой. Это порождение ограничений libvpx и libaom.
libsvtav1 умеет жать в crf не требуя второго прохода, подобно тому как это происходит в x264 и x265.
Ты ждёшь от меня универсальных гайдов, но таких нет. Но одно я могу сказать наверняка: vp9 устарел, vp8 засохшее говно мамонта.
Причина по которой vp9 устарел заключается даже не в наличии AV1, а в отсутствии надлежащей поддержки. Референсный libvpx-vp9 жмёт медленно и плохо паралелится. Отсутсвуют аналоги не то что x264/5, но даже аналоги svt av1. Тот svt vp9 что есть работает только на некоторых зеонах (то есть на твоём райзене не запустится), не умеет жрать вход из пайпа, и никто даже не чешется улучшать этот самый svt vp9. Аппаратного ускорения сжатия нет и не предвидеться.
В сфере сжатия аудио opus вытесняет aac. Сейчас это серебрянная пуля. Пользоваться им проще простого: -c:a libopus -b:a 64k. Ну можешь битрейт повыше поставить, если у тебя в лимит влезет. Из ограничений только то что в ffmpeg для libopus поддержку многоканала вроде как не завезли и неизвестно когда завезут.
В сфере сжатия видео идёт соперничество между h265 и AV1. H265 берёт широкой аппаратной поддержкой, в том числе и кодирования, а также наличием кодировщика x265. AV1 берёт открытостью, местами лучшим сжатием, поддержкой со стороны браузеров, и перспективами дальнейшего повсеместного внедрения. Уже есть аппаратная поддержка декодирования AV1 во флагманских смартфонах и у карточек nvidia c 3000-й серии. С 4000-й серии добавили аппаратное кодирование.
Какие-то гайды есть, но выбирать параметры кодирования тебе придётся самому, под твои предпочтения.
https://kokomins.wordpress.com/2019/10/10/anime-encoding-guide-for-x265-and-why-to-never-use-flac/
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/README.md?ref_type=heads
>>411870
Выбери одно.
H264 уже давно не про максимальное сжатие. А оптимальное пожатие aac требует компиляции своего билда ffmpeg, потому что libfdkaac не входит в публично распространяемые исполняемые файлы по причинам лицензионных ограничений.
Такая вещь не является нормой. Это порождение ограничений libvpx и libaom.
libsvtav1 умеет жать в crf не требуя второго прохода, подобно тому как это происходит в x264 и x265.
Ты ждёшь от меня универсальных гайдов, но таких нет. Но одно я могу сказать наверняка: vp9 устарел, vp8 засохшее говно мамонта.
Причина по которой vp9 устарел заключается даже не в наличии AV1, а в отсутствии надлежащей поддержки. Референсный libvpx-vp9 жмёт медленно и плохо паралелится. Отсутсвуют аналоги не то что x264/5, но даже аналоги svt av1. Тот svt vp9 что есть работает только на некоторых зеонах (то есть на твоём райзене не запустится), не умеет жрать вход из пайпа, и никто даже не чешется улучшать этот самый svt vp9. Аппаратного ускорения сжатия нет и не предвидеться.
В сфере сжатия аудио opus вытесняет aac. Сейчас это серебрянная пуля. Пользоваться им проще простого: -c:a libopus -b:a 64k. Ну можешь битрейт повыше поставить, если у тебя в лимит влезет. Из ограничений только то что в ffmpeg для libopus поддержку многоканала вроде как не завезли и неизвестно когда завезут.
В сфере сжатия видео идёт соперничество между h265 и AV1. H265 берёт широкой аппаратной поддержкой, в том числе и кодирования, а также наличием кодировщика x265. AV1 берёт открытостью, местами лучшим сжатием, поддержкой со стороны браузеров, и перспективами дальнейшего повсеместного внедрения. Уже есть аппаратная поддержка декодирования AV1 во флагманских смартфонах и у карточек nvidia c 3000-й серии. С 4000-й серии добавили аппаратное кодирование.
Какие-то гайды есть, но выбирать параметры кодирования тебе придётся самому, под твои предпочтения.
https://kokomins.wordpress.com/2019/10/10/anime-encoding-guide-for-x265-and-why-to-never-use-flac/
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/README.md?ref_type=heads
> мммаксимально малюсенький mp4-файл
> (видео x264, аудио aac)
> шебмки с видосами
Выбери одно.
H264 уже давно не про максимальное сжатие. А оптимальное пожатие aac требует компиляции своего билда ffmpeg, потому что libfdkaac не входит в публично распространяемые исполняемые файлы по причинам лицензионных ограничений.
> Двухпроходный вариант с crf есть или только на vp9?
Такая вещь не является нормой. Это порождение ограничений libvpx и libaom.
libsvtav1 умеет жать в crf не требуя второго прохода, подобно тому как это происходит в x264 и x265.
Ты ждёшь от меня универсальных гайдов, но таких нет. Но одно я могу сказать наверняка: vp9 устарел, vp8 засохшее говно мамонта.
Причина по которой vp9 устарел заключается даже не в наличии AV1, а в отсутствии надлежащей поддержки. Референсный libvpx-vp9 жмёт медленно и плохо паралелится. Отсутсвуют аналоги не то что x264/5, но даже аналоги svt av1. Тот svt vp9 что есть работает только на некоторых зеонах (то есть на твоём райзене не запустится), не умеет жрать вход из пайпа, и никто даже не чешется улучшать этот самый svt vp9. Аппаратного ускорения сжатия нет и не предвидеться.
В сфере сжатия аудио opus вытесняет aac. Сейчас это серебрянная пуля. Пользоваться им проще простого: -c:a libopus -b:a 64k. Ну можешь битрейт повыше поставить, если у тебя в лимит влезет. Из ограничений только то что в ffmpeg для libopus поддержку многоканала вроде как не завезли и неизвестно когда завезут.
В сфере сжатия видео идёт соперничество между h265 и AV1. H265 берёт широкой аппаратной поддержкой, в том числе и кодирования, а также наличием кодировщика x265. AV1 берёт открытостью, местами лучшим сжатием, поддержкой со стороны браузеров, и перспективами дальнейшего повсеместного внедрения. Уже есть аппаратная поддержка декодирования AV1 во флагманских смартфонах и у карточек nvidia c 3000-й серии. С 4000-й серии добавили аппаратное кодирование.
Какие-то гайды есть, но выбирать параметры кодирования тебе придётся самому, под твои предпочтения.
https://kokomins.wordpress.com/2019/10/10/anime-encoding-guide-for-x265-and-why-to-never-use-flac/
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/README.md?ref_type=heads
>>412012
Спасибо, очень развёрнуто. Понятно что всё устарело, кодирую для старых девайсов - они никакие x265, webm и тем более av1 не тащат. Но как оказалось и x264 не всякое жуют!
Мобилка начала десятых играет максимум -preset slow, всё выше - картинки нет, аудио есть.
Смарт-телик середины десятых почему-то вообще в отказ, даже просто -c:v libx264 -c:a aac. "В настоящее время этот формат не поддерживается" и всё. Надо откопать что за модель и что точно он поддерживает.
Спасибо, очень развёрнуто. Понятно что всё устарело, кодирую для старых девайсов - они никакие x265, webm и тем более av1 не тащат. Но как оказалось и x264 не всякое жуют!
Мобилка начала десятых играет максимум -preset slow, всё выше - картинки нет, аудио есть.
Смарт-телик середины десятых почему-то вообще в отказ, даже просто -c:v libx264 -c:a aac. "В настоящее время этот формат не поддерживается" и всё. Надо откопать что за модель и что точно он поддерживает.
>>412036
Там дело не в пресетах, а в профилях и уровнях.
Когда ты включаешь пресет медленнее, он активирует опции, которые улучшают сжатие, но снижают совместимость. Тот же CABAC, количество b кадров, например.
Есть 3 основных профиля и куча производных от них. Основные профили это baseline, main, high.
Baseline самый слабый, когда то для айфонов кодировали в этом профиле.
Main это что-то среднее, вроде как для SD контента.
High это самый сильный профиль, предназначенный для HD контента и включает такие опции как CABAC.
Ну и уровни, которые указывают максимальное разрешение и частоту кадров, которые этот декодер должен декодировать. Там от 1.1 до 5.0 или 5.1, не помню точно.
Читал мануалы на торрент форумах, там рекомендуют кодировать в уровень 4.1 для 1080p. Но это если частота кадров не превышает 30. Уровень 4.2 позволяет уже до 60 fps.
Так вот, профиль и уровень переопределяют настройки пресета. Так что ты можешь поставить хоть placebo, но если ты правильно указал уровень и профиль, то всё должно работать.
Узнать профиль и уровень ты должен в спецификации устройства. Но если такой нет, найди методом перебора. А ещё учти, что чтобы попасть в уровень, тебе возможно понадобится снижать разрешение и количество кадров в секунду. Сам кодировщик этого не сделает.
https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels
Там дело не в пресетах, а в профилях и уровнях.
Когда ты включаешь пресет медленнее, он активирует опции, которые улучшают сжатие, но снижают совместимость. Тот же CABAC, количество b кадров, например.
Есть 3 основных профиля и куча производных от них. Основные профили это baseline, main, high.
Baseline самый слабый, когда то для айфонов кодировали в этом профиле.
Main это что-то среднее, вроде как для SD контента.
High это самый сильный профиль, предназначенный для HD контента и включает такие опции как CABAC.
Ну и уровни, которые указывают максимальное разрешение и частоту кадров, которые этот декодер должен декодировать. Там от 1.1 до 5.0 или 5.1, не помню точно.
Читал мануалы на торрент форумах, там рекомендуют кодировать в уровень 4.1 для 1080p. Но это если частота кадров не превышает 30. Уровень 4.2 позволяет уже до 60 fps.
Так вот, профиль и уровень переопределяют настройки пресета. Так что ты можешь поставить хоть placebo, но если ты правильно указал уровень и профиль, то всё должно работать.
Узнать профиль и уровень ты должен в спецификации устройства. Но если такой нет, найди методом перебора. А ещё учти, что чтобы попасть в уровень, тебе возможно понадобится снижать разрешение и количество кадров в секунду. Сам кодировщик этого не сделает.
https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels
>>412058
Ну например так, исходники всякие - от 1280х720 до 4K, от 25 фпс до 60:
ffmpeg -i test.mp4 -vf scale=640:360 -c:v libx264 -preset slow -crf 28 -c:a copy test1.mp4
> правильно указал уровень и профиль
Ну например так, исходники всякие - от 1280х720 до 4K, от 25 фпс до 60:
ffmpeg -i test.mp4 -vf scale=640:360 -c:v libx264 -preset slow -crf 28 -c:a copy test1.mp4
>>412064
Для сохранение соотношения сторон, насколько это возможно, ты мог бы сделать так:
или так, в случае если ты обрезал чёрные полосы у источника
К сожалению, не существует способа, как вписать картинку в прямоугольник, чтобы выходная ширина и высота видео всегда были чётными, в рамках одной команды ffmpeg. Такое надо считать для каждого видео отдельно, или сделать отдельный скрипт для этого. Также мы не можем в рамках только одной команды ffmpeg уполовинить количество кадров в секунду, когда количество кадров превышает заданный порог, такой как 30 например.
Разрешение 360p при 30 fps примерно соответствует уровню 3.0
> scale=640:360
Для сохранение соотношения сторон, насколько это возможно, ты мог бы сделать так:
> scale=-2:360
или так, в случае если ты обрезал чёрные полосы у источника
> scale=640:-2
К сожалению, не существует способа, как вписать картинку в прямоугольник, чтобы выходная ширина и высота видео всегда были чётными, в рамках одной команды ffmpeg. Такое надо считать для каждого видео отдельно, или сделать отдельный скрипт для этого. Также мы не можем в рамках только одной команды ffmpeg уполовинить количество кадров в секунду, когда количество кадров превышает заданный порог, такой как 30 например.
Разрешение 360p при 30 fps примерно соответствует уровню 3.0
>>412051
Ок, заменил slower на slow.
Ок, заменил slower на slow.
>>412036
Так, сосунг ue32j5500aw. В мануале заявлено всё что можно - и h263, и h264, и hevc, и даже vp8. А на сайтах магазинов из всей мультимедии только
Ну окау, есть скажем 1920х1080 видосы с мобилы, которые я разжал в лосслесс -c:v huffyuv -c:a pcm_s16le, потом фиксил тряску тем же ффмпегом и размножил нейронкой flowframes фпс с 30 до 60 - во что их кодировать, чтобы пошло на этом телике?
проще комп подрубить в режиме моника похоже
> Надо откопать
Так, сосунг ue32j5500aw. В мануале заявлено всё что можно - и h263, и h264, и hevc, и даже vp8. А на сайтах магазинов из всей мультимедии только
> MP3, WMA, MPEG4, DivX, MKV, JPEG
Ну окау, есть скажем 1920х1080 видосы с мобилы, которые я разжал в лосслесс -c:v huffyuv -c:a pcm_s16le, потом фиксил тряску тем же ффмпегом и размножил нейронкой flowframes фпс с 30 до 60 - во что их кодировать, чтобы пошло на этом телике?
проще комп подрубить в режиме моника похоже
>>412087
Во первых, не факт что твой телик может в 60 fps.
Из его характеристик известно, что у него экран 1920x1080. Из этого следует то, что он должен жрать 1080p видео, типичное количество кадров которого обычно не превышает 30.
Исходя из этого, я предполагаю, что он должен поддерживать профиль high уровня 4.1
Прямо так и пишешь -c:v libx264 -profile:v high -level:v 4.1
Если не будет работать, можешь ещё -bf 3 добавить.
Во первых, не факт что твой телик может в 60 fps.
Из его характеристик известно, что у него экран 1920x1080. Из этого следует то, что он должен жрать 1080p видео, типичное количество кадров которого обычно не превышает 30.
Исходя из этого, я предполагаю, что он должен поддерживать профиль high уровня 4.1
Прямо так и пишешь -c:v libx264 -profile:v high -level:v 4.1
Если не будет работать, можешь ещё -bf 3 добавить.
А можно ли строчкой задать условие "если битрейт аудио оригинала >130 кбит, то пожать в дефолтный aac, моно (60-70 кбит)"? Или только батник пилить?
>>412281
Для этого нужно подключать ffprobe, без скрипта не обойтись.
Для этого нужно подключать ffprobe, без скрипта не обойтись.
Как заставить ффмпег не менять дату оригинального файла? Вот говно мамонта из 2003 года и чтоб полученная шебмка/мп4 тоже имела дату изменения 2003. Или никак?
>>412478
В линуксе есть touch -r <оригинальный файл> <новый файл>, копирует дату изменение с оригинального файла в новый.
Может в винде есть что-то такое же, ищи.
В линуксе есть touch -r <оригинальный файл> <новый файл>, копирует дату изменение с оригинального файла в новый.
Может в винде есть что-то такое же, ищи.
>>411031 >>411044 >>411189 >>411192
Это называется форс-мажор, сука.
https://pastebin.com/mwUVX4Cq
>уже понедельник пиздабол где
Это называется форс-мажор, сука.
https://pastebin.com/mwUVX4Cq
23 Кб, 1507x183>>412740
Таки сляпал всё в единый батник. И x264 с нужным пресетом-качеством-разрешением, и aac в моно с микробитрейтом, и обрезка инфразвука с компрессией, и полное сохранение даты.
Таки сляпал всё в единый батник. И x264 с нужным пресетом-качеством-разрешением, и aac в моно с микробитрейтом, и обрезка инфразвука с компрессией, и полное сохранение даты.
28 Кб, 1223x132У меня для вас новость
ffmpeg поддерживает VVC
ffmpeg поддерживает VVC
Господа специалисты по видеофайлам, нужен ваш фидбек.
На доске /mov/ про фильмы в шапке торрент-треда среди прочего есть гайд о том, что делать, если чуть-чуть недокачался файл из полумертвой раздачи, который сводит с ума видеоплееры, и можно ли это как-то починить.
Вот текущая версия, которую я написал пару месяцев назад: https://pastebin.com/BcQKSVxZ
Как легко заметить, она не дописана в конце (раздел для любопытных аутистов, которым интересно знать, почему так происходит). Причину того, почему может не скачаться конец файла, я отлично знаю и расписал максимально подробно, а вот почему именно недокачанный конец приводит к таким спецэффектам - в этой теме я "плаваю". Знаю ситуацию в общих чертах и также знаю, что линейные редакторы типа avidemux, virtualdub (и в частности mkvtoolnix при работе с содержимым файла) честно дотошно читают весь файл целиком и изучают, что у него лежит на каких таймстампах, прежде чем дать пользователю скакать по нему. Но писать свои додумывания - возможно, откровенно ошибочные - не хочу.
Что бы вы дописали в тот недописанный в конце раздел, или мб даже что бы вы исправили в том, что уже написано?
С меня нихуя, но этот текст будет висеть в перекатах торрент-треда в обозримом будущем и мб кому-то поможет, ну или хотя бы кого-то просветит.
На доске /mov/ про фильмы в шапке торрент-треда среди прочего есть гайд о том, что делать, если чуть-чуть недокачался файл из полумертвой раздачи, который сводит с ума видеоплееры, и можно ли это как-то починить.
Вот текущая версия, которую я написал пару месяцев назад: https://pastebin.com/BcQKSVxZ
Как легко заметить, она не дописана в конце (раздел для любопытных аутистов, которым интересно знать, почему так происходит). Причину того, почему может не скачаться конец файла, я отлично знаю и расписал максимально подробно, а вот почему именно недокачанный конец приводит к таким спецэффектам - в этой теме я "плаваю". Знаю ситуацию в общих чертах и также знаю, что линейные редакторы типа avidemux, virtualdub (и в частности mkvtoolnix при работе с содержимым файла) честно дотошно читают весь файл целиком и изучают, что у него лежит на каких таймстампах, прежде чем дать пользователю скакать по нему. Но писать свои додумывания - возможно, откровенно ошибочные - не хочу.
Что бы вы дописали в тот недописанный в конце раздел, или мб даже что бы вы исправили в том, что уже написано?
С меня нихуя, но этот текст будет висеть в перекатах торрент-треда в обозримом будущем и мб кому-то поможет, ну или хотя бы кого-то просветит.
А в чем прикол вот этой темы?
https://github.com/AnimMouse/ffmpeg-autobuild
https://github.com/AnimMouse/ffmpeg-autobuild
>>413270
Используют гитхаб, чтобы бесплатно автоматически собирать кастомный ффмпег с libfdk-aac и прочими плюшками.
Используют гитхаб, чтобы бесплатно автоматически собирать кастомный ффмпег с libfdk-aac и прочими плюшками.
Анончики, а можно ли как нибудь увеличить фпс, допустим, с 30 до 60 и при этом увеличить плавность видео, как это делает Topaz ?
И вообще есть ли какие нибудь функции для улучшении картинки при апскейле ?
Пока только нашел как выкрутить резкость (-vf unsharp=x:x:x)
И вообще есть ли какие нибудь функции для улучшении картинки при апскейле ?
Пока только нашел как выкрутить резкость (-vf unsharp=x:x:x)
>>413495
Это в принципе невозможно, только притвориться.
Ты хочешь добавить кадр посередине между двумя. Камера не снимала что там происходило и это никому не известно. Можно только либо интерполировать, либо фантазировать какими-нибудь нейронками.
Интеполяцию ffmpeg умеет: https://ffmpeg.org/ffmpeg-filters.html#minterpolate
Это в принципе невозможно, только притвориться.
Ты хочешь добавить кадр посередине между двумя. Камера не снимала что там происходило и это никому не известно. Можно только либо интерполировать, либо фантазировать какими-нибудь нейронками.
Интеполяцию ffmpeg умеет: https://ffmpeg.org/ffmpeg-filters.html#minterpolate
>>413508
Почему невозможно то, бери соседние кадры, вставляй промежуточные, делая новые из соседних через оверлей.
Только смысла в этом немного, всё современное железо такое фуфло на лету делать может при проигрывании, качество видео не улучшится от таких манипуляций.
>Это в принципе невозможно
Почему невозможно то, бери соседние кадры, вставляй промежуточные, делая новые из соседних через оверлей.
Только смысла в этом немного, всё современное железо такое фуфло на лету делать может при проигрывании, качество видео не улучшится от таких манипуляций.
>>413508
>>413517
Проблема в всех этих интерполяторов в том что они не способны отличить реальную частоту кадров от фиктивной. Например в том же аниме нередко рисуют 12 кадров, а кодируют как 23.976 (24000 / 1001). И притом в одном и том же видео может быть как 24 реальных кадра, так и 12.
И если пройтись по такому сурсу нейронками, то будет не плавность, а рваная плавность, поскольку ему нечего интерполировать между одинаковыми кадрами.
И это я ещё молчу про пулдаун из киношных 23.976 в NTSC (29.97 полных кадров). Как такое интерполировать, я даже не представляю.
>>413517
Проблема в всех этих интерполяторов в том что они не способны отличить реальную частоту кадров от фиктивной. Например в том же аниме нередко рисуют 12 кадров, а кодируют как 23.976 (24000 / 1001). И притом в одном и том же видео может быть как 24 реальных кадра, так и 12.
И если пройтись по такому сурсу нейронками, то будет не плавность, а рваная плавность, поскольку ему нечего интерполировать между одинаковыми кадрами.
И это я ещё молчу про пулдаун из киношных 23.976 в NTSC (29.97 полных кадров). Как такое интерполировать, я даже не представляю.
>>413517
Потому что то ты там наклеил не имеет отношения к тому что происходило перед объективом. Кадр ты можешь только угадывать или придумывать сам. Любое размытие будет просто мылом, любое наложение даст артефакты типа шестиногих котов
Потому что то ты там наклеил не имеет отношения к тому что происходило перед объективом. Кадр ты можешь только угадывать или придумывать сам. Любое размытие будет просто мылом, любое наложение даст артефакты типа шестиногих котов
3,8 Мб, webm,1920x1080, 0:13
>>413688
Если тупо замедлить без интерполяции, то получается дерганная картинка в 5 фпс с дублированными кадрами.
Если тупо замедлить без интерполяции, то получается дерганная картинка в 5 фпс с дублированными кадрами.
>>413654
А также артефакты на стыке кадров (в смысле ракурсов / планов), когда интерполировать последний кадрик предыдущей сцены и первый кадр следующей НЕ надо, а надо тогда уж экстраполировать из двух последних кадров предыдущей сцены.
Но детект смены сцены https://en.wikipedia.org/wiki/Shot_transition_detection - это ДОХУЯ сложная задача, а какой хуйни нейронка нагенерит на плавных сменах кадров, типа фейдов или наездов - представить страшно.
А также артефакты на стыке кадров (в смысле ракурсов / планов), когда интерполировать последний кадрик предыдущей сцены и первый кадр следующей НЕ надо, а надо тогда уж экстраполировать из двух последних кадров предыдущей сцены.
Но детект смены сцены https://en.wikipedia.org/wiki/Shot_transition_detection - это ДОХУЯ сложная задача, а какой хуйни нейронка нагенерит на плавных сменах кадров, типа фейдов или наездов - представить страшно.
>>413688
Тебе нужен rife для такого, годных консольных тулзов под это дело вроде не замутили, гугли flowframes
Тебе нужен rife для такого, годных консольных тулзов под это дело вроде не замутили, гугли flowframes
>>415025
Если тебе без лишней ебли - скачай Avidemux, это линейный редактор с гуи, который работает на ффмпеге. Внизу таймлайн видео, по нему можно скакать мышкой или контролами слева, там есть "перейти на следующий / предыдущий ключевой кадр" (там же рядом для текущего кадра всегда пишется, каков текущий, тебе нужны I-кадры). Кнопками A и B можно выделить нужный тебе фрагмент (кнопка B включительная, то есть кадр B будет последним кадром выреза, а не первым кадром того, что следует за нужным тебе и уже не будет вырезано). Слева для видео и аудио можно выбрать режимы - Copy - это полная копия потока без какого-либо перекодирования, остальные варианты с кодеками - перекодирование в нужный кодек и их настройки и фильтры (кроп кадра сверху и снизу, ускорение и прочее, естественно, это все доступно только при перекодировании). Тебе нужен режим Copy для видео и аудио, в нем начало выделенного фрагмента ОБЯЗАТЕЛЬНО должно быть ключевым I-кадром, а вот если перекодируешь (т.е. создаешь видеопоток с нуля), тогда можешь вырезать начиная с какого угодно кадра.
Если тебе без лишней ебли - скачай Avidemux, это линейный редактор с гуи, который работает на ффмпеге. Внизу таймлайн видео, по нему можно скакать мышкой или контролами слева, там есть "перейти на следующий / предыдущий ключевой кадр" (там же рядом для текущего кадра всегда пишется, каков текущий, тебе нужны I-кадры). Кнопками A и B можно выделить нужный тебе фрагмент (кнопка B включительная, то есть кадр B будет последним кадром выреза, а не первым кадром того, что следует за нужным тебе и уже не будет вырезано). Слева для видео и аудио можно выбрать режимы - Copy - это полная копия потока без какого-либо перекодирования, остальные варианты с кодеками - перекодирование в нужный кодек и их настройки и фильтры (кроп кадра сверху и снизу, ускорение и прочее, естественно, это все доступно только при перекодировании). Тебе нужен режим Copy для видео и аудио, в нем начало выделенного фрагмента ОБЯЗАТЕЛЬНО должно быть ключевым I-кадром, а вот если перекодируешь (т.е. создаешь видеопоток с нуля), тогда можешь вырезать начиная с какого угодно кадра.
>>415084
Вдогонку: там же можно удалить / убрать ненужный тебе фрагмент из видео / из последовательности кадров, если тебе нужно склеить какие-то два фрагмента, которые разделены другим ненужным.
В этом случае две тонкости:
- в случае удаления (а не выделения для рендера / экспорта, как в сообщении выше) кнопка B устанавливает не последний кадр удаляемого, а первый кадр нетронутого, то есть в этом случае вырезание НЕ включительное по B, последний кадр удаляемого фрагмента будет предыдущим до кадра, установленного кнопкой B
- если ты вырезаешь без перекодирования в режиме Copy, то тут уже именно B должен быть ключевым I-кадром, а A (начало удаляемого фрагмента) может быть любым. Потому что можно запросто обрезать хвост любой последовательности кадров, декодируемых друг за другом каждый из предыдущего, а вот НАЧАЛО последовательности (второй нужный тебе фрагмент, следующий за удаляемым куском) обязательно должно быть полным нетронутым кадром. Это, как бы, достаточно "очевидно" и несложно, но советую не запомнить это как факт, а посидеть подумать и, так сказать, "осознать", чтобы потом не путаться.
Удаляется просто: выделяешь на таймлайне фрагмент кнопками A и B и просто нажимаешь Delete. Учти, что если ты куда-то на бумажку записываешь свои монтажные последовательности покадрово, то тайминг следующих за этим кусков съедет (если ты удалил 30 секунд с 0:30 по 1:00, то то, что было 2:30, станет 2:00).
Вдогонку: там же можно удалить / убрать ненужный тебе фрагмент из видео / из последовательности кадров, если тебе нужно склеить какие-то два фрагмента, которые разделены другим ненужным.
В этом случае две тонкости:
- в случае удаления (а не выделения для рендера / экспорта, как в сообщении выше) кнопка B устанавливает не последний кадр удаляемого, а первый кадр нетронутого, то есть в этом случае вырезание НЕ включительное по B, последний кадр удаляемого фрагмента будет предыдущим до кадра, установленного кнопкой B
- если ты вырезаешь без перекодирования в режиме Copy, то тут уже именно B должен быть ключевым I-кадром, а A (начало удаляемого фрагмента) может быть любым. Потому что можно запросто обрезать хвост любой последовательности кадров, декодируемых друг за другом каждый из предыдущего, а вот НАЧАЛО последовательности (второй нужный тебе фрагмент, следующий за удаляемым куском) обязательно должно быть полным нетронутым кадром. Это, как бы, достаточно "очевидно" и несложно, но советую не запомнить это как факт, а посидеть подумать и, так сказать, "осознать", чтобы потом не путаться.
Удаляется просто: выделяешь на таймлайне фрагмент кнопками A и B и просто нажимаешь Delete. Учти, что если ты куда-то на бумажку записываешь свои монтажные последовательности покадрово, то тайминг следующих за этим кусков съедет (если ты удалил 30 секунд с 0:30 по 1:00, то то, что было 2:30, станет 2:00).
51 Кб, 908x266Анончики, что это за дичь (см.пик) ?
Кстати про ключевые кадры, ффмпег и авидемукс.
Подскажите, как кодировать видео так, чтобы ключевые кадры стояли в основном на смене ракурсов / на начале новых шотов, а не равномерно каждые 10 секунд?
H264 в Авидемуксе на пресетах slow, slower, veryslow делает именно последнее. А, например, в ресурсах блюреев (и в исходных .m2ts с блюреев) часто вижу, что ключевые кадры стоят чуть ли не на каждом первом новом шоте (мб не совсем буквально на каждом, но тем не менее). При этом же, например, недавно качал чей-то херовенький блюрей-рип (реенкод в меньший размер) - там ключевые кадры раз в 25 секунд сука, охуенно удобно скакать по файлу (нет). Где эта настройка?
Подскажите, как кодировать видео так, чтобы ключевые кадры стояли в основном на смене ракурсов / на начале новых шотов, а не равномерно каждые 10 секунд?
H264 в Авидемуксе на пресетах slow, slower, veryslow делает именно последнее. А, например, в ресурсах блюреев (и в исходных .m2ts с блюреев) часто вижу, что ключевые кадры стоят чуть ли не на каждом первом новом шоте (мб не совсем буквально на каждом, но тем не менее). При этом же, например, недавно качал чей-то херовенький блюрей-рип (реенкод в меньший размер) - там ключевые кадры раз в 25 секунд сука, охуенно удобно скакать по файлу (нет). Где эта настройка?
> в ресурсах блюреев
* в ремуксах.
39,1 Мб, mp4,1920x1080, 0:15
Подскажите, что не так с этим видео?
Весь файл целиком большой, но вот этот кусок вырезан без перекодирования (перекодировал только аудио в AAC для браузеров, видео не тронул и порезал по ключевому кадру).
Не "просто" интерлейс, а некий MBAFF. Еще Avidemux называет типы кадров не просто I, P, B, а I-TFF, P-TFF, B-TFF.
При этом видеоплеер (MPC-HC) воспроизводит нормально, а вот Avidemux при загрузке видеофайла в него декодирует как "неправильный" интерлейс (невооруженным глазом везде постоянно видны полосы интерлейса при любом движении), и браузер (Firefox) - тоже. В Avidemux не нашел в настройках декодирования чего-либо типа "смены порядка чтения полей" (если дело в этом), в Firefox тем более даже не знаю где искать подобное.
В чем тут дело и можно ли превратить этот файл и подобные ему в "нормально" читаемый интерлейс без перекодирования содержимого?
Весь файл целиком большой, но вот этот кусок вырезан без перекодирования (перекодировал только аудио в AAC для браузеров, видео не тронул и порезал по ключевому кадру).
> Frame rate mode : Constant
> Frame rate : 29.970 (30000/1001) FPS
> [...]
> Scan type : MBAFF
> Scan type, store method : Interleaved fields
> Scan order : Top Field First
Не "просто" интерлейс, а некий MBAFF. Еще Avidemux называет типы кадров не просто I, P, B, а I-TFF, P-TFF, B-TFF.
При этом видеоплеер (MPC-HC) воспроизводит нормально, а вот Avidemux при загрузке видеофайла в него декодирует как "неправильный" интерлейс (невооруженным глазом везде постоянно видны полосы интерлейса при любом движении), и браузер (Firefox) - тоже. В Avidemux не нашел в настройках декодирования чего-либо типа "смены порядка чтения полей" (если дело в этом), в Firefox тем более даже не знаю где искать подобное.
В чем тут дело и можно ли превратить этот файл и подобные ему в "нормально" читаемый интерлейс без перекодирования содержимого?
>>416789
https://www.afterdawn.com/glossary/term.cfm/macroblock-adaptive_frame-field_coding
«TFF» — это «top field first». Раз они специально отмечают это в типе кадра, то можно предположить, что это нестандартный вариант. В общем случае кодек должен быть готов принять видео с любым порядком полей и выдать после декодирования точно такое же, поскольку он может (точнее, мог) находиться в цепочке инфраструктуры обработки чересстрочного видео, которая складывалась годами или десятками лет. Поэтому просто взять и переделать в один «правильный» формат — не вариант (не говоря о возможных проблемах с пропажами из потока полукадров для отметок времени в начале и конце).
Чинить известно как: находишь референсный декодер, проверяешь, что видео им декодируется правильно, идёшь жаловаться в багтрекер программы с приложением куска своего видео.
В Avidemux есть функция swap fields, меняющая их порядок. Если он просто не умеет получать правильный порядок полей от декодера, то всё исправится одним нажатием. Другое дело, если всё хитрее, и макроблоки с минимумом движения, закодированные с построчной развёрткой, программой отображаются правильно, и только чересстрочные — неправильно. Тогда смена порядка полей исправит чересстрочные части, но испортит картинку в статичных областях. Экспериментируй.
https://www.afterdawn.com/glossary/term.cfm/macroblock-adaptive_frame-field_coding
«TFF» — это «top field first». Раз они специально отмечают это в типе кадра, то можно предположить, что это нестандартный вариант. В общем случае кодек должен быть готов принять видео с любым порядком полей и выдать после декодирования точно такое же, поскольку он может (точнее, мог) находиться в цепочке инфраструктуры обработки чересстрочного видео, которая складывалась годами или десятками лет. Поэтому просто взять и переделать в один «правильный» формат — не вариант (не говоря о возможных проблемах с пропажами из потока полукадров для отметок времени в начале и конце).
Чинить известно как: находишь референсный декодер, проверяешь, что видео им декодируется правильно, идёшь жаловаться в багтрекер программы с приложением куска своего видео.
В Avidemux есть функция swap fields, меняющая их порядок. Если он просто не умеет получать правильный порядок полей от декодера, то всё исправится одним нажатием. Другое дело, если всё хитрее, и макроблоки с минимумом движения, закодированные с построчной развёрткой, программой отображаются правильно, и только чересстрочные — неправильно. Тогда смена порядка полей исправит чересстрочные части, но испортит картинку в статичных областях. Экспериментируй.
>>413495
Был какой-то интерполяционный изврат в ффмпег, но получалось всрато - на резких сменах сцены всё квадратится. Нормально делает flowframes.
Был какой-то интерполяционный изврат в ффмпег, но получалось всрато - на резких сменах сцены всё квадратится. Нормально делает flowframes.
> ffmpeg -loop 1 -i background.png -i audio.opus -r 30 -vf subtitles=sub.srt -c:v libvpx-vp9 -c:a copy -shortest out.webm
Какого хрена субтитры двоятся? Маленьким шрифтом и поверх крупным. Или надо обязательно на готовое видео их накладывать, а не генерить его из фоновой пикчи?
>>417170
Пробуй так
ffmpeg -loop 1 -i background.png -i audio.opus -r 30 -vf "subtitles=sub.srt" -c:v libvpx-vp9 -c:a copy -shortest out.webm
Пробуй так
ffmpeg -loop 1 -i background.png -i audio.opus -r 30 -vf "subtitles=sub.srt" -c:v libvpx-vp9 -c:a copy -shortest out.webm
Ребята тред не читал, есть вопрос по кропу
ширина и высота: новые размеры видео после обрезки.
x и y: координаты верхнего левого угла области, которую вы хотите сохранить
И тут я буксанул, у меня не отображается картинка видео в голове для обрезки чтобы правильно обрезать, до этого юзал редакторы с оболочками там хуле хлоп хлоп и готово, а тут координаты какие-то ща конечно же буду на рандом ебашить но мб кто подскажет
>входное_видео.mp4: это ваш входной видеофайл.
ширина и высота: новые размеры видео после обрезки.
x и y: координаты верхнего левого угла области, которую вы хотите сохранить
И тут я буксанул, у меня не отображается картинка видео в голове для обрезки чтобы правильно обрезать, до этого юзал редакторы с оболочками там хуле хлоп хлоп и готово, а тут координаты какие-то ща конечно же буду на рандом ебашить но мб кто подскажет
Анон, у меня не работает одновременно пресет realtime в vp9 и 2pass. Ошибку не скину сейчас - на работе. Может оно в принципе не работать не должно?
>>418031
оо спасибо!
оо спасибо!
>>418022
Аналогично вышепостеру прикидываю координаты по скриншоту в paint.net. И это всё-таки удобнее, чем во всех гуях, которые пробовал.
Аналогично вышепостеру прикидываю координаты по скриншоту в paint.net. И это всё-таки удобнее, чем во всех гуях, которые пробовал.
>>418022
Попробуй ffmpeg заменить на ffplay в команде – заиграет то что ты режешь, помогает для отладки.
Но так да, гуи на то и гуи что в них удобнее визуальные части делать.
Попробуй ffmpeg заменить на ffplay в команде – заиграет то что ты режешь, помогает для отладки.
Но так да, гуи на то и гуи что в них удобнее визуальные части делать.
>>417209
Кавычки добавить? Не помогает. Кодировать вавку в опус, а не копировать ffmpeg -loop 1 -i background.png -i audio.wav -r 30 -vf "subtitles=sub.srt" -c:v libvpx-vp9 -c:a libopus -shortest out.webm - тоже всё двоится.
Кавычки добавить? Не помогает. Кодировать вавку в опус, а не копировать ffmpeg -loop 1 -i background.png -i audio.wav -r 30 -vf "subtitles=sub.srt" -c:v libvpx-vp9 -c:a libopus -shortest out.webm - тоже всё двоится.
>>418032
Расскажи, как ты будешь кодировать видео, которое находится в процессе получения, и которое закончится в неизвестный момент времени в будущем, в два прохода от начала до конца, чтобы готовый файл имел заданный размер?
> realtime
> 2pass
Расскажи, как ты будешь кодировать видео, которое находится в процессе получения, и которое закончится в неизвестный момент времени в будущем, в два прохода от начала до конца, чтобы готовый файл имел заданный размер?
>>418479
Чел, это просто название для более быстрого пресета. Не надо так буквально воспринимать слова, которыми анальники называют всякое. На вики написано что рекомендовано для быстрого энкодинга. Я конечно предполагаю что там может быть несовместимость с 2pass по названным тобой причинам, но я для того в тред и написал чтобы узнать так это или нет (лень документацию читать).
Чел, это просто название для более быстрого пресета. Не надо так буквально воспринимать слова, которыми анальники называют всякое. На вики написано что рекомендовано для быстрого энкодинга. Я конечно предполагаю что там может быть несовместимость с 2pass по названным тобой причинам, но я для того в тред и написал чтобы узнать так это или нет (лень документацию читать).
>>418534
Чел, это просто название для более быстрого пресета. При котором кадры выплёвываются настолько быстро, насколько можно, и их анализ минимален. Настолько, что сохранять в файл статистики просто нечего, поскольку те же циферки (какие-нибудь средние значения и эффективные диапазоны) могут быть получены каждый раз заново простым сканированием при загрузке или копировании кадров. Следовательно, работу в режиме нескольких проходов с такими настройками даже не реализовывали, да и уровень качества несопоставим. Ты понимаешь, зачем нужно кодирование в два прохода, и как оно работает?
Чел, это просто название для более быстрого пресета. При котором кадры выплёвываются настолько быстро, насколько можно, и их анализ минимален. Настолько, что сохранять в файл статистики просто нечего, поскольку те же циферки (какие-нибудь средние значения и эффективные диапазоны) могут быть получены каждый раз заново простым сканированием при загрузке или копировании кадров. Следовательно, работу в режиме нескольких проходов с такими настройками даже не реализовывали, да и уровень качества несопоставим. Ты понимаешь, зачем нужно кодирование в два прохода, и как оно работает?
>>418547
Ну вот я и хотел знать совместимы эти режим или нет. Как работает 2pass знаю.
Спасибо за ответ.
Ну вот я и хотел знать совместимы эти режим или нет. Как работает 2pass знаю.
Спасибо за ответ.
31,4 Мб, mp4,1280x960, 0:34
Сап, анончики. Попробовал оцифровать VHS кассеты, взял дешевый EasyCAPture, по гайдам из инета попробовал через VirtualDub захватить видео и получил ряд проблем:
1. При захвате видео в имеющемся формате постоянно полосит, но хуже этого - появляется зеленый кадр с черными квадратами, причём довольно часто (на приложенном видео есть).
2. То ли само это устройство такое дешманское, то ли ещё что, но при выборе его в VDub нельзя ни кодеки поменять, он просто отказывается что-либо показывать, и ссылается на ошибку, ни изменить PAL/SECAM, просто все эти вкладки неактивны. Кодеки ставил K-Lite Mega.
3. При некоторых действиях в проге делит изображение на 4 и выебывается.
Захват происходил без сжатия и в 64-, и в 32-битной версиях, сжимал для отправки сюда.
Я в этой теме вообще новенький, и даже хз насколько в правильном месте вопрос задаю, так что если что, пните в нужном направлении.
1. При захвате видео в имеющемся формате постоянно полосит, но хуже этого - появляется зеленый кадр с черными квадратами, причём довольно часто (на приложенном видео есть).
2. То ли само это устройство такое дешманское, то ли ещё что, но при выборе его в VDub нельзя ни кодеки поменять, он просто отказывается что-либо показывать, и ссылается на ошибку, ни изменить PAL/SECAM, просто все эти вкладки неактивны. Кодеки ставил K-Lite Mega.
3. При некоторых действиях в проге делит изображение на 4 и выебывается.
Захват происходил без сжатия и в 64-, и в 32-битной версиях, сжимал для отправки сюда.
Я в этой теме вообще новенький, и даже хз насколько в правильном месте вопрос задаю, так что если что, пните в нужном направлении.
>>418576
Для начала выясни, какие возможности настройки есть в твоём устройстве через драйвер, софт производителя или внешние программы. Синхронизация, параметры сигнала, вот это всё. Задача в том, чтобы получить качественную и необработанную исходную картинку, а уже в программе её подновлять как надо. Кодеки и перекодирование финального результата — это вообще не вопрос, делается после захвата и обработки миллионом способов. Никакие «кодек-паки» в 2024 году не нужны.
Для начала выясни, какие возможности настройки есть в твоём устройстве через драйвер, софт производителя или внешние программы. Синхронизация, параметры сигнала, вот это всё. Задача в том, чтобы получить качественную и необработанную исходную картинку, а уже в программе её подновлять как надо. Кодеки и перекодирование финального результата — это вообще не вопрос, делается после захвата и обработки миллионом способов. Никакие «кодек-паки» в 2024 году не нужны.
>>418593
Да, но прежде всего выясни, какой именно у тебя чип внутри (выпиши идентификаторы оборудования), потому что китайцы в сараях лепят кучу вариантов этих древних устройств захвата из того, что есть под рукой, меняют загружаемые в устройство прошивки, а драйверы под современные системы не пишут. Возможно, придётся искать нормально работающий драйвер и руками добавлять.
Да, но прежде всего выясни, какой именно у тебя чип внутри (выпиши идентификаторы оборудования), потому что китайцы в сараях лепят кучу вариантов этих древних устройств захвата из того, что есть под рукой, меняют загружаемые в устройство прошивки, а драйверы под современные системы не пишут. Возможно, придётся искать нормально работающий драйвер и руками добавлять.
Наилучший способ сконвертить без потери качества webm в mp4?
А вообще, может и не мп4. Моя цель состоит в том, чтобы свои вебм массово сконвертировать в формат, читаемый телеграмом. Дело в том, что webm превращается в ФАЙЛ, когда удалить его основу, и без скачивания не обойтись.
А вообще, может и не мп4. Моя цель состоит в том, чтобы свои вебм массово сконвертировать в формат, читаемый телеграмом. Дело в том, что webm превращается в ФАЙЛ, когда удалить его основу, и без скачивания не обойтись.
>>418842
Что не убивает нас, делает нас криножовее
Что не убивает нас, делает нас криножовее
>>419065
Хотя бы в том что x265 это lossy кодек. А ещё в том что нельзя взять рандомное видео из интернета и сжать его в visually lossless. Там хорошо если если размер файла снизится на 20-30%. Но с учетом generation loss, нет, подобная затея лишена всякого смысла.
Хотя бы в том что x265 это lossy кодек. А ещё в том что нельзя взять рандомное видео из интернета и сжать его в visually lossless. Там хорошо если если размер файла снизится на 20-30%. Но с учетом generation loss, нет, подобная затея лишена всякого смысла.
>>418705
Странно что двачеры-анальники ещё не пояснили. Телега поддерживает вебм просто она стесняется в этом признаться. Переименуй свою вебм в мп4 и телега прожуёт видео как полагается. То есть контейнер webm в телеге поддерживается, просто файлы с расширением webm не распознаются телегой как нечто к чему надо эту поддержку применять. Даже перепковывать не надо.
А так, у тебя вопрос не корректный. Говоришь про контейнеры, а в то же время хочешь что-то там конвертировать. В крайнем случае пришлось бы запаковать vp9 и opus в мп4.
Странно что двачеры-анальники ещё не пояснили. Телега поддерживает вебм просто она стесняется в этом признаться. Переименуй свою вебм в мп4 и телега прожуёт видео как полагается. То есть контейнер webm в телеге поддерживается, просто файлы с расширением webm не распознаются телегой как нечто к чему надо эту поддержку применять. Даже перепковывать не надо.
А так, у тебя вопрос не корректный. Говоришь про контейнеры, а в то же время хочешь что-то там конвертировать. В крайнем случае пришлось бы запаковать vp9 и opus в мп4.
Где посмотреть, какие форматы файлов способна отображать и воспроизводить ебучая сосака? Хотя бы пошлите в направлении, где это можно посмотреть
>>419754
Не, я имел ввиду и картинки тоже. Знаю, что большие проблемы с анимацией, из которой прожевался только GIF, ну а из статичных очевидно жрет стандартные jpg, png, еще webp - насчет других не знаю
Не, я имел ввиду и картинки тоже. Знаю, что большие проблемы с анимацией, из которой прожевался только GIF, ну а из статичных очевидно жрет стандартные jpg, png, еще webp - насчет других не знаю
>>419101
Ну то есть стоит посмотреть сначала изначально какое видео и с каким кодеком, а потом уже подбирать?
Ну то есть стоит посмотреть сначала изначально какое видео и с каким кодеком, а потом уже подбирать?
>>419806
Я потому и спросил здесь, что не хотел тупо перебирать все возможные варианты в /test. Но да ладно, видимо другого варианта нет
Я потому и спросил здесь, что не хотел тупо перебирать все возможные варианты в /test. Но да ладно, видимо другого варианта нет
>>415917
Дизеринг отключить
Дизеринг отключить
>>415953
спасибо
спасибо
>>419756
Ну не только кодек, а ещё и битрейт, разрешение, fps, и это наверно не полный список.
Если к примеру у тебя видео снятое на телефон. Или даже с камеры. Такое сжимвть можно, при условии что ты потом не будешь из него монтировать.
Ещё жмут блюреи, если делать это осторожно. Но тут учти что с h264 в h264 ты особо не сожмёшь. А с более современными кодеками уже надо поебаться, ибо они имеют тенденцию мылить.
Ну не только кодек, а ещё и битрейт, разрешение, fps, и это наверно не полный список.
Если к примеру у тебя видео снятое на телефон. Или даже с камеры. Такое сжимвть можно, при условии что ты потом не будешь из него монтировать.
Ещё жмут блюреи, если делать это осторожно. Но тут учти что с h264 в h264 ты особо не сожмёшь. А с более современными кодеками уже надо поебаться, ибо они имеют тенденцию мылить.
svt или aom использовать для дваче вебмок? посоветуйте золотую середину пресета (1-13) и crf. Давно av1 кодировал и был косяк с превью на дваче и в некоторых браузерах не воспроизводилось.
>>420136
Почему нет? Проигрываются же, только точно не знаю какие настройки оптимальные.
Почему нет? Проигрываются же, только точно не знаю какие настройки оптимальные.
>>420100
4 ± 2
24 ± 8
svt должен быть побыстрее. Но и libaom никто не запрещает.
> посоветуйте золотую середину пресета (1-13)
4 ± 2
> и crf
24 ± 8
> svt или aom использовать
svt должен быть побыстрее. Но и libaom никто не запрещает.
>>420100
Двач это в принципе один сплошной косяк, превью может просто так пропадать, независимо от кодека.
>косяк с превью на дваче
Двач это в принципе один сплошной косяк, превью может просто так пропадать, независимо от кодека.
Есть прога или короче как можно конвертировать видева всякие avi, mkv и прочий кал в mp4 x264. Но есть условие: конвертор должен брать исходные данные видевы (разрешение, битрейты аудио и видео и тд) и просто перегонять в h264. В прогах всяких что делал там блять надо вручную битрейт ебаный выставлять, а если видосов штук 100 ебанешься же на хуй. В чем проблема в этих дегенератских прогах сделать настройку чтобы не только разрешение или фпс был как у исходника но и битрейт ебаный тоже оставался а не выставлялся хуй знает какой пизды.
>>420596
Тебе не нужно ебаться с битрейтом. Просто ставишь -crf 18 и всё.
А если тебя не устраивает битрейт, смирись. Потому что пожатие сильно пожатого окончательно добьёт остатки качества.
Тебе не нужно ебаться с битрейтом. Просто ставишь -crf 18 и всё.
А если тебя не устраивает битрейт, смирись. Потому что пожатие сильно пожатого окончательно добьёт остатки качества.
>>420625
Так это даже не программа а просто настройка. Да и как можно испортить h264 видео сохранив допустим битрейт AVI исходника.
Может через питон и ffmpeg сделать, чтобы скрипт на питоне считывал битрейт видео и полученную цифру загонял в настройки конвертации и запускал конвертацию.
Так это даже не программа а просто настройка. Да и как можно испортить h264 видео сохранив допустим битрейт AVI исходника.
Может через питон и ffmpeg сделать, чтобы скрипт на питоне считывал битрейт видео и полученную цифру загонял в настройки конвертации и запускал конвертацию.
>>420620
Никогда не слышал о такой опции в консольный кодировщиках. Могу сказать что многопроходный режим для crf для x264 не нужен.
> 2P или 3P
Никогда не слышал о такой опции в консольный кодировщиках. Могу сказать что многопроходный режим для crf для x264 не нужен.
>>420628
Очевидно, у тебя неверные идеализированные представления о том, что при пережатии исходника с битрейтом X в битрейт Y теряются только данные, соответствующие разнице X-Y, а при пережатии из одного кодека в другой — разнице между ними. Например, если ты перекодируешь видео в H.264 с заданным битрейтом, а потом результат опять перекодируешь с теми же настройками, а потом ещё и ещё, то с каждым разом результат будет хуже, несмотря на одинаковый размер всех экземпляров. Вдобавок артефакты сжатия старых кодеков вроде резких границ между макроблоками могут перетянуть на себя усилия кодировщика, а содержательная часть картинки станет от этого ещё хуже.
Определение того, какие настройки качества кодировщика приведут к результату, визуально не отличимому для большинства пользователей от качества исходного видео, является сложной задачей, требующей множества тестов с разными типами содержания, разными условиями просмотра и разными участниками. Математически она не решается, математически кадры после кодирования совершенно другие, чем до. Перекодирование финальных (сильно сжатых) продуктов в сравнимые битрейты является пустой тратой электричества. В предложенном варианте оно ещё и портит качество.
Очевидно, у тебя неверные идеализированные представления о том, что при пережатии исходника с битрейтом X в битрейт Y теряются только данные, соответствующие разнице X-Y, а при пережатии из одного кодека в другой — разнице между ними. Например, если ты перекодируешь видео в H.264 с заданным битрейтом, а потом результат опять перекодируешь с теми же настройками, а потом ещё и ещё, то с каждым разом результат будет хуже, несмотря на одинаковый размер всех экземпляров. Вдобавок артефакты сжатия старых кодеков вроде резких границ между макроблоками могут перетянуть на себя усилия кодировщика, а содержательная часть картинки станет от этого ещё хуже.
Определение того, какие настройки качества кодировщика приведут к результату, визуально не отличимому для большинства пользователей от качества исходного видео, является сложной задачей, требующей множества тестов с разными типами содержания, разными условиями просмотра и разными участниками. Математически она не решается, математически кадры после кодирования совершенно другие, чем до. Перекодирование финальных (сильно сжатых) продуктов в сравнимые битрейты является пустой тратой электричества. В предложенном варианте оно ещё и портит качество.
25 Кб, 527x620>>365343 (OP)
Надеюсь, вы меня не побьёте.
Когда-нибудь буду осваивать FFmpeg, но сейчас нужна ваша помощь по VirtualDub2.
Пожалуйста, подскажите.
Имеется видео в формате avi.
Хочу перекодировать в mp4.
У файла изначальные данные такие (pic1).
Надеюсь, вы меня не побьёте.
Когда-нибудь буду осваивать FFmpeg, но сейчас нужна ваша помощь по VirtualDub2.
Пожалуйста, подскажите.
Имеется видео в формате avi.
Хочу перекодировать в mp4.
У файла изначальные данные такие (pic1).
>>421876
Получаются (картинки под номерами 2 и 4), а нужно чтобы ширина была как у оригинала (картинка под номером 5).
Подскажите, пожалуйста, как перевести в mp4, чтобы ширина была как у оригинала?
Получаются (картинки под номерами 2 и 4), а нужно чтобы ширина была как у оригинала (картинка под номером 5).
Подскажите, пожалуйста, как перевести в mp4, чтобы ширина была как у оригинала?
>>421875
Avi и mp4 это контейнеры, которые могут в себе хранить вполне одни и те же видео и аудио потоки.
Так что надо понять зачем ты вообще что-то там перекодируешь.
Avi и mp4 это контейнеры, которые могут в себе хранить вполне одни и те же видео и аудио потоки.
Так что надо понять зачем ты вообще что-то там перекодируешь.
ух поигрался с av1 теперь я дефенетли av1 бой
Test
>>422723
В том, что не указал сборку, кодировщик, их версии и вообще год проверки, а также не удосужился разубедиться в своём синдроме утёнка. Может, было такое в какой-нибудь бета-версии, но сейчас (уже давно) таких проблем нет, я их даже не встречал никогда.
В том, что не указал сборку, кодировщик, их версии и вообще год проверки, а также не удосужился разубедиться в своём синдроме утёнка. Может, было такое в какой-нибудь бета-версии, но сейчас (уже давно) таких проблем нет, я их даже не встречал никогда.
>>422750
В 5.0 (или 5.1? когда там первые потуги по AV1 завезли) стабилке такое было. Года полтора-два назад.
> Может, было такое в какой-нибудь бета-версии
В 5.0 (или 5.1? когда там первые потуги по AV1 завезли) стабилке такое было. Года полтора-два назад.
>>422723
Svt-av1 даёт защеку vp9 по качеству и скорости энкода. Минус в том что на телефоне видео тормозит при хардварном декоде. В нормальных плеерах это настраивается, а вот в телеге нет.
>>422460
Тогда помочь не могу. Я хз что за виртуал даб. И с ави с его приколами я не возился. Вообще непердолики используют handbrake.
На крайняк вот тебе мой скрипт на питоне для конвертации в вп9 и в свт ав1. Нужен, собственно, питон и ffmpeg в переменной PATH. Нужно перетащить нужные файлы на файл скрипта. Делалось для себя и больше ради самого процесса пердолинга. Ну и тестировалось соответственно на узком спектре сценариев.
https://files.catbox.moe/gwl5sv.zip
Svt-av1 даёт защеку vp9 по качеству и скорости энкода. Минус в том что на телефоне видео тормозит при хардварном декоде. В нормальных плеерах это настраивается, а вот в телеге нет.
>>422460
Тогда помочь не могу. Я хз что за виртуал даб. И с ави с его приколами я не возился. Вообще непердолики используют handbrake.
На крайняк вот тебе мой скрипт на питоне для конвертации в вп9 и в свт ав1. Нужен, собственно, питон и ffmpeg в переменной PATH. Нужно перетащить нужные файлы на файл скрипта. Делалось для себя и больше ради самого процесса пердолинга. Ну и тестировалось соответственно на узком спектре сценариев.
https://files.catbox.moe/gwl5sv.zip
>>422772
Зачем жрать капусту если есть картошка? H264 упоминать в треде где челы в консолечке файнтюнят анимешечьку чтобы ffmetrics при том же размере выдавал на 0.0005 выше vmaf это или троллинг или необычайное невежество. Вп9 это золотой стандарт пердольного красноглазого сжатия. H264 это дёшево и сердито и вообще не про эффективность.
Зачем жрать капусту если есть картошка? H264 упоминать в треде где челы в консолечке файнтюнят анимешечьку чтобы ffmetrics при том же размере выдавал на 0.0005 выше vmaf это или троллинг или необычайное невежество. Вп9 это золотой стандарт пердольного красноглазого сжатия. H264 это дёшево и сердито и вообще не про эффективность.
>>422798
Да ну как бы 90% ффмпега это написать строчку для двупроходного перекодирования в вп9. Ещё 5% это то же самое, но в crf режиме. Ещё 4% это с изменением разрешения и фпс. И оставшийся процент это всякие зернистости, интерполяции, форматы пиксела и прочее.
Вот тебе, собственно, исчерпывающая статья про те самые 95%.
https://trac.ffmpeg.org/wiki/Encode/VP9
Да ну как бы 90% ффмпега это написать строчку для двупроходного перекодирования в вп9. Ещё 5% это то же самое, но в crf режиме. Ещё 4% это с изменением разрешения и фпс. И оставшийся процент это всякие зернистости, интерполяции, форматы пиксела и прочее.
Вот тебе, собственно, исчерпывающая статья про те самые 95%.
https://trac.ffmpeg.org/wiki/Encode/VP9
>>422800
Спасибо.
Я сейчас немного не в том настроении, чтобы вкатываться, но когда сил поднаберусь, начну вкатывание с твоей статьи.
Ещё раз спасибо за помощь.
Спасибо.
Я сейчас немного не в том настроении, чтобы вкатываться, но когда сил поднаберусь, начну вкатывание с твоей статьи.
Ещё раз спасибо за помощь.
Имеется десяток записей экрана. Как объединить их в один файл и добавить главы (как в фильмах), чтобы как-бы разделить их главами в этом одном большом файле?
Ну и когда будут новые записи, их нужно будет тоже добавлять к уже имеющимся, соответственно желательно без перекодировки, добавив только новый кусок видео и новую главу.
Ну и когда будут новые записи, их нужно будет тоже добавлять к уже имеющимся, соответственно желательно без перекодировки, добавив только новый кусок видео и новую главу.
>>422999
Не нашёл, как там главы добавить. Сделал через mkvtoolnix.
Не нашёл, как там главы добавить. Сделал через mkvtoolnix.
https://github.com/gianni-rosato/svt-av1-psy
Попробовал этот форк, созданный для визуальной достоверности.
При использовании tune=3 не так сильно удаляет родинки с лица, как ванильный svt-av1, может быть svt-av1 всё-таки не так безнадежен в плане мыльности, как я думал.
Попробовал этот форк, созданный для визуальной достоверности.
При использовании tune=3 не так сильно удаляет родинки с лица, как ванильный svt-av1, может быть svt-av1 всё-таки не так безнадежен в плане мыльности, как я думал.
Артефакты сжатия каких кодеков выглядят лучше/хуже?
>>365343 (OP)
Подскажите пжл. как можно вырезать из файла (видео или аудио) определённые куски по времени, потом слепить их в один и на выходе сделать формат wav? Желательно уже готовыми командами (или даже одной)
Подскажите пжл. как можно вырезать из файла (видео или аудио) определённые куски по времени, потом слепить их в один и на выходе сделать формат wav? Желательно уже готовыми командами (или даже одной)
>>427294
Спасибо.
Спасибо.
>>365343 (OP)
Мнение о командах братишки из другой борды который пытается в to create highly compressed videos with VP9 that still preserve some semblance of quality?
ffmpeg -i "$i" -passlogfile "${i%.}-360p-256k" -an -vf scale=640:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 384k -minrate 128k -b:v 256k -bufsize 512k -max-intra-rate 371k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 150 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 15000/1001 -row-mt 1 -speed 4 -threads 4 -tile-columns 1 -tile-rows 0 -pass 1 -f null /dev/null \
ffmpeg -i "$i" -passlogfile "${i%.}-360p-256k" -c:a libopus -ac 1 -ar 16k -b:a 24.4k -application voip -vbr 2 -vf scale=640:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 384k -minrate 128k -b:v 256k -bufsize 512k -max-intra-rate 371k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 150 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 15000/1001 -row-mt 1 -speed 1 -threads 4 -tile-columns 1 -tile-rows 0 -pass 2 -f webm -map_metadata -1 -fflags +bitexact -flags:a +bitexact -flags:v +bitexact -y "${i%.}-360p-256k.webm" \
ffmpeg -i "$i" -passlogfile "${i%.}-240p-114k" -an -vf scale=426:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 171k -minrate 57k -b:v 114k -bufsize 228k -max-intra-rate 165k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 75 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 7500/1001 -row-mt 1 -speed 4 -threads 4 -tile-columns 0 -tile-rows 0 -pass 1 -f null /dev/null \
ffmpeg -i "$i" -passlogfile "${i%.}-240p-114k" -c:a libopus -ac 1 -ar 8k -b:a 12.2k -application voip -vbr 2 -vf scale=426:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 171k -minrate 57k -b:v 114k -bufsize 228k -max-intra-rate 165k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 75 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 7500/1001 -row-mt 1 -speed 1 -threads 4 -tile-columns 0 -tile-rows 0 -pass 2 -f webm -map_metadata -1 -fflags +bitexact -flags:a +bitexact -flags:v +bitexact -y "${i%.}-240p-114k.webm" && \
Мнение о командах братишки из другой борды который пытается в to create highly compressed videos with VP9 that still preserve some semblance of quality?
ffmpeg -i "$i" -passlogfile "${i%.}-360p-256k" -an -vf scale=640:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 384k -minrate 128k -b:v 256k -bufsize 512k -max-intra-rate 371k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 150 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 15000/1001 -row-mt 1 -speed 4 -threads 4 -tile-columns 1 -tile-rows 0 -pass 1 -f null /dev/null \
ffmpeg -i "$i" -passlogfile "${i%.}-360p-256k" -c:a libopus -ac 1 -ar 16k -b:a 24.4k -application voip -vbr 2 -vf scale=640:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 384k -minrate 128k -b:v 256k -bufsize 512k -max-intra-rate 371k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 150 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 15000/1001 -row-mt 1 -speed 1 -threads 4 -tile-columns 1 -tile-rows 0 -pass 2 -f webm -map_metadata -1 -fflags +bitexact -flags:a +bitexact -flags:v +bitexact -y "${i%.}-360p-256k.webm" \
ffmpeg -i "$i" -passlogfile "${i%.}-240p-114k" -an -vf scale=426:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 171k -minrate 57k -b:v 114k -bufsize 228k -max-intra-rate 165k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 75 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 7500/1001 -row-mt 1 -speed 4 -threads 4 -tile-columns 0 -tile-rows 0 -pass 1 -f null /dev/null \
ffmpeg -i "$i" -passlogfile "${i%.}-240p-114k" -c:a libopus -ac 1 -ar 8k -b:a 12.2k -application voip -vbr 2 -vf scale=426:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 171k -minrate 57k -b:v 114k -bufsize 228k -max-intra-rate 165k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 75 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 7500/1001 -row-mt 1 -speed 1 -threads 4 -tile-columns 0 -tile-rows 0 -pass 2 -f webm -map_metadata -1 -fflags +bitexact -flags:a +bitexact -flags:v +bitexact -y "${i%.}-240p-114k.webm" && \
>>428990
Да. Кодеков кучи, а нагрузка ничтожна. Смысла нет аппаратную поддержку городить.
Да. Кодеков кучи, а нагрузка ничтожна. Смысла нет аппаратную поддержку городить.
810 Кб, 1197x1577>>365343 (OP)
малютки, нужно видео в 60фпс перекодировать в .avi с кодеками видео vp8 и аудио vorbis, можно это сделать вашим ффмпегом и эсли да то как?
малютки, нужно видео в 60фпс перекодировать в .avi с кодеками видео vp8 и аудио vorbis, можно это сделать вашим ффмпегом и эсли да то как?
>>429424
Мамкин енкодерер даже официальный гайд не осилил.
> For libvpx-vp9, the traditional wisdom of speeding up the first pass by using a faster encoding speed setting does not apply; -speed values from 0 to 4 result in the same speed for the first pass and yield the exact same results in the final encode, whereas any speed setting above 4 results in the first pass utilising only a single core, slowing things down significantly. Therefore the -speed switch can be entirely omitted from the first pass, since the default value of 1 will result in fast speed.
Мамкин енкодерер даже официальный гайд не осилил.
32 Кб, 405x208>>429715
Можно, но не нужно. Проблема именно в Vorbis. Используй вместо него MP3.
Можно, но не нужно. Проблема именно в Vorbis. Используй вместо него MP3.
>>429931
С замечаниями. Можно и с переменным.
https://en.wikipedia.org/wiki/Comparison_of_video_container_formats#Audio_coding_formats_support
>>429715
Можно, но получиться воспроизводиная штука, но довольно дикая. Разновсяческие проигрыватели вряд ли ждут на входе такое необычное. Скорее, к таким кодекам пойдёт матрёшка или webm.
Можно.
Я попробовал так:
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libmp3lame -b:a 128k out.avi
И вот так:
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -q:a 3 out.avi
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -b:a 128k out.avi
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -b:a 128k -minrate:a 128k -maxrate:a 128k out.avi
Все три последних варианта продуцируют файлы, которые mpv не может проиграть, не ломая синхронизацию. Википедия говорит, что под Windows нет совместимости с фильтрами DirectShow при извлечении vorbis из AVI. И ещё много нехорошего.
При этом AVI с VP8 и MP3 играются без проблем на mpv.
Сделал ещё контрольный файл так:
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -q:a 3 out.mkv
Проверил заодно на телевизоре LG LK6190PLA — из матрёшки vorbis играется, но с искажениями, а из AVI vorbis не играется вообще, о чём телевизор предупреждает.
> Вроде как еще можно AAC, но с постоянным битрейтом
С замечаниями. Можно и с переменным.
https://en.wikipedia.org/wiki/Comparison_of_video_container_formats#Audio_coding_formats_support
>>429715
>нужно видео... .avi с кодеками видео vp8 и аудио vorbis,
Можно, но получиться воспроизводиная штука, но довольно дикая. Разновсяческие проигрыватели вряд ли ждут на входе такое необычное. Скорее, к таким кодекам пойдёт матрёшка или webm.
>можно это сделать вашим ффмпегом и эсли да то как?
Можно.
Я попробовал так:
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libmp3lame -b:a 128k out.avi
И вот так:
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -q:a 3 out.avi
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -b:a 128k out.avi
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -b:a 128k -minrate:a 128k -maxrate:a 128k out.avi
Все три последних варианта продуцируют файлы, которые mpv не может проиграть, не ломая синхронизацию. Википедия говорит, что под Windows нет совместимости с фильтрами DirectShow при извлечении vorbis из AVI. И ещё много нехорошего.
При этом AVI с VP8 и MP3 играются без проблем на mpv.
Сделал ещё контрольный файл так:
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -q:a 3 out.mkv
Проверил заодно на телевизоре LG LK6190PLA — из матрёшки vorbis играется, но с искажениями, а из AVI vorbis не играется вообще, о чём телевизор предупреждает.
>>430365
fix
Ну, и, на всякий случай, напомню, что VP8 комплектовать было бы правильно opus-ом и паковать в webm.
>Можно, возможно получиться воспроизводимая штука, но довольно дикая.
fix
Ну, и, на всякий случай, напомню, что VP8 комплектовать было бы правильно opus-ом и паковать в webm.
Здравствуйте. Возможно ли сделать накладывать изменяющийся текст на видео? Есть сетевой видеопоток, и есть файл. В файле периодически обновляется строка текста, при обновлений строки - менять наложенный на видеопоток текст.
>>430724
возможно не при обновлении строки, а как-нибудь каждые n секунд залезать в файл и выводить всё что там есть
возможно не при обновлении строки, а как-нибудь каждые n секунд залезать в файл и выводить всё что там есть
608 Кб, 1938x1638Фильтр concat вообще способен склеивать не целые файлы, а обработанные иными фильтрами куски видео?
Если делать так, то всё работает:
ffmpeg -i a.mp4 -i b.mp4 -filter_complex "[0][1]concat=n=2:v=1" -c:v libx264 -crf 30 -an out.mp4
Если, например, делать так, то происходит хз что, куски не клеятся:
ffmpeg -i a.mp4 -filter_complex "[0]split=2[a];[a]concat=n=2:v=1" -c:v libx264 -crf 30 -an out.mp4
Если делать так, то всё работает:
ffmpeg -i a.mp4 -i b.mp4 -filter_complex "[0][1]concat=n=2:v=1" -c:v libx264 -crf 30 -an out.mp4
Если, например, делать так, то происходит хз что, куски не клеятся:
ffmpeg -i a.mp4 -filter_complex "[0]split=2[a];[a]concat=n=2:v=1" -c:v libx264 -crf 30 -an out.mp4
>>431635
Блядь, хули съело буквы, харкач ебаный.
Вот второй пример.
ffmpeg -i a.mp4 -filter_complex "[0]split=2[a][d];[a][d]concat=n=2:v=1" -c:v libx264 -crf 30 -an out.mp4
Блядь, хули съело буквы, харкач ебаный.
Вот второй пример.
ffmpeg -i a.mp4 -filter_complex "[0]split=2[a][d];[a][d]concat=n=2:v=1" -c:v libx264 -crf 30 -an out.mp4
>>431635>>431637
Не ffmpeg-ом единым такие вопросы решаются. Если тебе уже монтажные операции делать, то ты возьми более подходящие для такого инструменты — avisynth+, avxsynth, vapoursynth. У них синтаксис не очень сложный — осваивается часов за восемь на нескольких примерах. Зато сценарии на этих языках выглядят гораздо более внятно и читаемо.
Не ffmpeg-ом единым такие вопросы решаются. Если тебе уже монтажные операции делать, то ты возьми более подходящие для такого инструменты — avisynth+, avxsynth, vapoursynth. У них синтаксис не очень сложный — осваивается часов за восемь на нескольких примерах. Зато сценарии на этих языках выглядят гораздо более внятно и читаемо.
>>431635
Чё за милфочка? Есть сурс?
Чё за милфочка? Есть сурс?
>>431663
Да это понятно, я в давинчи могу хуячить, но тут шаманил один сценарий в ffmpeg и проебался пару часов с этим concat'oм ебучим, беглый поиск в гугле внятной информации не нашёл по нему, стало интересно, но не настолько, чтобы исходники смотреть.
Решил тут спросить, может кто в курсе.
Да это понятно, я в давинчи могу хуячить, но тут шаманил один сценарий в ffmpeg и проебался пару часов с этим concat'oм ебучим, беглый поиск в гугле внятной информации не нашёл по нему, стало интересно, но не настолько, чтобы исходники смотреть.
Решил тут спросить, может кто в курсе.
>>432292
Нет. Там есть возможность вывести из ffmpeg на стандартный вывод, а его уже перенаправить в исполняшку svt-av1 на стандартный ввод. Если очень хочется именно в ffmpeg использовать библиотеку libsvtav1, то собираешь из исходников svt-av1-psy библиотеку libsvtav1, её бинарник и заголовочники подменяешь в исходниках ffmpeg, и собираешь из исходников уже сам ffmpeg.
Нет. Там есть возможность вывести из ffmpeg на стандартный вывод, а его уже перенаправить в исполняшку svt-av1 на стандартный ввод. Если очень хочется именно в ffmpeg использовать библиотеку libsvtav1, то собираешь из исходников svt-av1-psy библиотеку libsvtav1, её бинарник и заголовочники подменяешь в исходниках ffmpeg, и собираешь из исходников уже сам ffmpeg.
>>432292
Сорри, я собираю в докере, тебе мои методы вряд ли помогут.
В mov кто-то кидал ссылку на:
https://github.com/BtbN/FFmpeg-Builds/releases
Я бы на твоем месте форкнул на гитхабе этот репозиторий, в файле:
https://github.com/BtbN/FFmpeg-Builds/blob/master/scripts.d/50-svtav1.sh
подменил SCRIPT_REPO и SCRIPT_COMMIT, и включил автосборку на гитхабе.
В итоге у тебя будет такой же ffmpeg как в первой ссылке, но с svt-av1-psy.
Сорри, я собираю в докере, тебе мои методы вряд ли помогут.
В mov кто-то кидал ссылку на:
https://github.com/BtbN/FFmpeg-Builds/releases
Я бы на твоем месте форкнул на гитхабе этот репозиторий, в файле:
https://github.com/BtbN/FFmpeg-Builds/blob/master/scripts.d/50-svtav1.sh
подменил SCRIPT_REPO и SCRIPT_COMMIT, и включил автосборку на гитхабе.
В итоге у тебя будет такой же ffmpeg как в первой ссылке, но с svt-av1-psy.
ебать я нахуй фильм скачал а он весит 33 гигабайта фулл хд и 8 озвучек как удалить озвучки через ффмпег
>>435720
MkvToolnix скачай
https://mkvtoolnix.download/windows/releases/82.0/mkvtoolnix-32-bit-82.0.7z
MkvToolnix скачай
https://mkvtoolnix.download/windows/releases/82.0/mkvtoolnix-32-bit-82.0.7z
>>435735
я там 10 дистров линуксов пролистал прежде чем нашел для виндовса
а че там нажимать чтобы удалить дорожку
я там 10 дистров линуксов пролистал прежде чем нашел для виндовса
а че там нажимать чтобы удалить дорожку
>>435720
Скопируй видео и нужную дорожку в новый файл через map и -c:v/-c:a copy. А затем снеси старый файл
Скопируй видео и нужную дорожку в новый файл через map и -c:v/-c:a copy. А затем снеси старый файл
ffmpeg -i a.mp4 -vf rotate=1*PI/180 -crf 25 -c:v h264_nvenc -b:v 8000K b.mp4
ну допустим вот такой трюк делаю с видосом.
Вопрос: разве при -c:v h264_nvenc у меня не должна видюха нагружаться сильно? Почему-то cpu 80%, а видюха на 40%. Что не так делаю, чтобы видюху по максимуму заюзать?
Чёт не всё так просто в интернете по этому поводу, даже не нахожу результатов тестов cpu vs gpu по скорости выполнения.
ну допустим вот такой трюк делаю с видосом.
Вопрос: разве при -c:v h264_nvenc у меня не должна видюха нагружаться сильно? Почему-то cpu 80%, а видюха на 40%. Что не так делаю, чтобы видюху по максимуму заюзать?
Чёт не всё так просто в интернете по этому поводу, даже не нахожу результатов тестов cpu vs gpu по скорости выполнения.
>>437965
А может у тебя всё упирается в скорость передачи данных. Попробуй переместить видеофайл на nvme ssd.
А может у тебя всё упирается в скорость передачи данных. Попробуй переместить видеофайл на nvme ssd.
>>438076
нет, разницы нет, что обычный ssd, что m2.
скорость низкая из-за rotate=1PI/180
Действительно, без rotate=1PI/180 видюха на 100% грузится, а цпу на 40%.
И как мне всё же при любых параметрах через видюху юзать ffmpeg? Чё, тут никто через видюху не юзает?
нет, разницы нет, что обычный ssd, что m2.
скорость низкая из-за rotate=1PI/180
Действительно, без rotate=1PI/180 видюха на 100% грузится, а цпу на 40%.
И как мне всё же при любых параметрах через видюху юзать ffmpeg? Чё, тут никто через видюху не юзает?
>>438226
Фильтр просчитывается процессором, видеокарта только кодирует.
Фильтр просчитывается процессором, видеокарта только кодирует.
>>438226
Я пробовал но качество говно по сравнению с процом почему то или я не те настройки выставил
> Чё, тут никто через видюху не юзает?
Я пробовал но качество говно по сравнению с процом почему то или я не те настройки выставил
а щас нормально, там битрейт надо было выставить
а я crf выставлял и ффмпег дефолтные 2000к кидал
а я crf выставлял и ффмпег дефолтные 2000к кидал
Как мне сделать батник который в 2 прохода кодирует и чтобы можно было пачку видео кинуть на рендер?
>>438270
Так и есть, хардварное кодирование в среднем хуже программного, потому что железо не резиновое по разрядности блоков, функционалу и т.д. Кодировать железно имеет смысл если надо быстро и много, а качество можно стерпеть
> Я пробовал но качество говно по сравнению с процом
Так и есть, хардварное кодирование в среднем хуже программного, потому что железо не резиновое по разрядности блоков, функционалу и т.д. Кодировать железно имеет смысл если надо быстро и много, а качество можно стерпеть
>>438290
Ну, современное сжатие с потерями (да, и без потерь это в общем случае тоже касается) — это задача оптимизационная. Соответственно, программные решения могут себе позволить рассматривать сколь угодно большое число вариантов кодирования на выбор, чтобы по наперёд избранному критерию выбирать оптимальный вариант. Аппаратные сжималки, как правило, ограничены временем отсечки, за которое решение должно быть найдено с гарантией. Отсюда и типовой способ достижения задачи — параллельно рассмотреть несколько вариантов (включающих в терминах, например, стандарта h.264 как распределение макроблоков, так и векторов движения и квантователей) и выбрать по простому критерию (например, по СКО) один; без пересмотра решения, без этих ваших градиентных поисков, без многокритериальной оптимизации. Максимум, что тут можно на аппаратном сжиматоре — это в две-три итерации попробовать найти решение, чуть более близкое к оптимальному. Ещё, вроде начали завозить в аппаратные сжиматоры двухфакторные критерии вроде «выигрыш по ширине блока в потоке — проигрыш в СКО», но это не точно.
Кроме того, для «по-быстрому» и без «стерпеть», в зелёные слотовые затычки не так давно завезли h.264 без потерь.
>потому что железо не резиновое по разрядности блоков, функционалу и т.д. Кодировать железно имеет смысл если надо быстро и много, а качество можно стерпеть
Ну, современное сжатие с потерями (да, и без потерь это в общем случае тоже касается) — это задача оптимизационная. Соответственно, программные решения могут себе позволить рассматривать сколь угодно большое число вариантов кодирования на выбор, чтобы по наперёд избранному критерию выбирать оптимальный вариант. Аппаратные сжималки, как правило, ограничены временем отсечки, за которое решение должно быть найдено с гарантией. Отсюда и типовой способ достижения задачи — параллельно рассмотреть несколько вариантов (включающих в терминах, например, стандарта h.264 как распределение макроблоков, так и векторов движения и квантователей) и выбрать по простому критерию (например, по СКО) один; без пересмотра решения, без этих ваших градиентных поисков, без многокритериальной оптимизации. Максимум, что тут можно на аппаратном сжиматоре — это в две-три итерации попробовать найти решение, чуть более близкое к оптимальному. Ещё, вроде начали завозить в аппаратные сжиматоры двухфакторные критерии вроде «выигрыш по ширине блока в потоке — проигрыш в СКО», но это не точно.
Кроме того, для «по-быстрому» и без «стерпеть», в зелёные слотовые затычки не так давно завезли h.264 без потерь.
Попалось.
Если кто не в курсе, MS-MPEG4 и Windows Media Video 7 и 8 версии лепились из кусков MPEG-4 Part 2 в процессе их обсуждения и стандартизации и случайно подарили миру DivX ;-) 3 и рипчики на 700 МБ, что чуть позже привело к DivX, Xvid и FFmpeg как полноценным реализациям.
https://wiki.multimedia.cx/index.php/Microsoft_MPEG-4
https://web.archive.org/web/20090523080617/http://www.fourcc.org/codecs.php
https://ffmpeg.org/~michael/msmpeg4.txt
Windows Media Video 9 — это уже базовая часть VC-1.
Если кто не в курсе, MS-MPEG4 и Windows Media Video 7 и 8 версии лепились из кусков MPEG-4 Part 2 в процессе их обсуждения и стандартизации и случайно подарили миру DivX ;-) 3 и рипчики на 700 МБ, что чуть позже привело к DivX, Xvid и FFmpeg как полноценным реализациям.
https://wiki.multimedia.cx/index.php/Microsoft_MPEG-4
https://web.archive.org/web/20090523080617/http://www.fourcc.org/codecs.php
https://ffmpeg.org/~michael/msmpeg4.txt
Windows Media Video 9 — это уже базовая часть VC-1.
>>438601
Только кодировщик, который день тратит на перебор вариантов для одного кадра, никому не нужен.
Сжатие, то есть поиск более компактного способа записи данных, — интеллектуальная, а не «оптимизационная» задача. Можно сказать, что оптимизируются здесь стратегии перебора этих способов, и делается это не на компьютере, а в процессе исследования и выбора алгоритмов. Как только мы наивно берёмся рассуждать о поиске наилучшей комбинации всех пикселей кадра, близкой к оригиналу, или там о переборе всех возможностей двигать блоки во всех направлениях между кадрами, мы получаем близкую к нулю производительность. Оптимизации уже придуманы, а кодировщик только подстраивает их параметры под характер материала.
Аппаратные кодировщики в видеокартах можно делать лучше, только это по многим причинам излишне. Размер модуля в кремнии, сложность разработки, процент выхода брака, потребление энергии, конечная стоимость продукта доходят до каких-то объективных границ. Кроме того, большинству пользователей это и не нужно. В одних случаях можно задрать битрейт, в других — потерпеть (особенно в одноразовых живых трансляциях, где видео нужно для галочки и даже не сохраняется никуда). Кроме того, это предрешено стандартами, комитеты которых заранее делят легко реализуемые аппаратно части и тяжёлые добавки по профилям, и разработчики чипов в них тоже сидят, внося свои оценки и предложения.
Если посмотреть на рынок сложных аппаратных кодировщиков, то он с домашними пользователями не пересекается. Это либо гиганты вроде YouTube, где одновременно нужны и минимально допустимый на практике битрейт, и максимально возможное качество, и минимальная практическая задержка, и чтобы счёт за электричество в датацентрах не был астрономическим, либо скучные коробки для телевидения, которые выдают нормальную картинку и больше никаких волшебных возможностей не содержат, но зато их можно поставить работать месяцами без перерыва, кодируя поток на спутник для всего континента с минимальной и постоянной задержкой между дыркой для входа и дыркой для выхода. Ограниченный рынок и сложность продукта задают стоимость в тысячи долларов для полупрофессиональных моделей.
> Соответственно, программные решения могут себе позволить рассматривать сколь угодно большое число вариантов кодирования на выбор, чтобы по наперёд избранному критерию выбирать оптимальный вариант.
Только кодировщик, который день тратит на перебор вариантов для одного кадра, никому не нужен.
Сжатие, то есть поиск более компактного способа записи данных, — интеллектуальная, а не «оптимизационная» задача. Можно сказать, что оптимизируются здесь стратегии перебора этих способов, и делается это не на компьютере, а в процессе исследования и выбора алгоритмов. Как только мы наивно берёмся рассуждать о поиске наилучшей комбинации всех пикселей кадра, близкой к оригиналу, или там о переборе всех возможностей двигать блоки во всех направлениях между кадрами, мы получаем близкую к нулю производительность. Оптимизации уже придуманы, а кодировщик только подстраивает их параметры под характер материала.
Аппаратные кодировщики в видеокартах можно делать лучше, только это по многим причинам излишне. Размер модуля в кремнии, сложность разработки, процент выхода брака, потребление энергии, конечная стоимость продукта доходят до каких-то объективных границ. Кроме того, большинству пользователей это и не нужно. В одних случаях можно задрать битрейт, в других — потерпеть (особенно в одноразовых живых трансляциях, где видео нужно для галочки и даже не сохраняется никуда). Кроме того, это предрешено стандартами, комитеты которых заранее делят легко реализуемые аппаратно части и тяжёлые добавки по профилям, и разработчики чипов в них тоже сидят, внося свои оценки и предложения.
Если посмотреть на рынок сложных аппаратных кодировщиков, то он с домашними пользователями не пересекается. Это либо гиганты вроде YouTube, где одновременно нужны и минимально допустимый на практике битрейт, и максимально возможное качество, и минимальная практическая задержка, и чтобы счёт за электричество в датацентрах не был астрономическим, либо скучные коробки для телевидения, которые выдают нормальную картинку и больше никаких волшебных возможностей не содержат, но зато их можно поставить работать месяцами без перерыва, кодируя поток на спутник для всего континента с минимальной и постоянной задержкой между дыркой для входа и дыркой для выхода. Ограниченный рынок и сложность продукта задают стоимость в тысячи долларов для полупрофессиональных моделей.
>>438601
Только кодировщик, который день тратит на перебор вариантов для одного кадра, никому не нужен.
Сжатие, то есть поиск более компактного способа записи данных, — интеллектуальная, а не «оптимизационная» задача. Можно сказать, что оптимизируются здесь стратегии перебора этих способов, и делается это не на компьютере, а в процессе исследования и выбора алгоритмов. Как только мы наивно берёмся рассуждать о поиске наилучшей комбинации всех пикселей кадра, близкой к оригиналу, или там о переборе всех возможностей двигать блоки во всех направлениях между кадрами, мы получаем близкую к нулю производительность. Оптимизации уже придуманы, а кодировщик только подстраивает их параметры под характер материала.
Аппаратные кодировщики в видеокартах можно делать лучше, только это по многим причинам излишне. Размер модуля в кремнии, сложность разработки, процент выхода брака, потребление энергии, конечная стоимость продукта доходят до каких-то объективных границ. Кроме того, большинству пользователей это и не нужно. В одних случаях можно задрать битрейт, в других — потерпеть (особенно в одноразовых живых трансляциях, где видео нужно для галочки и даже не сохраняется никуда). Кроме того, это предрешено стандартами, комитеты которых заранее делят легко реализуемые аппаратно части и тяжёлые добавки по профилям, и разработчики чипов в них тоже сидят, внося свои оценки и предложения.
Если посмотреть на рынок сложных аппаратных кодировщиков, то он с домашними пользователями не пересекается. Это либо гиганты вроде YouTube, где одновременно нужны и минимально допустимый на практике битрейт, и максимально возможное качество, и минимальная практическая задержка, и чтобы счёт за электричество в датацентрах не был астрономическим, либо скучные коробки для телевидения, которые выдают нормальную картинку и больше никаких волшебных возможностей не содержат, но зато их можно поставить работать месяцами без перерыва, кодируя поток на спутник для всего континента с минимальной и постоянной задержкой между дыркой для входа и дыркой для выхода. Ограниченный рынок и сложность продукта задают стоимость в тысячи долларов для полупрофессиональных моделей.
> Соответственно, программные решения могут себе позволить рассматривать сколь угодно большое число вариантов кодирования на выбор, чтобы по наперёд избранному критерию выбирать оптимальный вариант.
Только кодировщик, который день тратит на перебор вариантов для одного кадра, никому не нужен.
Сжатие, то есть поиск более компактного способа записи данных, — интеллектуальная, а не «оптимизационная» задача. Можно сказать, что оптимизируются здесь стратегии перебора этих способов, и делается это не на компьютере, а в процессе исследования и выбора алгоритмов. Как только мы наивно берёмся рассуждать о поиске наилучшей комбинации всех пикселей кадра, близкой к оригиналу, или там о переборе всех возможностей двигать блоки во всех направлениях между кадрами, мы получаем близкую к нулю производительность. Оптимизации уже придуманы, а кодировщик только подстраивает их параметры под характер материала.
Аппаратные кодировщики в видеокартах можно делать лучше, только это по многим причинам излишне. Размер модуля в кремнии, сложность разработки, процент выхода брака, потребление энергии, конечная стоимость продукта доходят до каких-то объективных границ. Кроме того, большинству пользователей это и не нужно. В одних случаях можно задрать битрейт, в других — потерпеть (особенно в одноразовых живых трансляциях, где видео нужно для галочки и даже не сохраняется никуда). Кроме того, это предрешено стандартами, комитеты которых заранее делят легко реализуемые аппаратно части и тяжёлые добавки по профилям, и разработчики чипов в них тоже сидят, внося свои оценки и предложения.
Если посмотреть на рынок сложных аппаратных кодировщиков, то он с домашними пользователями не пересекается. Это либо гиганты вроде YouTube, где одновременно нужны и минимально допустимый на практике битрейт, и максимально возможное качество, и минимальная практическая задержка, и чтобы счёт за электричество в датацентрах не был астрономическим, либо скучные коробки для телевидения, которые выдают нормальную картинку и больше никаких волшебных возможностей не содержат, но зато их можно поставить работать месяцами без перерыва, кодируя поток на спутник для всего континента с минимальной и постоянной задержкой между дыркой для входа и дыркой для выхода. Ограниченный рынок и сложность продукта задают стоимость в тысячи долларов для полупрофессиональных моделей.
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 8 июня в 19:32.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 8 июня в 19:32.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.