Pemrosesan tugas asinkron - ApsaraVideo Media Processing

Dokumen ini memberikan ikhtisar garis waktu tugas asinkron, menggunakan tugas transkoding sebagai ilustrasi cara menafsirkan status tugas dan memperkirakan waktu pemrosesan. Bidang status, indikator progres, dan metode kueri dapat berbeda tergantung jenis tugasnya. Selalu merujuk ke dokumentasi produk spesifik dan tanggapan API aktual.

Ikhtisar

Alibaba Cloud ApsaraVideo VOD, Alibaba Cloud Intelligent Media Services, dan Alibaba Cloud Media Processing menyediakan berbagai kemampuan pemrosesan media asinkron. Saat Anda mengirimkan tugas asinkron, layanan tersebut memprosesnya di latar belakang dan mengembalikan hasil setelah selesai.

Pengiriman yang berhasil hanya mengonfirmasi bahwa layanan telah menerima tugas tersebut. Ini tidak berarti tugas akan segera dimulai atau menjamin penyelesaian dalam waktu tetap.

Tugas asinkron merupakan bentuk pemrosesan offline. Berbeda dengan API sinkron, waktu penyelesaian tugas asinkron dipengaruhi oleh berbagai faktor, termasuk penjadwalan tugas, fluktuasi volume tugas, kompleksitas tugas, karakteristik file sumber, dan konfigurasi parameter. Waktu penyelesaian total bisa jauh lebih lama daripada waktu pemrosesan setelah tugas memasuki tahap pemrosesan aktual.

Tugas asinkron tidak cocok digunakan sebagai dependensi pemblokiran dalam alur kerja bisnis yang sensitif terhadap waktu. Jangan gunakan nilai referensi kecepatan pemrosesan dalam dokumen ini untuk memperkirakan waktu pengiriman di lingkungan produksi.

Cakupan

Dokumen ini berlaku untuk tugas pemrosesan media yang diajukan dan dieksekusi secara asinkron di Alibaba Cloud ApsaraVideo VOD, Alibaba Cloud Intelligent Media Services, dan Alibaba Cloud Media Processing, termasuk namun tidak terbatas pada:

Tugas transkoding media.
Tugas penyuntingan media.
Tugas snapshot dan gambar sprite.
Tugas analisis media.
Tugas pemrosesan media asinkron berbantuan AI.
Tugas pemrosesan media lainnya yang diajukan dan diambil melalui mekanisme asinkron.

Jika tersedia dokumentasi terpisah untuk kemampuan tertentu, ikuti petunjuk tersebut.

Garis waktu umum

Bacalah seluruh bagian ini sebelum menginisiasi tugas dan merancang alur kerja bisnis Anda.

Waktu total untuk tugas asinkron biasanya terdiri dari dua bagian:

waktu total tugas = waktu tunggu + waktu pemrosesan

Di mana:

waktu tunggu: Waktu yang dihabiskan tugas dalam antrian setelah dikirimkan namun sebelum memasuki tahap pemrosesan aktual.
waktu pemrosesan: Waktu yang dibutuhkan untuk mengeksekusi tugas itu sendiri setelah memasuki tahap pemrosesan aktual.

Penting

Menerima ID tugas hanya mengonfirmasi bahwa tugas berhasil dibuat.
Waktu penyelesaian yang dirasakan adalah waktu total tugas, bukan hanya waktu pemrosesan.
Nilai referensi performa hanya bersifat ilustratif. Nilai tersebut bukan komitmen layanan, metrik Service Level Agreement (SLA), jaminan pengiriman, atau dasar untuk kompensasi.
Meskipun spesifikasi tugas mirip dengan contoh referensi, waktu penyelesaian total bisa jauh lebih lama akibat peningkatan waktu tunggu.
Jika bisnis Anda memiliki tenggat waktu ketat, sisihkan waktu cadangan dan rancang sistem Anda dengan penguraian keterkaitan asinkron, fallback timeout, serta rencana penurunan layanan.

