ข้ามไปที่เนื้อหา
Callaba
ราคาเข้าสู่ระบบปรับใช้ Callaba บน AWSภูมิภาคที่แนะนำ: Thailand
การนำเข้า SRT การตรวจสอบ และการกำหนดเส้นทาง

เซิร์ฟเวอร์ Callaba SRT

เซิร์ฟเวอร์ SRT รับ จัดการ และถ่ายทอดวิดีโอสดที่มีความหน่วงต่ำผ่านเครือข่าย IP ที่ไม่สามารถคาดเดาได้ Callaba เพิ่มสถานะการเชื่อมต่อ การควบคุมการเข้าถึง และกำหนดเส้นทางฟีดเดียวกันไปยัง Multiview การบันทึก การสตรีมซ้ำ หรือ Web Player ที่ฝังได้ รันบน AWS หรือเซิร์ฟเวอร์ Linux ของคุณเอง

เปิดการสาธิต Multiview แบบสด

ต้องการรายละเอียดโปรโตคอลหรือไม่?อ่านวิธีการทำงานของเซิร์ฟเวอร์ SRT

การแสดงตัวอย่างการดำเนินงานของ SRT

ติดตามฟีดจากการเชื่อมต่อไปยังเอาต์พุต

เลือกขั้นตอนเพื่อดูว่าผู้ปฏิบัติงานสามารถตรวจสอบและควบคุมสิ่งใดใน Callaba ได้ ค่าด้านล่างแสดงให้เห็นถึงอินเทอร์เฟซ ไม่ใช่การวัดระยะไกลแบบสด

ใครบ้างที่เชื่อมต่อ

รู้จักเพียร์ก่อนที่คุณจะกำหนดเส้นทางฟีด

ดูภูมิภาคที่รายงานและ IP เพียร์สำหรับผู้เผยแพร่และผู้รับทุกรายที่เชื่อมต่อกับเซิร์ฟเวอร์ SRT

แฟรงก์เฟิร์ต เดลาแวร์203.0.113.42
การตรวจวัดระยะไกลการขนส่งแบบสด

ดูบิตเรต, RTT และการสูญเสียแพ็กเก็ต

6.2 เมกะไบต์/วินาทีRTT 42 msการสูญเสียแพ็คเก็ต 0.02%
การเชื่อมต่อที่ได้รับการอนุมัติ

ตั้งกฎแยกต่างหากสำหรับผู้จัดพิมพ์และผู้รับ

อนุญาตรหัสสตรีมและที่อยู่เพียร์ที่คุณคาดหวัง โดยมีกฎที่แตกต่างกันสำหรับผู้ที่ส่งและรับวิดีโอ

เปิดใช้งานการเข้าถึงของแขกแล้ว
ใช้ฟีดเดียวกันใน

เส้นทางขาออก

กล้องหรือสตูดิโอระยะไกลเชื่อมต่อกับ Callaba เพียงครั้งเดียว แต่ละโมดูลสามารถใช้แหล่งที่มาที่ยอมรับภายใน Callaba ได้ ดังนั้นคุณจึงไม่สร้างการนำเข้า SRT แยกกันสำหรับทุกงาน

MVRECOUTWEB
อินพุต SRT หนึ่งชุด โมดูลผลิตภัณฑ์สี่ชุด

รับฟีด SRT หนึ่งรายการ ใช้ใน Multiview, การบันทึก, การสตรีมซ้ำ และ Web Player

กล้อง ตัวเข้ารหัส หรือสตูดิโอระยะไกลของคุณเชื่อมต่อกับ Callaba เพียงครั้งเดียว เซิร์ฟเวอร์ SRT รับสตรีม แสดงความสมบูรณ์ของการขนส่ง และทำให้แหล่งข้อมูลสดเดียวกันพร้อมใช้งานสำหรับแต่ละโมดูล

เลือกแหล่งที่มา SRT หนึ่งรายการ
IN

กล้องหรือตัวเข้ารหัส

ส่งฟีด SRT ที่เข้ารหัสผ่านอินเทอร์เน็ตสาธารณะ

IN

สถานที่หรือสตูดิโอระยะไกล

นำฟีดภาคสนามหรือสตูดิโอกลับสู่การผลิต

SRT

เซิร์ฟเวอร์ Callaba SRT

รับฟีด ตรวจสอบสุขภาพ และควบคุมตำแหน่งที่จะไป

ดูบิตเรต, RTT และการสูญเสียแพ็กเก็ตตั้งกฎแยกต่างหากสำหรับผู้จัดพิมพ์และผู้รับ
คลาวด์หรือโฮสต์ด้วยตนเอง
ใช้ฟีดเดียวกันใน
MV

มัลติวิว

วางแหล่งที่มาบนวอลล์ตัวดำเนินการที่ใช้เบราว์เซอร์

REC

การบันทึก

บันทึกฟีดสดเพื่อตรวจสอบหรือนำมาใช้ซ้ำ

OUT

กำลังรีสตรีม

ส่งฟีดที่ยอมรับเดียวกันไปยังปลายทางที่กำหนดค่าไว้

WEB

เครื่องเล่นเว็บ

เผยแพร่การเล่นบนเบราว์เซอร์ จากนั้นใช้ URL ของผู้ดูที่ได้รับการยืนยันหรือฝังไว้

กล้องหรือสตูดิโอระยะไกลเชื่อมต่อกับ Callaba เพียงครั้งเดียว แต่ละโมดูลสามารถใช้แหล่งที่มาที่ยอมรับภายใน Callaba ได้ ดังนั้นคุณจึงไม่สร้างการนำเข้า SRT แยกกันสำหรับทุกงาน

ใช้สตรีม SRT ที่ได้รับในโปรแกรมควบคุม

เปลี่ยนฟีดกล้อง SRT จากสถานที่ต่างๆ ให้เป็นรายการถ่ายทอดสดรายการเดียว เลือกสตรีมที่ได้รับแต่ละรายการเป็นอินพุต Video Mixer จัดเรียงแหล่งที่มาในฉากและปรับเสียง เตรียมฉากถัดไปในหน้าตัวอย่างขณะที่รายการยังออนแอร์ จากนั้นสลับเป็น CUT หรือ FADE เผยแพร่และบันทึกผลลัพธ์จากพื้นที่ทำงานเดียวกัน ฟีดที่เสร็จแล้วยังคงสามารถรับและกำหนดเส้นทางได้โดยไม่ต้องผสม

  1. รับและตรวจสอบสตรีม SRT
  2. เลือกสตรีมที่ได้รับเป็นอินพุต AV Mixer
  3. สร้างฉากในการแสดงตัวอย่าง จากนั้นนำไปตั้งโปรแกรมด้วย CUT หรือ FADE
เปิดตัวผสมวิดีโอ
การเผยแพร่ทางสังคมอย่างต่อเนื่อง

ให้ YouTube, Facebook และ Twitch ถ่ายทอดสดในขณะที่แหล่งสัญญาณ SRT สลับ

