क्या संस्करण नियंत्रण में वीडियो उत्पादन वर्कफ़्लो का एक हिस्सा है?


20

मैं एक सॉफ्टवेयर डेवलपर हूं और मुझे फोटोग्राफी (चार साल के लिए) और वीडियो प्रोडक्शन (केवल कुछ महीनों के लिए) में दिलचस्पी है।

सॉफ्टवेयर विकास में ■, एक महत्वपूर्ण नियम है जो प्रत्येक डेवलपर प्रत्येक परियोजना पर अनुसरण करता है : सब कुछ संस्करण नियंत्रण में होना चाहिए : स्रोत कोड, कॉन्फ़िगरेशन फ़ाइलें, डेटाबेस स्कीमा, प्रलेखन - सब कुछ जो खरोंच से परियोजना का निर्माण करने में सक्षम बनाता है। इसके दो सुखद परिणाम हैं:

  1. एक आपदा की स्थिति में जब आप संस्करण नियंत्रण भंडार को छोड़कर सब कुछ खो देते हैं, तो आपको यह जारी रखने में सक्षम होना चाहिए जैसे कि कुछ भी नहीं हुआ।

  2. कुछ बेवकूफ बदलाव की स्थिति में जो परियोजना को नकारात्मक रूप से प्रभावित करता है, डेवलपर पहले के संशोधन में वापस आ सकता है।

■ फ़ोटोग्राफ़ी में, मेरे द्वारा फ़ोटो में किए गए हर परिवर्तन को लाइटरूम कैटलॉग में हमेशा के लिए संग्रहीत किया जाता है , जिससे किसी भी क्षण पिछली स्थिति में वापस आना संभव हो जाता है। आभासी प्रतियों की सुविधा के साथ, लाइटरूम वह भी करने में सक्षम होता है जिसे संस्करण नियंत्रण में एक शाखा कहा जाता है : कुछ अलग परीक्षण करने की क्षमता, और या तो दोनों परिणाम रखें या बाद में उनमें से एक को हटा दें।

कैटलॉग RAW फ़ोटो को स्वयं संग्रहीत नहीं करता है, लेकिन वे वैसे भी बदलते नहीं हैं।

वीडियो उत्पादन में ■, चीजें अलग लगती हैं। मैं के साथ काम Premiere Pro, After Effects और Soundbooth।

  • कोई भी इतिहास को स्थायी रूप से संग्रहीत नहीं करता है: अगर मैं गलती से एक कार्रवाई करता हूं और इसे केवल अगले दिन नोटिस करता हूं, तो पिछले संस्करण को पुनर्प्राप्त करने का कोई तरीका नहीं है।

  • साउंडबॉथ भी सीधे WAV फ़ाइलों को बदलता है, जिसे संशोधित करने के लिए मूल रिकॉर्डिंग को अलग रखने के लिए अतिरिक्त प्रयास की आवश्यकता होती है।

  • संस्करण नियंत्रण शायद ही कभी उल्लेख किया गया है, और मुझे यह बताने में किसी को भी नहीं मिला कि वह वास्तव में अपने वर्कफ़्लो में संस्करण नियंत्रण का उपयोग कैसे करता है। इसके अलावा, किसी का उल्लेख नहीं है कि कौन से संस्करण नियंत्रण का उपयोग किया जाना चाहिए, और चूंकि अधिकांश संस्करण नियंत्रण प्रणाली पाठ फ़ाइलों के लिए अनुकूलित हैं, न कि बाइनरी वाले, यह एक अतिरिक्त चुनौती बनाता है।

  • Video.SE में या टैग नहीं हैं।

इस प्रकार, मेरे दो प्रश्न हैं:

  1. क्या संस्करण नियंत्रण में वीडियो उत्पादन के साथ काम करने वाले व्यक्ति के वर्कफ़्लो का एक हिस्सा है? यह कैसे एकीकृत है?

  2. Adobe क्रिएटिव क्लाउड की मदद से पलायन होगा? क्या कोई विशिष्ट विशेषताएं हैं जो क्रिएटिव क्लाउड में, Premiere Pro के बाद या प्रभाव परियोजना के क्रमिक संशोधनों को ट्रैक करने की अनुमति देती हैं?

टिप्पणी: ऑफ-टॉपिक उत्तरों से बचने के लिए, मैं इस बात पर प्रकाश डालता हूं कि मेरा प्रश्न बैकअप से असंबंधित है , और विशेष रूप से डेटा के ऑन-साइट / ऑफ-साइट बैकअप न होने पर, मेरे काम के लगातार संशोधनों को संग्रहीत करने के बारे में है।

जवाबों:


10

