Akış, indirme işlemiyle aynı miktarda bant kullanıyor mu?

İçeriğin aynı kalitede olduğunu varsayarsak (ceteris paribus), akış ortamı (yani video, ses) indirirken kullandığı kadar bant genişliği kullanıyor mu?

Amazon'dan bir HD film indirebileceğimi veya aktarabileceğimi söyle, bant genişliğinin eşdeğeri kullanımı olur mu?

Genellikle eşdeğer değildir.

Akış sağlayıcılar , filmin kalitesini kullanıcıların bant genişliği kullanılabilirliğine ve kalite isteklerine göre dinamik olarak ayarlamak için DASH gibi protokoller kullanır . Ardından, sunucular bağlantınızı hızlandırabilir; böylece belirli bir miktarı (10 saniye, belki 30 dakika veya bir dakika gibi bir süre) arabelleğe alabilirsiniz ve daha sonra içeriği gerçek zamanlı olarak almak için gereken bant genişliği miktarını elde edersiniz. Bu, sağlayıcının bakış açısından açık bir optimizasyondur, çünkü bant genişliğini kullanıcılar arasında daha eşit bir şekilde yayar ve ayrıca boşuna aktarılmaktan kaçınır (örneğin, kullanıcı bir 480p filmi 10 dakika boyunca, ratelimsiz ve ortak bir downlink ile, daha önce indirilmiş olandan çok daha büyük olasılıkla indirilir, ancak kullanıcılar videoyu izlemeyi bırakırsa israf olur).

Aktarılan veri miktarı aynı. Ancak, yayın akışı daha uzun sürebilir, çünkü sağlayıcı veri aktarımını, içeriği gerçek zamanlı olarak belirli bir kalitede yayınlamak için gereken oranla sınırlayabilir.

Dailymotion, bağlantıları hızlandıran sağlayıcılardan biridir. En az 100 Mbit / s simetrik bağlantıya sahip bir sunucudan, aşağıdaki davranışları görüyoruz¹:

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

Oran mümkün olanın çok altında (ve diğer sağlayıcılar ile elde ediliyor). Ayrıca, farklı malzemeler denerseniz, oranın tek tek videoya büyük ölçüde bağlı olduğunu görürsünüz:> 1 MiB / s ile kolayca indirilen bir fullhd video, bunun gibi bir müzik videosu 200 KiB / s civarında veya altında kalır. .

Hepsini özetlemek ve olası bazı yanlış anlaşılmaları gidermek için: Bazı sağlayıcılar, indirme sırasında, müşteri uygulamaları (örneğin, html5 veya flash video oynatıcı ile youtube) veya sunucu araçları aracılığıyla indirme hızınızı sınırlayabilir. Sizi sunucu yoluyla sınırlandırmazlarsa, indirme işlemi daha fazla bant genişliği tüketir, çünkü akış sırasında istemci uygulaması tarafından uygulanan hız sınırlaması gerçekleşmez. Bu, tüketilen bant genişliğinin orijinal soruya göre farklı olduğu ana durumdur.

1. Bunun bir çeşit anektodal kanıt olduğunun farkındayım - ancak bu davranışı tutarlı bir şekilde gözlemledim.

Aynı kaliteden bahsettiğimizi varsayalım (örneğin, azaltıcı, kare atlama veya düşük kaliteli akışlar yok), o zaman en iyi ihtimalle akışlar indirme / indirme hızında aynı miktarda bant genişliği alacaktır. sağlayıcıya daha uygun. Videonun nasıl sıkıştırıldığına bağlı olarak daha fazla bant genişliği de alabilirdi - çoğu zaman resmin tamamı gönderilmez, yalnızca çerçeveler arasındaki değişiklik (veya delta). Bu, daha fazla tarih olması anlamına gelir (yani, Y karesindeki X pikselinden gelen mavi tonu kullanın), daha az gönderilmesi gerekir. Bu normalde pek fazla ortaya çıkmaz, ancak ne olursa olsun bir akış duraklatıldığında / kesildiğinde, bu “tarihçe” kaybolur ve yeniden iletilmesi gerekir, böylece indirme sırasında, bant genişliğini artırabilir "ara" da, ve alıcının bu bilgiye zaten sahip olduğunu varsaydık. Aynısı ses için, özellikle sabit bir hızın olmadığı durumlarda kullanılabilir (mp3 yerine FLAC gibi).

