Cloudflare เปิดตัว MoQ CDN สำหรับการส่งสื่อผ่าน QUIC เป็นรายแรก

 (moq.dev)
8 คะแนน โดย GN⁺ 2025-08-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Cloudflare เปิดตัว CDN ที่ใช้ Media over QUIC (MoQ) อย่างเป็นทางการเป็นรายแรก
  • MoQ เป็นมาตรฐานใหม่สำหรับ การส่งสื่อแบบเรียลไทม์ และถูกคาดหวังว่าจะมาแทน WebRTC, HLS/DASH, RTMP/SRT
  • ขณะนี้ยังอยู่ในขั้น developer preview และสามารถทดสอบได้ผ่าน public endpoint ของ Cloudflare ด้วยไคลเอนต์และไลบรารีหลายตัว
  • มี ฟีเจอร์สาธิต อย่างการถ่ายทอดสดและการรับชม รวมถึงคำบรรยายที่ขับเคลื่อนด้วย AI ให้ใช้งานบนเว็บและในไคลเอนต์ Rust
  • ฟีเจอร์สำคัญบางอย่าง เช่น การยืนยันตัวตน, การรองรับ Safari, ANNOUNCE ยังไม่ได้ถูกพัฒนาเสร็จ และนักพัฒนาที่สนใจสามารถรัน MoQ relay เองได้

Cloudflare เปิดตัว MoQ CDN รายแรกอย่างเป็นทางการ

บทนำ

  • การที่ Cloudflare เปิดตัว CDN บนมาตรฐาน Media over QUIC (MoQ) อย่างเป็นทางการ ถือเป็นสัญญาณของการเปลี่ยนแปลงครั้งใหญ่ในวงการส่งสื่อแบบเรียลไทม์
  • MoQ กำลังได้รับความสนใจในฐานะมาตรฐานยุคถัดไป ที่อาจเข้ามาแทนโปรโตคอลเดิมทั้งหมดอย่าง WebRTC, HLS/DASH, RTMP/SRT สำหรับการส่งข้อมูลสื่อสด เช่น วิดีโอและเสียงแบบเรียลไทม์
  • การเปิดตัวครั้งนี้มาในรูปแบบผลิตภัณฑ์จริง และผู้ใช้ทั่วโลกสามารถทดลองใช้งานได้โดยตรงบนเครือข่าย Anycast ทั่วโลก
  • Cloudflare จึงกลายเป็นผู้ให้บริการ MoQ CDN รายแรก และเทคโนโลยีนี้ถูกคาดว่าจะช่วยเร่งนวัตกรรมในระบบนิเวศการส่งสื่อแบบเรียลไทม์

ฟีเจอร์ที่มีให้ใช้งานในตอนนี้

  • เทคโนโลยีนี้ยังเป็น เวอร์ชันพรีวิว ดังนั้นเสถียรภาพของบริการและขอบเขตฟีเจอร์ยังมีข้อจำกัด
  • Cloudflare เปิด public endpoint ที่ relay.cloudflare.mediaoverquic.com
  • สามารถทดสอบได้ผ่านไลบรารีและไคลเอนต์โอเพนซอร์สหลายตัวดังต่อไปนี้
  • สามารถใช้เว็บเดโมและไลบรารีเพื่อ ถ่ายทอดสดและรับชมสตรีมแบบเรียลไทม์ภายในเบราว์เซอร์ ได้
  • มีการสาธิตฟังก์ชัน ประมวลผลคำบรรยายด้วย AI
    • ภายในเบราว์เซอร์มีการใช้เทคโนโลยีอย่าง [silero-vad], [whisper], [transformers.js], [onnxruntime-web], [WebGPU] เพื่อสร้างและส่งคำบรรยาย
  • รองรับทั้ง API แบบ Web Component และการใช้งานขั้นสูงผ่าน JavaScript API
  • ยังมีสภาพแวดล้อมสำหรับผู้ที่ไม่ต้องการใช้ JavaScript ผ่าน ไลบรารี Rust เช่น การนำเข้า MP4, การเชื่อมต่อกับ ffmpeg และการถ่ายทอด/รับชมผ่าน gstreamer

