연중무휴 YouTube에서 동영상을 방송하세요

최근에는 취미로 제가 아는 심리학자의 강의를 촬영하고 있어요. 영상을 편집하여 웹사이트에 게시합니다. 한 달 전, 저는 이 강의를 YouTube에서 연중무휴 24시간 방송하자는 아이디어를 얻었습니다. 개인 성장에 전념하는 일종의 주제별 "TV 채널"입니다.

나는 정규 방송을 하는 방법을 알고 있다. 하지만 비디오 파일의 방송이 되도록 만드는 방법은 무엇입니까? 연중무휴 24시간 운영되고, 유연하고, 최대한 자율적이며, 동시에 내 집 컴퓨터에 어떤 식으로든 의존하지 않습니다. 이것이 내가 알아내야 했던 것입니다.

해결책을 찾는 데 며칠이 걸렸습니다. 나는 내 방송이 제대로 작동하지 않았을 수많은 포럼과 다양한 매뉴얼을 연구했습니다. 이제 장난이 성공했으니 내 해결책을 공유해야겠다는 생각이 들었습니다. 이런 기사가 나왔어요.

간단히 말해서 최종 해결책은 다음과 같습니다. VPS + ffmeg + bash 스크립트. 컷 아래에는 진행 과정을 설명하고 방송을 구성하면서 발견한 함정에 대해 이야기합니다.

1단계 - 방송은 어디에서 제공되나요?

처음에는 방송의 출처와 출처를 결정하는 것이 필요했습니다. 가장 먼저 떠오른 것은 집 컴퓨터에서. 비디오를 재생 목록으로 수집하고 비디오 플레이어에서 재생을 시작하세요. 그런 다음 화면 이미지를 캡처하여 YouTube에 방송합니다. 그러나 나는 이 옵션을 거의 즉시 거부했습니다. 왜냐하면... 이를 구현하려면 가정용 컴퓨터를 계속 켜두어야 합니다. 즉, 밤에도 쿨러에서 소음이 발생하고 전기 소비량이 증가합니다(매월 +100-150kWh). 그리고 방송 중에는 집에 있는 컴퓨터를 사용할 수 없는 것으로 나타났습니다. 마우스의 움직임은 방송에 표시됩니다.

그러다가 옆을 보기 시작했어요 클라우드 서비스. 나는 내 비디오를 업로드하거나 예를 들어 YouTube의 비디오 링크를 삽입할 수 있고 이 모든 것이 하나의 논스톱 방송으로 패키지되는 기성 서비스를 찾고 있었습니다. 그러나 나는 적합한 것을 찾지 못했습니다. 제가 잘 검색을 안 했을 수도 있겠네요. 그 기능에 딱 맞는 것이 여러 플랫폼에 동시 방송을 도와주는 서비스인 restream.io 뿐입니다. 자신의 동영상을 업로드할 수 있게 해주는 것 같습니다. 하지만 이 서비스는 완전히 다른 목적으로 만들어졌으며 방송은 몇 시간 정도만 지속될 것으로 예상됩니다. 이 서비스를 통해 XNUMX시간 방송이 가능해진다면 한 달에 수십 달러, 심지어 수백 달러까지 늘어날 것이라고 생각합니다. 하지만 나는 여전히 무료로 또는 최소한의 재정적 투자로 방송을 구성하고 싶었습니다.

방송을 위해 필요하다는 것이 분명해졌습니다. 별도의 장치 아니면 별도의 컴퓨터라도요. 나는 Raspberri Pi와 같은 것을 생각하고있었습니다. 그리고 뭐? 그 사람은 쿨러가 없어요. 플래시 드라이브에 영상을 녹화하고, 이더넷 케이블을 연결한 뒤 한적한 곳에 놓아두고 방송했습니다. 옵션. 하지만 저는 보드 자체도, 작업 경험도 없었기 때문에 이 옵션도 거부했습니다.

