สตรีมวิดีโอและเสียง - เซิร์ฟเวอร์ไปยังไคลเอนต์เท่านั้น

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

ดังนั้น WebRTC จึงเป็นโปรเจ็กต์แบบเปิดฟรีที่ให้บริการเบราว์เซอร์และแอปพลิเคชันมือถือที่มีความสามารถในการสื่อสารแบบเรียลไทม์ (RTC) ผ่าน API แบบง่าย. เยี่ยมเลย นั่นคือ: WebRTC มีการรองรับเบราว์เซอร์ที่ค่อนข้างดี (ไม่ใช่ในทุกเบราว์เซอร์ แต่ Safari เพิ่งเริ่มรองรับเมื่อเดือนที่แล้วด้วย Safari 11) แต่ในกรณีนี้เราต้องการใช้ WebRTC ในฝั่งเซิร์ฟเวอร์ ท้ายที่สุดแล้ว เรายังคงนึกถึงการสื่อสารแบบเรียลไทม์แบบเพียร์ทูเพียร์ โดยที่หนึ่งในเพื่อนร่วมงานของเราคือเซิร์ฟเวอร์

• มีไลบรารีบางส่วนที่รวมฟังก์ชัน WebRTC ที่จะใช้ในฝั่งเซิร์ฟเวอร์ เช่น node-webrtc และ node-rtc-peer-connection

• แต่ฉันขอแนะนำให้คุณดูที่ electron-werbrtc เนื่องจากตัวอื่นๆ อาจใช้ วิธีการที่เลิกใช้แล้วหรือไม่สมบูรณ์ electronic-webrtc รันไคลเอ็นต์ Electron ที่ไม่มีส่วนหัวในพื้นหลังเพื่อใช้การใช้งาน WebRTC ในตัวของ Chromium ดังนั้นคุณควรจะสามารถเข้าถึงกล้องในเซิร์ฟเวอร์ของคุณและสร้างสตรีมเพื่อให้บริการแก่เพียร์อื่น (เบราว์เซอร์)

ทั้งหมดข้างต้นจะเป็นงานที่เกี่ยวข้องกับ WebRTC ในกรณีนี้: การสตรีมวิดีโอเพียร์ (เซิร์ฟเวอร์) - ต่อ - เพียร์ (เบราว์เซอร์)

ทีนี้มาพูดถึงกระบวนการส่งสัญญาณ สตัน และเลี้ยวกันดีกว่า

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

• งัน/เปลี่ยน: รูปแบบข้างต้นทำงานได้อย่างสมบูรณ์แบบในเครือข่ายท้องถิ่นที่แต่ละเครื่องมีที่อยู่ IP ของตัวเอง และไม่มีไฟร์วอลล์และเราเตอร์ระหว่างกัน แต่มิฉะนั้น คุณสามารถมีเพียร์ที่อยู่เบื้องหลัง NAT หรือไฟร์วอลล์ได้ จากนั้นเซิร์ฟเวอร์การส่งสัญญาณของคุณจะไม่สามารถทำให้เพียร์ทั้งสองค้นพบตัวเองได้ หากคุณมีเพียร์ที่อยู่เบื้องหลัง NAT คุณจะต้องมีเซิร์ฟเวอร์ STUN และถ้าคุณมีเพียร์ที่อยู่เบื้องหลังไฟร์วอลล์ คุณจะต้องมีเซิร์ฟเวอร์ TURN วิธีนี้ค่อนข้างง่าย แต่ฉันแค่อยากให้คุณเห็นภาพทั่วไปว่าเมื่อใดที่คุณอาจต้องใช้เซิร์ฟเวอร์ STUN/TURN

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

ตอนนี้ สำหรับสถานการณ์ของคุณ:

• ฉันคิดว่าคุณอาจไม่จำเป็นต้องใช้เซิร์ฟเวอร์ STUN/TURN และคุณไม่จำเป็นต้องใช้กระบวนการส่งสัญญาณ เนื่องจากเบราว์เซอร์ที่ควรได้รับสตรีมจากเซิร์ฟเวอร์จะรู้ที่อยู่เซิร์ฟเวอร์นั้น ใช่ไหม เพื่อให้พวกเขาสามารถสร้างการเชื่อมต่อ WebRTC กับมันได้
• แก้ไข: มีแนวโน้มว่าคุณจะต้องดำเนินการจับมือระหว่างเซิร์ฟเวอร์และไคลเอนต์ (เบราว์เซอร์) ดังนั้นนี่จะเป็นกระบวนการส่งสัญญาณ นี่ไม่ใช่ส่วนหนึ่งของ WebRTC และนี่คือสาเหตุ คุณต้องดำเนินการด้วยตัวเอง อย่างที่ฉันบอกไป มันเป็นวิธีที่เพื่อน 2 คนสามารถค้นพบกันและกันได้ แต่พวกเขายังแลกเปลี่ยนข้อมูลตามเงื่อนไขของสื่อท้องถิ่น เช่น ตัวแปลงสัญญาณ ความละเอียดที่พวกเขาสามารถจัดการได้ เป็นต้น ในกรณีของคุณ เซิร์ฟเวอร์การส่งสัญญาณของคุณอาจโฮสต์อยู่ในเซิร์ฟเวอร์เดียวกัน คุณใช้ในการ strea: คุณสามารถสร้างแอป node.js ขนาดเล็กที่ทำงานที่นั่นและจัดการกระบวนการส่งสัญญาณทั้งหมดได้อย่างง่ายดาย มันไม่ใช่เรื่องใหญ่อะไร ฉันขอแนะนำให้คุณอ่านบทความนี้ และโดยเฉพาะหัวข้อ "ฉันจะสร้างบริการส่งสัญญาณได้อย่างไร" โดยทั่วไปบทความ WebRTC ทั้งหมดจากไซต์นั้นมีประโยชน์มาก

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