Etrafa atlamak (atlama, yeniden sarma vb.), Kullanımı da etkileyebilir - tampondan ileri doğru ilerlemek, bir akım tarafından kullanılan bant genişliği miktarını azaltır, ancak herhangi bir yeniden sarma onu artırabilir. Ayrıca, kullanımın artmasına neden olacak bir kesinti olacaktır (yukarıya bakın) ve youtube ve netflix kullanımının kullandığı gibi herhangi bir "küçük resim önizlemesi" de bant genişliğini biraz artırabilir.

Son not: Sıkıştırma: Bu indirme işlemi için yapılabilir, ancak akışlar için çok fazla bir şey olmazdı - uyarısı çoğu videonun zaten sıkıştırılmış olmasıydı, bu yüzden burada çok fazla kazanılmayacaktı. yüksek çözünürlük / kalite departmanı).

Akış, özellikle ağ koşulları kötüyse daha az bant genişliği kullanır, ancak bu bir ücrete tabidir .

Sorun, gönderilmesi gereken veriler. Bir indirme modelinde, ne olursa olsun tüm verilerin müşteriye doğru sırayla ulaşması gerekir . Ağ koşulları kötüyse ve verilerin bir kısmı müşteriye ulaşmazsa, yeniden gönderilmesi gerekir ve bu, bant genişliği kullanımını artırır. Eğer bazı veriler oradan sipariş dışına çıkarsa, sunulmadan önce yeniden düzenlenmesi gerekir ve bu da yanıt verebilirliği azaltır.

Bir akış modelinde, verilerin bir kısmının müşteriye ulaşmaması sorun değil . Bir film akışı yapıyorsanız ve bir kare oraya ulaşmazsa, filmi atlayıp devam edebilirsiniz, böylece yeniden gönderimlerde ek bant genişliği kullanmazsınız. Bazı çerçeveler oraya sıra dışı gelirse, sadece ileri gidenleri oynayın; anlık bir çarpma önemli olmayacak ve bu da tepkiyi arttırıyor. Bununla birlikte, aynı zamanda tam olarak verileri tam olarak elde edemeyeceğiniz anlamına da gelir: ne görürseniz görüyorsunuz, ilk vuruşta orada ne varsa.

Modeller arasında seçim yapmanız gerekiyorsa, verilerle ne yapmak istediğinizi temel alarak seçin. Arşivlemek ve / veya muhtemelen defalarca görüntülemek istiyorsanız, her şeyi alacağınızdan emin olmak için indirin. Arşivlemeyi planlamıyorsanız veya yalnızca verileri bir kez görüntülemeyi planlıyorsanız, devam edin ve akış; Muhtemelen tek bir görüntülemedeki farkı görmeyeceksiniz ve eğer ağ koşulları fark ettiğiniz kadar kötü ise, indirme işlemi daha da kötü olacaktır.

Gerçekten "bant genişliği" (bayt / sn) ve "toplam veri" (bayt) değil, en önemli soru şudur: hangi zaman diliminde? Kullanıcının tüm videoyu izlediğini ve aynı kodek / kalite vb'nin döndürüldüğünü varsayarsak ve akış isteği / yanıtlarının küçük yükünü görmezden gelirsek, döndürülen toplam veri eşittir.

Şimdi, bant genişliği nedir? Sorunuzu anlamanın iki yolu vardır:

1. İndirme işlemi tamamlanana kadar geçen süre boyunca bant genişliği. Akış için, öbür ucun sonuna yaklaşıncaya kadar bu öbek izlenirken sıfıra geri dönen (sonraki öbek istendiğinde) yüksek sivri uçları görmelisiniz ve yine bant genişliğinde bir ani yükselme vardır. İndirmek için, videonun tamamı yüklenir yüklenmez sıfıra inen 10 dakika için çok yüksek bir bant genişliği görmelisiniz. Denemeyi şimdi durdurursanız, indirme için bant genişliği, bitinceye kadar indirme bağlantınızı maksimuma çıkardığı için açıkça daha yüksektir.

2. Videonun izlendiği süre boyunca bant genişliği. Videonun izlenme süresi, her ikisinin de hemen izlemeye başladığını varsayarsak, hem akış hem de indirme için aynıdır. Toplam veri boyutu da aynıdır. Bant genişliği zaman başına veri olduğundan, her iki senaryoda da aynıdır.

Aşağıdaki örnekte, her zaman toplam 40 (veri birimi) indirilmiştir. Ancak "indirme" için ilk zaman diliminde 40, "akış" için ilk zaman diliminde (büyük bir başlangıç ​​öbeği almak için) 20 ve iki ek parça için iki kez 10'dur. Eğer -eğer bant genişliği y ekseni üzerine çizilir ise, iki grafik her birisinin altında kalan alan verileri (bayt) karşılık geldiğine dikkat edin entegre zaman / saat bayt bayt olsun.

Onlar karşılaştırılamaz.

İlk olarak, yerel görüntüleme için en uygun kodlama, akışlı görüntüleme için en uygun kodlamadan farklıdır.

Video kodlama hakkında konuşalım.

Çoğu video kodlama biçiminde, genellikle iki tür kare vardır:

1. Kodlanmış çerçeve (I-Frame) - bunlar tamamen aktarılan çerçevelerdir, bu çerçeve başka herhangi bir çerçeve bilgisi olmadan çözülebilir. Bir kodlanmış çerçeve, temel olarak statik bir görüntüdür. Kodlayıcılar bunları ani geçişler sırasında üretecektir. Bunlar sıkıştırmak için daha az verimlidir.
2. Öngörülen çerçeve (P-Frame) veya Bi-tahmini çerçeve (B-Frame) - bunlar sadece çerçeveler arasındaki farkları saklayan çerçevelerdir, ancak izleyicinin önceki ve / veya sonraki çerçeveleri de bilmesi durumunda çözülebilir. Bunlar sıkıştırmak için çok daha etkilidir.

Yerel görüntüleme için kodlama, daha fazla P ve B çerçevesinden faydalanmak için hızlı diskin avantajlarından yararlanabilirken, verimli akış için kodlanmış bir videonun, uyması için ani geçişler olmasa bile, tüm video boyunca daha fazla gereksiz I-Frame kodlaması gerekecek rastgele arayış.

Ayrıca, iki farklı akış tipi vardır. Önceden kaydedilmiş bir akışa (çoğu Youtube videosu) ve canlı etkinlik akışına (örneğin Youtube Live) sahip olabilirsiniz. Gecikme ihtiyacı nedeniyle, canlı yayın olayı uzun veya tahmin edilemeyen bir zaman alan gelişmiş kodlama tekniklerinden yararlanamaz; önceden kaydedilmiş bir yayın kodlamak için gereken kadar zaman alabilir.

Streamed video ayrıca genellikle sabit bit hızı (CBR) ile kodlanır. Aynı hedef boyut için, değişken bit hızlı (VBR) bir video, genellikle bir CBR videodan daha yüksek kalitede olacaktır. Tersine, bir VBR videosu bir CBR videosunun kalitesi için daha küçüktür. DASH gibi uyarlanabilir bir akış protokolü, CBR ile VBR arasında bir uzlaşma olan uyarlamalı bir bit hızına (ABR) sahiptir. ABR, izleyicinin ağ bant genişliğindeki değişikliklere uyum sağlamasına izin verir. Sabit, tutarlı bir bant genişliği verildiğinde, ABR CBR ile hemen hemen aynıdır.

