क्या स्ट्रीमिंग के रूप में स्ट्रीमिंग बैंडविड्थ की समान मात्रा का उपयोग करता है?

75

यह मानते हुए कि सामग्री समान गुणवत्ता (ceteris paribus) की है, क्या स्ट्रीमिंग मीडिया (अर्थात वीडियो, ऑडियो) बैंडविड्थ की उतनी ही मात्रा का उपयोग करता है जितना कि इसे डाउनलोड करना?

कहो कि मुझे अमेज़ॅन से एक एचडी फिल्म डाउनलोड करनी थी या इसे स्ट्रीम करना था, क्या यह बैंडविड्थ के बराबर उपयोग होगा?

download streaming data-transfer

— stemie
स्रोत

2

प्रोटोकॉल और कोडेक पर निर्भर करता है: जैसे http के माध्यम से डाउनलोड करें और rtmp के माध्यम से स्ट्रीम करें, या h264 बनाम vp6। IMO इस सवाल की तुलना करने के लिए संपीड़न और डेटा ट्रांसमिशन विधियों की मात्रा को देखते हुए बहुत व्यापक है।

— ज़मानट्स

बस अपने प्रश्न को स्पष्ट करने के लिए। बैंडविड्थ द्वारा आप डेटा दर का उल्लेख कर रहे हैं, फ़ाइल (फिल्म) के आकार का नहीं?

— मैट एच

स्ट्रीमिंग पर डाउनलोड करने का एक फायदा (जो तकनीकी रूप से डाउनलोड हो रहा है, लेकिन केवल एक ही उपयोग के लिए है) यह है कि आप उस सामग्री का अधिक से अधिक बार उपभोग कर सकते हैं, जितना आप चाहते हैं कि आप हर बार उस पर अपना बैंडविड्थ खर्च न करें। कुछ मीडिया प्लेयर ऐसे वीडियो भी चला सकते हैं जिन्हें आप वर्तमान में डाउनलोड कर रहे हैं (पूरी तरह से डाउनलोड नहीं किया गया है), डाउनलोड करने के लाभ के साथ स्ट्रीमिंग का "महसूस" कर रहे हैं।

— एडीटीसी

3

हां मैं डेटा रेट की बात कर रहा हूं। मैंने जो कारण पूछा वह मेरी बहन के साथ असहमति थी और जब मैं ऑनलाइन देखता हूं तो मुझे लगता है कि येहु के जवाबों से अस्पष्ट जवाब मिल सकता है। मुझे लगता है कि बहुत सारे चर हैं जो इस पर निर्भर करते हैं लेकिन मुझे लगा कि यह कम से कम पूछने लायक था।

— स्टेमिनी

2

"कंप्यूटर नेटवर्किंग और कंप्यूटर विज्ञान, बैंडविड्थ, नेटवर्क बैंडविड्थ, डेटा बैंडविड्थ, या डिजिटल बैंडविड्थ में प्रति सेकंड या बिट के व्यक्त बिट्स में व्यक्त या उपलब्ध डेटा संचार संसाधनों की बिट-दर का एक माप है (बिट / एस, kbit / s , Mbit / s, Gbit / s, आदि) - wikipedia.org/wiki/Bandwidth_(computing) "

— स्टेमी

43

यह अक्सर बराबर नहीं होता है।

स्ट्रीमिंग प्रदाता प्रोटोकॉल का उपयोग करते हैं, जैसे कि DASH , मूवी बैंडविड्थ की उपलब्धता और गुणवत्ता की इच्छाओं को गतिशील रूप से समायोजित करने के लिए। तब सर्वर आपके कनेक्शन को रेट-लिमिट कर सकते हैं ताकि आप एक निश्चित राशि (जैसे 10 सेकंड, शायद 30 या एक मिनट) के लिए बफर कर सकें और बाद में आपको केवल वास्तविक समय में सामग्री प्राप्त करने के लिए आवश्यक बैंडविड्थ की मात्रा प्राप्त हो। यह प्रदाता के दृष्टिकोण से एक स्पष्ट अनुकूलन है, क्योंकि यह उपयोगकर्ताओं के बीच बैंडविड्थ को अधिक समान रूप से फैलाता है और इसके अलावा डेटा को व्यर्थ में स्थानांतरित करने से बचता है (उदाहरण के लिए जब उपयोगकर्ता 480 मिनट की फिल्म 10 मिनट के लिए देखता है, बिना रैलिमिटिंग के और एक सामान्य डाउनलिंक के साथ, यह संभावना है कि पहले से डाउनलोड की गई तुलना में बहुत अधिक है, लेकिन तब बर्बाद हो जाता है यदि उपयोगकर्ता वीडियो देखना बंद कर देते हैं)।