Perbedaan antara "waktu penyelesaian total" dan "waktu pemrosesan"

Memahami perbedaan ini penting untuk mengelola ekspektasi terhadap tugas asinkron.

Referensi kecepatan pemrosesan, pengali kecepatan, atau contoh waktu dalam dokumen ini hanya menggambarkan karakteristik performa tugas setelah memasuki tahap pemrosesan aktual.

Waktu yang dibutuhkan untuk menerima hasil bergantung pada:

Berapa lama tugas menunggu dalam antrian sebelum pemrosesan dimulai.
Berapa lama tugas diproses setelah dimulai.

Oleh karena itu:

Waktu pemrosesan referensi ≠ Waktu penyelesaian total.
Anda tidak dapat menggunakan waktu pemrosesan referensi untuk memprediksi waktu pengiriman tugas.
Tugas dengan spesifikasi identik yang dikirimkan pada waktu berbeda dapat memiliki waktu penyelesaian total yang sangat berbeda.

Waktu tunggu umum

Setelah tugas dikirimkan, layanan menjadwalkannya untuk diproses berdasarkan jenis tugas, volume tugas keseluruhan, dan strategi pemrosesan internal.

Waktu tunggu dapat meningkat dalam situasi berikut:

Sejumlah besar tugas dikirimkan dalam periode singkat.
Volume tugas berfluktuasi signifikan dalam periode waktu yang sama.
Proporsi tinggi tugas kompleks secara komputasi berada dalam antrian.

Catatan

Pengiriman tugas yang berhasil tidak berarti tugas telah mulai diproses.
Waktu tunggu dapat bervariasi tergantung waktu pengiriman, jenis tugas, volume tugas, dan perbedaan pipeline pemrosesan.
Jangan mengirim ulang tugas yang sama selama masih dalam masa tunggu. Hal ini dapat menyebabkan pemrosesan duplikat dan memperpanjang waktu tunggu secara keseluruhan.
Gunakan callback asinkron untuk menerima hasil tugas, bukan polling frekuensi tinggi.

Untuk memahami status layanan saat ini, pertimbangkan poin-poin berikut:

Waktu tunggu dipengaruhi oleh banyak faktor, seperti volume tugas dan karakteristik tugas. Peningkatan waktu tunggu saja bukan indikator andal adanya masalah layanan. Untuk memastikan status layanan saat ini, hubungi dukungan teknis.
Jika terjadi masalah layanan berdampak luas, Alibaba Cloud akan memberi tahu pengguna yang terdampak melalui pesan internal, SMS, atau saluran lainnya.

Waktu pemrosesan umum

Waktu pemrosesan aktual bergantung pada jenis tugas, karakteristik file sumber, dan konfigurasi tugas. Kemampuan berbeda memiliki model estimasi durasi tugas yang berbeda pula.

Faktor-faktor yang umum memengaruhi

Faktor	Pola	Deskripsi
Durasi file sumber	Durasi lebih panjang biasanya berarti waktu pemrosesan lebih lama	Salah satu faktor utama untuk sebagian besar tugas pemrosesan media.
Spesifikasi output	Spesifikasi lebih tinggi biasanya berarti waktu pemrosesan lebih lama	Misalnya, resolusi lebih tinggi atau format output lebih kompleks.
Kompleksitas algoritma pemrosesan	Algoritma lebih kompleks biasanya berarti waktu pemrosesan lebih lama	Misalnya, transkoding lanjutan atau analisis kompleks.
Parameter kustom	Parameter lebih kompleks biasanya berarti waktu pemrosesan lebih lama	Misalnya, parameter peningkatan atau pemrosesan multi-tahap.
Karakteristik file sumber	Karakteristik lebih kompleks dapat menyebabkan variasi waktu lebih besar	Misalnya, bitrate, laju frame, format kontainer, atau struktur aliran.
Jenis tugas	Jenis tugas berbeda memiliki model waktu berbeda	Anda tidak dapat langsung membandingkan waktu tugas transkoding, penyuntingan, snapshot, dan analisis.

Perbedaan antar jenis tugas

