Truyền trực tuyến từ bên trong các trang HTML, bằng ví dụ

Vì vậy, tôi là một kỹ sư phần mềm đang cố gắng tìm hiểu một số chi tiết khó chịu về cách thức hoạt động của phương tiện truyền thông. Tôi đã dành phần lớn thời gian trong ngày để cố gắng hiểu các loại tiền mã hóa, định dạng chứa và các giao thức truyền phát phù hợp với ứng dụng của tôi. Cho đến nay, đây là sự hiểu biết của tôi về cách thức hoạt động của nó, rất có thể bị đánh lừa:

• Truyền phát trực tuyến thực sự sôi sục với định dạng container và giao thức truyền phát :
  • Tất cả dữ liệu âm thanh được mã hóa (thông qua codec âm thanh) thành luồng bit âm thanh
  • Tất cả dữ liệu video được mã hóa (một lần nữa, thông qua codec) thành dòng bit video
  • Hai luồng được hợp nhất ( ghép kênh? ) Với nhau thành một thùng chứa mà cuối cùng trở thành một tệp (chẳng hạn như MP4, v.v.)
  • Sau đó, một máy chủ phương tiện đặc biệt sẽ phục vụ bộ chứa này (tệp MP4 hoặc một số định dạng khác) cho khách hàng (có thể là trình phát Video HTML5 chạy bên trong trình duyệt của ai đó) thông qua một số giao thức truyền phát tiêu chuẩn, chẳng hạn như RTSP
    • Trong trường hợp máy khách trình duyệt, tôi giả sử chính trình duyệt có ứng dụng khách RTSP mà sau đó trình bày cho người dùng HTML5 Video Player
• Tôi có thể lưu trữ tệp MP4 từ máy chủ web , chẳng hạn như nginx hoặc httpd, nhưng vì các máy chủ đó không phải là máy chủ RTSP, nên chỉ có thể coi các yêu cầu cho MP4 là yêu cầu tải xuống và do đó, không thể truyền phát tập tin phương tiện truyền thông
  • Tương tự, nếu tôi sử dụng curlđể tìm nạp các tệp từ máy chủ nginx, vì cả curlnginx cũng không nói RTSP, nó sẽ được coi là tải xuống tệp
• Nhưng, khi tôi lưu trữ tệp MP4 từ máy chủ phương tiện truyền phát trực tuyến (Videolan, Red5, Wowza, v.v.) và tôi sử dụng ứng dụng khách RTSP (hoặc bất kỳ ứng dụng truyền phát trực tuyến được hỗ trợ nào) để yêu cầu truyền phát từ máy chủ đó , sau đó và chỉ sau đó có bất kỳ luồng thực tế xảy ra
  • Do đó, mặc dù các "video" YouTube hoặc Vimeo được lưu trữ trên các trang HTML được cung cấp qua HTTP (S) bởi các máy chủ HTTP, tôi cho rằng các trình phát video được nhúng trên các trang đó (nơi mà các video thực sự phát ra) thực sự bắt đầu một giây , kết nối tiếp theo đến máy chủ phát trực tuyến và phát trực tuyến đang diễn ra qua RTSP hoặc một số giao thức không phải HTTP khác

Vì vậy, đó là sự hiểu biết của tôi và tôi đoán trước tiên tôi sẽ hỏi rằng nếu bất cứ điều gì tôi nêu ở trên là không chính xác, vui lòng bắt đầu bằng cách sửa lỗi cho tôi! Giả sử tôi ít nhiều đúng:

Làm cách nào để phát trực tuyến trình phát phương tiện, chạy bên trong các trang HTML và được phục vụ bởi các máy chủ HTML, thiết lập kết nối phát trực tuyến (RTSP, v.v.) với các máy chủ truyền phát trực tuyến (phục vụ các yêu cầu RTSP)?