Git के अर्थ में संस्करण नियंत्रण वीडियो की दुनिया में बहुत व्यावहारिक नहीं है। आपको हर ऑडियो और वीडियो टूल के लिए एक विशिष्ट संस्करण नियंत्रण उपकरण बनाने की आवश्यकता होगी क्योंकि सभी अपने स्वयं के प्रोजेक्ट प्रारूपों के साथ काम करते हैं। लेकिन इन प्रारूपों को पढ़ने में सक्षम होना सिर्फ एक बात है, फिर आपको डिफरेंशियल दिखाने के लिए उस टूल के रेंडर इंजन की भी जरूरत है।

हालांकि ये सभी उपकरण एक गैर-विनाशकारी तरीके से काम करते हैं जब तक कि आप कुछ सामान को पूर्व-रेंडर न करें (तुलना करें कि आपके कोड के एक टुकड़े / डीएल / परिवाद को संकलित करना और उस पर अभी से काम करना), तो आप बेकार में वापस जा सकते हैं एक पुराने संशोधन के लिए ctrl + z या कुछ प्रोग्राम्स में इतिहास टूल का उपयोग करके।

हालांकि उप संस्करणों को सहेजना आमतौर पर जाने का तरीका है। जैसे उनके उत्तर में वर्णित स्टिब या मैन्युअल रूप से ऐसा करना।

मुझे कुछ ऐसा करना पसंद है और हर सॉफ्टवेयर के साथ अच्छी तरह से काम करना मेरी प्रोजेक्ट फाइलों (नो सोर्स फुटेज) को ड्रॉपबॉक्स में डाल रहा है। यदि आपके पास कुछ तेज़ अपलोड गति (~ 1 Mbit / s) है और आपकी प्रोजेक्ट फ़ाइल 100MB + नहीं है, तो अगली बार सहेजने से पहले आप अपनी परियोजना अपलोड कर सकते हैं। एक औसत Premiere / AE / FCP परियोजना लगभग 10-20MB है तो आपकी हाल ही में सहेजी गई फाइलें 1-2 मिनट में अपलोड हो जाएंगी। और भी तेजी से अगर आपके पास अधिक अपलोड बैंडविड्थ है।

फिर अगर आपको वापस जाना है तो आप अपनी फ़ाइलों के ड्रॉपबॉक्स के इतिहास तक पहुँच सकते हैं और उस संशोधन को डाउनलोड या पुनर्स्थापित कर सकते हैं। ड्रॉपबॉक्स एक भुगतान किए गए खाते पर हमेशा के लिए फ़ाइल संशोधन को बचाता है (* कम से कम जब उनके पास पैक चूहा विकल्प था, अब इसका एक साल मुझे लगता है) और एक मुफ्त खाते पर 30 दिनों के लिए। मुझे यकीन है कि अन्य क्लाउड होस्टर्स हैं जो समान सुविधाएं प्रदान करते हैं। यह बिट के सुपर सीमित संस्करण का उपयोग करने जैसा है जो बाइनरी फ़ाइलों को बहुत अच्छी तरह से संभालता है और सिरदर्द से मुक्त है। इसका यह लाभ है कि आप फ़ोल्डर को टन फ़ाइलों के साथ अव्यवस्थित नहीं करते हैं और उसी समय बैकअप होता है।

अधिकांश क्लाउड होस्टर्स टीम सदस्यता भी प्रदान करते हैं ताकि आप कई संपादकों के साथ काम कर सकें। या आप टीम के अन्य सदस्यों के साथ प्रोजेक्ट फ़ोल्डर साझा करते हैं।


ड्रॉपबॉक्स स्टोर फ़ाइल संशोधन हमेशा के लिए? फिर क्या होगा अगर आपके पास 800 संशोधनों के साथ 5 जीबी वीडियो फ़ाइल थी?
पेसियर

मैंने उत्तर को थोड़ा संपादित किया। पुराने पैक चूहे के विकल्प के साथ यह वास्तव में हमेशा के लिए अब एक वर्ष का था, और हाँ आप वही कर सकते हैं जो आपने अभी वर्णित किया है लेकिन जैसे मैंने अपने उत्तर में लिखा है कि इसमें स्रोत (जैसे वीडियो / छवि / ऑडियो) फ़ाइलें नहीं हैं, केवल आपके प्रोजेक्ट फ़ाइलें। जब तक आपके पास एक गीगाबिट कनेक्शन नहीं होता है जो बदलते स्रोत के संस्करणों को रखने या फ़ाइलों को प्रस्तुत करने के लिए बहुत ही अव्यावहारिक होगा।
पीटीएस