ฟีเจอร์ที่ยังไม่รองรับ

  • เวอร์ชันปัจจุบันรองรับเพียง subset แบบจำกัดของ Draft-07 เท่านั้น
  • ฟีเจอร์สำคัญที่ยังไม่มีในตอนนี้
    • ยังไม่รองรับการยืนยันตัวตนของสตรีม: แต่ละสตรีมต้องตั้งชื่อที่คาดเดาได้ยากด้วยตนเอง
    • ยังไม่รองรับ ANNOUNCE: จึงยังไม่มีความสามารถในการตรวจจับการเริ่ม/จบของสตรีม
    • ยังไม่รองรับเบราว์เซอร์ Safari: ไม่สามารถใช้งานร่วมกับ Safari ได้เนื่องจากปัญหาการรองรับ WebTransport
    • ยังปรับแต่งไม่สมบูรณ์: ประสบการณ์ผู้ใช้และส่วนอื่น ๆ จะค่อย ๆ ปรับปรุงต่อไป
  • หากต้องการ ก็สามารถติดตั้งอินสแตนซ์ moq-relay เองเพื่อใช้งานฟีเจอร์ขั้นสูงได้
    • กำลังพัฒนาฟีเจอร์เพิ่มเติม เช่น การยืนยันตัวตนแบบ JWT และ WebSocket fallback สำหรับ Safari/TCP
    • ยังสามารถใช้ terraform module เพื่อสร้างเครือข่าย CDN แบบทั่วโลกได้

ความหมายของ MoQ และ Cloudflare

  • งานมาตรฐาน MoQ ดำเนินมาแล้ว นานกว่า 3 ปี และกว่าจะได้รับการยอมรับใช้อย่างแพร่หลายทั่วโลกน่าจะยังต้องใช้เวลาอีกพอสมควร
  • Cloudflare ตัดสินใจอย่างกล้าหาญด้วยการ ออกผลิตภัณฑ์จริงอย่างรวดเร็วก่อน RFC จะถูกรับรอง เพื่อดึง feedback ที่ใช้งานได้จริงจากนักพัฒนาและผู้ใช้
  • เทคโนโลยี MoQ มีศักยภาพในการเข้ามาแทนโปรโตคอลสื่อเดิมอย่าง WebRTC/HLS/RTMP
  • แม้การพูดคุยเรื่องร่างมาตรฐานและปัญหาในโค้ดยังคงดำเนินต่อไป แต่ประสบการณ์จากการใช้งานจริงจะช่วยผลักดันพัฒนาการของมาตรฐานได้อย่างมาก
  • ในอนาคต ผู้เล่นอย่าง Google, Akamai และ Fastly อาจจำเป็นต้องนำโค้ดนี้ไปใช้งานบนเครือข่ายและเซิร์ฟเวอร์ของตนเอง เพื่อทำความเข้าใจความต้องการที่แท้จริงของตลาดการส่งสื่อบน MoQ

แผนต่อไปและชุมชน

  • ยังมีงานอีกมากในการนำ WebRTC และโปรโตคอลเดิม มาสร้างใหม่ด้วย API สมัยใหม่บนเว็บ
  • ไม่ควรตัดสินศักยภาพของ MoQ ทั้งหมดจากประสิทธิภาพหรือฟีเจอร์ในระยะเริ่มต้นนี้ และควรเข้ามา ทดสอบและให้ feedback อย่างจริงจัง
  • ในชุมชน (Discord) มีผู้เข้าร่วมใช้งานอยู่มากกว่า 900 คน และสามารถเข้าไปถามคำถามหรือเสนอความร่วมมือได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-08-24
