👽 👂🏼 🛫 एचटीएमएल 5 ऑडियो - स्थिति। भाग २ 🐌 🕐 👩🏿‍🤝‍👩🏻

(फ्रंटएंड और मीडिया टैग विशेषज्ञ मार्क बोस का एक लेख 8 मई, 2012 को। अंतिम भाग का अनुवाद। शुरुआत ने स्पष्ट कर दिया कि आपको पूरी रसोई में महारत हासिल करने से पहले पसीना बहाना होगा, लेकिन यह अभी भी विकसित हो रहा है ... लघु व्यंजनों की प्रतीक्षा न करें।)

पहले भाग की सामग्री:
■ MIME प्रकार
● सर्वर भाग
● ग्राहक भाग
अग्रिम में ऑडियो के प्रकार को जानने में मदद मिलेगी .canPlayType (शायद)
ब्राउज़रों में वर्तमान कोडेक समर्थन
■ कंटेनर प्रारूप और फ़ाइल एक्सटेंशन
■ हमारे पास एक <ऑडियो> टैग है और इसका उपयोग करने से डरते नहीं हैं!
■ बफरिंग, खोज और प्लेबैक अंतराल
● बफर विशेषता
● TimeRanges ऑब्जेक्ट
● मांगने और खोजने योग्य विशेषताएँ

● मांगने और खोजने योग्य विशेषताएँ

मीडिया फ़ाइल के संदर्भ में खोज मीडिया फ़ाइल में आगे या पीछे दिख रही है। यह आमतौर पर तब होता है जब पूर्ण फ़ाइल बफ़रिंग अभी तक पूर्ण नहीं है। यह मांगने की विशेषता का उपयोग यह दर्शाने के लिए किया जाता है कि "तलाश" घटना हुई है। यह सच है कि फ़ाइल का हिस्सा अभी तक अपलोड नहीं किया गया है।

यह हास्यास्पद है : सफारी / विंडोज को छोड़कर सभी आधुनिक ब्राउज़रों में एक खोजी विशेषता है, जिसका अर्थ है कि मांगने वाली घटना कभी नहीं होगी, ताकि उपयोगकर्ता सीधे कार्यक्रम के वांछित भाग में जा सके। खोजी घटना घटित नहीं होती है , जो कुछ लोगों को यह विश्वास दिलाती है कि " चाहने वाले == सच्चे " हमेशा मांगे गए आयोजन से पहले होने चाहिए।

याद रखें कि बफ़र्ड संपत्ति कहती है कि कौन से हिस्से लोड किए गए थे, जो अक्सर प्लेबैक तत्परता के संकेतक के रूप में उपयोग किया जाता है। यदि ब्राउज़र समर्थन करता है, तो यह सुनिश्चित करने के लिए कि फ़ाइल के किस हिस्से को अपलोड किया गया है, को खोजने योग्य विशेषता का उपयोग करने का कोई मतलब हो सकता है।

खोज योग्य समय-सार वस्तु लौटाता है - अंतराल जो तत्काल प्लेबैक के लिए तैयार हैं। यह "बाइट-रेंज-रिक्वेस्ट" के रूप में जानी जाने वाली एक तकनीक का उपयोग करता है, जो आपको HTTP अनुरोधों के अंत में कड़ाई से डेटा का हिस्सा अनुरोध करने की अनुमति नहीं देता है, लेकिन पहले, जबकि अभी भी अनुरोध हैं। दूसरे शब्दों में, हमारे पास मीडिया चलाने के लिए सारा डेटा नहीं है। उदाहरण:

var isSeeking = audio.seeking; //     ""? //   seekable, ,    "" var isSeekable = audio.seekable && audio.seekable.length > 0; //   ,       var seekableEnd = audio.seekable.end();

