Apakah streaming menggunakan jumlah bandwidth yang sama dengan mengunduh?

Dengan asumsi konten memiliki kualitas yang sama (ceteris paribus), apakah streaming media (yaitu video, audio) menggunakan jumlah bandwidth yang sama dengan mengunduhnya?

Katakanlah saya akan mengunduh film HD dari Amazon atau streaming, apakah itu setara dengan penggunaan bandwidth?

Seringkali tidak setara.

Penyedia streaming menggunakan protokol, seperti DASH , untuk secara dinamis menyesuaikan kualitas film dengan ketersediaan bandwidth dan keinginan kualitas pengguna. Kemudian server dapat menilai-membatasi koneksi Anda sehingga Anda dapat menyangga jumlah tertentu (sekitar 10 detik, mungkin 30 atau satu menit penuh) dan setelah itu Anda hanya mendapatkan jumlah bandwidth yang diperlukan untuk mengirimkan konten kepada Anda secara real time. Ini adalah pengoptimalan yang jelas dari sudut pandang penyedia, karena itu menyebarkan bandwidth lebih merata di antara para pengguna dan juga menghindari data yang akan ditransfer dengan sia-sia (misalnya ketika pengguna menonton film 480p selama 10 menit, tanpa ratelimiting dan dengan downlink yang umum, kemungkinan lebih dari yang sudah diunduh, tetapi kemudian terbuang jika pengguna berhenti menonton video).

Jumlah data yang ditransfer adalah sama. Tapi itu mungkin memakan waktu lebih lama dengan streaming, karena penyedia mungkin menilai-batas transfer data ke tingkat yang diperlukan untuk mengirimkan konten dalam kualitas yang diberikan secara real time.

Dailymotion adalah salah satu penyedia yang menilai batas koneksi. Dari server dengan setidaknya koneksi simetris 100 Mbit / s, kita melihat perilaku berikut¹:

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

Angka ini jauh di bawah yang mungkin (dan dicapai dengan penyedia lain). Juga, jika Anda mencoba materi yang berbeda, Anda akan menemukan bahwa nilainya sangat tergantung pada masing-masing video: video fullhd mudah diunduh dengan> 1 MiB / s, sementara video musik seperti ini tetap sekitar atau di bawah 200 KiB / s .

Untuk meringkas semuanya dan menjernihkan beberapa kesalahpahaman yang mungkin terjadi: Beberapa penyedia layanan mungkin menilai batas unduhan Anda saat streaming, melalui aplikasi klien mereka (misalnya youtube dengan html5 atau pemutar video flash) atau dengan cara server. Jika mereka tidak menilai batas Anda dengan cara server, maka pengunduhan akan menggunakan lebih banyak bandwidth, karena pembatasan laju yang mungkin diterapkan oleh aplikasi klien selama streaming tidak terjadi. Ini adalah kasus utama ketika bandwidth yang digunakan berbeda sehubungan dengan pertanyaan awal.

1. Saya sadar bahwa ini adalah semacam bukti anektodal — namun saya telah mengamati perilaku ini secara konsisten.

Dengan asumsi kita berbicara tentang kualitas yang sama (yaitu tidak ada pelambatan, frame-skipping, atau stream berkualitas rendah), maka paling tidak stream akan mengambil jumlah bandwidth yang sama dengan unduhan, meskipun itu bisa dilakukan pada waktu / laju lebih nyaman bagi penyedia. Ini juga dapat mengambil bandwidth lebih banyak tergantung pada bagaimana video dikompresi - sebagian besar waktu seluruh gambar tidak dikirim, bukan hanya perubahan (atau delta) antara frame. Ini berarti bahwa semakin banyak sejarah yang ada (yaitu menggunakan rona biru dari piksel X dalam bingkai Y), semakin sedikit yang perlu dikirim. Ini biasanya tidak muncul banyak, tetapi ketika aliran dijeda / terputus karena alasan apa pun, "riwayat" ini hilang dan perlu ditransmisikan ulang, sehingga meningkatkan bandwidth, sementara dengan unduhan, itu dapat dilanjutkan di "istirahat", dan berasumsi bahwa penerima sudah memiliki informasi ini. Hal yang sama dapat digunakan untuk audio, terutama di mana tidak ada tarif tetap (yaitu FLAC, bukan mp3)

