Truyền phát có sử dụng cùng một lượng băng thông như tải xuống không?


75

Giả sử nội dung có cùng chất lượng (ceteris paribus), liệu phương tiện truyền phát trực tuyến (tức là video, âm thanh) có sử dụng cùng một lượng băng thông như tải xuống không?

Giả sử tôi đã tải xuống một bộ phim HD từ Amazon hoặc phát trực tuyến, nó có phải là sử dụng băng thông tương đương không?


2
Phụ thuộc vào giao thức và codec: ví dụ: tải xuống qua http và stream qua rtmp, hoặc h264 so với vp6. IMO câu hỏi này quá rộng với số lượng phương pháp nén và truyền dữ liệu để so sánh.
zamnuts

Chỉ cần làm rõ câu hỏi của bạn. Theo băng thông bạn đang đề cập đến tốc độ dữ liệu, không phải kích thước tệp (phim)?
Matt H

Một lợi thế để tải xuống qua phát trực tuyến (là tải xuống về mặt kỹ thuật nhưng chỉ sử dụng một lần) là bạn có thể tiêu thụ tài liệu nhiều lần bạn muốn mà không phải tốn băng thông cho mỗi lần. Một số trình phát phương tiện thậm chí có thể phát các video mà bạn hiện đang tải xuống (chưa tải xuống đầy đủ), mang lại "cảm giác" phát trực tuyến với lợi thế tải xuống.
ADTC

3
Có tôi đang đề cập đến tốc độ dữ liệu. Lý do tôi hỏi là có sự bất đồng với chị tôi và khi tôi tìm trên mạng tất cả những gì tôi có thể tìm thấy là những câu trả lời mơ hồ từ câu trả lời của yahoo. Tôi nhận ra có rất nhiều biến số này phụ thuộc vào nhưng tôi nghĩ nó ít nhất là đáng để hỏi.
thân cây

2
"Trong mạng máy tính và khoa học máy tính, băng thông, băng thông mạng, băng thông dữ liệu hoặc băng thông kỹ thuật số là phép đo tốc độ bit của các tài nguyên truyền thông dữ liệu có sẵn hoặc tiêu thụ được biểu thị bằng bit trên giây hoặc bội số của nó (bit / s, kbit / s , Mbit / s, Gbit / s, v.v.) - wikipedia.org/wiki/Bandference_(computing) "
thân từ

Câu trả lời:


43

Nó thường không tương đương.

Các nhà cung cấp phát trực tuyến sử dụng các giao thức, chẳng hạn như DASH , để tự động điều chỉnh chất lượng phim theo mức độ sẵn có của băng thông người dùng và mong muốn chất lượng. Sau đó, các máy chủ có thể giới hạn tốc độ kết nối của bạn để bạn có thể đệm một số tiền nhất định (khoảng 10 giây, có thể 30 hoặc toàn bộ phút) và sau đó bạn chỉ nhận được lượng băng thông cần thiết để đưa nội dung đến cho bạn trong thời gian thực. Đây là một sự tối ưu hóa rõ ràng theo quan điểm của nhà cung cấp, bởi vì nó phân bổ băng thông đồng đều hơn giữa những người dùng và ngoài ra, tránh truyền dữ liệu vô ích (ví dụ: khi người dùng xem phim 480p trong 10 phút, mà không cần duyệt lại và với một đường xuống chung, có khả năng nhiều hơn số đó đã được tải xuống, nhưng sau đó bị lãng phí nếu người dùng ngừng xem video).

Lượng dữ liệu được truyền là như nhau. Nhưng có thể mất nhiều thời gian hơn khi phát trực tuyến, vì nhà cung cấp có thể giới hạn tốc độ truyền dữ liệu đến tốc độ cần thiết để phân phối nội dung theo chất lượng nhất định trong thời gian thực.