नोट : अंतराल भ्रामक हो सकता है। Audio.seekable.end () वास्तव में अंतिम अंतराल के समापन बिंदु को इंगित करता है, संपूर्ण मीडिया फ़ाइल के समापन बिंदु को नहीं। व्यवहार में, हालांकि, यह पर्याप्त है, क्योंकि ब्राउज़र या तो कई अनुरोध देता है या नहीं। यदि यह पता चलता है कि कोई अनुरोध नहीं थे, तो ऑडियो.सेकेबल ऑडियो.buffered के बराबर होगा, जो फ़ाइल में अंतराल के अंत का सही संकेत देगा।

ध्यान दें कि खोज योग्य अवस्था में प्लेबैक अनुभाग उन बफ़र्ड अवस्था से भिन्न होते हैं। वे एक ही समय में दोनों नहीं हो सकते।

मजेदार : व्यवहार में, केवल एक TimeRanges ऑब्जेक्ट ही खोजी संपत्ति में बनाया जाता है। अंतराल अनुरोधों का समर्थन करने वाले ब्राउज़र में, TimeRanges ऑब्जेक्ट शून्य से प्लेबैक समय के अंत तक फैली हुई है, असमर्थित लोगों में, TimeRanges लोड होने से शून्य से अंत तक बढ़ता है।

बफरिंग और डेटा पुनर्प्राप्ति उपयोगी जानकारी प्रदान कर सकते हैं, लेकिन यह बहुत आसान होगा यदि कुछ बिंदुओं के लिए नहीं।

1. पुराने पुराने ब्राउज़रों (ओपेरा 10 / फ़ायरफ़ॉक्स 3.6) में प्रीलोडिंग समर्थित नहीं है।
2. बफ़र्ड विशेषता हमेशा समर्थित नहीं होती है (ब्लैकबेरी प्लेबुक)।
3. सभी HTML5 ब्राउज़र बाइट-रेंज खोज का समर्थन नहीं करते हैं, उदाहरण के लिए, सफारी / विंडोज। इस मामले में, लोड की गई सामग्री के लिए खोज बनी रहती है, जैसा कि फ्लैश करता है।

यदि आप उपयोगकर्ताओं को सर्वश्रेष्ठ समाधान देना चाहते हैं, तो निहित क्षमताओं का परीक्षण करें।

● प्रीलोड के बारे में ध्यान दें

मैंने पिछले लेख में प्रीलोड विशेषता का उल्लेख किया है। यह 3 संभावित मान लेता है:
1. कोई नहीं - कुछ भी प्रीलोड नहीं करता है। कुछ भी डाउनलोड करने से पहले प्ले इवेंट की प्रतीक्षा करें।
2. मेटाडेटा - केवल मेटाडेटा को प्रीलोड करता है। अंतराल अनुरोध के माध्यम से फ़ाइल की शुरुआत और अंत हो जाता है और प्लेबैक की अवधि निर्धारित करता है।
3. ऑटो - पूरी फाइल को प्री लोड करता है। फ़ाइल की शुरुआत और अंत हो जाता है, और फिर फ़ाइल की शुरुआत से डाउनलोड करने के लिए फिर से आगे बढ़ता है।

मजेदार : मोबाइल सफारी प्रीलोड विशेषता को अनदेखा करता है, जो इसमें हमेशा " कोई नहीं " होता है।

जब यह प्री-लोडिंग की बात आती है, तो याद रखें कि यह ब्राउज़र के लिए एक अनुरोध या इच्छा है कि आप प्रीलोडिंग प्रक्रिया को कैसे देखना चाहते हैं। ब्राउज़रों को इसे लागू करने की आवश्यकता नहीं है, इसलिए वे अलग-अलग तरीकों से काम कर सकते हैं।

● सफलतापूर्वक खेला गया

यह ध्यान दिया जाना चाहिए कि एक खेला संपत्ति है जो रिपोर्ट करती है कि क्या अंतराल पूरी तरह से पुन: पेश किए गए हैं।

 var played = audio.played; //   TimeRanges

