비디오 인코딩 속도를 XNUMX배로 높이는 방법

매일 수백만 명의 시청자가 인터넷에서 동영상을 시청합니다. 하지만 비디오를 사용할 수 있으려면 서버에 업로드할 뿐만 아니라 처리도 수행해야 합니다. 이 작업이 빠를수록 서비스와 사용자에게 더 좋습니다.

제 이름은 Askar Kamalov이고, XNUMX년 전에 Yandex 비디오 기술 팀에 합류했습니다. 오늘 저는 Habr 독자들에게 인코딩 프로세스를 병렬화하여 사용자에게 비디오를 전달하는 속도를 크게 높일 수 있었던 방법에 대해 간략하게 설명하겠습니다.

이 게시물은 주로 비디오 서비스 내부에서 무슨 일이 일어나는지 이전에 생각해 본 적이 없는 사람들에게 흥미로울 것입니다. 댓글에서 질문을 하고 향후 게시물에 대한 주제를 제안할 수 있습니다.

작업 자체에 대한 몇 마디. Yandex는 다른 사이트에서 동영상을 검색하는 데 도움이 될 뿐만 아니라 자체 서비스를 위해 동영상을 저장하는 데도 도움이 됩니다. 오리지널 프로그램, 방송 중인 스포츠 경기, KinoPoisk의 영화, Zen 및 News의 비디오 등 이 모든 것이 당사 서버에 업로드됩니다. 사용자가 비디오를 시청하려면 필요한 형식으로 변환하거나 미리보기를 생성하거나 기술을 실행하는 등의 준비가 필요합니다. DeepHD. 준비되지 않은 파일은 공간만 차지합니다. 또한 우리는 최적의 하드웨어 사용뿐만 아니라 사용자에게 콘텐츠를 전달하는 속도에 대해서도 이야기하고 있습니다. 예: 하키 경기의 결정적인 순간에 대한 녹화물은 이벤트 발생 후 XNUMX분 이내에 검색될 수 있습니다.

순차 인코딩

따라서 사용자의 행복은 동영상이 얼마나 빨리 제공되는지에 크게 좌우됩니다. 그리고 이는 주로 트랜스코딩 속도에 의해 결정됩니다. 비디오 업로드 속도에 대한 엄격한 요구 사항이 없으면 문제가 없습니다. 분할할 수 없는 단일 파일을 가져와서 변환하고 업로드합니다. 여정을 시작할 때 우리가 작업한 방식은 다음과 같습니다.

클라이언트는 비디오를 스토리지에 업로드하고, 분석기 구성 요소는 메타 정보를 수집하고 변환을 위해 비디오를 작업자 구성 요소로 전송합니다. 모든 단계는 순차적으로 수행됩니다. 이 경우 인코딩 서버는 여러 개가 있을 수 있지만 특정 비디오를 처리하는 서버는 단 하나만 사용됩니다. 간단하고 투명한 다이어그램. 이것이 장점이 끝나는 곳입니다. 이 구성표는 더 강력한 서버 구매로 인해 수직으로만 확장할 수 있습니다.

중간 결과가 포함된 순차적 인코딩

고통스러운 기다림을 어떻게든 완화하기 위해 업계에서는 빠른 코딩 옵션을 고안했습니다. 이름은 오해의 소지가 있습니다. 실제로 전체 코딩은 순차적으로 발생하고 시간이 오래 걸리기 때문입니다. 그러나 중간 결과가 있습니다. 아이디어는 다음과 같습니다. 가능한 한 빨리 저해상도 버전의 비디오를 준비하고 게시한 다음 고해상도 버전만 게시하는 것입니다.

한편으로는 비디오를 더 빠르게 이용할 수 있게 됩니다. 그리고 중요한 행사에 유용합니다. 그러나 반면에 사진이 흐릿하게 나타나 보는 사람을 짜증나게 합니다.

비디오를 빠르게 처리하는 것뿐만 아니라 품질도 유지해야 한다는 것이 밝혀졌습니다. 이것이 바로 사용자가 현재 비디오 서비스에 기대하는 것입니다. 가장 생산적인 서버를 구입하고 정기적으로 한 번에 업그레이드하는 것만으로도 충분해 보일 수 있습니다. 그러나 가장 강력한 하드웨어라도 속도를 늦추는 비디오가 항상 있기 때문에 이것은 막다른 골목입니다.

병렬 인코딩

