All Products
Search
Document Center

Intelligent Media Services:Pemrosesan tugas asinkron

Last Updated:Apr 21, 2026

Berlaku untuk tugas pemrosesan media asinkron di ApsaraVideo VOD, Intelligent Media Services (IMS), dan ApsaraVideo Media Processing (MPS). Topik ini memberikan panduan umum untuk memahami waktu dan perilaku tugas asinkron, menggunakan Transkoding sebagai contoh untuk menggambarkan status tugas dan durasi pemrosesan. Bidang status, indikator progres, dan metode kueri bervariasi tergantung jenis tugas. Untuk detailnya, rujuk dokumentasi masing-masing API atau layanan.

Ikhtisar

ApsaraVideo VOD, IMS, dan MPS menyediakan berbagai kemampuan pemrosesan media asinkron. Tugas asinkron diajukan melalui panggilan API dan diproses di latar belakang. Hasil tersedia setelah pemrosesan selesai.

Pengajuan tugas yang berhasil berarti tugas telah diterima, bukan berarti pemrosesan telah dimulai atau akan selesai dalam waktu tetap.

Tugas asinkron pada dasarnya merupakan pekerjaan pemrosesan offline. Berbeda dengan panggilan API sinkron, waktu untuk menghasilkan output bergantung pada beberapa faktor: penjadwalan tugas, fluktuasi workload, kompleksitas tugas, karakteristik file sumber, dan konfigurasi parameter. Waktu penyelesaian total bisa jauh lebih lama daripada waktu pemrosesan aktual saja.

Oleh karena itu, tugas asinkron tidak boleh digunakan sebagai kondisi pemblokiran dalam alur kerja yang sensitif terhadap latensi. Jangan gunakan patokan kecepatan pemrosesan dalam dokumen ini untuk memperkirakan jadwal pengiriman di lingkungan produksi.

Cakupan

Panduan ini berlaku untuk tugas pemrosesan media yang diajukan dan dieksekusi secara asinkron di ApsaraVideo VOD, IMS, dan MPS. Termasuk, namun tidak terbatas pada:

  • Tugas Transkoding media.

  • Tugas editing dan kompositing media.

  • Tugas Snapshot dan sprite sheet.

  • Tugas analisis media.

  • Tugas pemrosesan media berbantuan AI.

  • Tugas pemrosesan media lainnya yang menggunakan model pengajuan dan Pengambilan asinkron.

Pipeline pemrosesan, karakteristik durasi, bidang status, indikator progres, metode kueri, dan mekanisme Notifikasi dapat berbeda antar jenis tugas. Jika dokumentasi suatu kemampuan tertentu menyediakan panduan terpisah, ikuti dokumentasi tersebut.

Panduan waktu umum

Kami menyarankan Anda membaca bagian ini sebelum mengajukan tugas dan merancang logika bisnis Anda sesuai dengan itu.

Waktu total untuk menyelesaikan tugas asinkron biasanya terdiri dari dua bagian:

Waktu penyelesaian total = Waktu tunggu antrian + Waktu pemrosesan aktual

Di mana:

  • Waktu tunggu antrian: Waktu antara pengajuan tugas dan dimulainya pemrosesan aktual.

  • Waktu pemrosesan aktual: Waktu yang dihabiskan untuk mengeksekusi tugas setelah pemrosesan dimulai.

Penting
  • ID tugas yang dikembalikan hanya mengonfirmasi bahwa tugas berhasil dibuat.

  • Waktu penyelesaian yang Anda alami adalah waktu penyelesaian total, bukan hanya waktu pemrosesan.

  • Patokan kecepatan pemrosesan menggambarkan karakteristik pemrosesan tipikal. Patokan tersebut bukan merupakan komitmen layanan, jaminan SLA, jaminan pengiriman, atau dasar untuk kompensasi.

  • Meskipun spesifikasi tugas sangat mirip dengan skenario patokan, waktu penyelesaian total bisa jauh lebih lama karena peningkatan waktu tunggu antrian.

  • Jika bisnis Anda memiliki persyaratan waktu yang ketat, sisipkan waktu buffer dan terapkan penguraian keterkaitan asinkron, fallback timeout, serta strategi degradasi elegan.

