Pull to refresh

Comments 20

Вот вам прямо стримы запихивать в youtube, правда с кодеками ffmpeg для разных камер возможно придется поиграться.
Dockerfile
FROM alpine:latest
RUN apk add --update ffmpeg
ENTRYPOINT ["ffmpeg"]



docker-compose
version: '3'
services:
  FirstStream:
    image: ffmpeg
    network_mode: host
    logging:
      driver: json-file
      options:
        max-file: '5'
        max-size: 5m
    command:
    - -err_detect
    - compliant
    - -thread_queue_size
    - '512'
    - -i
    - rtsp://user:password@rtsp-server-url
    - -f
    - lavfi
    - -i
    - anullsrc
    - -map
    - 0:v
    - -map
    - 1:a
    - -vcodec
    - copy
    - -acodec
    - aac
    - -ab
    - 128k
    - -strict
    - experimental
    - -preset
    - medium
    - -f
    - flv
    - rtmp://a.rtmp.youtube.com/live2/stream-token

Для ffmpeg можно использовать двух-проходное сжатие (2pass encoding).
Возможен ли такой вариант: вы создаёте лог первого прохода дома на компе с оригинальных видео, затем на сервере используете этот лог 1-го прохода для кодирования (я так понял в нём содержится информация для энкодера какие сцены кодировать с повышенным/пониженным битрейтом)? Правда видео оригинальное и отправляемое на ютуб отличаются наложенными текстами, но мне кажется, это не должно как-то сильно влиять, т.к. эта часть картинки статична.
Для ютюба предпочтительней постоянный битрейт
Двухпроходное кодирование не имеет преимуществ перед CRF из libx264 при восприятии человеком, кроме разве что возможности заранее задать точный результирующий размер файла. CRF-кодирование — это вершина эволюции для сжатия в H.264, а устаревшее двухпроходное кодирование осталось приоритетным только в проприетарном ПО от компаний так или иначе связанных с MPEG LA (к примеру Adobe), остальные же от него давно отказались.
В моём случае получается, что ffmpeg «на лету» конвертирует мой файл из mp4 в flv.
Имхо, если один раз конвертнуть его, то можно будет сильно сэкономить в CPU.
Я в курсе. Рендер основных файлов занимает порядка 5 часов. А если взять все время на подготовку, съемку, монтаж, рендер, публикацию на сайт – это уже занимает около 15 часов в неделю. Многовато для хобби.

Хотя вот писал вам ответ и понял, что можно попробовать автоматизировать конвертацию на сервере. Чтобы я все также загружал оригинальные файлы, а сервак уже сам их конвертил и запускал в трансляцию, когда будет готов flv. Надо подумать.
Естественно. Тем же ffmpeg с теми же параметрами только сначала в файл. А на Youtube уже отдавать без конвертации.
Я так понял, что перекодировка нужна только из-за субтитров?
Почему не воспользоваться API youtube и менять название на соответствующее?
Или как вариант чтоб ускорить перекодировку использовать аппаратные кодеки (Quick Sync, NVEnc), благо они поддерживаются даже под windows.
На моем старом i5-4670 при кодировании 720p в битрейт 3500 время кодирования 3-4 меньше времени видео

Если речь о файлах, то зачем их перекодировать на лету? Один раз скодировать, сохранить в файл да раздавать из файла заранее перекодированное — нагрузка на процессор будет около нуля.


А ещё меня смущает, что каждый файл передаётся отдельным ффмпегом. В момент после завершения первого ффмпега и перед запуском второго происходит фактически обрыв стрима, а его перезапуск не мгновенный. Значит из стрима выпадут несколько десятков/сотен миллисекунд, и в конце концов зрители «догонят» стрим и он наверное начнёт подлагивать.

#!/bin/bash

for i in *.mp4; do
       ffmpeg -hide_banner -nostats -i "$i" -c:v mpeg2video [proper settings] -f mpegts -
done | mbuffer -q -c -m 20000k | ffmpeg -hide_banner -nostats -re -fflags +igndts -thread_queue_size 512 -i pipe:0 -fflags +genpts [proper codec setting] -f flv rtmp://a.rtmp.youtube.com/live2/...
Вернее так даже лучше:
for f in *.mp4; do
    cat "$f"
done | mbuffer -q -c -m 20000k | ffmpeg -hide_banner -nostats -i pipe:0 -f flv rtmp://a.rtmp.youtube.com/live2/...

А для этого нужно mp4 специальным образом закодировать и pts/dts как-то пересчитать

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

По поводу предварительного перекодирования файлов соглашусь с вами. Нагрузку на процессор это может снизить существенно, но увеличит нагрузку на меня)) В общем и целом это хобби требует порядка 15 часов в неделю, что много для хобби. Отдельный рендер в flv потребует еще порядка 3 часов. Хотелось бы наоборот время сокращать. Выше уже отвечал на этот вопрос. Своё время не хочется тратить, но появилась мысль настроить так, чтобы файлы автоматически конвертились на сервере.

UPD: Вспомнил еще одну причину по которой важно, чтобы каждый файл запускался отдельной командой – надписи на видео уникальны на каждом видео.
-re – указывает, что файл необходимо конвертировать в поток.

Чепуха, кстати. Эта опция всего лишь указывает, чтобы скорость чтения входного потока соответствовала скорости воспроизведения этого потока («at native frame rate»), то есть чтобы файл не читался быстрее чем нужно.


Здесь, кстати, запрятаны грабли. Я когда-то пытался стримить один и тот же файл, бесконечно зациклив его фильтром. В первую итерацию всё было хорошо, но со второй итерации fps улетал в небеса и стрим ломался к чертям. А всё потому, что опция -re влияет только на чтение входного потока, а после первой итерации он уже полностью прочитан и больше ни на что не влияет, а скорость фильтров никто не ограничивает. Поэтому если фильтры генерируют какой-то контент, который отсутствует во входных потоках (то же зацикленное видео, например), то скорость нужно ограничивать фильтрами realtime/arealtime.

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

Да, если настроить воспроизведение просто всех .mp4-файлов из каталога – это было бы универсальнее. Но как быть с надписями? Ведь для каждого видео нужна своя подпись, которая актуальна только для этого файла.
А зачем? Выложите плейлист. Удобно же, захотел, прокрутил. Выбрал лекцию.
Или это не про удобство, а про то как заработать денег на youtube?
На канале нет и 100 подписчиков, о каких деньгах речь? :) Скорее это попытка получить больше охваты т.к. стримы на ютубе размещаются в отдельном разделе. Ну и плейлист – это банально, трансляция выглядела интересной технической задачей :)
Only those users with full accounts are able to leave comments. Log in, please.