เตรียมฟีด SRT หลักและสำรอง จากนั้นสลับระหว่างฟีด SRT ด้วยตนเองหรืออัตโนมัติที่ระดับการขนส่ง การเชื่อมต่อตัวรับสัญญาณและตัวดึงดาวน์สตรีมยังคงเชื่อมต่ออยู่ผ่านสวิตช์ ทดสอบแหล่งที่มา เครือข่าย บัฟเฟอร์ และปลายทางจริงก่อนการใช้งานจริง

เส้นทางหลักสัญญาณไม่เสถียร
แหล่ง รฟท. ที่เตรียมไว้พร้อม
SRTความล้มเหลวของแหล่งที่มา
เซสชันการเผยแพร่มีชีวิตอยู่
  • YouTubeLIVE
  • FacebookLIVE
  • TwitchLIVE

สลับต้นทางให้ทุกปลายทางถ่ายทอดสด

Callaba ย้ายไปยังเส้นทาง SRT PULL ที่ทดสอบถัดไปในขณะที่เอาต์พุต YouTube, Facebook และ Twitch ยังคงเชื่อมต่ออยู่

เลือกแหล่งที่มา รักษาการเชื่อมต่อแบบดาวน์สตรีม

ผู้ปฏิบัติงานสามารถเลือกแหล่งที่มาได้ด้วยตนเองในขณะที่การเชื่อมต่อตัวรับสัญญาณดาวน์สตรีมและตัวดึงยังคงเชื่อมต่ออยู่ สิ่งที่มาถึงภาพและเมื่อไรจะขึ้นอยู่กับฟีด เครือข่าย บัฟเฟอร์ และปลายทางที่เตรียมไว้ ทดสอบเส้นทางจริง

การสูญเสียเฟรมที่แน่นอนขึ้นอยู่กับความพร้อมของแหล่งที่มา ความเข้ากันได้ของสื่อ การบัฟเฟอร์ เงื่อนไขของเครือข่าย และการตั้งค่าการใช้งาน ทดสอบเส้นทางที่สมบูรณ์ก่อนการผลิต

ข้อกำหนดทางเทคนิค

ผลิตภัณฑ์รองรับอะไรบ้าง และต้องตรวจสอบอะไรบ้าง

พฤติกรรมที่ได้รับการสนับสนุนอยู่ข้างๆ การตรวจสอบการยอมรับในทางปฏิบัติ อินเทอร์เฟซ Callaba ที่ติดตั้งและแหล่งที่มา ปลายทาง และโปรไฟล์โครงสร้างพื้นฐานที่แท้จริงยังคงเชื่อถือได้

ผลิตภัณฑ์รองรับอะไรบ้าง และต้องตรวจสอบอะไรบ้าง
ความสามารถพฤติกรรมที่รองรับการตรวจสอบการยอมรับ
รับฟีด SRT สดเชื่อมต่อกล้อง ตัวเข้ารหัส สตูดิโอ หรือสถานที่ห่างไกลกับ Callabaโดยจะได้รับฟีด SRT แบบสด แสดงให้ผู้ให้บริการทราบถึงสถานะการเชื่อมต่อและการขนส่ง ควบคุมผู้ที่สามารถเผยแพร่หรือรับได้ และส่งวิดีโอไปยัง Multiview การบันทึก การสตรีมซ้ำ หรือการเล่น
เริ่มต้นด้วยการเรียกไปยังผู้ฟังสำหรับการทดสอบการนำเข้าที่ตรงไปตรงมา ให้เรียกใช้ Callaba ในฐานะผู้ฟัง SRT และเชื่อมต่อตัวเข้ารหัสในฐานะผู้โทรสำนักพิมพ์ที่เข้ามา: ดูบิตเรต, RTT, การสูญเสียแพ็กเก็ต, สถานะการเชื่อมต่อ, ภูมิภาค และที่อยู่เพียร์ในขณะที่ฟีดถ่ายทอดสด
ดูสุขภาพการขนส่งดูบิตเรต, RTT, การสูญเสียแพ็กเก็ต, สถานะการเชื่อมต่อ, ภูมิภาค และที่อยู่เพียร์ในขณะที่ฟีดถ่ายทอดสดการตรวจวัดระยะไกลการขนส่งแบบสด
ส่งฟีดเดียวไปยังงานหลายงานใช้แหล่งข้อมูลซ้ำใน Multiview การบันทึก การสตรีมซ้ำ หรือการเล่นฟีดที่ได้รับสามารถปรากฏใน Multiview, บันทึก, สตรีมซ้ำ หรือเล่นต่อไปยังเอาต์พุตการเล่นที่กำหนดค่าใน Callaba
มัลติวิววางแหล่งที่มาบนวอลล์ตัวดำเนินการที่ใช้เบราว์เซอร์ฟีดที่ได้รับสามารถปรากฏใน Multiview, บันทึก, สตรีมซ้ำ หรือเล่นต่อไปยังเอาต์พุตการเล่นที่กำหนดค่าใน Callaba
ให้ YouTube, Facebook และ Twitch ถ่ายทอดสดในขณะที่แหล่งสัญญาณ SRT สลับเตรียมฟีด SRT หลักและสำรอง จากนั้นสลับระหว่างฟีด SRT ด้วยตนเองหรืออัตโนมัติที่ระดับการขนส่ง การเชื่อมต่อตัวรับสัญญาณและตัวดึงดาวน์สตรีมยังคงเชื่อมต่ออยู่ผ่านสวิตช์ ทดสอบแหล่งที่มา เครือข่าย บัฟเฟอร์ และปลายทางจริงก่อนการใช้งานจริงกำหนดค่าเวิร์กโฟลว์ SRT หลักและสำรอง จากนั้นทดสอบทั้งการสลับไปใช้การสำรองข้อมูลและการกลับสู่หลักด้วยต้นทางและปลายทางจริง การสลับระดับการขนส่งจะรักษาการเชื่อมต่อตัวรับและตัวดึงแบบดาวน์สตรีม แต่ไม่ได้รับประกันว่าการสลับแบบ Hitless หรือการสูญเสียเป็นศูนย์
Continue in the product

Set it up in Callaba. Then check the full path.

You have seen what the product does. These three guides take you into the exact controls, show what to connect next, and give you a practical check before the workflow goes live.

  1. ConfigureSRT serversOpen guide
  2. ConnectSRT routesOpen guide
  3. VerifyStreams and connection accessOpen guide
การปรับใช้

รันบน AWS หรือบนเซิร์ฟเวอร์ Linux ของคุณเอง

อินเทอร์เฟซผลิตภัณฑ์ยังคงคุ้นเคยในรุ่นใดรุ่นหนึ่ง เลือกโครงสร้างพื้นฐานที่ทีมของคุณพร้อมที่จะดำเนินการ

เก็บไว้ในโครงสร้างพื้นฐานของคุณ

ติดตั้ง Callaba บน Linux เมื่อคุณต้องการพาธมีเดียและโฮสต์ภายใต้การควบคุมของคุณ

ต้องการรายละเอียดโปรโตคอลหรือไม่?

เซิร์ฟเวอร์ SRT: วิธีปรับใช้ เรียกใช้ และแก้ไขปัญหาในการผลิต

เรียนรู้ว่าเซิร์ฟเวอร์ SRT คืออะไร โหมดผู้โทร/ผู้ฟัง พอร์ต UDP เวลาแฝง รหัสสตรีม และข้อความรหัสผ่านทำงานอย่างไรสำหรับการนำเข้าวิดีโอสด