1
यदि आपको अलग-अलग रूपों की आवश्यकता है तो आपको केवल फॉर्मेट को समझने के लिए अपने VCS की आवश्यकता है। यह उम्मीद करने के लिए थोड़ा सा है।
पीटर कॉर्डेस

1
इसलिए आप आसानी से अपनी परियोजना फाइलों को नियंत्रित कर सकते हैं, क्योंकि 10-20MB बाइनरी डेटा की कोई समस्या नहीं है। आपको यह बताने के लिए कि आपकी फ़ाइल सहेजने के समय क्या स्थिति थी, यह बताने के लिए आपको उपयोगी प्रतिबद्ध संदेश लिखने की आवश्यकता है। यदि आप भाग्यशाली हैं, तो छोटे संपादन परिवर्तन अक्सर प्रोजेक्ट फ़ाइल में अधिकांश बिट्स को नहीं बदलते हैं, और git का डेल्टा संपीड़न हर कमिट के लिए पूर्ण 10MB से बहुत कम उपयोग करेगा। और फिर बैकअप git pushआपके बैकअप सर्वर के लिए उतना ही आसान है। (किस वीडियो स्वामी के प्रोजेक्ट के साथ जाने के लिए किसी अन्य विधि के साथ, किस प्रोजेक्ट के साथ, शायद स्रोत फ़ाइलों के md5sums?)
पीटर कॉर्डेस

यदि आपका प्रोजेक्ट एक बड़ी परियोजना फ़ाइल के साथ समाप्त होता है, तो आप आदर्श स्थिति को पूरा करते हैं, आप अपने कनेक्शन के आधार पर अक्सर संशोधन अपलोड नहीं कर सकते हैं। क्लाउड स्टोरेज सॉफ्टवेयर पूरी तरह से तराशता है, आखिरकार परेशानियों में चलेगा। हालांकि कमिट मैसेज निश्चित रूप से गिट के लिए एक प्लस है।
पीटीएस

6

बस पिछली प्रतिक्रियाओं को जोड़ने के लिए: जबकि वीडियो की दुनिया के लिए Git जैसा कुछ नहीं है, डिजिटल एसेट मैनेजमेंट / मीडिया एसेट मैनेजमेंट टूल हैं जो कम या ज्यादा एक ही काम कर सकते हैं - संस्करण नियंत्रण और अनुमति / उपयोगकर्ता प्रबंधन (वे भी करते हैं) बहुत अधिक, जैसा कि वे वास्तव में आपके मीडिया के लिए पुस्तकालयों के रूप में निर्मित हैं)। वर्षों के लिए, मैंने Apple के फाइनल कट सर्वर ऐप (अब अप्रचलित) का उपयोग किया, जो कि एक छोटी पोस्ट सुविधा में फाइनल कट सूट (फाइनल कट प्रो 7, साउंडट्रैक प्रो, आदि) के साथ एकीकृत है।

हमने प्रोजेक्ट फ़ाइलों पर संस्करण नियंत्रण और ब्रांचिंग के लिए इसका उपयोग किया, जिससे कई संपादकों को अपेक्षाकृत एक ही परियोजना पर काम करने की अनुमति मिली। क्योंकि यह एक Apple उत्पाद था, इसे अंतिम कट प्रो के साथ उपयोग करने के लिए डिज़ाइन किया गया था और इसलिए इसे पढ़ सकते हैं और साथ काम कर सकते हैं FCP परियोजना फाइलें बहुत आसानी से। यहां तक ​​कि इसे दिया गया, फाइनल कट सर्वर का संस्करण नियंत्रण संपूर्ण प्रोजेक्ट फ़ाइल के पिछले संस्करणों को सहेजने पर निर्भर करता था, यह अलग-अलग उपयोग नहीं करता था। मैं किसी भी डीएएम के बारे में नहीं जानता, जो इस कारण से है कि एक पिछला उत्तर पहले से ही बताया गया है - वैसे बहुत अधिक मालिकाना प्रारूप हैं (भले ही, विडंबना यह है कि उनमें से कई अब उन प्रोजेक्ट फ़ाइल स्वरूपों के लिए एक्सएमएल की रीढ़ के रूप में भरोसा करते हैं। )।

एफसीएस महान था क्योंकि यह अपेक्षाकृत सस्ती थी। Premiere Pro के लिए वास्तव में कुछ भी अनुरूप नहीं था। आजकल, दुर्भाग्य से, आपको समान क्षमताओं को प्राप्त करने के लिए बदलाव का एक अच्छा हिस्सा सौंपने की आवश्यकता होगी - ज्यादातर क्योंकि ये उपकरण वास्तव में पोस्ट सुविधाओं के लिए डिज़ाइन किए गए हैं, एक भी संपादक नहीं। उन्हें संभावित महत्वपूर्ण एकीकरण / सेटअप की भी आवश्यकता होती है।

