หากต้องการดูสตรีม SRT ให้ตรวจทั้งการเชื่อมต่อและสื่อ
ใช้ player แบบเนทีฟเมื่อจำเป็นต้องดู feed contribution โดยตรง ใช้การเล่นในเบราว์เซอร์หลังจากแปลง feed เป็นเอาต์พุตที่เบราว์เซอร์รองรับแล้วเท่านั้น ไม่ว่ากรณีใด การเชื่อมต่อ SRT สำเร็จและภาพเล่นได้เป็นผลลัพธ์คนละเรื่อง: mode, host, พอร์ต UDP, latency, Stream ID และ passphrase เปิดเซสชัน ส่วน container, track, timestamp และ codec เป็นตัวตัดสินว่าจะถอดรหัสได้หรือไม่
หากงานคือการสร้าง ปกป้อง หรือดูแล endpoint สำหรับรับ ให้ไปที่ Callaba SRT Server คู่มือนี้เริ่มที่ฝั่งผู้รับ
เดโม SRT player สด
ทดสอบการเชื่อมต่อ SRT player
สร้างการเชื่อมต่อชั่วคราวเป็นเวลาหนึ่งชั่วโมง ส่งสตรีม SRT ไปยังที่อยู่ publisher ในโหมด Caller, โดยปล่อย Stream ID ว่างไว้ หลัง publisher เชื่อมต่อแล้ว ดูได้ใน Multiview ด้านล่าง หรือเชื่อมต่อ player เนทีฟ ไปยังที่อยู่ receiver ในโหมด Caller.
เลือก player ให้ตรงกับงาน
ffplay เหมาะสำหรับตรวจผ่าน command line อย่างรวดเร็ว เมื่อ FFmpeg ที่ติดตั้งมี SRT OBS Media Source มีประโยชน์เมื่อคุณต้องการ preview แบบกราฟิกและตั้งรายละเอียดอินพุต SRT ได้ VLC อาจเหมาะสำหรับดูในเครื่อง หากเวอร์ชันที่ติดตั้งรองรับ SRT mode ที่ต้องใช้; ตรวจเอกสารปัจจุบันของแอปและทดสอบ build นั้นโดยตรง ตัวเลือกเหล่านี้ไม่มีตัวใดทำให้ payload ที่ไม่รู้จักถอดรหัสได้
เดโมด้านบนสร้างคู่ SRT ของ Callaba ที่ใช้ได้หนึ่งชั่วโมง หลัง publisher ขาเข้าเชื่อมต่อ ระบบจะสร้าง Multiview preview ใช้ค่าที่ให้ไว้ทดสอบคู่นี้และตรวจภาพกับเสียงที่ได้ นี่เป็นเส้นทาง Callaba ชั่วคราวที่ใช้งานจริง ไม่ใช่ player สำหรับ URL SRT ภายนอกใดๆ
ลอง ffplay ก่อน
สำหรับ receiver ที่เรียก listener ที่ทราบ ให้แทนที่ placeholder ด้วย endpoint ที่คุณได้รับอนุญาตให้ใช้:
ffplay "srt://LISTENER_HOST:PORT?mode=caller"สำหรับ receiver ที่รอ caller:
ffplay "srt://0.0.0.0:PORT?mode=listener"อย่าวาง passphrase ลงใน ticket, แชต หรือประวัติ shell ที่คุณควบคุมไม่ได้ FFmpeg อธิบายตัวเลือก URL ของ SRT; OBS อธิบายขั้นตอนใช้อินพุต SRT
จับคู่ Caller และ Listener ก่อนเปลี่ยนการตั้งค่า player
รูปแบบทั่วไปเรียบง่าย: Listener รอที่พอร์ต UDP และ Caller เชื่อมต่อไปยังที่อยู่ที่เข้าถึงได้ จดบทบาททั้งสอง ตรวจ host และ port จากเครือข่ายของผู้ส่ง แล้วจึงเริ่ม player Listener สองตัวต่างก็รออยู่; Caller ที่ชี้ไปยังที่อยู่เข้าไม่ถึงจะไม่หายด้วยการตั้งค่า codec Rendezvous เป็นการตั้งค่าแยกที่ endpoint ทั้งคู่ต้องรองรับ
เมื่อเปิดการเข้ารหัส ให้ใช้ passphrase เดียวกันและการตั้งค่า key ที่เข้ากันได้ทั้งสองฝั่ง หากบริการใช้ Stream ID เพื่อเลือกสตรีม ให้คง syntax และการ escape ของมันไว้ ถือทั้งสองอย่างเป็นข้อมูลการเชื่อมต่อ: อย่าให้ secret อยู่ใน screenshot หรือรายงาน และเปรียบเทียบเซสชันที่ถูกปฏิเสธกับ endpoint log ที่มี
ตั้ง latency เพื่อการกู้คืน ไม่ใช่เพื่อรูปลักษณ์
SRT latency ให้เวลาสำหรับแพ็กเก็ตที่มาช้าและการส่งซ้ำ มันไม่ใช่ดีเลย์ glass-to-glass ทั้งหมด; การเข้ารหัส, decoder buffer, packaging และ viewer buffer ต่างเพิ่มดีเลย์ของตนเอง เริ่มจากเส้นทางที่วัดได้ แล้วเปรียบเทียบสภาวะปกติและมีปัญหา โดยดู loss, retransmission, drop และความต่อเนื่องหลังถอดรหัส
ใน URL SRT แบบ FFmpeg ค่า latency=200000 หมายถึง 200 ms เพราะค่าใช้หน่วยไมโครวินาที เป็นเพียงตัวอย่าง บันทึกค่าที่มีผลจริงของทั้งสอง endpoint และปรับตามเส้นทาง contribution ที่ใช้จริง
ตรวจ payload เมื่อเชื่อมต่อแล้วแต่ยังเล่นไม่ได้
SRT ขนส่งแพ็กเก็ต ไม่ได้สัญญาเรื่อง video codec, audio codec หรือ container MPEG-TS พบได้บ่อยสำหรับ contribution แต่ยังต้องมี programme information, timestamp และ stream ที่ player ที่เลือกถอดรหัสได้ ตรวจ endpoint เดียวกันก่อนเปลี่ยน latency อีกครั้ง:
ffprobe -v error -show_format -show_streams "srt://LISTENER_HOST:PORT?mode=caller"ดู container, codec วิดีโอและเสียง, profile, track และ timestamp เปรียบเทียบข้อเท็จจริงเหล่านี้กับการรองรับที่ player ระบุไว้
หากมี bitrate แต่หน้าจอยังดำ
| สิ่งที่เห็น | สิ่งที่ต้องตรวจต่อ |
|---|---|
| ไม่เชื่อมต่อ | บทบาท, host ที่เข้าถึงได้, พอร์ต UDP, firewall และข้อมูลเข้าถึง |
| เชื่อมต่อแล้ว แต่ไม่มีภาพหรือเสียง | รัน probe; ตรวจ programme information, codec, track และ timestamp |
| ภาพขาดเมื่อมี loss | เปรียบเทียบการวัดเส้นทางและ recovery latency ก่อนเปลี่ยน player |
การแยกเช่นนี้ช่วยไม่ให้ปัญหา payload กลายเป็นการเปลี่ยนค่าการเชื่อมต่ออย่างไม่รู้จบ
ใช้ SRT แบบเนทีฟสำหรับ contribution; ใช้เอาต์พุตเบราว์เซอร์สำหรับผู้ชม
media element มาตรฐานของเบราว์เซอร์เปิด URL srt:// โดยตรงไม่ได้ รับ contribution ก่อน แล้วเผยแพร่เอาต์พุตที่เบราว์เซอร์รองรับและทดสอบบนอุปกรณ์กับเครือข่ายที่จะใช้ดู ใช้ Multiview เป็นมุมมองยืนยันร่วมกันของ operator และ Web Player สำหรับส่งให้เบราว์เซอร์
เก็บรายการตรวจ receiver แบบสั้น
- บันทึกบทบาท endpoint, host, port, latency, นโยบาย Stream ID และสถานะการเข้ารหัส
- ยืนยันว่าเครือข่ายผู้ส่งจริงเข้าถึง receiver ได้
- ตรวจ transport ทั้งช่วงปกติและสภาวะมีปัญหาที่สำคัญต่องาน
- ยืนยันภาพที่ถอดรหัสและ programme audio บน player ที่ตั้งใจใช้
- รีสตาร์ตหนึ่งฝั่งในการทดสอบตามแผน และตรวจ operator หรือ viewer surface สุดท้ายอีกครั้ง
สำหรับรายละเอียด protocol ดู เอกสาร SRT live-transmit และ คู่มือ SRT protocol ของ Callaba
คำถามพบบ่อยเกี่ยวกับ SRT player
เบราว์เซอร์เล่น URL SRT โดยตรงได้หรือไม่?
ไม่ได้ผ่าน HTML media element มาตรฐาน รับ SRT ก่อนแล้วจึงเผยแพร่เอาต์พุตที่เบราว์เซอร์รองรับ
ทำไมการเชื่อมต่อ SRT แสดง bitrate แต่ไม่มีวิดีโอ?
เซสชันอาจทำงานได้ในขณะที่ player ถอดรหัส container, track, timestamp หรือ codec profile ไม่ได้
player ควรใช้โหมด Caller หรือ Listener?
ใช้บทบาทที่เติมเต็ม peer ที่ตกลงกันและการเข้าถึงเครือข่ายของ peer นั้น
เพิ่ม SRT latency แล้วแก้ packet loss ได้เสมอหรือไม่?
ไม่ มันให้เวลาการส่งซ้ำมากขึ้น แต่เปิด UDP ที่ถูกบล็อก ซ่อมการสูญเสีย capacity ต่อเนื่อง หรือถอดรหัส payload ที่ไม่รองรับไม่ได้