Tüm bunların anlamı, aynı kalite ve görüntüleme deneyimi göz önüne alındığında, videoyu yerel görüntüleme için akışlı videodan daha verimli bir şekilde kodlayabilirsiniz ve videoyu önceden kaydedilmiş akışlar için canlı akışlardan daha verimli bir şekilde kodlayabilirsiniz.

Daha sonra, akış protokolünde bir ek yük de vardır. Normal bir HTTP indirme işlemi, çok az ek yüke sahip olan dosyanın tamamını indirmek için yığınlanmış kodlamayı kullanabilir. Akışlı bir indirme işlemi, öbek aktarma işlemi için öbek ve öbek üzerinde pazarlık yapmak zorunda kalacak. Şeylerin büyük şemasında, transfer protokolünün ek yükü nispeten küçüktür.

Genel olarak, izlenen videonun aynı miktarı için, akışlı videonun daha fazla miktarda bant genişliği alması gerekir. Bant genişliği kullanımı açısından, yayın akışının birincil avantajı, videoyu indiren ancak videoyu tam olarak izlemeyen kullanıcılar tarafından kurtarabilmesi, bu da çok önemli bir tasarruf olabilir.

Cevap, duruma bağlı".

Cevap, genel olarak video barındıran sağlayıcılar için HAYIR. Video akışı yapan yarı iyi sağlayıcılar, olabildiğince çok insan için sorunsuz oynatım ve optimum bant genişliği sağlayacak şekilde hız kontrolü yapar. Çok fazla bant genişliğine sahip olsanız bile, sadece 5Mbit vermeye ve hala oldukça iyi görünmeye karar verebilir.

Bir HTTP indirme işlemi yaparsanız, bağlantının bir veya iki ucunu veya aradaki herhangi bir şeyi doyurmanızı sağlamak için TCP rate kontrol algoritmaları devreye girer. Yani 100Mbit'iniz varsa, alabileceği her şeyi veya 100Mbit'e yakın kullanacaktır.

Tabii ki, istemci ile sunucu arasında hiçbir yerde QoS olmadığı varsayılmaktadır.

Sorunuz o kadar gevşek ki, bazı naif kurulumlarda cevap aynı zamanda EVET (varsayımlarla), bant genişlikleri aynı olacak şekilde yapabilirim. Bunu yapmak için, dosyayı basit bir web sunucunuza bırakın ve bir izleyicinin başlaması için tarayıcınızla açın. Videoyu temel web sunucunuza gömün ve tekrar tarayıcıda oynatın ve aynı bant genişliğini kullanın. Aşağıdaki varsayım ... başka kullanıcı yok, başkalarıyla ağ paylaşan başka kimse yok ... oyunda bant genişliğinizi değiştirebilecek başka faktör yok.

Bir web sitesinden dosya indirdiğinizde, ardından tekrar indirdiğinizde ilk ve ikinci indirme arasındaki bant genişliğinin değişebileceğini unutmayın. Bunun nedeni, sunucudaki yükün değişebilmesi ve ağdaki tıkanıklığı ve ağ yollarının değişebilmesidir.

Yani orada var ... buna bağlı.

Ağ bakış açısından "indirme" ve "akış" farklı hizmetlerdir, buna "trafik profili" denir.

Akış servisi için ağ minimum bir sabit verim sağlamak zorundadır (teknik olarak "bant genişliği" farklı bir şey anlamına gelir), akış servisi kesintilere ve titremeye karşı hassastır. Maksimum ağ verimi gerektirmez, gecikme veya gecikme kritik değildir.

Son kullanıcı bakış açısından, şu anlama gelir: Video kesintisiz veya düşmeden sorunsuz şekilde çalışacaktır. Videonun birkaç saniye önce veya sonra başlaması önemli değildir.

"İndirme" genellikle mümkün olan maksimum ağ verimini gerektirir, indirme mümkün olduğu kadar çabuk yapılmalıdır. Gecikmeler, kesintiler ve sarsıntı kritik değildir.

