View a markdown version of this page

Pemecahan masalah IVS Streaming Low-Latency - Amazon IVS
Penyiaran dan PengkodeanPemantauan dan AcaraPemutaran StreamingAuto-Record ke Amazon S3Topik Lain-lain

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pemecahan masalah IVS Streaming Low-Latency

Dokumen ini menjelaskan praktik terbaik dan kiat pemecahan masalah untuk Amazon Interactive Video Service (IVS). Perilaku yang tidak terduga atau tidak diinginkan dapat terjadi saat menggunakan IVS. Perilaku ini dapat terjadi di berbagai titik dalam proses streaming, dari penyiaran hingga pemutaran konten:

Perilaku yang tidak terduga atau tidak diinginkan dapat terjadi di berbagai titik dalam proses streaming, mulai dari penyiaran hingga pemutaran konten.

Untuk informasi tentang dukungan dan sumber daya Amazon IVS lainnya, lihat Sumber Daya dan Dukungan.

Penyiaran dan Pengkodean

Pertanyaan di bagian ini adalah tentang penyiaran, pengkodean, dan kondisi streaming mil pertama ke IVS. Perilaku ini terjadi sebelum konten mencapai server IVS.

Topik:

Apa itu kelaparan aliran?

“Kelaparan aliran” adalah penundaan atau penghentian pengiriman paket konten saat Anda mengirim konten ke IVS; yaitu, ketika konten dicerna oleh IVS. Jika IVS tidak mendapatkan jumlah bit yang diharapkan saat menelan yang diiklankan oleh perangkat pengkodean yang akan dikirim dalam jangka waktu tertentu, ini dianggap sebagai peristiwa kelaparan. Seringkali, peristiwa kelaparan disebabkan oleh encoder penyiar, kondisi jaringan lokal, and/or dalam transit melalui internet publik, antara perangkat pengkodean dan IVS.

Dari sudut pandang pemirsa, peristiwa kelaparan dapat muncul sebagai video yang tertinggal, menyangga, atau macet. Stream-starvations peristiwa bisa singkat (kurang dari 5 detik) atau panjang (beberapa menit), tergantung pada sifat peristiwa kelaparan.

Untuk memungkinkan pemantauan kejadian kelaparan, IVS mengirimkan peristiwa kelaparan sebagai EventBridge peristiwa Amazon; lihat Contoh: Aliran Perubahan Kesehatan dalam Menggunakan Amazon EventBridge dengan Amazon IV S. Ini dikirim ketika aliran masuk atau keluar dari keadaan kelaparan. Tergantung pada kasus penggunaan, Anda dapat mengambil tindakan yang sesuai, seperti memberi tahu penyiar dan pemirsa tentang kondisi aliran intermiten.

Untuk alat pemantauan kelaparan tambahan, lihat Memantau Amazon IVS Low-Latency Streaming, operasi ListStreams API IVS (pemfilteran berdasarkan kesehatan), dan GetStream operasi IVS (untuk menganalisis aliran individu). Lihat juga Bagaimana cara memantau peristiwa kelaparan aliran?

Mengapa aliran tiba-tiba berhenti?

Berikut ini adalah alasan paling umum mengapa aliran dapat berhenti tiba-tiba (yaitu, sesi streaming berakhir):

  • Data ingest hilang — Ketika proses penyerapan sesi streaming benar-benar berhenti (tidak ada data yang terserap ke IVS) selama 30 detik, server penyerapan IVS mengakhiri sesi aliran IVS. Periode 30 detik memungkinkan penyiar untuk terhubung kembali ke server ingest. Namun, dalam beberapa kasus (seperti pengalihan jaringan), koneksi ulang ke sesi aliran yang ada mungkin tidak mungkin dilakukan, karena jabat tangan TLS dari RTMPS telah rusak. Akar penyebab umum untuk ini termasuk masalah jaringan (seperti kemacetan antara perangkat siaran dan IVS), hilangnya internet sepenuhnya pada perangkat siaran, atau perangkat siaran tidak menghasilkan segmen konten (tag FLV).

    Seringkali, pemutusan aliran sejajar dengan peristiwa kelaparan aliran; peristiwa kelaparan dipicu ketika ada penghentian dalam data yang masuk. Jika peristiwa starvation-start dikirim dan kemudian peristiwa stream-end dikirim (tanpa peristiwa starvation-end), ini sering menunjukkan bahwa aliran telah berakhir karena tidak ada data yang dikirim ke IVS.

  • StopStream Operasi IVS — Selama sesi aliran IVS, jika panggilan StopStream API dilakukan, sesi aliran IVS akan berakhir. StopStream Operasi memutuskan aliran RTMPS yang masuk dari server ingest IVS. Tergantung pada peng software/hardware kodean yang digunakan, sesi aliran baru dapat dicoba.

  • Kesalahan encoder - Beberapa software/hardware encoder akan memutuskan sesi streaming ketika terjadi kesalahan selama proses pengkodean. Dari perspektif IVS, pemutusan ini muncul sebagai pemutusan yang disengaja oleh penyiar. Namun, dalam log pengkodean, dapat ditentukan bahwa aliran terputus karena kesalahan yang tidak disengaja.

