Streaming Media Dari Di Dalam Halaman HTML, dengan Contoh


12

Jadi saya seorang insinyur perangkat lunak yang mencoba memahami beberapa detail penting tentang bagaimana media streaming bekerja. Saya telah menghabiskan sebagian besar hari mencoba memahami berbagai codec, format wadah dan protokol streaming yang berkaitan dengan aplikasi saya. Sejauh ini, inilah pemahaman saya tentang cara kerjanya, yang bisa saja disesatkan:

  • Media streaming benar-benar bermuara pada format wadah dan protokol streaming :
    • Semua data audio dikodekan (melalui audio codec) ke dalam bitstream audio
    • Semua data video dikodekan (sekali lagi, melalui codec) ke dalam bitstream video
    • Dua aliran digabung ( multiplexing? ) Bersama-sama ke dalam wadah yang akhirnya menjadi file (seperti MP4, dll.)
    • Server media khusus kemudian menyajikan wadah ini (file MP4, atau format lain) kepada klien (mungkin pemutar Video HTML5 yang berjalan di dalam browser seseorang) melalui beberapa protokol streaming standar, seperti RTSP
      • Dalam kasus klien browser, saya menganggap browser itu sendiri memiliki klien RTSP yang kemudian entah bagaimana menyajikan kepada pengguna HTML5 Video Player
  • Saya dapat meng-host file MP4 dari server web , seperti nginx atau httpd, tetapi karena server itu bukan server RTSP, hanya akan dapat memperlakukan permintaan untuk MP4 sebagai permintaan unduhan , dan dengan demikian, tidak dapat melakukan streaming file media
    • Demikian juga, jika saya digunakan curluntuk mengambil file dari server nginx, karena tidak curljuga nginx berbicara RTSP, itu akan diperlakukan sebagai unduhan file
  • Tetapi, ketika saya meng-host file MP4 dari server media streaming (VideoLAN, Red5, Wowza, dll.), Dan saya menggunakan klien RTSP (atau klien media streaming yang didukung) untuk meminta streaming dari server itu, yang kemudian dan hanya lalu apakah streaming aktual terjadi
    • Oleh karena itu meskipun "video" YouTube atau Vimeo di-host pada halaman HTML yang dilayani melalui HTTP (S) oleh server HTTP, saya berasumsi bahwa pemutar video tertanam pada halaman tersebut (yang merupakan tempat video sebenarnya diputar) sebenarnya memulai detik , koneksi selanjutnya ke server streaming, dan streaming terjadi melalui RTSP atau protokol non-HTTP lainnya

Jadi itu pemahaman saya, dan saya kira saya pertama kali bertanya bahwa jika sesuatu yang saya katakan di atas salah, silakan mulai dengan mengoreksi saya! Dengan asumsi saya kurang lebih benar:

Bagaimana cara streaming pemutar media, berjalan di dalam halaman HTML dan dilayani oleh server HTML, membangun koneksi streaming (RTSP, dll.) Dengan server media streaming (melayani permintaan RTSP)?


4
Mengapa downvote? Ini bukan penipuan, ada pada topik, pasti menunjukkan penelitian dan merupakan SSCCE .
smeeb


Mengapa streaming melalui HTTP menjadi aneh? Streaming pada dasarnya hanya "bermain sambil mengunduh", membuang data setelahnya, (dengan buffering opsional) alih-alih menunggu pengunduhan selesai. Gagasan ini juga digunakan untuk jenis pemrosesan aliran lainnya dalam pemrograman.
Daniel B

Nah, setelah membaca komentar pada jawaban yang dihapus, saya pikir saya akhirnya menentukan apa yang Anda tanyakan: “Bagaimana cara mencari bekerja sama sekali dengan streaming HTTP? Anda tidak dapat menerjemahkan cap waktu ke posisi byte di dalam file! ”Mungkin Anda harus mengklarifikasi pertanyaan tentang hal itu.
Daniel B

Jawaban:


7

Bagaimana cara streaming pemutar media, berjalan di dalam halaman HTML dan dilayani oleh server HTML, membangun koneksi streaming (RTSP, dll.) Dengan server media streaming (melayani permintaan RTSP)?

Aplikasi Umum