स्थानांतरित किए गए डेटा की मात्रा समान है। लेकिन इसे स्ट्रीमिंग में अधिक समय लग सकता है, क्योंकि प्रदाता डेटा ट्रांसफर को वास्तविक समय में दिए गए गुणवत्ता में सामग्री को वितरित करने के लिए आवश्यक दर को सीमित कर सकता है।

Dailymotion उन प्रदाताओं में से एक है जो कनेक्शनों को रेट-लिमिट करते हैं। कम से कम 100 Mbit / s सममितीय कनेक्शन वाले सर्वर से, हम निम्नलिखित व्यवहार देखते हैं:

youtube-dl http://www.dailymotion.com/video/xhc3zz_long-distance-calling-into-the-black-wide-open_music
[dailymotion] xhc3zz: Downloading webpage 
[dailymotion] xhc3zz: Extracting information 
[dailymotion] xhc3zz: Downloading embed page 
[download] Destination: LONG DISTANCE CALLING - ' Into The Black Wide Open '-xhc3zz.mp4 
[download]   5.8% of 51.99MiB at 203.89KiB/s ETA 04:06

यह दर बहुत कम है कि क्या संभव होगा (और अन्य प्रदाताओं के साथ हासिल किया गया है)। इसके अलावा, यदि आप अलग-अलग सामग्री का प्रयास करते हैं, तो आप पाएंगे कि यह दर व्यक्तिगत वीडियो पर अत्यधिक निर्भर है: एक फुलएचडी वीडियो आसानी से> 1 MiB / s के साथ डाउनलोड करता है, जबकि आ म्यूजिक वीडियो जैसे कि यह 200 KiB / s के आसपास या नीचे रहता है ।

इसे पूरा करने के लिए और कुछ संभावित गलतफहमी को दूर करने के लिए: कुछ प्रदाता अपने डाउनलोड की सीमा को अपने क्लाइंट एप्लिकेशन (जैसे कि उनके एचटीएमएल 5 या फ्लैश वीडियो प्लेयर के साथ यूट्यूब) या सर्वर के माध्यम से सीमित कर सकते हैं। यदि वे आपको सर्वर के माध्यम से सीमित नहीं करते हैं, तो डाउनलोडिंग अधिक बैंडविड्थ का उपभोग करेगा, क्योंकि स्ट्रीमिंग के दौरान संभवतः क्लाइंट अनुप्रयोग द्वारा लागू की जाने वाली दर सीमित नहीं होती है। यह मुख्य मामला है जब बैंडविड्थ की खपत मूल प्रश्न के संबंध में अलग है।

मुझे पता है कि यह एक तरह का एक अनौपचारिक साक्ष्य है- मैंने हालांकि इस व्यवहार को लगातार देखा है।

— जोनास शेफर
स्रोत

3

@Pycogeek Youtube DASH का उपयोग करने वाले उदाहरणों में से एक है (यदि यह टिप्पणी आपके लिए समझ में नहीं आती है, तो मेरे द्वारा लिंक किए गए लेख का प्रारंभिक भाग पढ़ें)। तात्पर्य यह है कि ग्राहक जिस खिलाड़ी का उपयोग कर रहा है, उसे किसी भी तरह से वीडियो के अनुक्रमिक विराम का अनुरोध करना चाहिए। यदि खिलाड़ी नहीं चल रहा है तो अधिक स्वाभाविक रूप से अनुरोध करने से रोकने के लिए वहां से कदम उठाना स्वाभाविक है। youtube-dlजब तक वीडियो पूरी तरह से डाउनलोड नहीं हो जाता, तब तक डाउनलोडर्स केवल अधिक जानकारी के लिए अनुरोध करते रहेंगे। इसलिए DASH के साथ स्ट्रीमिंग थोड़ी अधिक ओवरहेड होती है, लेकिन यह संभवतः इसके लायक है (उपयोगकर्ता और प्रदाता दोनों के लिए) और उपेक्षित।