Apa yang terjadi ketika saya beralih jaringan saat streaming?

Ketika penyiar beralih jaringan (misalnya, dari WiFi ke seluler), koneksi RTMPS yang sedang berlangsung terputus. Sementara koneksi internet penyiar mungkin dibuat kembali setelah 3-4 detik, koneksi baru memiliki alamat IP baru karena sakelar jaringan, yang menghasilkan koneksi RTMPS baru. Selama sakelar ini, koneksi RTMPS sebelumnya tidak terputus dengan bersih: encoder tidak mengirimkan pesan pemutusan IVS. Akibatnya, IVS menunggu 30 detik hingga koneksi RTMPS sebelumnya terhubung kembali, yang memblokir aliran RTMPS baru di jaringan baru agar tidak terhubung ke IVS.

Untuk mengaktifkan peralihan antar jaringan yang lebih cepat, sebaiknya gunakan fitur pengambilalihan aliran. Dalam skenario ini, ketika perangkat siaran terhubung ke jaringan baru, perangkat siaran dapat “mengambil alih” aliran yang ada dengan streaming ke atas dengan ditambahkan ke tombol aliran, di mana N adalah ?priority=N bilangan bulat positif apa pun hingga 2.147.483.647. Pengambilalihan aliran akan berhasil jika prioritas yang diberikan untuk aliran baru lebih besar daripada prioritas yang ditetapkan untuk aliran yang sedang berlangsung. (Perhatikan bahwa stream-up asli tidak memerlukan parameter prioritas untuk disetel, tetapi semua upaya pengambilalihan melakukannya.)

Bagaimana saya bisa memiliki redundansi multi-wilayah dengan IVS?

Redundansi dalam IVS dapat dicapai dengan beberapa cara; lihat Ketahanan IVS dalam Keamanan IVS.

IVS dipisahkan ke dalam bidang jaringan yang berbeda; Kontrol dan Data.

  • Bid ang kontrol bersifat regional (berdasarkan wilayah AWS) dan menyimpan informasi tentang sumber daya IVS (saluran, kunci aliran, pasangan kunci pemutaran, dan konfigurasi perekaman).

  • Bid ang data tidak terbatas pada wilayah AWS dan merupakan jaringan yang membawa data dari ingest ke egress. Bahkan jika saluran dibuat di wilayah us-west-2 (misalnya), video yang dialirkan ke saluran tersebut mungkin tidak melalui us-west-2.