Làm cách nào để phát trực tuyến trình phát phương tiện, chạy bên trong các trang HTML và được phục vụ bởi các máy chủ HTML, thiết lập kết nối phát trực tuyến (RTSP, v.v.) với các máy chủ truyền phát trực tuyến (phục vụ các yêu cầu RTSP)?

Các ứng dụng phổ biến

RTSP hiện dường như được sử dụng nhiều hơn với các ứng dụng / giao diện thiết bị trực tiếp dòng sống (ví dụ như camera IP) hoặc tái suối (giống như một động cơ) hơn là cho truyền các tập tin media lưu từ một vị trí địa lý thông qua một giao diện phát HTTP web với một người chơi nhúng.

Dường như RTSP là một giao thức trạng thái và nó sử dụng UDP nhiều hơn TCP khi phát trực tuyến và nó được sử dụng nhiều hơn như một thiết bị máy chủ (như camera IP) được kết nối với mạng TCP / IP và cung cấp luồng qua UDP, v.v. Sau đó, bạn kết nối với các nguồn cấp dữ liệu này (máy chủ) với tư cách là máy khách trên cùng một mạng và bạn có thể đưa ra các yêu cầu RTSP để sử dụng tương ứng.

^{Chỉ thị giao thức}

^{Mặc dù tương tự theo một số cách với HTTP, RTSP định nghĩa các chuỗi điều khiển hữu ích trong việc kiểm soát phát lại đa phương tiện. Trong khi HTTP không trạng thái , RTSP có trạng thái; một định danh được sử dụng khi cần thiết để theo dõi các phiên đồng thời. Giống như HTTP, RTSP sử dụng TCP để duy trì kết nối đầu cuối và trong khi hầu hết các thông báo điều khiển RTSP được máy khách gửi đến máy chủ, một số lệnh di chuyển theo hướng khác (tức là từ máy chủ đến máy khách).}

^{Trình bày ở đây là các yêu cầu RTSP cơ bản. Một số yêu cầu HTTP điển hình, như yêu cầu TÙY CHỌN, cũng có sẵn. Số cổng của lớp vận chuyển mặc định là 554 [3] cho cả TCP và UDP, cái sau hiếm khi được sử dụng cho các yêu cầu điều khiển.}

^_nguồn

^{Không quốc tịch}

^{Giao thức không trạng thái không yêu cầu máy chủ lưu giữ thông tin phiên hoặc trạng thái về từng đối tác truyền thông trong suốt thời gian của nhiều yêu cầu. Ngược lại, một giao thức yêu cầu giữ trạng thái nội bộ trên máy chủ được gọi là giao thức trạng thái .}

^{Một nhược điểm của trạng thái không trạng thái là có thể cần bao gồm thông tin bổ sung trong mỗi yêu cầu và thông tin bổ sung này sẽ cần được máy chủ giải thích.}

^_nguồn

Dòng chảy tự nhiên

Cách tôi hiểu luồng truyền phát trực tuyến ở dạng này là:

• máy chủ nơi chứa nội dung đa phương tiện sẽ đóng gói, nén, mã hóa, v.v. nội dung dữ liệu video / âm thanh ở các định dạng và phân đoạn thích hợp để phân phối luồng
• máy chủ web lắng nghe các kết nối để truy cập phương tiện truyền phát sẽ cung cấp tất cả các tài nguyên cần thiết để truyền phát phương tiện
• khách hàng yêu cầu và tải xuống các tài nguyên và tệp có thể áp dụng, sau đó lắp ráp chúng liên tục để phát lại thông qua con trỏ URL như được định cấu hình và các tham số khác. Phần mềm phát lại ở cấp máy khách lắp ráp các gói được truyền theo trình tự để cho phép phát lại nội dung phù hợp.

Vui lòng xem phần Công nghệ phát trực tuyến bên dưới để so sánh chung về HTTP và RTSP.

Hơn nữa

