스트리밍은 다운로드와 동일한 양의 대역폭을 사용합니까?

컨텐츠가 동일한 품질 (세 테리아 파리 부)이라고 가정하면 스트리밍 미디어 (예 : 비디오, 오디오)는 컨텐츠를 다운로드 할 때와 동일한 대역폭을 사용합니까?

Amazon에서 HD 영화를 다운로드하거나 스트리밍한다고 가정하면 대역폭을 동등하게 사용할 수 있습니까?

종종 동일하지 않습니다.

스트리밍 제공 업체는 DASH 와 같은 프로토콜을 사용 하여 사용자의 대역폭 가용성 및 품질 요구에 맞게 영화의 품질을 동적으로 조정합니다. 그런 다음 서버가 연결 속도를 제한하여 특정 양 (10 초, 30 분 또는 1 분 정도)을 버퍼링 할 수 있으며 그 후에는 콘텐츠를 실시간으로 얻는 데 필요한 대역폭 만 확보 할 수 있습니다. 이는 사용자의 대역폭을보다 균등하게 분산시키고 데이터가 헛된 것으로 전송되는 것을 방지하기 때문에 (예 : 사용자가 속도 제한없이 10 분 동안 480p 영화를 볼 때) 일반적인 다운 링크를 사용하면 이미 다운 링크 된 것보다 훨씬 더 많이 다운로드되었을 수 있지만 사용자가 비디오 시청을 중단하면 낭비됩니다.

전송 되는 데이터 의 양은 같습니다. 그러나 공급자는 데이터 품질을 콘텐츠를 지정된 품질로 실시간으로 제공하는 데 필요한 속도로 속도 제한 할 수 있기 때문에 스트리밍 시간이 더 오래 걸릴 수 있습니다.

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

요율은 가능한 것보다 훨씬 낮습니다 (다른 제공 업체와 함께 달성). 또한 다른 자료를 사용하면 개별 비디오에 따라 속도가 크게 좌우됩니다. fullhd 비디오는> 1 MiB / s로 쉽게 다운로드되는 반면 뮤직 비디오는 200KiB / s 이하로 유지됩니다. .

요약하면 일부 오해의 여지를 없애기 위해 : 일부 공급자는 스트리밍하는 동안 클라이언트 응용 프로그램 (예 : html5 또는 플래시 비디오 플레이어가있는 YouTube) 또는 서버 수단을 통해 다운로드 속도를 제한 할 수 있습니다. 이들이 서버 수단별로 속도를 제한하지 않으면 스트리밍 중에 클라이언트 응용 프로그램에서 적용 할 수있는 속도 제한이 발생하지 않으므로 다운로드시 더 많은 대역폭이 소비됩니다. 이는 원래 질문과 관련하여 소비되는 대역폭이 다른 경우의 주된 경우입니다.

1. 나는 이것이 일종의 일화 증거라는 것을 알고있다. 그러나 나는이 행동을 일관되게 관찰했다.

동일한 품질 (스로틀 링, 프레임 건너 뛰기 또는 저품질 스트림 없음)에 대해 이야기하고 있다고 가정하면 스트림은 시간 / 속도로 수행 할 수 있지만 다운로드와 동일한 대역폭을 사용하게됩니다. 공급자에게 더 편리합니다. 또한 비디오 압축 방식에 따라 더 많은 대역폭이 필요할 수 있습니다. 대부분의 경우 전체 이미지가 전송되지 않고 프레임 간의 변경 (또는 델타)이 발생합니다. 즉, 이력이 많을수록 (즉, 프레임 Y의 픽셀 X에서 파란색의 색조를 사용) 전송할 필요가 적습니다. 일반적으로 많이 나타나지는 않지만 어떤 이유로 든 스트림이 일시 중지 / 중단되면이 "기록"이 손실되고 다시 전송해야하므로 대역폭을 늘리면 다운로드와 함께 다시 시작할 수 있습니다. "휴식"에서 수신자가 이미이 정보를 가지고 있다고 가정합니다. 고정 속도가없는 경우 (예 : mp3 대신 FLAC) 오디오에도 동일하게 사용할 수 있습니다.