यहां कुछ विकल्प दिए गए हैं (मेरा इनमें से किसी भी कंपनी के साथ कोई संबंध नहीं है, यह पूरी तरह से एक समान समाधान की तलाश में मेरे शोध पर आधारित है):


5

संस्करण नियंत्रण का वास्तव में वीडियो संपादन में उतना स्थान नहीं है क्योंकि यह प्रकृति द्वारा गैर-विनाशकारी है। किसी भी NLE (नॉन-लीनियर वीडियो एडिटर) के मूल में, आउटपुट वास्तव में एक एडिटिंग डिसिजन लिस्ट या EDL के रूप में जाना जाता है। यह लाइटरूम में इतिहास के लिए अत्यंत अनुरूप है क्योंकि यह इतिहास उन सभी परिवर्तनों का रिकॉर्ड है जो क्रम में लागू किए गए हैं।

NLE स्रोत क्लिप से काम करते हैं। वे उन क्लिपों की शुरुआत और समाप्ति बिंदुओं को उन्हें एक समयरेखा में रखने के लिए लेते हैं और फिर उन परिसंपत्तियों को किसी दिए गए क्रम में (प्रभावों की नियुक्ति के आधार पर) लागू किया जा सकता है, हालांकि ये सभी संपादन निर्णय हैं और मक्खी पर लागू होते हैं ( या संभवतः अस्थायी पूर्वावलोकन फ़ाइलों के लिए प्रदान किया गया)। अंतिम आउटपुट रेंडर स्रोत क्लिप में पूरे EDL को लागू करने का परिणाम है।