อิอูรี ปาโฮลคอฟ ผู้ก่อตั้ง Callaba

เขียนโดย Iurii Pakholkov

อัปเดตล่าสุด: 4 สิงหาคม 2026

ภาพรวมผลิตภัณฑ์ด้านบนอธิบายว่า Callaba SRT Server สามารถทำอะไรได้บ้าง คู่มือนี้เริ่มต้นที่แฮนด์ออฟของโอเปอเรเตอร์: มีการสร้างจุดสิ้นสุดแล้วและเป็นของจริง กระแส รฟท ตอนนี้ต้องเชื่อมต่อ พกพาสื่อที่ใช้งานได้ และบรรลุผลการผลิตที่ต้องการ

รฟท. ย่อมาจาก การขนส่งที่เชื่อถือได้และปลอดภัย. โดยจะใช้ UDP จากนั้นจึงเพิ่มการส่งสัญญาณซ้ำแบบเลือก หน้าต่างการกู้คืนที่ปรับได้ การเข้ารหัสเสริม บทบาทการเชื่อมต่อ และสถิติการขนส่ง การควบคุมเหล่านี้มีประโยชน์เมื่อฟีดการมีส่วนร่วมต้องข้ามอินเทอร์เน็ตสาธารณะ อัปลิงก์ของสถานที่ หรือเครือข่ายอื่นที่จะไม่สะอาดสมบูรณ์

เก็บ การมีส่วนร่วมและการบริโภค แยกจากการเล่นของผู้ชม ตำแหน่งข้อมูล SRT ยอมรับหรือเริ่มต้นเซสชันการขนส่งที่มีการควบคุม ห้องผู้เล่น CDN หรือผู้เข้าร่วมจะมาในภายหลัง เมื่อฟีดได้รับการพิสูจน์แล้ว ระบบการผลิตสามารถกำหนดเส้นทาง บันทึก แปลงรหัส สตรีมซ้ำ หรือเตรียมเอาต์พุต เช่น HLS หรือ WebRTC

คำตอบด่วนสำหรับผู้ปฏิบัติงาน

ถือว่าเซิร์ฟเวอร์ SRT เป็นจุดตรวจสอบการผลิตแรกหลังจากแหล่งที่มา รูปแบบการนำเข้าทั่วไปมี เซิร์ฟเวอร์เป็นผู้ฟัง และ ตัวเข้ารหัสเป็นผู้โทรแต่บทบาทเหล่านั้นบอกว่าใครเป็นคนเปิดการเชื่อมต่อ ไม่ใช่ว่าสื่อจะต้องเดินทางไปทางไหน การยอมรับต้องใช้เซสชันที่ต้องการ บิตเรตขาเข้า สถานะการขนส่ง ภาพและเสียงที่ถอดรหัส และเอาต์พุตถัดไป

SRT server for live video ingest Indexable diagram showing an encoder sending SRT over UDP to an SRT server, then the server routing the live feed to monitoring, recording, restreaming and playback workflows. SRT server live video ingest · UDP · caller/listener · monitoring · routing Encoder camera, OBS, vMix, FFmpeg, mobile app SRT over UDP stream ID · passphrase · latency SRT server listener endpoint receive · monitor route · protect Record HLS Restream API contribution recovery UDP workflow control
เซิร์ฟเวอร์ SRT จะได้รับฟีดการสนับสนุนก่อน การบันทึก การเล่น การสตรีมซ้ำ และการกำหนดเส้นทางเกิดขึ้นหลังจากการนำเข้า

เซิร์ฟเวอร์ SRT คืออะไร?

หนึ่ง เซิร์ฟเวอร์รฟท เป็นซอฟต์แวร์ที่เป็นเจ้าของปลายด้านหนึ่งของเซสชัน SRT อาจรอตัวเข้ารหัส เรียกจุดสิ้นสุดอื่น หรือส่งต่อฟีดต่อไป ในแง่การใช้งานจริง เป็นสถานที่ที่แหล่งข้อมูลระยะไกลกลายเป็นเซสชันที่ทีมรับสัญญาณสามารถระบุ สังเกต และส่งต่อไปยังระบบอื่นได้

การตรวจสอบการยอมรับที่เป็นประโยชน์จะแยกงานสี่งานแทนที่จะยุบงานให้เป็นสถานะ "เชื่อมต่อ" สถานะเดียว:

  • รับฟีดสด: ตัวเข้ารหัสกล้อง, OBS, vMix, FFmpeg, Larix หรือแหล่งอื่นส่งวิดีโอไปยังเซิร์ฟเวอร์
  • ปกป้องเส้นทางการสนับสนุน: SRT สามารถกู้คืนแพ็กเก็ตที่สูญหายและเข้ารหัสเซสชันการขนส่งได้
  • เปิดเผยสถิติสด: โอเปอเรเตอร์สามารถตรวจสอบบิตเรต, RTT, การสูญเสียแพ็กเก็ต, การส่งสัญญาณซ้ำ และสถานะการเชื่อมต่อ
  • ผ่านกระแสน้ำล่อง: เซิร์ฟเวอร์สามารถกำหนดเส้นทางฟีดไปยังเวิร์กโฟลว์การบันทึก การแปลงรหัส การสตรีมซ้ำ การสลับ หรือการเล่น

เมื่อลูกเรือที่อยู่ห่างไกลพูดว่า "เรากำลังส่ง" ให้ตอบพร้อมหลักฐานจากขอบเขตนี้ ยืนยันว่าเพียร์ที่คาดไว้เชื่อมต่ออยู่ สื่อนั้นยังคงมาถึง การกู้คืนเป็นไปตามเส้นทาง และตัวถอดรหัสดาวน์สตรีมสามารถใช้ฟีดได้ แต่ละคำตอบจะแยกแยะประเภทความล้มเหลวที่แตกต่างกันออกไป

เซิร์ฟเวอร์ SRT กับโปรโตคอล SRT

ที่ โปรโตคอล รฟท กำหนดวิธีที่อุปกรณ์ปลายทางสร้างและปกป้องเซสชันการขนส่ง ที่ เซิร์ฟเวอร์รฟท เป็นหนึ่งในอุปกรณ์ปลายทางที่ทำงาน โดยมีพอร์ต บทบาท นโยบายการเข้าถึง เส้นทางสื่อ และสถานะการปฏิบัติงานเป็นของตัวเอง

ภาคเรียน ความหมาย ตัวอย่าง
โปรโตคอล รฟท วิธีการขนส่งแบบ UDP ใช้เพื่อย้ายสื่อสดด้วยการกู้คืน การเข้ารหัส การควบคุมเวลาแฝง และสถิติ การเชื่อมต่อระหว่างตัวเข้ารหัสและ Callaba
เซิร์ฟเวอร์รฟท จุดสิ้นสุดการนำเข้าหรือส่งต่อที่ยอมรับเซสชัน SRT และเชื่อมต่อกับส่วนที่เหลือของเวิร์กโฟลว์ Callaba กำลังฟังฟีดสถานที่ห่างไกล

เซิร์ฟเวอร์สด SRT คืออะไร?