Tugas transkoding: Waktu pemrosesan biasanya bergantung pada durasi video, resolusi, format encoding, algoritma transkoding, dan parameter templat.
Tugas penyuntingan: Waktu pemrosesan juga dipengaruhi oleh jumlah klip, apakah diperlukan re-encoding, apakah penyuntingan melewati keyframe, dan penyambungan multi-klip.
Tugas snapshot, gambar sprite, dan analisis: Metode estimasi waktu mungkin berbeda dari transkoding. Merujuklah ke dokumentasi produk spesifik untuk mengetahui apakah bidang progres, bidang status, dan tahapan pemrosesan tersedia.

Status dan progres tugas

Bidang status, indikator progres, metode kueri, dan mekanisme notifikasi hasil dapat berbeda tergantung jenis tugas asinkron.

Logika status yang dijelaskan dalam dokumen ini menggambarkan tahapan pemrosesan umum tugas asinkron. Tidak semua tugas asinkron menggunakan model status ini.

Secara umum, tugas asinkron melewati tahapan berikut:

Catatan:

Beberapa tugas mungkin memiliki bidang progres yang dapat Anda kueri.
Beberapa tugas mungkin hanya mengembalikan beberapa status, seperti Processing, Succeeded, atau Failed.
Untuk beberapa tugas, "Waiting" bukan status terpisah melainkan fase yang ditentukan dengan menggabungkan bidang status dengan bidang lainnya.
Untuk definisi status spesifik, merujuklah ke tanggapan API aktual dan dokumentasi produk terkait.

Contoh: Tugas transkoding

Bagian ini mengilustrasikan cara menafsirkan status dan memperkirakan durasi tugas transkoding. Tugas asinkron lainnya mungkin menggunakan mekanisme berbeda.

Status tugas transkoding

Sebagai contoh, setelah mengirimkan tugas transkoding, bidang status dalam hasil kueri mungkin menampilkan "Transcoding".

Perhatikan bahwa status "Transcoding" berarti tugas telah memasuki proses transkoding, namun belum tentu transkoding aktual telah dimulai.

Anda dapat menggunakan bidang TranscodeProgress untuk lebih lanjut menentukan tahap tugas:

Status tugas	TranscodeProgress	Deskripsi	Interpretasi yang disarankan
Transcoding/Submitted	0	Belum melakukan transkoding.	Waiting
Transcoding/Percent/Running	> 0	Transkoding sedang berlangsung.	Transcoding
Succeeded status	100 atau penyelesaian tugas	Transkoding berhasil diselesaikan.	Succeeded
Failed status	-	Transkoding dihentikan karena error.	Failed

Untuk tugas transkoding, waiting biasanya bukan status mandiri. Ini merupakan fase yang ditentukan dengan menggabungkan status tugas dan progres transkoding.

Referensi kecepatan transkoding

Penting

Nilai referensi ini menggambarkan kecepatan pemrosesan tugas transkoding setelah dimulai, dalam kondisi uji khas. Nilai ini tidak mencakup waktu tunggu, tidak merepresentasikan waktu penyelesaian total tugas, dan bukan komitmen layanan.

Untuk skenario transkoding H.264 720p khas, karakteristik kecepatan pemrosesan algoritma transkoding berbeda adalah sebagai berikut:

Algoritma transkoding	Referensi kecepatan	Deskripsi
Standard Transcoding	Sekitar kecepatan 3x	Hanya mencerminkan kecepatan tahap pemrosesan dalam kondisi khas.
Narrowband HD 1.0	Sekitar kecepatan 1,5x	Waktu pemrosesan biasanya lebih lama daripada transkoding standar.
Narrowband HD 2.0	Biasanya jauh kurang dari kecepatan 1x	Waktu pemrosesan biasanya lebih lama daripada durasi video sumber. Waktu aktual bergantung pada tugas.

Pengali kecepatan

Kecepatan = Pengali durasi video yang dapat diproses per satuan waktu