Waktu penyelesaian total vs. waktu pemrosesan

Memahami perbedaan ini sangat penting saat bekerja dengan tugas asinkron.

Kecepatan pemrosesan, pengali kecepatan, dan perkiraan waktu yang disebutkan dalam dokumentasi ini hanya mengacu pada kecepatan pemrosesan setelah tugas benar-benar mulai diproses.

Waktu yang benar-benar Anda alami sebelum hasil tersedia bergantung pada:

  1. Berapa lama tugas menunggu sebelum pemrosesan dimulai.

  2. Berapa lama tugas diproses.

Oleh karena itu:

  • Patokan waktu pemrosesan tidak sama dengan waktu penyelesaian total.

  • Patokan waktu pemrosesan tidak dapat digunakan untuk menghitung jadwal pengiriman.

  • Tugas identik yang diajukan pada waktu berbeda dapat memiliki waktu penyelesaian total yang berbeda secara signifikan.

Waktu tunggu antrian

Setelah tugas diajukan, layanan menjadwalkannya berdasarkan jenis tugas, workload saat ini, dan kebijakan pemrosesan.

Waktu tunggu antrian dapat meningkat dalam kondisi berikut:

  • Sejumlah besar tugas diajukan dalam periode singkat.

  • Terjadi fluktuasi workload dalam jendela waktu yang sama.

  • Proporsi tinggi tugas kompleks berada dalam antrian.

Catatan
  • Pengajuan yang berhasil tidak berarti tugas telah memasuki tahap pemrosesan.

  • Waktu tunggu dapat bervariasi berdasarkan waktu pengajuan, jenis tugas, volume tugas, dan perbedaan pipeline pemrosesan.

  • Jangan mengajukan ulang tugas yang sama selama masa tunggu. Pengajuan duplikat dapat menyebabkan pemrosesan berlebihan dan semakin memperpanjang waktu tunggu keseluruhan.

  • Gunakan callback asinkron untuk menerima hasil tugas, bukan polling frekuensi tinggi.

Untuk memeriksa status layanan saat ini:

  • Peningkatan waktu tunggu saja tidak selalu menunjukkan adanya gangguan layanan. Banyak faktor yang memengaruhi waktu tunggu. Untuk memastikan status layanan saat ini, hubungi dukungan teknis.

  • Jika terjadi gangguan layanan luas, Alibaba Cloud akan memberi tahu pengguna yang terdampak melalui pesan di Konsol, SMS, atau saluran lainnya.

Waktu pemrosesan aktual

Waktu pemrosesan aktual bergantung pada jenis tugas, karakteristik file sumber, dan konfigurasi tugas. Kemampuan berbeda memiliki model kinerja berbeda.

Faktor umum yang memengaruhi waktu pemrosesan

Faktor

Pola

Deskripsi

Durasi file sumber

File yang lebih panjang membutuhkan waktu pemrosesan lebih lama.

Faktor utama untuk sebagian besar tugas pemrosesan media.

Spesifikasi output

Spesifikasi output yang lebih tinggi membutuhkan waktu lebih lama.

Misalnya, resolusi lebih tinggi atau format output lebih kompleks.

Kompleksitas algoritma

Algoritma yang lebih kompleks membutuhkan waktu lebih lama.

Misalnya, Transkoding lanjutan atau analisis kompleks.

Parameter kustom

Parameter yang lebih kompleks membutuhkan waktu lebih lama.

Misalnya, parameter enhancement atau pemrosesan multi-tahap.

Karakteristik file sumber

Karakteristik yang lebih kompleks meningkatkan variansi.

Misalnya, bitrate, laju frame, format kontainer, dan struktur aliran.

Jenis tugas