Melompat-lompat (melompati, memutar ulang, dll.) Juga dapat memengaruhi penggunaan - bergerak maju melewati buffer akan mengurangi jumlah bandwidth yang digunakan oleh aliran, tetapi pemutaran ulang apa pun akan menambahnya. Juga akan ada interupsi, yang akan menyebabkan peningkatan penggunaan (lihat di atas), dan segala jenis "preview thumbnail" seperti apa yang digunakan youtube dan netflix juga akan sedikit meningkatkan bandwidth.

Catatan terakhir: kompresi: ini bisa dilakukan untuk unduhan, tetapi tidak terlalu banyak untuk streaming - peringatannya adalah bahwa sebagian besar video sudah dikompresi, jadi tidak akan banyak yang didapat di sini (walaupun mungkin ada ruang untuk mendapatkan di ultra- departemen resolusi / kualitas tinggi).

Streaming akan menggunakan lebih sedikit bandwidth, terutama jika kondisi jaringan buruk, tetapi ini harus dibayar mahal .

Yang dipermasalahkan adalah data yang perlu dikirim. Dalam model unduhan, semua data harus menjangkau pelanggan, semua dalam urutan yang benar, apa pun yang terjadi . Jika kondisi jaringan buruk dan beberapa bit data tidak mencapai klien, mereka harus membenci, dan ini meningkatkan penggunaan bandwidth. Jika beberapa data keluar dari urutan, itu harus dimasukkan kembali ke dalam urutan sebelum disajikan, dan ini mengurangi responsif.

Dalam model streaming, tidak apa-apa jika beberapa data tidak mencapai klien . Jika Anda streaming film dan bingkai tidak sampai di sana, Anda bisa melewatkannya dan melanjutkan, sehingga Anda tidak menggunakan bandwidth tambahan saat mengirim ulang. Jika ada beberapa frame yang rusak, mainkan saja yang maju; blip sesaat tidak akan masalah, dan dengan demikian meningkatkan responsif. Namun, itu juga berarti bahwa Anda tidak perlu mendapatkan data lengkap: apa pun yang Anda lihat adalah apa pun yang ada di foto pertama.

Jika Anda harus memilih di antara model, pilih berdasarkan apa yang ingin Anda lakukan dengan data. Jika Anda ingin mengarsipkannya dan / atau mungkin melihatnya berkali-kali, unduhlah sehingga Anda yakin mendapatkan semuanya. Jika Anda tidak berencana untuk mengarsipkan, atau hanya berencana melihat data satu kali, maka lanjutkan dan streaming; Anda mungkin tidak akan melihat perbedaan pada satu tampilan, dan jika kondisi jaringan cukup buruk sehingga Anda perhatikan, maka pengunduhan akan lebih buruk.

Jika Anda benar-benar meminta "bandwidth" (byte / detik) dan bukan "data total" (byte), pertanyaan krusialnya adalah: selama periode waktu berapa? Jika kita mengasumsikan bahwa pengguna menonton seluruh video dan bahwa codec / kualitas yang sama dll dikembalikan, dan mengabaikan overhead kecil permintaan / tanggapan streaming, maka total data yang dikembalikan sama.

Sekarang, berapa bandwidth? Ada dua cara untuk memahami pertanyaan Anda:

1. Bandwidth selama waktu yang dibutuhkan hingga unduhan selesai. Untuk streaming, Anda akan melihat lonjakan bandwidth tinggi (ketika potongan berikutnya diminta) yang kembali ke nol saat Anda menonton potongan sampai Anda mendekati ujung potongan dan ada lonjakan bandwidth lagi. Untuk mengunduh, Anda akan melihat bandwidth yang sangat tinggi untuk, katakanlah, 10 menit yang turun ke nol segera setelah seluruh video diunduh. Jika Anda menghentikan percobaan sekarang, bandwidth untuk mengunduh jelas lebih tinggi karena memaksimalkan tautan balik Anda sampai selesai.