— जोनास श्फर

1

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

— dsollen 15

2

@dsollen: जब तक एक यूडीपी प्रेषक केवल परवाह किए बिना पैकेट को बहने नहीं जा रहा है कि क्या इच्छित प्राप्तकर्ता अभी भी मौजूद है, यूडीपी और टीसीपी दोनों को आवधिक स्वीकृति की आवश्यकता है; दोनों स्थितियों में, कुल ट्रैफ़िक के बहुत छोटे हिस्से का प्रतिनिधित्व करने जा रहे हैं। इसके अलावा, इस तरह से डेटा को प्रारूपित करना कि प्रत्येक पैकेट को समझा जा सके, भले ही पिछला पैकेट सामान्य रूप से प्राप्त न हो, इसका मतलब यह है कि टीसीपी के लिए आवश्यक स्तर से ऊपर का स्तर क्या होगा।

— सुपर

7

यदि मेरे पास पर्याप्त प्रतिनिधि था, तो मैं इस उत्तर को अस्वीकार कर दूंगा: यह प्रश्न का उत्तर नहीं देता है , कुंजी वाक्यांश "समान गुणवत्ता" है। जब एक प्रदाता गुणवत्ता को गिराता है, तो यह क्रेटरिस पेरिबस नहीं है ।

— ज़मानट्स

1

@zamnuts, फिर एक बेहतर पोस्ट करें और समुदाय को निर्णय लेने दें। FWIW, इसका एक छोटा सा सेब और संतरे जब आप विचार करते हैं कि प्रदाता ने गुणवत्ता वाले डिप्स का फैसला किया है, लेकिन मुझे नहीं लगता कि इसका उत्तर इसके बिना पूरा होगा।

— 21:30 बजे पक्कोगोमेज़

19

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

इधर-उधर कूदना (स्किप करना, री-वाइंडिंग इत्यादि) भी उपयोग को प्रभावित कर सकता है - बफर के आगे जाने से एक स्ट्रीम द्वारा उपयोग किए जाने वाले बैंडविड्थ की मात्रा कम हो जाएगी, लेकिन कोई भी री-वाइंडिंग इसे बढ़ा देगा। इसके अलावा एक रुकावट होगी, जिसके कारण उपयोग में वृद्धि होगी (ऊपर देखें), और किसी भी तरह के "थंबनेल पूर्वावलोकन" जैसे कि यूट्यूब और नेटफ्लिक्स का उपयोग भी बैंडविड्थ को थोड़ा बढ़ा देगा।

अंतिम नोट: संपीड़न: यह डाउनलोड के लिए किया जा सकता है, लेकिन धाराओं के लिए इतना नहीं है - यह चेतावनी दी जा रही है कि अधिकांश वीडियो पहले से ही संपीड़ित हैं, इसलिए यहां बहुत कुछ प्राप्त नहीं होगा (हालांकि अल्ट्रा में लाभ के लिए जगह हो सकती है- उच्च संकल्प / गुणवत्ता विभाग)।

— user2813274
स्रोत

7

स्ट्रीमिंग कम बैंडविड्थ का उपयोग करेगा, नेटवर्क शर्तों बुरा कर रहे हैं विशेष रूप से अगर, लेकिन यह एक कीमत पर आता है ।