Dailymotion là một trong những nhà cung cấp giới hạn tỷ lệ kết nối. Từ một máy chủ có kết nối đối xứng ít nhất 100 Mbit / s, chúng ta thấy các hành vi sau:

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

Tỷ lệ thấp hơn nhiều so với những gì có thể (và đạt được với các nhà cung cấp khác). Ngoài ra, nếu bạn thử các tài liệu khác nhau, bạn sẽ thấy rằng tốc độ phụ thuộc rất nhiều vào từng video: một video fullhd dễ dàng tải xuống với> 1 MiB / s, trong khi video nhạc aa như thế này ở khoảng hoặc dưới 200 KiB / s .

Để tổng hợp tất cả và xóa một số hiểu lầm có thể xảy ra: Một số nhà cung cấp có thể đánh giá giới hạn tải xuống của bạn trong khi phát trực tuyến, thông qua ứng dụng khách của họ (ví dụ: youtube với html5 hoặc trình phát video flash) hoặc bằng máy chủ. Nếu họ không đánh giá giới hạn của bạn theo phương tiện máy chủ, thì việc tải xuống sẽ tiêu tốn nhiều băng thông hơn, bởi vì giới hạn tốc độ có thể được áp dụng bởi ứng dụng khách trong khi truyền phát không diễn ra. Đây là trường hợp chính khi băng thông tiêu thụ khác nhau đối với câu hỏi ban đầu.


  1. Tôi biết rằng đây là một loại bằng chứng trực tràng mà tôi đã quan sát thấy hành vi này một cách nhất quán.

3
@Psycogeek Youtube là một trong những ví dụ sử dụng DASH (nếu nhận xét này không có ý nghĩa với bạn, hãy đọc phần giới thiệu của bài viết tôi đã liên kết). Điều này ngụ ý rằng trình phát mà máy khách đang sử dụng phải yêu cầu các đoạn video liên tục. Thực hiện bước từ đó để ngừng yêu cầu nhiều phần hơn nếu người chơi không chạy là điều tự nhiên. Các trình tải xuống như youtube-dlsẽ chỉ tiếp tục yêu cầu nhiều đoạn hơn cho đến khi video được tải xuống đầy đủ. Vì vậy, phát trực tuyến với DASH phát sinh thêm một chút chi phí, nhưng có lẽ nó đáng giá (cho cả người dùng và nhà cung cấp) và không thể bỏ qua.
Jonas Schäfer

1
Giả sử mã hóa và định nghĩa dữ liệu tương tự được sử dụng (xem bình luận psychogeek) tải xuống sẽ sử dụng tổng băng thông nhiều hơn. Việc tải xuống video gần như chắc chắn sẽ được thực hiện với TCP, trong khi truyền phát sẽ là UDP hoặc phương pháp phân phối không được bảo đảm tương tự. Do đó, TCP sẽ có nhiều acks được gửi tối thiểu và vì bạn có thể sẽ mất hoặc hỏng ít nhất một vài gói, cách tiếp cận tcp cũng thực sự sẽ được tải xuống nhiều hơn (vì nó cũng sẽ tải các gói bị mất). Mặc dù sự khác biệt là rất nhỏ so với kích thước của tải xuống, vì vậy điều này chủ yếu là học thuật.
DSollen

2
@dsollen: Trừ khi người gửi UDP sẽ chỉ để các gói dữ liệu trôi qua mà không quan tâm liệu người nhận dự định có còn tồn tại hay không, cả UDP và TCP sẽ yêu cầu xác nhận định kỳ; trong cả hai trường hợp, các xác nhận sẽ chiếm một phần rất nhỏ trong tổng lưu lượng. Hơn nữa, định dạng dữ liệu theo cách mà mỗi gói có thể được hiểu ngay cả khi gói trước đó không được nhận thường ngụ ý một mức phí vượt quá mức cần thiết cho TCP.
supercat