Lihat juga Solusi Global, Kontrol Regional. Pertimbangkan dua skenario ini:

  • Jika hanya satu wilayah bidang kontrol (misalnya, us-east-1) yang digunakan — Jika wilayah kontrol AWS tertentu mengalami degradasi atau pemadaman, bidang kontrol IVS mungkin mengalami latensi atau kesalahan saat membuat, membaca, memperbarui, atau menghapus salah satu hal berikut: saluran, tombol aliran, pasangan kunci pemutaran, atau konfigurasi perekaman. Mencoba memulai aliran baru selama pemadaman dapat mengakibatkan lebih banyak latensi atau kesalahan saat memulai sesi streaming. Tergantung pada tingkat keparahan degradasi, dimungkinkan untuk melanjutkan penyiaran ke saluran dengan aliran yang sudah berlangsung.

    Jika otorisasi pemutaran diaktifkan, pemirsa saat ini mungkin dapat melanjutkan pemutaran streaming yang sedang berlangsung, tetapi pemirsa baru mungkin tidak dapat mulai menonton jika ada masalah dengan otorisasi pasangan kunci pemutaran. Jika otorisasi pemutaran tidak diaktifkan, pemirsa saat ini dan baru harus dapat melihat streaming yang sedang berlangsung.

    Fitur IVS Auto-Record ke S3 juga dapat terganggu jika terjadi pemadaman.

    Pesawat kontrol IVS tidak secara otomatis gagal dialihkan ke wilayah AWS lain jika terjadi pemadaman regional.

  • Jika dua wilayah bidang kontrol (misalnya, us-east-1 dan us-west-2) sedang digunakan, dan wilayah kedua adalah failover jika wilayah utama tidak tersedia - IVS tidak secara asli mendukung failover bidang kontrol regional; dengan demikian, jika wilayah bidang kontrol mengalami masalah, aliran baru yang dimulai atau panggilan ke bidang kontrol mungkin mengalami masalah. Namun, bidang data mungkin tidak akan terpengaruh, sehingga aliran yang sedang berlangsung untuk wilayah pesawat kontrol akan berlanjut tanpa masalah. Memindahkan bidang kontrol ke wilayah sekunder (failover) perlu dilakukan di sisi aplikasi. Anda dapat menulis logika implementasi khusus untuk menangani failover bidang kontrol. Kami tidak memiliki panduan resmi tentang cara mengelola failover saluran regional.

    Dengan memisahkan bidang data video dan bidang kontrol regional, arsitektur IVS menambah ketahanan: streaming langsung yang sedang berlangsung seharusnya memiliki sedikit atau tidak ada gangguan jika terjadi kegagalan bidang kontrol regional. IVS mempertahankan SLA 99,9% uptime dan berkomitmen untuk memastikan stabilitas infrastrukturnya bagi pelanggannya (lihat SLA kami).

Bagaimana cara memecahkan masalah sesi IVS Web Broadcast SDK?

IVS Web Broadcast SDK bekerja sedikit berbeda dari sesi konsumsi IVS RTMPS normal. Web Broadcast SDK memanfaatkan protokol WebRTC untuk melakukan streaming ke titik akhir IVS. Setelah konten memasuki titik akhir IVS, itu diproses dan masuk remuxed/transcoded ke output HLS untuk dilihat.

Karena sifat SDK Siaran Web, perhatikan tips berikut untuk memecahkan masalah perilaku pengkodean:

  • Tutup tabs/programs semua perangkat penyiaran yang tidak perlu dibuka selama sesi penyiaran. Orang asing tabs/programs dapat menggunakan sumber daya komputasi (seperti CPU, RAM, dan jaringan), yang dapat menyebabkan kinerja yang buruk untuk aplikasi penyiaran. Untuk tabs/programs itu tidak dapat ditutup, pastikan mereka tidak menggunakan sumber daya komputasi dalam jumlah yang tidak perlu.

  • Pastikan kecepatan unggah perangkat melebihi 200 Kbps. Untuk mengevaluasi kecepatan unggah, buka Task Manager perangkat penyiaran untuk menganalisis jaringan yang tersedia saat streaming. Jika unggahan speed/bitrate lebih rendah dari yang diharapkan atau diinginkan, evaluasi tabs/processes yang lain yang mungkin menghabiskan bandwidth. Juga, lihat mesin lain di jaringan lokal yang mungkin mengonsumsi bandwidth dalam jumlah tinggi.

  • Jika ada lonjakan acak dalam penggunaan CPU, lihat Task Manager mesin untuk memahami proses apa yang mungkin menghabiskan CPU. Layanan umum yang secara acak menyebabkan penggunaan CPU adalah perangkat lunak anti-virus yang menjalankan pemindaian berkala pada mesin.

  • Cobalah melakukan streaming melalui https://stream.ivs.rocks/ untuk membantu mengisolasi lingkungan dan memastikan bahwa logika aplikasi tidak menyebabkan perilaku yang tidak diinginkan. Situs ini dioperasikan oleh IVS dan merupakan lingkungan pengujian yang solid untuk mengevaluasi apakah ada bagian dari integrasi dengan Web Broadcast SDK adalah akar penyebab perilaku yang tidak diinginkan.

  • Coba gunakan Google Chrome WebRTC-internals (lihat di bawah).