Contoh:
Kecepatan 3x berarti setiap 1 menit pemrosesan, sekitar 3 menit konten video dapat diproses.
Oleh karena itu, untuk video berdurasi 30 menit, waktu pemrosesan teoretis sekitar 10 menit, tidak termasuk waktu tunggu.

Catatan

Nilai referensi di atas hanya berlaku untuk skenario transkoding H.264 720p khas.
Jangan gunakan nilai ini untuk memperkirakan waktu penyelesaian total tugas.
Untuk resolusi lebih tinggi, encoding lebih kompleks, atau konfigurasi parameter lebih intensif, kecepatan pemrosesan biasanya lebih rendah daripada nilai referensi.
Perbedaan bitrate, laju frame, format kontainer, dan struktur aliran video sumber semuanya dapat secara signifikan memengaruhi waktu pemrosesan.
Kompleksitas pemrosesan Narrowband HD 2.0 biasanya jauh lebih tinggi daripada transkoding standar dan Narrowband HD 1.0.
Untuk waktu pemrosesan aktual, merujuklah ke hasil kueri status tugas atau notifikasi penyelesaian.

FAQ

1. Apakah tugas transkoding 10 menit, 720p selalu selesai dalam 3 hingga 4 menit?

Tidak selalu.

Nilai referensi "sekitar kecepatan 3x" menggambarkan kecepatan pemrosesan tugas setelah dimulai, dalam kondisi khas. Nilai ini tidak mencakup waktu tunggu sebelum pemrosesan dimulai, maupun merepresentasikan waktu penyelesaian total tugas di lingkungan produksi.

Waktu aktual hingga hasil tersedia adalah waktu penyelesaian total tugas. Jangan gunakan referensi kecepatan pemrosesan untuk memprediksi waktu pengiriman.

Jika waktu total tugas melebihi ekspektasi bisnis Anda, merujuklah ke bagian troubleshooting umum untuk panduan, atau hubungi dukungan teknis.

2. Mengapa status tugas transkoding saya menunjukkan "Transcoding" tetapi TranscodeProgress selalu 0?

Untuk tugas transkoding, status "Transcoding" berarti tugas telah memasuki alur kerja transkoding, namun belum berarti transkoding aktual telah dimulai.

Saat TranscodeProgress = 0, tugas masih dalam tahap waiting. Saat TranscodeProgress > 0, tugas telah memasuki tahap pemrosesan transkoding aktual.

3. Spesifikasi tugas saya mirip dengan skenario referensi, tetapi mengapa waktu penyelesaian aktual jauh lebih lama?

Kemungkinan penyebabnya antara lain:

Tugas mengalami waktu tunggu panjang sebelum pemrosesan dimulai.
Karakteristik aktual file sumber Anda berbeda dari skenario referensi khas.
Parameter tugas atau konfigurasi templat lebih kompleks dari biasanya.
Fluktuasi volume tugas dalam periode yang sama menyebabkan waktu penyelesaian total meningkat.

Untuk mengidentifikasi penyebab lebih lanjut, kami sarankan Anda menghubungi dukungan teknis dan memberikan ID tugas untuk bantuan.

4. Apakah peningkatan waktu tunggu selalu menunjukkan adanya masalah layanan?

Tidak selalu.

Waktu tunggu dipengaruhi oleh banyak faktor, seperti volume tugas dan karakteristik tugas. Peningkatan waktu tunggu saja bukan indikator andal adanya masalah layanan. Untuk memastikan status layanan saat ini, kami sarankan Anda menghubungi dukungan teknis untuk bantuan.

5. Dapatkah saya menggunakan referensi kecepatan pemrosesan untuk menjamin waktu pengiriman bisnis saya?

Tidak.

Referensi kecepatan pemrosesan hanya bertujuan membantu Anda memahami karakteristik pemrosesan tugas. Referensi ini tidak boleh digunakan sebagai dasar untuk waktu pengiriman produksi, SLA bisnis, atau komitmen kepada pengguna akhir.