RTSP saat ini tampaknya lebih banyak digunakan dengan aplikasi / antarmuka perangkat yang secara langsung live streaming (mis. Kamera IP) atau re-stream (seperti mesin) daripada untuk streaming file media yang disimpan dari lokasi fisik melalui antarmuka pemutaran web HTTP dengan antarmuka pemutar tertanam.

Tampaknya RTSP adalah protokol stateful dan menggunakan UDP lebih dari TCP saat streaming, dan itu digunakan lebih sebagai perangkat server (seperti kamera IP) yang terhubung ke jaringan TCP / IP, dan mengumpan aliran melalui UDP, dll Anda kemudian terhubung ke feed ini (server) sebagai klien di jaringan yang sama dan Anda dapat mengeluarkan permintaan RTSP untuk memanfaatkannya.


Arahan protokol

Meskipun serupa dalam beberapa hal dengan HTTP, RTSP mendefinisikan urutan kontrol yang berguna dalam mengendalikan pemutaran multimedia. Sementara HTTP adalah stateless , RTSP memiliki status; pengidentifikasi digunakan saat dibutuhkan untuk melacak sesi bersamaan. Seperti HTTP, RTSP menggunakan TCP untuk mempertahankan koneksi ujung ke ujung dan, sementara sebagian besar pesan kontrol RTSP dikirim oleh klien ke server, beberapa perintah berjalan ke arah lain (yaitu dari server ke klien).

Disajikan di sini adalah permintaan RTSP dasar. Beberapa permintaan HTTP biasa, seperti permintaan OPSI, juga tersedia. Nomor port lapisan transport default adalah 554 [3] untuk TCP dan UDP, yang terakhir jarang digunakan untuk permintaan kontrol.

sumber


Tanpa kewarganegaraan

Protokol tanpa kewarganegaraan tidak mengharuskan server untuk menyimpan informasi sesi atau status tentang setiap mitra komunikasi selama beberapa permintaan. Sebaliknya, sebuah protokol yang membutuhkan menjaga keadaan internal di server dikenal sebagai protokol stateful .

Kelemahan dari kewarganegaraan adalah bahwa hal itu mungkin perlu untuk memasukkan informasi tambahan dalam setiap permintaan, dan informasi tambahan ini perlu ditafsirkan oleh server.

sumber


Aliran logis

Cara saya memahami aliran media streaming dalam bentuk ini adalah:

  • server tempat konten media berada akan merangkum, mengompres, menyandikan, dll. konten data video / audio dalam format dan segmen yang tepat untuk pengiriman streaming
  • server web yang mendengarkan koneksi untuk mengakses media streaming akan memberikan semua sumber daya yang diperlukan untuk streaming media
  • klien meminta dan mengunduh sumber daya dan file yang berlaku, dan kemudian merakitnya secara terus menerus untuk diputar melalui penunjuk URL sebagai yang dikonfigurasikan dan parameter lainnya. Perangkat lunak pemutaran pada tingkat klien mengumpulkan paket-paket yang dikirimkan secara berurutan untuk memungkinkan pemutaran konten yang tepat.

Silakan lihat bagian Streaming Technologies di bawah ini untuk perbandingan umum HTTP versus RTSP.


Selanjutnya

Di bawah 10 Alasan Mengapa Anda Seharusnya Tidak Pernah Meng-host Video Anda Sendiri Saya telah mengutip bagian-bagian yang sampai pada titik untuk membantu menjawab pertanyaan Anda dalam "umum" tanpa terlalu spesifik.

Pada dasarnya dikatakan bahwa situs web yang memiliki kontrol pemutar media tertanam akan:

  • (1) mendeteksi pengaturan browser web klien pada "koneksi dan permintaan" dari klien dan
  • (2) ini akan mengatur codec dan pengaturan deteksi sisi klien lainnya ke nilai parameter yang berlaku, lalu
  • (3) itu akan mengalirkan video langsung dari server streaming Anda menjadi tuan rumah file video dan audio berdasarkan kode lebih lanjut dalam konfigurasi pemutar media tertanam Anda yang menunjuk ke URL file media pada server yang dihosting.

Teknologi Streaming

