+--> Destination 1
                    |
OBS --> VPS Restream +--> Destination 2
                    |
                    +--> Destination 3
                    |
                    +--> Private Server

Restream Server دقیقاً چه کاری انجام می‌دهد؟

فرض کنید OBS یک Stream با Bitrate شش مگابیت ارسال می‌کند. اگر بخواهید مستقیماً سه مقصد را از OBS پوشش دهید، به Upload بسیار بیشتری در کامپیوتر فرستنده نیاز دارید.

با Restream Server، OBS فقط همان یک Stream را به VPS ارسال می‌کند. VPS Stream را دریافت و خودش به سه مقصد Forward می‌کند.

در نتیجه فشار اصلی Upload چندمقصدی از اینترنت شما به شبکه دیتاسنتر منتقل می‌شود.

Restream با Transcoding فرق دارد

اگر Stream را بدون تغییر Codec و کیفیت Forward کنیم، عملیات بیشتر شبیه Remux/Relay است و CPU زیادی نمی‌خواهد.

اگر یک مقصد H.264 1080p و مقصد دیگری 720p با Bitrate پایین‌تر بخواهد، باید Transcoding انجام شود و مصرف CPU یا GPU افزایش پیدا می‌کند.

MediaMTX برای Restream چه قابلیت‌هایی دارد؟

در نسخه‌های جدید MediaMTX قابلیت Forward به‌صورت Native وجود دارد. Stream ورودی می‌تواند به مقصدهای RTMP/RTMPS، SRT، RTSP، WebRTC/WHIP و Media-over-QUIC Forward شود.

اگر مقصد نیازمند Filter یا Transcoding باشد، می‌توان FFmpeg را با runOnAvailable اجرا کرد.

برای Restream چه VPSای لازم است؟

اگر از Forward Native یا -c copy استفاده می‌کنید، CPU معمولاً مسئله اصلی نیست؛ پهنای باند مهم‌تر است.

برای مثال یک Stream با Bitrate شش مگابیت که به سه مقصد فرستاده شود، تقریباً ۱۸Mbps ترافیک خروجی Restream ایجاد می‌کند؛ علاوه بر حدود ۶Mbps ورودی از OBS.

اگر سه مقصد هرکدام کیفیت جدا بخواهند، منابع CPU/GPU نیز باید به محاسبه اضافه شوند.

مرحله اول: نصب MediaMTX

اگر مقاله قبلی ساخت سرور پخش زنده با OBS را انجام داده‌اید، MediaMTX از قبل آماده است.

در غیر این صورت با Docker نسخه فعلی را اجرا کنید:

services:
  mediamtx:
    image: bluenviron/mediamtx:1.21.1

    restart: unless-stopped

    ports:
      - "1935:1935"
      - "8888:8888"

    volumes:
      - ./mediamtx.yml:/mediamtx.yml:ro

مرحله دوم: تعریف Publisher

authInternalUsers:
  - user: obs
    pass: CHANGE_THIS_PASSWORD
    permissions:
      - action: publish
        path: live

  - user: any
    pass:
    permissions:
      - action: read
        path: live

paths:
  live:

مرحله سوم: اتصال OBS

در OBS:

Service: Custom

Server:

rtmp://restream.example.com/live?user=obs&pass=PASSWORD

Stream Key: خالی

مرحله چهارم: Forward به چند RTMP Server

حالا بخش paths را کامل می‌کنیم:

paths:
  live:
    forward:
      - dest: rtmps://DESTINATION-1/app#STREAM_KEY_1

      - dest: rtmps://DESTINATION-2/app#STREAM_KEY_2

      - dest: rtmps://DESTINATION-3/app#STREAM_KEY_3

با شروع Stream روی مسیر live، MediaMTX آن را به هر سه Destination ارسال می‌کند.

ارسال به YouTube

در پنل Live سرویس مقصد، Stream URL و Stream Key را دریافت کنید و آن‌ها را به شکل Destination RTMPS در MediaMTX قرار دهید.

برای YouTube باید Stream شما هم Track ویدئو و هم Audio داشته باشد؛ Streamهای Video-only ممکن است پذیرفته نشوند.

ارسال هم‌زمان به SRT Server

Native Forward محدود به RTMP نیست. برای SRT:

paths:
  live:
    forward:
      - dest: srt://remote.example.com:8890?streamid=publish:live

Forward به MediaMTX دیگر

اگر یک Media Server دوم دارید، می‌توانید Stream را با RTSP، RTMP، SRT، WHIP یا Media-over-QUIC Forward کنید.

این روش برای ساخت Relay Node در دیتاسنتر دیگر کاربردی است.

چه زمانی Native Forward کافی نیست؟

اگر مقصد Stream را با Codec فعلی قبول کند، Native Forward بهترین مسیر است؛ چون Transcoding اضافه ندارید.

اما فرض کنید OBS با 1080p و 6000kbps Stream می‌فرستد و مقصد دوم فقط 720p و 3000kbps می‌خواهد. اینجا باید FFmpeg وارد مسیر شود.

Restream با FFmpeg و بدون Transcoding

MediaMTX می‌تواند با runOnAvailable هنگام شروع Stream فرمان FFmpeg را اجرا کند.

pathDefaults:
  runOnAvailable: >
    ffmpeg
    -i rtsp://127.0.0.1:8554/$MTX_PATH
    -c copy
    -f flv
    rtmp://remote.example.com/live/STREAM_KEY

  runOnAvailableRestart: yes

