Streaming Protocal คืออะไร?
Streaming Protocol คือ ชุดของกฎที่ควบคุมการเดินทาง Multimedia จากระบบสื่อสารหนึ่งไปอีกระบบหนึ่ง เพื่อให้สื่อสารในระบบเครือข่ายทำงานได้ด้วยกันทั้งระบบ ก่อนที่จะอธิบาย Streaming Protocol เราต้องพูดถึงสิ่งที่สำคัญคือ Logical Layers 7 ชั้น แต่ละชั้นทำหน้าที่ Function เฉพาะและทำงานร่วมกันได้ ชั้นล่างสุดทำหน้าที่เป็นรากฐานและแต่ละชั้นเพิ่มเติมขึ้นมาจะเพิ่มความซับซ้อนยิ่งขึ้น โดยชั้นที่ 1-3 จะอยู่ในส่วน Media Layers และชั้นที่ 4-7 เป็นส่วน Host Layers
| ลำดับชั้น | Layers | Data Unit | Protocals |
|---|---|---|---|
7 | Application | Data | HTTP, WebSocket เป็นต้น |
6 | Presentation | Data | ACSE, FTAM |
5 | Session | Data | L2TP, SMPP |
4 | Transport | Segments | TCP / UDP |
3 | Network | Packets | IP |
2 | Data Link | Frames | Ethernet, Wi-FI |
1 | Physical | Bits | 10 Base T, 802.11 |
TCP vs. UDP Streaming Protocol
Layer ของ Streaming Protocol ที่น่าสนใจคือ Transport Layer มีหน้าที่ในการส่ง Content ไปยัง Platform ปลายทาง มี 2 วิธีในการส่างผ่านคือ Transmission Control Protocol (TCP) และ User Datagrame Protocol (UDP) ความแตกต่างระกว่ง 2 แบบนี้คือ TCP บังคับให้อุปกรณ์สื่อสารสร้างการเชื่อมต่อเพื่อถ่ายโอนข้อมูล ในทางกลับกัน UDP ไม่สนใจขั้นตอนนี้
ในการใช้งานจริง UDP จะส่งข้อมูลขนาดเล็กได้เร็วกว่า TCP อย่างไรก็ตามสิ่งนี้มาพร้อมกับราคา เนื่องจากไม่มีการติดต่อกันหลายครั้งและขั้นตอนการยืนยันระหว่างอุปกรณ์จึงไม่สามารถส่งข้อมูลตามลำดับได้ ยิ่งไปกว่านั้นฝ่ายรับอาจไม่ได้รับบางข้อมูลเลย บางครั้งอาจส่งผลให้เกิดปัญหาเล็กน้อยเกี่ยวกับคุณภาพ
การเลือกใช้ Streaming Protocol
Streaming Protocol ปัจจุบันมีอยู่หลายประเภทขึ้นอยู่กับวิธีการเลือกใช้งาน ความเข้ากันได้ในการเล่น ระยะเวลา และการรับชม เช่น ผู้แพร่ภาพกระจายเสียง (Broadcasters) หลายรายใช้ RTMP เพื่อรับจากตัว Encoder ไปที่ Server จากนั้นแปลงรหัส Stream เป็น HTTP เป็นต้น Streaming Protocal มีหลายประเภทดังนี้
Streaming Protocols ที่นิยม
Streaming Protocals แบบที่นิยมเช่น RTSP และ RTMP รองรับการ Stream ที่มีใช้เวลาน้อย แต่ไม่รองรับอุปกรณ์ปลายทางทั้งหมด (เช่น IOS) แบบนี้ทำงานได้ดีที่สุดสำหรับการ Stream ไปยังผู้รับชุมกลุ่มเล็กๆ จาก Media Server
RTMP ส่งวิดีโอด้วยความเร็วใกล้เคียงกับการออกอากศทาง Cable ในเวลาเพียว 5 วินาทีส่วน RTSP/RTP เร็วกว่าในเวลาประมาณ 2 วินาที เนื่องจากมี Player เพียงไม่กี่เครื่องที่สนับสนุน Protocal เหล่านี้จึงไม่ได้รับการปรับให้เหมาะสมเพื่อการรับชมที่ดีในวงกว้าง ผู้แพร่ภาพกระจายเสียงจำนวนมากเลือกที่จะส่ง Stream สดไปยัง Media Server โดยใช้ RTMP จากนั้นแปลงรหัสเป็น HTTP สำหรับการส่งหลายอุปกรณ์
RTMP
Adobe ออกแบบ RTMP สำหรับการส่งข้อมูลวิดีโอและเสียงระหว่างเทคโนโลยีต่างๆเช่น Steaming Server และ Adobe Flash Player และใช้เวลาน้อยซึ่งใช้งานได้ดีสำหรับการถ่ายทอดสด แต่มาตรฐานแบบเปิดและการ Streamแบบปรับ Bitrate ได้ทำให้ RTMP เป็นที่นิยม RTMP Encoder ยังคงเป็นที่ต้องการสำหรับผู้ผลิต Content จำนวนมาก
- Audio Codecs: AAC, AAC-LC, HE-AAC+ v1 & v2, MP3, Speex, Opus, Vorbis
- Video Codecs: H264, VP8, VP6, Sorenson Spark®, Screen Video v1 & v2
- Playback Compatibility: ไม่รับรองอย่างกว้างขวาง (Flash Player, Adobe AIR, Player ที่เล่น RTMP ได้)
- ข้อดี: ใช้เวลาน้อยและไม่ต้องใช้ Buffer
- ข้อเสีย: ไม่ได้รับการปรับให้เหมาะสมกับคุณภาพของรับชมหรือความสามารถในการปรับขนาด
- เวลาในการตอบสนอง: 5 วินาที
RTSP/RTP
RTSP/RTP ใช้สำหรับการสนับสนุนวิดีโอซึ่งตรงข้ามกับการส่งหลายอุปกรณ์ ในขณะที่ RTSP เป็น Presentation-Layer Protocol ที่ช่วยให้ผู้ใช้สามารถสั่ง Media Server ผ่านความสามารถในการหยุดชั่วคราวและเล่นได้ แต่ RTP เป็น Transport Protocol ที่ใช้ในการย้ายข้อมูลดังกล่าว
อุปกรณ์ Android และ iOS ไม่มีโปรแกรมเล่นที่รองรับ RTSP ทำให้เป็นอีก Protocol หนึ่งที่ไม่ค่อยได้ใช้ในการเล่น ที่กล่าวว่า RTSP ยังคงเป็นมาตรฐานในสถาปัตยกรรมการเฝ้าระวังและโทรทัศน์วงจรปิด (CCTV) จำนวนมาก ทำไม? เหตุผลง่ายๆคือ การสนับสนุน RTSP ยังคงแพร่หลายในกล้อง IP)
- Audio Codecs: AAC, AAC-LC, HE-AAC+ v1 & v2, MP3, Speex, Opus, Vorbis
- Video Codecs: H.265 (preview), H.264, VP9, VP8
- Playback Compatibility: ไม่รับรองอย่างกว้างขวาง (Quicktime Player, Player ที่รองรับ RTSP/RTP, VideoLAN VLC media player, อุปกรณ์มือถือที่รองรับ 3G)
- ข้อดี: ใช้เวลาน้อยและกล้อง IP ส่วนใหญ่รองรับ
- ข้อเสีย: ไม่ใช้สำหรับการส่งวิดีโอไปยังผู้ใช้ปลายทางอีกต่อไป
- เวลาในการตอบสนอง: 2 วินาที
HTTP-Based Streaming Protocol
การ Stream ที่ใช้งานผ่าน HTTP ไม่ใช่ “Streams” ในทางเทคนิค แต่เป็นการ Dowload แบบล่วงหน้าที่ส่งผ่าน Web Servers ทั่วไป การใช้ Streaming แบบปรับ Bitrate ได้ Protocol ที่ใช้ HTTP จะมอบคุณภาพวิดีโอและประสบการณ์การรับชมที่ดีที่สุดไม่ว่าจะเชื่อมต่อ Software หรืออุปกรณ์ใดก็ตาม Protocol ที่ใช้ HTTP ที่พบมากที่สุด ได้แก่ MPEG-DASH และ HLS ของ Apple
Apple HLS
เนื่องจาก Apple เป็น Player รายใหญ่ในโลกของอุปกรณ์ที่เชื่อมต่อ Internet จึงเป็นไปตามที่ HLS Protocol ของ Apple กำหนดแนวทาง Digital Video ประการแรก Protocol รองรับ Streaming แบบปรับ Bitrate ได้ซึ่งเป็นกุญแจสำคัญในประสบการณ์ของผู้ชม ที่สำคัญกว่านั้น Stream ที่ส่งผ่าน HLS จะเล่นบนอุปกรณ์ส่วนใหญ่ซึ่งจะช่วยขยายฐานผู้ชมของคุณ
ในขณะที่การสนับสนุน HLS นั้น จำกัด เฉพาะอุปกรณ์ iOS เช่น iPhone และ iPad ในตอนแรก แต่การสนับสนุนแบบพื้นฐานได้ถูกเพิ่มเข้าไปใน Platforms ที่หลากหลาย เGoogle Chrome ทั้งหมดรวมถึงอุปกรณ์ Android, Linux, Microsoft และ MacOS สามารถเล่น Stream ที่ส่งโดยใช้ HLS
- Audio Codecs: AAC-LC, HE-AAC+ v1 & v2, xHE-AAC, Apple Lossless, FLAC
- Video Codecs: H.265, H.264
- Playback Compatibility: ดีที่สุด (Google Chrome Browser ทั้งหมด, อุปกรณ์ Android, Linux, Microsoft และ MacOS กล่องรับสัญญาณ Smart ทีวีและ Player อื่น ๆ)
- ข้อดี: ปรับ Bitrate ได้, รองรับอย่างกว้างขวาง
- ข้อเสีย: เวลาในการตอบสนองช้า
- เวลาในการตอบสนอง: เวลาในการตอบสนอง 6-30 วินาที(เวลาในการตอบสนองต่ำลงได้เมื่อปรับแต่งเท่านั้น)
Low-Latency HLS
กลางปี 2019 Apple ประกาศขยาย HLS Protocol ที่ออกแบบมาเพื่อลดเวลาในการตอบสนองลง Protocol นี้ทำได้โดยใช้การส่ง HTTP / 2 PUSH รวมกับ Media ที่สั้นกว่า ซึ่งแตกต่างจาก HLS แบบเดิม Apple Low-Latency HLS ยังไม่รองรับการ Stream แบบปรับ Bitrate ได้ แต่อยู่ในแผนงานอนาคต
- Playback Compatibility: ดีที่สุด ( Player ที่ไม่ได้รับการปรับให้เหมาะกับ Low-Latency HLS สามารถถอยกลับไปใช้ HLS แบบเดิมได้)
- ข้อดี: เวลาในการตอบสนองเร็วตรงตามแบบ HTTP
- ข้อเสีย:เนื่องจากพึ่งเกิดขึ้นใหม่ข้อมูลเลยมีอยู่จำกัด
- เวลาในการตอบสนอง: 3 วินาทีหรือน้อยกว่า
MPEG-DASH
Moving Pictures Expert Group(MPEG) ซึ่งเป็นหน่วยงานระหว่างประเทศเกี่ยวกับมาตรฐานเสียงและวิดีโอ Digital ได้พัฒนา Dynamic Adaptive Streaming ผ่าน HTTP(DASH) ซึ่งเป็นทางเลือกมาตรฐานอุตสาหกรรมสำหรับ HLS โดยทั่วไป DASH จะได้รับตัวเลือก Open-source แต่เนื่องจาก Apple มีแนวโน้มที่จะจัดลำดับความสำคัญของ Software ที่เป็นกรรมสิทธิ์สำหรับการสนับสนุน DASH
- Audio Codecs: Codec-agnostic
- Video Codecs: Codec-agnostic
- Playback Compatibility: ดี (อุปกรณ์ Android ทั้งหมด, TV หลังปี 2012 Samsung, Philips, Panasonic และ Sony ส่วนใหญ่, Browsers Chrome, Safari และ Firefox)
- ข้อดี: ผู้ให้บริการอิสระตามมาตรฐานสากลสำหรับ Bitrate แบบปรับได้
- ข้อเสีย: ไม่สนับสนุน IOS หรือ Apple TV
- เวลาในการตอบสนอง: 6-30 วินาที(เวลาในการตอบสนองต่ำลงได้เมื่อปรับแต่งเท่านั้น)
Emerging Technologies
สุดท้ายแต่ไม่ท้ายสุดเทคโนโลยีใหม่ๆ เช่น WebRTC และ SRT ได้รับการออกแบบโดยคำนึงถึงความเร็ว เช่นเดียวกับ Low-latency CMAF สำหรับ DASH และ Apple Low-Latency HLS, Protocol เหล่านี้ยังคงพัฒนาต่อไป
SRT
Open-Source Protocol นี้ได้รับการยอมรับว่าเป็นทางเลือกที่ได้รับการพิสูจน์แล้วสำหรับเทคโนโลยีการขนส่งที่เป็นกรรมสิทธิ์ซึ่งช่วยในการนำเสนอ Stream ที่เชื่อถือได้โดยไม่คำนึงถึงคุณภาพของเครือข่าย ตั้งแต่การกู้คืน Packets ที่สูญหายไปจนถึงการรักษาการกำหนดเวลา SRT ได้รับการออกแบบมาเพื่อแก้ปัญหาความท้าทายในการสนับสนุนและเผยแพร่วิดีโอผ่าน Internet
- Audio Codecs: Codec-agnostic
- Video Codecs: Codec-agnostic
- Playback Compatibility: จำกัด (ปัจจุบันใช้สำหรับการสนับสนุน)
- ข้อดี: วิดีโอคุณภาพสูงและมีความหน่วงต่ำผ่าน Network ที่ไม่ปกติ
- ข้อเสีย: การสนับสนุนการเล่นยังคงใช้งานได้
- เวลาในการตอบสนอง: 3 วินาทีหรือน้อยกว่า
WebRTC
WebRTC เป็นการรวมกันของมาตรฐาน Protocol และ JavaScript API ที่ช่วยให้สามารถสื่อสารแบบ Real-time (RTC จึงเป็นชื่อของมัน) ผู้ใช้เชื่อมต่อผ่าน Chrome, Firefox หรือ Safari สามารถสื่อสารโดยตรงผ่า Browser โดยเปิดใช้งานเวลาต่ำกว่า 500 มิลลิวินาที จากข้อมูลของ Google พบว่า 85% ของ Browser ที่ติดตั้งทั้งหมดทั่วโลกได้กลายเป็น Client สำหรับการสื่อสารแบบ Real-time บน Internet
- Audio Codecs: Opus, iSAC, iLBC
- Video Codecs: H.264, VP8, VP9
- Playback Compatibility: Chrome, Firefox, และ Safari รองรับ WebRTC ไม่ต้องลง Plugin ใดๆ
- ข้อดี: เร็วมากและใช้ Browser
- ข้อเสีย: ออกแบบมาสำหรับการประชุมทางวิดีโอและไม่สามารถปรับขนาดได้
- เวลาในการตอบสนอง: ต่ำกว่า 500 มิลลิวินาที