7
Tôi sẽ đánh giá thấp câu trả lời này nếu tôi có đủ đại diện: nó không trả lời câu hỏi, cụm từ chính là "cùng chất lượng". Khi một nhà cung cấp giảm chất lượng, đây không phải là paribus paribus .
zamnuts

1
@zamnuts, sau đó đăng một cái tốt hơn và để cộng đồng quyết định. FWIW, đó là một chút táo và cam khi bạn xem xét nhà cung cấp quyết định chất lượng giảm, nhưng tôi không nghĩ câu trả lời sẽ hoàn tất nếu không có nó.
paqogomez

19

Giả sử chúng ta đang nói về cùng một chất lượng (nghĩa là không có luồng điều tiết, bỏ qua khung hình hoặc luồng chất lượng thấp hơn), thì tốt nhất là các luồng sẽ có cùng băng thông khi tải xuống, mặc dù có thể được thực hiện theo thời gian / tốc độ thuận tiện hơn cho nhà cung cấp. Nó cũng có thể mất nhiều băng thông hơn tùy thuộc vào cách nén video - hầu hết thời gian toàn bộ hình ảnh không được gửi, thay vào đó chỉ là thay đổi (hoặc delta) giữa các khung. Điều này có nghĩa là càng có nhiều lịch sử (tức là sử dụng màu xanh lam từ pixel X trong khung Y), thì càng cần phải gửi ít hơn. Điều này thường không bật lên nhiều, nhưng khi một luồng bị tạm dừng / gián đoạn vì bất kỳ lý do gì, "lịch sử" này bị mất và sẽ cần được truyền lại, do đó làm tăng băng thông, trong khi với tải xuống, nó có thể được nối lại vào lúc "nghỉ", và giả định rằng người nhận đã có thông tin này. Điều tương tự có thể được sử dụng cho âm thanh, đặc biệt là khi không có tỷ lệ cố định (ví dụ FLAC thay vì mp3)

Nhảy xung quanh (bỏ qua, cuộn lại, v.v.) cũng có thể ảnh hưởng đến việc sử dụng - đi qua bộ đệm sẽ làm giảm lượng băng thông được sử dụng bởi một luồng, nhưng bất kỳ cuộn dây nào cũng sẽ làm tăng nó. Ngoài ra, sẽ có một ngắt, điều này sẽ làm tăng mức sử dụng (xem ở trên) và bất kỳ loại "xem trước hình thu nhỏ" nào như những gì youtube và netflix sử dụng cũng sẽ làm tăng nhẹ băng thông.

Lưu ý cuối cùng: nén: điều này có thể được thực hiện để tải xuống, nhưng không quá nhiều cho các luồng - điều đáng lưu ý là hầu hết các video đã được nén, vì vậy sẽ không có nhiều lợi ích ở đây (mặc dù có thể có nhiều lợi ích trong cực kỳ bộ phận có độ phân giải / chất lượng cao).


7

Truyền phát sẽ sử dụng ít băng thông hơn, đặc biệt nếu điều kiện mạng không tốt, nhưng điều này có giá .

Vấn đề là dữ liệu cần phải được gửi. Trong mô hình tải xuống, tất cả dữ liệu phải đến tay khách hàng, tất cả theo đúng thứ tự, không có vấn đề gì . Nếu điều kiện mạng không tốt và một số bit dữ liệu không đến được máy khách, chúng phải được gửi lại và điều này làm tăng mức sử dụng băng thông. Nếu một số dữ liệu được đưa ra khỏi trật tự, nó phải được đưa trở lại trật tự trước khi được trình bày và điều này làm giảm khả năng phản hồi.

