เมื่ออยากหาว่าภาพหนึ่งอยู่ตรงเวลาใดในคลิป เราอาจเริ่มจากเลขเฟรมหารด้วย fps ที่โปรแกรมแสดง วิธีนี้ดูตรงไปตรงมา โดยเฉพาะไฟล์ที่ระบุ30fps แต่ค่าที่เห็นอาจไม่ได้บอกว่าเฟรมทุกคู่ห่างกันเท่ากันจริง
วิดีโอจากกล้อง โปรแกรมอัดหน้าจอหรือระบบประมวลผลอาจมีจังหวะเฟรมต่างกันตามข้อมูลเวลาในไฟล์ หากนำอัตราเฉลี่ยไปแทนเวลาแต่ละเฟรม ความคลาดก็อาจไปปรากฏตอนจับคู่เสียง คำบรรยายหรือข้อมูลอีกชุด
ก่อนเอาเลขเฟรมไปใช้อ้างเวลา ควรดู timeline ที่ไฟล์เก็บไว้ครับ แล้วค่อยเลือกว่าต้องรักษาจังหวะเดิมหรือแปลงเป็นรูปแบบอื่นเพื่อส่งต่อ
Constant frame rate หรือ CFR ใช้จังหวะการนำเสนอเฟรมที่สม่ำเสมอตามอัตราที่กำหนด ส่วน variable frame rate หรือ VFR อนุญาตให้ช่วงเวลาระหว่างเฟรมต่างกันได้ การมีค่าอัตราเฉลี่ยจึงไม่ได้แยกสองแบบนี้ให้ครบด้วยตัวเลขเดียว
ตัวอย่างสมมติคือเฟรมสามภาพแรกมีเวลา0 0.03 และ0.09วินาทีตามลำดับ ช่องว่างแรกกับช่องว่างถัดไปต่างกันอยู่แล้ว การเลือกเลขเฉลี่ยแล้วหารลำดับเฟรมให้เป็นเวลาเท่ากันทุกภาพจะสร้าง timeline อีกแบบ ไม่ได้อ่านข้อมูลเดิมของตัวอย่างนั้น
ตัวเลขนี้เป็นเพียงภาพอธิบาย ไม่ใช่ผลจากคลิปที่เปิดตรวจจริง และไม่ได้หมายความว่าอุปกรณ์ทุกตัวใช้จังหวะแบบนี้ จุดที่ต้องการให้เห็นคือเวลาในแต่ละเฟรมเป็นข้อมูลอีกด้านจากจำนวนเฟรมทั้งหมด
เมื่อตรวจไฟล์จึงต้องอ่านความหมายของ field ที่เครื่องมือรายงาน บางค่าเป็นอัตราที่ stream ระบุหรืออนุมาน บางค่าเป็นค่าเฉลี่ย การเห็นค่าใกล้30ไม่ได้รับรองว่าไม่มีช่วงห่างผิดปกติหรือไม่มีการเปลี่ยนจังหวะภายใน
Timestamp อาจเก็บเป็นจำนวนหน่วยของ time base ไม่ใช่เลขวินาทีโดยตรง หากนำค่าดิบจาก stream หนึ่งไปเทียบอีก stream โดยไม่แปลงหน่วย ก็อาจได้ความต่างที่ไม่มีความหมายตามเวลาจริง
Presentation timestamp หรือ PTS เกี่ยวข้องกับเวลาที่นำเสนอ ส่วน decoding timestamp หรือ DTS มีบทบาทต่อการถอดรหัสตามโครงสร้าง codec การมีลำดับการ decode ที่ต่างจากลำดับภาพที่แสดงจึงไม่ใช่หลักฐานว่าเฟรมเสียด้วยตัวมันเอง
ถ้าโจทย์คือหาภาพที่ผู้ใช้เห็น ณ เวลาหนึ่ง ต้องเลือกข้อมูลด้านการนำเสนอที่เหมาะสมตามผลที่ decoder ให้ ไม่หยิบ packet แถวแรกที่เวลาใกล้กันมาใช้แทนเฟรมที่แสดงโดยไม่รู้ความสัมพันธ์
จุดเริ่ม timeline ก็ต้องระบุด้วย ไฟล์อาจมี start time หรือ offset ของแต่ละ stream การใช้เวลาเริ่มหน้าต่างเล่นเป็นศูนย์กับค่าที่เก็บอยู่ใน container อาจต่างกัน ต้องตกลงฐานเดียวก่อนจับคู่ข้อมูลจากแหล่งอื่น
ffprobe ใช้อ่านข้อมูล container กับ stream และมีตัวเลือกดูแต่ละ frame ได้ จึงใช้เริ่มตรวจว่ามี video กับ audio ใดอยู่และมีข้อมูลเวลาลักษณะไหน ก่อนเลือกดึงรายละเอียดที่จำเป็น
ตัวอย่างต่อไปนี้เป็นรูปแบบคำสั่งอ่านไฟล์สมมติในเครื่อง ไม่ใช่ผลการตรวจไฟล์วิดีโอของผู้ใช้ ส่วน output จริงต้องอ่านตามรุ่นเครื่องมือและข้อมูลที่ไฟล์นั้นมี
ffprobe -v error -show_streams -of json input.mp4
ffprobe -v error -select_streams v:0 -show_frames -of json input.mp4
การแสดงทุก frame ของคลิปยาวอาจให้ข้อมูลมาก จึงควรจำกัดช่วงหรือเลือก field ตามคำถามเมื่อใช้จริง และตรวจว่า stream ที่เลือกเป็นวิดีโอที่ต้องการ ไม่ใช่ภาพปกหรือ stream อีกชุดที่อยู่ในไฟล์เดียวกัน
การไม่พบ field ที่คาดก็ต้องอ่านว่าเครื่องมือไม่มีข้อมูลนั้นหรือกำลังดูผิดชั้น ไม่เติม timestamp จากเลขเฟรมเงียบๆ แล้วเรียกผลที่คำนวณว่าเป็นเวลาต้นฉบับ ควรเก็บว่าส่วนไหนอ่านจากไฟล์และส่วนไหนเป็นสมมติฐานที่ระบบสร้างเพิ่ม
เครื่องมืออย่าง FFmpeg มีวิธีเลือกการจัดการเวลาและอัตราเฟรมตามงาน การสร้างผลแบบ CFR อาจต้องทำซ้ำหรือทิ้งเฟรมเพื่อให้ได้จังหวะที่กำหนด จึงไม่ใช่การเปลี่ยนป้าย fps โดยไม่มีผลต่อจำนวนภาพที่ใช้
เฟรมที่ถูกทำซ้ำไม่ได้เพิ่มข้อมูลการเคลื่อนไหวที่กล้องไม่เคยเก็บ และการทิ้งบางเฟรมก็ต้องดูว่ากระทบจุดที่ต้องตรวจหรือไม่ หากจะใช้คลิปเพื่อวิเคราะห์เหตุการณ์ ควรเก็บต้นฉบับกับเวลาเดิมไว้และระบุผลที่แปลงว่าเป็น derivative
การแก้ timestamp เริ่มที่ศูนย์หรือเปลี่ยน time base ก็ควรมีเหตุผลตามปลายทาง ไม่ใช้ชุดคำสั่งที่ล้าง offset ทั้งหมดเพื่อให้ไฟล์เปิดได้ก่อน แล้วหวังว่าข้อมูลตำแหน่งหรือคำบรรยายที่ผูกกับเวลาเดิมจะยังตรงเอง
ควรบันทึกกติกาแปลงพร้อมไฟล์ผล เพื่อรู้ว่าการเปลี่ยนเวลาเป็นสิ่งที่ตั้งใจหรือเกิดจากค่าอัตโนมัติของ muxer หรือ pipeline ไม่ดูเพียงชื่อ codec กับขนาดภาพแล้วถือว่าสัญญาเวลายังเหมือนต้นฉบับทั้งหมด
เมื่อเทียบเสียงหรือข้อมูลเวลาอื่น หากเหลื่อมเท่าเดิมตลอดคลิป อาจต้องตาม offset หรือจุดเริ่ม แต่ถ้าความต่างเปลี่ยนตามระยะ ก็ต้องตรวจฐานเวลา rate และ clock ของแต่ละทาง ไม่แก้ด้วยการเลื่อนต้นคลิปอย่างเดียวแล้วจบ
ลักษณะอาการช่วยตั้งคำถามแต่ยังไม่พิสูจน์สาเหตุ ควรเทียบจุดอ้างอิงที่ระบุได้หลายช่วง พร้อมข้อมูล timestamp ของทั้งสองด้าน ไม่ใช้เหตุการณ์ที่มองหรือฟังไม่ชัดเป็นหลักฐานละเอียดกว่าที่มันให้ได้
ชุดตรวจควรมีทั้งไฟล์จังหวะสม่ำเสมอ ไฟล์ที่ช่วงเฟรมต่างกันและไฟล์ที่มีหลาย stream ตามที่ระบบต้องรองรับ ตรวจหลัง export ด้วยว่าโปรแกรมปลายทางรักษาหรือปรับ timeline อย่างไร ไม่รับรองผลจากการเปิด preview เพียงโปรแกรมเดียว
เวลาในวิดีโอควรอ้างจาก timestamp ที่มีความหมายและหน่วยตรงกัน ไม่ใช้ fps เฉลี่ยแทนระยะของทุกเฟรมโดยไม่ตรวจ เมื่อแยก PTS time base และผลของการแปลง CFR ได้ เราจะจับคู่ภาพกับข้อมูลอื่นบน timeline ที่อธิบายได้ พร้อมรักษาต้นฉบับไว้ตรวจย้อนว่าช่วงใดมาจากการบันทึกและช่วงใดถูกจัดใหม่ภายหลัง