यदि आप चाहते हैं तो आप EDL के पिछले संस्करण में वापस जाने में सक्षम होने के लिए परियोजना के एक संस्करण को बचा सकते हैं, लेकिन यह आम तौर पर तब तक आवश्यक नहीं है जब तक कि आप अनुक्रम को संपादित करने के लिए वैकल्पिक दृष्टिकोण की कोशिश करने के लिए बहुत जानबूझकर शाखाओं में बँटे नहीं हैं ( जिस स्थिति में उस समय की एक प्रति अक्सर एक बेहतर विकल्प होती है। "


यहां "गैर-विनाशकारी" और एनएलई से आपका क्या मतलब है?
पेसियर

एनएलई एक गैर-रेखीय संपादक है (अधिकांश वीडियो संपादन सॉफ्टवेयर के लिए तकनीकी नाम।) गैर-विनाशकारी का अर्थ है कि परिवर्तन से परिसंपत्तियों का विनाश नहीं होता है। यह बनाने के लिए परिवर्तनों की एक सूची बना रहा है, जो मूल रूप से वही चीज है जो संस्करण नियंत्रण करता है। जब आप कोड में परिवर्तन करते हैं, तो यह विनाशकारी होता है क्योंकि आपके नए परिवर्तन आपके पुराने को नष्ट कर देते हैं। एक एनएलई के साथ, आपकी परिसंपत्तियां सभी अनछुए रहती हैं और आप बस उपयोग करने के लिए अनुभागों की एक सूची को संशोधित कर रहे हैं और लागू करने के लिए फ़िल्टर करते हैं।
ए जे हेंडरसन

तो क्या आपका मतलब है कि हम वीडियो एडिटिंग प्रोग्राम "रिवर्ट टू वर्जन 2.5" को बता सकते हैं, एबिट को एडिट कर सकते हैं, फिर इसे "वर्जन 7 पर वापस लाएं" और यह ऐसा करने में सक्षम है?
पचेरियर

1
नहीं, उसका मतलब है कि आपके पास अभी भी आपका मास्टर वीडियो है। धारणा यह है कि आपके द्वारा पहले किए गए प्रभावों / कटौती को पुन: प्रस्तुत करना कठिन नहीं है, या कि वीसीएस के साथ परियोजनाओं की फाइलों को सहेजना संपादित निर्णयों को फिर से इनपुट करने की तुलना में अधिक काम होगा। यदि ऐसा नहीं है, तो निश्चित रूप से, संस्करण आपकी परियोजना फ़ाइलों को नियंत्रित करता है। यद्यपि विभिन्न शाखाओं से परिवर्तनों को मर्ज करने की क्षमता के बिना, यह संभवतः किसी भी सटीक फ्रेम संख्या को लिखने के लिए अधिक उपयोगी है जो यह पता लगाने में आपको एक लंबा समय लगा कि एक कट, या कुछ के लिए सही जगह थी।
पीटर कॉर्डेस

3

यदि आप इसे वरीयताओं में सक्षम करते हैं After Effects और Premiere स्वचालित रूप से परियोजना फाइलों की वृद्धिशील बचत करता है। स्वत: सहेजना प्राथमिकताएँ

इन वृद्धिशील बचत का उपयोग पिछले संस्करणों में वापस करने के लिए किया जा सकता है, जो कि संस्करण नियंत्रण के एक बहुत ही बुनियादी कार्यान्वयन की तरह है (आप 5 से संस्करणों की संख्या में वृद्धि करना चाह सकते हैं)। FCP में "पिछले संस्करण से पुनर्स्थापना" फ़ंक्शन बनाया गया है, जो उस समय के लिए अच्छा है जब यह आपकी प्रोजेक्ट फ़ाइलों को मैंग करता है। प्रभाव के बाद (लेकिन प्रीमियर के पास नहीं है, आंकड़ा जाने) एक परियोजना को बढ़ाने की क्षमता। मैं यह हर समय उपयोग करता हूं जब मैं एक परियोजना में बड़े बदलाव कर रहा हूं, और मुख्य ट्रंक को वापस करने में सक्षम होना चाहता हूं, इसलिए बोलने के लिए।

अतिरिक्त नियंत्रण के लिए, आप सोच सकते हैं कि फ़ोल्डर का प्रबंधन करने के लिए संस्करण नियंत्रण सॉफ्टवेयर का उपयोग करें, जहां आप अपनी परियोजना की फाइलें और ऑटो-सेव रखते हैं, इसलिए संपादक वर्तमान कट की जांच करेंगे और परिवर्तन करेंगे, जब तक कि सभी मीडिया केंद्रीय रूप से सुलभ या कॉपी नहीं हो जाते। एक ही रिश्तेदार पथ में हर किसी की मशीनों पर। यह आपको कांटे और अन्य लोगों के संपादन को विलय करने की अनुमति नहीं देगा, जैसे आप कोड के साथ कर सकते हैं - जो कि एक दिलचस्प विशेषता होगी (मैं कहूंगा कि इसे Adobe की एक्सटेंडस्क्रिप्ट स्क्रिप्टिंग के साथ लागू किया जा सकता है, जब तक कि आपके कौशल फिर से लिखने के लिए हैं। जावास्क्रिप्ट में जावास्क्रिप्ट या एसवीएन)।


1
हाँ, अंतर करने और विलय करने के लिए, या तो आपके VCS को आपकी NLE की फाइलों को समझना होगा, या NLE को अंतर / मर्ज प्रदान करना होगा। (उदाहरण के लिए, एक प्रोग्राम को देखते हुए, जो एक प्रोजेक्ट फ़ाइल में परिवर्तन को मर्ज कर सकता है, जिसे एक सामान्य पूर्वज दिया गया है, मुझे लगता है कि आप इसका उपयोग करने के लिए गिट सेट कर सकते हैं git mergetool, संशोधित परियोजना फाइलों वाले पेड़ों के कमिट्स को मर्ज करने में सक्षम होने के लिए।)
पीटर कॉर्डेस

आप संभवतः अपने सभी प्रोजेक्ट आइटमों के सभी गुण प्राप्त करके और फ़ाइल में डेटा सहेजकर अपनी वर्तमान परियोजना को 'सहेजने' के लिए एक्सटेंडस्क्रिप्ट का उपयोग कर सकते हैं। लेकिन यहां तक ​​कि एक बड़ी परियोजना के लिए जिसे करने में लंबा समय लग सकता है। यदि आपने ऐसा किया है तो आप संभवतः एक संस्करण नियंत्रण प्रणाली का निर्माण कर सकते हैं।
stib

3

एक लंबी अवधि के वीडियो पेशेवर के रूप में, मैं इस तथ्य पर ध्यान दे सकता हूं कि वीसीएस के हल्के, मजबूत, पारदर्शी और खुले रूप की आवश्यकता मीडिया के बहुसंख्यक सदस्यों की कमी है। हालाँकि यह समस्या बहुआयामी है और एक सांस्कृतिक और साथ ही एक तकनीकी है।

परंपरागत रूप से हम सॉसेज फैक्ट्री में काम कर रहे हैं, जैसे कि कोई प्रोजेक्ट स्क्रिप्ट से ग्रीनलाइट होता है, प्रोडक्शन में जाता है, एक बार लपेटने के बाद पोस्ट-प्रोडक्शन में चला जाता है और फिर एक अंतिम आउटपुट डिस्ट्रीब्यूशन आर्म को डिलीवर कर दिया जाता है, जो फिर डिवाइस / प्लेटफॉर्म आउटपुट को स्पिन करता है ।

आजकल यह कारखाना जैसा दृष्टिकोण एक भ्रम है जहां उत्पादन और वितरण के बीच का हाथ विशेष रूप से स्पष्ट नहीं है। विभिन्न भाषाओं / बाज़ारों के लिए कट / एडिट के साथ बहुत कुछ आगे और पीछे होता है, उदाहरण के लिए नवीनतम प्रारूप के लिए फिर से मास्टर करना। फिर विपणन उद्देश्यों के लिए अंतिम संस्करणों तक पहुंचने की आवश्यकता है ... परिणामस्वरूप न केवल दूरदराज के दलों की आवश्यकता है, बल्कि वे लोग जो कभी भी एक सूचीबद्ध, निश्चित समझ नहीं पाते हैं कि उन्हें किस संस्करण पर काम करने की आवश्यकता है। यह न केवल मास्टर एन्कोड करने के लिए बल्कि विभिन्न बाजारों के लिए उस मास्टर के सभी संस्करणों के साथ-साथ प्रत्येक मास्टर को बनाने के लिए उपयोग की जाने वाली संपत्ति के संस्करणों तक फैली हुई है।

केवल अब मीडिया टेक समुदाय इस बात पर उलझे हुए हैं कि वास्तव में एक संस्करण क्या है और विभिन्न वर्कफ़्लो और चिंताओं के असंख्य होने के कारण नियमित रूप से इस पर बहस होती है। मैं इसे एक कार्यशील संस्करण और एक वितरण संस्करण के रूप में तोड़ता हूं। एक संग्रह फ़ाइल प्रारूप बनाकर वितरण के भीतर इसे मापने का प्रयास किया जाता है जो संस्करणों को अपने भीतर ट्रैक करता है (इस तथ्य का मुकाबला करने के लिए कि कई उपकरण, प्लेटफ़ॉर्म आदि हैं) - इसे इंटरप्रेन्योर मास्टर प्रारूप (आईएमएफ) कहा जाता है - भ्रमित होने की नहीं बैंक) और SMPTE के माध्यम से चलाया जा रहा है। इसके बारे में अच्छी बात यह है कि यह डिजिटल परिसंपत्ति प्रबंधन प्रणालियों के असंख्य (जो इसे समर्थन करना चाहते हैं) के बीच अंतर प्रदान करने के लिए बढ़ रहा है जो कि वहां हैं - कुछ स्टूडियो मुझे पता है कि सैकड़ों में संख्या में संपत्ति प्रबंधन प्रणाली है - यह आंतरिक रूप से बाहरी हैंडऑफ़ के लिए उन्हें अकेले जाने में मदद करें। बेशक इसका उपयोग उत्पादन के माहौल के भीतर नहीं किया गया है, फिर भी इसे देखते हुए इसे एक आर्काइव स्तर के प्रारूप के रूप में तैयार किया गया है (नेटफ्लिक्स अब इसका उपयोग करता है)। यह भी बहुत आसान फ़ाइल है, इसे बनाने का कोई आसान तरीका नहीं है जब तक कि आपके पास उपकरण में निवेश करने के लिए आवश्यक पूंजी न हो। नेटफ्लिक्स ने एक ओपन सोर्स टूल सेट जारी किया जो पढ़ने की क्षमता प्रदान करता है जो अच्छा है। यह भी बहुत आसान फ़ाइल है, इसे बनाने का कोई आसान तरीका नहीं है जब तक कि आपके पास उपकरण में निवेश करने के लिए आवश्यक पूंजी न हो। नेटफ्लिक्स ने एक ओपन सोर्स टूल सेट जारी किया जो पढ़ने की क्षमता प्रदान करता है जो अच्छा है। यह भी बहुत आसान फ़ाइल है, इसे बनाने का कोई आसान तरीका नहीं है जब तक कि आपके पास उपकरण में निवेश करने के लिए आवश्यक पूंजी न हो। नेटफ्लिक्स ने एक ओपन सोर्स टूल सेट जारी किया जो पढ़ने की क्षमता प्रदान करता है जो अच्छा है।