Trong mô hình phát trực tuyến, sẽ ổn nếu một số dữ liệu không đến được máy khách . Nếu bạn đang phát trực tuyến phim và khung hình không đến đó, bạn có thể bỏ qua phim và tiếp tục, vì vậy bạn không sử dụng băng thông bổ sung khi gửi lại. Nếu một số khung hình vượt ra khỏi trật tự, chỉ cần chơi những khung hình đi về phía trước; một đốm sáng tạm thời sẽ không thành vấn đề, và vì vậy điều này làm tăng khả năng phản hồi. Tuy nhiên, điều đó cũng có nghĩa là bạn không nhất thiết phải có được dữ liệu đầy đủ: bất cứ điều gì bạn thấy là bất cứ điều gì có ở lần chụp đầu tiên.

Nếu bạn phải chọn giữa các mô hình, hãy chọn dựa trên những gì bạn muốn làm với dữ liệu. Nếu bạn muốn lưu trữ nó và / hoặc có thể xem nó nhiều lần, sau đó tải xuống để bạn chắc chắn có được mọi thứ. Nếu bạn không có kế hoạch lưu trữ, hoặc chỉ có kế hoạch xem dữ liệu một lần, thì hãy tiếp tục và truyền phát; bạn có thể sẽ không nhận thấy sự khác biệt trong một lần xem và nếu điều kiện mạng đủ tệ để bạn chú ý, thì việc tải xuống sẽ còn tồi tệ hơn.


Bạn đang nói rằng các dịch vụ phát trực tuyến sử dụng UDP thay vì TCP để cố ý cho phép dữ liệu bị mất?
FreeAsInBeer

1
@FreeAsInBeer: Có. TCP xây dựng trong một loạt các cơ chế độ tin cậy và các tính năng khác rất hữu ích cho hầu hết các ứng dụng có thể tưởng tượng. Nhưng các trường hợp sử dụng DO tồn tại khi có những thứ thậm chí còn quan trọng hơn độ tin cậy và phát trực tuyến là một trong số đó: điều quan trọng hơn là hiển thị đúng khung hình vào đúng thời điểm hơn là hiển thị từng khung hình. Chơi game trực tuyến là một ví dụ khác trong đó UDP phổ biến, vì những lý do tương tự: dừng hành động để xây dựng lại dấu vết của trạng thái người chơi còn tệ hơn là phải sửa cho trạng thái thỉnh thoảng bị bỏ.
Chiếc thìa ngon nhất

Trên thực tế, nhiều hệ thống truyền dữ liệu qua TCP và bộ đệm ở phía máy khách. Để phát trực tuyến phim, độ trễ không quan trọng. Không có bất tiện cho người dùng nếu một số khung hình tình cờ ngồi trong bộ đệm trong một phút trước khi đến lúc hiển thị chúng. Nhưng đối với các ứng dụng tương tác như hội nghị truyền hình, độ trễ là rất quan trọng.
kasperd

1
kasperd: Nói đúng ra, đó không phải là phát trực tuyến. Các câu trả lời khác đã đề cập đến các dịch vụ tải xuống nhưng bắt đầu phát trước khi quá trình tải xuống kết thúc và đó là những gì hệ thống bạn mô tả đang làm.
Chiếc thìa ngon nhất

+1 cho câu trả lời ít gây nhầm lẫn nhất (cho đến nay) trong chuỗi này.
Vũ trụ Ossifrage

5

Nếu bạn thực sự yêu cầu "băng thông" (byte / giây) chứ không phải "tổng dữ liệu" (byte), câu hỏi quan trọng là: trong khoảng thời gian nào? Nếu chúng tôi giả định rằng người dùng xem toàn bộ video và trả lại cùng một codec / chất lượng, v.v. và bỏ qua chi phí nhỏ của yêu cầu / phản hồi phát trực tuyến, thì tổng dữ liệu được trả về là bằng nhau.