Jenis tugas berbeda memiliki model kinerja berbeda.

Tugas Transkoding, editing, Snapshot, dan analisis tidak dapat dibandingkan secara langsung.

Perbedaan antar jenis tugas

  • Tugas Transkoding: Waktu pemrosesan biasanya berkorelasi dengan durasi video, resolusi, kodek, algoritma Transkoding, dan parameter templat.

  • Tugas editing: Faktor tambahan mencakup jumlah segmen, apakah re-encoding diperlukan, apakah potongan melewati batas keyframe, dan konkatenasi multi-segmen.

  • Tugas Snapshot, sprite sheet, dan analisis: Metode estimasi durasi mungkin berbeda dari Transkoding. Keberadaan bidang progres, bidang status, dan rincian tahapan bergantung pada kemampuan spesifik. Rujuk dokumentasi terkait.

Status dan progres tugas

Bidang status, indikator progres, metode kueri, dan mekanisme pengiriman hasil bervariasi antar jenis tugas asinkron.

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

Dari perspektif umum, tugas asinkron biasanya melewati tahapan berikut:

image

Perlu diingat:

  • Beberapa tugas menampilkan bidang progres yang dapat dikueri.

  • Beberapa tugas hanya mengembalikan sekumpulan status terbatas, seperti processing, completed, atau failed.

  • Untuk beberapa tugas, status "waiting" bukanlah nilai enum diskret. Anda menentukannya dengan menggabungkan bidang status dengan bidang lainnya.

  • Rujuk respons API aktual dan dokumentasi produk terkait untuk definisi status yang tepat.

Contoh tugas Transkoding

Bagian berikut hanya berlaku untuk tugas Transkoding. Tugas asinkron lainnya mungkin menggunakan mekanisme berbeda.

Status tugas Transkoding

Saat Anda mengajukan tugas Transkoding, bidang status dalam hasil kueri mungkin menampilkan Transcoding.

Perhatikan bahwa Transcoding menunjukkan tugas telah memasuki pipeline Transkoding, tetapi belum tentu berarti Transkoding aktual telah dimulai.

Gabungkan bidang TranscodeProgress untuk menentukan tahap saat ini:

Status

TranscodeProgress

Makna

Interpretasi

Transcoding/Submitted

0

Tugas belum memulai Transkoding aktual.

Waiting

Transcoding/Percent/Running

> 0

Tugas sedang ditranskode.

Processing

Completed

100 atau tugas selesai

Transkoding selesai berhasil.

Completed

Failed

-

Transkoding dihentikan secara abnormal.

Failed

Untuk tugas Transkoding, waiting biasanya bukan nilai enum status diskret. Status tersebut disimpulkan dengan menggabungkan status tugas dengan progres transkode.

Patokan kecepatan Transkoding

Penting

Patokan berikut menggambarkan kecepatan pemrosesan tugas Transkoding dalam kondisi uji tipikal setelah pemrosesan aktual dimulai. Patokan tersebut tidak mencakup waktu tunggu antrian, tidak merepresentasikan waktu penyelesaian total, dan bukan merupakan komitmen layanan.

Tabel berikut menunjukkan karakteristik kecepatan pemrosesan untuk algoritma Transkoding berbeda, menggunakan skenario H.264 720p tipikal sebagai referensi:

Algoritma

Patokan kecepatan pemrosesan

Deskripsi

Standard transcoding

Sekitar kecepatan 3x

Hanya mencerminkan kecepatan tahap pemrosesan dalam kondisi tipikal.

Narrowband HD 1.0

Sekitar kecepatan 1,5x

Waktu pemrosesan aktual biasanya lebih lama daripada standard transcoding.

Narrowband HD 2.0

Umumnya jauh di bawah kecepatan 1x

Waktu pemrosesan biasanya melebihi durasi video sumber. Hasil aktual bervariasi.

Penjelasan pengali kecepatan

Pengali kecepatan = kelipatan durasi video yang diproses per satuan waktu pemrosesan

