tìm hiểu công nghệ chia sẻ audio và nghe nhạc trực tuyến qua mạng IP trên môi trường windows hoặc linux

Chức năng: chức năng của hệ thống chia sẻ nhạc nhằm mục đích tạo ra một kho nhạc có thể chia sẻ cho một hoặc nhiều người dùng. Người dùng có thể truy cập vào kho nhạc và thoải mái lựa chọn và chơi nhạc

Báo cáo: Truyền thông đa phương tiện

Đề tài 18 – Nhóm 14: tìm hiểu công nghệ chia sẻ audio và nghe nhạc trực tuyến qua mạng IP trên môi trường windows hoặc linux

Tên thành viên:

Trần Việt Anh – 20121242

An Mạnh Công – 20121330

Nguyễn Như Nai - 20122096

Đoàn khắc hùng - 20121821

Contents

Chương 0: Giới thiệu

Ngày nay, ngành công nghệ thông tin đang phát triển, việc chia sẻ nhạc, video, audio cho lĩnh vực giải trí là cần thiết Đáp ứng nhu cầu này, một số giải pháp một số dịch vụ ra đời

Hiện nay chúng ta có thể biết đến một số trang web chia sẻ nhạc như: zing.vn, youtobe.com, mp3.vn … Việc truy cập vào, và sử dụng dịch vụ nghe nhạc trực tuyến ở các trang web chia sẻ nhạc này là rất đơn giản Vậy chúng ta hãy tự hỏi chúng hoạt động như thể nào? Làm sao mà chỉ

một thiết bị như máy tính, điện thoại lại có thể phát được các bài hát yêu thích khi chỉ cần vào các trang web này? Vậy dữ liệu là gì và nó được truyền như thể nào?

Trong khuôn khổ báo cáo này chúng em sẽ giải thích về một hệ thống chia sẻ nhạc có thể là audio or video, nó làm việc như thể nào, và nó sử dụng công nghệ gì? Các công nghệ áp dụng vào thực tế như thế nào (phần demo)

Chúng em lựa chọn việc nghiên cứu về hệ thống chia sẻ nhạc trên web, môi trường lựa chọn tìm hiểu là môi trường windows và dịch vụ là youtube

Chương I: Tổng quan hệ thống chia sẻ nhạc

Yêu cầu: Tìm hiêu chức năng và hoạt động hệ thống chia sẻ audio và nghe nhac trưc tuyến qua mạng IP, khảo sát dịch vụ hiện có trên môi trường Window hoặc Linux?

1 Chức năng mô hình hoạt động của hệ thống

Chức năng: chức năng của hệ thống chia sẻ nhạc nhằm mục đích tạo ra một kho nhạc có thể chia

sẻ cho một hoặc nhiều người dùng Người dùng có thể truy cập vào kho nhạc và thoải mái lựa chọn và chơi nhạc

Trước khi bắt đầu chúng em xin giới thiệu về một mô hình chia sẻ nhạc cơ bản

Mô hình trên bao gồm 3 phần quan trọng:

- Data music: đây là phần dữ liệu, có thể là các file nhạc, hoặc hệ thống lưu trữ nhạc Nói chugn data music là một kho lưu trữ nhạc Ngày nay một số trang web đã lấy một

số các nguồn online

- Server: server đây là server chia sẻ nhạc, có thể là web server, có thể là streaming server …

- Application Client: Ứng dụng phía client có thể là ứng dụng, có là thiết bị

smartphone, hoặc chính browser của chúng ta Công việc của người dùng là truy cập vào site chia sẻ nhạc chơi và thưởng thức

2 Khảo sát một dịch vụ trên môi trường windows

Có rất nhiều ứng dụng cũng như dịch vụ chia sẻ nhạc hiện có

Như chúng ta đã biết đến thì youtube, zing, mp3 … là những trang web chia sẻ nhạc phổ biến Đối với windows có thể sử dụng windows player để chia sẻ nhạc trong môi trường mạng IP Ngoài ra cũng có một số các phần mềm khác như VLC …

Trong phần thực hành này chúng em sẽ tìm hiểu nghiên cứu về công nghệ sử dụng của youtube data streaming

Chương II: Khảo sát – phân tích công nghệ sử dụng

