FAQ Pemecahan Masalah

Dokumen ini menjelaskan praktik terbaik dan tips pemecahan masalah untuk Amazon Interactive Video Service (IVS). Perilaku tak terduga atau tidak diinginkan dapat terjadi saat menggunakan IVS. Perilaku ini 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?

• Mengapa aliran tiba-tiba berhenti?

• Apa yang terjadi ketika saya beralih jaringan saat streaming?

• Bagaimana saya bisa memiliki redundansi multi-wilayah dengan IVS?

• Bagaimana cara memecahkan masalah sesi SDK Siaran Web IVS?

• Bagaimana cara menggunakan metrik WebRTC internal Google Chrome untuk mengevaluasi sesi SDK Siaran Web IVS?

Apa itu kelaparan aliran?

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

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

Untuk memungkinkan pemantauan peristiwa kelaparan, IVS mengirimkan peristiwa kelaparan sebagai peristiwa EventBridge Amazon; lihat Contoh: Streaming Perubahan Kesehatan dalam Menggunakan Amazon dengan Amazon EventBridge IVS. Ini dikirim ketika aliran masuk atau keluar dari keadaan kelaparan. Bergantung 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 Streaming Latensi Rendah Amazon IVS, titik akhir ListStreamsAPI IVS (pemfilteran berdasarkan kesehatan), dan titik akhir IVS GetStream(untuk menganalisis aliran individual). Lihat juga Bagaimana cara memantau peristiwa kelaparan aliran?

Mengapa aliran tiba-tiba berhenti?

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

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

  Seringkali, pemutusan aliran sejalan dengan peristiwa kelaparan aliran; peristiwa kelaparan dipicu ketika ada penghentian data yang masuk. Jika peristiwa awal kelaparan dikirim dan kemudian peristiwa akhir aliran dikirim (tanpa peristiwa akhir kelaparan), ini sering menunjukkan bahwa aliran telah berakhir karena tidak ada data yang dikirim ke IVS.

• StopStream Titik akhir IVS — Selama sesi streaming IVS, jika panggilan StopStreamAPI dilakukan, sesi aliran IVS akan berakhir. StopStream Titik akhir memutus aliran RTMPS yang masuk dari server ingest IVS. Bergantung pada perangkat lunak/perangkat keras pengkodean yang digunakan, sesi aliran baru dapat dicoba.

• Kesalahan encoder - Beberapa encoder perangkat lunak/perangkat keras akan memutuskan sesi aliran 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 dibangun 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 mengirim pesan pemutus 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, kami sarankan Anda menggunakan StopStreamtitik akhir IVS untuk menutup sesi streaming sebelumnya saat perangkat beralih jaringan. Dalam skenario ini, ketika perangkat siaran terhubung ke jaringan baru, perangkat siaran dapat memanggil StopStream titik akhir untuk mengakhiri aliran yang sekarang tidak aktif. Setelah StopStream panggilan berhasil, perangkat siaran dapat memulai sesi streaming baru di jaringan baru tanpa menunggu selama 30 detik.

Bagaimana saya bisa memiliki redundansi multi-wilayah dengan IVS?

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

IVS dipisahkan menjadi bidang jaringan yang berbeda; Kontrol dan Data.

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

• Bidang data tidak terbatas pada wilayah AWS dan merupakan jaringan yang membawa data dari ingest ke egress. Bahkan jika saluran dibuat di wilayah us-barat-2 (misalnya), video yang dialirkan ke saluran itu 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 dari berikut ini: 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. Bergantung 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 melihat jika ada masalah dengan otorisasi pasangan kunci pemutaran. Jika otorisasi pemutaran tidak diaktifkan, pemirsa saat ini dan yang baru harus dapat melihat streaming yang sedang berlangsung.

  Fitur Rekam Otomatis IVS ke S3 juga dapat terganggu jika terjadi pemadaman.

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

• Jika dua wilayah bidang kontrol (misalnya, us-east-1 dan us-west-2) digunakan, dan wilayah kedua adalah failover jika wilayah utama tidak tersedia — IVS tidak secara native mendukung failover bidang kontrol regional; dengan demikian, jika wilayah bidang kontrol mengalami masalah, aliran baru yang dimulai atau panggilan ke pesawat kontrol mungkin mengalami masalah. Namun, bidang data mungkin tidak akan terpengaruh, sehingga aliran yang sedang berlangsung untuk wilayah bidang 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 SDK Siaran Web IVS?

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