Contoh:
Kecepatan 3x berarti sekitar 3 menit konten video diproses per 1 menit waktu pemrosesan.
Video berdurasi 30 menit, tanpa memperhitungkan waktu tunggu antrian, akan membutuhkan sekitar 10 menit untuk diproses.
Catatan
  • Patokan ini hanya berlaku untuk skenario Transkoding H.264 720p tipikal.

  • Patokan tersebut tidak dapat digunakan untuk memperkirakan waktu penyelesaian tugas total.

  • Resolusi lebih tinggi, kodek lebih kompleks, atau parameter lebih berat biasanya menghasilkan kecepatan pemrosesan lebih rendah.

  • Perbedaan bitrate video sumber, laju frame, format kontainer, dan struktur aliran dapat secara signifikan memengaruhi waktu pemrosesan.

  • Narrowband HD 2.0 biasanya jauh lebih intensif secara komputasi dibandingkan standard transcoding dan Narrowband HD 1.0.

  • Rujuk kueri status tugas atau notifikasi penyelesaian untuk waktu pemrosesan aktual.

FAQ

1. Apakah tugas Transkoding 720p berdurasi 10 menit selalu selesai dalam 3–4 menit?

Tidak selalu.

Patokan "sekitar kecepatan 3x" menggambarkan kecepatan pemrosesan dalam kondisi uji tipikal setelah tugas memasuki tahap pemrosesan aktual. Patokan tersebut tidak mencakup waktu tunggu antrian dan tidak merepresentasikan waktu penyelesaian total di lingkungan produksi.

Waktu yang benar-benar Anda alami sebelum hasil tersedia ditentukan oleh waktu penyelesaian akhir. Jangan gunakan patokan kecepatan pemrosesan untuk memperkirakan jadwal pengiriman.

Jika waktu total melebihi ekspektasi Anda, rujuk bagian troubleshooting umum, atau hubungi dukungan teknis.

2. Mengapa tugas Transkoding saya menunjukkan status Transcoding dengan TranscodeProgress macet di 0?

Untuk tugas Transkoding, Transcoding berarti tugas telah memasuki pipeline Transkoding, tetapi belum berarti Transkoding aktual telah dimulai.

Saat TranscodeProgress = 0, tugas masih dalam tahap waiting. Saat TranscodeProgress > 0, Transkoding aktual sedang berlangsung.

3. Mengapa tugas saya memakan waktu jauh lebih lama daripada patokan, meskipun spesifikasinya serupa?

Kemungkinan penyebabnya meliputi:

  • Tugas menunggu dalam antrian dalam periode panjang sebelum pemrosesan dimulai.

  • Karakteristik file sumber berbeda dari skenario patokan tipikal.

  • Parameter tugas atau konfigurasi templat lebih kompleks daripada pengaturan standar.

  • Fluktuasi workload dalam jendela waktu yang sama meningkatkan waktu penyelesaian total.

Untuk investigasi lebih lanjut, hubungi dukungan teknis dan berikan ID tugas.

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

Tidak selalu.

Waktu tunggu dipengaruhi oleh banyak faktor, termasuk workload dan karakteristik tugas. Peningkatan waktu tunggu saja tidak menunjukkan adanya gangguan layanan. Untuk memastikan status layanan saat ini, hubungi dukungan teknis.

5. Dapatkah saya menggunakan patokan kecepatan pemrosesan untuk berkomitmen pada waktu pengiriman bisnis?

Kami tidak merekomendasikan pendekatan ini.

Patokan kecepatan pemrosesan membantu Anda memahami karakteristik pemrosesan tugas. Patokan tersebut tidak boleh digunakan langsung sebagai jadwal pengiriman produksi, SLA bisnis, atau komitmen kepada pengguna akhir.

Untuk skenario dengan persyaratan waktu ketat, sisipkan waktu buffer dalam arsitektur Anda dan terapkan mekanisme fallback timeout serta degradasi elegan.

