HN chia sẻ: Winamp và các trình phát media khác được tái tạo trên web bằng Web Components
(player.style)- player.style là bộ sưu tập giao diện trình phát video·audio dựa trên Media Chrome, có thể áp dụng theo cùng một cách cho nhiều trình phát web và framework ứng dụng khác nhau
- Sau khi chọn giao diện trình phát mong muốn rồi chọn trình phát và framework, bạn sẽ được dẫn tới luồng mã có thể sao chép và dán
- Có thể thu hẹp giao diện theo Video/Audio, HTML, React, Next.js, Vue, Svelte cùng các điều kiện như timeline thumbnails, AirPlay, Google Cast, chapters, tooltips
- Giao diện trình phát có thể được điều chỉnh chỉ bằng HTML và CSS, đồng thời cũng cung cấp thiết lập màu chủ đề như Primary, Secondary, Accent
- Có thể nhanh chóng áp dụng các trải nghiệm trình phát media hiện có như Sutro, Instaplay, Notflix, YT, Minimal, Winamp dưới dạng giao diện web được tái cấu trúc lại
Cách dùng và tùy biến player.style
- player.style cung cấp giao diện trình phát video·audio được tạo bằng Media Chrome
- Phạm vi hướng tới là “every web player” và “every web app framework”
- Quy trình áp dụng gồm 3 bước đơn giản
- Chọn giao diện trình phát bạn thích
- Chọn trình phát và framework ứng dụng sẽ dùng
- Sao chép·dán đoạn mã được tạo ra
- UI trình phát có thể được tinh chỉnh chi tiết chỉ bằng HTML và CSS
- Các bộ lọc và mục thiết lập gồm có
- Media: Video, Audio
- Framework: HTML, React, Next.js, Vue, Svelte
- Tính năng: timeline thumbnails, AirPlay, Google Cast, chapters, tooltips
- Màu sắc: Primary, Secondary, Accent
Bộ sưu tập giao diện trình phát web
- Sutro: giao diện tinh tế và hiện đại, lấy tên từ ăng-ten TV ở San Francisco
- X-mas: giao diện Giáng sinh với tông đỏ·xanh lá, đèn lấp lánh và không khí cuối năm
- Halloween: giao diện mang không khí Halloween vào trình phát video
- Instaplay: giao diện ưu tiên di động, lấy cảm hứng từ trải nghiệm phát của ứng dụng mạng xã hội phổ biến
- Sutro Audio: giao diện audio có cùng mô tả như Sutro
- Notflix: giao diện gợi nhắc một trải nghiệm thiếu mỗi “chữ N đỏ lớn” và chuyến xe buýt dài tới Los Gatos
- Reelplay: giao diện trình phát media retro lấy cảm hứng từ các trình phát media thời trước
- Vimeonova: giao diện diễn giải lại thiết kế trình phát Vimeo cổ điển theo cách mới
- YT: lời tri ân tới trình phát YouTube hiện đại và phổ biến, được tái tạo gần nhất có thể bằng Web Components
- Tailwind Audio: giao diện trình phát audio tối giản được tạo bằng Tailwind CSS
- Demuxed 2022: giao diện trình phát media được tạo cho Demuxed 2022
- Microvideo: giao diện phù hợp với nội dung ngắn, nơi không cần các điều khiển phát mạnh mẽ vốn cần cho nội dung dài
- Minimal: giao diện đơn giản rút gọn trải nghiệm Mux Player xuống các điều khiển cơ bản mà người xem cần
- Winamp: giao diện retro lấy cảm hứng từ trình phát media Winamp kinh điển
1 bình luận
Các ý kiến trên Hacker News
Nếu bạn chỉ cần nhạc chứ không cần video thì https://webamp.org/ cũng đáng xem
Không cần phải “compile” hay “tích hợp” gì to tát, chỉ cần nhúng vào là được, còn playlist thì ứng dụng tự tạo. Ví dụ: Music
Tôi thích ý tưởng này và cảm ơn vì đã phát hành dưới giấy phép MIT
Đúng lúc tôi đang làm một ứng dụng media, chính xác hơn là một trình chỉnh sửa video, và trước đây cũng từng làm vài trình phát video bằng Flash và HTML/JS. Khoảng năm 2015, tôi đã thử dùng Web Components trong một trình phát, nhưng cứ liên tục khổ sở nên cuối cùng quay lại JavaScript thông thường. Kỳ lạ là trong ứng dụng media hiện tại, tôi đang dùng các Web Component như timeline của trình chỉnh sửa video, và đến giờ thì hoạt động khá ổn. Tôi không rõ điều gì đã thay đổi, hay nhờ sự phát triển chậm rãi của web mà mức độ tương thích đã đủ tốt
Tôi đã lướt qua tài liệu Media Chrome và cũng chỉ xem nhanh repository GitHub, nhưng tôi thích các nguyên tắc thiết kế và ghi chú kiến trúc. Khi đưa thứ như thế này vào, nhất là từ góc nhìn của người đã tự làm những thứ tương tự nhiều lần, điều tôi lo nhất là khả năng mở rộng và kích thước file. Chẳng hạn, tôi tò mò việc điều chỉnh component timeline của mình cho khớp với mô hình MediaController sẽ khó đến mức nào. Nếu tự làm toàn bộ thì lợi thế là chỉ có đúng những gì cần, không hơn. Media Chrome hẳn có nhiều tính năng tôi sẽ không bao giờ dùng, nên câu hỏi là vì thế tôi phải gánh thêm bao nhiêu “trọng lượng” không cần thiết. Không chỉ các component không dùng, mà cả các tính năng không dùng bên trong những component có dùng cũng vậy. Đôi khi các tính năng dư thừa có sẵn còn cản trở khả năng mở rộng ở tầng thấp hơn
Ngoài ra, repository
media-elements[1] không có file giấy phép. Trong package.json có ghi các element cũng là MIT, nhưng có một file LICENSE rõ ràng thì lúc nào cũng tốtDù vậy đây là một thư viện khá hấp dẫn. Ít nhất cho đến nay, trang nhúng đang tự kết nối các element với nhau, và tôi vốn đang muốn một abstraction tốt hơn, nên có lẽ tôi sẽ “mượn” ý tưởng bọc các component của mình bằng một element kiểu media-controller
Trong thời gian đó đã có đặc tả Web Components v2, nhưng tôi không phải chuyên gia về những gì đã thay đổi. Giờ thì có thể thấy Web Components ở nhiều nơi, đặc biệt là trong các trình phát media. Ví dụ như trình phát web của Apple
Rất vui vì bạn thích kiến trúc controller. Phiên bản ban đầu là mọi element đều trỏ trực tiếp tới media element, và khi controller xuất hiện thì mọi thứ gọn gàng hơn nhiều. Ít nhất so với cách tôi từng làm, tôi rất khuyến nghị
Tôi xem UI trình chỉnh sửa video là một phần mở rộng tự nhiên của bộ Media Chrome. Nếu bạn để lại issue trong repository về những gì sẽ hữu ích hơn cho mảng đó thì rất tốt
Tôi rất đồng cảm với việc do dự khi đưa thứ như Media Chrome vào vì tính linh hoạt trong tương lai và kích thước. Nếu là tôi, có 3 điểm có thể thuyết phục được. 1) Có thể chỉ nhúng những UI component cần thiết, và đây là khác biệt lớn về kích thước so với các trình phát video web khác. 2) Những nhà phát triển player giàu kinh nghiệm nhất đang làm việc trên đó, bao gồm cả những phần như accessibility và quốc tế hóa trong tương lai. 3) Chúng tôi đang cố làm cho nó có khả năng cấu hình rất cao thông qua slot, CSS parts và biến CSS
Tất nhiên không thể thắng được kích thước file của phần mềm tùy biến hoàn toàn, nhưng khi các tính năng cơ bản đã đầy đủ, tôi nghĩ sẽ khá sát. Cảm ơn vì đã báo về giấy phép của elements
Chiến lược marketing của Mux rất khôn ngoan
Họ mua lại hoặc tạo mới các dự án open source để các lập trình viên đang tìm gói video rốt cuộc sẽ biết đến tên công ty
Một ví dụ khác tôi thấy gần đây là https://github.com/cookpete/react-player
Một phần hiện tượng thấy ở mảng trình phát open source là vì dù sao chúng tôi cũng phải hỗ trợ các dự án đó. Chúng tôi không phụ thuộc vào player nào, nên khách hàng của chúng tôi dùng nhiều dự án open source, kể cả những dự án không được bảo trì tích cực
Hiện tại trong số các công ty video lấy lập trình viên làm trung tâm, rất ít nơi đóng góp tích cực cho open source, nên tôi nghĩ chúng tôi đang được hưởng lợi
Mux trông có vẻ ổn, nhưng tôi không tin công ty sẽ tiếp tục duy trì gói mã hóa video miễn phí, nên chắc tôi sẽ không xây gì trên đó
Mã hóa theo yêu cầu cho người dùng cũng có vẻ hơi vô lý về mặt tài nguyên. Mô hình starter là trả 10 đô la để mua lượng credit trị giá 100 đô la. Tất cả trông như một món hàng mồi rất lớn, và ngày càng khó tin vào một công ty dường như đang đốt tiền mỗi ngày. Tôi thà họ tính phí gì đó còn hơn. Tôi biết mã hóa không miễn phí. Hoặc nếu trên trang có một mục giải thích làm sao họ có thể đưa ra mức giá thấp hơn tất cả mọi người trong ngành mà vẫn tiếp tục kinh doanh được, thì có lẽ sẽ giảm đáng kể sự nghi ngờ. Tôi đã bị SaaS làm cho “bỏng tay” quá nhiều rồi
“Một mục giải thích làm sao họ có thể đưa ra mức giá thấp hơn tất cả mọi người trong ngành mà vẫn tiếp tục kinh doanh được” là phản hồi thực sự hay, tôi sẽ đưa vào danh sách việc cần làm. Nhất định phải có
Chúng tôi sẽ không đưa ra mức giá với hiệu quả kinh tế mà mình không kham nổi, hoặc ít nhất phải có một lộ trình rõ ràng để kham được. Toàn bộ giá theo từng mức lưu lượng đều được công khai, nên nếu bạn hiểu khái niệm như credit thì sẽ không gặp cảnh bị đổi giá sau lớp mồi nhử. Điều đó trái ngược với một số đối thủ khiến người dùng bất ngờ bằng giá mới khi họ đã tăng trưởng quy mô. Tôi thật sự ghét cách làm như vậy
Trong nội bộ, chúng tôi có lợi thế nhờ dùng mã hóa đúng lúc và các tối ưu hóa nâng cao khác. Cũng có lợi thế kinh tế theo quy mô, và chúng tôi dự định sẽ viết bài về chuyện này
Tuy nhiên, nhận thức của khách hàng là phần khó. Một số khách hàng hiểu mã hóa và chi phí của nó, cũng như các lợi ích như streaming thích ứng hoặc xử lý nội dung tải lên do người dùng tạo. Nhiều lập trình viên mới làm video nên kỳ vọng chi phí sẽ giống như đưa MP4 lên S3. Có người nêu ra đối thủ không tính phí mã hóa, có người lấy YouTube làm lý do rằng lẽ ra phải rẻ hơn. Trước đây Mux có thu phí mã hóa nên bị xếp vào “lựa chọn đắt đỏ”, vì vậy chúng tôi đang xây dựng cấu trúc giá mới: bắt đầu từ mức mã hóa thấp hơn nhưng bền vững về mặt kinh tế, rồi nếu thấy có giá trị thì có thể chọn mức chi phí/giá trị mã hóa cao hơn. Một phần đã ra mắt, một phần còn sắp tới
Chúng tôi nghĩ video nên xuất hiện ở nhiều nơi hơn hiện nay, nhưng về bản chất video đắt đỏ so với nhiều chi phí khác khi xây dựng ứng dụng. Vì vậy chúng tôi xem việc của mình là tiếp tục hạ chi phí và tinh chỉnh cấu trúc giá để video có thể được dùng trong nhiều trường hợp hơn
Các đánh đổi khi dùng mã hóa miễn phí được tóm tắt ở đây: https://docs.mux.com/guides/use-video-quality-levels. Ngay cả mã hóa basic miễn phí thì chi phí lưu trữ và truyền tải vẫn được tính. Chúng tôi hy vọng nếu giúp giảm chi phí lúc bắt đầu, chúng ta có thể cùng phát triển
Mã hóa theo yêu cầu, tức JIT, thực sự giống như phép màu khi nhìn thấy nó hoạt động tốt và ổn định đến mức nào
Tôi làm việc tại Mux
Ở đây có vài chỗ xử lý focus hơi lạ. Hy vọng được xem là góp ý mang tính xây dựng; tất cả đều có cùng vấn đề
Nếu nhấp vào chính video, có thể dùng phím mũi tên trái/phải để tua video tiến/lùi. Mũi tên lên/xuống không làm gì cả
Nếu nhấp vào thanh điều hướng, phím mũi tên trái/phải ngừng hoạt động. Thay vào đó, mũi tên lên/xuống bắt đầu tua lùi/tiến theo các khoảng thời gian khác nhau
Nếu nhấp vào vùng trống như thanh màu xanh kiểu Windows 98 trong ví dụ Winamp hoặc Reelplay, tất cả các điều khiển này đều ngừng hoạt động và phím cách cũng không phát/tạm dừng được
Tôi kiểm tra trên Chrome mới nhất của macOS
Nhìn chung tình huống hơi phức tạp vì “phím tắt” điều khiển video, các điều khiển trợ năng của từng component, và kỳ vọng trợ năng chung cho toàn trang chồng lấn lên nhau. Ví dụ có vấn đề như khi player đang có focus thì có nên luôn bắt mũi tên lên/xuống để điều khiển âm lượng hay không, hay không nên vì mọi người kỳ vọng dùng chúng để cuộn trang
Dù sao phần này cần được lặp lại và cải thiện thêm, nên phản hồi rất hữu ích
Player.style rất tuyệt
Ở startup trước, tôi từng bắt đầu tự làm theme cho video.js, nhưng vài giờ sau kết luận là không đáng để bỏ thời gian và dùng mặc định. Từ giờ các theme như thế này có vẻ sẽ là điểm khởi đầu tốt hơn nhiều khi muốn tạo thứ tùy biến hơn
Nhân tiện có các chuyên gia video trong thread này, tôi tò mò liệu có triển khai player nào cho phép tua nhanh và mượt kèm âm thanh không
Ý tôi là tính năng tương tự như việc lướt hoặc xem timeline ở tốc độ 16x trong Adobe Premiere. Có lẽ cần chủ động tải sẵn thứ gì đó như track âm thanh mono 16kHz và định dạng video 240p chỉ có sprite 1fps hoặc I-frame, rồi chuyển sang nó khi tua
Không có câu trả lời chính xác, nhưng có lẽ nên xem khu vực WebCodecs, nơi đang có các ví dụ hiệu năng tốt được tạo ở mức thấp hơn: https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...
Web Components rất tuyệt, và Mux đang làm những điều hay với chúng
Có thể điều chỉnh mã để hoạt động với nhúng YouTube
Chỉ cần đặt các tham số sau trong
srccủa phần nhúng YouTubecontrols=0– loại bỏ các nút điều khiển trình phát như phát, tạm dừng, âm lượngmodestbranding=1– giảm thiểu logo YouTube trong trình phátrel=0– không hiển thị video liên quan ở cuối. Chỉ hoạt động theo cách chỉ hiển thị video từ cùng kênhshowinfo=0– loại bỏ tiêu đề video và thông tin người tải lên. Tham số này đã bị loại bỏ, nhưngmodestbrandingcó thể giúp íchfs=0– vô hiệu hóa nút toàn màn hìnhiv_load_policy=3– ẩn các chú thích video như thông báo bật lênSau đó trong mã, chỉ cần phát hiện URL nhúng YouTube và tạo trình phát bằng
iframethay vì thẻvideo. Cuối cùng, ánh xạ các điều khiển trình phát sang API nhúng YouTube. Plyr.io cũng đã làm việc tương tựViệc tạo ra thứ gì đó hơi giống Winamp không có nghĩa nó là Winamp