เปิดตัวบน HN: Winamp และมีเดียเพลเยอร์อื่น ๆ ที่นำมาสร้างใหม่บนเว็บด้วย Web Components

 (player.style)
3 คะแนน โดย GN⁺ 2024-10-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • player.style คือชุดธีมวิดีโอและออดิโอเพลเยอร์ที่อิงกับ Media Chrome ซึ่งสามารถนำไปใช้กับเว็บเพลเยอร์และแอปเฟรมเวิร์กหลากหลายแบบได้ด้วยวิธีเดียวกัน
  • เมื่อเลือก ธีมเพลเยอร์ ที่ต้องการ แล้วเลือกเพลเยอร์และเฟรมเวิร์ก ระบบจะพาไปสู่ขั้นตอนโค้ดที่สามารถคัดลอกไปวางได้
  • สามารถกรองธีมตามเงื่อนไข เช่น Video/Audio, HTML, React, Next.js, Vue, Svelte รวมถึง timeline thumbnails, AirPlay, Google Cast, chapters, tooltips
  • UI ของเพลเยอร์สามารถปรับแต่งได้ด้วย HTML และ CSS เท่านั้น และยังมีการตั้งค่าสีธีมอย่าง Primary, Secondary, Accent
  • สามารถนำประสบการณ์มีเดียเพลเยอร์เดิม ๆ เช่น Sutro, Instaplay, Notflix, YT, Minimal, Winamp มาสร้างใหม่เป็นธีมสำหรับเว็บและนำไปใช้ได้อย่างรวดเร็ว

วิธีใช้และปรับแต่ง player.style

  • player.style ให้บริการ ธีมวิดีโอและออดิโอเพลเยอร์ ที่สร้างด้วย Media Chrome
  • ขอบเขตเป้าหมายคือ “every web player” และ “every web app framework”
  • ขั้นตอนการใช้งานประกอบด้วย 3 ขั้นตอนง่าย ๆ
    • เลือกธีมเพลเยอร์ที่ชอบ
    • เลือกเพลเยอร์และแอปเฟรมเวิร์กที่จะใช้
    • คัดลอกและวางโค้ดที่สร้างขึ้น
  • UI ของเพลเยอร์สามารถปรับรายละเอียดได้ด้วย HTML และ CSS เท่านั้น
  • ตัวกรองและรายการตั้งค่าประกอบด้วย
    • สื่อ: Video, Audio
    • เฟรมเวิร์ก: HTML, React, Next.js, Vue, Svelte
    • ฟีเจอร์: timeline thumbnails, AirPlay, Google Cast, chapters, tooltips
    • สี: Primary, Secondary, Accent