Browser klien harus menerima data dari server dan meneruskannya ke aplikasi streaming untuk diproses. Aplikasi streaming mengubah data menjadi gambar dan suara. Faktor penting dalam keberhasilan proses ini adalah kemampuan klien untuk menerima data lebih cepat sehingga aplikasi dapat menampilkan informasi. Kelebihan data disimpan dalam buffer - area memori yang disediakan untuk penyimpanan data dalam aplikasi. Jika data tertunda dalam transfer antara kedua sistem, buffer mengosongkan dan penyajian materi tidak akan mulus.

Protokol HTTP

HTTP adalah cara utama di mana dokumen ditautkan di Internet. Klien membuat koneksi ke server yang berisi file yang akan di-stream, file diambil dan koneksi ditutup. Server HTTP berkomunikasi dengan browser jenis file yang akan ditransfer.

Manfaat Menggunakan HTTP

Saat streaming file menggunakan HTTP, server streaming khusus tidak diperlukan. Selama browser Anda memahami tipe MIME, ia dapat menerima file streaming dari server HTTP. Salah satu keuntungan berbeda dari streaming file menggunakan HTTP adalah bahwa ia dapat melewati firewall dan memanfaatkan server proxy.

Beberapa Kerugian

Streaming HTTP menggunakan TCP / IP (Transmission Control Protocol dan Internet Protocol) untuk memastikan pengiriman file yang andal. Proses ini memeriksa paket-paket yang hilang dan memintanya untuk dikirim kembali. Ini menjadi masalah dalam skenario streaming ketika Anda ingin data diabaikan jika hilang dalam pengiriman, sehingga file dinamis terus diputar. HTTP tidak dapat mendeteksi kecepatan modem sehingga administrator server harus dengan sengaja menghasilkan file dengan laju kompresi berbeda untuk pengguna server dengan berbagai jenis koneksi. Streaming file dari server HTTP tidak disarankan untuk situasi dengan permintaan tinggi.

Protokol RTSP

RTSP adalah protokol standar yang digunakan oleh sebagian besar vendor server streaming. Server RTSP menggunakan UDP (User Datagram Protocol) untuk mentransfer file media. UDP tidak terus-menerus memeriksa apakah file telah tiba di tujuannya. Ini merupakan keuntungan untuk streaming aplikasi karena transfer file dapat terganggu selama penundaan tidak terlalu lama. Hasil dari metode ini adalah bahwa ada kehilangan data di kali, tetapi file terus diputar jika penundaannya kecil.

sumber


10 Alasan Mengapa Anda Tidak Harus Meng-host Video Anda Sendiri

Kami Membicarakan Embedding vs. Video yang Di-Host-kan

Pertama, Anda mengunggah file video Anda ke layanan hosting video pihak ketiga seperti YouTube, Vimeo, atau Wistia.

Kemudian, Anda menyalin sedikit kode yang mereka berikan kepada Anda, dan menempelkannya ke posting atau halaman Anda di situs WordPress Anda sendiri. Video akan muncul di situs Anda, di lokasi di mana Anda menempelkan kode embed, tetapi video itu sendiri sedang dialirkan dari server host video, sebagai lawan dari server web Anda sendiri, di mana situs WordPress Anda di-host.

4. Tidak Ada Standar Format File Tunggal untuk Video Web

Spesifikasi konsep HTML5 saat ini tidak menentukan format video browser mana yang harus didukung. Akibatnya, browser web utama telah menyimpang, masing-masing mendukung format yang berbeda. Internet Explorer dan Safari akan memutar video H.264 (MP4), tetapi tidak WebM atau Ogg. Firefox akan memutar video Ogg atau WebM, tetapi tidak H.264. Untungnya, Chrome akan memutar semua format video utama, tetapi jika Anda ingin memastikan video Anda akan diputar ulang di semua browser web utama, Anda harus mengubah video Anda menjadi beberapa format: .mp4, .ogv, dan .webm

5. Semoga Anda suka mengonversi video. Banyak.

Sebagian besar audiens Anda kemungkinan akan menonton video Anda dari desktop atau laptop mereka dengan manfaat koneksi internet berkecepatan tinggi. Bagi orang-orang itu, Anda ingin mengirimkan file besar, kualitas HD sehingga mereka dapat menontonnya di layar penuh jika mereka mau. Secara umum, ini berarti file 1080p atau 720p pada bitrate streaming tinggi (5000 - 8000 kbps).