Bây giờ, băng thông là gì? Có hai cách để hiểu câu hỏi của bạn:

  1. Băng thông trong suốt thời gian cần thiết cho đến khi quá trình tải xuống hoàn tất. Để phát trực tuyến, bạn sẽ thấy các dải băng thông cao (khi đoạn tiếp theo được yêu cầu) trở về 0 trong khi bạn đang xem đoạn đó cho đến khi bạn ở gần cuối đoạn và lại có sự tăng đột biến về băng thông. Để tải xuống, bạn sẽ thấy băng thông rất cao, giả sử, 10 phút sẽ giảm xuống 0 ngay khi toàn bộ video được tải xuống. Nếu bạn dừng thử nghiệm ngay bây giờ, băng thông để tải xuống rõ ràng là cao hơn vì nó tối đa hóa đường xuống của bạn cho đến khi hoàn thành.

  2. Băng thông trong thời gian video được xem. Thời gian video đang được xem là giống nhau cho cả phát trực tuyến và tải xuống, giả sử cả hai bắt đầu xem ngay lập tức. Tổng kích thước dữ liệu là như nhau là tốt. Vì băng thông là dữ liệu mỗi lần, nên cả hai trường hợp đều giống nhau.

Trong ví dụ dưới đây, luôn có tổng cộng 40 (đơn vị dữ liệu) được tải xuống. Nhưng đối với "tải xuống", nó là 40 trong đơn vị thời gian đầu tiên, trong khi "phát trực tuyến" là 20 trong các đơn vị thời gian đầu tiên (để có được một đoạn lớn ban đầu) và sau đó hai lần 10 cho hai khối bổ sung. Lưu ý rằng mặc dù băng thông được vẽ trên trục y, khu vực bên dưới mỗi hai biểu đồ tương ứng với dữ liệu (byte) nếu bạn tích hợp byte / thời gian theo thời gian, bạn sẽ nhận được byte.


4

Họ không thể so sánh được.

Đối với trường hợp đầu tiên, mã hóa tối ưu để xem cục bộ khác với mã hóa tối ưu để xem truyền phát.

Hãy nói về mã hóa video.

Trong hầu hết định dạng mã hóa video, thường có hai loại khung:

  1. Khung mã hóa nội bộ (Khung hình I) - đây là các khung được truyền đầy đủ, khung này có thể được giải mã mà không cần biết về bất kỳ khung nào khác. Một khung mã hóa nội tại về cơ bản là một hình ảnh tĩnh. Bộ mã hóa sẽ tạo ra những thứ này trong quá trình chuyển đổi đột ngột. Đây là ít hiệu quả để nén.
  2. Khung dự đoán (Khung P) hoặc khung dự đoán Bi (Khung B) - đây là các khung chỉ lưu trữ sự khác biệt giữa các khung, nó chỉ có thể được giải mã nếu người xem cũng biết khung trước và / hoặc khung sau. Đây là hiệu quả hơn nhiều để nén.

Mã hóa để xem cục bộ có thể tận dụng các tìm kiếm đĩa nhanh để sử dụng nhiều khung hình P và B hơn, trong khi video được mã hóa để phát trực tuyến hiệu quả sẽ phải mã hóa I-Frame dự phòng nhiều hơn ngay cả khi không có chuyển đổi đột ngột để phù hợp tìm kiếm ngẫu nhiên.

Ngoài ra, có hai loại phát trực tuyến khác nhau. Bạn có thể phát trực tuyến một luồng được ghi trước (hầu hết các video trên Youtube) và các luồng sự kiện trực tiếp (ví dụ: Youtube Live). Do nhu cầu độ trễ, phát trực tiếp sự kiện không thể tận dụng các kỹ thuật mã hóa tiên tiến mất nhiều thời gian hoặc không thể đoán trước, trong khi luồng được ghi trước có thể mất nhiều thời gian như cần mã hóa.