1 Tổng quan về công nghệ sử dụng (Youtube)

Được thành lập năm 2005, Youtube là một trong những website phát triển nhanh nhất, và đã trở thành một trong những website được truy cập nhiều nhất trên Internet Nó có một tác động đáng

kể đến sự phân bố lưu lượng truy cập Internet, nhưng chính điều đó làm hạn chế khả năng mở rộng và chất lượng dịch vụ Hiểu biết về các tính năng của YouTube là như vậy, rất quan trọng cho mạng lưới mạng và kỹ thuật để phát triển bền vững thế hệ của các dịch vụ mới này Trong bài khảo sát, đầu tiên chúng tôi mô tả cách tăng tính sẵn sàng của siêu dữ liệu trong Web 2.0

có thể được khai thác một cách hiệu quả để cải thiện hiệu suất và khả năng của YouTube Đặc biệt, chúng ta nghiên cứu những lợi ích đạt được bằng cách bộ nhớ đệm địa phương cùng với tìm nạp trước trong việc giảm các thời gian truy cập của client và bắt đầu lên chậm trễ trong việc xem video

2 Phân tích công nghệ sư dụng của youtube

a Youtube làm việc như thế nào?

Một trong những chìa khóa thành công của YouTube là việc sử dụng Flash Video (FLV) định dạng của Adobe để phân phối video Trong khi người dùng có thể tải lên các nội dung trong một loạt các định dạng phương tiện truyền thông (ví dụ, WMV, MPEG và AVI), YouTube chuyển đổi chúng sang Flash Video trước khi gửi bài cho họ Điều này cho phép người dùng xem các video

mà không cần tải bất kỳ trình duyệt bổ sung thêm điều kiện họ có cài đặt Flash Player Để kích hoạt tính năng phát lại các video Flash trước khi nội dung được tải xong, YouTube dựa trên công nghệ tải về tiến bộ của Adobe Truyền thống download-and-play đòi hỏi các tập tin FLV đầy đủ

để được tải về trước khi phát lại có thể bắt đầu Tính năng tải về tiến bộ của Adobe cho phép phát lại để bắt đầu mà không cần tải file hoàn toàn Điều này được thực hiện bằng cách sử dụng lệnh ActionScript đó cung cấp các tập tin FLV để người chơi như là nó đang được tải về, cho phép phát lại các tập tin đã tải về một phần Tải về tiến bộ làm việc với máy chủ Web và nội dung video được giao sử dụng HTTP / TCP

Kỹ thuật vận chuyển này đôi khi được gọi là pseudo-streaming để phân biệt nó từ phương tiện truyền thông truyền thống streaming Truyền thống về yêu cầu trực tuyến của các tập tin đa phương tiện lưu thông thường đòi hỏi việc sử dụng các máy chủ trực tuyến dành riêng cho rằng điều kiện tương tác client-server trong quá trình phát lại video Sự tương tác này có thể được sử dụng cho việc thích ứng của chất lượng video hoặc sử dụng tương tác như nhanh về phía trước hoặc tua lại hoạt động Trong khi nội dung video thường là trọng tâm của một lượt xemm các trang web YouTube, có nhiều chuyển file đó xảy ra đằng sau hậu trường để nhúng các file video

và hiển thị xung quanh nội dung trang web Ví dụ, khi người dùng nhấp vào một video quan tâm, một yêu cầu GET cho các trang tiêu đề của HTML cho các yêu cầu video được thực hiện Trang HTML này thường bao gồm các tài liệu tham khảo cho một số tập tin javascript Những kịch bản này chịu trách nhiệm cho việc nhúng Shockwave Flash (SWF) chơi, và nhiệm vụ ngoại vi khác như xếp hạng xử lý video và bình luận Các tập tin SWF là tương đối nhỏ (26 KB), do đó, các trang web tải nhanh chóng Một khi người chơi được nhúng, một yêu cầu cho các file video FLV được ban hành Các file video FLV được tải về máy tính của người dùng bằng cách sử dụng một yêu cầu HTTP GET, được phục vụ bởi một trong hai máy chủ YouTube hoặc một máy chủ từ một mạng lưới phân phối nội dung (CDN)