แกลเลอรีธีมเว็บเพลเยอร์

  • Sutro: ธีมเรียบหรูและทันสมัย ตั้งชื่อตามเสาอากาศทีวีในซานฟรานซิสโก
  • X-mas: ธีมคริสต์มาส ที่มาพร้อมโทนสีแดง-เขียว แสงไฟระยิบระยับ และบรรยากาศปลายปี
  • Halloween: ธีมที่เพิ่มบรรยากาศฮาโลวีนให้กับวิดีโอเพลเยอร์
  • Instaplay: ธีมแบบ mobile-first ที่ได้แรงบันดาลใจจากประสบการณ์การเล่นสื่อของแอปโซเชียลมีเดียยอดนิยม
  • Sutro Audio: ธีมออดิโอที่มีคำอธิบายเดียวกับ Sutro
  • Notflix: ธีมที่สื่อถึงประสบการณ์แบบหนึ่ง ยกเว้น “ตัว N สีแดงขนาดใหญ่” และรถบัสสายยาวไป Los Gatos
  • Reelplay: ธีม มีเดียเพลเยอร์ย้อนยุค ที่ได้แรงบันดาลใจจากมีเดียเพลเยอร์ในอดีต
  • Vimeonova: ธีมที่ตีความดีไซน์เพลเยอร์ Vimeo แบบคลาสสิกขึ้นใหม่
  • YT: คารวะต่อเพลเยอร์ YouTube สมัยใหม่ที่ใช้งานกันอย่างแพร่หลาย และถูกสร้างใหม่ด้วย Web Components ให้ใกล้เคียงที่สุด
  • Tailwind Audio: ธีมออดิโอเพลเยอร์แบบมินิมัลที่สร้างด้วย Tailwind CSS
  • Demuxed 2022: ธีมมีเดียเพลเยอร์ที่สร้างสำหรับ Demuxed 2022
  • Microvideo: ธีมที่เหมาะกับ คอนเทนต์สั้น ซึ่งไม่ต้องการคอนโทรลการเล่นที่ทรงพลังแบบที่จำเป็นสำหรับคอนเทนต์ยาว
  • Minimal: ธีมเรียบง่ายที่ลดประสบการณ์ของ Mux Player ให้เหลือเฉพาะคอนโทรลพื้นฐานที่ผู้ชมต้องใช้
  • Winamp: ธีมย้อนยุคที่ได้แรงบันดาลใจจากมีเดียเพลเยอร์คลาสสิก Winamp

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

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

 
GN⁺ 2024-10-09
ความคิดเห็นบน Hacker News

  • ถ้าต้องการแค่เพลง ไม่ใช่วิดีโอ https://webamp.org/ ก็น่าดูเหมือนกัน
    ไม่ต้อง “คอมไพล์” หรือ “ผสานรวม” ให้ใหญ่โต แค่ใส่เข้าไปก็พอ แล้วให้แอปสร้างเพลย์ลิสต์เอง เช่น Music

    • การทำออกมาดีมาก ถ้าต้องการ น่าจะเพิ่ม การรองรับวิดีโอ ได้ง่ายด้วย และภายในก็น่าจะใช้แค่องค์ประกอบสื่อธรรมดา

  • ชอบไอเดียนี้ และขอบคุณที่เปิดเป็น ไลเซนส์ MIT
    พอดีกำลังทำแอปสื่ออยู่ พูดให้ตรงคือโปรแกรมตัดต่อวิดีโอ และเมื่อก่อนก็เคยทำวิดีโอเพลเยอร์ด้วย Flash และ HTML/JS มาหลายตัว ราวปี 2015 เคยลองใช้เว็บคอมโพเนนต์ในเพลเยอร์ตัวหนึ่ง แต่เจ็บปวดต่อเนื่องจนสุดท้ายกลับไปใช้ JavaScript แบบธรรมดาแทน แปลกที่ในแอปสื่อตอนนี้ผมกำลังใช้เว็บคอมโพเนนต์อย่างเช่นไทม์ไลน์ของโปรแกรมตัดต่อวิดีโอ และจนถึงตอนนี้ก็ทำงานได้ค่อนข้างดี ไม่แน่ใจว่าอะไรเปลี่ยนไป หรือเป็นเพราะเว็บค่อย ๆ พัฒนาจนความเข้ากันได้ดีพอแล้วกันแน่
    ผมไล่อ่านเอกสาร Media Chrome และดูรีโพซิทอรี GitHub แบบเร็ว ๆ เท่านั้น แต่ชอบหลักการออกแบบและโน้ตสถาปัตยกรรม เวลาเอาของแบบนี้มาใช้ โดยเฉพาะจากมุมของคนที่เคยทำของพวกนี้เองมาหลายครั้ง สิ่งที่กังวลที่สุดคือ ความสามารถในการขยาย และขนาดไฟล์ เช่น ผมสงสัยว่าการปรับคอมโพเนนต์ไทม์ไลน์ของผมให้เข้ากับแนวทาง MediaController จะยากแค่ไหน ถ้าทำเองทั้งหมดก็มีข้อดีคือมีเฉพาะสิ่งที่จำเป็นและไม่มีอะไรมากกว่านั้น ใน Media Chrome น่าจะมีฟีเจอร์จำนวนมากที่ผมไม่มีวันใช้ คำถามคือเพราะแบบนั้นผมจะต้องแบกรับน้ำหนักส่วนเกินที่ไม่จำเป็นมากแค่ไหน ไม่ใช่แค่คอมโพเนนต์ที่ไม่ใช้เท่านั้น แต่รวมถึงฟีเจอร์ที่ไม่ใช้ภายในคอมโพเนนต์ที่ใช้ด้วย บางครั้งฟีเจอร์ที่ไม่จำเป็นซึ่งมีอยู่แล้วก็ขัดขวางความสามารถในการขยายในระดับที่ต่ำกว่าได้ด้วย
    นอกจากนี้ รีโพซิทอรี media-elements [1] ไม่มีไฟล์ไลเซนส์ ใน package.json ระบุว่าองค์ประกอบต่าง ๆ เป็น MIT เช่นกัน แต่การมีไฟล์ LICENSE ระบุชัดเจนไว้ย่อมดีเสมอ
    ถึงอย่างนั้นก็เป็นไลบรารีที่ค่อนข้างน่าสนใจ อย่างน้อยจนถึงตอนนี้ หน้าเว็บที่ฝังมันอยู่เป็นตัวเชื่อมองค์ประกอบต่าง ๆ เข้าด้วยกันเอง แต่ผมก็กำลังอยากได้ abstraction ที่ดีกว่านี้อยู่พอดี ดังนั้นน่าจะขอยืมไอเดียการห่อคอมโพเนนต์ของผมด้วยองค์ประกอบอย่าง media-controller ไปใช้

    1. https://github.com/muxinc/media-elements
    • ราวปี 2015 ผมน่าจะมองเว็บคอมโพเนนต์ค่อนข้างในแง่ดีและดื้อดึงอยู่พอสมควร อยากให้มันไปได้สวยจริง ๆ แต่กว่าจะเอาเข้าการใช้งานจริงในโปรดักชันได้ก็ประมาณปี 2020
      ระหว่างนั้นมีสเปกเว็บคอมโพเนนต์ v2 แต่ผมไม่ใช่ผู้เชี่ยวชาญว่าอะไรเปลี่ยนไปบ้าง ตอนนี้เริ่มเห็นเว็บคอมโพเนนต์ตามที่ต่าง ๆ แล้ว และเห็นมากเป็นพิเศษในมีเดียเพลเยอร์ ตัวอย่างเช่นเว็บเพลเยอร์ของ Apple
      ดีใจที่ชอบสถาปัตยกรรมคอนโทรลเลอร์ เวอร์ชันแรก ๆ คือให้องค์ประกอบทุกตัวชี้ไปที่องค์ประกอบสื่อโดยตรง และพอมีคอนโทรลเลอร์เข้ามาก็จัดระเบียบได้ดีขึ้นมาก อย่างน้อยเมื่อเทียบกับวิธีที่ผมเคยทำ ผมแนะนำอย่างยิ่ง
      UI โปรแกรมตัดต่อวิดีโอถือเป็นการต่อยอดที่เป็นธรรมชาติของชุด Media Chrome ถ้ามีอะไรที่จะช่วยด้านนั้นได้มากขึ้น อยากให้เปิด issue ไว้ในรีโพซิทอรี
      ผมเข้าใจอย่างลึกซึ้งถึงความลังเลในการนำของอย่าง Media Chrome มาใช้ เพราะเรื่องความยืดหยุ่นในอนาคตและขนาด ถ้าเป็นผม มี 3 ประเด็นที่น่าจะโน้มน้าวได้ 1) สามารถรวมเฉพาะคอมโพเนนต์ UI ที่จำเป็นได้ ซึ่งในแง่ขนาดแล้วต่างจากเว็บวิดีโอเพลเยอร์อื่น ๆ มาก 2) นักพัฒนาเพลเยอร์ที่มีประสบการณ์มากที่สุดกำลังทำงานอยู่ รวมถึงด้านอย่าง accessibility และ internationalization ในอนาคตด้วย 3) เรากำลังพยายามทำให้ตั้งค่าได้สูงมากระหว่าง slot, CSS parts และตัวแปร CSS
      แน่นอนว่าคงสู้ขนาดไฟล์ของซอฟต์แวร์ที่ปรับแต่งเฉพาะทางเต็มรูปแบบไม่ได้ แต่เมื่อฟังก์ชันพื้นฐานครบทั้งหมดแล้ว ผมคิดว่าน่าจะเข้าใกล้ได้มาก ขอบคุณที่แจ้งเรื่องไลเซนส์ของ elements

  • กลยุทธ์การตลาดของ Mux ฉลาดดี
    ซื้อหรือสร้างโปรเจกต์โอเพนซอร์สขึ้นมา เพื่อให้นักพัฒนาที่กำลังมองหาแพ็กเกจวิดีโอได้เจอชื่อบริษัทในที่สุด
    อีกตัวอย่างที่เพิ่งเห็นเมื่อไม่นานมานี้คือ https://github.com/cookpete/react-player

    • ขอบคุณครับ คำว่า “ฉลาด” อาจจะชมเกินไปหน่อย ส่วนใหญ่แล้วมันใกล้เคียงกับการดูว่านักพัฒนาใช้วิดีโอกันอย่างไร แล้วพยายามแก้ปัญหาในพื้นที่นั้นมากกว่า Next-video.dev ก็เป็นอีกตัวอย่างที่เราภูมิใจ
      ส่วนหนึ่งของสิ่งที่เห็นในฝั่งโอเพนซอร์สเพลเยอร์ เป็นเพราะไม่ว่าอย่างไรเราก็มีด้านที่ต้องรองรับโปรเจกต์เหล่านั้นอยู่แล้ว เราไม่ผูกกับเพลเยอร์ใดเพลเยอร์หนึ่ง ลูกค้าจึงใช้โอเพนซอร์สหลากหลาย รวมถึงโปรเจกต์ที่ไม่ได้มีการดูแลอย่างแข็งขันด้วย
      ตอนนี้ในบรรดาบริษัทวิดีโอที่เน้นนักพัฒนา มีน้อยมากที่มีส่วนร่วมกับโอเพนซอร์สอย่างจริงจัง จึงมองว่าเราได้ประโยชน์จากตรงนี้

  • Mux ดูดี แต่ผมไม่เชื่อว่าบริษัทจะคง เทียร์เข้ารหัสวิดีโอฟรี ไว้ต่อไป จึงคงไม่สร้างอะไรบนบริการนั้น
    การเข้ารหัสแบบออนดีมานด์สำหรับผู้ใช้ก็ดูไม่ค่อยสมเหตุสมผลในแง่ทรัพยากร โมเดลเริ่มต้นคือจ่าย 10 ดอลลาร์เพื่อซื้อเครดิตมูลค่า 100 ดอลลาร์ ทั้งหมดดูเหมือนสินค้าเรียกลูกค้าขาดทุนก้อนใหญ่ และเริ่มเชื่อใจบริษัทที่ดูเหมือนเผาเงินทุกวันได้ยากขึ้น ผมอยากให้คิดเงินอะไรสักอย่างมากกว่า ผมรู้ว่าการเข้ารหัสไม่ได้ฟรี หรือถ้ามีส่วนบนเว็บไซต์อธิบายว่าทำไมถึงคิดราคาต่ำกว่าทุกคนในอุตสาหกรรมแล้วธุรกิจยังอยู่ได้ ก็น่าจะลดความสงสัยลงได้มาก โดน SaaS เล่นงานมาเยอะเกินไปแล้ว

    • คำตอบเรื่องนี้เขียนเป็นหนังสือได้ทั้งเล่มเลย
      “ส่วนที่อธิบายว่าทำไมถึงคิดราคาต่ำกว่าทุกคนในอุตสาหกรรมแล้วธุรกิจยังอยู่ได้” เป็นฟีดแบ็กที่ดีมาก และจะใส่ไว้ในรายการงานที่ต้องทำ ควรมีอย่างแน่นอน
      เราจะไม่ตั้งราคาที่มีเศรษฐศาสตร์ที่รับไม่ไหว และอย่างน้อยต้องมีเส้นทางที่ชัดเจนว่าจะรับไหว ราคาตามปริมาณทั้งหมดเปิดเผยอยู่แล้ว ดังนั้นถ้าเข้าใจแนวคิดอย่างเครดิต ก็ไม่ควรเจอการเปลี่ยนราคาหลังจากเหยื่อเรียกลูกค้า เมื่อเทียบกับคู่แข่งบางรายที่พอใช้งานใหญ่ขึ้นแล้วทำให้ผู้ใช้ตกใจกับราคาใหม่ เราตรงกันข้ามกับแนวนั้นเลย ผมเกลียดวิธีแบบนั้นจริง ๆ
      ภายในเราได้เปรียบจากการใช้ การเข้ารหัสแบบทันเวลา และการปรับแต่งขั้นสูงอื่น ๆ นอกจากนี้ยังมีเศรษฐกิจจากขนาด และมีแผนจะเขียนบทความเกี่ยวกับเรื่องนี้
      แต่การรับรู้ของลูกค้าเป็นเรื่องยาก ลูกค้าบางคนเข้าใจการเข้ารหัสและต้นทุนของมัน รวมถึงข้อดีอย่าง adaptive streaming หรือการรองรับอัปโหลดที่ผู้ใช้สร้างขึ้น นักพัฒนาจำนวนมากเพิ่งเริ่มทำวิดีโอ จึงคาดว่าต้นทุนจะเท่ากับการอัปโหลด MP4 ไปไว้บน S3 บางคนยกคู่แข่งที่ไม่มีค่าบริการเข้ารหัสมาอ้าง บางคนบอกว่าควรถูกกว่านี้เพราะมี YouTube ในอดีต Mux คิดค่าบริการเข้ารหัส จึงถูกจัดเป็น “ตัวเลือกที่แพง” เราจึงกำลังสร้างโครงสร้างราคาใหม่ที่เริ่มจากระดับการเข้ารหัสที่ต่ำลงและรับได้ทางเศรษฐศาสตร์ก่อน แล้วถ้าเห็นว่าคุ้มค่า ก็เลือกขยับไปยังระดับต้นทุน/มูลค่าการเข้ารหัสที่สูงขึ้นได้ บางส่วนเปิดตัวแล้ว และบางส่วนกำลังจะมา
      เราคิดว่าวิดีโอควรอยู่ในที่ต่าง ๆ มากกว่าตอนนี้ แต่โดยเนื้อแท้แล้ววิดีโอมีต้นทุนสูงเมื่อเทียบกับต้นทุนอื่น ๆ จำนวนมากในการสร้างแอป ดังนั้นเรามองว่างานของเราคือการลดต้นทุนลงเรื่อย ๆ และปรับโครงสร้างราคา เพื่อให้ใช้วิดีโอได้ใน use case มากขึ้น
    • มี use case อย่างเนื้อหาที่ผู้ใช้สร้างขึ้นซึ่ง การเข้ารหัสเป็นศูนย์กลางต้นทุนขนาดใหญ่ เราจึงอยากให้สร้างบน Mux ได้แม้ใช้โมเดลแบบนั้น
      ข้อแลกเปลี่ยนของการใช้การเข้ารหัสฟรีสรุปไว้ที่นี่: https://docs.mux.com/guides/use-video-quality-levels แม้การเข้ารหัสแบบ basic ที่ฟรี ก็ยังมีค่า storage และค่า delivery อยู่ เราหวังว่าการช่วยลดต้นทุนตอนเริ่มต้นจะทำให้เติบโตไปด้วยกันได้
      ออนดีมานด์ หรือ JIT encoding นั้น ถ้าดูว่ามันทำงานได้ดีสม่ำเสมอแค่ไหน ก็เหมือนเวทมนตร์จริง ๆ
      ผมทำงานที่ Mux

  • ตรงนี้มีส่วนที่ การจัดการโฟกัส แปลกอยู่บ้าง หวังว่าจะรับเป็นคำวิจารณ์เชิงสร้างสรรค์ และทั้งหมดมีปัญหาเดียวกัน
    ถ้าคลิกที่ตัววิดีโอเอง จะใช้ปุ่มลูกศรซ้าย/ขวาเพื่อเลื่อนวิดีโอไปข้างหน้า/ถอยหลังได้ ส่วนขึ้น/ลงไม่ทำอะไร
    ถ้าคลิกแถบ seek ปุ่มลูกศรซ้าย/ขวาจะหยุดทำงาน แต่ปุ่มลูกศรขึ้น/ลงจะเริ่มถอย/เดินหน้าในช่วงเวลาที่ต่างกันแทน
    ถ้าคลิกพื้นที่ว่าง เช่น แถบสีน้ำเงินที่ดูเหมือน Windows 98 ในตัวอย่าง Winamp หรือ Reelplay คอนโทรลทั้งหมดนี้จะหยุดทำงาน และกดสเปซบาร์เพื่อเล่น/หยุดชั่วคราวก็ไม่ได้
    ตรวจสอบบน Chrome เวอร์ชันล่าสุดบน macOS

    • เป็นฟีดแบ็กที่ดี มี issue ที่เกี่ยวข้องใน repository ของ Media Chrome: https://github.com/muxinc/media-chrome/issues/957
      โดยทั่วไปสถานการณ์ค่อนข้างซับซ้อน เพราะ “คีย์ลัด” สำหรับควบคุมวิดีโอ, คอนโทรลด้าน accessibility ของแต่ละคอมโพเนนต์ และความคาดหวังด้าน accessibility ทั่วไปของทั้งหน้า มันทับซ้อนกัน ตัวอย่างเช่น เมื่อโฟกัสอยู่ที่ player ควรจับปุ่มลูกศรขึ้น/ลงไว้เป็นการควบคุมระดับเสียงเสมอหรือไม่ หรือไม่ควรเพราะผู้คนคาดว่าจะใช้เลื่อนหน้า
      อย่างไรก็ดี ส่วนนี้ยังต้องปรับปรุงซ้ำต่อไป ฟีดแบ็กจึงมีประโยชน์มาก

  • Player.style ยอดเยี่ยมมาก
    ที่สตาร์ทอัพก่อนหน้านี้ ผมเคยเริ่มทำธีม video.js เอง แต่ผ่านไปไม่กี่ชั่วโมงก็สรุปว่าไม่คุ้มกับเวลาของผม แล้วใช้ค่าเริ่มต้นแทน ต่อไปธีมแบบนี้น่าจะเป็นจุดเริ่มต้นที่ดีกว่ามากเมื่อจะสร้างของที่ปรับแต่งเฉพาะมากขึ้น

    • ถ้ายังมี friction ในการสร้างธีมเอง แปลว่างานของเรายังไม่จบ อยากให้บอกเรา

  • ไหน ๆ ก็มีผู้เชี่ยวชาญด้านวิดีโออยู่ในเธรดนี้แล้ว ผมสงสัยว่ามีการ implement player ที่ทำให้ การเลื่อนหาแบบรวดเร็วและลื่นไหลพร้อมเสียง เป็นไปได้ไหม
    หมายถึงฟีเจอร์คล้ายกับการไถหรือดูไทม์ไลน์ใน Adobe Premiere ที่ความเร็ว 16x อาจต้องโหลดล่วงหน้าแบบค่อนข้าง aggressive เช่น แทร็กเสียงโมโน 16kHz และฟอร์แมตวิดีโอ 240p ที่มี sprite 1fps หรือมีแต่ I-frame แล้วสลับไปใช้สิ่งนั้นตอน seek

    • การ seek ที่แม่นยำระดับเฟรมหรือลื่นไหลนั้นยากเสมอใน ระดับ abstraction ขององค์ประกอบ video
      ไม่มีคำตอบที่แน่ชัด แต่แนะนำให้ดูฝั่ง WebCodecs ซึ่งกำลังมีตัวอย่างประสิทธิภาพดี ๆ ที่สร้างบนระดับที่ต่ำกว่า: https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...

  • Web Components ยอดเยี่ยม และ Mux ก็กำลังทำสิ่งเจ๋ง ๆ ด้วยมัน

    • ฟีดแบ็กเล็กน้อย: ลองพิจารณาใช้ adoptedStyleSheets ดู ตอนนี้รองรับดีมากแล้ว และช่วยเพิ่มประสิทธิภาพในองค์ประกอบที่ซ้ำ ๆ กันได้ อีกทั้งยังทำ fallback ได้ด้วย

  • สามารถปรับโค้ดให้ทำงานร่วมกับ YouTube embed ได้
    เพียงตั้งค่าต่อไปนี้ใน src ของ YouTube embed
    controls=0 – ลบคอนโทรลของตัวเล่น เช่น เล่น หยุดชั่วคราว และระดับเสียง
    modestbranding=1 – ลดการแสดงโลโก้ YouTube ภายในตัวเล่นให้เหลือน้อยที่สุด
    rel=0 – ไม่ให้แสดงวิดีโอที่เกี่ยวข้องในตอนท้าย โดยจะทำงานในลักษณะที่แสดงเฉพาะวิดีโอจากช่องเดียวกันเท่านั้น
    showinfo=0 – ลบชื่อวิดีโอและข้อมูลผู้อัปโหลด พารามิเตอร์นี้ถูกยกเลิกไปแล้ว แต่ modestbranding ยังช่วยได้
    fs=0 – ปิดใช้งานปุ่มเต็มหน้าจอ
    iv_load_policy=3 – ซ่อนคำอธิบายประกอบบนวิดีโอ เช่น การแจ้งเตือนแบบป๊อปอัป
    จากนั้นในโค้ด ให้ตรวจจับ URL ของ YouTube embed และสร้างตัวเล่นด้วย iframe แทนแท็ก video สุดท้ายให้แมปคอนโทรลของตัวเล่นเข้ากับ YouTube embed API โดย Plyr.io ก็เคยทำงานคล้าย ๆ กัน

  • การสร้างสิ่งที่คล้ายกับ Winamp อยู่บ้าง ไม่ได้แปลว่ามันจะเป็น Winamp