Trong 10 lý do dưới đây tại sao bạn không bao giờ nên lưu trữ phần Video của riêng mình, tôi đã trích dẫn các phần để giúp trả lời câu hỏi của bạn một cách "chung chung" mà không quá cụ thể.

Về cơ bản, nó nói rằng trang web có các điều khiển trình phát đa phương tiện nhúng sẽ:

• ⁽¹⁾ phát hiện cài đặt trình duyệt web của khách hàng khi "kết nối và yêu cầu" từ máy khách và
• ⁽²⁾ điều này sẽ đặt codec và mọi cài đặt phát hiện phía máy khách khác thành các giá trị tham số áp dụng, và sau đó
• ⁽³⁾ nó sẽ truyền phát video trực tiếp từ máy chủ phát trực tuyến mà bạn lưu trữ các tệp video và âm thanh dựa trên mã khác trong cấu hình trình phát phương tiện được nhúng của bạn trỏ đến URL của tệp phương tiện trên máy chủ được lưu trữ.

^{Công nghệ truyền phát}

^{Trình duyệt máy khách phải nhận dữ liệu từ máy chủ và chuyển nó đến ứng dụng phát trực tuyến để xử lý. Ứng dụng phát trực tuyến chuyển đổi dữ liệu thành hình ảnh và âm thanh. Một yếu tố quan trọng trong sự thành công của quá trình này là khả năng khách hàng nhận dữ liệu nhanh hơn mà ứng dụng có thể hiển thị thông tin. Dữ liệu dư thừa được lưu trữ trong bộ đệm - một vùng bộ nhớ dành riêng cho việc lưu trữ dữ liệu trong ứng dụng. Nếu dữ liệu bị trì hoãn khi chuyển giữa hai hệ thống, bộ đệm trống và phần trình bày của tài liệu sẽ không được trơn tru.}

^{Giao thức HTTP}

^{HTTP là cách chủ yếu trong đó các tài liệu được liên kết trên Internet. Máy khách tạo kết nối đến máy chủ chứa tệp được truyền phát, tệp được truy xuất và kết nối được đóng lại. Máy chủ HTTP giao tiếp với trình duyệt loại tệp sẽ được chuyển.}

^{Lợi ích khi sử dụng HTTP}

^{Khi truyền phát tệp bằng HTTP, không cần có máy chủ phát trực tuyến đặc biệt. Miễn là trình duyệt của bạn hiểu các loại MIME, nó có thể nhận tệp phát trực tuyến từ máy chủ HTTP. Một trong những lợi thế khác biệt của việc truyền phát tệp bằng HTTP là nó có thể đi qua tường lửa và sử dụng máy chủ proxy.}

^{Một số nhược điểm}

^{Truyền phát HTTP sử dụng TCP / IP (Giao thức điều khiển truyền và giao thức Internet) để đảm bảo phân phối tệp đáng tin cậy. Quá trình này kiểm tra các gói bị thiếu và yêu cầu chúng được truyền lại. Điều này trở nên có vấn đề trong kịch bản phát trực tuyến khi bạn muốn dữ liệu bị bỏ qua nếu bị mất trong phân phối, vì vậy các tệp động tiếp tục phát. HTTP không thể phát hiện tốc độ modem, do đó, quản trị viên máy chủ phải cố tình tạo các tệp ở các tốc độ nén khác nhau cho người dùng máy chủ với các loại kết nối khác nhau. Truyền tệp từ máy chủ HTTP không được khuyến nghị cho các tình huống yêu cầu cao.}

^{Giao thức RTSP}

^{RTSP là giao thức chuẩn được sử dụng bởi hầu hết các nhà cung cấp máy chủ phát trực tuyến. Máy chủ RTSP sử dụng UDP (Giao thức gói dữ liệu người dùng) để truyền tệp phương tiện. UDP không liên tục kiểm tra xem các tệp đã đến đích của chúng chưa. Đây là một lợi thế cho các ứng dụng phát trực tuyến vì nó cho phép việc truyền tệp bị gián đoạn miễn là độ trễ không quá dài. Kết quả của phương pháp này là đôi khi mất dữ liệu, nhưng các tệp vẫn tiếp tục phát nếu độ trễ nhỏ.}