그 결과, 나는 창조에 대해 논의하는 특정 토론을 접하게 되었습니다. 자체 서버 방송. 정확히 제가 찾던 것은 아니었지만 핵심 아이디어는 얻었습니다. 서버를 사용할 수 있다는 것입니다! 그 논의에서는 VPS + nginx + OBS의 조합을 사용하는 것이 제안되었습니다. 이 조합이 나에게도 어울릴 수 있다는 것이 분명해졌습니다. 저를 혼란스럽게 했던 유일한 점은 저는 서버를 관리해 본 적이 없었고, 전용 서버를 갖는 것이 혼란스럽고 비용이 많이 든다는 것이었습니다. 최소한의 구성으로 서버를 임대하는 데 비용이 얼마나 드는지 알아보기로 결정했고 기분 좋게 놀랐습니다.

가격은 벨로루시 루블로 표시되며 이는 단지 부스러기일 뿐입니다. 이해하자면 8 벨로루시 루블은 약 3.5 달러 또는 240 러시아 루블입니다. 24시간 내내 켜져 있고 빠른 인터넷 접속이 가능한 본격적인 컴퓨터를 한 달 동안 사용했습니다. 왠지 이 발견은 나에게 매우 즐거웠고 며칠 동안 나는 우주 로켓을 발견한 어린아이처럼 몹시 행복하게 돌아다녔다 :)

그건 그렇고, 나는 "VPS 임대"라는 검색어에 대해 Google이 나에게 제공한 첫 번째 사이트의 제안을 활용했습니다. 아마도 더 많은 예산 솔루션이 있을 수 있지만 이 가격이 나에게 적합했기 때문에 더 이상 고려하지 않았습니다.

서버를 생성할 때 서버가 실행될 운영 체제를 선택할 수 있습니다. 나열된 시스템 중 하나에서 방송을 구성하고 선호도와 재정적 능력에 따라 선택할 수 있습니다(Windows가 설치된 서버의 경우 추가 비용이 필요함). 저는 CentOS를 선택했습니다. 이전에는 경험이 거의 없었기 때문입니다.

2단계 - 서버 설정

서버를 만든 후 가장 먼저 해야 할 일은 SSH를 통해 서버에 연결하는 것입니다. 처음에는 PuTTy를 사용했지만, 이후 Google Chrome에서 실행되는 Secure Shell 앱을 사용하기 시작했습니다. 나에게는 더 편리한 것으로 판명되었습니다.

그런 다음 호스트 이름을 변경하고, 서버에서 시간 동기화를 설정하고, 시스템을 업데이트하고, iptables를 수정하고, 기타 여러 가지 작업을 수행했지만 꼭 필요해서가 아니었습니다. 저는 단지 서버 설정에 관심이 있었고 그것은 저에게 효과적이었습니다. 운동할 때 너무 좋아요 :)

수행해야 할 단계는 다음과 같습니다.

1. EPEL 저장소를 연결합니다.
2. FTP 서버를 설정합니다(저는 vsftp를 선택했습니다).
3. ffmpeg를 설치하세요.

자세한 명령을 내리지는 않겠습니다; 이 지침은 일반적인 행동 계획을 전달하기 위한 개념적인 것입니다. 어떤 단계에서든 어려움이 있는 경우 "CentOS connect EPEL" 또는 "CentOS install FTP server"와 같은 검색 엔진 쿼리를 사용하여 신속하게 해결할 수 있습니다. 첫 번째 링크에서 자세한 단계별 지침을 찾을 수 있습니다.

그래서 앞서 쓴 것처럼 VPS + nginx + OBS 조합이 필요했습니다. VPS – 준비되었습니다. 그러나 다른 점에서도 의문이 생기기 시작했습니다. OBS는 방송 프로그램인 Open Broadcaster Software입니다. 그리고 스트림에서만 작동합니다. 예를 들어 웹캠에서 이미지를 가져와 방송합니다. 아니면 화면 녹화. 또는 이미 진행 중인 방송이 다른 사이트로 리디렉션됩니다. 하지만 스트림이 없고 스트림으로 만들어야 하는 비디오 파일 세트만 있습니다.

