Apakah streaming menggunakan jumlah bandwidth yang sama dengan mengunduh?


75

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?


2
Tergantung pada protokol dan codec: mis. Unduhan melalui http dan streaming melalui rtmp, atau h264 vs vp6. IMO pertanyaan ini terlalu luas mengingat jumlah kompresi dan metode transmisi data untuk dibandingkan.
zamnuts

Hanya untuk memperjelas pertanyaan Anda. Dengan bandwidth, Anda mengacu pada kecepatan data, bukan ukuran file (film)?
Matt H

Keuntungan mengunduh lebih dari streaming (yang secara teknis mengunduh tetapi hanya untuk sekali pakai) adalah Anda dapat mengkonsumsi materi sebanyak yang Anda inginkan tanpa harus menghabiskan bandwidth Anda untuk itu setiap kali. Beberapa pemutar media bahkan dapat memutar video yang sedang Anda unduh (belum sepenuhnya diunduh), memberikan "nuansa" streaming dengan keuntungan mengunduh.
ADTC

3
Ya saya mengacu pada data rate. Alasan saya bertanya adalah memiliki perselisihan dengan saudara perempuan saya dan ketika saya melihat online semua yang saya temukan adalah jawaban yang tidak jelas dari jawaban yahoo. Saya menyadari ada banyak variabel ini tergantung pada tetapi saya pikir itu setidaknya layak ditanyakan.
stemie

2
"Dalam jaringan komputer dan ilmu komputer, bandwidth, bandwidth jaringan, bandwidth data, atau bandwidth digital adalah pengukuran laju bit dari sumber daya komunikasi data yang tersedia atau dikonsumsi yang dinyatakan dalam bit per detik atau kelipatannya (bit / s, kbit / s , Mbit / s, Gbit / s, dll.) - wikipedia.org/wiki/Bandwidth_(computing) "
stemie

Jawaban:


43

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.

3
@Psycogeek Youtube adalah salah satu contoh menggunakan DASH (jika komentar ini tidak masuk akal bagi Anda, baca bagian pengantar dari artikel yang saya tautkan). Ini menyiratkan bahwa pemain yang digunakan klien harus meminta potongan video berurutan. Mengambil langkah dari sana untuk berhenti meminta lebih banyak potongan jika pemain tidak berjalan adalah wajar. Pengunduh seperti youtube-dlhanya akan terus meminta lebih banyak potongan sampai video sepenuhnya diunduh. Jadi streaming dengan DASH menimbulkan overhead yang sedikit lebih banyak, tetapi mungkin sepadan (untuk pengguna dan penyedia) dan diabaikan.
Jonas Schäfer

1
Dengan asumsi pengkodean dan definisi data yang sama digunakan (lihat komentar psychogeek) mengunduh akan menggunakan lebih banyak bandwidth total. Pengunduhan video hampir pasti akan dilakukan dengan TCP, sedangkan streaming akan menjadi pendekatan pengiriman yang tidak dijamin. Dengan demikian TCP akan memiliki lebih banyak acks yang dikirim minimum, dan karena Anda mungkin akan kehilangan atau merusak setidaknya beberapa paket, pendekatan tcp sebenarnya akan lebih banyak mengunduh juga (karena akan mengambil paket yang hilang juga). Meskipun perbedaannya sangat kecil dibandingkan dengan ukuran unduhan, jadi ini sebagian besar bersifat akademis.
dsollen

2
@dsollen: Kecuali pengirim UDP akan membiarkan paket mengalir tanpa peduli apakah penerima yang dituju masih ada, baik UDP dan TCP akan membutuhkan ucapan terima kasih secara berkala; dalam kedua kasus, pengakuan akan mewakili bagian yang sangat kecil dari total lalu lintas. Selanjutnya, memformat data sedemikian rupa sehingga setiap paket dapat dipahami bahkan jika paket sebelumnya tidak diterima umumnya menyiratkan tingkat overhead di luar apa yang akan diperlukan untuk TCP.
supercat