건너 뛰기 (스킵, 되감기 등)도 사용량에 영향을 줄 수 있습니다. 버퍼를지나 가면 스트림에서 사용하는 대역폭의 양이 줄어들지 만 되감기시에는 증가합니다. 또한 인터럽트가 발생하여 사용량이 증가하고 (위 참조) YouTube 및 netflix에서 사용하는 것과 같은 "썸네일 미리보기"도 대역폭을 약간 증가시킵니다.

마지막 참고 사항 : 압축 : 다운로드는 가능하지만 스트림은 그다지 많지 않습니다. 대부분의 비디오가 이미 압축되어 있으므로 여기서 얻을 수있는 이점은 많지 않습니다. 고해상도 / 품질 부서).

스트리밍은 특히 네트워크 상태가 좋지 않은 경우 더 적은 대역폭을 사용하지만 가격이 비쌉니다 .

문제는 전송해야 할 데이터입니다. 다운로드 모델에서 모든 데이터는 무엇이든간에 올바른 순서로 고객에게 도달해야합니다 . 네트워크 상태가 좋지 않고 일부 데이터가 클라이언트에 도달하지 않으면 다시 보내야하므로 대역폭 사용량이 증가합니다. 일부 데이터가 순서에 맞지 않으면 표시되기 전에 순서대로 되돌려 놓아야하므로 응답 성이 떨어집니다.

스트리밍 모델에서 일부 데이터가 클라이언트에 도달하지 않아도 괜찮습니다 . 영화를 스트리밍 할 때 프레임이 표시되지 않으면 건너 뛰고 계속 진행하면 재전송시 추가 대역폭을 사용하지 않습니다. 일부 프레임이 순서에 맞지 않으면 앞으로 진행되는 프레임 만 재생하십시오. 순간적인 실수는 중요하지 않으므로 응답 성이 향상됩니다. 그러나 그것은 또한 당신이 반드시 전체 데이터를 얻을 필요는 없다는 것을 의미합니다. 당신이 보는 것은 첫 번째 장면에서 얻은 것입니다.

모델 중에서 선택해야하는 경우 데이터로 수행 할 작업을 기반으로 선택하십시오. 보관 및 / 또는 여러 번 보려는 경우 모든 것을 얻을 수 있도록 다운로드하십시오. 보관을 계획하지 않거나 데이터를 한 번만 보려는 경우 계속 진행하십시오. 단일보기에서 차이를 느끼지 못할 수 있으며 네트워크 상태가 충분히 나쁘면 다운로드가 더 나빠질 수 있습니다.

"총 데이터"(바이트)가 아닌 "대역폭"(바이트 / 초)을 실제로 요청하는 경우 중요한 질문은 몇 가지 기간입니까? 사용자가 전체 비디오를보고 동일한 코덱 / 품질 등이 반환되고 스트리밍 요청 / 응답의 작은 오버 헤드를 무시한다고 가정하면 반환 된 총 데이터는 동일합니다.

이제 대역폭은 얼마입니까? 질문을 이해하는 데는 두 가지 방법이 있습니다.

1. 다운로드가 완료 될 때까지 걸리는 대역폭. 스트리밍의 경우 청크의 끝 부분에 도달 할 때까지 해당 청크를보고있는 동안 0으로 돌아가는 높은 대역폭의 급증 (다음 청크가 요청 될 때)이 다시 나타나고 대역폭이 다시 급증해야합니다. 다운로드의 경우 전체 비디오를 다운로드하자마자 10 분 동안 매우 높은 대역폭이 표시되어야합니다. 지금 실험을 중단하면 다운 링크가 완료 될 때까지 다운 링크가 최대가되기 때문에 다운로드 대역폭이 분명히 높아집니다.

