DmitrySvit Mar 20 2020 at 17:34

Круглосуточная трансляции своих видео на YouTube

11 min

77K

*nix*DIY

From sandbox

+31

Comments 20

denaspireone Mar 20 2020 at 17:43

Вот вам прямо стримы запихивать в 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

chyvack Mar 20 2020 at 20:34

Для ffmpeg можно использовать двух-проходное сжатие (2pass encoding).
Возможен ли такой вариант: вы создаёте лог первого прохода дома на компе с оригинальных видео, затем на сервере используете этот лог 1-го прохода для кодирования (я так понял в нём содержится информация для энкодера какие сцены кодировать с повышенным/пониженным битрейтом)? Правда видео оригинальное и отправляемое на ютуб отличаются наложенными текстами, но мне кажется, это не должно как-то сильно влиять, т.к. эта часть картинки статична.

semen-pro Mar 21 2020 at 14:04

Для ютюба предпочтительней постоянный битрейт

iDm1 Mar 21 2020 at 15:30

Двухпроходное кодирование не имеет преимуществ перед CRF из libx264 при восприятии человеком, кроме разве что возможности заранее задать точный результирующий размер файла. CRF-кодирование — это вершина эволюции для сжатия в H.264, а устаревшее двухпроходное кодирование осталось приоритетным только в проприетарном ПО от компаний так или иначе связанных с MPEG LA (к примеру Adobe), остальные же от него давно отказались.

savostin Mar 20 2020 at 20:48

В моём случае получается, что ffmpeg «на лету» конвертирует мой файл из mp4 в flv.

Имхо, если один раз конвертнуть его, то можно будет сильно сэкономить в CPU.

DmitrySvit Mar 21 2020 at 19:56

Я в курсе. Рендер основных файлов занимает порядка 5 часов. А если взять все время на подготовку, съемку, монтаж, рендер, публикацию на сайт – это уже занимает около 15 часов в неделю. Многовато для хобби.

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

savostin Mar 21 2020 at 20:18

Естественно. Тем же ffmpeg с теми же параметрами только сначала в файл. А на Youtube уже отдавать без конвертации.

PbIXTOP Mar 23 2020 at 04:32

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

andreymal Mar 20 2020 at 22:11

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

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

savostin Mar 20 2020 at 22:50

#!/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/...

savostin Mar 20 2020 at 23:57

Вернее так даже лучше:

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/...

andreymal Mar 21 2020 at 00:22

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

anba8005 Jan 18 2021 at 19:42

ffmpeg -stream_loop -1 -i file.mp4…

DmitrySvit Mar 21 2020 at 20:07

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

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

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

andreymal Mar 20 2020 at 23:13

-re – указывает, что файл необходимо конвертировать в поток.

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

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

nikolau Mar 21 2020 at 07:48

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

DmitrySvit Mar 21 2020 at 20:15

Да, если настроить воспроизведение просто всех .mp4-файлов из каталога – это было бы универсальнее. Но как быть с надписями? Ведь для каждого видео нужна своя подпись, которая актуальна только для этого файла.

pewpew Mar 21 2020 at 10:50

А зачем? Выложите плейлист. Удобно же, захотел, прокрутил. Выбрал лекцию.
Или это не про удобство, а про то как заработать денег на youtube?

DmitrySvit Mar 21 2020 at 20:28

На канале нет и 100 подписчиков, о каких деньгах речь? :) Скорее это попытка получить больше охваты т.к. стримы на ютубе размещаются в отдельном разделе. Ну и плейлист – это банально, трансляция выглядела интересной технической задачей :)

Ahen Mar 27 2020 at 02:00

UPD: написал чушь

Show the best of all time