Bagaimana cara menggunakan WebRTC-internals metrik Google Chrome untuk mengevaluasi sesi IVS Web Broadcast SDK?

Saat streaming melalui IVS Web Broadcast SDK, berbagai perilaku dapat terjadi selama pengkodean dan pengiriman siaran. Ikuti langkah-langkah berikut untuk memecahkan masalah atau mengumpulkan informasi tentang sesi di perangkat penyiaran:

  1. Di Google Chrome, buka halaman web penyiaran.

  2. Buka tab Chrome baru dan buka chrome://webrtc-internals/ (salin ini dengan tepat).

  3. Di tab halaman web siaran asli, mulai sesi SDK Penyiaran Web dan biarkan sesi berjalan sampai perilaku diamati.

  4. Setelah perilaku diamati, beralih ke tab chrome: //webrtc-internals/ (jangan akhiri sesi siaran), dan pastikan halaman web yang benar ditampilkan:

    Tab Chrome webrtc-internals, menunjukkan bahwa halaman yang benar ditampilkan.

  5. Buka bagian Create Dump expandable di bagian paling atas layar.

  6. Pilih Unduh PeerConnection pembaruan dan data statistik di bagian atas layar (tepat di bawah Buat Dump), untuk mengunduh .txt file dari sesi yang relevan.

  7. Setelah diunduh, file akan menampilkan tampilan historis koneksi WebRTC. Anda dapat melihat ini di berbagai alat atau mengirimkannya ke tim Dukungan AWS untuk analisis lebih lanjut.

Pemantauan dan Acara

Pertanyaan di bagian ini adalah tentang pemantauan, metrik, dan peristiwa IVS.

Topik:

Bagaimana cara memantau peristiwa kelaparan aliran?

Kami merekomendasikan metode pemantauan berikut untuk peristiwa kelaparan aliran:

  • Amazon EventBridge dengan Amazon IVS — Ketika acara kelaparan aliran dimulai atau berakhir, IVS menghasilkan acara perubahan kesehatan EventBridge aliran. Menggunakan EventBridge target dan aturan Amazon, Anda dapat menggunakan peristiwa kelaparan aliran ini untuk mendapatkan peringatan saat kelaparan aliran terjadi. Untuk detail tentang target dan aturan, lihat Panduan EventBridge Pengguna Amazon.

  • Memantau Amazon IVS Low-Latency Streaming — Selama sesi streaming langsung, data direkam dan kemudian tersedia melalui analitik kesehatan aliran IVS. Ini termasuk informasi tentang konfigurasi encoder, metrik ingest, dan peristiwa sesi streaming. Ini bermanfaat saat memantau aliran yang sedang berlangsung atau mengevaluasi aliran secara retroaktif. Anda dapat menggunakan konsol IVS atau API untuk mengidentifikasi aliran yang mengalami kelaparan. Stream-session data tersedia selama 60 hari, bahkan setelah saluran dihapus, sehingga ini dapat berguna untuk mengidentifikasi aliran sebelumnya dengan peristiwa kelaparan.

  • Memfilter Aliran berdasarkan Kesehatan — Dengan konsol IVS atau operasi ListStreams API IVS, Anda dapat menggunakan health filter untuk menemukan sesi streaming yang berada dalam status. STARVING Selain itu, CloudWatch metrik IVS untuk ConcurrentStreams menyertakan Health dimensi yang dapat Anda gunakan untuk mengumpulkan jumlah total aliran yang berada dalam keadaan kelaparan aliran. Lihat Mem antau Low-Latency Streaming Amazon IVS.

  • Anda dapat menggunakan GetStream operasi IVS untuk menganalisis aliran individu.

Lihat juga Apa itu kelaparan aliran?

Bagaimana cara menggunakan Amazon CloudWatch untuk memantau kuota layanan IVS?