2. 비디오를 보는 동안의 대역폭. 비디오 시청 시간은 즉시 시청을 시작한다고 가정 할 때 스트리밍과 다운로드 모두 동일합니다. 총 데이터 크기도 동일합니다. 대역폭은 시간당 데이터이므로 두 시나리오 모두 동일합니다.

아래 예에서는 항상 총 40 개 (데이터 단위)가 다운로드됩니다. 그러나 "다운로드"의 경우 첫 번째 단위는 40이고, "스트리밍"의 경우 첫 번째 단위 (20 개) (큰 초기 청크를 얻음) 동안 20이고, 두 개의 추가 청크의 경우 10입니다. 대역폭이 y 축에 표시되어 있지만 두 그래프 각각의 아래 영역은 데이터 (바이트)에 해당합니다. 시간이 지남에 따라 바이트 / 시간 을 통합 하면 바이트를 얻게됩니다.

그것들은 비교할 수 없습니다.

첫 번째 경우, 로컬보기를위한 최적의 인코딩은 스트리밍보기를위한 최적의 인코딩과 다릅니다.

비디오 인코딩에 대해 이야기합시다.

대부분의 비디오 인코딩 형식에는 일반적으로 두 가지 유형의 프레임이 있습니다.

1. 인트라 코딩 된 프레임 (I-Frame)-전체로 전송되는 프레임이며이 프레임은 다른 프레임에 대한 지식 없이도 디코딩 될 수 있습니다. 인트라 코딩 된 프레임은 본질적으로 정적 이미지입니다. 엔코더는 갑작스런 전환 중에이를 생성합니다. 압축 효율이 떨어집니다.
2. 예측 된 프레임 (P- 프레임) 또는 이중 예측 된 프레임 (B- 프레임)-프레임 간의 차이 만 저장하는 프레임으로, 뷰어가 이전 및 / 또는 후자의 프레임을 알고있는 경우에만 디코딩 할 수 있습니다. 압축하는 것이 훨씬 더 효율적입니다.

로컬보기를위한 인코딩은 더 많은 P 및 B 프레임을 사용하기 위해 빠른 디스크 탐색을 활용할 수 있지만 효율적인 스트리밍을 위해 인코딩 된 비디오는 수용 할 갑작스러운 전환이없는 경우에도 전체 비디오를 통해 더 많은 중복 I-Frame을 인코딩해야합니다. 무작위 탐색.

또한 두 가지 유형의 스트리밍이 있습니다. 사전 녹화 된 스트림 (대부분의 Youtube 비디오) 및 라이브 이벤트 스트림 (예 : Youtube Live)의 스트리밍을 가질 수 있습니다. 대기 시간 요구로 인해 스트리밍 라이브 이벤트는 오래 걸리거나 예측할 수없는 시간이 걸리는 고급 인코딩 기술을 이용할 수 없으며 사전 녹화 된 스트림은 인코딩하는 데 시간이 오래 걸릴 수 있습니다.

스트리밍 비디오는 일반적으로 고정 비트 전송률 (CBR)로 인코딩됩니다. 동일한 대상 크기의 경우 VBR (가변 비트 전송률) 비디오는 일반적으로 CBR 비디오보다 품질이 높습니다. 반대로 VBR 비디오는 동일한 품질의 CBR 비디오에 대해 더 작습니다. DASH와 같은 적응 스트리밍 프로토콜에는 적응 비트 전송률 (ABR)이 있으며 이는 CBR과 VBR의 절충입니다. ABR을 통해 시청자는 네트워크 대역폭의 변화에 ​​적응할 수 있습니다. 일정하고 일관된 대역폭이 주어지면 ABR은 CBR과 거의 동일합니다.

이러한 모든 의미는 동일한 품질과 시청 환경을 제공하므로 스트리밍 비디오보다 로컬에서 볼 수 있도록 비디오를보다 효율적으로 인코딩하고 라이브 스트림보다 미리 녹화 된 스트림에 대해 비디오를 인코딩 할 수 있습니다.

