STAREC 2 도움말

목차

접근 권한

신규 유입을 돕기 위해 접근 요건을 낮게 유지했으나, 자료를 한 번 공유하고 권한만 얻은 뒤 사라지는 경우가 빈번하여 부득이하게 요건을 약간 상향 조정했습니다. 여전히 활동을 장려하기 위해 관대한 기준을 적용하고 있습니다. 공정성을 위해 체크리스트를 엄격히 따를 예정이니, 기준을 충족하지 못하신다면 무작정 신청하기보다 활동을 늘려주시기 바랍니다.

다음 중 하나를 반드시 충족해야 합니다:

  1. 최근 3개월 내 최소 3회 자료 공유
  2. 저와 교환 이력이 있음 (ㅊㄷ/ㅁㅈㅌ)
  3. 유틸러

접근 권한은 아래에서 신청할 수 있습니다:

7ZHJpdmUuZ29vZ2xlLmNvbS9kcml2ZS9mb2xkZXJzLzFWMjNQOVRsTktTUS12MUs0Vnl5UmIwVUVLbU1UT1NTQQ

메인 게시물에 본인이 충족하는 기준을 포함하여 댓글을 남겨주세요. 기준 명시가 없으면 요청은 무시됩니다.
예시:

xyz로 요청드려요 (1)

모든 피드백이나 제안은 언제나 환영합니다.


질문하기 전에 이 도움말 전체를 정독해 주세요. 작성하는 데 많은 시간을 들였으며, 대부분의 궁금증에 대한 답변이 포함되어 있습니다.

문제가 발생하면 웹 UI 일반 설정 > 로깅 > 로그 다운로드에서 로그를 받아 함께 올려주세요. 로그가 없으면 원인을 파악할 수 없어 서로의 시간만 낭비하게 됩니다.

설치 및 설정

이 섹션에서는 스타렉2 설치 및 설정 과정을 안내합니다.

요구 사항

스타렉2은 많은 파이썬 프로그램처럼 설치 과정이 간단합니다.

외부 도구

특정 외부 도구는 별도로 다운로드하여 설치해야 합니다:

  • 필수: ffmpeg - 비디오와 오디오 먹싱 및 스냅샷에 사용됩니다.
  • 선택 사항 (유튜브 녹화 시):
    • 권장: yt-dlp SABR branch - SABR 포맷(고화질/타임머신) 접근을 위해 권장됩니다.
    • 필수: deno - 서명 문제를 해결하기 위해 필요합니다.
    • 필수: PO token provider - 유튜브의 차단을 피하기 위해 필요할 수 있습니다.
  • 선택 사항: mtn - 빠른 스냅샷 생성에 필요합니다.
    • Windows: 안타깝게도 공식 Windows 릴리스에는 매우 중요한 수정 사항이 포함되어 있지 않으므로 아티팩트 페이지에서 직접 다운로드해야 합니다.
    • Linux: 배포판에 따라 이 지침에 따라 설치하세요. GCP/Oracle의 경우 다음이 작동합니다:
      echo 'deb http://download.opensuse.org/repositories/home:/movie_thumbnailer/Debian_12/ /' | sudo tee /etc/apt/sources.list.d/home:movie_thumbnailer.list
      curl -fsSL https://download.opensuse.org/repositories/home:movie_thumbnailer/Debian_12/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home_movie_thumbnailer.gpg > /dev/null
      sudo apt update
      sudo apt install mtn

이러한 도구들을 다운로드/설치한 후에는 스타렉2이 해당 도구들을 찾을 수 있도록 시스템의 PATH 환경 변수에 추가해야 합니다. PATH의 변경 사항은 변수를 추가한 후에 새로 여는 셸에서만 사용 가능하다는 점을 기억하세요. 리눅스의 경우, `apt-get`을 통해 설치하지 않았다면 `/usr/bin`에 추가하는 방법도 있습니다.

파이썬

시스템에 파이썬이 설치되어 있어야 합니다. 버전 3.11 이상을 권장하며, 이전 버전은 작동을 보장하지 않습니다.

의존성에 대한 참고 사항: 이 버전의 스타렉2에 필요한 일부 파이썬 의존성은 이전 버전의 스타렉과 충돌할 수 있습니다. 이러한 의존성을 업그레이드하면 이전 스타렉 설치가 작동을 멈출 수 있습니다. 새 버전과 이전 버전을 함께 사용하려면 파이썬 가상 환경을 설정하는 것을 강력히 권장합니다.

가상 환경 설정하기

가상 환경은 프로젝트 간 충돌을 방지하며 자체적인 의존성 집합을 가진 격리된 작업 공간을 제공합니다. 만드는 방법은 간단합니다:

  1. 터미널에서 스타렉2 디렉터리로 이동합니다.
  2. 가상 환경을 만듭니다 (예: myenv라는 이름으로):
    python -m venv myenv
  3. 가상 환경을 활성화합니다:
    • Windows (명령 프롬프트/PowerShell):
      myenv\Scripts\activate
    • Linux/macOS (bash/zsh):
      source myenv/bin/activate

활성화되면 현재 셸 세션의 모든 파이썬 명령이 이 환경을 사용합니다. 새 셸을 열거나 새 터미널 세션을 시작하면 환경을 다시 활성화해야 합니다.

파이썬 (그리고 선택적으로 가상 환경)이 준비되면 PIP를 사용하여 필요한 파이썬 패키지를 설치합니다:

pip install --upgrade -r requirements.txt

참고: streamlinkrequirements.txt에 의존성으로 명시되어 있지 않습니다. 특정 패치가 적용된 맞춤형 버전의 streamlink가 이미 이 릴리스에 포함되어 있기 때문입니다. 스타렉2은 시스템 전체에 설치된 streamlink가 아닌 이 포함된 버전을 사용합니다.

Oracle이나 GCP와 같이 매우 기본적인 시스템 환경이라면 일부 기본 그래픽 라이브러리가 누락되었을 수 있습니다. 다음 명령어로 설치할 수 있습니다:

sudo apt-get install libgl1

또한 시스템에 한글 폰트가 누락되었을 수 있습니다. 스냅샷 기능을 사용할 계획이라면, 적절한 폰트와 fontconfig가 설치 및 설정되었는지 확인하는 것이 좋습니다:

sudo apt-get install fontconfig fonts-noto-cjk fonts-nanum fonts-liberation
sudo fc-cache -f -v

기존 데이터베이스 마이그레이션

기존 스타렉/달타렉 데이터베이스를 스타렉2에서 사용하도록 쉽게 마이그레이션할 수 있습니다.

이를 위해, starec2/database/ 폴더로 이동하여 다음 명령어를 실행하면 됩니다:

python migrate.py "C:/path/to/your/old/master.db"

이 명령어는 starec2/database 폴더에 새로운 스키마 형식의 master.db 파일을 생성합니다.

스타렉2 시작하기

스타렉2을 시작하려면 다음을 실행합니다:

python main.py

이 명령은 마스터와 슬레이브 구성 요소를 함께 시작하며, 대부분의 사용자에게 권장되는 설정입니다.

시작 시 스타렉2은 웹 UI URL을 표시합니다. 브라우저에서 이 URL을 사용하여 녹화 및 기타 설정을 관리합니다.

중요: 파이썬은 멀티스레딩에 제한이 있어, 컴퓨터에 리소스가 충분하더라도 슬레이브 하나는 동시 녹화 약 30-40개에서 포화 상태가 됩니다. 이 문제가 발생한다고 생각되면 스타렉2 시작 시 --num-slaves N 인수를 사용하여 여러 슬레이브를 자동으로 생성하십시오.