Tetapi Anda juga ingin menyandikan versi yang lebih kecil, resolusi lebih rendah untuk pengiriman ke perangkat seluler seperti ponsel dan tablet, serta pengiriman ke pemirsa dengan koneksi internet yang lebih lambat.

6. Pemutar Video

Pemutar video adalah sepotong kecil perangkat lunak web yang Anda pasang di situs Anda yang secara otomatis akan mendeteksi perangkat mana yang meminta video Anda, beserta kecepatan koneksinya, dan kemudian memberikan versi yang sesuai kepada orang tersebut.

7. Kode Praktis [atau Shortcode]

Baik Anda menggunakan plugin pihak ketiga atau kemampuan video bawaan WordPress, Anda harus membuat sedikit kode untuk memberi tahu pemutar video format apa yang telah Anda buat, serta lokasinya di server. Itu terlihat seperti ini ...

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

Jadi apa solusi terbaik untuk menambahkan video ke situs Anda?

Cukup gunakan layanan hosting video pihak ketiga, lalu masukkan video Anda ke dalam posting atau halaman WordPress Anda.

Langkah Satu: Unggah video Anda ke salah satu layanan hosting video populer dan mapan seperti Vimeo PRO.

Langkah Dua: Setelah video Anda diunggah dan siap untuk dilihat, salin URL ke video Anda. Kembali ke situs WordPress Anda dan rekatkan URL ke posting atau halaman tempat Anda ingin video itu muncul.


Ketika orang melihat halaman Anda, video akan muncul di lokasi tempat Anda menempelkan URL. Tetapi file video itu sendiri akan dialirkan dari server host video, sebagai lawan dari server Anda sendiri, di mana situs WordPress Anda di-host.

Pemutar video tertanam akan secara otomatis mendeteksi perangkat pengguna, browser, dan kecepatan koneksi Internet, dan kemudian melayani versi file video yang sesuai untuk mereka. Tidak ada yang dipasang di situs Anda. Tidak ada plugin untuk tetap up to date. Tidak ada kode yang rumit.

sumber


Terima kasih @PIMP_JUICE_IT (+1) - beberapa pertanyaan lanjutan jika Anda tidak keberatan, yang berasal dari sedikit kebingungan atas penggunaan frasa " pemutar video tertanam ": Ketika Anda mengatakan "Pada dasarnya ia mengatakan bahwa situs web yang telah disematkan pemutar video dan audio akan ... ", apa yang Anda maksudkan dengan pemutar yang disematkan ? Bagi saya, audio / video dapat dilayani dari server web (menggunakan MPEG-DASH atau yang serupa) atau server streaming yang berbicara sesuatu seperti RTSP. Dan lagi, bagi saya, seorang pemain adalah konstruksi sisi klien yang memutar / menyajikan audio / video kepada manusia.
smeeb

Jadi ketika Anda berbicara tentang sebuah situs web (server) yang memiliki pemain , ini agak membingungkan. Bisakah Anda mengklarifikasi?
smeeb

4

Saya akan membahas di bawah ini terutama pertanyaan Anda tentang apa yang terjadi ketika video ditampilkan di browser. Subjeknya sangat luas, jadi saya hanya akan menyentuh pada item yang relevan.

HTML5 telah memperkenalkan <VIDEO>tag yang memecahkan masalah mengintegrasikan video yang ditampilkan ke dalam browser saat menggunakan JavaScript dan CSS. <OBJECT>Tag sebelumnya memerlukan perangkat lunak eksternal dan tidak terintegrasi dengan halaman. Tag baru yang berlaku mengharuskan browser juga menjadi pemutar video, meskipun tidak ada standar yang diberlakukan. Hasilnya adalah fragmentasi total standar, di mana satu-satunya solusi adalah bahwa server video akan menyediakan beberapa format video dan bahwa semua sumber alternatif ini ditentukan dalam <VIDEO>tag, dari mana browser akan memilih yang didukungnya.

Contoh tag dengan banyak sumber:

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