नोट : यदि हम सभी ऑडियो.प्लेट किए गए अंतराल को संक्षेप में प्रस्तुत करते हैं, तो हमें उस ऑडियो का अंश मिलता है, जिसे सुना गया था, जो मैट्रिक्स को इकट्ठा करने के लिए उपयोगी हो सकता है।

■ मीडिया की घटनाओं

ऑडियो और वीडियो इंटरफ़ेस एपीआई घटनाओं के एक पूरे सेट पर आधारित है। एक पूरी सूची विनिर्देश के WhatWG संस्करण में उपलब्ध है।

मीडिया इवेंट संचालकों को स्थापित करने से नियंत्रण की स्थिति में परिवर्तनों को ट्रैक करना आसान हो जाता है। उदाहरण के लिए, प्रत्येक टाइमअपडेट ईवेंट के लिए खेलने के समय को अपडेट करने के लिए यह उपयोगी है।

आमतौर पर इस्तेमाल की जाने वाली घटनाओं की एक छोटी सूची:

घटना	विवरण
durationchange	अद्यतन अवधि विशेषता
समाप्त	अंत तक पहुँचने पर प्लेबैक रुक गया
ठहराव	प्लेबैक को रोक दिया गया है ( स्टॉप इवेंट की अनुपस्थिति पर ध्यान दें)
खेलने	फाइल चलने लगी
timeupdate	वर्तमान प्लेबैक स्थिति बदल गई है (आमतौर पर हर 250 एमएस)
volumechange	मान बदल गया है

युक्ति : Android (कम से कम 2.3) हमेशा समाप्त हुई घटना को नहीं बढ़ाता है। ठीक है, चलो बस कहते हैं, यह कभी-कभी शालीनता के लिए एक बनाता है, लेकिन सामान्य तौर पर, आपको अपना स्वयं का ईवेंट बनाना होगा, जब यह मीडिया फ़ाइल के अंत तक पहुंचता है और ऑडियो.डाउंटर के साथ audio.currentTime की तुलना करते हुए ठहराव घटना को कैप्चर करता है । या आप पॉज़ ईवेंट को सुखा सकते हैं और सुनिश्चित कर सकते हैं कि Audio.currentTime शून्य है। पूरी तरह से निश्चित होने के लिए, आपको दोनों करने की आवश्यकता है।

कुछ अन्य घटनाएँ:

घटना	विवरण
canplay	फ़ाइल वापस खेली जा सकती है, लेकिन इसे लोड करने में कुछ समय लग सकता है।
canplaythrough	मौजूदा डाउनलोड दर पर, यह माना जाता है कि फ़ाइल को बिना किसी रुकावट के शुरू से अंत तक खेला जा सकता है।
प्रगति	ब्राउज़र प्लेबैक स्थिति (आमतौर पर हर 250 एमएस) दिखाता है

फिर से, HTML5 मीडिया इवेंट इंस्पेक्टर अनुकूल है।

आप areweplayingyet.org के साथ ब्राउज़र समर्थन का परीक्षण कर सकते हैं। यह कोड और परीक्षणों को देखने के लायक है कि क्या हो रहा है की व्यवस्था को समझने के लिए।

■ स्ट्रीमिंग

मीडिया नियंत्रण के लिए स्ट्रीमिंग ऑडियो एक आम आवश्यकता है। कुछ समय पहले तक, एडोब फ्लैश तकनीक इस क्षेत्र पर हावी थी। मालिकाना सर्वर प्रौद्योगिकियों अच्छी तरह से जाना जाता है। उनमें से एक प्रमुख है एडोब का रियल टाइम मैसेजिंग प्रोटोकॉल ( RTMP )। हालाँकि, आधुनिक ब्राउज़र केवल HTTP प्रोटोकॉल पर स्ट्रीमिंग का समर्थन करते हैं, और फ्लैश के समान कुछ भी RTMP स्ट्रीम की आवश्यकता होती है।

