วิดีโอและคำบรรยาย · ชุดเครื่องมือคำบรรยาย
เปรียบเทียบรหัสเวลาของคำบรรยาย: SRT ลูกน้ำ, VTT จุด และ SMPTE เฟรม
· พื้นหลัง
คำบรรยาย รหัสเวลา อัตราเฟรม
วิธีเขียนเวลาแสดงไว้สามวิธีในงานคำบรรยาย: HH:MM:SS,mmm ของ SRT HH:MM:SS,mmm, HH:MM:SS.mmm ของ SMPTE HH:MM:SS:FF โพสต์นี้จะอธิบายว่าแต่ละข้อหมายถึงอะไร ทำให้เกิด Conversion ได้อย่างไร และ Conversion ผิดพลาดตรงไหน
ช่วงเวลาเดียวกันเขียนไว้สามวิธี — ทัวร์ชมรหัสเวลาสั้นๆ ที่บรรณาธิการพบในโปรเจ็กต์เดียว
โครงการหนึ่งสามารถส่งบรรณาธิการได้ทันทีที่เขียนได้สามวิธี ไฟล์คำบรรยายใช้เวลา ชั่วโมง นาที วินาที และเครื่องหมายจุลภาคก่อนมิลลิวินาที ไฟล์คำบรรยายเว็บใช้จุดในตำแหน่งเดียวกัน รายการการตัดสินใจแก้ไขใช้หมายเลขเฟรมแทนเศษส่วน ทั้งสามชื่อช่วงเวลาเดียวกัน และมีเพียงหนึ่งเท่านั้นที่สามารถอ่านได้โดยไม่ต้องรู้อะไรเกี่ยวกับเนื้อหาอื่นอีก
จุดสุดท้ายคือจุดที่สำคัญ สัญกรณ์สองรายการเหล่านี้เป็นแบบสัมบูรณ์และอีกรายการหนึ่งไม่เป็นเช่นนั้น และการแปลงระหว่างสองสัญกรณ์จะล้มเหลวในลักษณะเฉพาะเมื่อมองข้ามความแตกต่าง
มิลลิวินาทีที่มีเครื่องหมายจุลภาค: SRT — ลักษณะทศนิยมของยุโรปที่กลายเป็นกฎการจัดรูปแบบ
SRT เขียนชั่วโมง นาที วินาที เครื่องหมายจุลภาค และมิลลิวินาทีสามหลักพอดี เครื่องหมายจุลภาคเป็นตัวคั่นทศนิยมในอนุสัญญายุโรป และกลายเป็นกฎรูปแบบตามการใช้งานมากกว่าตามข้อกำหนด เนื่องจาก SubRip ไม่มีเอกสารมาตรฐานที่จะแก้ไข ไม่มีอะไรเกี่ยวกับคุณค่าที่เป็นของยุโรป มีเพียงเครื่องหมายวรรคตอนเท่านั้น
โปรแกรมแยกวิเคราะห์ที่นี่อ่านมิลลิวินาทีโดยเติมตัวเลขใดๆ ก็ตามที่พบทางด้านขวาเป็นสาม ดังนั้นการประทับเวลาที่ลงท้ายด้วยตัวเลขหลักเดียวจะถูกอ่านเป็นหลายร้อยมิลลิวินาที แทนที่จะเป็นหน่วย นั่นสำคัญเพราะไฟล์ที่เขียนด้วยมือหรือตัวแปลงแบบหลวมๆ มักไม่ได้ระบุตัวเลขสามหลักเสมอไป และการอ่านตัวเลขต่อท้ายเพียงตัวเดียวเนื่องจากหน่วยจะวางคิวล่วงหน้าเกือบหนึ่งวินาที
มิลลิวินาทีที่มีจุด: WebVTT — ค่าเดียวกัน ตัวคั่นต่างกัน และเหตุใดจึงมีความสำคัญต่อตัวแยกวิเคราะห์
WebVTT เขียนค่าเดียวกันด้วยจุด และอนุญาตให้ละเว้นฟิลด์ชั่วโมงทั้งหมด ดังนั้นแบบฟอร์มสองฟิลด์จึงใช้ได้ โดยที่ SRT คาดว่าจะมีสามฟิลด์ สำหรับโปรแกรมแยกวิเคราะห์แล้ว ไวยากรณ์เหล่านี้แตกต่างออกไปอย่างแท้จริง ซึ่งเป็นเหตุว่าทำไมไฟล์จึงสามารถถูกปฏิเสธได้เนื่องจากเครื่องหมายวรรคตอนเพียงอย่างเดียว แม้ว่าตัวเลขทุกตัวในนั้นจะถูกต้องก็ตาม
ไฟล์จริงผสมทั้งสองอย่างต่อเนื่อง ดังนั้น parser จึงยอมรับตัวคั่นตัวใดตัวหนึ่ง โดยไม่คำนึงว่าไฟล์จะอ้างว่าเป็นรูปแบบใดก็ตาม ความอดทนนั้นอยู่ที่อินพุตเท่านั้น ในเอาต์พุต ตัวคั่นจะถูกเลือกตามรูปแบบเป้าหมาย เครื่องหมายจุลภาคสำหรับ SRT และจุดสำหรับ WebVTT ดังนั้นไฟล์ที่แปลงแล้วจึงเป็นแบบบัญญัติมากกว่าสำเนาของความผิดปกติใดๆ ที่มาถึง
เฟรม: SMPTE รหัสเวลา — HH:MM:SS:FF ขึ้นอยู่กับอัตราเฟรมและภาวะแทรกซ้อนของเฟรมดรอป
SMPTE รหัสเวลาจะแทนที่ส่วนที่เป็นเศษส่วนด้วยหมายเลขเฟรม โดยให้ชั่วโมง นาที วินาที และเฟรม แตกต่างจากอีกสองเฟรมที่ไม่สามารถตีความได้โดยลำพัง: เฟรมที่สิบสองเป็นช่วงเวลาที่แตกต่างกันที่ยี่สิบห้าเฟรมต่อวินาทีมากกว่าที่สามสิบ ดังนั้นรหัสเวลาแบบเฟรมโดยไม่มีอัตราที่ประกาศไว้จึงไม่สมบูรณ์แทนที่จะเป็นเพียงความคลุมเครือ
Drop-frame เพิ่มภาวะแทรกซ้อนที่สอง เนื้อหาที่ 29.97 เฟรมต่อวินาทีจะถูกนับราวกับว่าเป็นสามสิบ และเพื่อให้การนับสอดคล้องกับนาฬิกา หมายเลขเฟรมสองตัวจะถูกข้ามไปเมื่อเริ่มต้นนาทีส่วนใหญ่ โดยทุกๆ สิบนาทีจะได้รับการยกเว้น เฟรมไม่ตกหล่น มีเพียงป้ายกำกับเท่านั้น รหัสเวลาแบบดรอปเฟรมเป็นรูปแบบการนับ และถือเป็นการนับเฟรมธรรมดาจะทำให้เกิดข้อผิดพลาดที่ขยายใหญ่ขึ้นทั่วทั้งโปรแกรม
การแปลงเฟรมเป็นมิลลิวินาที — เลขคณิตและการปัดเศษที่ทำให้เกิดข้อผิดพลาดเล็กน้อยแต่เกิดขึ้นจริง
การแปลงเฟรมเป็นมิลลิวินาทีเป็นการหารด้วยอัตราเฟรม และการปัดเศษคือจุดที่ข้อผิดพลาดเล็กๆ น้อยๆ เกิดขึ้น ดัชนีเฟรมที่หารด้วยอัตราแล้วคูณด้วยพันนั้นแทบจะไม่ได้ลงถึงหนึ่งมิลลิวินาที และผลลัพธ์จะต้องถูกปัดเศษจึงจะจัดเก็บได้ ตัวชี้นำภายในจะถูกเก็บไว้เป็นมิลลิวินาทีทั้งหมดนับจากศูนย์ ดังนั้นทุกการแปลงเป็นตัวแทนนั้นจะปัดเศษหนึ่งครั้ง
การปัดเศษครั้งเดียวไม่เป็นอันตราย ข้อผิดพลาดที่ควรระวังคือการแปลงซ้ำ: ไฟล์ที่นำมาจากเฟรมเป็นมิลลิวินาที กลับไปยังเฟรมในอัตราอื่นแล้วส่งต่ออีกครั้งจะสะสมการปัดเศษในแต่ละครั้ง และข้อผิดพลาดเหล่านั้นจะไม่ยกเลิก แปลงครั้งเดียวจากแหล่งที่เชื่อถือได้แทนที่จะส่งไฟล์ผ่านเครื่องมือหลายอย่าง
ตัวอย่างการทำงาน: หนึ่งคิวที่ 25 fps และที่ 29.97 ดรอปเฟรม — แปลงทั้งสองเป็นมิลลิวินาทีและเปรียบเทียบ
ใช้เวลาหนึ่งคิวในหนึ่งนาทีสามสิบวินาทีและสิบสองเฟรม ที่ยี่สิบห้าเฟรมต่อวินาที สิบสองเฟรมเท่ากับสิบสองยี่สิบห้าของวินาที ซึ่งเท่ากับสี่ร้อยแปดสิบมิลลิวินาทีพอดี ดังนั้นชั่วขณะจึงเท่ากับเก้าหมื่นสี่ร้อยแปดสิบมิลลิวินาที
ที่ 29.97 ดรอปเฟรม ป้ายกำกับเดียวกันจะต่างออกไป นับเฟรม: เก้าสิบวินาทีที่สามสิบระบุให้สองพันเจ็ดร้อยบวกสิบสอง ลบสองป้ายกำกับที่ตกในนาทีแรก ซึ่งเท่ากับสองพันเจ็ดร้อยสิบเฟรม หารด้วยอัตราที่แท้จริงสามหมื่นมากกว่าหนึ่งพันหนึ่งและชั่วขณะคือประมาณเก้าหมื่นสี่ร้อยยี่สิบสี่มิลลิวินาที รหัสเวลาทั้งสองมีลักษณะเกือบจะเหมือนกันและแตกต่างกันประมาณห้าสิบหกมิลลิวินาที ซึ่งเล็กพอที่จะตรวจสอบได้ และใหญ่พอที่จะมองเห็นได้ในคิวที่แน่นหนา
สิ่งนี้ไม่ครอบคลุมถึง ชั่วโมงที่เกิน 99 เวลาติดลบ และรหัสเวลาในข้อมูลเมตาของคอนเทนเนอร์
ซึ่งครอบคลุมถึงสัญลักษณ์ไทม์โค้ดในไฟล์คำบรรยาย ไม่ครอบคลุมฟิลด์ชั่วโมงที่เกินเก้าสิบเก้า ซึ่งบางระบบใช้สำหรับระบุม้วนมากกว่าเวลาที่ผ่านไป และไม่ครอบคลุมเวลาที่เป็นค่าลบ ซึ่งรูปแบบคำบรรยายไม่สามารถแสดงได้ การเปลี่ยนแปลงที่จะทำให้เกิดการเปลี่ยนแปลงจะถูกยึดไว้ที่ศูนย์
รหัสเวลาที่จัดเก็บไว้ในข้อมูลเมตาของคอนเทนเนอร์อยู่นอกขอบเขตเช่นกัน ไฟล์วิดีโออาจมีรหัสเวลาเริ่มต้นที่จะชดเชยทุกอย่างที่อยู่ภายใน ดังนั้นไฟล์คำบรรยายที่ถูกต้องกับโปรแกรมอาจปรากฏผิดกับไฟล์ และไม่มีการตรวจสอบการประทับเวลาคำบรรยายสักเท่าใดที่จะเปิดเผยข้อมูลนั้นได้
ประเด็นสำคัญ: รู้ว่าคุณกำลังอ่านนาฬิกาเรือนไหน — ชุดเครื่องมือคำบรรยายแปลงระหว่างรหัสเวลา SRT และ WebVTT ได้อย่างไร
รู้ว่าคุณกำลังอ่านนาฬิกาไหน เครื่องหมายจุลภาคและจุดเป็นค่าเดียวกันที่เขียนสำหรับ parsers ที่แตกต่างกัน และการแปลงระหว่างทั้งสองควรเปลี่ยนเครื่องหมายวรรคตอนและไม่มีอะไรอื่นใด จำนวนเฟรมเป็นตัวเลขประเภทอื่น ซึ่งไม่มีความหมายหากไม่มีอัตราและทำให้เข้าใจผิดเมื่ออัตราเป็นเฟรมแบบดรอปเฟรม
แปลงระหว่าง SRT และ WebVTT ด้วยชุดเครื่องมือและเปรียบเทียบการประทับเวลาก่อนและหลัง: ตัวคั่นควรเปลี่ยนและตัวเลขไม่ควรเปลี่ยน หากตัวเลขถูกย้าย ไฟล์จะต้องผ่านขั้นตอนแบบเฟรมที่ไหนสักแห่ง และนั่นคือการแปลงที่ต้องตรวจสอบ