브라이트코브 라이브: 모범 사례

Video Cloud Live를 사용하면 라이브 이벤트를 쉽게 설정하고 웹, iOS 및 Android 디바이스로 멀티 비트레이트 스트림을 전달할 수 있습니다. 이 항목에서는 고품질의 안정적인 라이브 스트리밍 환경을 보장하는 데 도움이 되는 일련의 모범 사례 및 권장 사항에 대해 간략하게 설명합니다.

개요

브라이트코브 라이브는 라이브 스트리밍 이벤트 또는 연중무휴 라이브 스트림을 만들 수 있는 강력한 서비스를 제공합니다. 이 가이드에서는 실시간 스트림을 최적화하기 위한 모범 사례를 간략하게 설명합니다.

콘텐츠 컨텍스트

스트리밍되는 콘텐츠 유형은 입력 품질을 유지하는 데 필요한 설정에 영향을 미치므로 고려해야 합니다. 장단점이 있으며 가능한 가장 높은 설정을 사용하면 건너뛴 프레임과 같은 문제가 발생할 수 있습니다.

아래 정보에 따라 라이브 이벤트 전에 품질 및 성능에 대한 다양한 설정 조합을 테스트하는 것이 좋습니다.

주요 입력 매개변수는 다음 표에 설명되어 있습니다.

라이브 스트리밍을 위한 주요 입력 매개변수
매개 변수 참고 사항
입력 비트레이트 인코더가 전송하는 비트 전송률입니다. 속도가 높을수록 네트워크 손실에 더 취약하므로 가능한 한 낮게 유지해야 합니다.
입력 해상도 소스 콘텐츠와 일치해야 합니다. 이것을 원래 소스보다 크게 만드는 것은 이점이 없으며 이 값이 높을수록 이를 지원하기 위해 더 높은 비트 전송률이 필요합니다.
상위 프로필 비율에 대한 입력 비트 전송률 입력 비트 전송률은 상위 프로필의 속도보다 높아야 하지만 너무 높으면 프레임이 떨어지거나 다른 문제가 발생할 수 있습니다. 예를 들어 최고 속도가 1080p 30fps인 경우 입력은 이상적으로 약 4MBPS여야 합니다. 이는 프로필의 영향을 받습니다. 일반적으로 가장 높은 비트레이트 라이브 렌디션 비트레이트의 2배(2배)인 입력 비트레이트를 권장합니다.

높은 비트 전송률의 최고 출력이 필요한 경우 단순히 입력 인코딩을 출력에 복사하는 copy_video 설정을 테스트할 가치가 있습니다.

프로파일 다양한 프로필(기준선, 기본, 높음)은 데이터를 오름차순으로 압축합니다(기준선: 최저, 높음: 최고). 압축률이 높을수록 전송 속도가 향상되지만 데이터를 디코딩하는 데 더 많은 CPU 리소스가 필요합니다. 인코더가 사용 가능한 리소스 기준 프로필에서 크게 제한되지 않는 한 피해야 합니다. 반면에 높은 비트 전송률에서 높은 프로필을 사용하면 필요한 디코딩 CPU 리소스 증가로 인해 프레임 건너뛰기가 발생할 가능성이 더 큽니다.

또한 아래의 GOP 구조를 참조하십시오.

프레임 속도 소스와 일치해야 합니다.

속도가 높을수록 비례적으로 더 높은 입력 비트레이트가 필요합니다. 예를 들어 액션 스포츠 콘텐츠의 경우 60fps 입력 스트림은 30fps 스트림보다 훨씬 더 많은 데이터를 전달합니다.

60fps와 같은 높은 속도는 높은 비트 전송률의 복잡한 콘텐츠에서 프레임 건너뛰기 문제가 발생할 가능성이 더 큽니다.

키프레임 속도 이를 위한 가장 효율적인 설정은 세그먼트 기간 x 프레임 속도입니다. 예를 들어 세그먼트가 6초이고 30fps로 키프레임 속도를 180(6x30)으로 설정하면 디코더 로드가 가장 낮아집니다.

그러나 모든 변동을 고려하기 위해 프레임 속도의 2배로 설정됩니다(예: 프레임 속도 30fps의 경우 60).