Untuk skenario bisnis dengan persyaratan waktu ketat, sisihkan waktu cadangan dalam arsitektur Anda dan terapkan mekanisme fallback timeout serta penurunan layanan.

6. Dapatkah saya menafsirkan status tugas asinkron lainnya dengan cara yang sama seperti tugas transkoding?

Tidak selalu.

Penggunaan "Transcoding" dan "TranscodeProgress" dalam contoh ini khusus untuk tugas transkoding.

Untuk tugas penyuntingan, snapshot, gambar sprite, analisis media, dan tugas asinkron lainnya, bidang status, bidang progres, dan metode interpretasi mungkin berbeda. Merujuklah ke API kueri dan dokumentasi untuk setiap tugas spesifik.

Operasi utama

Kirim tugas

Saat Anda mengirimkan tugas asinkron melalui API, layanan akan mengembalikan ID tugas.

ID tugas merupakan pengenal unik untuk mengkueri status, mengorelasikan notifikasi, dan troubleshooting. Simpanlah dengan aman.

Ambil hasil

Setelah tugas diproses, layanan dapat mengirimkan notifikasi hasil jika URL callback dikonfigurasi. Anda dapat menggunakan callback ini untuk mendeteksi penyelesaian tugas secara otomatis tanpa polling terus-menerus.

Menggunakan callback

Kami merekomendasikan menggunakan metode callback untuk mendapatkan hasil di lingkungan produksi.
Jika URL callback tidak dapat dijangkau, layanan secara otomatis mencoba ulang sesuai kebijakan yang telah ditentukan.
Jika pengiriman gagal setelah beberapa kali percobaan ulang, gunakan API kueri untuk memeriksa status akhir tugas secara aktif.
Notifikasi callback mungkin tertunda atau dikirim lebih dari sekali akibat fluktuasi jaringan atau masalah di sisi client.
Logika callback di sisi client Anda harus melakukan pemeriksaan idempotensi berdasarkan ID tugas.
Status akhir tugas harus didasarkan pada hasil yang dikembalikan oleh API kueri.

Untuk detail konfigurasi callback dan mekanisme percobaan ulang, lihat Callback Configuration.

Kueri tugas

Anda dapat secara aktif mengkueri status dan hasil tugas saat ini menggunakan ID tugasnya. Ini berguna dalam skenario berikut:

Anda belum mengonfigurasi notifikasi callback.
Anda telah mengonfigurasi callback tetapi perlu memeriksa progres saat ini.
Durasi tugas melebihi ekspektasi bisnis Anda.
Sebagai metode fallback saat notifikasi callback gagal.

Mengkueri informasi tugas

API kueri terutama mengembalikan informasi status, progres, dan hasil tugas. Jika tugas membutuhkan waktu jauh lebih lama dari yang diharapkan, kami sarankan melakukan troubleshooting dengan memeriksa perubahan status tugas, waktu pengiriman, dan konfigurasi tugas. Jika Anda masih tidak dapat menentukan penyebabnya, Anda dapat menghubungi dukungan teknis dan memberikan ID tugas untuk analisis.

General troubleshooting

Jika tugas membutuhkan waktu lebih lama dari yang diharapkan, ikuti langkah-langkah berikut:

1. Konfirmasi penyelesaian tugas

Kueri status atau hasil tugas saat ini menggunakan ID tugasnya:

Jika tugas selesai, ambil hasilnya dan evaluasi waktu total yang dibutuhkan.
Jika tugas gagal, periksa kode error dan pesan error-nya.
Jika tugas belum selesai, lanjutkan ke langkah berikutnya untuk menentukan apakah tugas berada dalam tahap waiting atau pemrosesan.

2. Tentukan tahap berdasarkan jenis tugas

Untuk tugas transkoding: Anda dapat memeriksa status "Transcoding" dan bidang "TranscodeProgress" untuk menentukan apakah tugas telah memasuki tahap pemrosesan aktual.
Untuk tugas asinkron lainnya: Merujuklah ke bidang yang dikembalikan oleh API kueri dan dokumentasi untuk tugas spesifik tersebut. Jangan menerapkan metode interpretasi yang sama seperti untuk tugas transkoding.