अब ब्राउज़र, अगर वे समर्थन करते हैं, तो केवल SHOUTcast और Icecast सर्वर जो HTTP के माध्यम से ऑडियो चलाते हैं। SHOUTcast मालिकाना है और केवल MP3 और AAC फ़ाइलें खेलता है, और Icecast खुला है और Ogg Vorbis, MP3 और AAC का समर्थन करता है।

धारा	एएसी	एमपी 3	जीजी vorbis	मूल समर्थन
Icecast	हां	हां	हां	हां
Shoutcast	हां	हां	नहीं	हां
RTMP	हां	हां	नहीं	नहीं (फ़्लैश आवश्यक)

विनिर्देशों का विकास (या "टी डिवा! यह दुर्घटना है!")

जैसा कि ऑडियो विनिर्देश विकसित होते हैं, ब्राउज़र कार्यान्वयन में कई विसंगतियां हैं जो ध्यान में रखने योग्य हैं। वे आमतौर पर पुराने ब्राउज़रों में दिखाई देते हैं।

● लोड विधि

कुछ समय पहले तक, लोड विधि ने ब्राउज़र को मीडिया फ़ाइल में बदलाव के बारे में सूचित किया और नियंत्रण परिवर्तन किया। अब यह आइटम को रीसेट करता है और खरोंच से एक नया संसाधन लोड करना और लोड करना शुरू करता है।

इस प्रकार, फ़ायरफ़ॉक्स 3.6 जैसे पुराने ब्राउज़रों के लिए, सूचना के स्रोत को बदलने के लिए, आपको न केवल विधि में मूल्य को बदलना होगा, बल्कि कमांड को भी निष्पादित करना होगा:

 var audio = new Audio(); audio.setAttribute("src","mynew.mp3"); audio.load(); //

● ब्राउज़र आधिकारिक दस्तावेज पर कब लौटेंगे?

क्रॉस-ब्राउज़र समाधान के लिए, यह जानना उपयोगी है कि कौन से ब्राउज़र W3C प्रलेखन का समर्थन करते हैं और वे किस हद तक और कैसे इससे विचलित होते हैं।

● ऑटो प्ले और वॉल्यूम

iOS और ब्लैकबेरी ऑटोप्ले विशेषता और वॉल्यूम नियंत्रण मीडिया तत्व की उपेक्षा करते हैं, जबकि एंड्रॉइड ऑटोप्ले का समर्थन करता है, लेकिन इसमें वॉल्यूम तत्व नहीं है।

वास्तव में, ब्लैकबेरी और आईओएस पर, ऑटोरन अक्षम है, क्योंकि दोनों प्रणालियों को उन्हें "किक" करने के लिए उपयोगकर्ता की अनुमति की आवश्यकता होती है। यह एक दुर्भाग्यपूर्ण दुष्प्रभाव है: ऑडियो का कोई भी प्लेबैक अन्तरक्रियाशीलता में आवश्यक देरी से ग्रस्त है।

इन असुविधाओं को कम करने के लिए, आप आईओएस में ऑडियो स्प्राइट्स को ठीक करने पर डॉ रेमी शार्प के उत्कृष्ट लेख को पढ़ सकते हैं ।

● कई ऑडियो टैग का एक साथ प्लेबैक

विशेष रूप से सब कुछ (विशेष रूप से खेल) के डेवलपर्स को परेशान करना, सबसे सरल अनुप्रयोगों को छोड़कर, कुछ ब्राउज़रों की अक्षमता (फिर से हम एक जोड़े को देखते हैं: आईओएस और ब्लैकबेरी) एक साथ कई ट्रैक खेलने के लिए।

● ओएस पर निर्भर

युक्ति : डेवलपर्स द्वारा इस पद्धति के सीमित उपयोग के बावजूद, आप अन्य कोडेक स्थापित कर सकते हैं जो ओएस में निर्मित नहीं होते हैं, जैसे कि ओग वोरबिस, और ब्राउज़र जो ऑपरेटिंग सिस्टम के कोडेक्स का उपयोग करते हैं, उन्हें समर्थन देना शुरू कर देना चाहिए।