2. Bandwidth selama waktu video ditonton. Waktu video ditonton adalah sama untuk streaming dan unduhan, dengan asumsi keduanya mulai menonton segera. Ukuran total data juga sama. Karena bandwidth adalah data per waktu, itu sama untuk kedua skenario.

Dalam contoh di bawah ini, selalu ada total 40 (unit data) yang diunduh. Tetapi untuk "mengunduh", itu adalah 40 dalam satuan waktu pertama, sedangkan untuk "pengaliran" adalah 20 selama satuan waktu pertama (untuk mendapatkan potongan awal yang besar) dan kemudian dua kali 10 untuk dua potongan tambahan. Perhatikan bahwa sementara bandwidth diplot pada sumbu y, area di bawah masing-masing dua grafik berhubungan dengan data (byte) —jika Anda mengintegrasikan byte / waktu dari waktu ke waktu, Anda mendapatkan byte.

Mereka tidak sebanding.

Untuk contoh pertama, pengodean optimal untuk tampilan lokal berbeda dari pengkodean optima untuk tampilan streaming.

Mari kita bicara tentang pengkodean video.

Dalam sebagian besar format penyandian video, biasanya ada dua jenis bingkai:

1. Intra-coded frame (I-Frame) - ini adalah frame yang ditransfer secara penuh, frame ini dapat didekodekan tanpa sepengetahuan frame lainnya. Frame Intra-coded pada dasarnya adalah gambar statis. Encoder akan menghasilkan ini selama transisi tiba-tiba. Ini kurang efisien untuk dikompres.
2. Bingkai yang diprediksi (Bingkai-P) atau bingkai yang diprediksi-Bi (Bingkai-B) - ini adalah frame yang menyimpan hanya perbedaan antara frame, hanya dapat diurai kode jika pemirsa juga mengetahui frame sebelumnya dan / atau yang terakhir. Ini jauh lebih efisien untuk dikompres.

Pengkodean untuk penayangan lokal dapat memanfaatkan upaya cakram cepat untuk memanfaatkan lebih banyak frame P dan B, sementara video yang dikodekan untuk streaming yang efisien harus mengkodekan I-Frame yang lebih berlebihan di sepanjang seluruh video bahkan ketika tidak ada transisi mendadak untuk mengakomodasi pencarian acak.

Juga, ada dua jenis streaming. Anda dapat memiliki streaming dari aliran yang direkam sebelumnya (sebagian besar video Youtube) dan aliran acara langsung (mis. Youtube Live). Karena kebutuhan latensi, streaming siaran langsung tidak dapat mengambil keuntungan dari teknik penyandian lanjutan yang memakan waktu lama atau tidak terduga, sementara aliran pra-rekam dapat memakan waktu sebanyak yang diperlukan untuk menyandikan.

Video yang streaming juga biasanya dikodekan dengan laju bit konstan (CBR). Untuk ukuran target yang sama, video laju bit variabel (VBR) biasanya akan memiliki kualitas lebih tinggi daripada video CBR. Sebaliknya, video VBR lebih kecil untuk kualitas video CBR yang sama. Protokol streaming adaptif seperti DASH memiliki bitrate adaptif (ABR), yang merupakan kompromi antara CBR dan VBR. ABR memungkinkan pemirsa untuk beradaptasi dengan perubahan bandwidth jaringan. Dengan bandwidth yang konstan dan konsisten, ABR kurang lebih sama dengan CBR.

Apa artinya semua ini adalah bahwa dengan kualitas dan pengalaman menonton yang sama , Anda dapat menyandikan video untuk menonton lokal lebih efisien daripada video yang streaming, dan Anda dapat menyandikan video untuk streaming yang direkam sebelumnya lebih efisien daripada streaming langsung.