इस मुद्दे पर डेटा भेजा जाना है। एक डाउनलोड मॉडल में, सभी डेटा को ग्राहक तक पहुंचना चाहिए, सभी सही क्रम में, कोई फर्क नहीं पड़ता कि क्या । यदि नेटवर्क की स्थिति खराब है और डेटा के कुछ बिट क्लाइंट तक नहीं पहुंचते हैं, तो उन्हें नाराज होना चाहिए, और इससे बैंडविड्थ का उपयोग बढ़ जाता है। यदि कुछ डेटा क्रम से बाहर हो जाता है, तो उसे प्रस्तुत करने से पहले वापस रखा जाना चाहिए, और इससे जवाबदेही कम हो जाती है।

स्ट्रीमिंग मॉडल में, यह ठीक है अगर कुछ डेटा क्लाइंट तक नहीं पहुंचता है । यदि आप एक फिल्म स्ट्रीम कर रहे हैं और एक फ्रेम वहाँ नहीं मिलता है, तो आप इसे छोड़ सकते हैं और आगे बढ़ सकते हैं, इसलिए आप रिज़ेंड पर अतिरिक्त बैंडविड्थ का उपयोग नहीं करते हैं। यदि कुछ फ्रेम वहां से निकलते हैं, तो केवल वही खेलते हैं जो आगे बढ़ते हैं; क्षणिक कोलाहल कोई मायने नहीं रखेगा, और इसलिए यह जवाबदेही बढ़ाता है। हालांकि, इसका मतलब यह भी है कि आपको जरूरी पूरा डेटा नहीं मिलता है: जो कुछ भी आप देखते हैं वह वहीं है जो पहले शॉट पर मिला है।

यदि आपको मॉडल के बीच चयन करना है, तो डेटा के साथ क्या करना है, इसके आधार पर चुनें। यदि आप इसे संग्रहीत करना चाहते हैं और / या संभवतः इसे कई बार देखते हैं, तो इसे डाउनलोड करें ताकि आप सब कुछ प्राप्त कर सकें। यदि आप संग्रह करने की योजना नहीं बनाते हैं, या केवल एक बार डेटा देखने की योजना बनाते हैं, तो आगे बढ़ें और स्ट्रीम करें; आप शायद एक भी देखने पर अंतर नहीं देखेंगे, और यदि नेटवर्क की स्थिति इतनी खराब है कि आप नोटिस करते हैं, तो डाउनलोड करना और भी बुरा होगा।

— स्पूनिएस्ट
स्रोत

क्या आप कह रहे हैं कि स्ट्रीमिंग सेवाएं जानबूझकर गिराए गए डेटा को टीसीपी के बजाय यूडीपी का उपयोग करती हैं?

— FreeAsInBeer

1

@ फ्रीएर्सबीयर: हाँ। टीसीपी विश्वसनीयता तंत्र और अन्य सुविधाओं के एक समूह में बनाता है जो अधिकांश कल्पनाशील अनुप्रयोगों के लिए बहुत उपयोगी होते हैं। लेकिन ऐसे मामलों का उपयोग करें जहां मौजूद हैं, जहां चीजें विश्वसनीयता से भी अधिक महत्वपूर्ण हैं, और स्ट्रीमिंग उनमें से एक है: हर एक फ्रेम को दिखाने के बजाय सही समय पर सही फ्रेम दिखाना अधिक महत्वपूर्ण है। ऑनलाइन गेमिंग एक अन्य उदाहरण है जहां यूडीपी लोकप्रिय है, उन्हीं कारणों से: खिलाड़ी राज्यों के निशान को फिर से संगठित करने के लिए कार्रवाई को रोकना सामयिक गिरा राज्य के लिए सही होने से भी बदतर है।

— स्पूनिएस्ट ऑक्ट

दरअसल कई सिस्टम क्लाइंट की तरफ टीसीपी और बफर पर डेटा स्ट्रीम करते हैं। फिल्म की स्ट्रीमिंग के लिए, विलंबता महत्वपूर्ण नहीं है। उपयोगकर्ता को कोई असुविधा नहीं होती है अगर उनमें से कुछ फ्रेम एक बफर में बैठे होने से पहले उन्हें प्रदर्शित करने का समय होता है। लेकिन वीडियो कॉन्फ्रेंसिंग की तरह इंटरैक्टिव usages के लिए, विलंबता महत्वपूर्ण है।