Hình 1 minh hoạ các thông tin liên lạc giữa các máy khách, máy chủ YouTube, và một máy chủ của CDN Khi một khách hàng đã chọn một video cụ thể, một thông GET HTTP được gửi từ máy khách đến máy chủ web YouTube Thông báo này chỉ ra rằng client được yêu cầu một video

cụ thể được xác định bởi một định video duy nhất Sau khi nhận được tin nhắn GET, các máy chủ web sẽ trả lời với một tin nhắn chuyển hướng Thông báo này có chứa một trường phản ứng-header vị trí, mà chuyển hướng khách hàng đến máy chủ video từ mà video sẽ được xem trực tiếp

Các cơ chế chuyển hướng giới thiệu cân bằng tải cho hệ thống từ máy chủ web có thể chuyển hướng khách hàng đến một máy chủ video một cách năng động Vì vậy, máy chủ web phải biết được video có thể được phục vụ từ đó các máy chủ video và tải trọng thực tế của video servers

Để cho phép cân bằng tải, YouTube, sử dụng một dịch vụ CDN cung cấp bởi cả hai máy chủ YouTube và Google Video Limelight CDN Một dịch vụ tự động phân phối video đến các máy chủ CDN

b Buffer management

Trong khi truyền dữ liệu qua mang – có thể là audio hoặc video, cần một cơ chế để thiết lập kích thước bộ nhớ đệm (client buffer) để làm sao việc trình diễn audio (video) là tốt nhất để client (người dùng) có một trải nghiệm dịch vụ trên youtube là mượt nhất Thông thường các Flash Player – Plugin xem video sẽ xử lý việc này, sẽ quy định cách xử lý các các giải quyết đối với buffer client tương ứng để cho người dùng cuối có một trải nghiệm dịch vụ tốt nhất Sau đây là một số cách để phân chia buffer client được sử dụng rộng dãi

- Standard video buffering,

- Dual-threshold buffering,

- H.264 encoded video buffering

i Standard video buffering

Đối với cách này, Streaming server (máy chủ chia sẻ nhạc) quản lý bộ nhớ đẹm với một cách thức khá đơn giản Server gửi dữ liệu tới client và dữ liệu đó được lưu trữ trên buffer (bộ nhớ đệm của client) Dữ liệu gửi với tốc độ mạng cho phép – càng nhanh càng tốt Khi buffer đầy (bộ nhớ đệm đầy) – ngưỡng được định nghĩa trước cho phép lưu trữ, thì bắt đầu phát video (audio) Khi đó server tiếp tục gửi dữ liệu cho client nhưng mà chỉ gửi để đủ số lượng buffer cho đầy Nếu tốc độ mạng không cho phép gửi đủ để đầy dữ liệu thì có thể phải đợi một khoảng thời gian

để buffer đầy (trường hợp xem video bị treo) Như vậy việc lựa chọn size buffer rất quan trọng,

nó ảnh hưởng tới chất lượng video.Nếu thực hiện xem lại video thì quá trình thực hiện như lúc đầu, gọi là cơ chế rebuffer-ing

Một buffer size nhỏ có thể trả lại kết quả ngay lập tức (xem video ngay tức khắc) Còn đối với buffer size lớn lại giúp khả năng phục hồi cao phù hợp vào băng thông (việc thực hiện phát lại có thể dễ dàng)

ii Dual-threshold buffering

Có vẻ như cách giải quyết “standard buffering” – cố định buffer không tối ưu khi băng thông tăng hoặc giảm đột ngột “Dual-threshold buffering” là một các sử lý buffer để có thể tối ưu hóa vấn đề này Khi buffer được làm đầy một lượng nhất định (ngưỡng đầu tiên), thì video được trình chiếu như bình thường Sau đó server gửi dữ liệu cho client nhưng sẽ được lưu ở buffer thứ 2 Khi video được trình chiếu hết ở buffer có thể chiển sang video thứ 2 để trình chiếu tiếp Một sự

lặp đi lặp lại sẽ được diễn ra, Chú ý buffer thứ 2 sẽ không có xác đinh size, như vậy sẽ giải quyết được vấn đề nếu băng thông dữ liệu tăng đột ngột

iii H.264 encoded video buffering.