복잡한 문제를 덜 복잡한 여러 문제로 나누고 여러 서버에서 동시에 해결하는 것이 훨씬 더 효율적입니다. 동영상용 MapReduce 입니다. 이 경우 서버 한 대의 성능에 제한을 받지 않고 수평적으로 확장할 수 있습니다(새 시스템을 추가하여).

그건 그렇고, 비디오를 작은 조각으로 나누고 병렬로 처리하고 함께 붙이는 아이디어는 비밀이 아닙니다. 이 접근 방식에 대한 많은 참고 자료를 찾을 수 있습니다. 예를 들어 Habré에서 프로젝트에 대한 게시물을 추천합니다. DistVIDc). 하지만 이것이 전반적으로 더 쉬워지는 것은 아닙니다. 기성 솔루션을 집에 설치할 수는 없기 때문입니다. 인프라, 비디오, 심지어 로드에도 적응이 필요합니다. 일반적으로 직접 작성하는 것이 더 쉽습니다.

그래서 새로운 아키텍처에서는 순차 코딩을 사용하는 모놀리식 Worker 블록을 마이크로서비스 Segmenter, Tcoder, Combiner로 나누었습니다.

1. Segmenter는 비디오를 약 10초 단위의 조각으로 나눕니다. 조각은 하나 이상의 GOP(사진 그룹). 각 GOP는 독립적이고 별도로 인코딩되므로 다른 GOP의 프레임을 참조하지 않고 디코딩할 수 있습니다. 즉, 조각은 서로 독립적으로 재생할 수 있습니다. 이 샤딩은 대기 시간을 줄여 처리를 더 일찍 시작할 수 있게 해줍니다.
2. Tcoder는 각 조각을 처리합니다. 대기열에서 작업을 가져와 저장소에서 조각을 다운로드하고 이를 다른 해상도로 인코딩한 다음(플레이어가 연결 속도에 따라 버전을 선택할 수 있음을 기억하세요) 결과를 저장소에 다시 넣고 조각을 처리된 것으로 표시합니다. 데이터베이스에서. 모든 조각을 처리한 후 Tcoder는 다음 구성 요소에 대한 결과를 생성하는 작업을 보냅니다.
3. Combiner는 결과를 함께 수집합니다. Tcoder에서 만든 모든 조각을 다운로드하고 다양한 해상도에 대한 스트림을 생성합니다.

소리에 관한 몇 마디. 가장 널리 사용되는 AAC 오디오 코덱에는 불편한 기능이 있습니다. 조각을 별도로 인코딩하면 조각을 완벽하게 연결할 수 없습니다. 전환이 눈에 띄게 나타납니다. 비디오 코덱에는 이 문제가 없습니다. 이론적으로는 복잡한 기술 솔루션을 찾을 수 있지만 이 게임은 아직 가치가 없습니다(오디오의 무게는 비디오보다 훨씬 적습니다). 따라서 비디오만 병렬로 인코딩되고 오디오 트랙 전체가 처리됩니다.

조사 결과

병렬 비디오 처리 덕분에 비디오가 우리에게 업로드되고 사용자에게 제공되기까지의 지연 시간이 크게 줄었습니다. 예를 들어, 이전에는 15시간 XNUMX분 동안 지속되는 FullHD 영화에 대해 서로 다른 품질의 여러 풀 버전을 만드는 데 XNUMX시간이 걸렸습니다. 이제 이 모든 작업에 XNUMX분이 소요됩니다. 또한 병렬 처리를 통해 기존 중간 결과 접근 방식을 사용하는 저해상도 버전보다 훨씬 빠르게 고해상도 버전을 생성합니다.

그리고 하나 더. 이전 접근 방식에서는 서버가 충분하지 않았거나 작업 없이 유휴 상태였습니다. 병렬 코딩을 사용하면 철 재활용 비율을 높일 수 있습니다. 이제 천 개가 넘는 서버로 구성된 클러스터는 항상 무언가로 바쁩니다.

사실 아직 개선의 여지가 있습니다. 예를 들어 비디오 전체가 도착하기 전에 비디오 조각 처리를 시작하면 상당한 시간을 절약할 수 있습니다. 그들이 말했듯이, 더 많은 것이 올 것입니다.

영상 작업 분야에서 읽고 싶은 작업이 무엇인지 댓글로 적어주세요.

업계 동료의 경험에 대한 유용한 링크

• SVE: Facebook 규모의 분산 비디오 처리
• Archer를 통해 Netflix에서 미디어 혁신을 단순화합니다. 넷플릭스 기술 블로그

출처 : habr.com