वर्किंग वर्जन या प्रोडक्शन लेवल वाइज मुझे लगता है कि वीसीएस प्रदान करने की जरूरत है (जैसे कि शायद git का एक संशोधित रूप) जो किसी को भी काम करने की सुविधा प्रदान करने के लिए बड़े या छोटे किसी भी चीज का उपयोग नहीं कर सकता है। मीडिया फाइलें बेशक स्वैपिंग कोड या पुस्तकालयों से बहुत बड़ी होती हैं लेकिन उन फाइलों पर किए गए निर्णय प्रमुख घटक होते हैं। अगर मैं केवल 'file_Final_FINAL_MASTER_version3.mxf' नामकरण सम्मेलनों के नामकरण सम्मेलनों से बचने के लिए दूरस्थ रूप से काम करना चाहता हूं, तो नामकरण परंपराएं जो आगे और पीछे स्वैप हो जाती हैं।


2

मेरे पास एक ही सवाल था, व्यापार से एक सॉफ्टवेयर इंजीनियर होने के नाते, फ़ोटोशॉप काम के बारे में सोच रहा था।

हम वीडियो एडिटिंग प्रोग्राम "रिवर्ट टू वर्जन 2.5" को बता सकते हैं, थोड़ा एडिट कर सकते हैं, फिर इसे "वर्जन 7 में रिवर्ट करें" बता सकते हैं और यह करने में सक्षम है?