วลี เซิร์ฟเวอร์ถ่ายทอดสด SRT มักจะหมายความว่าจุดสิ้นสุดกำลังดำเนินเหตุการณ์ในขณะที่มันเกิดขึ้น ฟีดได้รับการยอมรับและส่งมอบให้กับการผลิต การบันทึก หรือการแจกจ่าย ในขณะที่แพ็กเก็ตที่ล่าช้ายังคงมีหน้าต่างที่จำกัดซึ่งมีประโยชน์

รูปแบบนั้นปรากฏในการมีส่วนร่วมของสถานที่ ลิงก์ระหว่างสตูดิโอกับคลาวด์ การนำเข้าตัวเข้ารหัสมือถือหรือฮาร์ดแวร์ การแฮนด์ออฟของพันธมิตร เส้นทางการสำรองข้อมูลที่เตรียมไว้ และเวิร์กโฟลว์การผลิตระยะไกล สามารถปฏิบัติตามการจัดส่งแบบหลายปลายทางได้ แต่ไม่ควรใช้เป็นข้อพิสูจน์ว่าการบริจาคที่เข้ามานั้นดี

ข้อจำกัดแบบสดทำให้เกิดการแลกเปลี่ยน เวลาแฝงต้องเหลือเวลาเพียงพอสำหรับการร้องขอและส่งคืนแพ็กเก็ตที่หายไป แต่ยังคงอยู่ในงบประมาณความล่าช้าในการผลิต ค่าที่คัดลอกจากสตูดิโอ LAN อาจสั้นเกินไปสำหรับเส้นทางเซลลูลาร์หรือระยะไกล แม้ว่าซ็อกเก็ตจะยังเชื่อมต่ออยู่ก็ตาม

เซิร์ฟเวอร์ SRT ทำงานอย่างไร

SRT ขนส่งเพย์โหลดที่เข้ารหัสแล้ว มันไม่ได้ตัดสินตัวแปลงสัญญาณของกล้องหรือซ่อมแซมแผนที่สื่อที่ไม่ถูกต้อง เส้นทางสดจำนวนมากมี MPEG-TS muxed พร้อมด้วยวิดีโอ H.264 หรือ H.265/HEVC และเสียง AAC แม้ว่าคอนเทนเนอร์และแทร็กจริงจะขึ้นอยู่กับผู้ส่งก็ตาม ตรวจสอบเพย์โหลดที่มาถึงจริงๆ แทนที่จะคิดว่าการจับมือกันของการขนส่งพิสูจน์ความเข้ากันได้ของตัวแปลงสัญญาณ

How an SRT server works Indexable workflow diagram showing source encoding, SRT transport, SRT server ingest, monitoring, routing and output formats. How an SRT server works The server receives live contribution first. Playback, recording and restreaming happen after ingest. 1. Encode H.264 / H.265 2. Send SRT caller 3. Receive SRT server listener 4. Monitor bitrate, RTT, loss 5. route recording restreaming transcoding playback
SRT มักจะแข็งแกร่งที่สุดในขั้นตอนการมีส่วนร่วมและการบริโภค จากนั้นเซิร์ฟเวอร์จะส่งกระแสข้อมูลไปยังส่วนที่เหลือของเวิร์กโฟลว์สื่อ
  1. ตัวเข้ารหัสจะสร้างสตรีมเสียงและวิดีโอสด
  2. ตัวเข้ารหัสส่งสตรีมไปยังเซิร์ฟเวอร์ SRT
  3. เซิร์ฟเวอร์ SRT รับสตรีมและติดตามความสมบูรณ์ของการเชื่อมต่อ
  4. หากแพ็กเก็ตสูญหาย SRT สามารถร้องขอการส่งสัญญาณซ้ำในขณะที่แพ็กเก็ตยังมีประโยชน์อยู่
  5. เซิร์ฟเวอร์ส่งสตรีมไปยังขั้นตอนเวิร์กโฟลว์ถัดไป: เครื่องบันทึก ตัวแปลงรหัส สตรีมซ้ำ ตัวสลับ เวิร์กโฟลว์ API หรือระบบการเล่น

โหมดผู้โทร ผู้ฟัง และนัดพบ

SRT เปิดเผยบทบาทการเชื่อมต่อสามบทบาท เลือกจากความสามารถในการเข้าถึงและข้อจำกัดของ NAT จากนั้นบันทึกตัวเลือกไว้บนปลายทางทั้งสอง ป้ายกำกับจะกำหนดวิธีการเปิดเซสชัน มันไม่ได้กำหนดทิศทางของสื่อด้วยตัวมันเอง

SRT caller listener and rendezvous modes Indexable diagram explaining SRT listener, caller and rendezvous connection modes for SRT server setup. SRT modes: caller, listener, rendezvous For cloud ingest, the most common production pattern is server as listener, encoder as caller. Listener server waits Known public IP or DNS. Known UDP port. Best first cloud setup. Caller encoder connects Starts the SRT session. Common for OBS, vMix, hardware encoders. Rendezvous both sides connect Useful in some NAT cases. Test before production. Not the first setup. Recommended first test: encoder caller → SRT server listener
สำหรับการทดสอบการนำเข้าระบบคลาวด์ครั้งแรก ให้ทำง่ายๆ: เซิร์ฟเวอร์ SRT ในโหมด Listener, แหล่งข้อมูลระยะไกลในโหมดผู้โทร
  • ผู้ฟัง: รอการเชื่อมต่อ SRT ขาเข้าบนพอร์ต UDP ที่รู้จัก นี่คือโหมดทั่วไปสำหรับเซิร์ฟเวอร์นำเข้าระบบคลาวด์หรือจุดสิ้นสุดศูนย์ข้อมูล
  • ผู้โทร: เริ่มการเชื่อมต่อกับผู้ฟัง นี่เป็นเรื่องปกติสำหรับตัวเข้ารหัสฟิลด์, OBS, vMix, FFmpeg, แอปมือถือ และแหล่งที่มาระยะไกล
  • นัดพบ: ทั้งสองฝ่ายเริ่มการเชื่อมต่อ สิ่งนี้สามารถช่วยได้ในบางกรณี NAT แต่ควรได้รับการทดสอบอย่างรอบคอบก่อนการผลิต

พอร์ตเซิร์ฟเวอร์ SRT และกฎไฟร์วอลล์

เนื่องจาก SRT ทำงานบน UDP ทุกขอบเขตการรับจะต้องอนุญาตพอร์ต UDP ที่เลือก: กลุ่มความปลอดภัยบนคลาวด์ ไฟร์วอลล์ของโฮสต์ เราเตอร์ กฎ NAT หรือนโยบายอัปสตรีม การเปิด TCP บนหมายเลขพอร์ตเดียวกันไม่ได้เปิดเส้นทาง SRT

  • เซิร์ฟเวอร์มี IP สาธารณะหรือที่อยู่เครือข่ายที่สามารถเข้าถึงได้
  • พอร์ต UDP ที่ถูกต้องเปิดอยู่
  • ตัวเข้ารหัสใช้โหมดผู้โทร/ผู้ฟังที่ถูกต้อง
  • รหัสสตรีมตรงกับกฎการกำหนดเส้นทางเซิร์ฟเวอร์ หากใช้รหัสสตรีม
  • ข้อความรหัสผ่านตรงกันทั้งสองด้าน หากเปิดใช้งานการเข้ารหัส
  • เวิร์กโฟลว์การรับจะถูกแมปกับเอาต์พุตดาวน์สตรีมที่ถูกต้อง