Anda dapat menggunakan Amazon CloudWatch untuk kuota layanan monitor/manage IVS secara proaktif. Lihat Kuota Layanan IVS. Dokumentasi ini mencakup informasi tentang membuat CloudWatch alarm untuk metrik penggunaan.

Kami menyarankan Anda mengatur topik SNS yang tepat untuk memberi tahu yang benar individuals/groups saat alarm dipicu. Jika alarm dipicu dan kuota dapat disesuaikan, Anda harus meminta kenaikan kuota layanan dengan nilai baru. Lihat Kuota Layanan IVS untuk informasi tentang meminta peningkatan.

Bagaimana cara mendiagnosis ketidakstabilan aliran menggunakan IVS Stream Health?

Sebaiknya evaluasi ketidakstabilan aliran menggunakan dasbor IVS Stream Health. Instruksi ada di Meman tau Amazon IVS Low-Latency Streaming.

Dasbor memiliki grafik deret waktu untuk bitrate video, kecepatan bingkai, dan bitrate audio; contohnya di bawah ini. Juga, Anda dapat mengklik Lihat di CloudWatch untuk melihat data di Amazon CloudWatch.

Beberapa skenario dibahas di bawah ini.

Bandwidth Internet Rendah atau Kemacetan Internet

Dalam hal ini, aliran relatif tidak stabil, bahkan ketika bitrate diturunkan. Entah tidak ada cukup bandwidth antara penyiar dan ISP atau antara ISP dan IVS, atau ada yang salah di jalur jaringan ke IVS. Untuk mengatasi masalah ini, periksa apakah tidak ada proses jaringan lain yang menggunakan bandwidth, atau hubungi ISP untuk diagnostik jaringan.

Dasbor Kesehatan Stream IVS:

Memeriksa bandwidth Internet rendah atau kemacetan Internet di dasbor IVS Stream Health.

CloudWatch:

Memeriksa bandwidth Internet rendah atau kemacetan Internet aktif CloudWatch.

Bitrate Tinggi Berlebihan

Bitrate yang lebih tinggi tidak selalu berarti kualitas yang lebih baik; di sini, bitrate tinggi menyebabkan ketidakstabilan. Dalam banyak kasus, karena kemacetan jaringan, bitrate tinggi menyebabkan ketidakstabilan aliran selama siaran. Patuhi bitrate maksimum yang tercantum diResolution/Bitrate/FPS.

Dasbor Kesehatan Stream IVS:

Memeriksa bitrate tinggi yang berlebihan di dasbor IVS Stream Health.

CloudWatch:

Memeriksa bitrate tinggi yang berlebihan aktif. CloudWatch

Masalah Jaringan atau Perangkat Keras

Pengkodean video membutuhkan banyak sumber daya komputasi, dan terkadang mesin yang melakukan pengkodean video tidak dapat mengikuti beban. Dalam hal ini, verifikasi bahwa mesin tidak kelebihan beban (menjalankan terlalu banyak hal sekaligus) dan encoder sudah mutakhir. Pertimbangkan untuk beralih ke preset pengkodean yang menggunakan lebih sedikit CPU.

Dasbor Kesehatan Stream IVS:

Memeriksa masalah jaringan atau perangkat keras di dasbor IVS Stream Health.

CloudWatch:

Memeriksa masalah jaringan atau perangkat keras CloudWatch.

Lonjakan dan Penurunan Bitrate

Terkadang encoder streaming mencoba menjadi terlalu pintar dan mengoptimalkan bitrate, seringkali tergantung pada kompleksitas bingkai yang dikompresi. Jika bitrate berfluktuasi dengan cepat, pemirsa mungkin mengalami buffering karena mencoba memuat terlalu banyak data. Pastikan bahwa Constant Bitrate (CBR) diaktifkan, karena mempertahankan bitrate yang konsisten di seluruh aliran, terlepas dari kompleksitas frame. Ketahuilah bahwa penurunan juga bisa terjadi; itu bisa menjadi tanda bahwa mesin Anda tidak memiliki daya CPU yang cukup untuk encoder untuk mengompres video.

Dasbor Kesehatan Stream IVS:

Memeriksa lonjakan dan penurunan bitrate di dasbor IVS Stream Health.