^nguồn

^{10 lý do tại sao bạn không bao giờ nên lưu trữ video của riêng bạn}

^{Chúng tôi đang nói về việc nhúng so với video tự lưu trữ}

^{Đầu tiên, bạn tải tệp video của mình lên dịch vụ lưu trữ video của bên thứ ba như YouTube, Vimeo hoặc Wistia.}

^{Sau đó, bạn sao chép một chút mã mà họ cung cấp cho bạn và dán nó vào bài đăng hoặc trang của bạn trên trang web WordPress của riêng bạn. Video sẽ xuất hiện trên trang web của bạn, tại vị trí bạn đã dán mã nhúng, nhưng chính video đó đang được truyền phát từ máy chủ của máy chủ video, trái ngược với máy chủ web của riêng bạn, nơi trang web WordPress của bạn được lưu trữ.}

^{4. Không có tiêu chuẩn định dạng tệp đơn cho video trên web}

^{Đặc tả dự thảo HTML5 hiện tại không chỉ định trình duyệt định dạng video nào sẽ hỗ trợ. Do đó, các trình duyệt web chính đã chuyển hướng, mỗi trình duyệt hỗ trợ một định dạng khác nhau. Internet Explorer và Safari sẽ phát video H.264 (MP4), nhưng không phát trực tuyến WebM hoặc Ogg. Firefox sẽ phát video Ogg hoặc WebM, nhưng không phải H.264. Rất may, Chrome sẽ phát tất cả các định dạng video chính, nhưng nếu bạn muốn đảm bảo video của mình sẽ phát lại trên tất cả các trình duyệt web chính, bạn sẽ phải chuyển đổi video của mình thành nhiều định dạng: .mp4, .ogv và .webm}

^{5. Hy vọng bạn thích chuyển đổi video. Rất nhiều.}

^{Hầu hết khán giả của bạn có thể sẽ xem video của bạn từ máy tính để bàn hoặc máy tính xách tay của họ với lợi ích của kết nối Internet tốc độ cao. Đối với những người này, bạn sẽ muốn cung cấp một tệp lớn, chất lượng HD để họ có thể xem toàn màn hình nếu họ chọn. Nói chung, điều này có nghĩa là tệp 1080p hoặc 720p ở tốc độ bit phát trực tuyến cao (5000 - 8000 kbps).}

^{Nhưng bạn cũng sẽ muốn mã hóa một phiên bản nhỏ hơn, độ phân giải thấp hơn để phân phối đến các thiết bị di động như điện thoại và máy tính bảng, cũng như phân phối cho người xem có kết nối Internet chậm hơn.}

^{6. Trình phát video}

^{Trình phát video là một phần mềm web nhỏ mà bạn cài đặt trên trang web của mình, nó sẽ tự động phát hiện thiết bị nào đang yêu cầu video của bạn, cùng với tốc độ kết nối của nó, sau đó cung cấp phiên bản phù hợp cho người đó.}

^{7. Mã rườm rà [hoặc Shortcodes]}

^{Cho dù bạn sử dụng plugin của bên thứ ba hoặc khả năng video tích hợp của WordPress, bạn sẽ cần tạo một chút mã để báo cho trình phát video những định dạng bạn đã tạo, cũng như vị trí của chúng trên máy chủ. Nó trông giống cái này}

<video poster="movie.jpg" controls>
<source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/>
<source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/>
<source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
<p>This is fallback content</p>
</video>

Vậy đâu là giải pháp tốt nhất để thêm video vào trang web của bạn?

Chỉ cần sử dụng dịch vụ lưu trữ video của bên thứ ba, sau đó chỉ cần nhúng video của bạn vào bài đăng hoặc trang WordPress của bạn.