6. Dapatkah saya menggunakan model status Transkoding untuk tugas asinkron lainnya?

Tidak selalu.

Bidang Transcoding dan TranscodeProgress dalam contoh Transkoding bersifat spesifik untuk tugas Transkoding.

Untuk tugas editing, Snapshot, sprite sheet, analisis, dan tugas asinkron lainnya, bidang status, indikator progres, dan metode interpretasi mungkin berbeda. Rujuk API kueri dan dokumentasi produk untuk jenis tugas spesifik.

Operasi utama

Ajukan tugas

Setelah Anda mengajukan tugas asinkron melalui API, layanan akan mengembalikan ID tugas.

ID tugas adalah pengidentifikasi unik untuk mengkueri status, menghubungkan notifikasi hasil, dan troubleshooting masalah. Simpan dengan aman.

Notifikasi hasil

Setelah tugas selesai, jika Anda telah mengonfigurasi URL callback, layanan akan secara proaktif mendorong notifikasi hasil. Gunakan callback untuk mendeteksi penyelesaian tugas secara otomatis, tanpa polling terus-menerus.

Panduan callback

  • Gunakan callback sebagai metode utama untuk menerima hasil di lingkungan produksi.

  • Jika URL callback tidak dapat dijangkau, layanan akan mencoba ulang secara otomatis berdasarkan kebijakan yang telah ditentukan.

  • Jika pengiriman gagal setelah beberapa kali percobaan ulang, gunakan API kueri untuk memeriksa status tugas akhir.

  • Notifikasi callback mungkin tertunda atau dikirim lebih dari sekali karena fluktuasi jaringan atau masalah di sisi client.

  • Terapkan pemeriksaan idempotensi dalam penanganan callback Anda, menggunakan ID tugas sebagai kunci.

  • Respons API kueri adalah sumber otoritatif untuk status tugas akhir.

Untuk detail tentang konfigurasi callback dan mekanisme percobaan ulang, lihat Konfigurasi callback.

Kueri tugas

Kueri status dan hasil tugas saat ini berdasarkan ID tugas. Ini berlaku dalam skenario berikut:

  • Anda belum mengonfigurasi notifikasi callback.

  • Anda telah mengonfigurasi callback tetapi ingin memeriksa progres saat ini secara proaktif.

  • Tugas memakan waktu lebih lama dari yang diharapkan.

  • Notifikasi callback gagal dikirim dan Anda memerlukan metode fallback.

Kueri informasi tugas

API kueri terutama mengembalikan status tugas, progres, dan informasi hasil. Jika tugas memakan waktu jauh lebih lama dari yang diharapkan, lakukan investigasi dengan meninjau perubahan status, waktu pengajuan, dan konfigurasi tugas. Jika Anda tidak dapat menentukan penyebabnya, hubungi dukungan teknis dan berikan ID tugas.

troubleshooting umum

Saat tugas memakan waktu lebih lama dari yang diharapkan, ikuti langkah-langkah berikut:

Langkah 1: Periksa apakah tugas telah selesai

Kueri status atau hasil tugas berdasarkan ID tugas:

  • Jika tugas selesai, ambil hasilnya dan evaluasi durasi totalnya.

  • Jika tugas gagal, tinjau kode kesalahan dan pesan kesalahan.

  • Jika tugas masih berjalan, lanjutkan ke langkah berikutnya untuk menentukan apakah tugas berada dalam tahap waiting atau processing.

Langkah 2: Tentukan tahap saat ini berdasarkan jenis tugas

  • Untuk tugas Transkoding: Gabungkan status Transcoding dengan TranscodeProgress untuk menentukan apakah pemrosesan aktual telah dimulai.

  • Untuk tugas asinkron lainnya: Rujuk bidang respons API kueri dan dokumentasi untuk jenis tugas spesifik. Jangan terapkan model tugas Transkoding secara langsung.

Langkah 3: Identifikasi kemungkinan penyebab berdasarkan karakteristik tugas

Gejala