ใช้ป้าย "เชื่อมต่อแล้ว" ของตัวเข้ารหัสเป็นจุดเริ่มต้นของการทดสอบ ยืนยันบิตเรตขาเข้าและสถานะการขนส่งที่ฝั่งรับ จากนั้นเปิด Multiview หรือปลายทางจริง ซ็อกเก็ตที่ใช้งานได้ไม่สามารถแสดงว่ามีเสียงของโปรแกรม ประทับเวลาใช้งานได้ หรือตัวถอดรหัสดาวน์สตรีมยอมรับเพย์โหลด

เทคโนโลยี บทบาทที่ดีที่สุด หมายเหตุการปฏิบัติ SRT การสนับสนุน การนำเข้า และการขนส่งระหว่างจุดสิ้นสุดที่มีการควบคุมแบบสด ใช้เมื่อเส้นทางการสนับสนุนมีความสำคัญหรือไม่สมบูรณ์ RTMP / RTMPS การเผยแพร่ที่เรียบง่ายและการนำเข้าแพลตฟอร์มโซเชียล มักใช้หลังจากการนำเข้า SRT เพื่อพุชไปยังแพลตฟอร์มครั้งสุดท้าย HLS การเล่นภาพขนาดใหญ่บนเบราว์เซอร์ ทีวี และอุปกรณ์มือถือ โดยปกติเบราว์เซอร์ต้องใช้ HLS หรือรูปแบบการเล่นอื่น ไม่ใช่ Raw SRT WebRTC วิดีโอแบบเรียลไทม์เชิงโต้ตอบ การโทร การตอบกลับ และการมีส่วนร่วมในเสี้ยววินาที มีประโยชน์เมื่อผู้ดูหรือผู้เข้าร่วมต้องการเวลาแฝงที่ต่ำมาก NDI เครือข่ายการผลิตที่มีความหน่วงต่ำภายในสภาพแวดล้อม LAN หรือสตูดิโอที่มีการควบคุม ใช้บริดจ์ SRT/NDI เมื่อย้ายสัญญาณการผลิตระหว่างไซต์หรือเวิร์กโฟลว์บนคลาวด์

หากการตัดสินใจเกี่ยวกับการขนส่งระหว่างผู้เผยแพร่ไปยังแพลตฟอร์มโดยเฉพาะ ให้ดำเนินการต่อ รฟท กับ RTMP และทดสอบทั้งกับตัวเข้ารหัสและปลายทางเดียวกัน

วิธีการปรับใช้เซิร์ฟเวอร์ SRT

การใช้งานบนคลาวด์และการโฮสต์ด้วยตนเองมีลำดับการยอมรับเดียวกัน สร้างขอบเขตเครือข่าย เริ่มต้นคู่ปลายทางที่รู้จัก ส่งตัวแปลงสัญญาณและบิตเรตที่ต้องการ สังเกตความสมบูรณ์ของการขนส่ง และพิสูจน์เอาต์พุตที่ถอดรหัสก่อนที่จะเพิ่มเส้นทางหรือระบบอัตโนมัติ

SRT server setup checklist

A connected session is not enough. Match transport settings and verify the media payload.

SRT server setup checklist
SettingServer sideSender sideWhy it matters
Mode Listener Caller handshake
Address public IP / DNS server host reachability
Port open UDP port same port firewall
Latency recovery budget same policy jitter/loss
Stream ID route/access rule same value identity
Passphrase same key same key encryption
Codec receive + route H.264 / H.265 compatibility
Container MPEG-TS common muxed A/V stream payload format
Bitrate watch actual input below uplink stability
Audio preview + monitor AAC / source audio payload
Stats RTT, loss, retransmit uplink health diagnostics
Route record / restream source label workflow
การตั้งค่าเซิร์ฟเวอร์ SRT ต้องใช้ทั้งการตั้งค่าเครือข่ายและการตรวจสอบสื่อ การจับมือที่สะอาดไม่ได้พิสูจน์ว่าวิดีโอใช้งานได้
การตั้งค่า แนะนำให้ทำการทดสอบครั้งแรก ทำไมมันถึงสำคัญ
โหมด เซิร์ฟเวอร์เป็นผู้ฟัง ตัวเข้ารหัสเป็นผู้โทร รูปแบบการนำเข้าคลาวด์ที่ง่ายที่สุด
พอร์ต UDP เปิดพอร์ต UDP ที่จัดทำเอกสารไว้หนึ่งพอร์ตต่อฟีดนำเข้า การรับส่งข้อมูล SRT จะไม่มาถึงผ่านไฟร์วอลล์แบบปิด
เวลาแฝง เริ่มต้นที่ 200–500 มิลลิวินาทีสำหรับเส้นทางอินเทอร์เน็ตปกติ ให้เวลา SRT เพื่อกู้คืนการสูญเสียและความกระวนกระวายใจ
MPEG-TS / คอนเทนเนอร์ MPEG-TS เป็นคอนเทนเนอร์วิดีโอสดทั่วไปบน SRT เซิร์ฟเวอร์ได้รับเพย์โหลดสื่อที่มักซ์ ไม่ใช่เพียงการเชื่อมต่อการขนส่งเท่านั้น
รหัสสตรีม ใช้ค่าที่อ่านได้ เช่น event-main ช่วยกำหนดเส้นทาง ระบุ และปกป้องฟีด
ข้อความรหัสผ่าน ค่าเดียวกันกับผู้ส่งและเซิร์ฟเวอร์ การเข้ารหัสล้มเหลวหากคีย์ไม่ตรงกัน
  1. สร้างเซิร์ฟเวอร์หรืออินสแตนซ์คลาวด์ ด้วย CPU ความจุเครือข่าย และพื้นที่จัดเก็บข้อมูลที่เพียงพอสำหรับเวิร์กโฟลว์ของคุณ
  2. เปิดพอร์ต UDP ที่ต้องการ ในกลุ่มรักษาความปลอดภัยคลาวด์และไฟร์วอลล์โฮสต์
  3. สร้างผู้ฟัง SRT ที่จะรับกระแสที่เข้ามา
  4. ตั้งค่ารหัสสตรีมและกฎรหัสผ่าน หากคุณต้องการการกำหนดเส้นทางและการเข้ารหัส
  5. เชื่อมต่อตัวเข้ารหัส เป็นผู้โทร SRT และส่งสตรีมไปยังจุดสิ้นสุดของผู้ฟัง
  6. ตรวจสอบสถิติสด เช่น บิตเรต, RTT, การสูญเสียแพ็กเก็ต, การส่งสัญญาณซ้ำ และสถานะการเชื่อมต่อ
  7. กำหนดเส้นทางลำธารด้านท้ายน้ำ เพื่อการบันทึก การสตรีมซ้ำ การแปลงรหัส หรือการเล่น