그런 다음 스트리밍 프로토콜에도 오버 헤드가 있습니다. 정기적 인 HTTP 다운로드는 청크 전송 인코딩을 사용하여 오버 헤드가 매우 적은 전체 파일을 다운로드 할 수 있습니다. 스트리밍 된 다운로드는 전송하기 위해 청크와 청크의 품질을 협상해야합니다. 전체적인 방식에서 전송 프로토콜의 오버 헤드는 상대적으로 적습니다.

전반적으로 동일한 양의 비디오를 시청하려면 스트리밍 비디오가 더 많은 대역폭을 차지하게됩니다. 대역폭 사용 측면에서 스트리밍의 주요 이점은 다운로드는했지만 비디오를 전체적으로 보지 않는 사람들이 저장할 수 있다는 것입니다.

대답은 "그것은 달려있다"입니다.

일반적으로 비디오를 호스팅하는 제공 업체는 '아니요'입니다. 비디오를 스트리밍하는 절반 정도의 서비스 제공 업체는 속도 제어를 통해 최대한 많은 사람들에게 원활한 재생과 최적의 대역폭을 보장합니다. 따라서 많은 대역폭이 있더라도 5Mbit 만 제공하고 여전히 괜찮은 것처럼 보일 수 있습니다.

HTTP 다운로드를 수행하면 TCP 속도 제어 알고리즘이 시작되어 연결의 한쪽 또는 양쪽 끝 또는 그 사이의 모든 것을 포화시킵니다. 따라서 100Mbit를 사용할 수 있다면 100Mbit 또는 그 근처에서 사용할 수있는 모든 것을 사용합니다.

물론 클라이언트와 서버 사이에 QoS가 발생하지 않는다고 가정합니다.

귀하의 질문은 너무 느슨하여 일부 순진한 설정에서 대답도 YES (가정 포함)이므로 대역폭이 동일합니다. 이렇게하려면 파일을 기본 웹 서버에 놓고 브라우저에서 파일을 열어서 뷰어가 시작되도록합니다. 또는 기본 웹 서버에 비디오를 포함하면 다시 브라우저에서 재생되며 동일한 대역폭을 사용합니다. 다음과 같은 가정은 ... 다른 사용자 나 다른 사용자와 네트워크를 공유하는 사람은 없습니다. 대역폭을 변경시킬 수있는 다른 요인은 없습니다.

웹 사이트에서 파일을 다운로드 한 다음 다시 다운로드하면 첫 번째 다운로드와 두 번째 다운로드 사이의 대역폭이 다를 수 있습니다. 서버의로드가 변경 될 수 있고 네트워크 및 네트워크 경로의 정체가 변경 될 수 있기 때문입니다.

그래서 당신은 그것을 가지고 있습니다 ... 그것은 달려 있습니다.

네트워크 관점에서 "다운로드"와 "스트리밍"은 다른 서비스이므로 "트래픽 프로필"이라고합니다.

스트리밍 서비스의 경우 네트워크는 최소한의 일정한 처리량 (기술적으로 "대역폭"은 다른 의미)을 제공해야하며, 스트리밍 서비스는 중단 및 지터에 민감합니다. 최대 네트워크 처리량을 요구하지 않으며 지연 또는 대기 시간은 중요하지 않습니다.

최종 사용자 관점에서 볼 때 다음과 같은 의미입니다. 비디오는 방해받지 않고 원활하게 실행되어야합니다. 비디오가 몇 초 전부터 시작되는지는 중요하지 않습니다.

"다운로드"는 일반적으로 가능한 최대 네트워크 처리량을 요구하며, 다운로드는 가능한 빨리 완료되어야합니다. 지연, 중단 및 지터는 중요하지 않습니다.

네트워크는 완전히 다른 트래픽 프로파일을 더 제공 할 수 있습니다. 예를 들어 음성 서비스 (단순 전화)는 처리량이 매우 적지 만 지연 (200ms 미만)에 매우 민감합니다.