ความคิดเห็นจาก Hacker News

  • ผมลองทดสอบเดโมที่ https://moq.dev/publish/ แล้ว รู้สึกลื่นมาก น่าประทับใจสุด ๆ และขอบคุณสำหรับเทคโนโลยีที่ยอดเยี่ยมนี้ด้วย พอลองดูเดโม Big Buck Bunny ที่ https://moq.dev/watch/?name=bbb บนมือถือ กลับเจออาการมีเส้นสีดำแนวนอนขึ้นเยอะมาก (แปลกตรงที่บนพีซีที่ใช้ Wi‑Fi เดียวกันกลับปกติ) เลยสงสัยว่าเกี่ยวกับขนาดบัฟเฟอร์หรือเปล่า อยากถามว่าสามารถเพิ่มบัฟเฟอร์ฝั่งไคลเอนต์ได้ไหม หรือต้องตั้งค่าฝั่งเซิร์ฟเวอร์ และก็ขอบคุณที่ไม่ลืมใส่ South Korea ไว้ในแผนที่ CDN "global"

    • สงสัยว่ามันใช้ได้เฉพาะบน Chrome หรือเปล่า บน Firefox Android ขึ้นแค่ว่าเป็นเบราว์เซอร์ที่ยังไม่รองรับ

    • ผมไม่แน่ใจเรื่องอาการเส้นสีดำแนวนอนนะ เราเรนเดอร์ด้วยองค์ประกอบ <canvas> แล้วปรับขนาดให้ตรงกับขนาดวิดีโอต้นฉบับ จากนั้นก็ใช้ CSS ปรับขนาดอีกครั้งให้พอดีกับหน้าต่าง

    • บน OnePlus Ten ถ้าเล่นด้วย Chrome จะเห็นเส้นดำกะพริบบ่อย โดยเฉพาะเป็นแนวจากด้านบนของหน้าจอลงไปทางขวาล่าง เลยสงสัยว่าอาจเป็นอาการรีเฟรชอาร์ติแฟกต์ของจอ (rolling shutter effect) ก็ได้

    • เพราะในหน้านั้นพูดถึง Rust code กับ WASM เยอะ เลยมีโอกาสว่าปัญหาอาจมาจาก CPU ของมือถือรัน WASM ได้ไม่เร็วพอ บน Samsung S20 ของผมไม่เห็นเส้นดำเลย

    • ผมทดสอบบน mac book air m4 กับการเชื่อมต่อ 600mbps แล้ว รู้สึกว่าตอบสนองทันทีและน่าทึ่งมาก

  • ในบทความมีส่วน "ทำไมถึงควรสนใจ?" อยู่ก็จริง แต่ไม่ได้อธิบายว่า Media over QUIC ให้ประโยชน์อะไรกับผู้เผยแพร่สื่อหรือผู้ใช้ปลายทาง ซึ่งก็คือสองฝ่ายที่สำคัญที่สุดของการแลกเปลี่ยนนี้ อาจจะเป็นฝ่ายเดียวที่สำคัญด้วยซ้ำ เลยสงสัยว่าทำไมผมควรสนใจเทคโนโลยีนี้

    • เป็นความผิดผมเองครับ ผมพยายามหลีกเลี่ยงการเขียนซ้ำกับบล็อกโพสต์ก่อนหน้าเลยอธิบายไม่พอ: https://moq.dev/blog/replacing-webrtc/ และจริง ๆ แล้ว MoQ ให้ประโยชน์หลักกับนักพัฒนา เพราะมันทำให้การสเกลระบบและการเพิ่มฟีเจอร์ต่าง ๆ ง่ายขึ้นมาก ดังนั้นประโยชน์ต่อผู้ใช้จึงเป็นทางอ้อม

    • latency แบบ end-to-end (glass-to-glass) ดีขึ้นอย่างชัดเจน สาเหตุหลักคือโปรโตคอลนี้ไม่ได้เป็นแบบ request/response อีกต่อไป

  • สวัสดีครับ! ผมเป็นนักพัฒนา Cloudflare MoQ ถามมาได้เลย และขอบคุณสำหรับรางวัลด้วยนะ kixelated xD

    • มีคำอธิบายว่า "ไม่มี head-of-line blocking: ต่างจาก TCP, stream ของ QUIC เป็นอิสระต่อกัน ถ้ามี packet loss ในสตรีมหนึ่ง (เช่น แทร็กเสียง) สตรีมอื่น (เช่น แทร็กวิดีโอ) ก็จะไม่ถูกบล็อก อาการสะดุดที่เกิดตลอดใน RTMP จะหายไปด้วยสิ่งนี้" แต่ถ้าโครงสร้างเป็นแบบนี้ แล้วเกิด packet loss ในแทร็กเสียงจนวิดีโอยังเล่นต่อโดยไม่หยุด แบบนั้นเสียงกับภาพจะหลุดซิงก์กันได้ไหม ผมอาจยังเข้าใจไม่พอเพราะไม่ค่อยคุ้นกับเทคโนโลยีนี้

    • มีคำถามว่า มีแผนที่เป็นรูปธรรมเพื่อลดช่องว่างด้าน goodput ระหว่าง TCP กับ QUIC หรือไม่[1] ในงานวิจัยที่ลิงก์ไว้ระบุว่าการเปลี่ยนจาก HTTP/2 (TCP) ไปเป็น HTTP/3 (QUIC) ทำให้ video bitrate ลดลงได้มากสุด 9.8% แน่นอนว่า MoQ มีโครงสร้างสแตกต่างออกไปเล็กน้อย จึงสรุปตรง ๆ ไม่ได้ แต่ก็น่าจะมีปัญหาคล้ายกันอยู่บ้าง (ส่วนตัวช่วงหลายเดือนที่ผ่านมาผมศึกษา AF_XDP datapath ของ MsQuic เป็นส่วนหนึ่งของวิทยานิพนธ์ปริญญาโท สรุปได้ว่ารู้สึกว่า GSO/GRO เป็นทางเลือกที่ดีกว่า และ QUIC ยังต้องการ hardware offload มากกว่านี้แน่ ๆ :p)
      [1]: https://arxiv.org/pdf/2310.09423

    • มีเรื่องที่สงสัยอยู่สองสามอย่าง :)
      อยากรู้ว่า QUIC เข้าใกล้ระดับที่ใช้งานได้จริงในเบราว์เซอร์มากแค่ไหนแล้ว ทั้งฝั่งเบราว์เซอร์และอินฟราที่รองรับ จนถึงระดับที่ "มันใช้งานได้เลย"
      แล้ว QUIC จัดการปัญหา NAT อย่างไร WebRTC ต้องพึ่ง STUN/TURN เพื่อทะลุ full cone NAT โดยเฉพาะ TURN นี่แหละที่เป็นปัญหา เพราะต้องรันอินฟราเยอะมาก

    • ผมทำงานด้าน WebRTC streaming ที่ getstream.io WebRTC ตั้งค่าค่อนข้างจุกจิก แต่พอเชื่อมต่อได้แล้วก็มีข้อดีเรื่อง latency ต่ำ เลยอยากรู้ว่า MoQ หลังจากเชื่อมต่อเสร็จแล้วมีข้อดีหรือปัญหาอะไรบ้าง หรือถ้าเทียบกับ WebRTC แล้วให้ความรู้สึกต่างกันอย่างไร

    • สงสัยว่า load balancing ของ relay อยู่นอกขอบเขตของ MoQ หรือเปล่า เหมือนบทความจะไม่ได้พูดถึงส่วนนี้

  • ผมชอบโปรเจกต์นี้มาก และก็อ่านบล็อกของ kixelated เป็นบางครั้ง แถมยังติดตามบน Github อยู่ด้วย
    ก่อนอื่นเลยอยากแสดงความยินดีกับทั้ง kixelated และ Cloudflare สำหรับงานที่ยอดเยี่ยมแบบนี้
    ผมสงสัยเรื่อง live streaming แบบเรียลไทม์ โดยปกติไลฟ์หนึ่งมีคนดูพร้อมกันตั้งแต่หลักร้อยถึงหลักพัน อยากรู้ว่าใน MoQ มีแนวคิดหรือความเป็นไปได้ที่จะใช้หรือทำ multicast หรือไม่ ใน HTTP/1.1 กับ HTTP/2 ทำได้ยากเพราะเป็น TCP แต่พอ HTTP/3 ใช้ UDP แล้ว มันดูเหมือนเริ่มเป็นไอเดียที่พอเป็นจริงได้ อยากทราบว่าคิดเห็นอย่างไร รู้มาว่า Akamai กับ BBC ก็กำลังวิจัยเรื่องนี้อยู่

    • ขอบคุณครับ!
      ไม่จำเป็นต้องมี multicast! จริง ๆ แล้ว CDN ก็แทบจะเท่ากับเอา multicast มาทำที่ L7 (ชั้นแอปพลิเคชัน) อยู่แล้ว จึงไม่จำเป็นที่ router หรือ ISP จะต้องไปทำสิ่งนี้โดยตรงที่ L3 นี่แหละคือสิ่งที่ผมทำมาตลอด 5 ปีที่ Twitch
      ในทางทฤษฎี multicast จะช่วยลดทราฟฟิกได้เฉพาะช่วงจาก CDN edge ไปยัง ISP แต่กรณีแบบนั้นมักมีแค่การถ่ายทอดสดระดับมหึมาอย่าง Super Bowl ปีละครั้ง ส่วนอีเวนต์ส่วนใหญ่ไม่ได้ประโยชน์อะไร หลาย CDN ก็แก้ปัญหานี้ด้วยการนำ CDN edge ไปติดตั้งไว้ภายใน ISP อยู่แล้ว และสำหรับอีเวนต์เล็ก ๆ โอกาสที่ผู้ชมสองคนจะใช้เส้นทางเดียวกันก็น้อยมากจนแทบไม่ได้ประโยชน์
      multicast ยังมีปัญหาอื่นอีก เช่น congestion control และ encryption ซึ่งยิ่งยากขึ้นไปอีกเมื่อเป็น multicast แบบสหพันธรัฐ
      ที่ที่ multicast น่าจะให้ประโยชน์มากที่สุดคือ P2P แต่ในระบบนิเวศ CDN ขนาดใหญ่คงนำไปใช้จริงได้ยาก
      WebRTC ก็เหมาะกับ multicast มากที่สุดเหมือนกัน และยังใช้ RTP (ซึ่งเดิมออกแบบมาสำหรับ multicast) แต่ในทางปฏิบัติก็แทบไม่มีความสนใจเรื่องรองรับ multicast
      อย่างไรก็ดี มีข่าวลือว่า Google ใช้ multicast ภายในเครือข่ายของตัวเองสำหรับบริการ Meet ก็เป็นไปได้เหมือนกัน

  • ลิงก์ "just announced" นี้ดีมากแม้สำหรับคนที่ไม่รู้เลยว่านี่คืออะไร: https://blog.cloudflare.com/moq/ (ตอนแรกผมเองก็พลาดไป)

    • "sub-second latency at broadcast scale" แต่ไม่ได้มี multicast จริง ๆ

    • เจอประโยคว่า "มันไม่ใช่แค่อีกหนึ่งโปรโตคอล แต่เป็นปรัชญาการออกแบบใหม่" แล้วเรดาร์ตรวจจับ AI ในหัวผมก็ทำงานทันที

  • สงสัยว่า MOQ จัดการเรื่องความละเอียดเวลาสลับไปใช้โหมดกู้คืนความล้มเหลว (failback) และ graceful degradation อย่างไร แล้วก็ยังมีปัญหาที่บน zed ต่อให้เปิดเต็มหน้าจอแล้วภาพก็ยังไม่เต็มจอด้วย

  • ผมเป็นผู้ใช้ Firefox และอยากแชร์ไว้เผื่อใครที่เข้าเว็บไซต์ซึ่งโฮสต์บน Cloudflare และใช้ HTTP/3 จะได้ระวังไว้:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1979683

    • ดูเหมือนอาจจะเป็นปัญหา happy eyeballs ไหมนะ? ผมจะลองส่งต่อให้คนที่รู้เรื่องกว่านี้

    • อยากรู้ว่าคุณใช้ตัวแก้ชื่อ DNS over HTTPS (DoH) ภายในเบราว์เซอร์อยู่หรือเปล่า เพราะส่วนตัวผมยังทำอาการนี้ให้เกิดซ้ำไม่ได้ ผมใช้ DoH กับ 1.1.1.1 อยู่
      ผมรู้สึกว่าทั้ง Chrome และ Firefox ใช้งาน HTTP/3 ได้สม่ำเสมอกว่าตอนใช้ตัวแก้ชื่อ DoH แทน system DNS เพราะตอนใช้ system resolver มักดึง HTTPS DNS record มาไม่ได้อย่างสม่ำเสมอ (หรือไม่ได้เลย)
      การรองรับ HTTP/3 ของเซิร์ฟเวอร์จะทำงานได้ก็ต่อเมื่อเบราว์เซอร์รับรู้ผ่าน HTTPS DNS record หรือไม่ก็ผ่าน Alt-Svc header ที่แคชไว้จาก HTTP/2/1.1 ก่อนหน้าเท่านั้น และเบราว์เซอร์ก็มักจะชอบ reuse การเชื่อมต่อที่เปิดอยู่แล้ว เลยไม่ค่อยสร้างการเชื่อมต่อใหม่
      Alt-Svc header เองก็แคชได้ไม่ค่อยสม่ำเสมอ โดยเฉพาะบน Firefox
      เรื่องที่ทำให้ซับซ้อนขึ้นไปอีกคือ ถ้าเบราว์เซอร์ โดยเฉพาะ Chrome สะสมความล้มเหลวในการเชื่อมต่อมากพอ มันจะปิดการรองรับ HTTP/3 ไปเลย ตอนผมใช้ Wi‑Fi มหาวิทยาลัย เจอการบล็อก UDP บ่อยและไม่สม่ำเสมอ จนทำให้เกิดอาการนี้ และหลังจากนั้นแม้กลับบ้าน HTTP/3 ก็ยังไม่ทำงาน วิธีแก้เดียวคือไปที่ chrome://flags แล้วเปิด QUIC เองด้วยมือ ถึงแม้ค่าเริ่มต้นจะโชว์ว่า "enabled by default" แต่สถานะจริงของเบราว์เซอร์อาจไม่ใช่แบบนั้น Firefox ก็มีพฤติกรรมยอมแพ้ต่อ HTTP/3 คล้ายกัน แต่ไม่ดื้อเท่า Chrome เลยไม่ค่อยเป็นปัญหาใหญ่
      ถ้าอยากดีบักเพิ่ม ลองเช็กว่า EncryptedClientHello (ECH) ทำงานหรือไม่ที่ https://tls-ech.dev เพราะอันนี้ใช้เฉพาะ HTTPS record สำหรับ ECH key จึงช่วยแยกปัญหาได้
      ต่อมาคือใช้ตัวตรวจ HTTP/3 ของ Fastly (https://http3.is) เพื่อตรวจว่ากำลังพึ่ง Alt-Svc negotiation อย่างเดียวหรือไม่
      หน้าเทสต์ของ Cloudflare (https://cloudflare-quic.com) ใช้ทั้ง HTTPS DNS record และ Alt-Svc ดังนั้นถ้าจับ HTTP/3 ได้ทันที ก็แปลว่าการแปลความ HTTPS record ทำงานปกติ
      ถ้ามีผลทดสอบบอกกลับมาจะดีมาก ปัญหาของ Firefox ที่ไม่สม่ำเสมอในแต่ละคนก็น่าจะเพราะมีตัวแปรหลากหลายแบบนี้นี่แหละ
      (สิ่งที่ผมอยากแจ้งกับคนของ Cloudflare คือ https://cloudflare-quic.com/favicon.ico น่าจะตั้งค่าผิดอะไรบางอย่าง และภาพ https://web.archive.org/web/20230424015350im_/https://www.cloudflare.com/img//nav/globe-lang-select-dark.svg ที่โหลดจาก Wayback Machine ทำให้หน้าเว็บโหลดช้า สำหรับรูปภาพควรใช้ลิงก์แบบ "id_" เพื่อไม่ให้โดน rewrite แล้วจะเร็วกว่า แต่ก่อนผมเคยใช้มันร่วมกับ Cloudflare Workers เพื่อกู้เว็บไซต์ชั่วคราวตอนการย้ายเซิร์ฟเวอร์พลาดมาแล้ว หรือจะใช้ต้นฉบับตรง ๆ อย่าง https://www.cloudflare.com/img/nav/globe-lang-select-dark.svg ก็ได้ ตอนนี้ไฟล์ก็ยังอยู่บนเว็บไซต์เดิม)
      ช่วงไม่กี่ปีมานี้ผมทดลองกับปัญหาการติดตั้งใช้งานและการอิมพลีเมนต์ HTTP/3 แปลก ๆ มาเยอะมาก มันเป็นโปรโตคอลที่ยอดเยี่ยม แต่ก็มีปัญหาการติดตั้งใช้งานและการอิมพลีเมนต์แปลก ๆ อยู่มากเหมือนกัน

    • สงสัยว่าเป็นเฉพาะบน macOS หรือเปล่า บน FF 141, 142 ของ Windows ผมทำให้เกิดซ้ำไม่ได้

  • เจ๋งมาก! ประทับใจกับความทุ่มเทจริง ๆ ตอนแรกผมอ่านเป็น QUIC CDN แล้วคิดว่า "ไม่น่าใช่" แต่พอไปดูละเอียดแล้วพบว่า Media over QUIC เป็นคนละแนวคิดกัน ก็น่าสนใจมาก

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

    • กำลังจะส่งเร็ว ๆ นี้ครับ แต่ยังอยากมีเวลาเก็บรายละเอียดอีกนิดก่อน

  • ถ้า "เทคโนโลยีทำงานอยู่ภายใน" ผมคิดว่าขอแค่รองรับเบราว์เซอร์หลักก็พอแล้ว (ใน caniuse ก็ยังไม่เห็นข้อมูล)
    และถ้ารองรับเอนจินเว็บวิวอย่าง Microsoft Edge WebView2 ด้วย ก็น่าจะเอาไปใช้พัฒนาได้ทันที
    แต่ในอีกด้านหนึ่ง มันจะมีความหมายจริงก็ต่อเมื่อฝั่งอย่าง OBS หรือ YouTube รองรับด้วย

    • ดังนั้น... MoQ กำลังเดินออกห่างจากการเป็นเว็บ API แบบ "กล่องดำ" ชุดใหญ่ใบเดียวเหมือน WebRTC เล็กน้อย ในมุมของเบราว์เซอร์ ประเด็นสำคัญคือการรองรับ WebTransport API
      เมื่อใช้ MoQT ร่วมกับ WebTransport ก็จะมีแนวทางใหม่ ๆ เช่น ใช้ WebCodecs เป็นตัวเล่นวิดีโอ ถ้ายอมแลกกับ latency เพิ่มขึ้นเล็กน้อย ก็สามารถเล่นผ่าน MSE พร้อมใส่ DRM ได้ด้วย
      ส่วนการให้ OBS publish ได้โดยตรงนั้น ผมก็เคยทำมาก่อนจะมาที่ Cloudflare ซึ่งเรื่องนี้ขึ้นอยู่มากกับการออกแบบรายละเอียดด้านสื่อในชั้น "streaming format" อุตสาหกรรมยังคงพัฒนาสเปกในชั้นนี้กันอยู่ต่อเนื่อง และตอนนี้สเปกที่นำอยู่คือ WARP เมื่อมาตรฐาน WARP เริ่มนิ่งขึ้น เราก็น่าจะได้เห็นความสามารถนี้ถูกใส่เข้ามาใน OBS และเครื่องมืออื่น ๆ ด้วย ตอนนี้ก็สามารถ publish วิดีโอผ่านฟอร์แมตสำรองแบบ fMP4 ได้ผ่าน Norsk(https://norsk.video/)
      สำหรับ YouTube นั้น มีคนจาก Google ที่มีส่วนร่วมกับ MoQT อย่างจริงจังอยู่ แต่เขาจะนำไปใช้กับผลิตภัณฑ์ YouTube เมื่อไรและอย่างไร ผมคงตอบแทนไม่ได้

    • https://caniuse.com/webtransport
      https://caniuse.com/webcodecs
      จริง ๆ แล้ว WebCodecs ไม่ได้จำเป็นเสมอไป จะเรนเดอร์ผ่าน MSE ก็ได้ แต่จะซับซ้อนกว่าและมี latency สูงกว่า
      ตอนนี้กำลังทำ WebSocket fallback และ OPUS encoder แบบ WASM เพื่อรองรับ Safari