วิธีใช้เซิร์ฟเวอร์ SRT ใน Callaba

ใน Callaba หน้าจอเซิร์ฟเวอร์ SRT เป็นส่วนสนับสนุนการทำงาน โดยนำบทบาทการเชื่อมต่อ สถานะผู้เผยแพร่หรือผู้รับ นโยบายการเข้าถึง หลักฐานการขนส่ง และเส้นทางต่อไปมาไว้ในขั้นตอนการทำงานของผู้ปฏิบัติงานเพียงรายเดียว ใช้ API หลังจากที่เข้าใจเวิร์กโฟลว์นั้นและสามารถทำซ้ำได้

ข้อมูลเข้าที่ยอมรับเดียวกันสามารถรองรับงานที่แตกต่างกันได้หลายงาน:

  • ตัวเข้ารหัส SRT ไปยัง Callaba จากนั้นสตรีมซ้ำไปที่ Twitch หรือ YouTube
  • OBS ไปยัง Callaba ผ่าน SRT จากนั้นบันทึกสตรีม
  • vMix ไปยัง Callaba บน SRT จากนั้นกำหนดเส้นทางฟีดไปยังปลายทางอื่น
  • แอพมือถือไปยัง Callaba ผ่าน SRT จากนั้นสตรีมซ้ำไปยังแพลตฟอร์มโซเชียล
  • สถานที่ห่างไกลไปยัง Callaba จากนั้นจัดแพ็คเกจสำหรับการเล่นเบราว์เซอร์
  • อินพุต SRT ไปยังเบราว์เซอร์ multiview, เครื่องบันทึก, การกำหนดเส้นทาง API และการนำส่งเครื่องเล่นที่ควบคุม

สิ่งที่ต้องตรวจสอบบนเซิร์ฟเวอร์ SRT

อ่านหลักฐานการขนส่งและสื่อที่ถอดรหัสร่วมกัน เคาน์เตอร์ขนส่งจะอธิบายเซสชันดังกล่าว ภาพ เสียง และปลายทางแสดงให้เห็นว่าการผลิตสามารถใช้งานได้จริงหรือไม่

สัญญาณการขนส่ง

  • สถานะการเชื่อมต่อ: เชื่อมต่อ ยกเลิกการเชื่อมต่อ เชื่อมต่อใหม่ หรือล้มเหลว
  • บิตเรตที่เข้ามา: ไม่ว่าสื่อจะยังไหลตามอัตราที่คาดหวังหรือไม่
  • RTT: เวลาไปกลับระหว่างผู้ส่งและผู้รับ
  • การสูญเสียแพ็กเก็ต: ข้อมูลจำนวนเท่าใดที่สูญหายไปบนเส้นทาง
  • การส่งสัญญาณซ้ำ: SRT ต้องกู้คืนแพ็กเก็ตที่หายไปบ่อยแค่ไหน
  • กระวนกระวายใจ: ระยะเวลาของแพ็กเก็ตจะแตกต่างกันมากน้อยเพียงใด
  • รับแรงดันบัฟเฟอร์: ไม่ว่าการเชื่อมต่อจะทำงานใกล้กับขีดจำกัดการกู้คืนมากเกินไปหรือไม่

สร้างเกณฑ์จากเส้นทาง: สังเกต RTT เป็นช่วง เปรียบเทียบการสูญเสียและเดลต้าการส่งสัญญาณใหม่ในช่วงเวลาเดียวกัน และเก็บบิตเรตที่เข้ารหัสไว้ภายในเฮดรูมของเครือข่ายที่วัดได้ เพิ่มเวลาแฝงเมื่อมีหลักฐานแสดงว่าแพ็กเก็ตที่กู้คืนได้มาถึงช้าเกินไปเท่านั้น อย่าคัดลอกเปอร์เซ็นต์สากลลงในการปรับใช้ทุกครั้ง

สัญญาณสื่อ

  • วิดีโอสีดำ วิดีโอค้าง เสียงหายไปหรือเสียงเงียบ
  • ตัวแปลงสัญญาณ อัตราเฟรม ความละเอียด หรือรูปแบบเสียงไม่ถูกต้อง
  • การประทับเวลาไม่ถูกต้อง คีย์เฟรมหายไป หรือการแมปสตรีมที่เข้ากันไม่ได้

ปัญหาเซิร์ฟเวอร์ SRT ทั่วไป

SRT server troubleshooting path Indexable troubleshooting diagram for SRT server problems: check mode, UDP port, stream ID, passphrase, latency, media payload and downstream route. Debug an SRT server in this order Do not stop at “connected.” Check transport, media and downstream route. 1. Mode caller/listener 2. UDP port open? 3. Security stream ID, key 4. Latency enough recovery? 5. Media codec, audio 6. Stats RTT, loss, bitrate 7. Output record, HLS, RTMP
ดีบักการขนส่งก่อน จากนั้นจึงวิเคราะห์เพย์โหลดสื่อ จากนั้นจึงตรวจสอบเส้นทางดาวน์สตรีม

การเชื่อมต่อ SRT ไม่เริ่มทำงาน

วางการกำหนดค่าปลายทางที่บันทึกไว้ทั้งสองรายการไว้เคียงข้างกัน ตรวจสอบบทบาท ที่อยู่ที่เข้าถึงได้ พอร์ต UDP ทุกขอบเขตไฟร์วอลล์ รหัสสตรีม และข้อความรหัสผ่าน วิธีนี้รวดเร็วและปลอดภัยกว่าการอนุมานสาเหตุจากข้อความสถานะของแอปพลิเคชันเดียว

สตรีมเชื่อมต่อแต่วิดีโอไม่เสถียร

จัดการแยกส่วนที่มองเห็นได้ให้สอดคล้องกับหลักฐาน RTT การสูญเสีย การส่งสัญญาณซ้ำ และหลักฐานแฝงจากช่วงเวลาเดียวกัน หากแพ็กเก็ตทดแทนกลับมาหลังจากช่วงระยะเวลาการกู้คืน ให้วัดอีกครั้งโดยมีเวลาแฝงมากขึ้นหรือบิตเรตน้อยลง หากลิงก์อิ่มตัวแล้ว หน้าต่างที่ใหญ่ขึ้นเพียงอย่างเดียวจะไม่สร้างแบนด์วิธ

สตรีมเชื่อมต่อแต่ไม่มีเสียง

เริ่มต้นที่ตัวเข้ารหัส: ยืนยันอุปกรณ์ที่ต้องการ มาตรวัด เค้าโครงช่องสัญญาณ และตัวแปลงสัญญาณเสียง จากนั้นตรวจสอบแทร็กที่ได้รับและการสนับสนุนตัวแปลงสัญญาณของแอปพลิเคชันถัดไป การเปลี่ยนการตั้งค่าเครือข่ายไม่สามารถกู้คืนเสียงที่ไม่เคยใส่ไว้ในเพย์โหลดได้

ฟังในเครื่องด้วย OBS, vMix, ตัวเข้ารหัสฮาร์ดแวร์ หรือเอาต์พุตอุปกรณ์ที่ได้รับการตรวจสอบก่อนที่จะสัมผัสเซิร์ฟเวอร์ เมื่อพิสูจน์เสียงต้นฉบับแล้ว ให้ติดตามแทร็กเดียวกันนั้นผ่านเครื่องรับและปลายทางโดยไม่ต้องเปลี่ยนสัญญาณทดสอบระหว่างการตรวจสอบ