— कास्परड

1

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

— स्पूनिएस्ट

इस थ्रेड में कम से कम भ्रमित करने वाले उत्तर (आज तक)।

— कॉस्मिक ओस्सिफ्रेज

5

यदि आप वास्तव में "बैंडविड्थ" (बाइट्स / सेकंड) और "कुल डेटा" (बाइट्स) नहीं पूछ रहे हैं, तो महत्वपूर्ण सवाल यह है: किस अवधि के दौरान? यदि हम यह मान रहे हैं कि उपयोगकर्ता पूरा वीडियो देखता है और उसी कोडेक / गुणवत्ता आदि को लौटाया जाता है, और स्ट्रीमिंग अनुरोध / प्रतिक्रियाओं के छोटे ओवरहेड को अनदेखा करता है, तो लौटाया गया कुल डेटा बराबर है।

अब, बैंडविड्थ क्या है? आपके प्रश्न को समझने के दो तरीके हैं:

डाउनलोड पूरा होने तक समय के दौरान बैंडविड्थ। स्ट्रीमिंग के लिए आपको उच्च बैंडविड्थ के स्पाइक्स देखने चाहिए (जब अगला चंक अनुरोध किया जाता है) जो शून्य पर वापस जाते हैं जब आप उस चंक को देख रहे होते हैं जब तक कि आप चंक के अंत के पास नहीं होते हैं और बैंडविड्थ में स्पाइक होता है। डाउनलोड करने के लिए, आपको 10 के लिए एक बहुत ही उच्च बैंडविड्थ देखना चाहिए, कहते हैं, 10 मिनट जो पूरी वीडियो डाउनलोड होते ही शून्य हो जाता है। यदि आप अभी प्रयोग बंद कर देते हैं, तो डाउनलोडिंग के लिए बैंडविड्थ स्पष्ट रूप से अधिक है क्योंकि यह आपके डाउनलिंक को अधिकतम करता है जब तक कि यह पूरा नहीं हो जाता।
वीडियो देखने के दौरान बैंडविड्थ। जिस समय वीडियो देखा जा रहा है वह स्ट्रीमिंग और डाउनलोड दोनों के लिए समान है, यह मानते हुए दोनों तुरंत देखना शुरू करते हैं। कुल डेटा का आकार समान है। चूंकि बैंडविड्थ प्रति समय डेटा है, यह दोनों परिदृश्यों के लिए समान है।

नीचे दिए गए उदाहरण में, हमेशा कुल 40 (डेटा की इकाइयाँ) डाउनलोड होती हैं। लेकिन "डाउनलोडिंग" के लिए, यह समय की पहली इकाई में 40 है, जबकि "स्ट्रीमिंग" के लिए यह समय की पहली इकाइयों के दौरान 20 है (एक बड़ा प्रारंभिक हिस्सा प्राप्त करने के लिए) और फिर दो अतिरिक्त विखंडू के लिए दो बार 10। ध्यान दें कि जब बैंडविड्थ को y- अक्ष पर प्लॉट किया जाता है, तो दो ग्राफ़ में से प्रत्येक के नीचे का क्षेत्र डेटा (बाइट्स) से मेल खाता है - यदि आप समय के साथ बाइट्स / समय को एकीकृत करते हैं, तो आपको बाइट्स मिलते हैं।

— mb21
स्रोत

4

वे तुलनीय नहीं हैं।

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

आइए वीडियो एन्कोडिंग के बारे में बात करते हैं।

अधिकांश वीडियो एन्कोडिंग प्रारूप में, आमतौर पर दो प्रकार के फ्रेम होते हैं:

इंट्रा-कोडेड फ्रेम (आई-फ्रेम) - ये ऐसे फ्रेम हैं जिन्हें पूर्ण रूप से स्थानांतरित किया जाता है, इस फ्रेम को किसी अन्य फ्रेम के ज्ञान के बिना डिकोड किया जा सकता है। एक इंट्रा-कोडेड फ्रेम अनिवार्य रूप से एक स्थिर छवि है। अचानक संक्रमण के दौरान एनकोडर इन्हें उत्पन्न करेंगे। ये संपीड़ित करने के लिए कम कुशल हैं।
पूर्वनिर्धारित फ़्रेम (पी-फ़्रेम) या द्वि-पूर्वानुमानित फ़्रेम (बी-फ़्रेम) - ये ऐसे फ्रेम हैं जो केवल फ़्रेम के बीच के अंतर को संग्रहीत करते हैं, यह केवल डिकोड किया जा सकता है यदि दर्शक पिछले और / या बाद के फ़्रेमों को भी जानता है। ये संपीड़ित करने के लिए बहुत अधिक कुशल हैं।

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

इसके अलावा, स्ट्रीमिंग के दो अलग-अलग प्रकार हैं। आपके पास पहले से रिकॉर्ड की गई स्ट्रीम (अधिकांश Youtube वीडियो) और लाइव इवेंट स्ट्रीम (जैसे Youtube लाइव) की स्ट्रीमिंग हो सकती है। विलंबता की आवश्यकता के कारण, लाइव इवेंट को स्ट्रीम करने में उन्नत एन्कोडिंग तकनीकों का लाभ नहीं उठाया जा सकता है, जिसमें एक लंबी या अप्रत्याशित मात्रा में समय लगता है, जबकि पहले से रिकॉर्ड की गई स्ट्रीम में उतना ही समय लग सकता है जितना इसे एन्कोड करने में लगता है।

स्ट्रीम किए गए वीडियो को भी आमतौर पर निरंतर बिट-दर (CBR) के साथ एन्कोड किया जाता है। समान लक्ष्य आकार के लिए, एक चर-बिट दर (VBR) वीडियो में आमतौर पर CBR वीडियो की तुलना में उच्च गुणवत्ता होगी। इसके विपरीत, एक VBR वीडियो CBR वीडियो की समान गुणवत्ता के लिए छोटा होता है। DASH जैसे एक अनुकूली स्ट्रीमिंग प्रोटोकॉल में एक अनुकूली बिटरेट (ABR) है, जो CBR और VBR के बीच एक समझौता है। एबीआर दर्शक को नेटवर्क बैंडविड्थ में बदलाव के अनुकूल होने की अनुमति देता है। एक निरंतर, निरंतर बैंडविड्थ को देखते हुए, एबीआर कमोबेश सीबीआर के समान है।

इन सभी साधनों का मतलब यह है कि समान गुणवत्ता और देखने के अनुभव को देखते हुए , आप स्ट्रीम किए गए वीडियो की तुलना में अधिक कुशलता से स्थानीय देखने के लिए वीडियो को एन्कोड कर सकते हैं, और लाइव स्ट्रीम की तुलना में आप पहले से रिकॉर्ड किए गए स्ट्रीम के लिए अधिक कुशलता से वीडियो को एन्कोड कर सकते हैं।

फिर स्ट्रीमिंग प्रोटोकॉल में एक ओवरहेड भी है। एक नियमित HTTP डाउनलोड पूरी फ़ाइल को डाउनलोड करने के लिए chunked हस्तांतरण एन्कोडिंग का उपयोग कर सकता है जिसमें बहुत कम ओवरहेड है। एक स्ट्रीम किए गए डाउनलोड को ट्रांसफर करने के लिए चंक की गुणवत्ता और गुणवत्ता पर बातचीत करनी होगी। चीजों की भव्य योजना में, स्थानांतरण प्रोटोकॉल का ओवरहेड अपेक्षाकृत मामूली है।

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

— झूठ बोले रेयान
स्रोत

1

उत्तर है, यह निर्भर करता है"।

इसका उत्तर NO है, ऐसे प्रदाताओं के लिए जो सामान्य रूप से वीडियो होस्ट करते हैं। वीडियो को स्ट्रीम करने वाले आधे सभ्य प्रदाता रेट नियंत्रित करते हैं ताकि अधिक से अधिक लोगों के लिए चिकनी प्लेबैक और इष्टतम बैंडविड्थ सुनिश्चित हो सके। इसलिए भले ही आपके पास बहुत सारी बैंडविड्थ हो, यह आपको केवल 5Mbit देने का निर्णय ले सकता है और अभी भी काफी सभ्य दिख सकता है।