CloudWatch:

Memeriksa lonjakan dan penurunan bitrate. CloudWatch

Pemutusan Internet

Ketika perangkat siaran mengalami masalah internet, server IVS memasuki periode 30 detik di mana mereka mengevaluasi apakah koneksi yang sama dibangun kembali. Jika koneksi yang sama tidak dibangun kembali, server IVS mengakhiri sesi streaming. Beberapa encoder akan mencoba menyambung kembali ke sesi siaran jika koneksi internet terputus, dalam hal ini sesi streaming baru dapat dimulai setelah aliran awal berakhir.

Dasbor Kesehatan Stream IVS:

Memeriksa pemutusan Internet di dasbor IVS Stream Health.

CloudWatch:

Memeriksa pemutusan Internet aktif. CloudWatch

Pemutaran Streaming

Sebagian besar informasi di bagian ini khusus untuk IVS Player SDK dan mungkin tidak berlaku untuk pemain lain. Untuk informasi selengkapnya, lihat Amazon IVS Player.

Topik:

Bagaimana cara men-debug perilaku pemain IVS?

Untuk mengaktifkan logging verbose untuk membantu men-debug IVS Player, gunakan metode setLogLevel pemutar. Ubah level log pemain untuk menggunakan DEBUG argumen; maka IVS Player akan menghasilkan logging verbose di sekitar status dan logika yang terjadi pada IVS Player.

Untuk menguji dengan cepat menggunakan IVS Player, dengan atau tanpa DEBUG log diaktifkan, gunakan situs https://debug.ivsdemos.com/ pengujian. Jika DEBUG log diaktifkan melalui menu pengaturan, Anda dapat melihat log di tampilan konsol browser.

Mengapa pemutaran freeze/stop untuk semua pemirsa?

Jika pemutaran untuk semua pemirsa freezes/stops secara bersamaan di dalam konten, ini mungkin adalah hasil dari perilaku hulu. Seringkali akar penyebabnya adalah encoder siaran.

Kelaparan streaming atau perilaku encoder broadcast-encoder yang merugikan dapat berdampak pada semua pemirsa secara bersamaan. Jika penyandian penyiaran terputus dan sesi streaming baru dimulai, semua pemirsa berhenti menerima konten secara bersamaan. Saat mengevaluasi perilaku ini, kami sarankan Anda mengevaluasi sesi streaming menggunakan Monitoring Amazon IVS Low-Latency Streaming.

Apa yang menyebabkan pemain IVS menyangga?

Dalam konteks pemutaran video dan audio streaming langsung, “buffering” berarti perangkat pemutaran tidak dapat mengunduh konten sebelum konten seharusnya diputar. Buffering dapat bermanifestasi dalam beberapa cara: konten dapat berhenti dan mulai secara acak (juga dikenal sebagai gagap), konten dapat berhenti untuk jangka waktu yang lama (juga dikenal sebagai pembekuan), atau pemain dapat memasuki keadaan. BUFFERING

Ada banyak penyebab buffering, yang dapat kita atur menjadi tiga kategori utama:

  • Viewer-side buffering sering terjadi ketika satu penonton atau sekelompok kecil pemirsa terpengaruh oleh peristiwa buffering. Akar penyebab peristiwa buffering ini sering berasal dari jaringan lokal (LAN) atau masalah perangkat pemutaran. Dalam kasus jaringan lokal atau masalah perangkat yang lambat, buffering dapat diselesaikan dengan memastikan bahwa pemutaran bitrate adaptif (ABR) diaktifkan, secara manual memilih kualitas yang lebih rendah, atau mengurangi bandwidth yang digunakan oleh program dan perangkat lain.

  • Network-level buffering — Masalah dapat terjadi antara jaringan lokal dan server distribusi IVS, atau dikenal sebagai tingkat ISP. Perilaku buffering yang muncul di tingkat ISP bisa sulit untuk dipecahkan, karena visibilitas penuh ke ISP mungkin tidak mungkin. Perilaku seperti latensi dan ketegangan jaringan (misalnya, ISP tidak dapat menangani incoming/outgoing lalu lintas secara keseluruhan) dapat menyebabkan penundaan dalam menyediakan konten kepada pemirsa.

  • Broadcast-side buffering — Masalah di sisi siaran sesi streaming langsung dapat menyebabkan masalah buffering pemirsa skala besar. Misalnya, jika perangkat penyiaran berhenti mengirim data ke IVS, IVS tidak memiliki konten untuk dikirimkan ke pemutar, dan IVS Player memasuki status buffering ketika tidak ada konten yang diunduh. Dalam banyak kasus, peristiwa buffering sisi siaran menyebabkan sebagian besar, jika tidak semua, pemirsa terpengaruh secara bersamaan.