Truyền phát video cũng thường được mã hóa với tốc độ bit không đổi (CBR). Với cùng kích thước mục tiêu, video tốc độ bit biến (VBR) thường sẽ có chất lượng cao hơn video CBR. Ngược lại, video VBR nhỏ hơn với cùng chất lượng của video CBR. Một giao thức truyền phát thích ứng như DASH có bitrate thích ứng (ABR), là một sự thỏa hiệp giữa CBR và VBR. ABR cho phép người xem thích ứng với những thay đổi trong băng thông mạng. Với một băng thông ổn định, nhất quán, ABR ít nhiều giống với CBR.

Tất cả những điều này có nghĩa là có cùng chất lượng và trải nghiệm xem , bạn có thể mã hóa video để xem cục bộ hiệu quả hơn video được phát trực tuyến và bạn có thể mã hóa video cho các luồng được ghi trước hiệu quả hơn so với phát trực tiếp.

Sau đó, cũng có một chi phí trong giao thức truyền phát. Tải xuống HTTP thông thường có thể sử dụng mã hóa chuyển khối để tải xuống toàn bộ tệp có chi phí rất nhỏ. Một tải xuống được truyền phát sẽ phải thương lượng khối và chất lượng của khối để chuyển. Trong sơ đồ lớn của mọi thứ, chi phí chung của giao thức chuyển giao là tương đối nhỏ.

Nhìn chung, với cùng một lượng video được xem, video được phát trực tuyến sẽ chiếm một lượng băng thông lớn hơn. Ưu điểm chính của phát trực tuyến, về mặt sử dụng băng thông, là nó có thể lưu bởi những người tải xuống nhưng không xem video đầy đủ, đây có thể là một cách tiết kiệm rất đáng kể.


1

Câu trả lơi con phụ thuộc vao nhiêu thư".

Câu trả lời là KHÔNG, đối với các nhà cung cấp lưu trữ video nói chung. Một nửa nhà cung cấp hợp lý truyền phát video kiểm soát tốc độ để đảm bảo phát lại mượt mà và băng thông tối ưu cho càng nhiều người càng tốt. Vì vậy, mặc dù bạn có thể có nhiều băng thông, nó có thể quyết định chỉ cung cấp cho bạn 5Mbit và trông vẫn khá ổn.

Nếu bạn thực hiện tải xuống HTTP thì các thuật toán kiểm soát tốc độ TCP sẽ khởi động để đảm bảo rằng bạn bão hòa một hoặc cả hai đầu của kết nối hoặc bất cứ thứ gì ở giữa. Vì vậy, nếu bạn có sẵn 100Mbit, nó sẽ sử dụng tất cả những gì nó có thể nhận được hoặc gần 100Mbit.

Tất nhiên, điều đó giả định rằng không có QoS xảy ra ở bất cứ đâu giữa máy khách và máy chủ.

Câu hỏi của bạn lỏng lẻo đến mức tôi cũng có thể đưa ra để trong một số thiết lập ngây thơ, câu trả lời cũng là CÓ (với các giả định), băng thông giống hệt nhau. Để làm điều đó, chỉ cần thả tệp vào máy chủ web cơ bản của bạn và mở nó bằng trình duyệt của bạn để người xem truy cập. Hoặc nhúng video trên máy chủ web cơ bản của bạn và một lần nữa, nó sẽ phát trong trình duyệt và sử dụng băng thông giống hệt với giả định sau đây ... không có người dùng nào khác, không ai khác chia sẻ mạng với bạn ... không có yếu tố nào khác có thể làm thay đổi băng thông của bạn.

Hãy nhớ rằng khi bạn tải xuống một tệp từ một trang web, sau đó tải lại nó, băng thông giữa lần tải xuống thứ nhất và thứ hai có thể khác nhau. Điều này chỉ đơn giản là vì tải trên máy chủ có thể thay đổi và tắc nghẽn trên mạng và đường dẫn mạng có thể thay đổi.

Vì vậy, bạn có nó ... nó phụ thuộc.