7
Saya akan downvote jawaban ini jika saya punya cukup rep: itu tidak menjawab pertanyaan, frasa kuncinya adalah "kualitas yang sama". Ketika penyedia menjatuhkan kualitas, ini bukan ceteris paribus .
zamnuts

1
@zamnuts, lalu poskan yang lebih baik dan biarkan komunitas memutuskan. FWIW, ini sedikit apel dan jeruk ketika Anda mempertimbangkan penyedia memutuskan penurunan kualitas, tapi saya rasa jawabannya tidak akan lengkap tanpa itu.
paqogomez

19

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).


7

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.


Apakah Anda mengatakan bahwa layanan streaming menggunakan UDP alih-alih TCP untuk dengan sengaja mengizinkan data yang dibuang?
FreeAsInBeer

1
@FreeAsInBeer: Ya. TCP membangun banyak mekanisme keandalan dan fitur lain yang sangat berguna untuk sebagian besar aplikasi yang bisa dibayangkan. Tetapi use case ada di mana ada hal-hal yang bahkan lebih penting daripada keandalan, dan streaming adalah salah satunya: itu lebih penting untuk menunjukkan bingkai yang tepat pada saat yang tepat daripada menunjukkan setiap frame tunggal. Permainan daring adalah contoh lain di mana UDP populer, karena alasan yang sama: menghentikan tindakan untuk merekonstruksi jejak negara pemain lebih buruk daripada harus mengoreksi keadaan yang dijatuhkan sesekali.
The Spooniest

Sebenarnya banyak sistem mengalirkan data melalui TCP dan buffer di sisi klien. Untuk streaming film, latensi tidak penting. Tidak ada ketidaknyamanan bagi pengguna jika beberapa frame kebetulan duduk di buffer selama satu menit sebelum saatnya untuk menampilkannya. Tetapi untuk penggunaan interaktif seperti konferensi video, latensi sangat penting.
kasperd

1
kasperd: Sebenarnya, itu tidak mengalir. Jawaban lain menyebutkan layanan yang diunduh tetapi mulai diputar sebelum pengunduhan selesai, dan itulah yang dilakukan sistem yang Anda gambarkan.
The Spooniest

+1 untuk jawaban yang paling membingungkan (hingga saat ini) di utas ini.
Cosmic Ossifrage

5

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.


4

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.


1

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.


"Bandwidth antara unduhan pertama dan kedua dapat bervariasi" tetapi tentunya itu mengunduh jumlah data yang sama pada akhirnya, bahkan jika yang satu lebih lama dari yang lain / kondisi jaringan telah berubah.
stemie

@stemie, Ini akan dekat. Protokol yang berbeda menambahkan overhead protokol. Tetapi jika tidak ada transcoding atau perubahan kualitas / tingkat selama proses streaming maka secara teori jumlah data video harus sama.
Matt H

1

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)


0

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.


0

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.


0

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.


-2

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


Ada perbedaan antara jumlah data yang ditransfer dan bandwidth yang digunakan.
Jonas Schäfer

baik di android saya menonton video dari streaming atau mengunduhnya memiliki penggunaan data yang sama
Tiago Ribeiro

@JonasWielicki Orang bijak pernah berkata: "Jumlah data yang ditransfer adalah sama". Tentu jumlah bandwidth yang digunakan bervariasi, karena karena buffering kecepatan transfer lebih lambat dari waktu ke waktu.
Nenotlep

1
Ini sebenarnya jawaban yang tepat dalam banyak kasus. Sering kali dalam banyak kasus, sumber daya dan protokol yang sama persis digunakan untuk streaming dan mengunduh. Jika Anda ingin memutar sumber daya melalui HTTP, itu tidak berbeda dengan mengunduhnya selain Anda memutarnya saat sedang diunduh. Tentu, ada optimisasi untuk streaming, dan protokol berbeda yang dapat mengubah bitrate Anda saat Anda streaming, tetapi saya tidak berpikir itulah inti dari pertanyaan yang diajukan. (Mereka memang pantas disebutkan.)
Brad
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.