Upload
Local media file managed file area में आती है, upload और processing पूरी करती है और फिर preview के लिए उपलब्ध होती है।
- नाम
- मुख्य कार्यक्रम master
- Managed path
- Internal disk
- Visibility
- उदाहरण विकल्प: Private
- Format
- Original
फ़ाइल अपलोड से या सीधे Recorder से आ सकती है। उसका नाम, path, description और visibility एक ही जगह बने रहते हैं। वहीं आप मीडिया का preview देख सकते हैं, दूसरा format चाहिए तो अलग converted copy बना सकते हैं, या सत्यापित फ़ाइल को Restreaming अथवा Web Player में भेज सकते हैं। फ़ाइलें डिफ़ॉल्ट रूप से internal disk उपयोग करती हैं; connected Storage वैकल्पिक है।
फ़ाइल का origin दिखाई देता रहता है, जबकि आप उसका record और media जाँचते हैं, तय करते हैं कि दूसरा format चाहिए या नहीं, और अगला product workflow चुनते हैं।
Local media file managed file area में आती है, upload और processing पूरी करती है और फिर preview के लिए उपलब्ध होती है।
Upload से आगे बढ़ेंफ़ाइल अब managed workflow का हिस्सा है। Format, visibility या destination बदलने से पहले उसका record और media review के लिए उपलब्ध रहते हैं।
यह उदाहरण product boundary स्पष्ट रखता है: metadata साफ़ है, Private एक जानबूझकर चुना गया उदाहरण है और internal disk default location बनी रहती है।
Format या transcoding settings में बदलाव background rewrite शुरू करता है और अलग managed copy बनाता है। Original को बदला नहीं जाता।
File Manager media record सुरक्षित रखता है, जबकि हर downstream product अपना runtime और access policy नियंत्रित करता है।
पूरा हुआ मीडिया picture, audio और duration की जाँच के लिए खुलता है।
पूरा हुआ मीडिया picture, audio और duration की जाँच के लिए खुलता है।
फ़ाइलें डिफ़ॉल्ट रूप से encrypted internal disk उपयोग करती हैं। दूसरा tier चाहिए तो Callaba object storage को metadata के साथ register करता है और managed copies के लिए POSIX-compatible namespace mount करता है।
यह तालिका default file behavior को वैकल्पिक Storage और downstream product choices से अलग करती है। चुनने योग्य formats और settings के लिए installed Callaba interface ही authoritative है।
| क्षमता | समर्थित व्यवहार | सत्यापन का तरीका |
|---|---|---|
| फ़ाइल के origin | Uploaded files, finalized recordings और अन्य managed processing results। | Valid result अपेक्षित origin, नाम और managed path के साथ दिखाई देता है। |
| Default location | External Storage configure किए बिना encrypted internal disk उपलब्ध है। | Non-critical upload या छोटी recording पूरी होती है, preview की जा सकती है और कोई Storage जोड़ने से पहले भी manageable रहती है। |
| Managed metadata | जहाँ उपलब्ध हों वहाँ नाम, description, path, visibility, format, processing settings, duration, size और timestamps। | Saved record और completed media की identity, duration, size और format मेल खाते हैं। |
| Visibility | Public और Private स्पष्ट file-record choices हैं। | Playback जोड़ने से पहले visibility की समीक्षा होती है; player authorization अलग control रहता है। |
| Upload | Progress और pending file record के correlation id के साथ binary upload। | Preview या downstream selection को ready मानने से पहले valid upload पूरा होता है। |
| Preview | पूरा managed media operator inspection के लिए खोला जा सकता है। | वास्तविक फ़ाइल अपेक्षित picture, audio, duration और seek behavior देती है। |
| Output formats | जहाँ चुना गया processing path समर्थन करे वहाँ managed output families में MOV, MP4, AVI, FLV, MP3, HLS, MKV और MPEG-TS शामिल हैं। | Installed format selector authoritative है और completed result उसके चुने container व tracks से मेल खाता है। |
| Format rewrite | Format या transcoding settings बदलने पर background rewrite शुरू हो सकता है, जो अलग managed copy बनाता है। | Progress पूरी होती है, original मौजूद रहता है और नई copy माँगे गए format में खुलती है। |
| Processing state | Background worker statistics bitrate, FPS, media time, speed और progress दिखा सकते हैं। | Completion से पहले progress आगे बढ़ती है, पर finished file फिर भी अलग से खोली जाती है; केवल runtime state फ़ाइल को सत्यापित नहीं करती। |
| Web Player handoff | सत्यापित managed file को browser playback source के रूप में चुना जा सकता है। | सटीक player URL शुरू होता है, चलता रहता है और अपना configured audience access लागू करता है। |
| Restreaming handoff | Managed file को file-based Restreaming input के रूप में चुना जा सकता है। | Output job सही फ़ाइल पढ़ता है और tested media profile अपने destination तक पहुँचाता है। |
| वैकल्पिक connected Storage | Object storage और metadata service को register, format और managed POSIX-compatible namespace के रूप में mount किया जा सकता है। | छोटी File Manager copy पूरी होती है और mounted managed path से वापस पढ़ी जाती है। |
| Copy progress | File Manager managed file को internal या configured external Storage में copy करके percentage और completion state दिखा सकता है। | Completion और destination read-back से तय होता है कि source हटाने पर विचार किया जा सकता है। |
| Encryption at rest | Internal disk और वैकल्पिक connected Storage पर managed files at rest encrypted रहती हैं; raw backing blocks अकेले playable media expose नहीं करते। | Normal और recovery access raw storage blocks के बजाय managed metadata और file path से होती है। |
| Lifecycle API | Create/upload, count/list, get, update, remove, rewrite status, copy और copy-progress workflows documented हैं। | Production media automate करने से पहले non-critical file आवश्यक lifecycle स्थापित करती है। |
| Deployment | Callaba cloud deployment या self-hosted Linux; capacity file sizes, concurrent processing और storage design से तय होती है। | चुने गए node और disks को वास्तविक upload, conversion, playback और copy mix के साथ load-test किया जाता है। |
Callaba cloud deployment एक managed starting point देता है। Self-hosting में infrastructure, network और data location आपकी टीम के नियंत्रण में रहते हैं।
Callaba node encrypted internal disk के साथ शुरू होता है; connected Storage तभी जोड़ा जाता है जब वर्कफ़्लो को दूसरे tier की आवश्यकता हो।
AWS में Callaba लॉन्च करेंApplication, encrypted media और वैकल्पिक storage connections आपकी टीम द्वारा संचालित infrastructure पर रहते हैं।
Callaba self-hosted इंस्टॉल करेंInterface workflow समझ लेने के बाद documented endpoints upload और file creation, listing और inspection, metadata updates, converted copies, processing state, वैकल्पिक Storage copies और removal संभालते हैं।
Cloud File Manager वह जगह है जहाँ uploaded, recorded और processed media managed workflow का हिस्सा बनता है। File record उसके path, description, visibility, format, processing state और downstream handoffs को एक साथ रखता है।
नहीं। फ़ाइलों की default location internal disk है। Connected Storage वैकल्पिक है और तभी जोड़ा जाता है जब वर्कफ़्लो को दूसरा managed storage tier चाहिए।
हाँ। Format या transcoding settings बदलने पर background rewrite शुरू होता है और अलग converted copy बनती है। Original अपने managed file record में बनी रहती है, जबकि File Manager नए result की progress दिखाता है।
हाँ। सत्यापन के बाद फ़ाइल Web Player या file-based Restreaming workflow के लिए managed input बन सकती है। Delivery और audience access फिर भी संबंधित downstream job के ही नियंत्रण में रहते हैं।
हाँ। Callaba managed files को internal disk और वैकल्पिक connected Storage दोनों में at rest encrypt करता है। Disk या backing object blocks की raw access भर से पढ़ने योग्य media file नहीं मिलती; managed metadata और access path भी आवश्यक हैं।
Callaba object storage को metadata service के साथ जोड़कर परिणाम को managed filesystem namespace की तरह mount करता है। Product modules परिचित file paths उपयोग कर सकते हैं, जबकि backing bucket implementation detail रहता है और product workflow के रूप में expose नहीं होता।
नहीं। Visibility managed file record का हिस्सा है। Web Player authorization और audience access अलग downstream निर्णय हैं, जिन्हें viewer URL साझा करने से पहले जाँचना अभी भी ज़रूरी है।
एक छोटा upload या recording पहले file record, visibility, preview और metadata स्थापित कर सकता है। उसके बाद वर्कफ़्लो के ज़रूरी अगले चरण को जाँचें: converted copy, Web Player, Restreaming या वैकल्पिक Storage।