The <VIDEO>tag sendiri adalah protokol-agnostik, sehingga dapat menggunakan protokol yang didukung oleh browser termasuk RTSP. Dukungan untuk protokol MPEG-DASH (Dynamic Adaptive Streaming over HTTP) akhir-akhir ini menjadi sangat komprehensif, sehingga akan diputar di sebagian besar perangkat dan browser asli, atau menggunakan HTML5, yang berarti tidak diperlukan plugin tambahan. Lihat bagan Kompatibilitas Perangkat dan Browser ini . Lihat juga artikel Mozilla ini untuk mempersiapkan server Anda untuk melayani MPEG-DASH. DASH bekerja melalui HTTP, jadi ini akan berfungsi selama server HTTP Anda mendukung permintaan rentang byte dan itu diatur untuk melayani file .mpd dengan mimetype="application/dash+xml".

Interaksi normal antara klien dan server terlihat mirip dengan yang berikut ini. Untuk HTML5 VIDEO, browser juga merupakan pemain, meskipun mungkin membuka koneksi baru untuk bermain.

gambar

Koneksi awal memasok metadata yang digunakan klien untuk menampilkan video. Jika protokol RTSP digunakan untuk mendapatkan metadata itu, maka koneksi RTP kemudian dibuat untuk mentransfer data video + audio. Protokol RTCP digunakan untuk mentransfer perintah tambahan ke server.

RTP, RTCP, dan RTSP semuanya beroperasi pada port yang berbeda. Biasanya ketika RTP ada di port N, RTCP ada di port N +1. Sesi RTP dapat berisi beberapa aliran untuk digabungkan di ujung penerima; misalnya, audio dan video mungkin berada di saluran yang terpisah.

Agar tidak ada yang terkunci dari konten Anda, Anda harus menyediakan codec bebas-royalti, webM atau Theora, dan video H.264, serta audio Vorbis dan MP3. (Kata mudah, sulit dilakukan.)

Inilah yang terjadi secara rinci untuk RTSP:

  1. Klien membuat koneksi TCP ke server, biasanya pada port TCP 554, port yang terkenal untuk RTSP.

  2. Klien kemudian akan mulai mengeluarkan serangkaian perintah header RTSP yang memiliki format yang mirip dengan HTTP, yang masing-masing diakui oleh server. Dalam perintah RTSP ini, klien akan menjelaskan ke server detail dari persyaratan sesi, seperti versi RTSP yang didukungnya, transportasi yang akan digunakan untuk aliran data, dan informasi port UDP atau TCP yang terkait. Informasi ini diteruskan menggunakan header DESCRIBE dan SETUP dan ditambah pada respons server dengan ID Sesi yang dapat digunakan klien, dan perangkat proxy sementara, untuk mengidentifikasi aliran dalam pertukaran lebih lanjut.

  3. Setelah negosiasi parameter transportasi selesai, klien akan mengeluarkan perintah MAIN untuk menginstruksikan server untuk memulai pengiriman aliran data RTP.

  4. Setelah klien memutuskan untuk menutup aliran, perintah TEARDOWN dikeluarkan bersama dengan Session ID yang memerintahkan server untuk menghentikan pengiriman RTP yang terkait dengan ID itu.

Bacaan lebih lanjut :


1

Inilah jawaban cepat dan kotor-

Ada perbedaan antara memutar video di web dan benar-benar streaming dalam waktu nyata.

Pemutaran dilakukan dengan cara pemain yang termasuk dalam halaman web (mungkin menggunakan flash, JS, atau objek video html5). Klien (browser) mengunduh pemain ini dan menjalankannya. Pemain, pada gilirannya, mengambil video dari url unduhan sederhana. Bahkan, bahkan dengan Youtube, ada program yang memungkinkan Anda untuk mengakses file video yang dihosting secara langsung dan mengunduhnya seperti halnya file apa pun. Karena sistem menggunakan tautan unduhan lama yang biasa, tidak perlu protokol streaming yang rumit seperti RTSP

Streaming waktu nyata (katakanlah, dari webcam) adalah .. well, trickier. Flash memiliki fungsi ini bawaan, tetapi seharusnya tidak digunakan lagi. Video HTML5 tidak mendukung streaming realtime, tetapi orang-orang telah dapat "mengelabui" nya dengan membuat server hosting file secara konstan mengubah file video yang ditawarkannya.

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.