TMO

Categoria 1 — Arquivos Locais

Formato Extensão Biblioteca
MPEG-4 .mp4, .m4v OpenCV, PyAV, FFmpeg
Matroska .mkv PyAV, FFmpeg
AVI .avi OpenCV, FFmpeg
QuickTime .mov PyAV, FFmpeg
Windows Media .wmv, .asf FFmpeg
Flash Video .flv, .f4v FFmpeg
WebM .webm FFmpeg, OpenCV
MPEG Transport Stream .ts, .mts, .m2ts FFmpeg, PyAV
MPEG-2 .mpg, .mpeg, .m2v FFmpeg
3GPP Mobile .3gp, .3g2 FFmpeg
OGG Video .ogv, .ogg FFmpeg
AVCHD (câmeras Sony/Canon) .mts, .m2ts FFmpeg
RAW de câmeras cinema .r3d, .braw, .ari FFmpeg + SDK
Imagens sequenciais .jpg, .png, .tiff OpenCV, PyAV
Categoria 2 — Câmeras por Hardware (Estádio)
Hardware Interface Biblioteca Python Observação
Câmera USB / Webcam USB 2/3 OpenCV, VidGear CamGear Mais simples
Câmera IP PTZ Ethernet/PoE OpenCV + RTSP/ONVIF Câmeras de estádio comuns
Placa captura HDMI PCIe/USB FFmpeg dshow (Win) / v4l2 (Linux) Elgato, AVerMedia, Magewell
Placa captura SDI PCIe/Thunderbolt FFmpeg decklink + Blackmagic SDK Padrão broadcast
profissional
SDI via Blackmagic DeckLink SDI (BNC) ctypes → DeckLinkAPI HD-SDI, 3G-SDI, 12G-SDI
FireWire / IEEE 1394 FireWire FFmpeg libdc1394 Câmeras legadas
GoPro (WiFi) HTTP stream yt-dlp ou requests Via GoPro Labs
Drone DJI WiFi/RTMP FFmpeg RTMP Via DJI SDK ou OBS
Câmera Android USB/WiFi adb + VidGear Via DroidCam/scrcpy
Raspberry Pi Camera CSI/USB VidGear PiGear Câmera embutida
Categoria 3 — Protocolos de Streaming (Rede)
Protocolo Uso Típico Biblioteca Python Latência
RTSP Câmeras IP, NVR, CFTV OpenCV, FFmpeg, VidGear Baixa
RTMP / RTMPS OBS → servidor, YouTube Live input FFmpeg, VidGear Baixa
HLS (m3u8) YouTube Live, Twitch, ABR FFmpeg, streamlink, m3u8 Média
DASH (mpd) YouTube, serviços premium FFmpeg, yt-dlp Média
SRT Broadcast profissional, estádio → nuvem FFmpeg SRT, srt-python Muito baixa
RTP / UDP Broadcast, IPTV FFmpeg, PyAV Muito baixa
NDI Studio, OBS, câmeras de rede ndi-python (NDI SDK) Muito baixa
WebRTC Navegador, conferência aiortc Ultra baixa
HTTP / HTTPS Streams simples, câmeras IP OpenCV, requests Média
MMS Microsoft Media Server (legado) FFmpeg —
FTP / SFTP / SMB Arquivos em rede FFmpeg —
Categoria 4 — Plataformas Online (via yt-dlp)
Plataforma Ao Vivo Gravado Formato
YouTube ✅ ✅ HLS / DASH
Twitch ✅ ✅ HLS
Facebook Live ✅ ✅ DASH
Instagram Live ✅ ✅ HLS
TikTok Live ✅ ✅ HLS
Dailymotion ✅ ✅ HLS
Vimeo — ✅ HLS
ESPN / SporTV ✅ ✅ HLS
1000+ sites varies ✅ varies

Requer autenticação/cookie do usuário

Categoria 5 — Broadcast Profissional (Estádio)

Formato Descrição Interface Biblioteca
SD-SDI 270 Mbps, SD (480i/576i) BNC coaxial FFmpeg decklink
HD-SDI 1.5 Gbps, HD (720p/1080i) BNC coaxial FFmpeg decklink
3G-SDI 3 Gbps, 1080p60 BNC coaxial FFmpeg decklink
6G-SDI 6 Gbps, 4K30 BNC coaxial FFmpeg decklink
12G-SDI 12 Gbps, 4K60 BNC coaxial FFmpeg decklink
HDMI 1.4 Até 1080p60 HDMI FFmpeg dshow/v4l2
HDMI 2.0/2.1 Até 4K120 HDMI FFmpeg via placa captura
NDI Vídeo HD em rede local Ethernet ndi-python
DisplayPort Monitor / câmera profissional DP Via captura
Thunderbolt Ultra alta velocidade TB3/4 Blackmagic Ultrastudio
Categoria 6 — Captura de Tela / Virtual
Fonte Biblioteca
Monitor / Desktop inteiro VidGear ScreenGear, dxcam
Janela específica mss, pygetwindow
Câmera virtual (OBS VirtualCam) OpenCV (aparece como webcam)
OBS → RTMP local FFmpeg RTMP

ANALISE ESSE PDF QUE CONTEM UM SOFTWARE PARA USO EM TELEVISON MATCH OFFICER
TMO,

CONSEGUIMOS FAZER ALGO ASSIM COM PHYTON

ME DE O PLANO PASSO A PASSO DISOO

I'll start by reading the PDF to understand the TMO software's features and capabilities.

Ler
CAPACITACION PISTON [Link]
Let me try with the PDF MCP tools.

Usado 2 ferramentas
Let me read the remaining pages.