สถิติการรฟท.ดูดีแต่คนดูยังมีปัญหาอยู่

เมื่อการขนส่งยังคงอยู่ในสภาพดีในระหว่างที่เกิดเหตุการณ์กับผู้ชม ให้ก้าวไปข้างหน้าผ่านการถอดรหัส การแปลงรหัส การบรรจุหีบห่อ ต้นทาง CDN และเครื่องเล่น เก็บการประทับเวลาเหตุการณ์ไว้หนึ่งรายการทั่วทั้งห่วงโซ่ เพื่อให้แต่ละทีมตรวจสอบเหตุการณ์เดียวกัน แทนที่จะเป็นอาการที่ดูคล้ายกัน

เซิร์ฟเวอร์ SRT ที่โฮสต์เองและที่ได้รับการจัดการ

เลือกการปรับใช้ตามขอบเขตการปฏิบัติงานที่ทีมของคุณเตรียมพร้อมที่จะเป็นเจ้าของ การโฮสต์ด้วยตนเองจะเก็บอินสแตนซ์ การอัพเกรด และนโยบายเครือข่ายไว้ในโครงสร้างพื้นฐานของคุณ การเปิดตัวบนคลาวด์สามารถร่นระยะเวลาการทดสอบระดับภูมิภาคครั้งแรกได้ ไม่มีตัวเลือกใดที่จะลบงานด้านความจุ การตรวจสอบ หรือการกู้คืน

ตัวเลือก ใช้เมื่อ ความเสี่ยงหลัก
เซิร์ฟเวอร์ SRT ที่โฮสต์ด้วยตนเอง คุณต้องควบคุมตำแหน่งเครือข่าย การปฏิบัติตามข้อกำหนด ลอจิกการกำหนดเส้นทาง หรือกฎการใช้งานภายในได้อย่างสมบูรณ์ ทีมของคุณเป็นเจ้าของการตรวจสอบ การปรับขนาด การอัปเดต และการดำเนินงานในแต่ละวัน
แพลตฟอร์มเวิร์กโฟลว์ SRT ที่มีการจัดการ คุณต้องเปิดใช้งานอย่างรวดเร็วและต้องการการตรวจสอบ การกำหนดเส้นทาง การบันทึก หรือการสตรีมซ้ำในที่เดียว คุณยังต้องตรวจสอบพอร์ต การตั้งค่าแหล่งที่มา รหัสสตรีม ข้อความรหัสผ่าน และเส้นทางดาวน์สตรีม

Callaba รองรับเวิร์กโฟลว์ตัวดำเนินการ SRT เดียวกันในการเปิดตัวบนคลาวด์หรือบนเซิร์ฟเวอร์ Linux ที่โฮสต์เอง พิสูจน์การนำเข้า Multiview หรือปลายทางและการบันทึกบนโครงสร้างพื้นฐานที่เลือก จากนั้นเพิ่มการกำหนดเส้นทาง การสตรีมซ้ำ การนำส่งเบราว์เซอร์ หรือการทำงานอัตโนมัติของ API เป็นขั้นตอนที่ทดสอบแยกกันได้

รายการตรวจสอบวันงานสำหรับเซิร์ฟเวอร์ SRT

  • ยืนยัน IP ของเซิร์ฟเวอร์หรือชื่อโฮสต์
  • ยืนยันว่าพอร์ต UDP เปิดอยู่
  • ยืนยันโหมดผู้โทร/ผู้ฟัง/นัดพบทั้งสองด้าน
  • ยืนยันรหัสสตรีม หากใช้
  • ยืนยันข้อความรหัสผ่านการเข้ารหัส หากใช้
  • ยืนยันบิตเรต ตัวแปลงสัญญาณ อัตราเฟรม ความละเอียด และรูปแบบเสียงที่คาดหวัง
  • เริ่มสตรีมและตรวจสอบบิตเรตที่เข้ามา
  • ตรวจสอบ RTT การสูญหายของแพ็กเก็ต การส่งสัญญาณซ้ำ และความกระวนกระวายใจ
  • ตรวจสอบวิดีโอและเสียงจริง ไม่ใช่แค่สถานะการเชื่อมต่อ
  • ยืนยันเส้นทางดาวน์สตรีม: การบันทึก การสตรีมซ้ำ การแปลงรหัส หรือการเล่น
  • ยืนยันการซิงโครไนซ์เวลา: เซิร์ฟเวอร์และตัวเข้ารหัสควรใช้ NTP หรือแหล่งเวลาอื่นที่สอดคล้องกัน เพื่อให้บันทึกและการบันทึกสามารถเชื่อมโยงกันระหว่างการแก้ไขปัญหา
  • ทดสอบเส้นทางสำรองก่อนที่กิจกรรมจะเริ่มต้น

การอ้างอิงอย่างเป็นทางการและการอ่านที่เกี่ยวข้อง

เก็บข้อกำหนดโปรโตคอลไว้ข้าง runbook และใช้คำแนะนำ Callaba ปัจจุบันสำหรับอินเทอร์เฟซและรายละเอียด API ที่สามารถเปลี่ยนแปลงได้โดยอิสระจากมาตรฐานการขนส่ง

คำตอบสั้น ๆ ก่อนที่คุณจะเปิดตัวเซิร์ฟเวอร์ SRT

เซิร์ฟเวอร์ SRT ต้องรับวิดีโอหรือไม่

ไม่ ผู้โทรและผู้ฟังอธิบายว่าใครเป็นคนเปิดการเชื่อมต่อ การออกแบบแอปพลิเคชันจะกำหนดว่าฝ่ายใดจะส่งสื่อ

เบราว์เซอร์สามารถเล่น Raw SRT URL ได้หรือไม่

โดยปกติการเล่นเบราว์เซอร์ทั่วไปจะต้องมีเอาต์พุตที่รองรับเบราว์เซอร์ เช่น HLS หรือ WebRTC เซสชัน SRT ยังคงเป็นการขนส่งเงินสมทบ

อะไรพิสูจน์ได้ว่าเซิร์ฟเวอร์ใช้งานได้?

ยืนยันเซสชันที่ต้องการ บิตเรตขาเข้า และสภาพการขนส่ง จากนั้นตรวจสอบภาพและเสียงที่ถอดรหัสใน Multiview หรือที่ปลายทาง

คำถามที่พบบ่อย

เซิร์ฟเวอร์ SRT คืออะไร?

มันเป็นจุดสิ้นสุดที่ทำงานหนึ่งในเซสชัน SRT เซิร์ฟเวอร์สามารถรอ เริ่มต้น หรือส่งต่อการเชื่อมต่อการสนับสนุน จากนั้นแสดงฟีดนั้นไปยังเวิร์กโฟลว์การผลิตที่ได้รับการควบคุม

เซิร์ฟเวอร์สด SRT คืออะไร?