3. Identifikasi penyebab berdasarkan karakteristik tugas

Gejala	Kemungkinan penyebab	Tindakan yang disarankan
Tidak ada hasil dalam waktu lama	Fluktuasi volume tugas, peningkatan waktu tunggu, masalah layanan, atau kompleksitas tugas tinggi	Periksa halaman status layanan. Hubungi dukungan teknis jika perlu.
Waktu pemrosesan jauh lebih lama dari biasanya	File sumber kompleks, parameter intensif, atau kompleksitas tugas tinggi	Periksa file sumber dan konfigurasinya. Hubungi dukungan jika perlu.
Tugas gagal	Masalah file sumber, kesalahan parameter, atau error pemrosesan	Periksa dokumentasi kode error dan perbaiki sesuai saran.
Tidak ada hasil dari kueri	ID tugas salah atau tugas tidak berhasil dikirimkan	Verifikasi hasil pengiriman dan ID tugas.

4. Informasi untuk dukungan teknis

Saat menghubungi dukungan teknis untuk troubleshooting, berikan informasi berikut:

ID tugas.
Waktu pengiriman tugas.
Jenis tugas (misalnya, transkoding, penyuntingan, snapshot, atau analisis).
Durasi file sumber, resolusi, dan format encoding.
Konfigurasi templat atau parameter pemrosesan.
Menyatakan apakah item dikirimkan secara batch.
Deskripsi masalah dan dampaknya.

Metode integrasi yang direkomendasikan

Metode	Deskripsi	Kasus penggunaan
Callback asinkron (Direkomendasikan)	Layanan mengirimkan hasil setelah tugas selesai.	Lingkungan produksi dan skenario bisnis reguler.
Polling	Secara berkala mengkueri status dan hasil tugas.	Debugging, pengujian, dan sebagai fallback saat callback gagal.

Rekomendasi integrasi

Di lingkungan produksi, prioritaskan penggunaan callback asinkron.
Hindari polling frekuensi tinggi untuk mengurangi permintaan yang tidak perlu.
Terapkan kontrol idempotensi saat mengirimkan tugas untuk menghindari duplikasi.
Untuk tugas batch, atur pengiriman secara bertahap untuk menghindari pembentukan antrian besar dalam waktu singkat.
Buat mekanisme untuk pemantauan timeout tugas, peringatan, dan fallback manual.
Untuk skenario bisnis kritis, sisihkan waktu cadangan yang cukup dan rancang rencana penurunan layanan.
Jangan gunakan referensi kecepatan pemrosesan untuk komitmen pengiriman produksi.

SLA dan cakupan tanggung jawab

Jika Anda mencurigai keterlambatan tugas disebabkan oleh masalah layanan, hubungi dukungan teknis dan berikan ID tugas serta informasi terkait untuk bantuan.
Ketersediaan layanan, tanggung jawab, dan kompensasi diatur oleh perjanjian layanan resmi dan Service Level Agreement (SLA).
Deskripsi durasi tugas, nilai referensi kecepatan pemrosesan, contoh, dan FAQ dalam dokumen ini hanya bersifat referensi. Dokumen ini membantu menjelaskan mekanisme pemrosesan tugas asinkron dan bukan komitmen tersendiri terhadap waktu penyelesaian, maupun dasar untuk kompensasi layanan atau bisnis.

Rekomendasi

Untuk mengurangi dampak bisnis akibat fluktuasi waktu tugas asinkron:

Gunakan penguraian keterkaitan asinkron dalam desain sistem Anda untuk menangani tugas media.
Gunakan callback atau kueri status untuk mendapatkan hasil tugas, bukan pemblokiran sinkron.
Sisihkan waktu cadangan ekstra untuk periode puncak, tugas batch, dan tugas kompleks.
Buat mekanisme untuk peringatan timeout tugas, intervensi manual, dan fallback bisnis.

Untuk informasi lebih lanjut, merujuklah ke dokumentasi produk terkait.