सफारी (5+) क्विकटाइम सेटिंग्स पर निर्भर करती है । विंडोज का उपयोग करने पर यह शायद ही कभी एक समस्या है।

इंटरनेट एक्सप्लोरर (9+) ऑपरेटिंग सिस्टम के कोडेक्स का उपयोग करता है। चूंकि यह केवल विंडोज पर काम करता है, सौभाग्य से, यह लगभग हमेशा ही होता है।

■ क्या है?

वेब ऑडियो के लिए कुछ नई सुविधाओं और एक नए एपीआई को स्पष्ट किया जा रहा है, तो आइए निकट भविष्य पर एक नज़र डालते हैं।

● चरण परिवर्तन

भविष्य के कार्यों के एक जोड़े पर ध्यान दें: प्लेबैकरेट और डिफॉल्टप्लेटबैक । वे प्लेबैक की गति और दिशा को बदलते हैं - तेजी से आगे और पीछे के कार्यों के लिए, या शायद उपयोगकर्ताओं को प्रति दिन अधिक पॉडकास्ट सुनने के लिए सुनने की गति को समायोजित करने की अनुमति देते हैं।

● Audio.playbackRate सामान्य गति से 1 रिटर्न देता है और गति गुणक के रूप में कार्य करता है। उदाहरण के लिए, प्लेबैक 2 सेट करना गति को दोगुना कर देगा, जब इसे -1 पर सेट करना है, तो खेल विपरीत दिशा में खेलेंगे।
● Audio.defaultPlaybackRate - इस तरह के ठहराव, पुनः आरंभ या घटना के बाद डिफ़ॉल्ट मीडिया गति।

● मीडिया के टुकड़े

यदि हम अब मीडिया फ़ाइल के भाग को संदर्भित करना चाहते हैं, तो हमें सबसे अधिक बार उस फ़ाइल के कम से कम भाग को डाउनलोड करने की आवश्यकता होती है जिसकी वास्तव में आवश्यकता नहीं है। इस प्रश्न और अन्य को हल करने के लिए मीडिया के टुकड़े के लिए W3C ऑफ़र बनाए गए थे, उदाहरण के लिए, पटरियों के वीडियो क्षेत्र या बस संबंधित पाठ (ऑडियो टैग, लेबल) की खोज। ऑडियो के लिए, हम URI मापदंडों के साथ बता सकते हैं कि हम किन भागों को लोड करना चाहते हैं।

■ उन्नत ऑडियो एपीआई: ब्राउज़र में भविष्य की ध्वनि

जब यह उन्नत ऑडियो के लिए आया, तो मोज़िला ने पहली बार फ़ायरफ़ॉक्स के लिए प्रारंभिक प्रायोगिक ऑडियो डेटा एपीआई पेश किया। यह जावास्क्रिप्ट में ऑडियो के साथ काम करने और निम्न-स्तरीय विकास के लिए एक मंच बनाने में मदद करनी चाहिए।

Google ने बनाए रखने के लिए, Chrome के लिए वेब ऑडियो API जारी किया है और इसे W3C प्रस्ताव के रूप में आगे रखा है। वेब ऑडियो एपीआई एक उच्च-स्तरीय कार्यान्वयन है जो ऑडियो ऑब्जेक्ट्स को ऑडियो नोड्स के रूप में ले जाता है और कई उपयोगी सुविधाएँ प्रदान करता है।

दोनों कार्यान्वयन ऑडियो के साथ डेवलपर्स की इच्छा को प्रतिबिंबित करते हैं - मक्खी पर ऑडियो बनाना, प्रबंधित करना, विश्लेषण करना और मिश्रण करना। वास्तव में, एक दिन हम ब्राउज़र में ऐसा करने में सक्षम हो सकते हैं जो हम केवल देशी ओएस अनुप्रयोगों में कर सकते हैं।