เป็นจุดสิ้นสุด SRT ที่มีส่วนร่วมในขณะที่เหตุการณ์กำลังเกิดขึ้น ฟีดที่ยอมรับสามารถดำเนินการสลับ ตรวจสอบ บันทึก การแปลงรหัส การกำหนดเส้นทาง การสตรีมซ้ำ หรือเวิร์กโฟลว์การส่งผู้ชมต่อไปได้

เซิร์ฟเวอร์ SRT เหมือนกับเซิร์ฟเวอร์สตรีมมิ่งหรือไม่

ไม่ เซิร์ฟเวอร์ SRT มักจะเป็นเจ้าของเซสชันการสนับสนุนหรือรีเลย์ แพลตฟอร์มสตรีมมิ่งที่กว้างขึ้นอาจเพิ่มการควบคุมการเข้าถึง การแปลงรหัส การบันทึก การวิเคราะห์ การทำงานของ API การเล่นของผู้ดู และการส่งมอบ CDN รอบการขนส่งนั้น

เซิร์ฟเวอร์ SRT ใช้ UDP หรือไม่

ใช่. SRT ทำงานบน UDP ดังนั้นพอร์ต UDP ที่เลือกจะต้องได้รับอนุญาตผ่านกฎคลาวด์ ไฟร์วอลล์ของโฮสต์ เราเตอร์ และขอบเขตเครือข่ายการรับอื่น ๆ

เซิร์ฟเวอร์ SRT ใช้พอร์ตใด

ไม่มีพอร์ต SRT สากล เลือกพอร์ต UDP ในการกำหนดค่าอุปกรณ์ปลายทาง สงวนไว้ในนโยบายเครือข่ายที่เกี่ยวข้อง และบันทึกว่าเหตุการณ์ ฟีด หรือผู้เช่าใดเป็นเจ้าของ

เซิร์ฟเวอร์ SRT ควรเป็นผู้ฟังหรือผู้โทร?

รูปแบบการนำเข้าบนคลาวด์ทั่วไปใช้ Callaba เป็นตัวฟังและตัวเข้ารหัสเป็นตัวเรียก เนื่องจากเซิร์ฟเวอร์มีที่อยู่ที่เข้าถึงได้และพอร์ต UDP ที่รู้จัก ใช้บทบาทอื่นเมื่อ NAT จริงและการออกแบบไฟร์วอลล์ต้องการ บทบาทไม่ได้กำหนดทิศทางของสื่อ

OBS สามารถส่งไปยังเซิร์ฟเวอร์ SRT ได้หรือไม่

ใช่. กำหนดค่า OBS ด้วยตำแหน่งข้อมูล SRT และบทบาท พอร์ต และค่าความปลอดภัยที่ตรงกัน หลังจากเชื่อมต่อแล้ว ให้ตรวจสอบบิตเรตที่ได้รับ ภาพและเสียงที่ถอดรหัสแล้ว ก่อนที่จะกำหนดเส้นทางฟีดต่อไป

vMix สามารถส่งไปยังเซิร์ฟเวอร์ SRT ได้หรือไม่

ใช่. vMix สามารถส่งหรือรับ SRT การออกแบบทั่วไปอย่างหนึ่งจะส่งโปรแกรม vMix ไปยัง Callaba เพื่อตรวจสอบ บันทึก กำหนดเส้นทาง หรือการสตรีมซ้ำ โดยจะมีการตรวจสอบทั้งบทบาทของอุปกรณ์ปลายทางและสื่อที่ส่งคืนระหว่างการซ้อม

SRT ดีกว่า RTMP หรือไม่

สำหรับการสนับสนุนที่สูญเสียหรือระยะไกล SRT เสนอการกู้คืนและกรอบเวลาแฝงที่ปรับแต่งได้ซึ่ง RTMP ไม่ได้จัดเตรียมไว้ในลักษณะเดียวกัน RTMP หรือ RTMPS ยังคงเป็นเรื่องปกติสำหรับการนำส่งไปยังแพลตฟอร์มของผู้เผยแพร่ ดังนั้นระบบจำนวนมากจึงใช้ SRT อัปสตรีมและดาวน์สตรีม RTMP

เบราว์เซอร์สามารถเล่น SRT ได้โดยตรงหรือไม่

การเล่นเบราว์เซอร์ทั่วไปไม่ใช้ SRT URL แบบดิบ รับการสนับสนุนก่อน จากนั้นจึงเตรียมเอาต์พุตที่รองรับเบราว์เซอร์ เช่น HLS หรือ WebRTC

เหตุใดสตรีม SRT ของฉันจึงเชื่อมต่อแต่ไม่แสดงวิดีโอ

การจับมือกันในการขนส่งสามารถเกิดขึ้นได้แม้ว่าจะไม่มีวิดีโอที่ใช้งานได้ก็ตาม ตรวจสอบบิตเรตขาเข้า คอนเทนเนอร์ ตัวแปลงสัญญาณ การประทับเวลา คีย์เฟรม การแมปแทร็ก และตัวถอดรหัสปลายทางด้วยตัวอย่างสดเดียวกัน

ฉันจะทำให้เซิร์ฟเวอร์ SRT น่าเชื่อถือมากขึ้นได้อย่างไร

ใช้เส้นทาง UDP ที่ต้องการ ปล่อยให้เฮดรูมของแบนด์วิดท์ที่วัดได้ ขนาดเวลาแฝงจาก RTT และพฤติกรรมการสูญเสีย ตรวจสอบเพย์โหลดสื่อ ตรวจสอบเดลต้า และซักซ้อมตำแหน่งข้อมูลสำรองที่ใช้งานได้จริงก่อนเกิดเหตุการณ์

SRT มักจะมี MPEG-TS หรือไม่

บ่อยครั้งก็ใช่: เวิร์กโฟลว์ SRT แบบสดจำนวนมากมีเสียงและวิดีโอที่มิกซ์ในรูปแบบ MPEG-TS SRT เองนั้นไม่เชื่อเรื่องพระเจ้าในเนื้อหา ดังนั้นโปรดยืนยันคอนเทนเนอร์และแทร็กที่สร้างโดยผู้ส่งจริง

ฉันควรดูตัวชี้วัดเซิร์ฟเวอร์ SRT ใดก่อน

เริ่มต้นด้วยสถานะการเชื่อมต่อ บิตเรตขาเข้า RTT การส่งสัญญาณซ้ำ และเดลต้าการสูญเสียในช่วงเวลาที่ทราบ อ่านข้อมูลเหล่านี้ข้างภาพและเสียงที่ถอดรหัส จากนั้นตั้งค่าระดับการแจ้งเตือนจากตัวแปลงสัญญาณ บิตเรต ภูมิภาค และเครือข่ายที่ต้องการ แทนที่จะเป็นเปอร์เซ็นต์สากล

ต่อไปจะไปไหน.

อัปเดตล่าสุด: 4 สิงหาคม 2026

ลองกับฟีดจริง

ดูว่า Callaba เหมาะกับเวิร์กโฟลว์ SRT ของคุณหรือไม่

เปิดการสาธิต Multiview แบบสด เปิดใช้ Callaba บน AWS หรือติดตั้งบนเซิร์ฟเวอร์ Linux ของคุณเอง

ดำเนินการต่อด้วยรายละเอียด SRT ที่คุณต้องการ