나는 이 방향으로 파기 시작했고 ffmpeg를 발견했습니다. FFmpeg는 다양한 형식으로 디지털 오디오 및 비디오를 녹음, 변환 및 스트리밍할 수 있는 무료 오픈 소스 라이브러리 세트입니다.

그리고 ffmpeg가 얼마나 많은 일을 할 수 있는지 매우 놀랐습니다. 원하는 경우 비디오에서 사운드를 추출합니다. 원한다면 녹화하지 않고 비디오의 일부를 잘라낼 수도 있습니다. 원하는 경우 한 형식에서 다른 형식으로 변환됩니다. 그리고 훨씬 더. 파일을 지정할 수 있을 정도로 파일을 스트림으로 변환하여 YouTube 자체로 전송합니다. 그게 다야, 체인이 조립되었습니다. 남은 것은 뉘앙스를 마무리하는 것입니다.

3단계 - 방송 설정

우리는 YouTube에서 방송을 만듭니다. 이 단계에서는 링크와 브로드캐스트 키만 필요합니다. 아래 스크린샷에서는 빨간색으로 강조 표시되어 있습니다.

다음 비디오 파일을 서버에 업로드하고, 우리가 방송할 계획이에요. 실제로 FTP는 이 단계에서만 필요합니다. 서버에 파일을 업로드하는 또 다른 편리한 방법이 있다면 FTP 서버를 설정할 필요가 없습니다.

스트림을 YouTube로 전송합니다. 브로드캐스트를 시작하려면 여러 속성을 사용하여 ffmpeg를 실행해야 합니다. 내가 얻은 가장 짧은 명령은 다음과 같습니다.

ffmpeg -re -i lecture1.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%

속성 디코딩-re – 파일을 스트림으로 변환해야 함을 나타냅니다.

-i – 재생해야 할 파일을 나타냅니다. 비디오 파일 자체가 있는 동일한 디렉터리에서 명령을 실행하는 것이 중요합니다. 그렇지 않으면 다음과 같이 파일에 대한 절대 링크를 지정해야 합니다. /usr/media/lecture1.mp4.

-f – 출력 파일 형식을 설정합니다. 내 경우에는 ffmpeg가 내 파일을 mp4에서 flv로 즉시 변환하는 것으로 나타났습니다.

마지막에는 방송 설정 페이지에 YouTube에서 가져온 데이터가 표시됩니다. 방송이 채널에 구체적으로 표시되도록 데이터를 전송해야 하는 주소와 방송 키.

모든 작업을 올바르게 수행했다면 이 명령을 실행한 후 YouTube에서 전송된 스트림을 볼 수 있습니다. 방송을 시작하려면 YouTube 자체에서 '방송 시작' 버튼을 클릭하기만 하면 됩니다.

4단계 - 자율성 추가

축하해요! 이제 비디오 파일에서 방송을 시작하는 방법을 알았습니다. 하지만 XNUMX시간 연중무휴 방송에는 이것만으로는 충분하지 않습니다. 첫 번째 비디오 재생이 끝나면 다음 비디오가 즉시 시작되고 모든 비디오가 표시되면 재생이 다시 시작되는 것이 중요합니다.

나는 다음 옵션을 생각해 냈습니다. 각 비디오 파일에 대한 명령을 작성한 .sh 파일을 만들고 맨 끝에 동일한 스크립트를 다시 실행하는 명령을 표시했습니다. 결과는 다음과 같은 재귀입니다.

Команда 1... (запуск трансляции файла lecture1.mp4)
Команда 2... (запуск трансляции файла lecture2.mp4)
Команда 3... (запуск трансляции файла lecture3.mp4)
bash start.sh

그리고 네, 효과가 있었습니다. 만족한 마음에 테스트 방송을 시작하고 잠자리에 들었습니다.

아침에 불쾌한 놀라움이 나를 기다리고있었습니다. 방송은 몇 분밖에 진행되지 않았으며 컴퓨터를 끄자마자 거의 즉시 종료되었습니다. 조사 결과, 이러한 방식으로 실행된 명령은 사용자가 서버에 로그인되어 있는 동안 실행되는 것으로 나타났습니다. 연결을 끊자마자 실행 중이던 명령이 중단되었습니다. 이런 일이 발생하지 않도록하려면 팀 앞에서 충분합니다. bash 명령을 추가하세요 nohup. 이렇게 하면 실행 중인 프로세스가 사용자의 존재 여부에 관계없이 실행될 수 있습니다.