Bước một: Tải video của bạn lên một trong những dịch vụ lưu trữ video phổ biến, được thiết lập tốt như Vimeo PRO.

Bước hai: Khi video của bạn đã được tải lên và sẵn sàng để xem, hãy sao chép URL vào video của bạn. Quay lại trang web WordPress của bạn và dán URL vào bài đăng hoặc trang của bạn nơi bạn muốn video xuất hiện.

---

^{Khi mọi người xem trang của bạn, video sẽ xuất hiện ở vị trí bạn dán URL. Nhưng bản thân tệp video sẽ được truyền phát từ máy chủ của máy chủ video, trái ngược với máy chủ của chính bạn, nơi trang web WordPress của bạn được lưu trữ.}

_{Trình phát video được nhúng sẽ tự động phát hiện thiết bị, trình duyệt và tốc độ kết nối Internet của người dùng, sau đó cung cấp phiên bản phù hợp của tệp video cho họ. Không có gì để cài đặt trên trang web của bạn. Không có plugin để cập nhật. Không có mã khó khăn.}

_nguồn

Tôi sẽ xử lý bên dưới chủ yếu câu hỏi của bạn về những gì diễn ra khi một video được hiển thị trong trình duyệt. Chủ đề rất rộng lớn, vì vậy tôi sẽ chỉ chạm vào các mục có liên quan.

HTML5 đã giới thiệu <VIDEO>thẻ giải quyết vấn đề tích hợp video được hiển thị vào trình duyệt trong khi sử dụng JavaScript và CSS. <OBJECT>Thẻ trước yêu cầu phần mềm bên ngoài và được tích hợp kém với trang. Thẻ mới có hiệu lực yêu cầu trình duyệt cũng trở thành trình phát video, mặc dù không có tiêu chuẩn nào được áp đặt. Kết quả là sự phân mảnh hoàn toàn của các tiêu chuẩn, mà giải pháp duy nhất là máy chủ video sẽ cung cấp một số định dạng video và tất cả các nguồn thay thế này được chỉ định trong <VIDEO>thẻ, từ đó trình duyệt sẽ chọn một tiêu chuẩn mà nó hỗ trợ.

Một ví dụ về thẻ có nhiều nguồn:

<video width=320 height=240 controls poster=image.jpg>
   <source src="movie.mpd">
   <source src="movie.webm">
   Your browser does not support the video tag.
</video>

Bản <VIDEO>thân thẻ là bất khả tri về giao thức, vì vậy có thể sử dụng bất kỳ giao thức nào được trình duyệt hỗ trợ bao gồm RTSP. Hỗ trợ cho giao thức MPEG-DASH (Dynamic Thích ứng Truyền qua HTTP) gần đây đã trở nên rất toàn diện, do đó, nó sẽ phát trên hầu hết các thiết bị và trình duyệt gốc hoặc sử dụng HTML5, có nghĩa là không cần bổ sung thêm. Xem biểu đồ Tương thích Thiết bị và Trình duyệt này . Xem thêm bài viết Mozilla này để chuẩn bị máy chủ của bạn phục vụ MPEG-DASH. DASH hoạt động thông qua HTTP, do đó, điều này sẽ hoạt động miễn là máy chủ HTTP của bạn hỗ trợ các yêu cầu phạm vi byte và nó được thiết lập để phục vụ các tệp .mpd với mimetype="application/dash+xml".

Sự tương tác bình thường giữa máy khách và máy chủ trông tương tự như sau. Đối với VIDEO HTML5, trình duyệt cũng là trình phát, mặc dù nó có thể mở một kết nối mới để phát.

Kết nối ban đầu cung cấp siêu dữ liệu mà khách hàng sử dụng để hiển thị video. Nếu giao thức RTSP được sử dụng để lấy siêu dữ liệu đó, thì kết nối RTP sau đó sẽ được tạo để truyền dữ liệu video + âm thanh. Giao thức RTCP được sử dụng để chuyển các lệnh bổ sung đến máy chủ.