"Băng thông giữa lần tải xuống thứ nhất và lần thứ hai có thể khác nhau" nhưng chắc chắn cuối cùng nó sẽ tải xuống cùng một lượng dữ liệu, ngay cả khi dữ liệu này mất nhiều thời gian hơn các điều kiện mạng khác đã thay đổi.
thân cây

@stemie, Nó sẽ gần thôi. Các giao thức khác nhau thêm giao thức. Nhưng nếu không có sự chuyển mã hoặc chất lượng / tốc độ thay đổi trong quá trình phát trực tuyến thì đó sẽ là cùng một lượng dữ liệu video trên lý thuyết.
Matt H

1

Từ quan điểm mạng "tải xuống" và "phát trực tuyến" là các dịch vụ khác nhau, nó được gọi là "hồ sơ lưu lượng truy cập"

Đối với dịch vụ truyền phát, mạng phải cung cấp thông lượng không đổi tối thiểu (về mặt kỹ thuật "băng thông" có nghĩa là một cái gì đó khác nhau), dịch vụ truyền phát rất nhạy cảm với các gián đoạn và jitter. Nó không yêu cầu thông lượng mạng tối đa, độ trễ hoặc độ trễ là không quan trọng.

Từ góc độ người dùng cuối, điều đó có nghĩa là: Video sẽ chạy trơn tru mà không bị gián đoạn hoặc giảm xuống. Không có vấn đề gì nếu video bắt đầu sớm hơn hoặc chậm hơn vài giây.

"Tải xuống" thường yêu cầu thông lượng mạng tối đa có thể, quá trình tải xuống sẽ được xử lý nhanh nhất có thể. Sự chậm trễ, gián đoạn và jitter không quan trọng.

Một mạng có thể cung cấp nhiều hồ sơ lưu lượng hoàn toàn khác nhau. Ví dụ: dịch vụ thoại (cuộc gọi điện thoại đơn giản) requrie thông lượng rất thấp nhưng rất nhạy cảm với độ trễ (dưới 200 ms)


0

Để thêm vào các câu trả lời khác, câu trả lời của tôi là: Không nhất thiết .

Bây giờ, giả sử rằng mọi thứ đều bằng nhau (không có lựa chọn chất lượng tự động, không điều tiết từ máy chủ và / hoặc ISP) ...

Băng thông thường được định nghĩa là size_of_data chia cho Total_time. (Về mặt kỹ thuật, thuật ngữ 'thích hợp' là thông lượng , nhưng tôi lạc đề).

Giả sử bạn sẽ phát trực tuyến video 2000 giây có kích thước 60 MB.

Với tính năng phát trực tuyến, chương trình truyền phát có thể tự giới hạn tốc độ để ngăn tràn bộ đệm. Vì vậy, tiêu đề yêu cầu HTTP của nó có thể bao gồm trường Phạm vi . Các hiệu quả băng thông kể từ khi dòng bắt đầu cho đến khi luồng đầu sau đó sẽ là ~ 60 MB / 2000 giây = 30 KB / s = 240 kbps.

Tuy nhiên, nếu bạn tải video hoàn toàn, bạn sẽ nhận được lên đến băng thông tối đa của dịch vụ Internet của bạn. Tùy thuộc vào cách sử dụng khác cùng một lúc, tất nhiên. Vì vậy, giả sử dịch vụ Internet 6 Mb / giây, với 50% băng thông khả dụng, bạn sẽ nhận được băng thông 3 Mb / giây để tải xuống video.


0

Truyền phát thực sự là một cách tải về.

Khi bạn xem một bộ phim được phát trực tuyến, trình phát đa phương tiện của bạn sẽ tải xuống các phần của bộ phim đó, hiển thị chúng cho bạn và loại bỏ các phần được hiển thị của tệp khi đang di chuyển.