스크립트의 최종 최소 버전은 다음과 같습니다.

ffmpeg -re -i lecture1.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
ffmpeg -re -i lecture2.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
ffmpeg -re -i lecture3.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
nohup bash start.sh $

여기서 start.sh는 이 스크립트가 작성된 파일입니다. 그리고 이 파일은 비디오 파일과 동일한 디렉터리에 있어야 합니다.

끝에 달러 기호를 추가하면 프로세스가 백그라운드에서 실행되어 방송을 중단하지 않고 콘솔을 계속 사용할 수 있습니다.

보너스에는 다음과 같은 상품이 포함되었습니다.

• 파일 재생을 수동으로 전환할 수 있습니다. 이렇게 하려면 현재 실행 중인 ffmpeg 프로세스를 "종료"해야 합니다. 그 후 목록의 다음 파일 재생이 자동으로 시작됩니다.
• 방송을 중단하지 않고도 방송에 새로운 영상을 추가할 수 있습니다. 비디오를 서버에 업로드하고 스크립트에서 이 파일을 실행하는 명령을 추가한 후 저장하면 됩니다. 그게 다야. 다음 재생 라운드에서는 새 파일이 이전 파일과 함께 방송됩니다.

5단계 - ffmpeg 사용자 정의

원칙적으로 우리는 거기에서 멈출 수도 있었습니다. 하지만 시청자들에게 좀 더 친근한 방송을 만들고 싶었어요.

어떤 사람이 방송에 가서 보기 시작했고, 좋아요가 있어서 처음부터 이 강의를 보고 싶었는데 방송에서는 되감기가 허용되지 않는다고 가정해 보겠습니다. 강의를 처음부터 보려면 내 웹사이트에 가서 관심 있는 강의를 녹음해야 합니다. 어떤 강의가 그 사람의 관심을 끌었는지 어떻게 알 수 있나요? 사이트에는 이미 16개의 강의가 있으며 매주 더 많은 강의가 제공됩니다. 이 모든 강의를 촬영하고 편집한 나조차도 무작위로 어떤 강의인지 판단할 수 없을 것이라고 생각합니다. 그러므로 각 강의를 어떻게든 지정하는 것이 필요하다.

편집 프로그램에서 원본 비디오 파일에 캡션을 추가하는 옵션이 나에게 적합하지 않았습니다. 원본 파일이 사용되었는지 확인해야 했습니다. 그래서 방송을 지원하려면 몸의 움직임이 최소화되어야 합니다.

ffmpeg가 이 문제에도 도움이 될 수 있다는 것이 밝혀졌습니다. 특별한 속성을 가지고 있어요 -vf, 비디오 위에 텍스트를 배치할 수 있습니다. 비디오에 텍스트를 추가하려면 명령에 다음 조각을 추가해야 합니다.

-vf drawtext="fontfile=OpenSans.ttf:text='Лекция 13: Психология эмоций. Как создавать радость?':fontsize=26:fontcolor=white:borderw=1:bordercolor=black:x=40:y=670"

매개변수 설명fontfile= – 글꼴 파일에 대한 링크입니다. 그렇지 않으면 캡션이 비디오에 추가되지 않습니다. 가장 쉬운 방법은 글꼴 파일을 비디오와 같은 폴더에 넣는 것입니다. 또는 파일의 전체 경로를 지정해야 합니다.

text= – 실제로는 동영상 위에 배치해야 하는 텍스트 자체입니다.

fontsize= – 글꼴 크기(픽셀).

fontcolor= - 글꼴 색상.

borderw= – 텍스트 주변의 윤곽선 두께(픽셀 단위)(검은색 윤곽선이 1픽셀 두께인 흰색 텍스트가 있습니다).

bordercolor= – 윤곽선 색상.