Karena sifat Web Broadcast SDK, perhatikan tips berikut untuk mengatasi masalah perilaku pengkodean:

• Tutup tab/program apa pun pada perangkat penyiaran yang tidak perlu dibuka selama sesi penyiaran. Tab/program asing dapat menggunakan sumber daya komputasi (seperti CPU, RAM, dan jaringan), yang dapat menyebabkan kinerja yang buruk untuk aplikasi penyiaran. Untuk tab/program yang tidak dapat ditutup, pastikan mereka tidak menggunakan jumlah sumber daya komputasi yang tidak perlu.

• Pastikan kecepatan unggah perangkat melebihi 200 Kbps. (Ini dicatat dalam salah satu Masalah yang Diketahui untuk SDK Siaran Web.) Untuk mengevaluasi kecepatan unggah, buka Task Manager perangkat penyiaran untuk menganalisis jaringan yang tersedia saat streaming. Jika kecepatan unggahan/bitrate lebih rendah dari yang diharapkan atau diinginkan, evaluasi tab/proses lain yang mungkin memakan bandwidth. Juga, lihat mesin lain di jaringan lokal yang mungkin mengkonsumsi bandwidth dalam jumlah tinggi.

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

• Coba 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 WebRTC-internal Google Chrome (lihat di bawah).

Bagaimana cara menggunakan metrik WebRTC internal Google Chrome untuk mengevaluasi sesi SDK Siaran Web IVS?

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 persis).

3. Di tab halaman web penyiaran asli, mulai sesi Web Broadcasting SDK dan biarkan sesi berjalan hingga perilaku diamati.

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

   

5. Buka bagian Create Dump yang dapat diperluas 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 AWS Support 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?

• Bagaimana cara menggunakan Amazon CloudWatch untuk memantau kuota layanan IVS?

• Bagaimana cara mendiagnosis ketidakstabilan aliran menggunakan IVS Stream Health?

Bagaimana cara memantau peristiwa kelaparan aliran?

Kami merekomendasikan metode pemantauan berikut untuk peristiwa kelaparan aliran:

• Amazon EventBridge dengan Amazon IVS — Ketika peristiwa kelaparan aliran dimulai atau berakhir, IVS menghasilkan peristiwa perubahan kesehatan aliran. EventBridge Dengan 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 Streaming Latensi Rendah Amazon IVS — Selama sesi streaming langsung, data direkam dan kemudian tersedia melalui analisis kesehatan aliran IVS. Ini termasuk informasi tentang konfigurasi encoder, metrik konsumsi, dan peristiwa sesi streaming. Ini bermanfaat saat memantau aliran yang sedang berlangsung atau mengevaluasi aliran secara surut. Anda dapat menggunakan konsol IVS atau API untuk mengidentifikasi aliran yang mengalami kelaparan. Data sesi streaming tersedia selama 60 hari, bahkan setelah saluran dihapus, jadi ini dapat berguna untuk mengidentifikasi aliran masa lalu dengan peristiwa kelaparan.

• Memfilter Stream menurut Kesehatan — Dengan konsol IVS atau titik akhir ListStreamsAPI 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 Memantau Streaming Latensi Rendah Amazon IVS.

• Anda dapat menggunakan GetStreamtitik akhir IVS untuk menganalisis aliran individual.

Lihat juga Apa itu kelaparan aliran?

Bagaimana cara menggunakan Amazon CloudWatch untuk memantau kuota layanan IVS?

Anda dapat menggunakan Amazon CloudWatch untuk memantau/mengelola kuota layanan IVS secara proaktif. Lihat Service Quotas IVS. Dokumentasi ini mencakup informasi tentang membuat CloudWatch alarm untuk metrik penggunaan.

Kami menyarankan Anda mengatur topik SNS yang tepat untuk memberi tahu individu/grup yang benar saat alarm dipicu. Jika alarm dipicu dan kuota dapat disesuaikan, Anda harus meminta peningkatan kuota layanan dengan nilai baru. Lihat Service Quotas IVS untuk informasi tentang permintaan kenaikan.

Bagaimana cara mendiagnosis ketidakstabilan aliran menggunakan IVS Stream Health?

Kami menyarankan Anda mengevaluasi ketidakstabilan aliran menggunakan dasbor IVS Stream Health. Instruksi ada di Pemantauan Streaming Latensi Rendah Amazon IVS.

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

Beberapa skenario dibahas di bawah ini.

Bandwidth Internet Rendah atau Kemacetan Internet

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