Auto-Record ke Amazon S3

Untuk informasi selengkapnya, lihat Auto-Record Amazon S3.

Topik:

Mengapa beberapa konten rekaman hilang?

Ada berbagai alasan mengapa konten yang direkam mungkin hilang. Kami merekomendasikan langkah-langkah berikut untuk memecahkan masalah konten yang hilang:

  1. Pastikan Auto-Record S3 diaktifkan untuk saluran IVS yang diinginkan:

    1. Konsol - Pada halaman detail untuk saluran yang relevan, di bagian Konfigurasi Umum, pastikan bahwa Auto-record ke S3 adaEnabled. Jika diaktifkan, periksa konfigurasi Rek aman untuk memastikan bahwa awalan Peny impanan dan Rekaman sudah benar.

    2. CLI — Jalankan get-channel dan lewati saluran IVS ARN yang diinginkan:

      aws ivs get-channel --arn "arn:aws:ivs:us-west-2:123456789012:channel/abcdABCDefgh"

      Lihat apakah a recordingConfigurationArn dikembalikan.

  2. Cari di bucket S3 yang ditunjuk untuk Isi Rekaman untuk sesi aliran tertentu (lihat A walan S3.) Awalan kunci S3 untuk sesi yang direkam ada di acara Perubahan EventBridge Status Rekaman Amazon. Catatan: Jika fitur gab ungkan aliran terfragmentasi diaktifkan, beberapa konten mungkin merupakan sesi rekaman lain.

  3. Jika durasi aliran keseluruhan kurang dari 10 detik atau konten streaming hilang (yaitu, terjadi kelaparan aliran), konten yang direkam mungkin hilang karena tidak ada yang dihasilkan.

Bisakah KMS-S3 enkripsi digunakan dengan rekaman otomatis ke S3?

Fitur rekam otomatis IVS ke Amazon S3 tidak mendukung KMS-S3 enkripsi. Saat mencoba menggunakan KMS-S3 enkripsi, awal perekaman akan gagal dan menghasilkan peristiwa Gag al Mulai Rek EventBridge aman. Solusi yang disarankan adalah menggunakan SSE-S3 enkripsi yang didukung, yang diaktifkan secara default pada semua objek yang diunggah ke Amazon S3.

Topik Lain-lain

Pertanyaan di bagian ini adalah tentang topik yang tidak dapat dikategorikan di tempat lain.

Topik:

Apa arti kesalahan “verifikasi tertunda”?

Saat menggunakan IVS, kesalahan mungkin muncul yang menyatakan: “Akun Anda sedang menunggu verifikasi. Sampai proses verifikasi selesai, Anda mungkin tidak dapat melakukan permintaan dengan akun ini. Jika Anda memiliki pertanyaan, hubungi Dukungan AWS.”

Ini menunjukkan bahwa akun AWS yang Anda gunakan harus diverifikasi dengan AWS sebelum Anda dapat menggunakan IVS. (Meskipun akun Anda dapat bekerja dengan layanan AWS lainnya, IVS menggunakan metode verifikasi yang disempurnakan.)

Untuk memverifikasi akun AWS Anda, hubungi Dukungan Akun AWS — dengan pesan kesalahan yang Anda terima — dari Pusat Dukungan AWS: https://support.console.aws.amazon.com/support/home? #/

Dapatkah saya memperkirakan biaya penggunaan IVS?

Sementara biaya pasti penggunaan IVS tidak dapat ditentukan sebelum sesi streaming, estimator biaya kasar ada di:. https://ivs.rocks/calculator Informasi harga tambahan ada di: https://aws.amazon.com/ivs/pricing/.