x= и y= – 텍스트 좌표. 점 0;0 왼쪽 상단에 위치해 있습니다. 내 좌표는 1280x720 픽셀의 비디오 해상도로 텍스트가 왼쪽 하단에 배치되는 방식으로 선택됩니다.

다음과 같습니다.

6단계 – 방송 품질 결정

이제 방송이 준비되었습니다. FFmpeg 방송, 파일 재생, 방송에 내 존재가 필요하지 않습니다. 모든 강의에도 서명이 있습니다. 그게 다인 것 같습니다.

그러나 또 다른 미묘한 차이가 드러났습니다. 최소 서버 구성을 선택했는데 방송이 나오지 않았습니다. 서버 구성: 1개 코어(예: 2.2GHz), 1GB RAM, 25GB SSD. RAM은 충분했지만 프로세서는 거의 100%(때로는 102-103%까지 로드됨)로 거의 완전히 로드되었습니다. 이로 인해 방송이 몇 초마다 정지되었습니다. 좋지 않습니다.

두 개의 코어로 더 비싼 구성을 취할 수도 있지만 다행스럽게도 클라우드 기술을 사용하면 몇 개의 버튼을 눌러 서버 구성을 변경할 수 있습니다. 하지만 최소한의 구성 용량에 맞추고 싶었습니다. 저는 ffmpeg 문서를 연구하기 시작했고, 그렇습니다. 시스템의 로드를 조절할 수 있는 설정도 있습니다.

높은 이미지 품질은 높은 CPU 로드 또는 높은 나가는 트래픽이라는 두 가지 방법으로 달성할 수 있습니다. 프로세서가 감당할 수 있는 로드가 많아질수록 필요한 채널 대역폭도 줄어드는 것으로 나타났습니다. 또는 프로세서를 너무 많이 로드할 수 없지만 트래픽 헤드룸이 큰 넓은 채널이 필요합니다. 프로세서와 나가는 채널/트래픽의 크기 모두에 제한이 있는 경우 방송이 원활하게 진행되도록 영상 품질을 줄여야 합니다.

내 서버는 10Mbit/s 폭의 채널에 액세스할 수 있습니다. 이 너비가 딱 맞습니다. 그러나 트래픽 제한은 월 1TB입니다. 따라서 트래픽 제한을 충족하려면 나가는 흐름이 초당 최대 300KB를 초과해서는 안 됩니다. 나가는 스트림의 비트 전송률은 2,5Mbit/s 이하여야 합니다. 그런데 YouTube에서는 이 비트레이트로 방송할 것을 권장합니다.

시스템의 부하를 조절하기 위해 ffmpeg는 다양한 접근 방식을 사용합니다. 이것에 대해 잘 썼어요 여기에. 결국 두 가지 속성을 사용하게 되었습니다. -crf и -preset.

고정율 인자(CRF) – 영상의 품질을 조정할 수 있는 계수입니다. CRF는 0에서 51까지의 값을 가질 수 있습니다. 여기서 0은 소스 파일의 품질이고 51은 가능한 최악의 품질입니다. 17에서 28 사이의 값을 사용하는 것이 좋습니다. 기본값은 23입니다. 계수가 17이면 비디오는 시각적으로 원본과 동일하지만 기술적으로는 동일하지 않습니다. 또한 문서에는 지정된 CRF에 따라 최종 비디오의 크기가 기하급수적으로 변경된다고 명시되어 있습니다. 계수를 6포인트씩 늘리면 나가는 비디오의 비트 전송률이 두 배가 됩니다.

CRF를 사용하는 경우 나가는 사진의 "가중치"를 선택한 다음 다음을 사용할 수 있습니다. 사전 설정(-preset) 프로세서가 얼마나 많이 로드되는지 결정할 수 있습니다. 이 속성에는 다음 매개변수가 있습니다.

• ultrafast
• superfast
• veryfast
• faster
• fast
• medium - 기본값
• slow
• slower
• veryslow

매개변수가 "빠르게" 지정될수록 프로세서의 로드가 높아집니다.