मैंने पाया कि फ़ोटोशॉप ने मुझे इतिहास में एक नामित संस्करण सेट करने दिया है, और मुझे लगता है कि फ़ाइल में सहेजा गया है ...? संशोधन के लिए (इतिहास सूची में प्रविष्टियाँ) जिनका नाम नहीं है, नोड्स प्रदर्शन से खो जाते हैं जब एक संपादन पिछली जगह (ब्रांचिंग) के लिए किया जाता है और कोई भी रिफ्लेक्ट उजागर नहीं होता है।

Premiere के नए संस्करणों को एक समान इतिहास लॉग लगता है और मैं अनुमान लगा रहा हूं कि यह एक ही आंतरिक वास्तुकला की ओर विकसित हो रहा है, जहां प्रत्येक परिवर्तन उस परियोजना की एक और प्रति है जो पिछले में सबसे अधिक सांकेतिक रूप से साझा करता है। यदि इतिहास में ऐसी चौकियाँ हैं जिन्हें सहेजा गया है, तो यह एक git store की तरह है: प्रत्येक संस्करण में सेगमेंट परिभाषाओं के नीचे अंतर्निहित तत्वों के संदर्भ (साझा) शामिल हैं। जैसा कि वीडियो स्वयं फ़ाइल में नहीं है, यह आकार में थोड़ी वृद्धि के साथ अधिक से अधिक संस्करण बढ़ने के लिए अच्छी तरह से उधार देता है।

मैंने एक संगोष्ठी देखी जहां फ़ोटोशॉप विकास टीम के किसी व्यक्ति ने वास्तुकला को समझाया। ऐसा लगता है कि आपके द्वारा देखी जाने वाली इतिहास प्रविष्टियाँ गिट संस्करणों के अनुरूप हैं, जैसे कि गिट डिस्प्ले। संस्करण का नामकरण एक जीआईटी टैग के समान है। आप इसे इंगित करके किसी भी दृश्य संशोधन को रीसेट कर सकते हैं, और वापस भी रीसेट कर सकते हैं। लेकिन इतिहास में खुद को डाला गया कोई भी बदलाव करना एक पूर्ण ताज़गी (शिफ्ट या ctrl F5) करने जैसा है - आप वर्तमान शाखा प्रमुख या नामित टैग से नीचे जो भी जंजीर नहीं है उसे खो देते हैं (लेकिन मुझे लगता है कि क्लोन-सोर्स संदर्भ जैसी चीजें अभी भी हैं अब-अनदेखी संस्करण की ओर इशारा करते हैं)।

लेकिन ऐसा नहीं है कि मैं सुझाव देने के लिए लिख रहा हूं। मैं NAS वॉल्यूम सेट करता हूं जहां मेरा प्रोजेक्ट हर 3 घंटे में स्नैपशॉट बनाने का रहता है। विंडोज में एक चेकपॉइंट तंत्र है लेकिन मुझे लगता है कि यह कॉन्फ़िगर करने योग्य नहीं है; मैक टाइम मशीन भी कुछ ऐसा ही करती है।

सामान्य तौर पर, आप फ़ाइल के सभी सहेजे गए संस्करणों को संग्रहीत कर सकते हैं , और प्रीमियर में जो सभी आयातित (स्थिर) संपत्ति नहीं है, इसलिए यह उन सभी को बचाने के लिए उचित है, यहां तक ​​कि केवल जो कुछ भी बदला है उसे बचाने के लिए डेल्टा का उपयोग किए बिना।

