RTMP, SRT หรือ WHIP: เลือกโปรโตคอลส่งสัญญาณเข้าแบบไหนดี

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

ความผิดพลาดที่ดูเหมือนไม่มีอะไรเกิดขึ้น

URL สำหรับส่งสัญญาณเข้า (ingest) แบบ SRT จะมี streamid หน้าตาแบบนี้: #!::r=live/sk_srt_…,m=publish อักขระเหล่านี้ — #, !, :, , — คือตัวที่คนรอบคอบมักเข้ารหัสแบบเปอร์เซ็นต์ (percent-encode) จนเป็นนิสัย อย่าทำแบบนั้น ไลบรารี SRT ไม่ถอดรหัส streamid แต่ส่งไบต์ตามตัวอักษรไปยังเซิร์ฟเวอร์ตรง ๆ ดังนั้น streamid ที่ถูกเข้ารหัสจะไปถึงในฐานะ ชื่อ สตรีมที่ขึ้นต้นด้วย %23 เซิร์ฟเวอร์จะมองการเชื่อมต่อนั้นเป็นคำขอรับชม ไม่ใช่การเผยแพร่ และจะไม่มีอะไรแจ้งให้คุณรู้เลย ตัวเข้ารหัส (encoder) ของคุณแสดงว่าเชื่อมต่อปกติ การ์ดสตรีมแสดงว่าไม่มีสัญญาณ และไม่มีข้อผิดพลาดที่ไหนเลย

วาง URL ของ SRT ให้ตรงตามที่ API ส่งกลับมาทุกตัวอักษร dcast ส่งค่านี้ในรูปแบบตามตัวอักษรที่พร้อมเผยแพร่ไว้ที่ data.ingest.srt ใน GET /api/v1/streams/:id และส่งค่าเดียวกันไว้ที่ data.ingest.srtDisplay ซึ่งมีไว้เป็นชื่อแทน (alias) สำหรับการเชื่อมต่อระบบรุ่นเก่าเท่านั้น จะใช้ค่าไหนก็วางลงในตัวเข้ารหัสได้ทันทีโดยไม่ต้องแก้อะไร

dcast รับอะไรได้บ้าง

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

ชื่อโฮสต์คือ a.dcast.pro เสมอ — จุดเข้าของพูลกำหนดเส้นทาง ไม่ใช่ชื่อเซิร์ฟเวอร์เครื่องใดเครื่องหนึ่ง เราตั้งใจทำแบบนี้ เพื่อให้ที่อยู่ที่คุณตั้งค่าไว้ครั้งเดียวยังใช้ได้ต่อไป แม้สตรีมจะไปลงที่เครื่องอื่น

RTMP: ตัวที่ใช้ได้เสมอ

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

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

ถ้าตัวเข้ารหัสของคุณต้องการเซิร์ฟเวอร์และคีย์แยกกัน ให้แบ่ง URL ที่เครื่องหมายทับตัวสุดท้าย: เซิร์ฟเวอร์ rtmp://a.dcast.pro/live คีย์ sk_rtmp_… (คีย์สตรีมจะขึ้นต้นด้วยชื่อโปรโตคอลที่ใช้สร้างการ์ด — sk_rtmp_, sk_srt_, sk_webrtc_ — ดังนั้นคีย์ที่คุณวางต้องตรงกับประตูที่คุณกำลังเคาะ)

SRT: ตัวสำหรับเครือข่ายแย่ ๆ

SRT มีไว้สำหรับกรณีที่ RTMP รับมือได้ไม่ดี — ลิงก์ที่แพ็กเก็ตหายและคุณแก้ไม่ได้ ซึ่งในทางปฏิบัติก็คือเครือข่ายมือถือ Wi-Fi สาธารณะตามสถานที่จัดงาน และทุกอย่างที่ต้องส่งข้ามระยะทางไกล

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

บัฟเฟอร์นั้นคือพารามิเตอร์ latency ซึ่งกำหนดเป็นมิลลิวินาที URL ที่ dcast ออกให้ตั้งไว้ที่ 500 ms และคุณเพิ่มได้สูงสุดถึง 7000 การแลกเปลี่ยนนี้ตรงไปตรงมาและไม่มีการตั้งค่าวิเศษใด ๆ: ค่าที่สูงขึ้นทนการสูญหายที่หนักขึ้นได้ และเพิ่มความหน่วงเท่ากับค่านั้นพอดี ถ้าสตรีมของคุณแพ็กเก็ตหาย ให้เพิ่มค่า

การลดให้ต่ำกว่า 500 คือสิ่งเดียวที่จะไม่ได้ผล และควรรู้เหตุผลไว้ก่อนดีกว่าไปเจอเอง ฝั่งรับสัญญาณของเราประกาศค่า 500 ms ของตัวเอง และการเชื่อมต่อ SRT จะตกลงใช้ค่าที่มากกว่าระหว่างสองฝั่ง — ตัวเข้ารหัสที่ขอ 80 ms จึงยังได้ 500 อยู่ดี ตัวเลขนี้คือค่าต่ำสุด ไม่ใช่แค่ค่าเริ่มต้น