Usou PDFTools-_Fill: Sign Merge Split Extract read pdf content

Now I have a clear picture of what PISTON does. Let me render the visual pages to confirm the UI
details.

Usado 2 ferramentas
I have all the information I need. The PDF is a training slide deck — mostly visual — but the text gives
a complete picture of the system. Here is the full plan:

O que é o PISTON (resumo do PDF)

É um sistema de ingestão, gravação e distribuição de vídeo para arbitragem de rugby, com:

5 câmeras SDI (Wide, Tight, Back Left, Back Right, TV Program) + áudio do árbitro
Gravação local no MacBook do Operador (200 GB)
Distribuição local via Ethernet para iPads do TMO, HIA e Citing Commission
Distribuição remota via cloud para analistas World Rugby e Citing remoto
Revisão de vídeo (slow-mo, frame a frame, multi-ângulo)
Estatísticas e relatórios por partida, jogador, torneio
Plano passo a passo em Python
FASE 1 — Motor de Vídeo (Ingestão + Gravação)
Objetivo: Capturar as 5 câmeras e gravar continuamente.

Biblioteca principal: ffmpeg-python + subprocess

Hardware: Blackmagic DeckLink (SDI) ou placa de captura HDMI
Passos:

Instalar FFmpeg com suporte decklink (SDI) ou dshow/v4l2 (HDMI/USB)

Criar VideoIngestor — classe que abre cada feed com FFmpeg em subprocesso separado
Gravação em arquivo com segmentação (ex: segmentos de 10 min em .mp4) para facilitar busca de
trecho
Buffer circular em memória (últimos 60s por câmera) para revisão imediata

Exemplo de estrutura
class CameraFeed:
name: str # "WIDE", "TIGHT", "BACK_LEFT"...
source: str # "decklink:0", "rtsp://...", "dshow:..."
process: subprocess # ffmpeg rodando

class VideoEngine:
feeds: list[CameraFeed]
def start_recording(self)
def stop_recording(self)
def get_clip(self, camera, start_ts, end_ts) -> Path
FASE 2 — Servidor de Streaming Local (distribuição para iPads)
Objetivo: TMO, HIA e Citing abrem no iPad e assistem ao vivo ou revisam.

Ferramenta: MediaMTX (binário open-source, roda como subprocess Python)

Protocolo: HLS (funciona em qualquer browser Safari/iPad sem plugin)
Passos:

Baixar e empacotar mediamtx (executável único, ~10 MB)