यदि आप एक HTTP डाउनलोड करते हैं तो टीसीपी दर नियंत्रण एल्गोरिदम यह सुनिश्चित करने के लिए किक करेगा कि आप कनेक्शन के एक या दोनों सिरों को संतृप्त करें या बीच में कुछ भी। इसलिए यदि आपके पास 100Mbit उपलब्ध था, तो यह 100Mbit के पास या इसके पास मिलने वाले सभी का उपयोग करेगा।

बेशक यह माना जाता है कि क्लाइंट और सर्वर के बीच कहीं भी कोई क्यूओएस नहीं है।

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

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

तो वहाँ आपके पास है ... यह निर्भर करता है।

— मैट एच
स्रोत

"पहले और दूसरे डाउनलोड के बीच की बैंडविड्थ अलग-अलग हो सकती है" लेकिन निश्चित रूप से यह अंत में समान डेटा डाउनलोड कर रहा है, भले ही वह दूसरे की तुलना में अधिक समय लेता हो / नेटवर्क की स्थिति बदल गई हो।

— स्टेमि

@stemie, यह करीब होगा। विभिन्न प्रोटोकॉल प्रोटोकॉल उपरि को जोड़ते हैं। लेकिन अगर स्ट्रीमिंग प्रक्रिया के दौरान कोई ट्रांसकोडिंग या गुणवत्ता / दर में बदलाव नहीं हुआ, तो यह सिद्धांत में वीडियो डेटा की समान मात्रा होनी चाहिए।

— मैट एच

1

नेटवर्क बिंदु से "डाउनलोडिंग" और "स्ट्रीमिंग" अलग-अलग सेवाएं हैं, इसे "ट्रैफ़िक प्रोफ़ाइल" कहा जाता है

स्ट्रीमिंग सेवा के लिए नेटवर्क को एक न्यूनतम निरंतर थ्रूपुट (तकनीकी रूप से "बैंडविड्थ" का अर्थ कुछ अलग करना है) प्रदान करना है, स्ट्रीमिंग सेवा रुकावट और घबराहट के लिए संवेदनशील है। इसमें अधिकतम नेटवर्क थ्रूपुट की आवश्यकता नहीं है, विलंब या विलंबता महत्वपूर्ण नहीं है।

एंड-यूज़र के नज़रिए से इसका मतलब है: वीडियो बिना किसी रोक-टोक या ड्रॉप के आसानी से चलेगा। इससे कोई फर्क नहीं पड़ता कि वीडियो कुछ सेकंड पहले या बाद में शुरू होता है।

"डाउनलोडिंग" में आमतौर पर अधिकतम संभव नेटवर्क थ्रूपुट की आवश्यकता होती है, डाउनलोड को जितना जल्दी हो सके समाप्त कर दिया जाएगा। देरी, रुकावट और घबराना महत्वपूर्ण नहीं हैं।

एक नेटवर्क अधिक ट्रैफ़िक प्रोफाइल प्रदान कर सकता है जो पूरी तरह से अलग हैं। उदाहरण के लिए वॉयस सर्विसेज (साधारण फोन कॉल) requrie बहुत कम थ्रूपुट लेकिन देरी (200 एमएस से कम) के लिए बहुत संवेदनशील हैं

— वर्नफ्रीड डम्सचेत
स्रोत

0

अन्य उत्तरों में जोड़ने के लिए, मेरा उत्तर है: जरूरी नहीं ।

अब, यह मानते हुए कि सब कुछ बराबर है (कोई स्वचालित गुणवत्ता चयन नहीं, सर्वर और / या आईएसपी से कोई थ्रॉटलिंग नहीं) ...

बैंडविड्थ को आमतौर पर कुल_टाइम द्वारा विभाजित size_of_data के रूप में परिभाषित किया जाता है। (तकनीकी रूप से, 'उचित' शब्द थ्रूपुट है , लेकिन मैं पचाता हूं)।

