- player.style Media Chrome पर आधारित वीडियो·ऑडियो प्लेयर थीम्स का संग्रह है, जिसे अलग-अलग वेब प्लेयर्स और app frameworks पर एक ही तरीके से लागू किया जा सकता है
- मनचाही player theme चुनने के बाद प्लेयर और framework चुनें, फिर copy-paste करने योग्य code flow मिलता है
- Video/Audio, HTML, React, Next.js, Vue, Svelte के साथ timeline thumbnails, AirPlay, Google Cast, chapters, tooltips जैसी शर्तों से themes को फ़िल्टर किया जा सकता है
- प्लेयर UI को सिर्फ HTML और CSS से समायोजित किया जा सकता है, और Primary, Secondary, Accent जैसी theme color settings भी दी जाती हैं
- Sutro, Instaplay, Notflix, YT, Minimal, Winamp आदि पुराने मीडिया प्लेयर अनुभवों को वेब थीम्स के रूप में फिर से बनाकर जल्दी लागू किया जा सकता है
player.style का उपयोग और customization
- player.style Media Chrome से बनी वीडियो·ऑडियो प्लेयर themes प्रदान करता है
- इसका लक्ष्य दायरा “every web player” और “every web app framework” है
- लागू करने की प्रक्रिया 3 आसान चरणों में बनी है
- पसंद की player theme चुनें
- इस्तेमाल करने वाला player और app framework चुनें
- जनरेट किया गया code copy-paste करें
- प्लेयर UI को सिर्फ HTML और CSS से बारीकी से समायोजित किया जा सकता है
- फ़िल्टर और settings में ये शामिल हैं
- मीडिया: Video, Audio
- framework: HTML, React, Next.js, Vue, Svelte
- features: timeline thumbnails, AirPlay, Google Cast, chapters, tooltips
- colors: Primary, Secondary, Accent
वेब प्लेयर theme gallery
- Sutro: SF TV antenna के नाम से लिया गया, परिष्कृत और आधुनिक theme
- X-mas: लाल-हरा टोन, चमकती लाइट्स और साल के अंत का माहौल रखने वाला Christmas theme
- Halloween: वीडियो प्लेयर में Halloween का माहौल जोड़ने वाला theme
- Instaplay: लोकप्रिय social media app के playback अनुभव से प्रेरित mobile-first theme
- Sutro Audio: Sutro जैसी ही व्याख्या वाला audio theme
- Notflix: “बड़े लाल N” और Los Gatos जाने वाली लंबी बस को छोड़कर बाकी अनुभव का संकेत देने वाला theme
- Reelplay: पुराने मीडिया प्लेयर्स से प्रेरित retro media player theme
- Vimeonova: क्लासिक Vimeo player design की नई व्याख्या करने वाला theme
- YT: आधुनिक और व्यापक रूप से इस्तेमाल होने वाले YouTube player को समर्पित, Web Components के साथ यथासंभव करीब से फिर से बनाया गया theme
- Tailwind Audio: Tailwind CSS से बना minimal audio player theme
- Demuxed 2022: Demuxed 2022 के लिए बनाया गया media player theme
- Microvideo: लंबे कंटेंट के लिए ज़रूरी मजबूत playback controls की आवश्यकता न रखने वाले short-form content के लिए बना theme
- Minimal: Mux Player अनुभव को दर्शकों के लिए ज़रूरी basic controls तक सीमित करने वाला सरल theme
- Winamp: क्लासिक Winamp media player से प्रेरित retro theme
1 टिप्पणियां
Hacker News टिप्पणियाँ
अगर आपको सिर्फ संगीत चाहिए, वीडियो नहीं, तो https://webamp.org/ भी देखने लायक है
“compile” करने या बड़े स्तर पर “integrate” करने की ज़रूरत नहीं; बस इसे include कर दें, और playlist ऐप में बना लें। उदाहरण: Music
यह idea पसंद आया और इसे MIT license के तहत जारी करने के लिए धन्यवाद
मैं भी इसी समय एक media app, ठीक कहें तो video editor, बना रहा हूँ और पहले Flash और HTML/JS में कुछ video players भी बना चुका हूँ। लगभग 2015 में एक player में web components आज़माए थे, लेकिन वे लगातार तकलीफ़देह रहे, इसलिए आखिरकार साधारण JavaScript पर लौट आया। अजीब बात है कि अपने मौजूदा media app में मैं video editor timeline जैसे web components इस्तेमाल कर रहा हूँ, और अब तक यह काफ़ी ठीक चल रहा है। पता नहीं क्या बदला है, या web की धीमी प्रगति की वजह से compatibility अब पर्याप्त हो गई है
Media Chrome documentation को सरसरी तौर पर देखा और GitHub repository भी जल्दी से देखी, लेकिन design principles और architecture notes मुझे पसंद आए। ऐसी चीज़ अपनाते समय, खासकर जब मैंने ऐसी चीज़ें खुद कई बार बनाई हों, तो मेरी सबसे बड़ी चिंताएँ extensibility और file size होती हैं। उदाहरण के लिए, मुझे उत्सुकता है कि मेरी timeline component को MediaController paradigm के हिसाब से ढालना कितना मुश्किल होगा। सब कुछ खुद बनाने का फायदा यह है कि सिर्फ वही रहता है जिसकी ज़रूरत है, उससे ज़्यादा कुछ नहीं। Media Chrome में ऐसी कई सुविधाएँ होंगी जिन्हें मैं कभी इस्तेमाल नहीं करूँगा, तो सवाल है कि उनकी वजह से कितना अनचाहा भार उठाना पड़ेगा। यह सिर्फ उन components के बारे में नहीं जिन्हें इस्तेमाल नहीं करूँगा, बल्कि इस्तेमाल किए जाने वाले components के भीतर की अनइस्तेमाल सुविधाओं पर भी लागू होता है। कभी-कभी मौजूदा अनावश्यक features lower-level extensibility में भी बाधा बन जाते हैं
साथ ही,
media-elementsrepository [1] में license file नहीं है। package.json में elements को भी MIT बताया गया है, लेकिन एक स्पष्ट LICENSE file होना हमेशा अच्छा रहता हैफिर भी यह library काफ़ी आकर्षक लगती है। कम से कम अब तक, जिस page में इसे include किया जाता था वही elements को जोड़ता था, लेकिन मैं बेहतर abstraction चाहता था, इसलिए अपने components को media-controller जैसे element से wrap करने का idea शायद मैं अपना लूँगा
उस बीच web components spec v2 आया था, लेकिन क्या बदला इस पर मैं expert नहीं हूँ। अब web components इधर-उधर दिखने लगे हैं, खासकर media players में। उदाहरण के लिए Apple का web player है
खुशी है कि आपको controller architecture पसंद आया। शुरुआती version में सभी elements सीधे media element की ओर इशारा करते थे, और controller आने से बहुत सफ़ाई आ गई। कम से कम मेरे अपने पुराने तरीके की तुलना में, मैं इसे strongly recommend करता हूँ
video editor UI मुझे Media Chrome family का natural extension लगता है। उस दिशा में क्या और मददगार होगा, अगर repository में issue के तौर पर बता दें तो अच्छा होगा
भविष्य की flexibility और size की वजह से Media Chrome जैसी चीज़ अपनाने में हिचकिचाहट मैं गहराई से समझता हूँ। मुझे मनाने के लिए 3 points काफ़ी होते। 1) आप सिर्फ़ ज़रूरी UI components include कर सकते हैं, और size के मामले में यह दूसरे web video players से बड़ा अंतर है। 2) accessibility और आगे की internationalization जैसी चीज़ों सहित, सबसे अनुभवी player developers इस पर काम कर रहे हैं। 3) slots, CSS parts और CSS variables के बीच इसे बहुत configurable बनाने की कोशिश हो रही है
बेशक यह पूरी तरह custom software के file size को नहीं हरा सकता, लेकिन basic features पूरे हो जाने पर शायद काफ़ी करीब पहुँच जाएगा। elements license के बारे में बताने के लिए धन्यवाद
Mux की marketing strategy समझदार है
video package ढूँढने वाले developers के सामने आखिरकार company का नाम आए, इसलिए वे open source projects को acquire करते हैं या नए बनाते हैं
हाल में देखा गया एक और उदाहरण https://github.com/cookpete/react-player है
open source players की तरफ़ दिखने वाली कुछ बातें इसलिए भी हैं क्योंकि किसी न किसी तरह हमें ऐसे projects को support करना ही पड़ता है। हम player-agnostic हैं, इसलिए हमारे customers कई open source projects इस्तेमाल करते हैं, जिनमें ऐसे projects भी शामिल हैं जिनका maintenance बहुत सक्रिय नहीं है
इस समय developer-focused video companies में open source में सक्रिय योगदान देने वाली बहुत कम हैं, इसलिए मुझे लगता है कि हमें इसका लाभ मिल रहा है
Mux अच्छा दिखता है, लेकिन मुझे भरोसा नहीं कि कंपनी free video encoding tier को जारी रखेगी, इसलिए शायद मैं उसके ऊपर कुछ नहीं बनाऊंगा
यूज़र के लिए on-demand encoding भी resource के लिहाज़ से थोड़ी अव्यावहारिक लगती है। starter model में 10 डॉलर देकर 100 डॉलर के credits खरीदने की व्यवस्था है। सब कुछ एक बड़े loss leader जैसा दिखता है, और ऐसी कंपनी पर भरोसा करना मुश्किल होता जा रहा है जो रोज़ पैसे जला रही हो। बेहतर होता कि वे कुछ न कुछ charge करते। मुझे पता है कि encoding free नहीं होती। या फिर साइट पर एक section हो जो समझाए कि वे industry में सभी से कम कीमत लेकर भी business कैसे चला सकते हैं, तो शक काफी कम हो सकता है। SaaS से बहुत बार जल चुका हूं
“industry में सभी से कम कीमत लेकर भी business कैसे चला सकते हैं, यह समझाने वाला section” वाकई अच्छा feedback है, और इसे to-do list में डालूंगा। यह ज़रूर होना चाहिए
हम ऐसी pricing नहीं रखेंगे जिसकी economics हम afford न कर सकें, और कम-से-कम उसे afford करने का साफ रास्ता तो होना ही चाहिए। volume के हिसाब से सभी prices public हैं, इसलिए अगर आप credits जैसी concept समझते हैं, तो bait के बाद price बदलने जैसी स्थिति नहीं होनी चाहिए। यह कुछ competitors के उलट है, जो scale बढ़ने पर users को नई pricing से चौंका देते हैं। मुझे वह तरीका सचमुच नापसंद है
internally हम just-in-time encoding और दूसरी advanced optimizations का इस्तेमाल करते हैं, जिससे हमें edge मिलता है। economies of scale भी हैं, और इस पर एक post लिखने का इरादा है
लेकिन customer perception मुश्किल है। कुछ customers encoding और उसकी cost, साथ ही adaptive streaming या user-generated uploads संभालने जैसे फायदे समझते हैं। कई developers video में नए होते हैं, इसलिए उम्मीद करते हैं कि यह MP4 को S3 पर रखने जितना ही खर्च होगा। कोई competitor का हवाला देता है जहां encoding cost नहीं है, कोई YouTube की वजह से कहता है कि यह और सस्ता होना चाहिए। पहले Mux encoding cost charge करता था, इसलिए उसे “महंगा option” माना गया, और इसी वजह से हम नया pricing structure बना रहे हैं: economically sustainable lower encoding level से शुरुआत, और फिर अगर value दिखे तो higher encoding cost/value level चुनने का विकल्प। इसका कुछ हिस्सा launch हो चुका है और कुछ आने वाला है
हमारा मानना है कि video आज से भी ज़्यादा जगहों पर होना चाहिए, लेकिन apps बनाते समय आने वाली कई दूसरी costs की तुलना में video inherently महंगा है। इसलिए हमारा काम है costs को लगातार कम करना और pricing structure को refine करना, ताकि ज़्यादा use cases में video इस्तेमाल हो सके
free encoding इस्तेमाल करने के trade-offs यहां लिखे हैं: https://docs.mux.com/guides/use-video-quality-levels. free basic encoding में भी storage और delivery costs फिर भी लगती हैं। उम्मीद है कि शुरुआत में cost कम करने में मदद करके हम साथ-साथ grow कर सकेंगे
on-demand, यानी JIT encoding, असल में कितनी consistently अच्छी तरह काम करती है यह देखकर जादू जैसा लगता है
मैं Mux में काम करता हूं
यहां focus handling में कुछ अजीब चीज़ें हैं। उम्मीद है इसे constructive criticism के तौर पर लिया जाएगा, और सबमें वही समस्या है
video पर ही click करने पर left/right arrow keys से video में आगे-पीछे जा सकते हैं। up/down कुछ नहीं करते
navigation bar पर click करने पर left/right arrow keys काम करना बंद कर देती हैं। इसके बजाय up/down arrow keys अलग time intervals में rewind/forward करने लगती हैं
Winamp example या Reelplay example में Windows 98 जैसी दिखने वाली नीली bar जैसी खाली जगह पर click करने पर ये controls सब काम करना बंद कर देते हैं, और spacebar से play/pause भी नहीं होता
macOS के latest Chrome में देखा
आम तौर पर video control करने वाले “shortcuts”, हर component के accessibility controls, और पूरे page की general accessibility expectations overlap होती हैं, इसलिए स्थिति थोड़ी जटिल हो जाती है। उदाहरण के लिए, जब player पर focus हो तो up/down arrows को हमेशा volume control के लिए पकड़ना चाहिए या नहीं, जबकि लोग उन्हें page scroll के लिए इस्तेमाल करने की उम्मीद कर सकते हैं—ऐसे सवाल हैं
खैर, इस हिस्से में आगे और iterations करनी होंगी, इसलिए feedback मददगार है
Player.style शानदार है
पिछले startup में मैंने video.js theme खुद बनाना शुरू किया था, फिर कुछ घंटों बाद तय किया कि यह मेरे समय के लायक नहीं है और defaults इस्तेमाल किए। आगे ऐसी themes ज़्यादा customized चीज़ बनाने के लिए कहीं बेहतर starting point लगेंगी
चूंकि इस thread में video experts हैं, मैं जानना चाहता हूं कि क्या ऐसा कोई player implementation है जो audio के साथ तेज़ और smooth seeking संभव बनाता हो
मेरा मतलब Adobe Premiere में timeline को 16x speed पर scrub या देख पाने जैसी सुविधा से है। शायद 16kHz mono audio track और 1fps sprite या सिर्फ I-frames वाले 240p video format जैसी चीज़ को पहले से aggressively load रखना होगा, और seeking के समय उसी पर switch करना होगा
कोई पक्का जवाब नहीं है, लेकिन WebCodecs के क्षेत्र को देखना अच्छा रहेगा, जहां lower level पर high-performance examples बन रहे हैं: https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...
Web Components शानदार हैं, और Mux उनमें बढ़िया काम कर रहा है
कोड को YouTube embed के साथ काम करने के लिए अनुकूलित किया जा सकता है
YouTube embed
srcमें ये सेट करना होगाcontrols=0– play, pause, volume जैसे player controls हटाता हैmodestbranding=1– player के अंदर YouTube logo को न्यूनतम करता हैrel=0– अंत में संबंधित वीडियो दिखाने से रोकता है। यह केवल उसी channel के वीडियो दिखाने के तरीके से ही काम करता हैshowinfo=0– वीडियो title और uploader जानकारी हटाता है। यह parameter deprecated हो चुका है, लेकिनmodestbrandingमदद करता हैfs=0– fullscreen button को disable करता हैiv_load_policy=3– pop-up notifications जैसी video annotations छिपाता हैइसके बाद code में YouTube embed URL detect करके,
videotag के बजायiframeसे player बनाया जा सकता है। आखिर में player controls को YouTube embed API से map करना होगा। Plyr.io ने भी कुछ ऐसा ही किया थाWinamp से कुछ हद तक मिलता-जुलता कुछ बना देने से वह Winamp नहीं बन जाता