Python gera [Link] dinamicamente com os 5 paths de câmera
FFmpeg faz push RTMP → MediaMTX que publica em HLS
iPad acessa [Link] no Safari
Rede local:
MacBook (PISTON) ──Ethernet──> Switch
├── iPad TMO (12.9")
├── iPad HIA (10.9")
└── iPad Citing (10.9")
FASE 3 — Interface Web para Clientes (TMO / HIA / Citing)
Objetivo: Página web acessível no iPad com player de vídeo + controles de revisão.

Stack: FastAPI + Jinja2 + [Link] (HTML5)

Passos:

Rota /tmo, /hia, /citing — cada uma com layout e permissões diferentes
Player [Link] com:
Seleção de câmera (botões: Wide | Tight | BL | BR | TV)
Velocidade de reprodução (0.25x, 0.5x, 1x)
Frame a frame (← →)
Scrubber de timeline (busca no clipe gravado)
Multi-ângulo (4 telas simultâneas)
WebSocket para receber alertas do Operador ("TMO Review Requested")
Telas no iPad TMO:
[WIDE] [TIGHT] [BACK L] [BACK R] [TV] ← seletor de câmera
┌─────────────────────────────────────┐
│ VIDEO PLAYER │
└─────────────────────────────────────┘
[◀◀] [0.25x] [0.5x] [1x] [▶] [frame◀] [frame▶]
[MARK INICIO] [MARK FIM] [ENVIAR PARA TMO]
FASE 4 — Dashboard do Operador (PISTON LOCAL)
Objetivo: Interface no MacBook para o Operador controlar tudo.

Stack: PyQt6 (desktop nativo) OU FastAPI + React (web local)

Recomendado: PyQt6 — mais robusto para uso em estádio sem internet
Passos:

Grid de 5 câmeras ao vivo (thumbnails via OpenCV)

Botões de ação:
Iniciar/Parar gravação
Disparar revisão TMO (envia timestamp via WebSocket)
Disparar HIA (marca evento)
Disparar Citing
Log de eventos em tempo real (lista rolante)
Monitor de status: disco livre, CPU, status de cada câmera (verde/vermelho)
Controle de stream para cloud (ligar/desligar relay)

Estrutura do Dashboard
class PistonDashboard(QMainWindow):
video_grid: QGridLayout # 5 câmeras
event_log: QListWidget # eventos
status_bar: StatusBar # disco, CPU, rede
def trigger_tmo_review(self, timestamp)
def trigger_hia(self, player_id)
FASE 5 — Sistema de Eventos (WebSocket)
Objetivo: Comunicação em tempo real entre Operador e clientes (iPads).

Stack: FastAPI WebSockets (já incluso no FastAPI)

Passos:

Servidor WebSocket central no MacBook

Mensagens tipadas:
{"type": "TMO_REVIEW", "timestamp": 1234567890, "camera": "WIDE"}
{"type": "HIA_TRIGGER", "player": "15", "timestamp": ...}
{"type": "HALF_TIME"}
{"type": "MATCH_END"}
Quando TMO pressiona "Review Request" no iPad → envia para Operador → Operador confirma →
todos os clientes recebem o trecho
SQLite armazena todos os eventos com timestamp
FASE 6 — Distribuição Cloud (Remoto)
Objetivo: Analistas World Rugby e Citing remoto assistem de qualquer lugar.

Stack: FFmpeg RTMP push → servidor cloud (AWS/Linode/VPS simples)

OU SRT (melhor para estádio com rede instável)
Passos:

Classe CloudRelay — gerencia FFmpeg RTMP/SRT push

Operador liga/desliga relay com 1 botão
Servidor cloud roda MediaMTX ou nginx-rtmp
Remoto acessa via HLS seguro (HTTPS + token)
Requisito de upload: ≥ 50 Mbps (como especificado no PDF)
MacBook ──RTMP/SRT──> Cloud VPS ──HLS HTTPS──> Citing Remoto
──HLS HTTPS──> Analista WR
FASE 7 — Estatísticas e Relatórios
Objetivo: Gerar relatórios por partida, jogador, torneio.

Stack: SQLite + SQLAlchemy + openpyxl + reportlab

Passos:

Modelo de dados SQLite:

matches(id, date, home, away, venue)
events(id, match_id, type, timestamp, camera, player_id, notes)
reviews(id, event_id, decision, duration_sec, clip_path)
Ao fim da partida, Operador clica "Gerar Relatório"
Tipos de relatório (como no PDF):
Relatório por partida (eventos, revisões, tempo de cada)
Relatório individual (por jogador)
Relatório de torneio (agregado)
Relatório 1v1 (marketing)
Formato World Rugby
Estrutura de Pastas do Projeto
piston-py/
├── core/
│ ├── video_engine.py # FFmpeg ingest + gravação
│ ├── stream_server.py # MediaMTX wrapper
│ ├── cloud_relay.py # RTMP/SRT push
│ └── event_bus.py # WebSocket hub
├── api/
│ ├── [Link] # FastAPI app
│ ├── routes_tmo.py # UI TMO
│ ├── routes_hia.py # UI HIA
│ └── routes_citing.py # UI Citing
├── ui/
│ └── [Link] # PyQt6 operador
├── db/
│ ├── [Link] # SQLAlchemy models
│ └── [Link] # gerador de relatórios
├── static/ # [Link], CSS
├── templates/ # Jinja2 HTML
├── [Link] # câmeras, IPs, paths
└── [Link] # entry point
Dependências Python
ffmpeg-python # controle do FFmpeg
fastapi # servidor web + WebSocket
uvicorn # ASGI server
jinja2 # templates HTML
PyQt6 # dashboard operador
opencv-python # thumbnails ao vivo
sqlalchemy # banco de dados
openpyxl # relatórios Excel
reportlab # relatórios PDF
aiofiles # servir arquivos de vídeo async
websockets # cliente WS no dashboard
Ordem de Desenvolvimento Recomendada
Prioridade Fase Tempo estimado
1 Fase 1 — Ingestão de vídeo + gravação 1 semana
2 Fase 2 — Servidor HLS local 3 dias
3 Fase 3 — UI web básica no iPad (player) 1 semana
4 Fase 4 — Dashboard operador PyQt6 1 semana
5 Fase 5 — Eventos WebSocket 3 dias
6 Fase 6 — Cloud relay 3 dias
7 Fase 7 — Relatórios 1 semana
Total estimado: 5-6 semanas para um MVP funcional.
Quer que eu comece a implementar alguma fase específica agora? A Fase 1 (motor de vídeo) e Fase
3 (UI do iPad) são as mais críticas para ter um protótipo funcional.

VAMOS FAZER ALGUMAS ALTERAÇÕES NA LOGICA

QUERO UM SOFFTWARE MULTIPLATAFORMA
PC-WINDOWS E MAC
CELULAR - ANDROID E IOS
TABLET - ANDROID E IOS

REESCREVA A LOGICA PARA QUE EU POSSA AVALIAR

Entendido. Deixa eu repensar a arquitetura de forma mais limpa para multiplataforma.

Perguntado
Frontend
Para a interface do cliente (TMO, HIA, Citing), qual abordagem prefere?

Web App / PWA (Recomendado)

O servidor PISTON vai rodar em qual máquina no estádio?

PC Windows (Recomendado)

Como os clientes (iPads/celulares) se conectam ao servidor?

Quais distâncias estão envolvidas no estádio típico?

Médio (100m - 300m)

Qual o nível de redundância de internet necessário?

Alta (missão crítica)

Entendido. Sistema completamente independente, sem OB Van, missão crítica. Vou montar a
infraestrutura física completa.

Infraestrutura Física — PISTON do Zero

Visão Geral do Fluxo de Sinal
┌───────────────────────────────────────────────────────────────
──────┐
│ CAMPO DE JOGO │
││
│ CAM 4 CAM 1 CAM 2 CAM 5 │
│ BACK L WIDE TIGHT BACK R │
│ (try left) (catbird) (ball follow) (try right) │
││││││
│ FIBRA FIBRA FIBRA FIBRA │
│ ~200m ~150m ~150m ~200m │
│ └───────────────┴───────────────┴───────────────┘ │
│││
│ CAM 3 — LATERAL │
│ (árbitro + campo) │
│ FIBRA ~100m │
└─────────────────────────────|
───────────────────────────────────────┘
│
┌─────────▼──────────┐
│ PATCH PANEL │
│ Fibra → SDI │
│ (sala técnica) │
└─────────┬──────────┘
│ 5× SDI (BNC, <10m)
┌─────────▼──────────┐
│ PISTON SERVER │
│ Windows PC │
│ + DeckLink 8K │
└─────────┬──────────┘
│
┌───────────────┼───────────────┐
│││
┌──────▼──────┐ ┌──────▼──────┐ ┌─────▼──────┐
│ LAN Switch │ │ Dual-WAN │ │ UPS │
│ Gigabit │ │ Peplink │ │ 1500VA │
└──────┬───────┘ └──────┬──────┘ └────────────┘
││
┌─────────┼──────┐ ┌─────┴──────────────────────┐
│ │ │ │ INTERNET REDUNDANTE │
TMO HIA CITING │ ① Fibra do Estádio │
(iPad) (iPad) (iPad) │ ② Roteador 5G dedicado │
│ ③ Starlink (backup) │
└─────────────┬───────────────┘
│ Upload ~50 Mbps
┌────▼─────┐
│ CLOUD │
│ VPS │
└────┬─────┘
│
┌────────────┼──────────────┐
[Citing Remoto] [Analista WR] [Árbitro Remoto]
BLOCO 1 — Câmeras (5 posições)
Especificação mínima para TMO
Resolução: 1080p60 (mínimo) → slow-motion a 50%
Ideal: 1080p120 → slow-motion a 25% (muito mais limpo para revisão)
Saída: SDI (BNC) — padrão broadcast
Latência de captura: < 2 frames
Câmeras Recomendadas por Posição
Câmera Posição Tipo Modelo sugerido Lente
CAM 1 WIDE (catbird) PTZ c/ SDI Sony BRC-X400 ou Panasonic AW-UE150 Wide 28mm
CAM 2 TIGHT (bola) PTZ c/ SDI Sony BRC-X400 Telephoto zoom
CAM 3 LATERAL PTZ c/ SDI Sony BRC-X400 Wide
CAM 4 BACK LEFT (try) Fixa c/ SDI Blackmagic Studio 4K Pro Wide 35mm
CAM 5 BACK RIGHT (try) Fixa c/ SDI Blackmagic Studio 4K Pro Wide 35mm
CAM 1 e 2 ficam na mesma torre (catbird, centro do estádio). Podem ser controladas remotamente por
joystick PTZ do operador.

BLOCO 2 — Transporte de Sinal (Fibra Óptica)

Por que Fibra e não Cabo Coaxial SDI
SDI Coaxial HDMI Cobre HDMI Fibra SDI Fibra
Distância máxima ~100m (HD) ~15m ~300-2000m ~2000m+
Imunidade a interferência Média Baixa Alta Alta
Peso do cabo Alto Médio Muito leve Muito leve
Custo Baixo Baixo Médio Médio-alto
Para 100-300m Com repetidor Inviável ✅ Ideal ✅ Ideal
Dois Caminhos Possíveis
Caminho A — SDI sobre Fibra (Padrão Broadcast)

Câmera (SDI BNC out)

↓
Conversor SDI→Fibra [Blackmagic Mini Converter SDI to Fiber]
↓
Cabo fibra monomodo LC/LC (100-300m)
↓
Conversor Fibra→SDI [Blackmagic Mini Converter Fiber to SDI]
↓
Patch Panel (sala técnica) → BNC → DeckLink no servidor
Caminho B — HDMI sobre Fibra (para câmeras HDMI)

Câmera (HDMI out)

↓
Extensor HDMI Fibra TX [StarTech ST121SHD30 / Aten VE883]
↓
Cabo fibra LC duplex (até 300m)
↓
Extensor HDMI Fibra RX
↓
Conversor HDMI→SDI [Blackmagic HDMI to SDI]
↓
Patch Panel → BNC → DeckLink
Recomendação: Caminho A (SDI nativo) se as câmeras tiverem SDI. Caminho B se usar câmeras
mais acessíveis com HDMI (Sony FX3, Blackmagic Pocket, etc.)

Infraestrutura de Cabos no Estádio

Posições das câmeras → Calhas/eletrodutos existentes → Sala técnica
Para instalar antes do evento:

Rolo fibra LC duplex OS2 (monomodo): 500m (cobre todas as posições)

 10x conectores LC (terminados em campo com kit de fusão)
Ou: cabo pré-terminado de comprimento fixo (mais simples, mais caro)
Patch Panel 12 portas LC no rack da sala técnica
BLOCO 3 — Servidor PISTON (Hardware)
Por que PC de Torre e não MacBook
O MacBook do PDF original funcionava porque recebia feed via rede. Para capturar 5 câmeras
SDI com placa DeckLink, precisamos de slot PCIe — que só existe em towers ou Mac Pro.

Especificação do Servidor PISTON

┌─────────────────────────────────────────────────────┐
│ PISTON SERVER — Especificação Mínima │
├─────────────────────────────────────────────────────┤
│ CPU Intel Core i9-13900K (24 núcleos) │
│ OU AMD Ryzen 9 7950X │
│ Necessário para 5x encode simultâneo │
├─────────────────────────────────────────────────────┤
│ RAM 32 GB DDR5 (mínimo) — 64GB ideal │
├─────────────────────────────────────────────────────┤
│ GPU NVIDIA RTX 4060 ou superior │
│ Usada para hardware encoding (NVENC) │
│ Reduz carga da CPU em ~60% │
├─────────────────────────────────────────────────────┤
│ Armazenamento │
│ OS + Software: 1x NVMe 512GB │
│ Gravação Câmeras: 2x NVMe 2TB (RAID 1) │
│ ≈ 200GB/câmera/partida × 5 = 1TB por partida │
│ RAID 1 = redundância: se um SSD falhar, não perde│
├─────────────────────────────────────────────────────┤
│ Placa de Captura │
│ Blackmagic DeckLink 8K Pro (PCIe) │
│ 8 entradas SDI 3G/12G │
│ Captura 5 câmeras em uma única placa │
├─────────────────────────────────────────────────────┤
│ Rede 2x porta Ethernet Gigabit (onboard) │
│ 1 para LAN local, 1 para internet │
├─────────────────────────────────────────────────────┤
│ Energia Fonte 850W 80+ Gold │
│ Consumo estimado: ~400-500W sob carga │
├─────────────────────────────────────────────────────┤
│ OS Windows 11 Pro (ou Ubuntu Server) │
└─────────────────────────────────────────────────────┘
Alternativa com MacBook + Capture Externa
MacBook Pro M3 Max (16")
+ Blackmagic UltraStudio 4K Mini (Thunderbolt)
→ 1 entrada SDI (limitado — só 1 câmera por device)
+ Switch SDI → 5 câmeras em 1 saída (Signal distributor)
Limitação: menos flexível para 5 entradas simultâneas
BLOCO 4 — Rede Local (LAN do Estádio)
PISTON SERVER
│
│ Gigabit Ethernet
▼
┌────────────────────────────────┐
│ Switch Gerenciável │
│ TP-Link TL-SG2210MP (PoE+) │
│ 10 portas Gigabit │
│ 8 portas PoE (alimenta APs) │
└────┬─────┬──────┬──────┬───────┘
││││
TMO HIA CITING WiFi AP
(cabo) (cabo)(cabo) (WiFi 6)
iPad iPad iPad │
├── iPad TMO (WiFi)
├── Celular Árbitro (WiFi)
└── Notebook Operador backup
Segmentação por VLAN (recomendado)
VLAN 10 — PISTON CORE (servidor + switches)
VLAN 20 — CLIENTES TMO (iPads oficiais)
VLAN 30 — CLOUD/INTERNET (WAN uplink)
VLAN 40 — GERÊNCIA (acesso administrativo)
Isso impede que um iPad comprometido afete o servidor de vídeo.

BLOCO 5 — Redundância de Internet (Missão Crítica)

Arquitetura de Tripla Conexão
┌─────────────────────────────────────────────────────────────┐
│ PEPLINK BALANCE 310X │
│ (Roteador Dual/Triple WAN profissional) │
│ SpeedFusion Bonding │
└──────────┬──────────────────┬──────────────────┬───────────┘
│││
┌──────▼──────┐ ┌───────▼──────┐ ┌───────▼──────┐
│ WAN 1 │ │ WAN 2 │ │ WAN 3 │
│ FIBRA │ │ 5G/LTE │ │ STARLINK │
│ Estádio │ │ Dedicado │ │ Satélite │
│ 300 Mbps │ │ 100 Mbps │ │ 50-200 Mbps │
│ (primária) │ │ (failover) │ │ (emergência)│
└─────────────┘ └──────────────┘ └──────────────┘
Comportamento por Modo
Modo Quando ativa Comportamento
Ativo-Ativo Operação normal Todas conexões ativas, tráfego balanceado, mais banda total
SpeedFusion Bond Streaming crítico Une as 3 conexões como 1 túnel VPN, tolerante a queda parcial
Failover automático Uma WAN cai Redireciona em < 1 segundo, sessões ativas não caem
Hot Standby WAN 3 (Starlink) Só entra se WAN 1 + 2 caírem simultaneamente
Configuração de QoS (Prioridade de Tráfego)
PRIORIDADE MÁXIMA: Stream RTMP/SRT para cloud (vídeo TMO)
PRIORIDADE ALTA: WebSocket (eventos em tempo real)
PRIORIDADE MÉDIA: HLS local (iPads no estádio)
PRIORIDADE BAIXA: Updates, downloads, outros
Equipamento de Rede — Internet
┌─────────────────────────────────────────────────────────┐
│ WAN 1 — Fibra do Estádio │
│ Cabo Ethernet do patch panel do estádio → Peplink WAN1 │
│ Solicitar IP fixo ao operador do estádio │
│ Upload mínimo necessário: 50 Mbps │
├─────────────────────────────────────────────────────────┤
│ WAN 2 — Roteador 5G Dedicado │
│ Peplink BR1 Pro 5G (SIM slot) │
│ SIM dedicado para o evento (dados ilimitados ou 100GB) │
│ Posicionar onde tem melhor sinal 5G (janela, exterior) │
│ Conecta ao Peplink Balance via cabo ou integrado │
├─────────────────────────────────────────────────────────┤
│ WAN 3 — Starlink Portátil │
│ Kit Starlink Flat High Performance │
│ Montar no telhado da cabine ou área aberta │
│ Latência: 20-60ms (suficiente para streaming) │
│ Ativa automaticamente só se WAN1+WAN2 falharem │
└─────────────────────────────────────────────────────────┘
BLOCO 6 — Infraestrutura Cloud
VPS para Relay de Streaming
┌──────────────────────────────────────────────────────┐
│ CLOUD VPS — Especificação │
├──────────────────────────────────────────────────────┤
│ CPU 4 vCPU │
│ RAM 8 GB │
│ Disco 100 GB SSD │
│ Banda 10 TB/mês transferência (suficiente) │
│ OS Ubuntu 22.04 LTS │
│ SW MediaMTX (Docker) + Nginx reverse proxy │
├──────────────────────────────────────────────────────┤
│ Localização: São Paulo (DigitalOcean/Vultr/AWS) │
│ Latência para América do Sul: <20ms │
│ Custo: ~$40-80/mês │
└──────────────────────────────────────────────────────┘
Cálculo de Banda para Cloud
5 câmeras × 4 Mbps (1080p H.264 encode) = 20 Mbps upload estádio → cloud
Clientes remotos:
Citing Remoto: 1 câmera × 4 Mbps = 4 Mbps download
Analista WR: 2 câmeras × 4 Mbps = 8 Mbps download
Total download cloud: ~12 Mbps (margem confortável)
Upload necessário no estádio: mínimo 25 Mbps
Com as 3 WANs combinadas: 450 Mbps disponível ✅
BLOCO 7 — Energia e UPS
Mapa de Consumo
Equipamento Consumo Qtd Total
PISTON Server (PC) 400W 1 400W
Switch Gerenciável (PoE) 65W + PoE 1 130W
Peplink Balance 310X 30W 1 30W
Roteador 5G Peplink BR1 25W 1 25W
Starlink (quando ativo) 50-75W 1 75W
Monitor operador 30W 2 60W
Total estimado ~720W
UPS Recomendado
APC Smart-UPS SRT 1500VA (1050W real)

Autonomia: ~20min a 720W de carga

Gerenciamento via software (desliga o servidor ordenadamente se necessário)
Saída endurecida (para equipamentos sensíveis)
Montagem em rack (opcional)
Câmeras: UPS separado por posição (UPS menor 600VA cada)
ou alimentação PoE via switch (se câmeras IP)
BLOCO 8 — Layout Físico da Cabine Operador
┌──────────────────────────────────────────────────────────┐
│ CABINE PISTON (2×1.5m) │
││
│ ┌────────────┐ ┌────────────┐ ┌────────────────────┐ │
│ │ Monitor 1 │ │ Monitor 2 │ │ Rack 6U │ │
│ │ Operador │ │ Multiview │ │ ┌──────────────┐ │ │
│ │ (dashboard)│ │ 5 câmeras │ │ │ Patch Panel │ │ │
│ └────────────┘ └────────────┘ │ │ SDI + Fibra │ │ │
│ │ ├──────────────┤ │ │
│ ┌────────────────────────────┐ │ │ PISTON Server│ │ │
│ │ PISTON SERVER (PC Tower) │ │ │ (PC ou 2U) │ │ │
│ │ + DeckLink 8K │ │ ├──────────────┤ │ │
│ └────────────────────────────┘ │ │ Switch GbE │ │ │
│ │ ├──────────────┤ │ │
│ ┌─────────┐ ┌──────────────┐ │ │ Peplink WAN │ │ │
│ │ Teclado │ │ Joystick PTZ │ │ ├──────────────┤ │ │
│ │ + mouse │ │ (câmeras 1-2)│ │ │ UPS │ │ │
│ └─────────┘ └──────────────┘ │ └──────────────┘ │ │
│ └────────────────────┘ │
└──────────────────────────────────────────────────────────┘
Entradas na cabine:
① 5× cabo fibra óptica (das câmeras)
② 1× cabo ethernet (internet do estádio)
 ③ 1× tomada 20A (alimentação + UPS)
Lista de Materiais (BOM) Completa

Item Especificação Qtd Finalidade

1 PC Servidor i9-13900K, 64GB RAM, 4TB NVMe 1 PISTON Server
2 Blackmagic DeckLink 8K Pro PCIe, 8x SDI 1 Captura 5 câmeras
3 NVIDIA RTX 4060 8GB VRAM 1 Hardware encode
4 Câmera PTZ SDI Sony BRC-X400 ou equiv. 3 WIDE, TIGHT, LATERAL
5 Câmera Fixa SDI Blackmagic Studio 4K Pro 2 BACK L, BACK R
6 Joystick PTZ Datavideo RMC-300A 1 Controle câmeras PTZ
7 Conversor SDI→Fibra Blackmagic Mini SDI-Fiber 5 1 por câmera
8 Conversor Fibra→SDI Blackmagic Mini Fiber-SDI 5 1 por câmera
9 Cabo fibra duplex OS2 LC/LC, 300m 1 rolo Runs de câmera
10 Patch Panel LC 12p 1U rack 1 Organização cabos
11 Switch Gerenciável PoE TP-Link TL-SG2210MP 1 LAN local
12 Access Point WiFi 6 TP-Link EAP670 2 iPads sem fio
13 Roteador Triplo WAN Peplink Balance 310X 1 Redundância internet
14 Modem 5G Dedicado Peplink BR1 Pro 5G 1 WAN 2
15 Starlink Portátil Flat High Performance 1 WAN 3 backup
16 UPS Servidor APC Smart-UPS 1500VA 1 Proteção energia
17 UPS Câmeras APC Back-UPS 600VA 5 1 por câmera
18 iPad 12.9" Apple iPad Pro M2 1 TMO
19 iPad 10.9" Apple iPad Air M1 2 HIA + Citing
20 Monitor Operador 27" 1440p 2 Dashboard + multiview
21 VPS Cloud 4vCPU, 8GB, SP region 1 Relay remoto
22 Rack 6U portátil StarTech 6U portable 1 Organização cabine
Checklist Pré-Jogo (Operador)
3h antes do KO:
□ Ligar UPS principal → servidor + rede
□ Verificar fibra: 5 câmeras com sinal verde no software
□ Confirmar WANs: fibra ✅ 5G ✅ Starlink ✅
□ Testar stream cloud: abrir URL no celular externo
□ Distribuir URL/QR Code para iPads TMO, HIA, Citing
□ Confirmar áudio árbitro na CAM 3/TV
□ Iniciar gravação
□ Confirmar espaço em disco: mínimo 1TB livre
1h antes do KO:
□ Teste de revisão completo com TMO (recortar clipe, enviar)
□ Teste de HIA com médico
□ Confirmar Citing Commission conectado (local + remoto)
□ Check latência cloud: < 5 segundos aceitável para revisão
KO:
□ Iniciar gravação contínua em todos os segmentos
□ Monitorar indicadores: CPU, disco, WANs, câmeras
Quer que eu agora detalhe o software (código Python) com base nessa infraestrutura física definida?
DA PARA USAR O MIKROTIK HEX RB750GR3 5GIGABIT 880MHZ 2 NUCLEOS, CONSEGUIMOS
UTILIZAR ESSE CARA PARA INTEGRAR PARTE DO SISTEMA

Boa pergunta. Vou analisar o que esse equipamento consegue fazer dentro da arquitetura.

Executou agente
Haiku 4.5
MikroTik hEX RB750Gr3 capabilities research
Perfeito. O hEX aguenta tudo que precisamos. Aqui está a análise completa de integração:

MikroTik hEX RB750Gr3 — Integração no Sistema PISTON

Veredicto Direto
✅ Triple WAN failover → substitui o Peplink Balance (~$800 economizados)
✅ QoS para streams RTMP/HLS → prioridade de vídeo garantida
✅ VLAN segmentação → isolamento TMO / HIA / Citing / Servidor
✅ Firewall/NAT ~1 Gbps → mais do que suficiente
✅ REST API (RouterOS v7) → Python fala direto com o roteador
✅ Scripts automáticos → reage a falhas de rede sozinho
❌ Sem PoE output → ainda precisa de switch PoE separado
❌ Sem WiFi → ainda precisa de AP separado
❌ Sem bonding real (SpeedFusion) → faz failover, não une as 3 WANs em 1 tubo
Alocação das 5 Portas
┌──────────────────────────────────────────────────────────────┐
│ MikroTik hEX RB750Gr3 │
││
│ ether1 ether2 ether3 ether4 ether5 │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │ WAN1 │ │ WAN2 │ │ WAN3 │ │PISTON│ │ LAN │ │
│ │Fibra │ │ 5G │ │Starlink │Server│ │Switch│ │
│ │Estád.│ │Router│ │ │ │direto│ │+APs │ │
│ └──┬───┘ └──┬───┘ └──┬────┘ └──┬───┘ └──┬───┘ │
└─────┼──────────┼──────────┼──────────┼───────────┼──────────┘
│││││
Fibra do Peplink Starlink PC PISTON Switch PoE
estádio BR1 Pro Flat HP (servidor) → iPads
→ WiFi AP
→ Citing
→ HIA
ether4 direto ao PISTON Server = caminho dedicado de 1 Gbps sem concorrência com clientes.
ether5 para o Switch PoE = todos os iPads, APs e dispositivos de campo.

Diagrama Atualizado Completo

CAMPO
Câmeras (5x) ──fibra──► Patch Panel SDI
│
│ BNC (< 10m)
▼
DeckLink 8K Pro
│ PCIe
▼
┌───────────────────────┐
│ PISTON SERVER (PC) │
│ Python + FFmpeg │
│ FastAPI + MediaMTX │
└───────────┬───────────┘
│ Gigabit
┌───────────▼───────────┐
│ MikroTik hEX │◄── ether1: Fibra Estádio
│ RB750Gr3 │◄── ether2: Modem 5G
│ Firewall/NAT/QoS │◄── ether3: Starlink
└───────────┬───────────┘
│ ether5
┌───────────▼───────────┐
│ Switch PoE Gigabit │
│ TP-Link TL-SG2210MP │
└──┬────┬──────┬────────┘
│││
AP TMO HIA Citing
WiFi6 iPad iPad iPad
│
Celulares / Notebooks
(árbitros, equipe)
│
───┼─── Internet (via MikroTik) ───►
Cloud VPS
(Citing Remoto / WR)
Configuração RouterOS — Triple WAN Failover
Lógica de Failover
Prioridade 1: ether1 (Fibra) — distância 1
Prioridade 2: ether2 (5G) — distância 2 (entra se fibra cair)
Prioridade 3: ether3 (Starlink) — distância 3 (entra se 5G também cair)
Verificação: ping a cada 10s para [Link] e [Link]
Se 3 pings consecutivos falham → marca WAN como DOWN → ativa próxima
Scripts RouterOS (copiáveis direto no terminal)
Verificação de saúde das WANs (Netwatch):

/tool netwatch
add host=[Link] interval=10s timeout=2s
up-script="/ip route set [find comment=wan1-route] distance=1"
down-script="/ip route set [find comment=wan1-route] distance=100"
add host=[Link] interface=ether2 interval=10s timeout=2s
up-script="/ip route set [find comment=wan2-route] distance=2"
down-script="/ip route set [find comment=wan2-route] distance=101"
add host=[Link] interface=ether3 interval=10s timeout=2s
up-script="/ip route set [find comment=wan3-route] distance=3"
down-script="/ip route set [find comment=wan3-route] distance=102"
Notificar o Python quando WAN cai (via HTTP POST para o servidor PISTON):

Dentro do down-script do Netwatch:

/tool fetch url="[Link]
http-method=post
http-data="wan=wan1&status=down"
output=none
QoS — Prioridade de Vídeo:

/ip firewall mangle

Marca pacotes RTMP (porta 1935) como prioridade máxima

add chain=prerouting protocol=tcp dst-port=1935
action=mark-packet new-packet-mark=video-rtmp passthrough=yes

Marca pacotes HLS (porta 8888) como prioridade alta

add chain=prerouting protocol=tcp dst-port=8888
action=mark-packet new-packet-mark=video-hls passthrough=yes
/queue tree
add name=video-priority parent=global packet-mark=video-rtmp
priority=1 max-limit=30M
add name=hls-stream parent=global packet-mark=video-hls
priority=2 max-limit=20M
VLANs:

/interface vlan
add name=vlan10-piston vlan-id=10 interface=ether5
add name=vlan20-clientes vlan-id=20 interface=ether5
add name=vlan30-gerencia vlan-id=30 interface=ether5
/ip address
add address=[Link]/24 interface=vlan10-piston
add address=[Link]/24 interface=vlan20-clientes
add address=[Link]/24 interface=vlan30-gerencia
Integração Python ↔ MikroTik (REST API)
O Python no servidor PISTON fala diretamente com o roteador para mostrar status no dashboard do
operador.

server/platform/[Link]
import httpx
import asyncio

class MikrotikMonitor:
def init(self, host="[Link]", user="admin", password=""):
[Link] = f"[Link]
[Link] = (user, password)

async def get_wan_status(self) -> dict:

"""Retorna status das 3 WANs em tempo real."""
async with [Link]() as client:
r = await [Link](
f"{[Link]}/interface",
auth=[Link], timeout=5
)
interfaces = [Link]()
wans = {}
for iface in interfaces:
if iface["name"] in ("ether1", "ether2", "ether3"):
wans[iface["name"]] = {
"running": [Link]("running", False),
"rx_byte": [Link]("rx-byte", 0),
"tx_byte": [Link]("tx-byte", 0),
}
return wans

async def get_active_wan(self) -> str:

"""Qual WAN está ativa agora."""
async with [Link]() as client:
r = await [Link](
f"{[Link]}/ip/route",
auth=[Link], timeout=5
)
routes = [Link]()
for route in routes:
if [Link]("dst-address") == "[Link]/0" and [Link]("active"):
return [Link]("gateway", "desconhecido")
return "nenhuma"

async def get_bandwidth(self) -> dict:

"""Upload/download atual em bps."""
async with [Link]() as client:
r = await [Link](
f"{[Link]}/interface/monitor-traffic",
auth=[Link],
json={"interface": "ether1,ether2,ether3", "once": True},
timeout=10
)
return [Link]()

async def force_failover_to(self, wan: str):

"""Força uso de WAN específica (emergência)."""
distance_map = {"ether1": 1, "ether2": 2, "ether3": 3}
# Eleva distância das outras, reduz da alvo
async with [Link]() as client:
for iface, dist in distance_map.items():
new_dist = 1 if iface == wan else 100
 await [Link](
f"{[Link]}/ip/route/[find comment~'{iface}']",
auth=[Link],
json={"distance": str(new_dist)}
)

Endpoint no FastAPI para receber alertas do MikroTik

api/routes_operator.py
from fastapi import APIRouter
from [Link] import MikrotikMonitor

router = APIRouter()
mikrotik = MikrotikMonitor()

@[Link]("/api/network/alert")
async def network_alert(wan: str, status: str):
"""Recebe POST do script RouterOS quando WAN cai."""
await event_bus.broadcast({
"type": "NETWORK_ALERT",
"wan": wan,
"status": status, # "down" | "up"
"message": f"⚠️ {[Link]()} {[Link]()} — failover automático ativo"
})
return {"ok": True}

@[Link]("/api/network/status")
async def network_status():
"""Dashboard chama isso a cada 5s para mostrar status das WANs."""
return {
"wans": await mikrotik.get_wan_status(),
"active": await mikrotik.get_active_wan(),
"bandwidth": await mikrotik.get_bandwidth()
}
Como aparece no Dashboard do Operador
┌─────────────────────────────────────────────────┐
│ REDE │
│ WAN1 Fibra ████████████ 45 Mbps ✅ ATIVA │
│ WAN2 5G ░░░░░░░░░░░░ 0 Mbps ✅ STANDBY │
│ WAN3 Starlink░░░░░░░░░░░░ 0 Mbps ✅ STANDBY │
││
│ Upload cloud: ████░░░░ 22 Mbps / 50 Mbps │
└─────────────────────────────────────────────────┘
Hardware Revisado com o MikroTik
Item Antes (com Peplink) Agora (com MikroTik)
Roteador principal Peplink Balance 310X (~$800) MikroTik hEX RB750Gr3 (~$60)
Modem 5G Peplink BR1 Pro 5G (~$500) Modem 5G USB + MikroTik ou [Link] AXT1800 (~$100)
Triple WAN failover ✅ SpeedFusion (bonding) ✅ RouterOS (failover)
QoS vídeo ✅ ✅
API Python ✅ ✅
Economia total — ~$1.100
Switch PoE TP-Link TL-SG2210MP Mantém igual
WiFi AP TP-Link EAP670 Mantém igual
Única perda real: O Peplink faz bonding real (une 3 WANs em 1 tubo mais gordo). O MikroTik faz
failover (usa 1 por vez, troca quando cai). Para TMO, failover é suficiente — o que importa é não cair,
não ter mais banda somada.

Checklist de Configuração do MikroTik no Dia

□ Resetar para configuração limpa (/system reset-configuration)
□ Definir senha forte de admin
□ Aplicar script de triple WAN (ether1/2/3)
□ Aplicar regras QoS (prioridade RTMP/HLS)
□ Criar VLANs (10=server, 20=clientes, 30=gerência)
□ Habilitar REST API (/ip service enable www-ssl)
□ Testar failover: desligar cabo ether1, confirmar ether2 assume em < 15s
□ Testar notificação Python: confirmar alerta aparece no dashboard
□ Configurar endereço IP fixo para PISTON Server (ether4)
O MikroTik entra como gateway de rede inteligente, integrado ao Python via REST API, substituindo
um equipamento 15x mais caro. Quer que eu agora escreva o código Python completo da Fase 1
(motor de vídeo + ingestão das câmeras)?