고급 마스터 및 슬레이브 설정

마스터 및/또는 슬레이브를 특정 주소와 포트를 사용하여 다른 머신에서 실행할 수 있습니다. 다음 인수가 지원됩니다:

  • --mode [combined|master|slave]: 작동 모드를 설정합니다. combined(기본값)는 마스터와 슬레이브를 동일한 머신에서 실행합니다. master는 마스터 구성 요소만 실행하고, slave는 슬레이브 구성 요소만 실행합니다.
  • --master-port <port>: 마스터 프로세스의 리스닝 포트를 재정의합니다. mastercombined 모드에 적용됩니다.
  • --master-address <address>: 슬레이브가 연결해야 할 마스터의 주소를 재정의합니다 (예: http://192.168.1.100). 이는 마스터와 다른 머신에서 실행되는 slave 모드에서만 적용됩니다.
  • --num-slaves <number>: 실행할 슬레이브 프로세스의 수를 지정합니다. 이는 combined 모드에서만 적용됩니다.
  • --slave-name <name>: 슬레이브 인스턴스의 기본 이름을 설정합니다. slave 모드에서는 고유 인스턴스 이름으로 사용됩니다. combined 모드에서는 생성된 이름의 접두사로 사용됩니다 (예: my-worker-0, my-worker-1).
  • --slave-port <port>: 단일 슬레이브 프로세스의 리스닝 포트를 재정의합니다. combined 모드는 동적 포트 할당을 사용하므로 이는 slave 모드에서만 적용됩니다.

config_values.yaml 파일의 base 섹션에서 수동으로 설정할 수도 있습니다. 스타렉2를 처음 실행하는 경우, 기본값으로 config_values.yaml이 생성되도록 한 번 이상 실행해야 합니다.

설정은 다음과 같이 매핑됩니다:

  • master_port: --master-port
  • master_address: --master-address
  • num_slaves: --num-slaves
  • slave_name: --slave-name
  • slave_port: --slave-port

설정

설정은 주로 웹 UI를 통해 관리됩니다. UI에서 변경된 사항은 스타렉2을 다시 시작할 필요 없이 실시간으로 적용됩니다. 또한 특정 플랫폼에 대해 재로드 버튼을 누르면 해당 플랫폼의 체커 코드가 다시 로드되어, 전체 재시작 없이 체커를 업데이트할 수 있습니다.

기본 설정은 대부분의 사용자에게 적합합니다. 많은 옵션은 웹 UI에서 마우스를 올리면 나타나는 툴팁과 함께 직관적으로 이해할 수 있습니다. 다음은 선택된 설정에 대한 자세한 설명입니다:

일반 설정

  • UI
    • 웹 UI의 모양을 사용자 정의하는 설정입니다. 거의 모든 설정이 이름만으로도 어떤 기능인지 쉽게 알 수 있습니다.
      • 썸네일 표시: 실녹 페이지에 라이브 스트림의 썸네일을 표시할지 여부입니다.
  • 녹화 제어
    • 전역 제한 / 전역 버스트: 이 설정들은 특히 스타렉이 처음 시작될 때 너무 많은 녹화가 동시에 시작되는 것을 방지하는 안전장치 역할을 합니다. 기본값은 버스트 3개 녹화와 복구율 0.1입니다 (초기 버스트를 모두 사용한 후 10초마다 새 녹화 하나를 시작할 수 있습니다).
    • 개별 제한 / 개별 제한 버스트: 전역 제한과 유사하지만, 동일한 방송의 재시도에 적용됩니다. 이는 특정 방송에서 오류가 발생할 경우 녹화가 반복적으로 다시 시작되는 것을 방지하는 데 도움이 됩니다.
    • 중복 녹화 방지: 최근에 녹화된 스트림을 다시 녹화하기 전까지 대기하는 시간입니다. 주된 목적은 플랫폼 API가 약간 늦게 응답하여 방송이 종료되었음에도 불구하고 여전히 라이브 상태로 보고될 때 중복 스트림을 다시 녹화하는 것을 피하기 위함입니다. 이는 타임머신 기능이 있는 플랫폼에서 특히 중요합니다.
    • 녹화 용량 제한: 녹화 파일의 최대 허용 크기입니다. 이 크기에 도달하면 녹화가 자동으로 중단됩니다. 0으로 설정하면 제한이 없습니다(기본값).
      주의: 타임머신 기능을 사용할 때 이 옵션을 설정하면, 녹화가 중단된 후 재시작되면서 과거 데이터를 반복적으로 다운로드하여 드라이브를 빠르게 가득 채울 수 있으므로 매우 주의해야 합니다.
    • 방제 필터: 방송을 필터링하는 데 사용되는 키워드로, 한 줄에 하나씩 입력합니다. 필터는 감지 시점에 적용됩니다. 예를 들어 다시보기를 추가하면, 스트리머가 제목에 다시보기를 포함한 라이브를 시작할 경우 무시됩니다. 만약 스트리머가 제목을 다른 것으로 변경하면 재방송을 하지 않더라도 녹화가 시작됩니다. 하지만 방송을 종료하지 않은 상태에서 제목을 다시 다시보기로 변경해도 녹화는 중단되지 않습니다.
    • 영상 썸네일 추출: 플랫폼에서 제공하는 API 썸네일 대신, 현재 녹화 중인 비디오 파일에서 직접 이미지를 추출하여 웹 UI에 표시합니다.
      • 용도: 숲(19금/비번방/구독), 알플레이, 띵라이브 등 플랫폼 API가 실제 방송 화면 대신 로고나 잠금 화면만 제공하는 경우 유용합니다. 유튜브, 트위치, 인스타그램, 틱톡 등에서도 더 정확한 최신 화면을 볼 수 있습니다.
      • 주의: 녹화 중인 파일을 읽어야 하므로 ffmpeg가 필요하며, 파일 탐색이 발생합니다. rclone 마운트를 사용하는 경우, rclone 캐시 설정이 올바르지 않으면 작동하지 않습니다.
  • 파일 설정
    • 출력 폴더: 녹화된 파일이 저장될 위치를 지정합니다. 이는 config_values.yamlslave_output 설정에 해당합니다. 단일 디렉터리를 제공하거나 슬레이브가 순환하며 사용할 여러 디렉터리를 각 줄에 하나씩 제공할 수 있습니다.
      여러 디렉터리를 사용하면 디스크 부하를 분산시키거나, 하위 폴더별로 다른 구드 (Google Drive) 계정으로 rclone을 설정하여 일일 업로드 할당량을 우회하는 데 유용할 수 있습니다.
    • 날짜 형식: strftime 형식 코드를 따릅니다.
    • 시간대: 파일명에 사용할 시간대를 지정합니다. 한국 시간으로 강제하는 데 유용합니다. local은 머신의 시간을 사용합니다. TZ 식별자를 허용합니다.
    • 파일명: 다음 플레이스홀더를 사용할 수 있습니다: _date_, _id_, _stream_id_, _display_, _platform_, _title_, _quality_.
    • 파일명 최대 길이: 파일명의 최대 길이를 지정합니다(초과 시 제목이 잘림). 0으로 설정하면 제한이 없습니다. 대부분의 운영체제와 파일 시스템은 255바이트 이상의 파일명을 허용하지 않으며, 확장자와 기타 접미사를 위한 여유 공간이 필요하므로 기본값은 220입니다.
    • 접근 태그 포함: 방송의 접근 수준(예: 비번방, 구독)을 파일명에 포함할지 여부를 결정합니다. 공개 방송이 아닌 특별한 접근 태그만 포함됩니다.
    • 최종 파일명 패턴: 녹화 완료 후 최종 파일명을 이 패턴으로 변경합니다. 예를 들어, 특정 문자열을 감지하여 파일을 업로드하는 스크립트가 있을 경우 유용합니다. rclone 사용 시에는 권장하지 않습니다.
    • 화질 변경 반영: 녹화 시작 시점에는 화질 정보를 알 수 없어 파일명에 'unknown' 등으로 표시될 수 있습니다. 이 옵션을 활성화하면 녹화 도중 정확한 화질이 감지되었을 때, 녹화가 끝나면 파일명을 자동으로 수정합니다. rclone 사용 시에는 권장하지 않습니다.
    • 영상 확장자: 실시간 먹싱 섹션을 참조하십시오.
  • 알림
    • 녹화 ID 형식: 알림 메시지에서 녹화 ID에 사용할 형식입니다. 파일명과 유사합니다.
    • 녹화 완료 형식: 녹화가 완료되었을 때 정보에 사용할 형식입니다. 유튜브는 손실 정보를 제공하지 않습니다.
    • 녹화 수 경고 한도: 경고를 보낼 녹화 수입니다. 이는 강제적인 제한이 아니며, 웹 UI에 경고가 표시되고 알림이 전송되지만 스타렉2은 모든 녹화를 계속 시도합니다.
    • 디스크 공간 알림: 경고를 보낼 디스크 사용량(%)입니다. 이전과 마찬가지로 경고일 뿐 강제적인 조치는 없습니다.
      • rclone 참고: Google Drive Workspace 폴더와 함께 rclone을 사용하는 경우, rclone이 특정 계정의 사용 가능한 공간 대신 전체 워크스페이스의 사용량을 보고하는 경우가 많습니다. 이는 잘못된 경고를 유발할 수 있습니다. 이 문제가 발생하면 이 옵션을 비활성화(0으로 설정)하는 것이 좋습니다.
    • 텔레그램 토큰: 텔레그램 봇 API 토큰으로, 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11과 같은 형식입니다. 봇을 생성할 때 얻을 수 있습니다.
    • 텔레그램 ID: 메시지를 보낼 텔레그램 채팅 ID입니다. 봇과 최근에 나눈 채팅이 있다면 https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates로 이동하여 얻을 수 있습니다.
    • 디스코드 웹훅: 메시지를 보낼 웹훅입니다.
  • 로깅
    • 로깅 수준: 디버그 모드를 권장합니다. 자동 로그 순환 기능이 있어 로그가 너무 커지는 것을 걱정할 필요가 없으며, 문제가 발생했을 때 문제 해결을 위해 공유할 로그를 항상 확보할 수 있습니다.
    • 녹화기 로깅 수준 / asyncio 디버깅: 별도의 요청이 없는 한 이 옵션을 변경하지 마십시오! 디버그 모드는 매우 상세하므로, streamlink나 asyncio 관련 문제를 디버깅하는 경우가 아니라면 활성화할 필요가 없습니다.
    • 메모리 덤프 포함: 무엇을 하는지 모른다면 이 옵션을 변경하지 마십시오! 성능 저하가 예상됩니다.
    • 로그 유지: 녹화기 로그losscheck 정보를 포함합니다. ffmpeg 로그는 ffmpeg 관련 문제를 디버깅하는 경우에만 필요합니다.
    • 최대 파일 크기 / 교체된 파일 개수: 로그 파일이 새 파일로 교체되기 전까지 허용되는 최대 크기와 보관할 교체 파일의 수를 설정합니다. 한도에 도달하면 가장 오래된 로그 파일이 자동으로 삭제됩니다.

플랫폼 설정

플랫폼별 설정은 많은 일반 설정을 덮어쓸 수 있어 플랫폼별로 맞춤형 동작을 허용합니다 (예: 치지직 ID는 매우 길 수 있으므로 치지직 파일명에서 ID를 제외하도록 설정할 수 있음). 이 섹션에서는 플랫폼 고유의 구성에 중점을 둡니다.

  • 활성화 (모든 플랫폼에 적용):

    플랫폼 활성화 여부를 결정합니다. 스타렉2은 녹화 목록에 해당 플랫폼의 활성 대상이 없으면 자동으로 해당 플랫폼을 시작하지 않으므로, 테스트 목적이 아니라면 일반적으로 플랫폼을 비활성화할 이유가 없습니다.

  • 확인 주기 (모든 플랫폼에 적용):

    각 대상의 라이브 상태 확인 사이의 대기 시간입니다. 기본값을 유지하는 것이 좋습니다.

    • 숫자가 낮을수록 대상을 더 자주 확인하지만, 요청 수가 늘어납니다.
    • 숫자가 너무 낮으면 비생산적입니다. 스트림은 항상 최소 10초(대부분 20초)의 과거 콘텐츠를 포함하므로 10초 미만으로 설정하는 것은 일반적으로 리소스 낭비입니다.
    • 타임머신이 있는 플랫폼의 경우, 이 값을 더 높게 설정해도 단점이 없습니다 (단, 예를 들어 60초로 설정하면 운이 나쁘면 60초 미만으로 지속된 방송을 놓칠 수 있음).
    • 팔로잉 / 멀티가져오기가 활성화된 경우, 이는 각 멀티가져오기 확인 사이의 대기 시간입니다.
  • 팔로잉 / 멀티가져오기 (여러 플랫폼에 적용)

    더 적은 요청으로 여러 대상의 실시간 상태를 가져오기 위해 플랫폼의 "팔로잉" 또는 "멀티가져오기" API를 사용할지 여부를 결정합니다. 특정 플랫폼에서 많은 대상을 모니터링하는 경우 API 호출 수를 크게 줄여주므로 강력히 권장됩니다.

    • 이 설정은 실시간 상태를 가져오는 방식만 변경합니다. 여전히 스타렉2 목록에 대상을 추가해야 합니다.
    • 팔로잉: 해당 플랫폼에 대한 쿠키 또는 자격 증명을 설정해야 하며, 계정의 구독/팔로우 목록을 사용합니다. 즉, 계정으로 팔로우하지 않은 대상은 스타렉2 목록에 있더라도 감지되지 않습니다.
    • 멀티가져오기: 플랫폼의 모든 현재 라이브 방송을 가져옵니다. 특별히 수동으로 조정해야 할 이유가 없다면 auto로 두는 것을 권장합니다.
  • 타임머신 (여러 플랫폼에 적용):

    일부 플랫폼은 상당한 양의 과거 세그먼트를 포함하는 스트림을 반환합니다. 이를 타임머신이라고 합니다.

    • 치지직은 이 기능을 활성화/비활성화하는 설정이 있습니다. 타임머신은 대부분의 제한(예: 저작권, 성인 콘텐츠 확인)을 우회하는 데 도움이 되므로 특정 테스트 목적이 아니라면 비활성화할 이유가 거의 없습니다. 인기 스트림의 경우 1시간, 일부 비인기 스트림의 경우 10분의 과거 콘텐츠를 포함합니다.
    • 유튜브는 항상 스트림 전체를 처음부터 포함합니다.
    • 위버스는 멤버십 전용 라이브 스트림을 제외하고는 항상 스트림 전체를 처음부터 포함합니다.
    • 라이브 스트림이 중간부터 녹화되기 시작하면(예: 새 대상을 추가했기 때문에), 현재 시점을 따라잡을 때까지 일반적으로 매우 높은 대역폭 사용량을 보입니다.
    • 시작 버퍼 (초 단위): 타임머신이 활성화된 경우, 이 값은 녹화를 시작해야 하는 과거 시점(초 단위)을 나타냅니다. 예를 들어, 300은 5분 전부터 녹화를 시작합니다. 0은 사용 가능한 가장 이른 시점부터 시작함을 의미합니다. 매우 낮은 값으로 설정하는 것은 타임머신을 비활성화하는 것과 같습니다.
  • 치지직
    • akamai CDN 사용타임머신 사용 시 치지직은 light-slit와 akamai의 livecloud라는 두 가지 다른 CDN을 사용합니다. light-slit는 일반적으로 인기 있는 스트림에 사용되며 한국 내 전용 CDN으로 보여 해외에서 접속 시 현저히 느립니다. 이 옵션은 m3u8 URL과 CDN 토큰을 재작성하여 대신 livecloud akamai CDN을 사용하도록 합니다. 머신이 해외(특히 미국이나 유럽)에 있다면 이 옵션을 활성화해야 합니다.
    • AID 프록시 주소

      AID 토큰을 가져올 때 사용할 프록시 주소입니다. 새 녹화를 시작할 때 단일 요청에 대해서만 프록시를 사용하며 그 외 모든 통신은 일반 연결을 통해 이루어집니다.

  • 트위치
    • 클라이언트 ID / 비밀

      트위치 개발자 콘솔에서 앱을 생성한 후 획득할 수 있습니다. 트위치 클라이언트는 시작 시에만 인스턴스화되므로 이 필드를 수정한 후에는 재로드 버튼을 클릭해야 합니다.

    • 라이브 VOD 사용

      활성화 시 라이브 VOD 재생 목록을 가져오려고 시도합니다. 이는 일반적으로 "Source" 화질을 제공하며 타임머신 기능을 더 강력하게 지원합니다. 라이브 VOD가 없으면(한국 스트리머의 경우 해당) 일반 m3u8로 대체됩니다.

    • Auth 토큰

      개인 OAuth 토큰입니다. 구독자 전용 방송 접근, 광고 제거(터보 사용 시), 화질 제한 우회(예: 2k+ 화질)에 사용됩니다.

    • Usher 프록시 주소

      Twitch의 "Usher" 서비스 요청에 사용할 프록시 URL 목록입니다. 이를 통해 특정 지역에서 원본 화질 및 광고 없는 스트림을 얻을 수 있습니다. 스트림 데이터 자체는 프록시를 통하지 않고 직접 다운로드됩니다. 목록의 프록시는 순서대로 시도되며, 모두 실패하면 직접 연결이 사용됩니다.

      참고: Usher 프록시가 활성화되면 Auth 토큰은 무시됩니다. 또한, URL을 프록시 주소에 추가하는 방식으로 작동하는 특수한 HTTP(S) 프록시여야 합니다. 작동하는 예시(251219 기준)는 https://proxy4.rte.net.ru입니다.

  • 팬더
    • 시청 불가 딜레이: 스트림이 감지되었지만 녹화를 시작할 수 없는 경우(예: 구독, 하트 등이 필요하지만 계정이 조건을 충족하지 못하는 경우), 해당 스트림은 시청 불가능으로 표시되고 의심스러운 요청을 피하기 위해 한동안 재시도되지 않습니다. 하지만 녹화 실패 알림을 받은 직후 필요한 것을 구매할 계획이라면, 스트림이 한동안 재시도되지 않으므로 이는 바람직하지 않을 수 있습니다. 이런 경우에는 이 값을 줄여야 합니다.
  • 알플레이
    • 멀티 가져오기 API: '멀티 가져오기' 사용 시 진행 중인 방송 목록을 가져오는 데 사용할 API를 선택합니다. livestreams API는 더 오래되었지만 모든 방송을 안정적으로 반환합니다. 하지만 특정 환경(특히 오라클 또는 일부 지역에서 접속 시 429 오류를 반환)에서는 차단될 수 있습니다. curation API는 더 최신이지만 일부 방송(특히 메인 페이지에 노출되지 않는 방송)이 제대로 감지되지 않을 수 있습니다. livestreams API가 작동하지 않는 경우가 아니라면 사용을 권장합니다.
    • 시청 불가 딜레이: 팬더와 정확히 동일합니다, 위 내용을 참조하세요.
    • 구독 갱신 주기: 알플레이는 스트림을 녹화할 수 있도록 구독 정보를 수동으로 가져와야 합니다. 하지만 구독 정보는 자주 변경되지 않으므로 일정 시간이 지난 후에만 다시 가져옵니다. 시청 불가 딜레이와 마찬가지로, 구독을 즉시 구매할 계획이라면 이는 비생산적일 수 있으므로 이 경우 값을 줄여야 합니다.
    • 사용자 ID / 토큰:

      이메일과 비밀번호를 사용할 수 없는 경우(예: Google 계정과 같은 OAuth를 통해 로그인하는 경우)에만 이 방법을 사용해야 합니다.
      올바르게 설정하려면 다음 단계를 따르십시오:

      1. 시크릿 브라우저 창에서 알플레이에 로그인합니다.
      2. 정보 페이지에서 사용자 ID를 찾을 수 있습니다.
      3. 브라우저의 localStorage에서 토큰을 가져옵니다 (Application 탭 -> Local storage -> _AUTHORIZATION_ 값)
      4. 시크릿 창을 닫습니다.
  • 위버스
    • 갱신 토큰: 위버스는 인증 흐름을 시작하기 위해 초기 액세스 토큰이 필요합니다. 이메일과 비밀번호를 사용할 수 없는 경우(예: Google 계정과 같은 OAuth를 통해 로그인하는 경우)에만 이 방법을 사용해야 합니다. 이는 일회성 설정이며, 이후 스타렉2은 필요한 토큰을 tokens/ 폴더에 저장하고 관리합니다.
      올바르게 설정하려면 다음 단계를 따르십시오:
      1. 시크릿 브라우저 창에서 위버스에 로그인합니다.
      2. 브라우저 쿠키에서 액세스 토큰을 가져옵니다 (Application 탭 -> Cookies -> we2_refresh_token 값)
      3. 이 토큰을 스타렉2의 위버스 설정에 있는 갱신 토큰 필드에 붙여넣습니다.
      4. 시크릿 창을 닫습니다.
  • 유튜브
    • 쿠키 파일: yt-dlp/yt-dlp용 쿠키가 포함된 파일 경로입니다. 쿠키 사용을 강력히 권장합니다. 공개 스트림이라도 쿠키를 사용하지 않으면 유튜브에서 차단하거나 사용량을 제한할 수 있습니다. 또한 유튜브는 활성 세션 쿠키를 자주 교체하므로, 합리적인 기간 동안 유효성을 유지하려면 시크릿 브라우저 세션에서 쿠키를 얻는 것이 중요합니다. Get cookies.txt LOCALLY와 같은 확장 프로그램을 사용하여 올바른 형식으로 쿠키를 내보낼 수 있습니다. (시크릿 모드에서 확장 프로그램을 허용해야 할 수 있습니다: 시크릿 모드에서 확장 프로그램 허용 방법).
    • 프로토콜 이해하기 (HLS, DASH, SABR)

      아래 설정을 이해하기 위해 유튜브의 영상 전송 방식을 알 필요가 있습니다:

      • HLS (m3u8): 타임머신(되감기)을 지원하지 않습니다. 광고가 없으며 최대 1080p (H.264)로 제한됩니다. 손실된 세그먼트를 추적할 수 없습니다.
      • DASH: 타임머신을 지원합니다(보통 처음부터 가져옴). 광고가 없으며 최대 1080p (H.264)로 제한됩니다. 손실된 세그먼트를 추적할 수 있습니다.
      • SABR: 타임머신을 지원합니다(라이브 플레이어가 탐색 허용하는 범위까지). 프리미엄이 없으면 광고가 포함될 수 있습니다(일반 라이브에서는 드묾). 유일하게 2K/4K+ 해상도와 최신 코덱(VP9, AV1, HDR)을 지원합니다. 손실된 세그먼트를 추적할 수 있습니다.
    • SABR 우선순위: 스트림 속성에 따라 어떤 프로토콜을 사용할지 결정합니다.
      • 자동 (권장): 스트림이 1080p를 초과하거나 HDR인 경우, 최고의 화질을 위해 SABR을 선택합니다. 그 외의 경우 타임머신 설정 활성화 여부에 따라 HLS 또는 DASH를 선택합니다. (특히 프리미엄 쿠키 사용 시 가장 균형 잡힌 설정입니다.)
      • SABR 후순위: 항상 HLS나 DASH를 선호합니다(타임머신 설정에 따라). 다른 프로토콜을 사용할 수 없을 때만 SABR을 사용합니다. 4K/1440p가 필요 없고, 광고 없는 환경과 타임머신 기능을 보장받고 싶을 때 사용하세요.
      • SABR 우선 (항상): 모든 스트림에 대해 SABR을 강제합니다. 다른 프로토콜에 문제가 생겼을 때만 유용합니다.

      참고: SABR을 지원하는 yt-dlp 브랜치가 설치되어 있지 않다면, 이 설정과 무관하게 HLS와 DASH만 사용됩니다.

    • 코덱 우선순위: 어떤 비디오 코덱을 선호할지 결정합니다 (SABR이 아니면 항상 H.264가 사용됨).
      • 자동 (권장): 비트레이트 등을 고려하여 yt-dlp가 최적의 코덱을 선택합니다.
      • AV1: 비트레이트 대비 효율과 화질이 가장 좋지만, 원활한 재생을 위해 최신 하드웨어가 필요합니다.
      • VP9: 밸런스가 좋으며 지원 기기가 많습니다.
      • AVC (H.264): 구형 기기/편집기와의 호환성이 가장 좋지만, 효율이 낮습니다.

녹화기 엔진

스타렉2의 핵심 녹화 로직은 커스텀 streamlink에서 이루어집니다 (유튜브는 예외로, yt-dlp를 사용합니다).

녹화기 설정은 녹화 엔진의 저수준 동작을 제어합니다:

  • 실시간 먹싱: 스트림의 컨테이너 형식을 다운로드하는 동안 실시간으로 변환(리먹싱)할 수 있게 해줍니다(예: .ts에서 .mkv로). 이는 디스크 공간을 절약하고, 호환성을 개선하며, 녹화 후 별도의 리먹싱 과정을 생략하게 해줍니다. 자세한 설명은 실시간 먹싱 섹션을 참조하십시오. 유튜브의 경우 실시간 먹싱이 불가능합니다.
  • 초기 스트림 대기: 방송이 감지된 후, 실제 비디오 스트림이 CDN에서 사용 가능해지기까지 약간의 시간이 걸릴 수 있습니다. 이 옵션은 녹화 시작 오류를 줄이기 위해, 포기하기 전까지 스트림 가져오기를 재시도하며 대기할 최대 시간(초)을 설정합니다.
  • 스트림 유휴 제한시간: 전체 스트림에 대한 마스터 시간 초과입니다. 이 시간(초) 동안 스트림에서 새로운 데이터가 수신되지 않으면, 연결이 끊어진 것으로 간주하고 녹화를 중지합니다. 이 값은 항상 세그 재시도 시간보다 높아야 합니다.
  • M3U8 재시도: 메인 스트림 재생 목록(M3U8 파일) 가져오기에 실패했을 때의 재시도 횟수입니다.
  • 세그 스레드: 스트림 세그먼트(작은 비디오 조각)를 동시에 다운로드하는 데 사용되는 스레드 수입니다. 하나 이상의 스레드(예: 기본값 4)를 사용하는 것을 강력히 권장합니다. 일반적인 상황에서는 리소스 오버헤드가 거의 없지만 안정성을 크게 향상시킵니다.

    작동 방식: 한 스레드가 문제가 있는 세그먼트를 재시도하느라 멈춰 있는 동안, 다른 스레드들이 후속 세그먼트를 계속 다운로드하여 녹화가 뒤처지는 것을 방지할 수 있습니다.

  • 나머지 설정들은 세그먼트와 관련이 있으며 아래에서 자세히 설명합니다.

세그먼트 재시도 로직 이해하기

참고: 이 로직은 streamlink를 사용하는 HLS 기반 플랫폼에만 적용됩니다. 인스타그램이나 유튜브의 경우 재시도 횟수는 세그 최소 재시도 설정값으로 고정됩니다.

단일 스트림 세그먼트(작은 비디오 조각) 다운로드에 실패했을 때, 다음 네 가지 설정이 함께 작동하여 복구를 시도합니다. 이들의 상호작용을 이해하는 것은 안정적인 녹화 설정을 위한 핵심입니다.

  • 세그 시간 초과: 각 개별 세그먼트 다운로드 시도에 대한 HTTP 요청 시간 초과(초)입니다. 이 시간 내에 서버로부터 응답이 없으면 해당 시도는 실패한 것으로 간주됩니다.
  • 세그 재시도 시간: 실패한 세그먼트의 재다운로드를 시도할 총 시간(초)을 정의합니다. 모든 재시도와 대기 시간을 포함한 총 소요 시간이 이 값을 초과하면 해당 세그먼트를 포기하고 다음으로 넘어갑니다.
  • 세그 재시도 간격: 실패한 단일 세그먼트에 대한 각 재시도 시도 사이의 목표 지연 시간(초)입니다. 실제 대기 시간은 이 값에서 이전 시도에 걸린 시간을 뺀 값이 됩니다.
  • 세그 최소 재시도: 세그 재시도 시간과 관계없이 시도될 최소 재시도 횟수입니다. 이 설정은 시간 제한이 만료되더라도 최소한의 재시도 횟수를 보장합니다.

작동 방식 예시

다음과 같은 설정을 가정해 보겠습니다:

  • 세그 시간 초과: 10초 (각 요청은 최대 10초 대기)
  • 세그 재시도 시간: 45초 (총 45초 이상 소요되면 포기)
  • 세그 재시도 간격: 3초
  • 세그 최소 재시도: 2
  1. 첫 번째 세그먼트 다운로드 시도가 세그 시간 초과에 도달하여 10초 후 실패합니다.
    • 총 경과 시간: 10초.
    • 결정: 세그 최소 재시도(2) 횟수를 충족하지 못했으므로 재시도해야 합니다. 10초의 시도 시간이 3초의 재시도 간격보다 길기 때문에 즉시 재시도합니다.
  2. 두 번째 시도 역시 일시적인 네트워크 문제로 빠르게 실패하며 2초가 소요됩니다.
    • 총 경과 시간: 10초 (1차 시도) + 2초 (2차 시도) = 12초.
    • 결정: 이제 세그 최소 재시도 횟수인 2번을 충족했습니다. 총 경과 시간(12초)이 여전히 45초의 전체 제한 시간보다 적기 때문에 재시도를 계속할 수 있습니다.
    • 동작: 스타렉2은 이제 1초를 기다립니다. 이는 세그 재시도 간격을 준수하기 위함입니다 (3초 간격 - 마지막 시도에 걸린 2초 = 1초 대기).
  3. 1초 대기 후 세 번째 시도를 시작합니다. 이번에는 연결이 안정되어 세그먼트가 1초 만에 성공적으로 다운로드됩니다.
    • 총 경과 시간: 12초 (이전 시도들) + 1초 (대기) + 1초 (마지막 시도) = 14초.
    • 결과: 세그먼트를 성공적으로 가져왔습니다. 녹화기는 이 세그먼트와 다른 스레드에서 이미 다운로드한 모든 후속 세그먼트를 파일에 기록하여 즉시 라이브 스트림을 따라잡습니다.

기타 녹화기 설정

  • 세그 큐 임계값: 숲과 같이 재생 목록에 명확한 "스트림 종료" 신호를 제공하지 않는 플랫폼을 위한 것입니다. 이 시간 동안 재생 목록에서 새로운 세그먼트를 보지 못하면 녹화가 중지됩니다.

    예시: 세그먼트 길이가 2초이고 이 값이 15(기본값)로 설정된 경우, 약 30초 동안 새로운 세그먼트가 없으면 녹화가 중지됩니다.

직접 녹화 요청 API 엔드포인트

스타렉2는 외부 소스에서 마스터로 직접 녹화 요청을 보내는 기능을 지원합니다.

이 기능은 별도의 도구로 방송을 감지하지만 실제 녹화는 스타렉2를 통해 처리하고 싶을 때 유용합니다. 이렇게 시작된 녹화도 웹 UI에 정상적으로 표시됩니다.

엔드포인트는 api/external_record이며 JSON 형식의 RecordInfo 데이터를 기대합니다. cp_token은 쿼리 파라미터로 전달하거나 JSON 본문의 필드로 포함해야 합니다.

예를 들어 http://{master_address}:{master_port}/api/external_record 주소로 다음과 같은 페이로드와 함께 POST 요청을 보낼 수 있습니다:

{
  "platform": "instagram",
  "streamer_id": "account_of_streamer",
  "display_name": "nickname_of_streamer",
  "m3u8_url": "https://address_to_the_m3u8",
  "title": "broadcast title example",
  "broad_start_time": 1766156956,
  "cp_token": "my_cp_token"
}

필요한 필드를 자유롭게 포함할 수 있습니다. 자세한 필드 정의는 starec2/common/record_info.py 파일의 RecordInfo 클래스를 참조하십시오.

참고: m3u8_url 필드는 플랫폼에 따라 용도가 다를 수 있습니다. 예를 들어 인스타그램의 경우 m3u8 대신 MPD URL이 들어갑니다. 정확한 사용법은 해당 플랫폼의 소스 코드를 확인하십시오.

스냅샷

스냅샷은 녹화가 중지될 때마다(정상적으로 종료되거나 중단/건너뛴 경우) 생성됩니다.

스냅샷은 비디오 파일의 타이밍 및 길이 메타데이터에 의존하므로 특정 상황에서는 작동하지 않을 수 있습니다. 가장 대표적인 사례는 치지직으로, 세그먼트가 실제 스트림 시작 시점을 기준으로 한 타이밍 메타데이터와 함께 전송됩니다. 따라서 스트림 중간부터 녹화를 시작하면 결과 비디오의 시작 부분에 빈 공백이 생길 수 있습니다. 이 문제는 실시간 먹싱을 활성화하여 해결할 수 있습니다. 실시간 먹싱은 파일의 모든 타이밍 메타데이터를 수정합니다(몇 가지 주의사항이 있으며, 특히 rclone 사용 시에는 실시간 먹싱 섹션을 참고하십시오).

스냅샷은 최종 영상 파일을 읽어야 하므로 rclone 사용 시 실시간 먹싱에서 발생하는 것과 동일한 문제가 발생한다는 점에 유의하십시오. rclone을 사용하신다면 관련 섹션을 참고하시기 바랍니다.

스타렉2은 스냅샷 생성을 위해 두 가지 방법을 지원합니다:

  • MTN: 이 방법을 사용하려면 mtn이 필요합니다.
    • 가능한 경우 키프레임을 통해 탐색하므로 매우 효율적입니다 (실시간 먹싱을 활성화하면 거의 항상 키프레임을 사용합니다).
    • 엣지 감지를 사용하여 좋은 스냅샷을 선택합니다.
    • 단점으로는 다른 글꼴로 대체하는 기능이 없어 일부 이모티콘이 파일 제목 메타데이터에 제대로 렌더링되지 않을 수 있습니다.
  • Pictex: 스타렉이 ffmpegpictex를 사용하여 스냅샷을 단계별로 수동으로 생성합니다.
    • 키프레임을 통해 탐색할 수 없으며, 특정 타임스탬프를 선택하여 해당 지점의 이미지를 디코딩합니다. 이는 비디오를 디코딩하는 과정이므로 예상보다 많은 리소스(CPU 및 메모리)를 사용합니다.
    • 이 라이브러리는 아직 안정적이지 않으며, 호환성이 깨지는 변경 사항을 자주 도입합니다 (예: 두 달 동안 공개 API를 두 번 변경했으며 일부 Windows 환경에서는 제대로 작동하지 않는 경우가 있습니다).
    • 텍스트가 더 보기 좋고 모든 문자/이모티콘이 올바르게 렌더링됩니다.

스냅샷 메타데이터의 이모티콘을 정말로 중요하게 생각하지 않는 한 mtn을 사용하는 것이 좋습니다. 비교하자면, 매우 약한 CPU에서 5x5 스냅샷은 mtn으로 100ms 미만이 걸리지만 pictex으로는 30초 이상 걸립니다.

대부분의 설정 옵션은 직관적입니다. 유일하게 특별한 것은 종료 시 대기로, 슬레이브를 중지할 때(예: CTRL+C를 누를 때) 수행할 작업을 나타냅니다. 활성화하면, 슬레이브는 종료 시점에 진행 중인 모든 녹화에 대한 스냅샷을 생성합니다.

비디오 스트리밍, 컨테이너 및 리먹싱

최대한 많은 분들이 이해하실 수 있도록 일부 내용은 의도적으로 단순화하거나 생략했습니다.

1. 전송 프로토콜 (HLS & DASH)

동영상 콘텐츠는 HTTP 기반 스트리밍 프로토콜을 통해 웹으로 전송됩니다. 서버에서 클라이언트로 데이터가 어떻게 조각나서 전달되는지는 구체적인 프로토콜에 따라 결정됩니다.

작동 메커니즘

스트리밍 프로토콜은 하나의 긴 파일을 통째로 보내지 않고 '플레이리스트' 방식을 사용합니다:

  1. 매니페스트 (플레이리스트): 클라이언트는 텍스트 파일(HLS는 .m3u8, DASH는 .mpd)을 먼저 다운로드합니다. 이 매니페스트에는 화질 정보(Variant Streams)와 현재 볼 수 있는 비디오 조각들의 목록이 들어있습니다.
  2. 세그먼트: 실제 영상 데이터는 보통 2~6초 길이의 작은 파일(세그먼트/프래그먼트)로 나뉘어 있습니다.
  3. 연속 재생: 클라이언트는 이 조각들을 순서대로 다운로드하고 이어 붙여 끊김 없이 재생합니다.

주요 프로토콜

  • HLS (HTTP Live Streaming): 전통적으로 MPEG-TS 세그먼트를 사용했으나 최근에는 Fragmented MP4 (fMP4)를 사용하는 추세입니다.
  • MPEG-DASH: 태생적으로 fMP4 세그먼트를 사용합니다.

이 개별 조각(TS vs fMP4)의 형식이 들어오는 스트림의 "본래" 컨테이너를 결정합니다.

2. 동영상 컨테이너 포맷

동영상 파일은 엘리멘터리 스트림(H.264/AVC 같은 인코딩된 영상 데이터와 AAC 같은 오디오 데이터)이 컨테이너 안에 담긴 형태입니다. 컨테이너는 데이터의 정렬, 인덱싱, 동기화 방식을 정의합니다.

녹화 과정에서 중요한 컨테이너들은 다음과 같습니다:

A. MPEG-TS (MPEG Transport Stream)

전통적인 방송 송출과 구형 HLS의 표준입니다.

  • 내부 구조: 데이터를 작고 고정된 크기(188바이트)의 패킷으로 나눕니다. 중앙 헤더가 없고 패킷 내의 싱크 바이트와 연속성 카운터로 동기화를 맞춥니다.
  • 장점:
    • 오류 복구: 전송 중 손실을 가정하고 만들어졌습니다. 신호가 끊겨 패킷이 유실돼도 다음 패킷부터 바로 유효한 재생이 가능합니다.
    • 저지연: 헤더를 기다릴 필요 없이 패킷을 받는 즉시 디코딩할 수 있습니다.
  • 단점:
    • 전체 인덱스 부재: "목차"가 없습니다. 탐색을 하려면 플레이어가 무작위 위치의 타임스탬프를 읽어가며 찾아야 해서 탐색이 느리고 부정확합니다.
    • 높은 오버헤드: 188바이트마다 헤더가 붙어서 실제 미디어 내용 대비 파일 용량이 커집니다.

B. Fragmented MP4 (fMP4)

웹 스트리밍의 최신 표준입니다.

  • 내부 구조: MP4 형식을 변형한 것입니다. 하나의 전체 인덱스 대신 짧고 독립적인 조각들의 연속으로 이루어져 있습니다. 각 조각은 moof 아톰(해당 조각의 메타데이터/인덱스)과 mdat 아톰(미디어 데이터)으로 구성됩니다.
  • 장점: 가변 비트레이트 전환과 HTTP 전송에 효율적이며, MPEG-TS보다 패키징 오버헤드가 적습니다.
  • 단점: TS와 마찬가지로 원본 fMP4 파일은 전체 녹화본에 대한 통합 인덱스가 없어서 로컬 플레이어에서 탐색 성능이 좋지 않습니다.

C. Matroska (.mkv)

범용성과 보관을 위해 설계된 포맷입니다.

  • 내부 구조: EBML을 사용합니다. 데이터는 주로 비디오 키프레임에 맞춰 Cluster 단위로 정리됩니다. 타임스탬프와 파일 위치를 매핑한 Cues 요소(인덱스)를 기록합니다.
  • 장점:
    • 뛰어난 탐색 성능: Cues 요소 덕분에 플레이어가 특정 시간으로 즉시 이동할 수 있습니다.
    • 손상 방지: 구조적으로 오류에 강합니다. 녹화 중 튕기거나 전원이 나가도 끊긴 시점까지의 파일은 정상적으로 재생됩니다.
    • 범용성: 거의 모든 비디오/오디오 코덱과 임의의 메타데이터를 지원합니다.
  • 단점: 아주 오래된 소프트웨어에서는 지원하지 않을 수 있습니다.

D. Standard MP4 (.mp4)

완성된 정적 동영상 파일의 표준입니다.

  • 내부 구조: 하나의 거대한 moov 아톰에 의존합니다. 이 안에 영상의 모든 프레임에 대한 인덱스 정보가 들어있습니다.
  • 장점: 모든 기기와 소프트웨어에서 지원합니다.
  • 단점 (치명적): moov 아톰을 만들려면 파일이 완성된 후의 최종 길이와 용량을 알아야 합니다. 만약 moov가 기록되기 전에 녹화가 강제 종료되면 파일 전체가 깨져서 읽을 수 없게 됩니다. 따라서 실시간 녹화용으로는 부적합합니다.

3. 리먹싱 과정

리먹싱은 엘리멘터리 스트림(영상/음성)을 꺼내서 다른 컨테이너로 옮겨 담는 과정을 말합니다.

  • 데이터 무결성: 인코딩된 영상과 음성 비트스트림을 그대로 복사합니다. 재인코딩은 일어나지 않습니다. 화질과 음질은 원본과 수학적으로 100% 동일합니다.
  • 메타데이터 변경: 타임스탬프(PTS)를 다시 계산하고 컨테이너별 헤더를 넣거나 뺍니다. 이 과정에서 오버헤드(예: TS 패킷의 패딩)가 제거되어 파일 용량이나 비트레이트 표기가 달라질 수 있습니다.

확장자에 대한 주의:
파일 확장자를 바꾼다고(예: .ts.mp4로 이름 변경) 내부 컨테이너 형식이 바뀌지는 않습니다. 서버가 fMP4 데이터를 보내는데 리먹싱 없이 .ts로 저장한다면 그 파일은 구조적으로 여전히 fMP4입니다. 플레이어가 알아서 재생해줄 순 있어도 원본 컨테이너의 한계는 그대로 남습니다. 예를 들어 치지직은 fMP4를 송출하므로 리먹싱 없이 내부적으로 .ts로 저장해봤자 껍데기만 TS인 fMP4 파일이 됩니다.

4. 실시간 먹싱

실시간 먹싱 기능은 다운로드되는 스트림을 가로채서 ffmpeg를 통과시켜 저장하기 전에 메모리 상에서 컨테이너 포맷을 바꾸는 방식입니다.

데이터 흐름

녹화 과정의 논리적 흐름은 다음과 같습니다.

시나리오 A: 일반적인 단일 스트림
  1. streamlink: 플랫폼에서 HLS/DASH 세그먼트를 받아 하나의 원본 스트림(보통 MPEG-TS나 fMP4)으로 이어 붙입니다.
  2. 파이프: 이 원본 스트림을 stdin(표준 입력)을 통해 ffmpeg 프로세스로 넘깁니다.
  3. ffmpeg: 스트림을 읽어서 원본 컨테이너 패킷을 버리고 Matroska 클러스터와 인덱스를 생성하여 출력합니다.
  4. 디스크: 최종적으로 .mkv 파일이 드라이브에 기록됩니다.
[플랫폼] -> (세그먼트) -> [streamlink] -> (원본 스트림) -> [ffmpeg] -> (MKV 스트림) -> [디스크]
시나리오 B: 오디오/비디오 분리 스트림 (예: 위버스)
  1. streamlink: 비디오와 오디오 세그먼트를 각각 동시에 받습니다.
  2. streamlink: 비디오와 오디오를 하나의 스트림으로 합칩니다.
  3. ffmpeg: 합쳐진 스트림을 타겟 컨테이너로 리먹싱합니다.
[플랫폼 비디오] ↘              ↗ (원본 스트림) ↘
                [streamlink]                 [ffmpeg] -> (MKV 스트림) -> [디스크]
[플랫폼 오디오] ↗              ↘ (원본 스트림) ↗
시나리오 C: 연속 스트림 (예: FLV)
  1. streamlink: 서버와 지속적인 HTTP(S) 연결을 엽니다.
  2. 파이프: 들어오는 바이트 스트림이 stdin을 통해 즉시 ffmpeg로 전달됩니다.
  3. ffmpeg: 스트림을 읽어 실시간으로 타겟 컨테이너로 리먹싱합니다.
  4. 디스크: 최종 파일이 기록됩니다.
[서버] -> (연속 스트림) -> [streamlink] -> (원본 스트림) -> [ffmpeg] -> (MKV 스트림) -> [디스크]

기능적 이점

  1. 인덱싱과 탐색 성능: 원본 스트림을 Matroska (.mkv)로 변환하면 실시간으로 탐색 인덱스(Cues)가 생성됩니다. 덕분에 로컬 플레이어에서 즉각적인 탐색이 가능해집니다. 원본(ts/fMP4) 그대로 저장하면 인덱스가 없어 앞뒤로 스킵할 때 버퍼링이나 렉이 걸립니다.
  2. 필러(Filler) 데이터 제거: HLS 스트림, 특히 MPEG-TS는 고정 비트레이트(CBR) 규격을 맞추기 위해 Null Packet(더미 데이터)을 채워 넣는 경우가 많습니다. 필러 삭제 옵션을 켜면 ffmpeg가 이 빈 패킷들을 버립니다. 실제 미디어 내용에는 영향 없이 디스크 용량을 줄일 수 있습니다 (트위치 등).
  3. I/O 효율성: 수동으로 후처리 리먹싱을 하면 (쓰기 -> 읽기 -> 다시 쓰기 -> 삭제) 과정을 거쳐 SSD 수명에 영향을 주지만, 실시간 리먹싱은 최종 파일 구조만 디스크에 딱 한 번 씁니다.

리소스 사용량

  • CPU: 거의 영향 없음
  • 메모리: 활성화된 녹화 하나당 약 50MB의 RAM을 사용합니다 (예: 10개를 동시에 녹화하면 약 500MB 사용).

5. 설정 추천

MP4(Standard)는 실시간 녹화 중 파일이 깨질 위험이 크므로 현실적인 출력 옵션은 Matroska 아니면 원본입니다.

추천: MKV로 실시간 리먹싱

  • 설정: 실시간 먹싱 ON (필러 삭제 포함) + 확장자 .mkv
  • 결과: 오류에 강하고 탐색이 빠르며 용량이 최적화된(패딩 제거) 파일 생성
  • 이유: 파일의 안정성, 편의성, 저장 효율의 균형이 가장 좋습니다.

대안: Raw 스트림 (원본 저장)

  • 설정: 실시간 먹싱 OFF + 확장자 .ts (이 경우 확장자는 컨테이너에 영향을 주지 않으므로 큰 의미 없음)
  • 결과: 서버에서 수신한 비트스트림을 그대로 저장
  • 이유: 디버깅 용도, 방송 신호의 완벽한 원본 보존 목적 또는 RAM이 부족한 시스템에서만 추천합니다. 탐색 성능은 좋지 않을 것입니다.

6. 특수한 경우

일부 플랫폼은 전송 구조의 특성상 표준 파이프라인과 다르게 작동합니다.

  • 인스타그램:
    • instarec을 통해 다운로드됩니다. 지난 세그먼트를 가져오는 방식 때문에 실시간 먹싱이 불가능합니다.
    • 일단 원본으로 다운로드된 후 녹화가 끝나면 자동으로 타겟 컨테이너로 리먹싱됩니다.
  • 유튜브:
    • HLS, DASH 그리고 독자적인(SABR) 방식이 복잡하게 섞여 있어 yt-dlp를 통해 다운로드합니다.
    • yt-dlp가 가능한 대로 처리합니다. 상황에 따라 실시간 먹싱을 하기도 하고 녹화가 끝난 후 리먹싱하기도 합니다. 컨테이너는 사용자가 설정한 확장자를 따라갑니다.
고급 참고: Rclone FUSE와 실시간 먹싱 함께 사용하기

MKV로 리먹싱할 때, ffmpeg는 녹화가 끝난 후 파일의 시작 부분으로 다시 탐색하여 파일 헤더에 길이와 같은 중요한 메타데이터를 작성해야 합니다.

표준 rclone FUSE 마운트는 이 탐색 작업을 지원하지 않을 수 있습니다. 기본적으로 rclone은 파일을 쓰기 전용 스트림으로 취급하여 이 마지막 메타데이터 쓰기가 실패하게 할 수 있습니다. 결과 비디오 파일은 완벽하게 재생되지만, 길이 메타데이터가 누락됩니다. 이는 스냅샷 생성이 이 메타데이터에 의존하기 때문에 스타렉2에게는 치명적인 문제입니다. 결과적으로, 이러한 마운트에 직접 저장된 녹화는 스냅샷 생성이 실패합니다.

이 문제를 해결하려면, 쓰기를 지원하는 캐시 모드로 rclone 디렉터리를 마운트해야 합니다. 예를 들어:

rclone mount remote:path /path/to/mount --vfs-cache-mode writes --vfs-cache-max-age 5m

하지만 --vfs-cache-mode writes 사용 시 다음과 같은 점을 인지해야 합니다:

  • rclone은 먼저 전체 파일을 로컬 디스크에 캐시합니다. 원격 스토리지로의 업로드는 녹화가 끝나고 파일이 닫힌 후에만 시작됩니다.
  • 동시 녹화 전체를 일시적으로 저장할 충분한 로컬 디스크 공간이 있어야 합니다.
  • 업로드는 점진적으로 이루어지는 대신, 대규모 버스트로 발생합니다. 파일이 작성되는 동안 업로드하는 대신, 파일 전체가 끝에 한 번에 업로드됩니다.

이러한 절충안을 고려하여 스냅샷 기능이 로컬 캐싱 요구 사항의 가치가 있는지 결정하는 것은 사용자에게 달려 있습니다.

자격 증명

특정 플랫폼은 성인 방송 정보 가져오기나 팔로워 기반 API(팔로잉/멀티가져오기) 사용과 같은 특정 기능에 접근하기 위해 자격 증명이 필요합니다.

각 플랫폼의 자격 증명은 웹 UI를 통해 설정합니다. 일단 제공되면, 스타렉2은 필요한 인증 토큰을 starec2/tokens/ 디렉터리에 저장합니다. 이 토큰들은 자동으로 관리되며 일반적으로 만료 직전에만 스타렉2에 의해 갱신되어 지속적인 접근을 보장합니다.

만약 특정 플랫폼에서 인증 관련 문제가 발생하면, 첫 번째 문제 해결 단계는 웹 UI에서 해당 플랫폼의 자격 증명을 업데이트하는 것입니다. 이렇게 하면 기존에 저장된 토큰이 무효화되고 스타렉2이 새로운 토큰 세트를 강제로 획득하게 되어 종종 문제가 해결됩니다.

자주 발생하는 문제

파이썬 SSL 인증서

일부 환경에서 파이썬에 오래되거나 누락된 SSL 인증서가 설치된 경우가 있습니다. 이런 경우 마스터 로그에 다음과 같은 오류가 표시됩니다:

ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate

이 문제를 해결하려면, 의존성이 최신 상태인지 확인하고 인증서를 수동으로 설치하십시오:

pip install --upgrade -r requirements.txt
pip install pip-system-certs