srt
v1.5.4
เกี่ยวกับ รฟท. | คุณสมบัติ | เริ่มต้นใช้งาน | คำแนะนำในการสร้าง | แอพและเครื่องมือตัวอย่าง | มีส่วนร่วม | ใบอนุญาต | ข่าวประชาสัมพันธ์
Secure Trusted Transport (SRT) เป็นโปรโตคอลการรับส่งสำหรับการสตรีมวิดีโอสดและเสียงที่มีความหน่วงต่ำเป็นพิเศษ (ย่อยวินาที) รวมถึงการถ่ายโอนข้อมูลจำนวนมากทั่วไป 1 SRT มีให้บริการในรูปแบบเทคโนโลยีโอเพ่นซอร์สพร้อมโค้ดบน GitHub, Internet Draft ที่เผยแพร่ และชุมชนผู้ใช้ SRT ที่กำลังเติบโต
SRT ถูกนำไปใช้กับจุดสิ้นสุดการสนับสนุนและการเผยแพร่โดยเป็นส่วนหนึ่งของเวิร์กโฟลว์สตรีมวิดีโอเพื่อส่งมอบวิดีโอคุณภาพดีที่สุดและมีเวลาแฝงต่ำที่สุดตลอดเวลา
| ปลอดภัย | เข้ารหัสสตรีมวิดีโอ |
| เชื่อถือ ได้ | กู้คืนจากการสูญเสียแพ็คเก็ตอย่างรุนแรง |
| ขนส่ง | ปรับให้เข้ากับสภาพเครือข่ายที่เปลี่ยนแปลงแบบไดนามิก |
ในการกำหนดค่าสตรีมมิงแบบสด โปรโตคอล SRT จะรักษาเวลาแฝงตั้งแต่ต้นทางถึงปลายทางคงที่ ซึ่งช่วยให้สามารถสร้างลักษณะสัญญาณของสตรีมสดขึ้นใหม่บนฝั่งผู้รับ ช่วยลดความจำเป็นในการบัฟเฟอร์ เนื่องจากแพ็กเก็ตถูกสตรีมจากต้นทางไปยังปลายทาง SRT จะตรวจจับและปรับให้เข้ากับสภาพเครือข่ายแบบเรียลไทม์ระหว่างจุดปลายทั้งสอง ช่วยชดเชยความกระวนกระวายใจและความผันผวนของแบนด์วิธอันเนื่องมาจากความแออัดของเครือข่ายที่มีเสียงดัง
SRT ใช้การเข้ารหัส AES เพื่อปกป้องเพย์โหลดของสตรีมมีเดีย และนำเสนอกลไกการกู้คืนข้อผิดพลาดต่างๆ เพื่อลดการสูญเสียแพ็กเก็ตซึ่งเป็นเรื่องปกติของการเชื่อมต่ออินเทอร์เน็ต ซึ่งใช้ Automatic Repeat reQuest (ARQ) เป็นวิธีการหลัก ด้วย ARQ เมื่อผู้รับตรวจพบว่ามีแพ็กเก็ตหายไป จะส่งการแจ้งเตือนไปยังผู้ส่งเพื่อขอให้ส่งแพ็กเก็ตที่หายไปอีกครั้ง การแก้ไขข้อผิดพลาดไปข้างหน้า (FEC) และการเชื่อมต่อการเชื่อมต่อ ซึ่งเพิ่มการป้องกันสตรีมที่ราบรื่นและการเฟลโอเวอร์แบบ Hitless ก็ได้รับการสนับสนุนจากโปรโตคอลเช่นกัน
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับโปรโตคอล โปรดสมัครสมาชิกบล็อก Innovation Labs ที่
หากต้องการถามคำถาม เข้าร่วมการสนทนาในช่อง #การพัฒนา บน 
- คลิกที่ปุ่ม ► เพื่อขยายคำอธิบายคุณสมบัติ
ไม่ว่าเครือข่ายของคุณจะไม่น่าเชื่อถือเพียงใด SRT ก็สามารถกู้คืนจากแพ็กเก็ตที่สูญหายและความกระวนกระวายใจได้ ทำให้มั่นใจในความสมบูรณ์และคุณภาพของสตรีมวิดีโอของคุณ
การแก้ไขข้อผิดพลาดในการสตรีมของ SRT สามารถกำหนดค่าได้เพื่อรองรับเงื่อนไขการใช้งานของผู้ใช้ ด้วยการใช้ประโยชน์จากการพัฒนาการสื่อสาร IP แบบเรียลไทม์เพื่อขยายแนวปฏิบัติในการกู้คืนข้อผิดพลาดของเครือข่ายแบบดั้งเดิม SRT มอบสื่อที่มีความหน่วงต่ำกว่า TCP/IP อย่างมาก ขณะเดียวกันก็ให้ความเร็วในการส่ง UDP พร้อมความน่าเชื่อถือที่ดีขึ้นอย่างมาก
แตกต่างจากโปรโตคอลการสตรีมอื่นๆ ที่รองรับเฉพาะรูปแบบวิดีโอและเสียงบางรูปแบบ SRT ไม่เชื่อเรื่องเพย์โหลด เนื่องจาก SRT ทำงานที่ระดับการขนส่งผ่านเครือข่าย โดยทำหน้าที่เป็นตัวห่อหุ้มเนื้อหาของคุณจึงสามารถขนส่งรูปแบบวิดีโอ ตัวแปลงสัญญาณ ความละเอียด หรืออัตราเฟรมทุกประเภท
กระบวนการจับมือที่ใช้โดย SRT รองรับการเชื่อมต่อขาออกโดยไม่มีความเสี่ยงและอันตรายที่อาจเกิดขึ้นจากการเปิดพอร์ตภายนอกแบบถาวรในไฟร์วอลล์ ดังนั้นจึงรักษานโยบายความปลอดภัย LAN ขององค์กรและลดความจำเป็นในการแทรกแซงด้านไอที
ด้วยการใช้การเข้ารหัส AES 128/192/256 บิตที่ได้รับความไว้วางใจจากรัฐบาลและองค์กรต่างๆ ทั่วโลก SRT ช่วยให้มั่นใจได้ว่าเนื้อหาที่มีคุณค่าได้รับการปกป้องตั้งแต่ต้นทางถึงปลายทางตั้งแต่การสนับสนุนไปจนถึงการเผยแพร่ เพื่อไม่ให้ฝ่ายที่ไม่ได้รับอนุญาตสามารถรับฟังได้
SRT 1.4 เห็นการแนะนำ API ตัวกรองแพ็คเก็ต กลไกนี้ช่วยให้การประมวลผลแบบกำหนดเองสามารถดำเนินการบนแพ็กเก็ตเครือข่ายทางฝั่งผู้ส่งก่อนที่จะส่ง และบนฝั่งผู้รับเมื่อได้รับจากเครือข่ายแล้ว API ช่วยให้ผู้ใช้สามารถเขียนปลั๊กอินของตนเองได้ จึงขยายขีดความสามารถของโปรโตคอล SRT ให้ดียิ่งขึ้นไปอีกด้วยการกรองแพ็กเก็ตที่แตกต่างกันทุกประเภท ผู้ใช้สามารถจัดการข้อมูลตัวกรองแพ็คเก็ตผลลัพธ์ด้วยวิธีใดก็ได้ เช่น สำหรับการเข้ารหัสแบบกำหนดเอง การตรวจสอบแพ็คเก็ต หรือการเข้าถึงข้อมูลก่อนที่จะส่ง
ปลั๊กอินแรกที่สร้างขึ้นเป็นตัวอย่างของสิ่งที่สามารถทำได้ด้วย API ตัวกรองแพ็กเก็ตมีไว้สำหรับ Forward Error Correction (FEC) ซึ่งในบางกรณีอาจให้เวลาแฝงที่ต่ำกว่าคำขอทำซ้ำอัตโนมัติ (ARQ) เล็กน้อย ปลั๊กอินนี้อนุญาตให้ใช้โหมดที่แตกต่างกันสามโหมด:
ARQ เท่านั้น – ส่งแพ็กเก็ตที่สูญหายอีกครั้ง
FEC เท่านั้น – จัดเตรียมค่าใช้จ่ายที่จำเป็นสำหรับการกู้คืน FEC ที่ฝั่งผู้รับ
FEC และ ARQ – ส่งแพ็กเก็ตที่สูญหายอีกครั้งซึ่ง FEC ไม่สามารถกู้คืนได้
เช่นเดียวกับ SMPTE-2022-7 บนเครือข่ายที่มีการจัดการ Connection Bonding เพิ่มการป้องกันสตรีมที่ราบรื่นและการเฟลโอเวอร์แบบไม่มีผลกระทบให้กับโปรโตคอล SRT เทคโนโลยีนี้อาศัยเส้นทางเครือข่าย IP มากกว่าหนึ่งเส้นทางเพื่อป้องกันการหยุดชะงักของการสตรีมวิดีโอสดในกรณีที่เครือข่ายติดขัดหรือขัดข้อง โดยรักษาความต่อเนื่องของการบริการ
ซึ่งสามารถทำได้โดยใช้กลุ่มซ็อกเก็ตที่นำมาใช้ใน SRT v1.5 แนวคิดทั่วไปของกลุ่มซ็อกเก็ตหมายถึงการมีกลุ่มที่ประกอบด้วยหลายซ็อกเก็ต โดยที่การดำเนินการหนึ่งรายการสำหรับการส่งสัญญาณข้อมูลเดียวจะถูกนำไปใช้กับกลุ่ม ซ็อกเก็ตเดี่ยวภายในกลุ่มจะเข้าควบคุมการดำเนินการนี้ และทำสิ่งที่จำเป็นเพื่อส่งสัญญาณไปยังเครื่องรับ
รองรับสองโหมด:
Broadcast - ในโหมด Broadcast ข้อมูลจะถูกส่งซ้ำซ้อนไปยังลิงก์สมาชิกทั้งหมดในกลุ่ม หากลิงก์ใดลิงก์หนึ่งล้มเหลวหรือประสบปัญหาการกระวนกระวายใจของเครือข่ายและ/หรือแพ็กเก็ตสูญหาย ข้อมูลที่ขาดหายไปจะได้รับจากลิงก์อื่นในกลุ่ม แพ็กเก็ตที่ซ้ำซ้อนจะถูกทิ้งที่ฝั่งผู้รับ
หลัก/สำรอง - ในโหมด หลัก/สำรอง จะมีการใช้ลิงก์ (หลัก) ครั้งละหนึ่งลิงก์เท่านั้นสำหรับการส่งข้อมูล ในขณะที่การเชื่อมต่ออื่นๆ (สำรอง) อยู่ในโหมดสแตนด์บายเพื่อให้แน่ใจว่าการส่งข้อมูลจะดำเนินต่อไปหากลิงก์หลักล้มเหลว เป้าหมายของโหมดหลัก/สำรองคือการระบุลิงก์ที่อาจเสียหายก่อนที่จะเกิดขึ้น จึงเป็นการให้กรอบเวลาในการสลับไปยังลิงก์สำรองอย่างราบรื่น
การควบคุมการเข้าถึงทำให้แอปพลิเคชันอัปสตรีมสามารถกำหนด Stream ID ให้กับสตรีม SRT แต่ละสตรีมได้ ด้วยการใช้ Stream ID ที่ไม่ซ้ำกัน ไม่ว่าจะสร้างขึ้นโดยอัตโนมัติหรือปรับแต่งเอง แอปพลิเคชันอัปสตรีมสามารถส่งสตรีม SRT หลายรายการไปยังที่อยู่ IP เดียวและพอร์ต UDP ผู้รับสามารถใช้รหัสสตรีมเพื่อระบุและแยกความแตกต่างระหว่างสตรีมนำเข้า ใช้วิธีการเข้าถึงด้วยรหัสผ่านของผู้ใช้ และในบางกรณียังใช้ระบบอัตโนมัติตามการตั้งชื่อรหัสสตรีมอีกด้วย ตัวอย่างเช่น การสนับสนุนสามารถส่งไปยังเวิร์กโฟลว์การผลิตวิดีโอและการตรวจสอบไปยังบริการตรวจสอบ
สำหรับผู้แพร่ภาพกระจายเสียง Stream ID เป็นกุญแจสำคัญในการแทนที่ RTMP สำหรับการนำเข้าสตรีมวิดีโอ โดยเฉพาะเนื้อหา HEVC/H.265 ไปยังบริการคลาวด์หรือ CDN ที่มีซ็อกเก็ต IP เดียว (ที่อยู่ + พอร์ต) ที่เปิดสำหรับวิดีโอขาเข้า
| SRT API | ร่างอินเทอร์เน็ต IETF | แอปตัวอย่าง |
| เอกสารอ้างอิงสำหรับไลบรารี API ของ SRT | ร่างอินเทอร์เน็ตโปรโตคอล SRT | คำแนะนำในการใช้แอปทดสอบ ( srt-live-transmit , srt-file-transmit ฯลฯ ) |
| ภาพรวมทางเทคนิคของ SRT | คู่มือการปรับใช้ SRT | ตำราอาหาร รฟท |
| ภาพรวมทางเทคนิคฉบับร่างเบื้องต้น (ที่มาของ Internet Draft) | ภาพรวมที่ครอบคลุมของโปรโตคอลพร้อมแนวทางการใช้งาน | บันทึกการพัฒนาเกี่ยวกับโปรโตคอล SRT |
| บล็อกห้องปฏิบัติการนวัตกรรม | ช่อง YouTube ของ SRTLab | หย่อน |
| บล็อกบนสื่อพร้อมบทความทางเทคนิคที่เกี่ยวข้องกับ SRT | ช่อง YouTube เทคนิคพร้อมวิดีโอที่เป็นประโยชน์ | ช่องทาง Slack เพื่อรับข่าวสารล่าสุดและถามคำถาม เข้าร่วม SRT Alliance บน Slack |
ทำไมต้อง รฟท.? - ประวัติโดยย่อและเหตุผลของ SRT โดย Marc Cymontkowski
RTMP กับ SRT: เอกสารไวท์เปเปอร์เปรียบเทียบเวลาแฝงและแบนด์วิธสูงสุด
เอกสารประกอบบน GitHub พร้อมเอกสาร SRT API การถอดรหัสคุณสมบัติ ฯลฯ
ร่างอินเทอร์เน็ตโปรโตคอล SRT: Datatracker | เวอร์ชันล่าสุด | สำเนาการทำงานล่าสุด | ที่เก็บ GitHub
ลินุกซ์ (อูบุนตู/CentOS) | หน้าต่าง | macOS | ไอโอเอส | แอนดรอยด์ | ผู้จัดการแพ็คเกจ
คอมไพเลอร์ที่สอดคล้องกับ C ++ 03 หรือสูงกว่า
CMake 2.8.12 หรือสูงกว่าเป็นระบบบิลด์
OpenSSL 1.1 เพื่อเปิดใช้งานการเข้ารหัส หรือสร้างด้วย -DENABLE_ENCRYPTION=OFF
มัลติเธรดมีให้โดยวิธีใดวิธีหนึ่งต่อไปนี้:
C++11: ไลบรารีมาตรฐาน ( std โดย -DENABLE_STDCXX_SYNC=ON ตัวเลือก CMake)
C++03: Pthreads (สำหรับระบบ POSIX ที่มีอยู่แล้วสำหรับ Windows จะมีไลบรารีพอร์ต)
Tcl 8.5 เป็นทางเลือกและใช้งานโดยสคริปต์ ./configure มิฉะนั้น ให้ใช้ CMake โดยตรง
สำหรับคำอธิบายโดยละเอียดของระบบบิลด์และตัวเลือก โปรดอ่านเอกสาร SRT Build Options
Repo ปัจจุบันมีแอปพลิเคชันตัวอย่างและตัวอย่างโค้ดที่สาธิตการใช้งาน API ไลบรารี SRT หนึ่งในนั้นคือ srt-live-transmit , srt-file-transmit และแอปพลิเคชันอื่น ๆ สามารถดูเอกสารที่เกี่ยวข้องได้ที่นี่ โปรดทราบว่าตัวอย่างทั้งหมดมีไว้เพื่อวัตถุประสงค์ในการสอน และไม่ควรใช้ในสภาพแวดล้อมการใช้งานจริง
ยูทิลิตี้ srt-xtransmit ถูกใช้อย่างแข็งขันสำหรับการทดสอบภายในและการประเมินประสิทธิภาพ ในบรรดาคุณสมบัติอื่นๆ มันสนับสนุนการสร้างเพย์โหลดจำลอง การกำหนดเส้นทางการรับส่งข้อมูล และการเชื่อมโยงการเชื่อมต่อ รายละเอียดเพิ่มเติมมีอยู่ใน repo srt-xtransmit เอง
เครื่องมือ Python ที่อาจมีประโยชน์ระหว่างการพัฒนาคือ:
srt-stats-plotting - สคริปต์ที่ออกแบบมาเพื่อพล็อตกราฟตามสถิติ SRT .csv
lib-tcpdump-processing - ไลบรารีที่ออกแบบมาเพื่อประมวลผล .pcap(ng) tcpdump หรือไฟล์ติดตาม Wireshark และแยกแพ็กเก็ต SRT ที่สนใจเพื่อการวิเคราะห์เพิ่มเติม
lib-srt-utils - ไลบรารี Python ที่มีโค้ดสนับสนุนสำหรับการรันการทดสอบ SRT ตามการกำหนดค่าการทดลอง
ใครๆ ก็ยินดีที่จะมีส่วนร่วม หากคุณตัดสินใจที่จะเข้าร่วม โปรดสละเวลาสักครู่เพื่อทบทวนหลักเกณฑ์:
คู่มือนักพัฒนา SRT
มีส่วนร่วม
การรายงานปัญหา
สำหรับข้อมูลเกี่ยวกับการสนับสนุน Internet Draft หรือส่งปัญหา โปรดไปที่ repo ต่อไปนี้ สามารถดู repo สำหรับการมีส่วนร่วมใน SRT CookBook ได้ที่นี่
โดยการบริจาครหัสให้กับโครงการ SRT คุณตกลงที่จะอนุญาตการบริจาคของคุณภายใต้ใบอนุญาต MPLv2.0
บันทึกประจำรุ่น
การกำหนดเวอร์ชัน SRT
คำว่า “การสตรีมสด” หมายถึงการส่งข้อมูลอย่างต่อเนื่อง (MPEG-TS หรือเทียบเท่า) พร้อมการจัดการเวลาแฝง การสตรีมมิงแบบสดตามการแบ่งส่วนและการส่งไฟล์ เช่น ในโปรโตคอล HTTP Live Streaming (HLS) (ตามที่อธิบายไว้ใน RFC8216) ไม่ได้เป็นส่วนหนึ่งของกรณีการใช้งานนี้ ในกรณีนี้ควรพิจารณาการส่งไฟล์ในโหมดข้อความหรือโหมดบัฟเฟอร์ ดูส่วนที่ 7 วิธีปฏิบัติที่ดีที่สุดและเคล็ดลับการกำหนดค่าสำหรับการส่งข้อมูลผ่าน SRT ของ Internet Draft เพื่อดูรายละเอียด โปรดทราบว่า SRT ไม่เชื่อเรื่องเนื้อหา ซึ่งหมายความว่าข้อมูลประเภทใดก็ตามสามารถส่งผ่านเพย์โหลดได้