GOP 구조 아래의 GOP 구조를 참조하십시오.

입력 제한

브라이트코브 라이브는 최고의 품질과 일관된 스트리밍 경험을 보장하기 위해 입력 스트림 설정을 다음과 같이 제한합니다.

  • 프로토콜: rtmp , rtprtp-fec , 또는srt (MPEG2-TS 입력을 제외한rtmp모든 항목) [1-1]
  • 해결: 최대 용량
  • 최대 30fps, 이는 전형적입니다. 브라이트코브는 최대 60fps를 지원하지만 한도를 늘리려면브라이트코브 지원에 문의해야합니다. 60fps를 사용하는 경우 Brightcove는 콘텐츠에 대해 원하는 시각적 품질과 일정한 프레임 속도를 얻기 위해 비트 전송률을 높일 것을 권장합니다.
  • 10Mbps 미만
  • 일정 비트레이트 (CBR) 는 문제 가능성을 크게 줄입니다.
  • 동영상 코덱은 H.264여야 합니다.
  • 슬라이스: 인코더에 이 옵션이 있는 경우 다음과 같이 설정하십시오. 1
  • 오디오 코덱은 다음과 같아야 합니다. AAC
  • 오디오 샘플링 속도: 44.1kHz 및 48kz는 권장되는 샘플 오디오 레이트입니다.
  • 키프레임 속도 또는 GOP (사진 그룹) 정렬:
    1. 키프레임은 입력과 출력(25fps 비디오 포함) 모두에 대해 항상 2초마다 발생해야 합니다. 즉, 스트림에서 2초마다 인코더에서 브라이트코브로 키프레임이 전송됩니다. 이 프로세스는 여러 가지 방법으로 정의할 수 있지만키프레임 속도가가장 일반적입니다.
    2. 다른 인코더에 의해 다른 방법으로 계산할 수 있습니다. 예:
      • 와이어캐스트는 통과하는 프레임 양을 사용하므로 30fps 비디오의 경우 설정은 60이 됩니다.
      • 엘리멘탈 엔코더는 초를 사용하므로 올바른 설정이 '2'가 됩니다.
      • 60 FPS 비디오는 이 설정이 프레임으로 계산되는 경우에만 변경됩니다. 이 경우 120 프레임마다 2 초가 됩니다.
  • [ 키프레임 정렬 ], [ GOP 동기화 ], [키프레임 정렬 ] 또는 해당 선을 따라 다른 항목이 있는 경우 키프레임이 정렬되어 있는지 확인합니다. 키프레임이 정렬되지 않으면 HLS 세그먼테이션에서 동기화 문제가 발생합니다.