Thông thường, khi bạn tải xuống một tệp, bạn đợi quá trình tải xuống kết thúc và chỉ sau đó bắt đầu xem nó. Nhưng có những trình phát phương tiện có khả năng hiển thị cho bạn phần đã tải xuống của tệp và tự động tạm dừng và chờ thêm một số phần mềm được tải xuống. Kiểu như phát trực tuyến, nhưng không loại bỏ các tập tin.

Về mặt kỹ thuật, khi mối quan tâm là tổng lượng dữ liệu được truyền, việc bạn tải xuống nó không quan trọng, nhưng sự khác biệt giữa tệp bạn tải xuống và tệp mà trình phát đa phương tiện tải xuống cho bạn dưới dạng luồng. Chúng có thể là cùng một tệp chính xác và điều đó có nghĩa là cùng một băng thông trong cả hai trường hợp.

Các trang web truyền thông trực tuyến thường mã hóa nội dung của chúng để có tốc độ bit thấp hơn so với đĩa mua tại cửa hàng. Nhưng bạn có thể xem phim từ máy tính để bàn trên máy tính xách tay thông qua WiFi bằng chức năng chia sẻ tệp của HĐH và nó sẽ chiếm gần như lưu lượng truy cập như khi bạn xem trên máy tính để bàn (như đọc byte từ cứng lái xe). Về mặt kỹ thuật, nó sẽ được phát trực tuyến, khi bạn xem một bộ phim trong khi các phần của nó liên tục được tải xuống và loại bỏ.

Vì vậy, câu trả lời là nó hoàn toàn phụ thuộc vào kích thước của hai tệp - được truyền qua trình phát phương tiện và được tải xuống đĩa.


0

Truyền phát sử dụng thông lượng tải xuống của bạn do đó bạn có thể coi đó là tải xuống. Câu hỏi của bạn hơi mơ hồ về những gì bạn cho là tải xuống. Bạn chỉ có thể tải xuống càng nhiều tải lên họ có thể và sẵn sàng cung cấp. Vì vậy, cuối cùng nếu bạn muốn so sánh tải xuống trực tiếp từ HTTP qua DASH (vẫn là HTTP), bạn phải kiểm tra xem bạn đang thực hiện tải xuống bao nhiêu từ mỗi.

Vì vậy, tôi đoán câu trả lời là nó có thể sử dụng cùng một lượng ... hoặc ít hơn ... hoặc nhiều hơn. tùy thuộc vào máy chủ và tỷ lệ họ đang phục vụ bạn.


-2

Vâng, nó là tương đương. Tải xuống = Bạn chỉ tải xuống một lần và nó vẫn ở trên máy tính của bạn. Stream = Bạn tạm thời tải "cái gì đó" về máy tính của bạn.


Có sự khác biệt giữa lượng dữ liệu được truyền và băng thông được sử dụng.
Jonas Schäfer

tốt trên Android của tôi xem video từ một luồng hoặc tải xuống nó có cùng cách sử dụng dữ liệu
Tiago Ribeiro

@JonasWielicki Một người đàn ông khôn ngoan đã từng nói: "Lượng dữ liệu được truyền là như nhau". Chắc chắn lượng băng thông được sử dụng khác nhau, trong đó do bộ đệm tốc độ truyền chậm hơn theo thời gian.
Nenotlep

1
Đây thực sự là câu trả lời đúng trong rất nhiều trường hợp. Thông thường trong rất nhiều trường hợp, cùng một tài nguyên và giao thức được sử dụng để truyền phát và tải xuống. Nếu bạn muốn phát tài nguyên qua HTTP, không khác gì tải xuống tài nguyên đó ngoài việc bạn đang phát lại tài nguyên đó khi nó đang được tải xuống. Chắc chắn, có tối ưu hóa để phát trực tuyến và các giao thức khác nhau có thể thay đổi tốc độ bit của bạn khi bạn truyền phát, nhưng tôi không nghĩ đó là cốt lõi của câu hỏi đang được hỏi. (Tuy nhiên, họ xứng đáng được đề cập đến.)
Brad
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.