Bir ağ tamamen farklı olan daha fazla trafik profili sağlayabilir. Örneğin sesli servisler (basit telefon görüşmesi) çok düşük verime ihtiyaç duyuyor ancak gecikmelere karşı çok hassas (200 ms'den az)

Diğer cevaplara eklemek için cevabım: mutlaka değil .

Şimdi, her şeyin eşit olduğunu varsayarak (otomatik kalite seçimi yok, sunucudan ve / veya ISS'den kısıtlama yok) ...

Bant genişliği genellikle size_of_data'nın total_time'a bölünmesi olarak tanımlanır. (Teknik olarak, 'uygun' terim verimliliktir , ancak ayrılıyorum).

60 MB boyutunda 2000 saniyelik bir video yayınlayacağınızı varsayalım.

Akışla flama programı olabilir kendi hızını sınırlayıcı tampon taşması önlemek için yapıyoruz. Bu nedenle, HTTP istek başlığı bir Range alanı içerebilir . Etkili akışı beri bant genişliği daha sonra 60 MB / 2000 saniye = 30 KB / s = 240 kbps ~ olacağını akışı bitene kadar başlar.

Eğer düpedüz videoyu indirmek Ancak, elde edersiniz kadar Internet hizmeti maksimum bant genişliği. Tabii ki aynı anda diğer kullanımlara bağlı olarak. Böylece,% 50 kullanılabilir bant genişliğine sahip 6 Mbps Internet servisini varsayarsak, video indirme için 3 Mbps bant genişliği elde edersiniz.

Akış gerçekten indirmenin bir yoludur.

Akışlı bir filmi izlerken, medya yürütücünüz bir parçasını indirecek, size gösterecek ve dosyanın gösterilen kısımlarını anında atacaktır.

Genellikle, bir dosyayı indirdiğinizde, indirme işleminin bitmesini bekler ve sonra izlemeye başlarsınız. Ancak, dosyanın indirilen kısmını size gösterebilecek ve otomatik olarak duraklatıp biraz daha indirilmesini bekleyebilecek ortam yürütücüleri var. Biraz akış gibi, ama dosyayı atmadan.

Teknik olarak, kaygı toplam aktarılan veri miktarı olduğunda, nasıl indirdiğiniz önemli değil, indirdiğiniz dosya ile medya oynatıcınızın sizin için bir akış olarak indirdiği dosya arasındaki farktır. Tam olarak aynı dosyalar olabilir ve her iki durumda da aynı bant genişliği anlamına gelir.

Akışlı medya siteleri genellikle içeriklerini mağazadan satın alınan bir diskten daha düşük bit hızına sahip olarak kodlar. Ancak, işletim sisteminizin dosya paylaşım işlevini kullanarak masaüstü bilgisayarınızdan bir dizüstü bilgisayarda WiFi üzerinden bir film izleyebilirsiniz ve masaüstünde izliyormuş gibi neredeyse aynı miktarda trafik çeker (zorlukla okunan bayt sayısı). ) sürücü. Teknik olarak, bir film sürekli olarak indirilirken ve atılırken bir film izlerken akıyor olacaktı.

Bu yüzden cevabı kesinlikle iki dosya boyutuna bağlıdır - medya oynatıcı üzerinden akış ve diske indirilmiş.

Akış, indirme işleminizi kullanıyor, bu nedenle indirme olarak kabul edebilirsiniz. Sorunuz, indirmeyi düşündüğünüz şey hakkında biraz belirsiz. Yalnızca olabildiğince fazla yükleme indirebilir ve sunmaya istekli olabilirsiniz. Sonuçta, örneğin DASH üzerinden HTTP üzerinden düz bir indirme işlemini (hala HTTP) karşılaştırmak istiyorsanız, örneğin, her birinden ne kadar indirme yaptığınızı kontrol etmeniz gerekir.

Sanırım cevabı aynı miktarda ... veya daha az ... veya daha fazla kullanıyor olabilir olmasıdır. sunuculara ve size sundukları ücrete bağlı olarak.

Evet eşdeğerdir. İndir = Sadece bir kez indirirsiniz ve bilgisayarınızda kalır. Stream = Bilgisayarınıza geçici olarak "bir şey" indirin.