ยังมีการตั้งค่า SRT อีกสองอย่างที่ควรรู้ โหมด — dcast ออก URL แบบ caller หมายความว่าตัวเข้ารหัสของคุณเป็นฝ่ายเปิดการเชื่อมต่อออกไปข้างนอก ซึ่งใช้ได้จากหลังเราเตอร์โดยไม่ต้องทำ port forwarding ส่วน listener และ rendezvous มีไว้สำหรับระบบที่จำเป็นต้องใช้ และ passphrase — SRT เข้ารหัสลิงก์ได้ ถ้าคุณตั้งไว้ ต้องยาวอย่างน้อยสิบตัวอักษร

WHIP: ตัวที่มาจากเบราว์เซอร์

WHIP คือวิธีที่แหล่งสัญญาณ WebRTC ใช้เผยแพร่ แทนที่จะใช้ URL ของสตรีม คุณส่ง SDP offer ไปยัง endpoint HTTPS แล้วการเชื่อมต่อแบบ peer จะถูกสร้างขึ้น dcast ส่ง endpoint นี้กลับมาพร้อมกับตัวอื่น ๆ บนการ์ดสตรีม

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

ข้อจำกัดของมันคือ WebRTC ใช้งานได้ยากกว่าการส่งแบบ TCP มันไวต่อเครือข่ายที่มีข้อจำกัดมากกว่า และตัวเข้ารหัสแบบฮาร์ดแวร์รองรับได้ไม่ทั่วถึงเท่า RTMP

โปรโตคอลที่คุณเลือกไม่เปลี่ยนภาพของคุณ

ส่วนนี้ช่วยให้หลายคนไม่ต้องทดสอบอีกมาก ไม่ว่าสตรีมของคุณจะมาด้วยโปรโตคอลไหน มันจะถูกแปลงให้อยู่ในรูปแบบภายในแบบเดียวกันก่อนขั้นตอนอื่นใด และขั้นบันไดการเข้ารหัส (encoding ladder) ที่ทำงานต่อจากนั้นก็เหมือนกันทุกประการ ขั้นเดียวกัน เพดานบิตเรตเดียวกัน ระยะห่าง keyframe 2 วินาทีเท่ากัน เซกเมนต์ 4 วินาทีที่มีสอง keyframe ต่อเซกเมนต์เหมือนกัน

แปลว่า: สตรีม SRT กับสตรีม RTMP ที่ส่งแหล่งสัญญาณเดียวกันด้วยบิตเรตเดียวกันจะได้ผลลัพธ์เหมือนกัน การเลือก SRT ไม่ได้ทำให้ภาพดีขึ้น และการเลือก RTMP ก็ไม่ได้ทำให้ภาพแย่ลง เลือกตามพฤติกรรมของเครือข่ายของคุณ ซึ่งเป็นสิ่งเดียวที่ตัวเลือกนี้มีผลจริง ๆ

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

อย่าประกอบ URL สำหรับส่งสัญญาณเข้าด้วยมือ

ที่อยู่สำหรับส่งสัญญาณเข้าทุกอันที่ dcast ให้คุณ ออกโดย API สำหรับการ์ดสตรีมใบใดใบหนึ่งโดยเฉพาะ และทุกส่วนของมันมีหน้าที่ของตัวเอง GET /api/v1/streams/:id ส่งทั้งหมดกลับมาพร้อมกันใน data.ingest และวิธีทำงานที่ถูกต้องคือคัดลอกจากตรงนั้นทุกครั้ง แทนที่จะเก็บ URL ไว้ในเอกสารแล้วไปแก้คีย์ในนั้น

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

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

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

การเข้ารหัสลิงก์

SRT เข้ารหัสสตรีมระหว่างตัวเข้ารหัสของคุณกับเราได้ด้วย passphrase ควรเปิดใช้ทุกครั้งที่ลิงก์ผ่านเครือข่ายที่คุณควบคุมไม่ได้ — Wi-Fi สำหรับแขกของสถานที่จัดงาน โรงแรม อัปลิงก์ที่ใช้ร่วมกันในงานประชุม — เพราะบนเครือข่ายแบบนั้น สัญญาณที่คุณส่งเข้ามาคือสิ่งเดียวที่คุณทำใหม่ไม่ได้จริง ๆ ถ้ามีใครมารบกวน

passphrase ต้องยาวอย่างน้อยสิบตัวอักษร ตั้งค่าเดียวกันทั้งสองฝั่ง ถ้าไม่ตรงกัน การจับมือ (handshake) จะล้มเหลวแทนที่จะลดระดับลง ซึ่งเป็นพฤติกรรมที่คุณต้องการ เพราะการถอยกลับไปเป็นแบบไม่เข้ารหัสอย่างเงียบ ๆ จะแย่กว่าการถูกปฏิเสธ

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

สรุปการเลือกในย่อหน้าเดียว

ถ้าเครือข่ายของคุณเป็นสายแลนในอาคารที่คุณควบคุมได้ ใช้ RTMP ถ้าคุณใช้เน็ตมือถือ Wi-Fi ของสถานที่จัดงาน หรือส่งข้ามทวีป ใช้ SRT แล้วเพิ่มค่าความหน่วงจนสตรีมสะอาด ถ้าแหล่งสัญญาณของคุณคือเว็บเบราว์เซอร์ ใช้ WHIP ถ้าเนื้อหามีอยู่แล้วในรูปสตรีมที่อื่น ใช้ HTTP pull แล้วให้เราดึงมาเอง แทนที่จะรีสตรีมด้วยมือ สี่ประโยคนี้ครอบคลุมเกือบทุกกรณีจริง

ทดสอบการส่งสัญญาณเข้าก่อนวันงาน

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

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

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

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