다른 답변에 추가하려면, 내 대답은 : 꼭 그렇지는 않습니다 .

이제 모든 것이 동일하다고 가정하면 (자동 품질 선택 없음, 서버 및 / 또는 ISP의 제한 없음) ...

대역폭 은 일반적으로 size_of_data를 total_time으로 나눈 값으로 정의됩니다. (기술적으로 '적절한'용어는 쓰루풋 이지만, 나는 다릅니다.)

60 초 크기의 2000 초 비디오를 스트리밍한다고 가정 해 봅시다.

스트리밍을 통해 스 트리머 프로그램 은 버퍼 오버 플로우를 방지하기 위해 자체 속도 제한을 수행 할 수 있습니다 . 따라서 해당 HTTP 요청 헤더에는 Range 필드 가 포함될 수 있습니다 . 스트리밍이 시작될 때까지 스트리밍이 시작된 이후 의 유효 대역폭은 ~ 60MB / 2000 초 = 30KB / s = 240kbps입니다.

그러나 비디오를 완전히 다운로드하면 인터넷 서비스의 최대 대역폭 까지 얻을 수 있습니다. 물론 다른 사용법에 따라. 따라서 인터넷 서비스가 6Mbps이고 사용 가능한 대역폭이 50 %라고 가정하면 비디오 다운로드에 3Mbps의 대역폭이 제공됩니다.

스트리밍은 실제로 다운로드 방법입니다.

스트리밍 된 영화를 볼 때 미디어 플레이어는 영화의 일부를 다운로드하여 보여주고 파일의 표시된 부분을 즉시 버립니다.

일반적으로 파일을 다운로드 할 때 다운로드가 완료 될 때까지 기다렸다가 파일을보기 만하면됩니다. 그러나 파일의 다운로드 된 부분을 보여줄 수있는 미디어 플레이어가 있으며 자동으로 일시 중지되어 더 많은 파일이 다운로드 될 때까지 기다립니다. 스트리밍을 좋아하지만 파일을 버리지 않습니다.

기술적으로, 전송되는 총 데이터 양이 문제인 경우 다운로드 방법은 중요하지 않지만 다운로드 한 파일과 미디어 플레이어가 스트림으로 다운로드 한 파일의 차이입니다. 이들은 동일한 정확한 파일 일 수 있으며 두 경우 모두 동일한 대역폭을 의미합니다.

스트리밍 미디어 사이트는 일반적으로 콘텐츠를 상점에서 구입 한 디스크보다 낮은 비트 전송률로 인코딩합니다. 그러나 OS의 파일 공유 기능을 사용하여 WiFi를 통해 노트북에서 데스크탑 PC의 영화를 볼 수 있으며 데스크탑에서 보는 것처럼 거의 동일한 양의 트래픽을 차지합니다 (하드에서 바이트를 읽는 것처럼) 드라이브). 기술적으로는 일부가 지속적으로 다운로드되어 삭제되는 동안 영화를 보면서 스트리밍됩니다.

답은 미디어 플레이어를 통해 스트리밍되고 디스크로 다운로드 된 두 파일의 크기에 따라 결정됩니다 .

스트리밍은 다운로드 처리량을 사용하므로 다운로드로 간주 할 수 있습니다. 귀하의 질문은 다운로드로 간주하는 것에 대해 약간 모호합니다. 제공 할 수 있고 제공하고자하는 업로드 만 다운로드 할 수 있습니다. 따라서 예를 들어 HTTP over DASH (여전 HTTP)의 직선 다운로드를 비교하려면 각각에서 다운로드하는 양을 확인해야합니다.

답은 같은 양을 사용할 수 있다는 것입니다. 서버 및 서비스 제공 속도에 따라

그렇습니다. 다운로드 = 한 번만 다운로드하면 컴퓨터에 유지됩니다. Stream = 컴퓨터에 "무언가"를 일시적으로 다운로드합니다.