Dasbor Kesehatan Stream IVS:

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 yang tinggi menyebabkan ketidakstabilan aliran di seluruh siaran. Patuhi bitrate maksimum yang tercantum diResolusi/Bitrate/FPS.

Dasbor Kesehatan Stream IVS:

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 up to date. Pertimbangkan untuk beralih ke preset pengkodean yang menggunakan lebih sedikit CPU.

Dasbor Kesehatan Stream IVS:

CloudWatch:

Lonjakan dan Kemiringan Bitrate

Terkadang encoder streaming mencoba 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:

CloudWatch:

Pemutusan Internet

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

Dasbor Kesehatan Stream IVS:

CloudWatch:

Pemutaran Streaming

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

Topik:

• Bagaimana cara men-debug perilaku pemain IVS?

• Mengapa pemutaran beku/berhenti untuk semua pemirsa?

• Apa yang menyebabkan pemain IVS buffer?

Bagaimana cara men-debug perilaku pemain IVS?

Untuk mengaktifkan pencatatan verbose untuk membantu men-debug IVS Player, gunakan metode pemain. setLogLevel 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 pengujian https://debug.ivsdemos.com/. Jika DEBUG log diaktifkan melalui menu pengaturan, Anda dapat melihat log di tampilan konsol browser.

Mengapa pemutaran beku/berhenti untuk semua pemirsa?

Jika pemutaran untuk semua pemirsa membeku/berhenti pada saat yang sama di dalam konten, ini mungkin adalah hasil dari perilaku hulu. Seringkali akar penyebabnya adalah encoder siaran.

Streaming kelaparan atau perilaku penyiaran-encoder yang merugikan dapat berdampak pada semua pemirsa secara bersamaan. Jika penyandian siaran terputus dan sesi streaming baru dimulai, semua pemirsa berhenti menerima konten secara bersamaan. Saat Anda mengevaluasi perilaku ini, kami sarankan Anda mengevaluasi sesi streaming menggunakan Pemantauan Streaming Latensi Rendah Amazon IVS.

Apa yang menyebabkan pemain IVS buffer?

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:

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

• Buffering tingkat jaringan — Masalah dapat terjadi antara jaringan lokal dan server distribusi IVS, atau dikenal sebagai tingkat ISP. Perilaku buffering yang muncul pada 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 keseluruhan lalu lintas masuk/keluar) dapat menyebabkan keterlambatan dalam menyediakan konten kepada pemirsa.

• Buffering sisi siaran - 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, acara buffering sisi siaran menghasilkan sebagian besar, jika tidak semua, pemirsa terpengaruh secara bersamaan.

Rekam Otomatis ke Amazon S3

Untuk informasi selengkapnya, lihat Rekam Otomatis ke Amazon S3.

Topik:

• Mengapa beberapa konten rekaman hilang?

• Bisakah enkripsi KMS-S3 digunakan dengan rekam otomatis ke S3?

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 Rekam Otomatis ke S3 diaktifkan untuk saluran IVS yang diinginkan:

   1. Konsol — Pada halaman detail untuk saluran yang relevan, di bagian Konfigurasi umum, pastikan bahwa Rekam otomatis ke S3 adalah. Enabled Jika diaktifkan, periksa konfigurasi Perekaman untuk memastikan bahwa awalan Penyimpanan dan Perekaman sudah benar.

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

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

      Lihat recordingConfigurationArn apakah a dikembalikan.

2. Lihat di bucket S3 yang ditentukan untuk Merekam Konten untuk sesi streaming tertentu (lihat Awalan S3.) Awalan kunci S3 untuk sesi rekaman ada di acara EventBridge Amazon Recording State Change. Catatan: Jika fitur gabungan aliran terfragmentasi diaktifkan, beberapa konten mungkin merupakan sesi rekaman lainnya.

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

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

Fitur rekam otomatis IVS ke Amazon S3 tidak mendukung enkripsi KMS-S3. Saat mencoba menggunakan enkripsi KMS-S3, awal perekaman akan gagal dan menghasilkan peristiwa Kegagalan Mulai Perekaman. EventBridge Solusi yang disarankan adalah menggunakan enkripsi SSE-S3 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”?

• Dapatkah saya memperkirakan biaya penggunaan IVS?

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 AWS Support.”

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 AWS Account Support — dengan pesan kesalahan yang Anda terima — dari AWS Support Center: https://support.console.aws.amazon.com/support/home?#/

Dapatkah saya memperkirakan biaya penggunaan IVS?

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