Strim HLS peribadi anda dimuatkan untuk anda, bukan untuk penonton anda

Anda menguji halaman pada komputer riba, pemain bermula, dan tiket ditutup. Penonton di hujung sana membuka halaman yang sama dan mendapat pemutar berputar yang tidak pernah selesai. Penjelasan biasa ialah VPN berada pada pelayan, jadi main balik sepatutnya berfungsi — tetapi pelayarlah komponen yang meminta senarai main, dan ia mempunyai laluan rangkaiannya sendiri. Halaman yang tertanam pada pelayan dengan akses peribadi tidak meminjamkan akses itu kepada sesiapa yang memuatkannya.

Ini tentang halaman ASP.NET sedia ada yang memainkan sumber HLS seperti http://10.5.5.9:8080/live/stream.m3u8, yang merupakan alamat peribadi ilustratif. Dua susunan berfungsi; salah satunya mungkin bukan yang anda bina.

Mitos: halaman yang dimuatkan membuktikan laluan media

HTML halaman itu datang dari pelayan web anda, melalui laluan apa pun yang dimiliki pelayan web anda. Senarai main dan segmen datang dari asal media, melalui laluan apa pun yang dimiliki komponen yang membuat permintaan. Apabila pemain berjalan dalam pelayar penonton, itu dua klien berbeza, dua alamat sumber berbeza dan selalunya dua domain kegagalan berbeza. Melihat yang pertama berjaya tidak memberitahu apa-apa tentang yang kedua.

Apa yang sebenarnya dibuktikan oleh ujian anda lebih sempit daripada kelihatannya: mesin anda dapat mencapai halaman awam dan hos media peribadi pada masa yang sama. Mesin penonton tidak pernah menjadi sebahagian daripada eksperimen itu.

Apa yang diminta oleh senarai main seterusnya

RFC 8216 memisahkan senarai main media, yang menyenaraikan segmen, daripada senarai main induk, yang menyenaraikan senarai main lain, dan menyelesaikan URI relatif terhadap URI senarai main yang mengandunginya. Peraturan itulah bahagian yang orang terlepas pandang. Mengambil satu fail .m3u8 dengan berjaya bukan ujian main balik, kerana fail yang anda ambil ialah indeks, bukan media.

Ikut rantaian seperti yang dilakukan pemain: buka senarai main yang dipilih, kemudian minta sumber yang dinamakannya, kemudian ikut apa-apa ubah hala. Senarai main yang disajikan melalui pelayan web yang boleh dicapai masih boleh menghantar penonton ke alamat peribadi yang tidak boleh dicapai. Begitu juga, memindahkan senarai main relatif ke URL lain menukar asas yang menjadi rujukan entri-entrinya, dan itulah sebabnya menulis semula URL pertama yang kelihatan dan berhenti di situ biasanya menghasilkan senarai main yang kelihatan sah tetapi tidak boleh dimainkan.

Tontonan langsung: penonton memerlukan laluan

Jika penonton sepatutnya mencapai hos media secara langsung, peranti mereka memerlukan VPN yang diluluskan atau laluan peribadi lain, DNS yang menyelesaikan nama yang anda benar-benar gunakan, kebenaran untuk mencapai destinasi itu, dan pengesahan apa pun yang diperlukan oleh perkhidmatan media. Semak setiap satu pada peranti penonton dan bukan pada pelayan. Pelayar pada telefon dengan profil VPN dipasang tetapi tidak disambungkan ialah kegagalan yang biasa dan boleh dihasilkan semula sepenuhnya.

Susunan ini mengekalkan sumber sebagai peribadi dan menolak keperluan akses kepada audiens. Ia keputusan dasar sama seperti keputusan teknikal, jadi sahkan bahawa setiap penonton yang dimaksudkan dibenarkan memegang laluan itu sebelum anda mereka bentuk mengikutnya.

Penghantaran dari sisi pelayan: satu titik masuk terkawal

Alternatifnya ialah bahagian hadapan media yang dibenarkan yang mengambil sumber melalui laluan peribadinya dan menerbitkan semula hanya sumber yang menghadap penonton. Kekalkan senarai main, segmen dan apa-apa sumber kunci selaras dengan titik masuk tunggal itu, jika tidak pemain akan mengambil senarai main yang ditulis semula melalui bahagian hadapan dan segmen terus dari alamat yang tidak dapat dicapai oleh penonton.

Hadkan sumber dan laluan yang dibenarkan dalam bahagian hadapan itu. URL sewenang-wenang yang diberikan pengguna menjadikan proksi yang berguna sebagai pengambil tanpa had bagi rangkaian dalaman anda, yang merupakan masalah jauh lebih teruk daripada strim yang tidak akan dimainkan. Masukkan sumber dan awalan laluan ke dalam senarai dibenarkan dan bukannya mengesahkan rentetan itu selepas kejadian.

Untuk sumber HLS sedia ada, semak dahulu sama ada pemajuan terkawal sudah memadai; VPN di tengah tidak bermakna transkod diperlukan. Kemudian sahkan gabungan pelayar dan kodek sebenar, kerana respons yang boleh dicapai dan format yang disokong ialah dua syarat berasingan. Kekalkan TLS, pengesahan dan keperluan keselamatan pelayar asal tanpa diubah — pemain tertanam bukan pengecualian daripadanya.

Uji rantaian, bukan URL

Jalankan pemeriksaan dari komponen yang benar-benar akan membuat setiap permintaan, dan anggap setiap langkah sebagai hasilnya sendiri:

curl -s http://10.5.5.9:8080/live/stream.m3u8
curl -s -o /dev/null -w '%{http_code}\n' http://10.5.5.9:8080/live/segment-000123.ts

Kemudian ulangi dalam pelayar penonton sendiri dengan strim yang dimaksudkan, bukan dengan corak ujian dari meja anda. Pemuatan halaman, pemuatan senarai main, pengambilan segmen dan kegagalan kebenaran ialah empat hasil berbeza, dan anda mahu keempat-empatnya diperhatikan sebelum mengisytiharkannya selesai. Jangan pasang pemalam pelayar lama kerana contoh lama memainkan satu strim dengan cara itu; bahagian yang hilang biasanya ialah laluan penonton atau URL segmen yang tidak ditandatangani.

Setelah susunan itu disengajakan, tuliskannya dalam satu baris: siapa yang mengambil media, melalui laluan apa, dan apa yang dibenarkan untuk diminta oleh penonton. Ayat itu menyelesaikan kebanyakan perdebatan masa depan tentang untuk siapa strim itu sebenarnya.