Buffering – bộ nhớ đệm trong H.264 encoded videos phức tạp hơn nhiều so với video FLV buffering bình thường Trong H.264 encode video, video frames có thể tham nhiều từ trong quá khứ và tương lai Vì vậy nó có thể yêu cầu tại lại một frame trước khi bắt đầu phát Điều này có nghĩa rằng các video được mã hóa với H.264 cần một buffer đặc biệt để xử lý các video này, và dịch vụ cung cấp thì không khuyến cáo điều này Giải pháp này chỉ áp dụng đối với video có kiểu encode là H.264

Chương III: Kỹ thuật truyền dữ liệu – youtube streaming

1 Kỹ thuật Video Streaming

a Giới thiệu

Streaming video sử dụng cách thức phát lại các đoạn video được lưu trữ trên các máy tính trên mạng tới người dùng đầu cuối muốn xem đoạn video mà không cần tải đoạn video đó về trên máy tính

Về bản chất, streaming video là quá trình chia nhỏ file video thành các frame, rồi lần lượt gửi từng frame tới một bộ đệm trên máy tính của người xem và hiển thị nội dung frame đó Và quá trình này tuân thủ chặt chẽ về ràng buộc theo thời gian, nói khác là tuân thủ chặt chẽ theo giao thức RTSP, RTP và RTCP

b Kỹ thuật streaming video

Các bước thực hiện kỹ thuật streaming video:

- Phần mềm máy khách (media player, web browser, ) cần kết nối được và xác định file video trên máy streaming server muốn xem

- Yêu cầu streaming file video đó sẽ được gửi tới streaming server để tìm file video đó

- Chương trình thực hiện streaming chạy trên máy streaming server sẽ chia file video thành các frame rồi gửi các frame đó tới máy yêu cầu sử dụng các giao thức ràng buộc về thời gian (RTSP, RTP, RTCP)

- Khi các frame về máy khách, sẽ được lưu trữ trong vùng đệm và nội dung các frame sẽ được giải mã (decode) và hiển thị thông qua các chương trình chơi video (ví dụ VLC)

2 Quá trình truyền dữ liệu

a Quá trình truyền dòng

B1:Mã hóa:

- Âm thanh stream được nén bằng cách sử dụng định dạng âm thanh như MP3, Vorbis hoặc AAC.

- Hình ảnh video stream được nén bằng cách sử dụng codec video như H.264 hoặc VP8

B2.Phân gói:(Lấy mẫu)

- là chia nhỏ nôi dung video thành các khối nhỏ thích hợp để có thể truyền đi trong môi trường mạng ,thực hiện theo thời gian+không gian

o Thời gian:tương ứng với thời gian thể hiện của các khung hình

o Không gian:chia nhỏ các khung hình thành các phần với kích thước thích hợp.

- Yêu cầu:các mẫu phải chứa đủ thông tin dùng cho việc khôi phục lại dữ liêu video ,audio về

cả không gian và thời gian khi bên nhận nhận được.

- Được thực hiện tự đông với giao thức RTP.

B3.Truyền các mẫu qua mạng

- có thể thực hiện trực tiếp thông qua các giao diện của môi trường mạng như Socket hoặc thông qua giao thức cấp cao ở tâng ứng dụng như RTP.Thường dùng cách 2

- các mẫu được đóng gói thành các gói tin ,mang đầy đủ thông tin như thời gian,số thứ tự và các thông tin khác đảm bảo việc khôi phục và đồng bộ các dòng khi bên nhận nhận và trình diễn.Các gói tin được truyền đi thông qua các giao thức lớp dứoi

B4.Khôi phục dữ liệu và đồng bộ

- bên nhận căn cứ vào thông tin trong từng gói để xác định vị trí không gian và thời gian của các mẫu dữ liệu mà gói tin mang theo.

- trường hợp nhiều dòng nhiều dòng khác nhau có quan hệ về thời gian thực thì cần đồng bộ các dòng về mặt thời gian.

- được thực hiện tự động bời các giao thức truyền dòng thời gian thực như RTP.

B5 Giải nén

- giải nén dòng video/audio với chuẩn nén được dùng khi nén.

b Streaming với băng thông và lưu trữ