چون -c copy استفاده شده، ویدئو دوباره Encode نمی‌شود.

Restream با کاهش کیفیت

ffmpeg \
  -i rtsp://127.0.0.1:8554/live \
  -vf "scale=-2:720" \
  -c:v libx264 \
  -preset veryfast \
  -b:v 2800k \
  -maxrate 3000k \
  -bufsize 5600k \
  -c:a aac \
  -b:a 128k \
  -f flv \
  rtmp://remote.example.com/live/STREAM_KEY

این دستور CPU بیشتری مصرف می‌کند، چون Frameها Decode و دوباره Encode می‌شوند.

یک Stream به چند مقصد با FFmpeg

FFmpeg Tee Muxer نیز برای خروجی چندگانه قابل استفاده است، اما اگر مقصدها مستقل هستند و قابلیت Native Forward MediaMTX نیاز شما را پوشش می‌دهد، مدیریت Destinationها در MediaMTX ساده‌تر است.

FFmpeg را زمانی وارد کنید که به Transcoding، Filter، Watermark، تغییر Resolution یا Protocol خاص نیاز دارید.

Watermark هنگام Restream

برای افزودن لوگو باید Stream دوباره Encode شود:

ffmpeg \
  -i rtsp://127.0.0.1:8554/live \
  -i logo.png \
  -filter_complex \
  "overlay=W-w-30:H-h-30" \
  -c:v libx264 \
  -preset veryfast \
  -b:v 4500k \
  -c:a aac \
  -b:a 128k \
  -f flv \
  rtmp://remote.example.com/live/STREAM_KEY

Failover در Restream

یک Restream Server خودش می‌تواند Single Point of Failure باشد. برای Liveهای مهم می‌توانید Server دوم، Source Backup یا Pipeline جایگزین داشته باشید.

همچنین runOnAvailableRestart می‌تواند Process مربوط به Forward را در صورت خروج دوباره اجرا کند، اما Failover کامل شبکه موضوع جداگانه‌ای است.

چطور مصرف پهنای باند را حساب کنیم؟

فرمول ساده:

Outbound ≈ Stream Bitrate × Number of Destinations

مثلاً:

6 Mbps × 4 destinations ≈ 24 Mbps outbound

این فقط Bitrate Media است و سربار Protocol را حساب نمی‌کند.

چطور Stream Keyها را امن نگه داریم؟

Stream Key عملاً Credential حساب Live شما است.

✅ فایل mediamtx.yml را عمومی نکنید.

✅ Permission فایل را محدود کنید.

✅ Configuration را داخل Repository عمومی Git قرار ندهید.

✅ بعد از افشای Stream Key فوراً آن را Rotate کنید.

✅ در صورت امکان از RTMPS استفاده کنید.

نمونه Permission:

sudo chmod 600 mediamtx.yml

آیا Restream کیفیت را کم می‌کند؟

اگر Native Forward یا -c copy انجام شود، Media دوباره Encode نمی‌شود و افت کیفیت ناشی از Re-encoding نداریم.

اگر برای هر مقصد Transcode انجام دهید، کیفیت و حجم خروجی به Encoder Settings بستگی دارد.

مانیتورینگ Restream Server

در Restream فقط Up بودن VPS کافی نیست. بهتر است این موارد را مانیتور کنید:

🔹 اتصال Publisher اصلی

🔹 اتصال هر Destination

🔹 پهنای باند ورودی و خروجی

🔹 CPU در صورت Transcoding

🔹 Packet Loss و Network Error

🔹 Logهای FFmpeg و MediaMTX

خطاهای رایج

یک مقصد Stream دریافت نمی‌کند

Stream URL و Key همان مقصد را دوباره از پنل Live بررسی کنید. همچنین Log MediaMTX را ببینید.

YouTube Stream را رد می‌کند

وجود Track صوت و تصویر، Codec، Bitrate و تنظیمات Live همان سرویس را بررسی کنید.

CPU به ۱۰۰ درصد می‌رسد

اگر فقط Forward می‌خواهید، مطمئن شوید Transcoding ناخواسته انجام نمی‌شود. -c copy یا Native Forward بسیار سبک‌تر است.

Stream بعد از قطع اینترنت OBS برنمی‌گردد

Reconnect Settings OBS، Network Stability و وضعیت Path MediaMTX را بررسی کنید.

سؤالات متداول

Restream Server چیست؟

سروری است که یک Stream ورودی دریافت می‌کند و آن را به یک یا چند مقصد دیگر Forward می‌کند.

آیا Restream به CPU زیاد نیاز دارد؟

اگر Stream بدون تغییر Forward شود، مصرف CPU پایین است. Transcoding کیفیت یا Codec مصرف CPU/GPU را بالا می‌برد.

آیا MediaMTX می‌تواند مستقیم Restream کند؟

بله. نسخه‌های فعلی Forward Native برای چند Protocol از جمله RTMP/RTMPS، SRT، RTSP و WebRTC دارند.

چه زمانی FFmpeg لازم است؟

وقتی مقصد به Resolution، Bitrate، Codec، Watermark یا Filter متفاوت نیاز دارد.

آیا یک Live را می‌توان به چند مقصد هم‌زمان فرستاد؟

بله. می‌توانید چند Forward Destination روی یک Path تعریف کنید.

Restream بهتر است روی VPS باشد یا سیستم شخصی؟

قرار دادن Restream روی VPS باعث می‌شود اینترنت فرستنده فقط یک Upload داشته باشد و توزیع به مقصدها داخل شبکه دیتاسنتر انجام شود.