RTP, RTCP và RTSP đều hoạt động trên các cổng khác nhau. Thông thường khi RTP ở trên cổng N, RTCP ở trên cổng N + 1. Một phiên RTP có thể chứa nhiều luồng được kết hợp ở cuối của người nhận; ví dụ: âm thanh và video có thể nằm trên các kênh riêng biệt.

Để không ai bị khóa khỏi nội dung của bạn, bạn nên cung cấp cả codec miễn phí bản quyền, webM hoặc Theora, và video H.264, và cả âm thanh Vorbis và MP3. (Nói dễ, khó làm.)

Đây là những gì xảy ra chi tiết cho RTSP:

1. Máy khách thiết lập kết nối TCP đến các máy chủ, thường là trên cổng TCP 554, cổng nổi tiếng cho RTSP.

2. Sau đó, máy khách sẽ bắt đầu phát hành một loạt các lệnh tiêu đề RTSP có định dạng tương tự HTTP, mỗi lệnh được máy chủ thừa nhận. Trong các lệnh RTSP này, máy khách sẽ mô tả cho các chi tiết máy chủ về các yêu cầu phiên, chẳng hạn như phiên bản RTSP mà nó hỗ trợ, vận chuyển được sử dụng cho luồng dữ liệu và bất kỳ thông tin cổng UDP hoặc TCP liên quan nào. Thông tin này được truyền bằng cách sử dụng các tiêu đề DESCRIBE và SETUP và được tăng cường trên phản hồi của máy chủ với ID phiên mà máy khách và mọi thiết bị proxy tạm thời có thể sử dụng để xác định luồng trong các trao đổi tiếp theo.

3. Khi quá trình đàm phán các tham số vận chuyển đã hoàn tất, khách hàng sẽ đưa ra lệnh PLAY để hướng dẫn máy chủ bắt đầu phân phối luồng dữ liệu RTP.

4. Khi khách hàng quyết định đóng luồng, lệnh TEARDOWN được ban hành cùng với ID phiên hướng dẫn máy chủ ngừng phân phối RTP được liên kết với ID đó.

Đọc thêm :

• Khái niệm cơ bản về giao thức truyền phát
• Hiểu các giao thức lớp ứng dụng - Giao thức truyền phát thời gian thực (RTSP)
• Giới thiệu về Video HTML5 (Opera)
• Âm thanh và video HTML5: Những gì bạn phải biết
• Phân tích RTSP Wireshark

Đây là một câu trả lời nhanh chóng và bẩn thỉu-

Có một sự khác biệt giữa phát lại video trên web và thực sự phát trực tuyến video trong thời gian thực.

Phát lại được thực hiện bằng phương tiện của trình phát được bao gồm trong trang web (có thể đang sử dụng flash, JS hoặc đối tượng video html5). Máy khách (trình duyệt) tải xuống trình phát này và chạy nó. Đến lượt người chơi, tải video từ một url tải xuống đơn giản. Trên thực tế, ngay cả với Youtube, có những chương trình cho phép bạn truy cập trực tiếp các tệp video được lưu trữ và tải xuống chúng giống như bất kỳ tệp nào. Vì hệ thống sử dụng một liên kết tải xuống cũ thông thường, không cần các giao thức truyền phát phức tạp như RTSP

Truyền phát thời gian thực (giả sử, từ một webcam) là .. tốt, phức tạp hơn. Flash có chức năng này tích hợp, nhưng nó không nên được sử dụng nữa. Video HTML5 không hỗ trợ phát trực tuyến thời gian thực, nhưng mọi người đã có thể "đánh lừa" nó bằng cách làm cho máy chủ lưu trữ tệp liên tục thay đổi tệp video mà nó cung cấp.