Lalu ada juga overhead dalam protokol streaming. Pengunduhan HTTP biasa dapat menggunakan pengkodean transfer terpotong untuk mengunduh seluruh file yang memiliki overhead yang sangat minimal. Unduhan yang dialirkan harus menegosiasikan bagian dan kualitas potongan yang akan ditransfer. Dalam skema besar, overhead protokol transfer relatif kecil.

Secara keseluruhan, untuk jumlah video yang sama ditonton, video streaming harus berakhir dengan mengambil bandwidth dalam jumlah yang lebih besar. Keuntungan utama streaming, dalam hal penggunaan bandwidth, adalah dapat disimpan oleh orang-orang yang mengunduh tetapi tidak menonton video secara penuh, yang bisa menjadi penghematan yang sangat signifikan.

Jawabannya adalah, tergantung".

Jawabannya adalah TIDAK, untuk penyedia yang menghosting video secara umum. Setengah penyedia yang layak yang mengalirkan video melakukan kontrol laju untuk memastikan pemutaran yang lancar dan bandwidth yang optimal untuk sebanyak mungkin orang. Jadi meskipun Anda mungkin memiliki banyak bandwidth, itu mungkin memutuskan untuk memberi Anda hanya 5Mbit dan terlihat masih cukup baik.

Jika Anda melakukan unduhan HTTP, maka algoritme kontrol laju TCP akan masuk untuk memastikan bahwa Anda memenuhi satu atau kedua ujung koneksi atau apa pun di antaranya. Jadi jika Anda memiliki 100Mbit tersedia, itu akan menggunakan semua yang bisa didapat atau mendekati 100Mbit.

Itu tentu saja mengasumsikan tidak ada QoS yang terjadi di antara klien dan server.

Pertanyaan Anda sangat longgar sehingga saya juga bisa membuatnya sehingga dalam beberapa pengaturan yang naif jawabannya juga YA (dengan asumsi), bandwidthnya identik. Untuk melakukan itu, cukup taruh file ke server web dasar Anda dan buka dengan browser Anda sehingga pemirsa masuk. Atau embed video pada server web dasar Anda dan lagi, itu akan diputar di browser dan menggunakan bandwidth yang identik dengan asumsi berikut ... tidak ada pengguna lain, tidak ada orang lain yang berbagi jaringan dengan Anda ... tidak ada faktor lain yang dapat mengubah bandwidth Anda.

Ingat bahwa ketika Anda mengunduh file dari situs web, dan kemudian mengunduhnya lagi, bandwidth antara unduhan pertama dan kedua dapat bervariasi. Ini hanya karena beban di server dapat berubah dan kemacetan di jaringan dan jalur jaringan dapat berubah.

Jadi begitulah ... itu tergantung.

Dari sudut pandang jaringan "pengunduhan" dan "pengaliran" adalah layanan yang berbeda, itu disebut "profil lalu lintas"

Untuk layanan streaming, jaringan harus menyediakan throughput konstan minimum (secara teknis "bandwidth" berarti sesuatu yang berbeda), layanan streaming sensitif untuk gangguan dan jitter. Itu tidak memerlukan throughput jaringan maksimum, keterlambatan atau latensi tidak kritis.

Dari perspektif pengguna akhir, artinya: Video akan berjalan dengan lancar tanpa interupsi atau tetesan. Tidak masalah jika video dimulai beberapa detik lebih awal atau lebih lambat.

"Pengunduhan" biasanya membutuhkan throughput jaringan semaksimal mungkin, pengunduhan akan dilakukan secepat mungkin. Penundaan, interupsi, dan jitter tidak penting.

Jaringan mungkin menyediakan lebih banyak profil lalu lintas yang sama sekali berbeda. Misalnya layanan suara (panggilan telepon sederhana) membutuhkan throughput yang sangat rendah tetapi sangat sensitif untuk penundaan (kurang dari 200 ms)