मान लेते हैं कि आप 2000-सेकंड के वीडियो आकार 60 MB को स्ट्रीम करने जा रहे हैं।

स्ट्रीमिंग के साथ, स्ट्रीमर कार्यक्रम हो सकता है अपने स्वयं के दर-सीमित बफर अतिप्रवाह रोकने के लिए क्या। तो, इसके HTTP अनुरोध शीर्षलेख में एक सीमा क्षेत्र शामिल हो सकता है । प्रभावी बैंडविड्थ स्ट्रीमिंग के बाद से स्ट्रीमिंग के समाप्त होने तक शुरू होता है तो ~ 60 एमबी / 2000 सेकंड = 30 KB / s = 240 केबीपीएस होगा।

हालाँकि, यदि आप वीडियो को एकमुश्त डाउनलोड करते हैं, तो आप अपनी इंटरनेट सेवा की अधिकतम बैंडविड्थ तक पहुँच जाएंगे । एक ही समय में, अन्य उपयोग के आधार पर। इसलिए, 50% उपलब्ध बैंडविड्थ के साथ 6 एमबीपीएस की इंटरनेट सेवा संभालने पर, आपको वीडियो डाउनलोडिंग के लिए 3 एमबीपीएस बैंडविड्थ मिलेगी।

— pepoluan
स्रोत

0

स्ट्रीमिंग वास्तव में डाउनलोड करने का एक तरीका है।

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

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

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

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

तो इसका जवाब यह बिल्कुल दो फाइलों के आकार पर निर्भर करता है - मीडिया प्लेयर के माध्यम से स्ट्रीम किया गया और डिस्क पर डाउनलोड किया गया।

— user1306322
स्रोत

0

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

तो मुझे लगता है कि इसका उत्तर यह है कि यह उसी राशि का उपयोग कर सकता है ... या कम ... या अधिक। सर्वर और उस दर के आधार पर जो वे आपकी सेवा कर रहे हैं।

— MinusFour
स्रोत

-2

हाँ यह बराबर है। डाउनलोड करें = आप इसे केवल एक बार डाउनलोड करते हैं और यह आपके कंप्यूटर पर रहता है। स्ट्रीम = आप अस्थायी रूप से "कुछ" अपने कंप्यूटर पर डाउनलोड करते हैं।

— टियागो रिबेरो
स्रोत

स्थानांतरित किए गए डेटा और उपयोग किए गए बैंडविड्थ के बीच अंतर है।

— जोनास श्फर

अच्छी तरह से मेरे Android पर एक स्ट्रीम से वीडियो देख रहा है या इसे डाउनलोड करने के लिए एक ही डेटा उपयोग है

— टियागो रिबेरो

@JonasWielicki एक बुद्धिमान व्यक्ति ने एक बार कहा था: "हस्तांतरित डेटा की मात्रा समान है"। निश्चित रूप से इस्तेमाल की जाने वाली बैंडविड्थ की मात्रा बदलती रहती है, क्योंकि बफरिंग के कारण स्थानांतरण की गति समय के साथ धीमी होती है।

— नेनोटलेप

1

यह वास्तव में बहुत सारे मामलों में सही उत्तर है। अक्सर कई मामलों में, स्ट्रीमिंग और डाउनलोड के लिए सटीक समान संसाधन और प्रोटोकॉल का उपयोग किया जाता है। यदि आप HTTP पर एक संसाधन खेलना चाहते हैं, तो इसे डाउनलोड करने के अलावा कोई अन्य नहीं है जो आप इसे वापस खेल रहे हैं जैसा कि यह डाउनलोड किया जा रहा है। ज़रूर, स्ट्रीमिंग के लिए अनुकूलन हैं, और विभिन्न प्रोटोकॉल जो आपके स्ट्रीम के रूप में आपकी बिटरेट को बदल सकते हैं, लेकिन मुझे नहीं लगता कि यह सवाल पूछा जा रहा है। (वे हालांकि उल्लेख के लायक हैं।)

— ब्रैड