참고 사항

  • [1-1] TS 입력에 여러 개의 비디오 / 오디오 트랙이있는 경우 각각에 대해 첫 번째 트랙을 선택합니다. 또한 인터넷을 통한 UDP를 통한 일반 TS는 매우 신뢰할 수 있으므로 FEC를 사용하는 것이 좋습니다. FEC의 경우작게행 / 열에 사용하는 값 일수록 오류 수정의 신뢰성이 높아집니다 (대역폭이 증가합니다.

스트리밍의 주요 문제

인코더에서 Brightcove로의 스트리밍 환경 문제와 관련하여 일반적으로 발생하는 몇 가지 문제가 있습니다.

  1. 입력에 영향을 미치는 네트워크 불안정성:
    1. 인터넷은 일반적으로 매우 안정적이지만 오류가 없는 것은 아니며 문제가 발생합니다. 비트 전송률이 높을수록 문제가 발견될 가능성이 더 큽니다.
    2. 실시간보다 비디오를 업로드하는 데 시간이 더 오래 걸리면 이로 인해 입력 드리프트가 발생할 수 있습니다(비디오를 수신한 시간이 보낸 시간보다 상당히 늦음).
  2. 프레임 건너뛰기로 인한 트랜스코더 과부하: 트랜스코더에 충분한 오버헤드가 있는지 확인하기 위해 모든 작업을 수행하는 동안 때때로 콘텐츠 복잡성, 네트워크 딸꾹질/캐치업 또는 기타 트랜스코더 중단으로 인해 프레임 건너뛰기가 발생할 수 있습니다. 입력이 복잡할수록 건너뛴 프레임이 발생할 가능성이 높아집니다. 5분 이상 연장된 시간 동안 스틸 이미지에서 변경하고 작업 콘텐츠를 갑자기 변경하면 과부하가 발생할 수 있는 알려진 문제도 있습니다.
  3. 가변 프레임 기간을 전송하는 인코더: 프레임 속도는 일정해야 하며 일정한 키프레임 간격을 허용해야 합니다. 예를 들어 29.97(30000/1001) 또는 23.976(24000/1001)과 같은 프레임 속도의 경우 일정한 간격으로 키프레임을 설정할 수 없으므로 피해야 합니다.
  4. 인코더가 일정 기간 떨어져 있지 않은 키프레임을 전송하는 경우 키프레임 속도는 프레임 속도의 최소 2배(초)여야 합니다. 예를 들어 프레임 속도가 30fps인 경우 키프레임 간격은 60프레임(2초)이어야 하며 최대 간격은 세그먼트당 한 번이어야 합니다. 예를 들어 세그먼트가 6초인 경우 최대 간격은 180프레임입니다. 30fps

콘텐츠 유형

일반적으로 더 복잡한 콘텐츠는 이러한 설정 중 더 높은 설정을 사용해야 하므로 프레임 건너뛰기에 더 취약합니다. 아래 표는 복잡성 순으로 몇 가지 예를 보여줍니다. 이는 예시일 뿐이며 거의 모든 인코더 설정이 다릅니다. 테스트 및 검증을 수행해야 합니다.

콘텐츠 유형 예
컨텐츠 타입 설정 예
웹캠
  • 해결: 360p
  • 전송률: 1MBPS
  • 프로필: 기준선
웹 컨퍼런스
  • 해결: 480p
  • 전송률: 2.5MBPS
  • 프로필: 기본
생기
  • 해결: 720p
  • 전송률: 2.5MBPS
  • 프로필: 기본
말하는 머리 / 뉴스
  • 해결: 720p
  • 전송률: 4MBPS
  • 프로필: 기본
라이브 콘서트
  • 해결: 1080p(또는 소스)
  • 전송률: 5MBPS
  • 프로필: 높은
라이브 스포츠
  • 해결: 1080p(또는 소스)
  • 전송률: 6MBPS
  • 프로필: 높은
라이브 스포츠 하이 FPS
  • 해결: 1080p(또는 소스)
  • 전송률: 10MBPS
  • 프로필: 높은

Transmux 라이브 작업

요청 분할 설정과 일치하도록 키 프레임 삽입을 설정합니다. 예를 들어 프레임 속도가 초당 25프레임이고 6초 세그먼트가 필요한 경우 키프레임 간격을 적어도 300프레임당 한 번으로 설정합니다.

원하는 대상 장치로 인코더 설정/출력을 테스트합니다. 이것은 일부 소비자 장치와 호환되지 않을 수 있는 스트림을 생성하는 고급 설정이 있을 수 있는 브로드캐스트 기여 인코더를 사용하는 경우에 특히 중요합니다. 특히 고급 설정을 피하는 것도 좋은 생각입니다. 가능한 인코더와 옵션이 너무 많기 때문에 이것이 정확히 무엇인지 말하기는 어렵습니다. 그러나 일반적인 최고 비율 프로필은 다음과 같아야 합니다.

  • 6Mbps 피크 비트 전송률
  • H264 하이 프로파일
  • B 프레임: 2
  • 8비트 4:2:0 컬러

확인 및 테스트

이상적으로는 가장 복잡한(가장 많이 변경되는 콘텐츠) 가장 낮은 설정으로 시작하고 출력이 허용될 때까지 다양한 설정을 늘려 콘텐츠를 테스트해야 합니다. 이는 일반적으로 설정이 높을수록 네트워크 또는 트랜스코딩에서 문제가 발생할 가능성이 높기 때문입니다.

대역폭 테스트

입력 스트림에 대한 적절한 설정에 도달하는 첫 번째 단계는 사이트에서 사용 가능한 대역폭을 결정하는 것입니다. 도움이 될 수 있는 몇 가지 도구가 있습니다.

  • SpeedOf.Me( https://speedof.me ) - HTTP 연결에 사용할 수 있는 총 대역폭을 결정하는 것이 좋은 첫 단계입니다. 그러나 입력 피드가 HTTP 대신 RTMP를 통해 Live 모듈로 스트리밍되므로 RTMP 연결에 사용할 수 있는 실제 대역폭은 상당히 줄어듭니다.
  • Speedtest( https://www.speedtest.net ) - 현재 업로드 및 다운로드 속도를 결정하는 온라인 도구입니다.

입력 대역폭

시청자에게 최상의 사용자 경험을 보장하는 유일한 방법은 고품질의 안정적인 입력 스트림을 제공하는 것입니다. 양호한 입력 스트림은 한 위치에서 지속적으로 사용 가능한 가장 높은 대역폭에서 최상의 비디오 품질을 제공합니다.

  • 최소 입력 대역폭: 2.5 메가 비프
  • 최대 입력 대역폭: 10 메가 프스

인코더 기능 판단

라이브 스트림을 인코딩하여 라이브 모듈로 전송하는 데 사용되는 소프트웨어 및 하드웨어의 기능을 이해하는 것도 중요합니다. 고품질의 1080p 입력 스트림을 보내려면 많은 비트 전송률이 있을 수 있지만 하드웨어는 실시간 속도보다 빠른 속도로 인코딩 할 수 있어야합니다. 일부 인코딩 도구는 사용 중인 총 CPU 사용량 및 대역폭에 대한 정보를 표시합니다. 예를 들어 Telestream Wirecast는 Wirecast 창 하단에 출력 통계를 표시합니다.

이 정보는 주어진 하드웨어에서 가능한 가장 안정적이고 최고 품질의 스트림을 결정할 때 유용합니다. 와이어캐스트에서 볼 수 있는 사항:

  • CPU는 80% 미만이어야 합니다.
  • 데이터 레이트는 대상 비트 전송률 근처에 있어야합니다.
  • FPS는 입력 스트림 설정 속도에 있어야합니다.

GOP 구조

비디오의 GOP(Group of Pictures) 구조는 먼저 다음과 같이 사용되는 프로필에 따라 달라집니다.

  1. 기본 프로필은 I 및 P 프레임과 CAVLC 엔트로피 인코딩만 지원합니다.
  2. MainHigh는 I, B 및 P 프레임과 CABAC 엔트로피 인코딩을 지원합니다.

기본 및 높음 프로필은 일반적으로 더 나은 품질로 더 나은 압축 결과를 가져오지만 인코딩 및 디코딩을 위해 추가 계산이 필요하므로 건너뛴 프레임에 더 취약할 수 있습니다. 또한 이러한 프로파일은 B(양방향) 프레임을 사용하므로 인코딩 프로세스에서 약간의 지연을 유발합니다.

기본 프로필은 인코딩 및 디코딩에 CPU가 덜 필요하지만 압축률이 낮기 때문에 품질을 유지하기 위해 더 높은 비트 전송률이 필요하므로 네트워크 문제에 더 취약합니다.

프레임 유형 및 성능에 미치는 영향에 대한 참고 사항:

  1. I 프레임 : 가장 많은 대역폭을 사용합니다. 전체 장면 변경 또는 세그먼트 경계에 추가하는 것이 가장 좋습니다. 즉, 콘텐츠가 더 많이 변경될수록 더 많은 항목이 필요합니다(더 짧은 GOP 길이).
  2. P 프레임 : I 프레임 사이의 기본 단위입니다.
  3. B 프레임 : 이전 프레임과 미래 프레임을 모두 사용합니다. 더 많이 추가할수록 압축률은 높아지지만 CPU와 대기 시간이 높아집니다.

I 프레임 의 사용은 이상적으로 세그먼트의 시작(패스스루를 사용하는 경우 중요) 또는 장면 변경으로 제한되어야 합니다. 전체 또는 많은 수의 I 프레임은 과도한 부하로 인해 프레임을 건너뛸 수 있으므로 피해야 합니다.

추가 참고 사항:

  • 키 프레임의 조밀한 배치를 방지하는 옵션을 사용하십시오(예: min_keyin = 3+).
  • 키 프레임 삽입의 규칙적인 케이던스를 보장하는 옵션을 사용하십시오. 예를 들어 GOP 길이를 초 단위로 지정하는 대신 정확한 분수 또는 프레임으로 지정합니다.

비트레이트

  • 최소 입력 대역폭: 2.5 메가 비프
  • 최대 입력 대역폭: 10 메가 프스
  • 스트림을 "거의 CBR""로 만드십시오 - max_bitrate = 1.1 * target_bitrate.
  • 가능한 경우 엄격한 HRD 준수 속도 제어 모드를 사용합니다.

プロトコル

인터넷은 보장된 전송 네트워크가 아니며 인터넷 연결이 "양호"한 것으로 간주될 수 있지만 고품질의 안정적인 라이브 비디오 스트리밍에는 충분하지 않을 수 있다는 점에 유의하는 것이 중요합니다. ISP의 약간의 정체, 라우터 간의 계획되지 않은 장애 조치 또는 유사한 문제와 같이 고객 인코더와 Brightcove 트랜스코딩 플랫폼 간의 경로가 약간 중단되면 비디오 출력이 중단될 수 있습니다. 고위험 라이브 방송에서는 관리 네트워크에서 전용 파이버, 예약된 위성 대역폭 또는 커밋된 대역폭으로 구성된 여러 전용 네트워크를 갖는 것이 일반적입니다. 이것은 상당한 비용이 들며 대부분의 경우 인터넷을 통해 충분히 좋은 결과를 얻을 수 있습니다. 그러나 결함 없는 전송을 유지하는 것이 중요한 경우 일정 수준의 전용 대역폭을 제공할 수 있는 AWS Direct Connect 또는 ISP를 고려하십시오.

일반적으로 대역폭 관련 네트워크 문제를 완전히 방지하려면 인코더의 예상 스트림 크기의 두 배에 해당하는 전용 대역폭을 사용하는 것이 좋습니다.

권장하는 옵션은 다음과 같습니다(순서대로).

  1. SRT - 전송 속도(UDP)와 일부 제어 및 오류 복원력의 좋은 조합을 제공합니다. 모든 인코더에서 사용할 수 있는 것은 아니지만 srt-transmit과 같은 로컬 RTP에서 변환할 수 있는 도구가 있습니다.
  2. RTMP - TCP 기반이며 우수한 수준의 오류 복원력을 제공하지만 상당한 오버헤드가 수반된다는 단점이 있습니다. 여러 오디오 트랙과 같은 모든 기능을 RTMP에서 사용할 수 있는 것은 아닙니다.
  3. RTP-FEC - 오류 복원력이 있는 빠른 UDP 기반 전송을 제공합니다.
  4. RTP - 오류 복원력 없이 빠른 전송 및 고급 기능 제공

지원되는 인코더

보다라이브 이벤트에 지원되는 인코더 Live와 함께 작동하는 것으로 알려진 인코더 목록. 다른 인코더도 작동할 수 있지만 테스트되지 않았습니다.

지원되는 CDN

  • Akamai
  • Amazon CloudFront

재시도

인코더에서 RTMP 연결에 대한 재시도를 활성화하는 것이 좋습니다. 5초 재시도 간격으로 재시도 횟수가 많으면 엔코더와 진입점 간의 간헐적인 연결 문제가 완화됩니다.

작업 설정(라이브 API만 해당)

권장 작업 설정

작업 설정
필드 권장 값
ad_audio_loudness_level -23 (EBU R.128 표준)

실시간 스트림 추천 시작

인코더 연결 전에 작업이 활성화되어야 합니다. 또한 인코더에서 스트림을 시작한 후 작업을 활성화하는 것은 지원되는 절차가 아니며 예기치 않은 동작이 발생할 수 있습니다.

슬레이트 소스 파일 권장 사항

  • 해결 : (인코딩 래더에서 최고)
  • FPS : (귀하의 출처와 동일)
  • 비트 레이트 : (인코딩 래더 이상에서 최고)
  • 오디오 : (최고의 표현과 동일한 비트 전송률, 채널, 샘플링 주파수 및 샘플 당 비트 또는 입력과 동일)

출력 권장 사항

다음은 권장 출력 설정이지만 대부분의 인코더에서는 RTMP 입력이 10MBPS (비디오+오디오) 로 제한되고 프레임 수는 30fps로 제한됩니다.

출력 권장 사항
아이템 권장 사항
비디오 코덱 h264현재 유일한 옵션입니다
오디오 코덱 aac현재 유일한 옵션입니다
너비 width또는height이 (가) 제공되지 않으면 소스 차원이 사용됩니다. width또는height이 제공된 경우 소스의 종횡비를 유지하기 위해 다른 치수가 계산됩니다.
높이 width또는height이 (가) 제공되지 않으면 소스 차원이 사용됩니다. width또는height이 제공된 경우 소스의 종횡비를 유지하기 위해 다른 치수가 계산됩니다.
비트레이트 입력 비트 전송률보다 작거나 같음(최상의 결과를 위해 최고 출력 비트 전송률은 입력 비트 전송률의 절반이어야 함)
키프레임 속도 2 초

자주하는 질문

라이브 작업을 만든 후 스트리밍을 얼마나 빨리 시작해야합니까? Brightcove Live에는 상태가 다음에서 전환 될 때 두 가지 조건이 있습니다. waiting ...에finishing :
  1. 직업이기다리는상태 (아직 시작되지 않음) 및max_waiting_time_ms경과하면 작업이 완료 / 비활성화됩니다.
  2. 직업이연결 해제상태 (시작되었지만 연결 해제 됨) 및reconnect_time경과하면 작업이 완료 / 비활성화됩니다.

만약event_length 30 분 이상이면 작업이 30 분 후에 종료됩니다. 만약event_length 30 분 미만이면 작업이 종료됩니다. event_length .

예를 들어event_length 60 분이면 라이브 작업이 30 분 후에 종료됩니다. 만약event_length 15 분이면 라이브 작업이 15 분 안에 종료됩니다.

그만큼reconnect_time 대기 상태에는 영향을주지 않습니다.

동시 라이브 작업 설정의 제한 사항은 무엇입니까?

최대 5개의 활성대기, 시작되지 않은작업은 언제든지 허용됩니다.

동시 작업에 대한 추가 제한 사항:

  • channel ( 24x7) 작업의 수는 0 또는 지역당 낮은 수 (계정 유형에 따라 다름) 로 제한됩니다.
  • 동시 수달리는event일자리는 지역별로 일반적으로 100 명으로 제한됩니다.
  • 동시접속 대기중인event작업의 수는 5개로 제한됩니다.
  • 리 전당 SEP 작업 수는 3 개 또는 10 개로 제한됩니다 ( 지원되는 AWS 지역 ).

이러한 제한은 지원 부서에서 계정 수준에서 조정할 수 있습니다. 추가 용량이 필요한 경우 고객 성공 관리자에게 문의하십시오.

입력 대역폭이 충분하다면 브라이트코브 라이브 푸시 1080p 품질을 보장할 수 있습니까? 예, 모든 계정에 대해 1080p 입력이 활성화됩니다.
DRM을 사용할 수 있습니까? 예! 라이브 계정에 DRM 지원을 추가하는 데 관심이 있는 경우 고객 성공 관리자에게 문의하십시오.

추가 도움말

라이브 이벤트를 진행하는 데 추가 도움이 필요한 경우당사에 문의하실수 있습니다. 최대한 빠른 답변을 받을 수 있도록 브라이트코브 지원에서 문제를 해결하기 위해 필요한 사항의 목록을 아래에 제시했습니다.

  • 스트리밍에서 발생하는 특정 증상 예: 전혀 재생이 되지 않는다거나 잠깐씩 멈추거나 정지되는 증상
  • 과거 이 스트리밍이 올바르게 동작했는지 여부
  • 인코더에서 사용하는 진입점 URL
  • 사용 중인 인코딩 소프트웨어 및 하드웨어
  • 생중계를 게시한 플레이어에 연결된 URL
  • 라이브 자산의 비디오 ID
  • 인코더에서 게시 지점 호스트로 경로를 추적한 결과