먼저 기본적으로 내 프로세서에 너무 힘든 사전 설정을 선택한 다음 CRF를 사용하여 로드를 더 세밀하게 선택했습니다. 내 경우에는 사전 설정이 작동했습니다. fast, crf의 경우 값 24로 결정했습니다.

결론

그게 다야. 방송을 시작하기 위한 최종 명령은 다음과 같습니다.

ffmpeg -re -i lecture1.mp4 -vf drawtext="fontfile=OpenSans.ttf:text='Лекция 1: Жонглирование картинами мира':fontsize=26:fontcolor=white:borderw=1:bordercolor=black:x=40:y=670" -c:v libx264 -preset fast -crf 24 -g 3 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%

여기에는 설명되지 않은 두 가지 사항만 남아 있습니다.

1) -c:v libx264 – 소스 파일 작업을 위한 특정 코덱을 지정합니다.
2) -g 3 – 키 프레임 수를 명시적으로 표시합니다. 이 경우 세 번째 프레임마다 키 프레임이 되도록 지정합니다. 표준 값은 5 또는 8이지만 YouTube는 맹세하고 최소 3을 요구합니다.

방송의 품질이 어떤지 알 수 있습니다 여기에.

서버의 부하는 다음과 같았습니다.

모니터링 데이터에 따르면 프로세서 로드 범위는 70%~95%이며 주중에는 방송이 100%에 도달한 적이 없습니다. 이는 이러한 설정을 사용하면 프로세서로 충분하다는 것을 의미합니다.

디스크를 로딩해 보면 거의 로딩이 되지 않은 상태이고, 방송용으로는 일반 HDD 정도면 충분하다고 할 수 있습니다.

하지만 나가는 트래픽의 양이 걱정스럽습니다. 내가 나가는 스트림의 범위는 초당 450KB에서 650KB 사이인 것으로 나타났습니다. 한 달이면 약 1,8테라바이트가 됩니다. 추가 트래픽을 구입하거나 코어가 XNUMX개인 구성으로 전환해야 할 수도 있습니다. 사진의 품질을 낮추고 싶지 않습니다.

***

결과적으로 이러한 방송을 처음부터 설정하는 데 약 1~2시간이 소요된다고 말씀드리겠습니다. 게다가 비디오를 서버에 업로드하는 데 대부분의 시간이 걸립니다.

그러한 방송의 출시는 마케팅 도구로서의 자체를 정당화하지 못했습니다. 아마도 YouTube 알고리즘이 이 방송을 선택하여 추천에 적극적으로 표시하도록 조회수를 늘리면 문제가 해결될 것입니다. 나의 경우 연속방송 16일 동안 58회 시청됐다.

괜찮습니다. 방송은 내 웹사이트의 메인 페이지에 조화롭게 맞습니다. 이를 통해 강사와 강의 자체에 대한 내 의견을 빠르게 형성할 수 있는 기회를 얻었습니다.

그리고 잠시만요. 방송이 다른 사람의 저작권을 침해하지 않는 것이 중요합니다. 그렇지 않으면 차단됩니다. 나는 방송에 대해 차분한 편이다. 왜냐하면... 저는 무료로 사용할 수 있는 음악 삽입물을 특별히 선택했는데 콘텐츠 작성자가 근처 컴퓨터에 앉아 있고 자신의 콘텐츠를 사용하는 것을 전혀 반대하지 않습니다. :)

그러나 방송 어딘가에서 백그라운드로 라디오가 재생되고 있거나 편집 중에 좋아하는 트랙을 사용했거나 인기 뮤직 비디오, TV 시리즈 또는 영화에서 비디오 시퀀스를 가져온 경우 방송이 위험에 처해 있습니다. 또한 방송이 최소한의 의미 로드를 전달하는 것도 중요합니다. 그렇지 않으면 스팸으로 차단될 수 있습니다.

***

그게 내가 가진 전부입니다. 이 매뉴얼이 누군가에게 도움이 되기를 바랍니다. 글쎄, 추가하고 쓸 내용이 있으면 기사에 대한 추가 사항과 설명을 기꺼이 읽어 드리겠습니다.

출처 : habr.com