तो, क्या हम एक ब्राउज़र में उन्नत ऑडियो के साथ काम करना चाहते हैं? खैर, दो अलग-अलग कार्यान्वयन पहले से मौजूद हैं। यदि आप एपीआई के आधार पर आवेदन लिखना चाहते हैं, तो आपको मतभेदों के सार के लिए तीसरे पक्ष के क्रॉस-लाइब्रेरी बनाने की आवश्यकता है।

एक काफी नया मोज़िला मीडियास्ट्रीम प्रोसेसिंग एपीआई दिखाई दिया है , जो उच्च और निम्न स्तर पर ऑडियो और वीडियो स्ट्रीम को नियंत्रित करने की क्षमता के साथ एक अलग दृष्टिकोण का उपयोग करता है।

वास्तव में, आधुनिक एपीआई का उपयोग करते हुए, आधुनिक जावास्क्रिप्ट इंजन की गति का उपयोग करके, हम असमर्थित कोडेक्स के लिए डिकोडर भी लिख सकते हैं। वर्तमान में हमारे पास JSMad MP3 डिकोडर और Alac.js दोषरहित डिकोडर है । जाहिर तौर पर FLAC और AAC स्ट्रीम में हैं। आशा है कि भविष्य में हमें ब्राउज़र प्रारूपों के समर्थन के बारे में चिंता नहीं करनी होगी।

आधुनिक इंटरनेट ऑडियो में रुचि रखने वालों के लिए, मैंने " HTML5 ऑडियो एपीआई: हाउ लो कैन गो गो? " लेख में क्रॉस-ब्राउज़र समाधान के लिए दृष्टिकोण और विभिन्न पुस्तकालयों में अंतर के बारे में लिखा है।

अच्छी खबर यह है कि पार्टियां सहमत हैं, ऑडियो पर W3C कार्य समूह में संचार है। ऐसा लगता है कि सब कुछ एकल ऑडियो एपीआई के विचारों के कार्यान्वयन की ओर बढ़ रहा है , जो तेजी से वेब मानक के रूप में प्रकाशन के करीब पहुंच रहा है।

■ निष्कर्ष

यद्यपि वर्तमान एचटीएमएल 5 ऑडियो विनिर्देश के ब्राउज़र कार्यान्वयन में सुधार हो रहा है, फिर भी कुछ समस्याएं हैं जो एक पूर्ण क्रॉस-ब्राउज़र समाधान के निर्माण को रोकती हैं। आपको ब्राउज़र और प्लेटफॉर्म जैसे कि iOS की सीमाओं को जानना होगा। उम्मीदें गायब हो जाएंगी।

"उन्नत ऑडियो" के सामने से अच्छी खबर है: एक नया मानक बनाया जा रहा है , हम ब्राउज़र रचनाकारों के काम के लिए एकल विनिर्देश प्राप्त करने के करीब हैं। उसी समय, जावास्क्रिप्ट पुस्तकालय हैं जो मौजूदा कार्यान्वयन के बीच की खाई को पाटने में मदद करेंगे।

ऐसे संकेत हैं कि हम कोडेक्स पर विभिन्न ब्राउज़रों की निर्भरता का अंत देख सकते हैं। ओपेरा मोबाइल पहले से ही एमपी 3 प्रारूपों का समर्थन करता है जहां ओएस इसका समर्थन करता है, और ऐसा लगता है कि मोज़िला इसे भी बर्दाश्त कर सकता है । यदि यह मोबाइल ब्राउज़र के लिए संभव है, तो सबसे अधिक संभावना है कि डेस्कटॉप ब्राउज़र सूट का पालन करेंगे।

बहुत कुछ बदल रहा है और बहुत कुछ हासिल हो चुका है। कार्यान्वयन अनियमितताओं को सुचारू किया जाता है, मानकों को अपनाया जाता है, और हम बहुत ही दिलचस्प नई तकनीकों का आधार देखते हैं।

ऑनलाइन ऑडियो का भविष्य शानदार लग रहा है!

एचटीएमएल 5 ऑडियो - स्थिति। भाग २