Untuk menambah jawaban lain, jawaban saya adalah: Belum tentu .

Sekarang, dengan asumsi bahwa semuanya sama (tidak ada pemilihan kualitas otomatis, tidak ada pembatasan dari server dan / atau ISP) ...

Bandwidth biasanya didefinisikan sebagai size_of_data dibagi dengan total_time. (Secara teknis, istilah 'tepat' adalah throughput , tapi saya ngelantur).

Mari kita asumsikan Anda akan melakukan streaming video 2000 detik berukuran 60 MB.

Dengan streaming, program streamer mungkin melakukan pembatasan sendiri untuk mencegah buffer overflow. Jadi, tajuk permintaan HTTPnya mungkin menyertakan bidang Kisaran . The efektif bandwidth yang sejak streaming yang dimulai sampai berakhir mengalir maka akan ~ 60 MB / 2000 detik = 30 KB / s = 240 kbps.

Namun, jika Anda men-download video langsung, Anda akan mendapatkan sampai dengan bandwidth maksimum layanan Internet Anda. Tergantung pada penggunaan lain pada saat yang sama, tentu saja. Jadi, dengan asumsi layanan Internet 6 Mbps, dengan bandwidth 50% tersedia, Anda akan mendapatkan bandwidth 3 Mbps untuk pengunduhan video.

Streaming benar-benar cara mengunduh.

Saat Anda menonton film yang dialirkan, pemutar media Anda akan mengunduh sebagian darinya, menunjukkannya kepada Anda, dan membuang bagian file yang ditunjukkan dengan cepat.

Biasanya, ketika Anda mengunduh file, Anda menunggu unduhannya selesai, dan baru mulai menontonnya. Tetapi ada pemutar media yang mampu menunjukkan kepada Anda bagian yang diunduh dari file tersebut dan secara otomatis berhenti dan menunggu beberapa untuk diunduh. Agak suka streaming, tetapi tanpa membuang file.

Secara teknis, ketika kekhawatiran adalah jumlah total data yang ditransfer, tidak masalah bagaimana Anda mengunduhnya, tetapi perbedaan antara file yang Anda unduh dan file yang diunduh oleh pemutar media Anda sebagai streaming. Mereka mungkin file yang sama persis, dan itu berarti bandwidth yang sama dalam kedua kasus.

Streaming situs media biasanya menyandikan konten mereka untuk memiliki bitrate lebih rendah daripada disk yang dibeli di toko. Tetapi Anda dapat menonton film dari PC desktop Anda pada notebook melalui WiFi menggunakan fungsi berbagi file OS Anda, dan itu akan memakan jumlah lalu lintas yang hampir sama seperti jika Anda menontonnya di desktop (seperti membaca byte dari hard mendorong). Secara teknis itu akan streaming, ketika Anda menonton film sementara bagian-bagiannya terus-menerus diunduh dan dibuang.

Jadi jawabannya adalah itu benar-benar tergantung pada ukuran dua file - streaming melalui media player dan diunduh ke disk.

Streaming memang menggunakan throughput unduhan Anda sehingga Anda dapat menganggapnya sebagai unduhan. Pertanyaan Anda agak tidak jelas tentang apa yang Anda anggap unduhan. Anda hanya dapat mengunduh sebanyak mungkin unggahan yang dapat dan mau mereka tawarkan. Jadi pada akhirnya jika Anda ingin membandingkan unduhan langsung dari HTTP dengan DASH (masih HTTP) misalnya, Anda harus memeriksa berapa banyak unduhan yang Anda lakukan dari masing-masing.

Jadi saya kira jawabannya adalah bisa menggunakan jumlah yang sama ... atau kurang ... atau lebih. tergantung pada server dan tingkat mereka melayani Anda.

Ya itu setara. Unduh = Anda hanya mengunduhnya satu kali dan tetap di komputer Anda. Stream = Anda untuk sementara mengunduh "sesuatu" ke komputer Anda.