Kemungkinan penyebab

Tindakan yang direkomendasikan

Tidak ada hasil dalam periode panjang

Fluktuasi workload, peningkatan waktu tunggu, gangguan layanan, atau tugas kompleks

Periksa halaman status layanan. Hubungi dukungan teknis jika diperlukan.

Waktu pemrosesan jauh lebih lama daripada tugas tipikal

File sumber kompleks, parameter berat, atau kompleksitas tugas tinggi

Tinjau file sumber dan konfigurasi. Hubungi dukungan jika diperlukan.

Tugas gagal

Masalah file sumber, kesalahan parameter, atau pengecualian pemrosesan

Tinjau deskripsi kode kesalahan dan ikuti langkah remediasi.

Kueri tidak mengembalikan hasil

ID tugas salah atau tugas tidak diajukan berhasil

Verifikasi hasil pengajuan dan ID tugas.

Langkah 4: Informasi yang harus disediakan saat menghubungi dukungan

Untuk membantu dukungan teknis menginvestigasi masalah, berikan informasi berikut:

  • ID tugas.

  • Waktu pengajuan tugas.

  • Jenis tugas (Transkoding, editing, Snapshot, analisis, atau lainnya).

  • Durasi file sumber, resolusi, dan kodek.

  • Konfigurasi templat atau parameter pemrosesan.

  • Apakah tugas diajukan secara Batch.

  • Gejala yang diamati dan cakupan dampaknya.

Pola integrasi yang direkomendasikan

Metode

Deskripsi

Kasus penggunaan

Callback asinkron (direkomendasikan)

Layanan mendorong hasil setelah tugas selesai.

Lingkungan produksi dan alur kerja bisnis langsung.

Polling

Menanyakan status dan hasil tugas secara terjadwal.

Debugging, pengujian, dan fallback saat callback gagal.

Praktik terbaik integrasi

  • Gunakan callback asinkron sebagai metode utama di lingkungan produksi.

  • Hindari polling frekuensi tinggi untuk mengurangi permintaan yang tidak perlu.

  • Terapkan kontrol idempotensi saat mengajukan tugas untuk mencegah pengajuan duplikat.

  • Atur jeda pengajuan Batch untuk menghindari penumpukan antrian jangka pendek.

  • Siapkan pemantauan timeout tugas, peringatan, dan mekanisme intervensi manual.

  • Sediakan waktu buffer yang cukup untuk skenario bisnis kritis dan rancang strategi degradasi elegan.

  • Jangan gunakan patokan kecepatan pemrosesan secara langsung untuk komitmen pengiriman produksi.

SLA dan batas tanggung jawab

  • Jika Anda mencurigai bahwa gangguan layanan menyebabkan penundaan pemrosesan tugas, hubungi dukungan teknis dan berikan ID tugas serta informasi terkait.

  • Ketersediaan layanan, penentuan tanggung jawab, dan cakupan kompensasi diatur oleh perjanjian layanan formal dan SLA.

  • Deskripsi waktu tugas, patokan kecepatan pemrosesan, contoh, dan konten FAQ dalam dokumen ini membantu Anda memahami pemrosesan tugas asinkron. Konten tersebut bukan merupakan komitmen waktu penyelesaian tersendiri, dasar kompensasi layanan, atau jaminan tanggung jawab bisnis.

Tips

Untuk mengurangi dampak fluktuasi latensi tugas asinkron terhadap bisnis Anda:

  • Gunakan penguraian keterkaitan asinkron untuk tugas pemrosesan media dalam desain sistem Anda.

  • Gunakan callback atau kueri status untuk mendeteksi hasil tugas, bukan pemblokiran sinkron.

  • Sediakan waktu buffer ekstra untuk periode puncak, pengajuan Batch, dan tugas kompleks.

  • Terapkan peringatan timeout tugas, prosedur intervensi manual, dan mekanisme fallback bisnis.

Untuk pertanyaan lebih lanjut, rujuk dokumentasi produk terkait.