- Băng thông rộng tốc độ từ 2,5 Mbit /s trở lên được khuyến khích cho việc streaming phim điện ảnh, ví dụ như AppleTV, GoogleTV hoặc SonyTV Blu-ray Disc Player, vào khoảng 10 Mbit/s cho các nội dung độ nét cao HD

- Kích thước lưu trữ Streaming media được tính bằng băng thông để Streaming và chiều dài của các tập tin Media, bằng cách sử dụng công thức sau đây (cho một người dùng duy nhất và tập tin):

Kích thước lưu trữ (MB) = chiều dài (giây) × tỷ lệ bit (bit / s) / (8 × 1024 × 1024)

Ví dụ thực tế:

Một giờ video được mã hóa ở 300 kbit /s (đây là băng thông video điển hình năm 2005 và nó thường được mã hóa 320 x 240 điểm ảnh) sẽ là:

(3.600 s × 300.000 bit / s) / (8 × 1024 × 1024) yêu cầu dung lượng lưu trữ ~128 MB.

Nếu tập tin được lưu trữ trên một máy chủ cho việc streaming theo yêu cầu và được xem bởi 1.000 người cùng một lúc bằng cách sử dụng một giao thức Unicast, yêu cầu là:

300 kbit/s × 1000 = 300.000 kbit/s = 300 Mbit/s của băng thông.

Điều này tương đương với khoảng 135 GB cho mỗi giờ Sử dụng giao thức Multicast server

sẽ gửi ra chỉ một luồng đơn(thông thường) cho tất cả người dùng Do đó, việc Stream như vậy sẽ chỉ sử dụng 300 kbit/s băng thông

Mã hóa âm thanh và video stream được nhúng trong một gói bitstream như FLV, WebM, ASF hoặc ISMA.

Bitstream được phân phối từ một streaming server tới một streaming client bằng cách sử dụng một giao thức truyền tải, ví dụ như là MMS hoặc RTP.

Các streaming client có thể tương tác với streaming server bằng cách sử dụng một giao thức kiểm soát, chẳng hạn như MMS hoặc RTSP.

i Giao thức RTSP

 Giới thiệu

- RTSP (Real Time Streaming Protocol) -Giao thức truyền tin thời gian thực là một tiêu chuẩn

do Nhóm chuyên trách kỹ thuật Internet - Internet Engineering Task Force (IETF) phát hành

- là một giao thức điều khiển trên mạng được thiết kế để sử dụng giao tiếp giữa máy client và máy streaming server Giao thức này được sử dụng để thiết lập và điều khiển phiên giao dịch giữa các máy tính (end points).

 Đặc điểm

- RTSP là một giao thức ở tầng ứng dụng trong bộ các giao thức Internet

- Về hình thức giao thức RTSP cũng có nét tương đồng với giao thức HTTP, RTSP định nghĩa một bộ các tín hiệu điều khiển tuần tự, phục vụ cho việc điều khiển quá trình playback.

- Trong khi giao thức HTTP là giao thức không có trạng thái thì RTSP là giao thức có xác định trạng thái Một định danh được sử dụng khi cần thiết để theo dõi các phiên giao dịch hiện tại của quá trình streaming video gọi là số hiệu session

- Cũng giống như HTTP, RTSP sử dụng TCP là giao thức để duy trì một kết nối đầu cuối tới đầu cuối và các thông điệp điểu khiển của RTSP được gửi bởi máy client tới máy server Nó cũng thực hiện điều khiển lại các đáp trả từ máy server tới máy client Cổng mặc định được

sử dụng bởi giao thức này là 554.

 Cách thực hiện

- Client gửi lên máy server ( streaming server) những request sau và phải theo một trình tự nhất định.

B1.

+ client gửi yêu cầu OPTIONS kèm link trỏ tới file video cần xem tới server, để server chấp

nhận

+Nếu server trả về mã chấp nhận link trên thì client tiếp tục gửi yêu cầu DESCRIBE tới máy server để máy server phân tích đường link Một yêu cầu DESCRIBE bao gồm một đường link RTSP có dạng (rtsp:// ) và kiểu dữ liệu đáp trả từ phía server

+Cổng mặc định được sử dụng cho giao thức RTSP là 554 và cổng này được sử dụng cho cả giao thức của tầng giao vận UDP và TCP