बस फिर से सीखना Premiere और चीजों की कोशिश करने के साथ अधिक आक्रामक हो रहा है, मुझे विश्वास है कि मैं अगली बार वापस आ सकता हूं अगर मैं इस पर काम करता हूं तो मुझे पछतावा होता है कि मैंने क्या किया, या एक बेहतर तरीका पाया और इसे फिर से करना चाहता हूं। यह एक प्रभावी संशोधन संस्करण प्रणाली है। इसे NAS पर करते हुए, मुझे बचाने के दौरान पूरे प्रोजेक्ट को रौंदने वाले बीएसओडी से भी बचाव होता है। :)

इतिहास अपडेट करें एक छोटी लंबाई है, 32 प्रविष्टियों के लिए डिफ़ॉल्ट है। प्रोजेक्ट लोड होने पर यह खाली है। हालाँकि, ऑटो-सेव केवल उसी फ़ाइल पर सेव नहीं करता है, जैसे हम ज्यादातर प्रोग्राम में देखते हैं; बल्कि यह उन्हें संख्या और उन्हें रखता है। इसलिए, मैं फ़ाइल टाइमस्टैम्प देख सकता हूं और एक पुरानी प्रतिलिपि लोड कर सकता हूं, जो मुझे 15 मिनट की चौकियों का एक संस्करण इतिहास देता है। मेरे मामले में, प्रत्येक फ़ाइल 44K है, जो कि परिसंपत्ति के आकार की तुलना में कुछ भी नहीं है - यह ऑडियो के 76 मिलीसेकंड के आकार, या कक्षा 10 एसडी कार्ड फुटेज के एक फ्रेम के 1/7 वें है ।

यदि आपके पास एक सार्थक नाम के साथ एक चौकी रखने के लिए दिमाग में उपस्थिति है, तो बस कॉपी अस सेव करें। लेकिन एक उच्च आवृत्ति के लिए सेट किया गया ऑटोसैव, किसी भी राज्य (उस समय के ग्रैनुलिटी) को बिना किसी अग्रिम योजना के, थोड़े प्रयास के साथ फिर से उपयोग करने के लिए उपयोग किया जा सकता है।

उन गैर-इंजीनियरों के लिए एक नोट जो संस्करण नियंत्रण से परिचित नहीं हैं: स्पष्ट रूप से आपके काम को पीछे करने की क्षमता के अलावा, मैं अक्सर इसका उपयोग यह जांचने के लिए करता हूं कि मैंने अभी क्या बदला है, या वर्तमान कार्य की शुरुआत से पहले की स्थिति की तुलना करें , या समूह के साथ साझा किए गए अंतिम संस्करण के साथ तुलना करें।

चूंकि प्रीमेयर अब कार्यक्षेत्र में कई परियोजनाओं को खोलने का समर्थन करता है, इसलिए दो समयसीमाओं की तुलना के लिए एक खिड़की व्यवस्था कार्यक्षेत्र की स्थापना करना संभव होगा। यही है, न केवल बैकअप के लिए, उन संस्करणों के होने का अधिक प्रभावी उपयोग करें । मैं अक्सर ऐसे प्रोग्रामर को बताता हूं, जो टेक्स्ट एडिटर की तरह, सामान्य उद्देश्य टूल कैसे बनते हैं, इसका उपयोग नहीं करते हैं।

मुझे आश्चर्य है कि पेशेवर फिल्म निर्माता संस्करण नियंत्रण कैसे संभालते हैं, अगर तदर्थ से अधिक कुछ भी हो? ऑटोसैव डिजाइन थिंकमोक्वेस्टफुल है, और एकीकृत स्क्रिप्ट-राइटिंग ग्रुपवेयर टूल में स्पष्ट रूप से दृश्यमान संशोधन है।


0

वीडियो फ़ाइलों के लिए संस्करण नियंत्रण स्वयं अव्यवहारिक है क्योंकि पहले, वे विशाल हैं, दूसरे वे आगे बढ़ रहे हैं (क्या आप हर फ्रेम को संरक्षित करने जा रहे हैं?), तीसरा, वे अपरिवर्तनीय हैं। यही है, संपादन करते समय मूल फाइलें कभी नहीं बदलती हैं।

लेकिन प्रोजेक्ट फ़ाइलों के लिए संस्करण नियंत्रण बहुत मायने रखता है। वर्तमान में, हर महत्वपूर्ण परिवर्तन के बाद मैं एक नई परियोजना फ़ाइल बनाता हूं और इसे कुछ वर्णनात्मक नाम देता हूं - मैंने क्या किया, मैंने क्या जोड़ा और मैंने क्या हटाया। संक्षेप में, मुझे फ़ाइल नामों के माध्यम से इतिहास को मैन्युअल रूप से बनाए रखना होगा। संस्करण नियंत्रण के तहत परियोजना फाइलों का होना एक महान विचार है, मैंने इसके बारे में पहले क्यों नहीं सोचा!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.