มีอัตราเฟรมมาตรฐาน "หลาย" แต่มีจำนวนมากที่สนับสนุน framerates โดยพลการง่ายกว่าสนับสนุนเฉพาะจำนวนมากโดยเฉพาะ นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งสำหรับผู้เล่นซอฟต์แวร์เช่น VLC
มีการสนับสนุนเพิ่มเติมสำหรับ FPS ที่หลากหลายและมากขึ้น (VFR, อัตราเฟรมตัวแปร) นี่คือที่ช่วงเวลาระหว่างเฟรมภายในวิดีโอเดียวกันไม่คงที่ รูปแบบไฟล์คอนเทนเนอร์วิดีโอหลายรูปแบบ (เช่น Matroska ( .mkv) หรือ MPEG-4 ( .mp4เกี่ยวข้องกับ Apple .mov)) ไม่แม้แต่จะเก็บหมายเลข FPS แต่เป็นเวลาฐาน (เช่น 1 / 30th ของวินาที) จากนั้นแต่ละเฟรม มีการประทับเวลาเป็นหลายฐานเวลา มันเกิดขึ้นเพียงว่าช่วงเวลาระหว่างแต่ละเฟรมคือหนึ่งหรือจำนวนเต็มเล็กน้อยของหน่วยของฐานเวลาในวิดีโอ CFR (อัตราเฟรมคงที่)
วิดีโอรักษาความปลอดภัยของกล้องที่มีเฟรมใกล้เคียงลดลงจะเป็นกรณีการใช้งานที่ชัดเจนสำหรับ VFR ยิ่งไปกว่านั้นหากมันถูกบีบอัดด้วยตัวแปลงสัญญาณวิดีโอแบบง่ายๆที่ไม่ได้ใช้ประโยชน์จากความซ้ำซ้อนทางโลก (ด้วยเฟรมระหว่าง (p และ b)) (เล่นไปffmpeg -vf mpdecimateเรื่อยๆเพื่อวางเฟรมใกล้เคียงใช้-vsync 2ถ้าส่งออกไปยัง mp4 เพราะเหตุผลบางประการมันไม่ใช่ค่าเริ่มต้นสำหรับ muxer นั้น แต่สำหรับ mkv)
อีกกรณีหนึ่งคือสมาร์ทโฟนที่ทันสมัย ตัวอย่างเช่น Moto G พี่ชายของฉัน (รุ่นที่ 2) บันทึกวิดีโอ VFR มันลดอัตราเฟรมเมื่อเซ็นเซอร์ต้องการแสงมากขึ้น เอาต์พุตบางส่วนจากการเรียกใช้ mediainfo บน mp4 ที่สร้างขึ้นโดยซอฟต์แวร์ของโทรศัพท์บันทึกในอาคาร:
Bit rate : 9 999 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Rotation : 90°
Frame rate mode : Variable
Frame rate : 16.587 fps
Minimum frame rate : 14.985 fps
Maximum frame rate : 30.030 fps
การเล่นสตรีมวิดีโอ VFR เดียวนั้นไม่ยาก ซอฟต์แวร์เพิ่งทำให้เฟรมถัดไปพร้อมที่จะแสดงหลับจนกระทั่งมันควรจะแสดงแล้วตื่นขึ้นมาแล้วแสดงมัน
สิ่งต่าง ๆ มีความซับซ้อนมากขึ้นเมื่อคุณคำนึงถึงความจริงที่ว่ามนุษย์สามารถเห็นเฟรมวิดีโอเฉพาะเมื่อจอภาพแสดงเท่านั้น มี VFR monitor แต่ก็ยังหายาก (google สำหรับ g-sync freesync)
การเปลี่ยนภาพที่แสดงในขณะที่สแกนออกไปยังจอภาพจะทำให้วิดีโอฉีกขาดอย่างน่าเกลียด สิ่งนี้ จำกัด ผู้เล่นให้เปลี่ยนภาพที่แสดงที่ 50 หรือ 60Hz (CRT สนับสนุนอัตรา vrefresh โดยพลการภายในช่วง แต่มันซับซ้อนในการปรุงโหมดที่มีการกำหนดเวลาที่ถูกต้องดังนั้นคนส่วนใหญ่ใช้อัตราการรีเฟรชคงที่เพียงไม่กี่ครั้งและตอนนี้ผู้คนมี LCD ที่รองรับอัตราการรีเฟรชคงที่ต่อไป จอมอนิเตอร์ freesync นั้นแพร่หลายมากขึ้นฉันหวังว่าจะเป็นอย่างนั้นจริงๆ :)
ดังนั้นด้วยอัตราเฟรมวิดีโอที่ไม่ใช่อัตราการรีเฟรชจอภาพหรือหลายปัจจัยเฟรมบางเฟรมจะแสดงสำหรับการรีเฟรชมอนิเตอร์ 3 ครั้งและอีก 2 ตัวอย่างเช่นแม้ว่าวิดีโอจะมีค่าคงที่ 25FPS (บนจอภาพ 60Hz)
สิ่งต่าง ๆ มีความซับซ้อนมากขึ้นเมื่อคุณต้องการทำงานกับคลิปหลายคลิปและจางหายไประหว่างพวกเขาหรือภาพซ้อนภาพหรือเอฟเฟกต์อื่น ๆ การเขียนซอฟต์แวร์ตัดต่อวิดีโอนั้นง่ายกว่ามากถ้าคุณคิดว่าคลิปทั้งหมดมีเฟรมใหม่ในเวลาเดียวกัน (พวกเขาบังคับให้การจัดตำแหน่งคลิปเพื่อจัดชิดทั้งเฟรม)
นี่คือเหตุผลที่ NLE (เช่น kdenlive หรือ pitivi เพื่อเลือกตัวอย่างซอฟต์แวร์สุ่มฟรี) มีแนวโน้มที่จะบังคับให้คุณไปยัง FPS คงที่และวาง / ทำซ้ำเฟรมจากคลิปของคุณเพื่อให้ตรงกับอัตราเฟรมนั้น CFR ที่คุณเลือกสามารถกำหนดเองได้ แต่โดยทั่วไปจะต้องมีค่าคงที่สำหรับ "โครงการ" ทั้งหมด
(NLE ใด ๆ ทำงานอย่างสมบูรณ์กับคลิป VFR และสร้างเอาต์พุต VFR ในกรณีนั้นหรือไม่)
ดังนั้นโดยสรุปแล้วเมื่อเรามีจอมอนิเตอร์แบบปรับค่าตัวแปรและระบบปฏิบัติการสิ่งเดียวที่ทำให้พวกเรากลับมาอีกครั้งคือการตัดต่อวิดีโอฉันเดา และการออกอากาศเนื่องจากเห็นได้ชัดว่า CFR เป็นเรื่องใหญ่สำหรับเรื่องนั้นเช่นกัน?
ในกรณีที่คุณสงสัยว่า 29.970 (จริง ๆ แล้วคือ 30000/1001) และ 23.976 (จริง ๆ แล้ว 24000/1001 จากการโทรคมนาคม) อัตราเฟรมที่ไม่ใช่จำนวนเต็มน่ารำคาญเป็นความผิดของสี NTSC ค้นหา 1.001 ถ้าเพียง แต่พวกเขายินดีที่จะเสี่ยง B&W สองสามชุดที่ไม่สามารถรองรับความถี่พิเศษ 0.1% สำหรับ subcarrier เสียงโลกจะได้รับการยกเว้นเรื่องไร้สาระนี้ (ฉันคิดว่าฉันเห็นบทความอื่นที่ทำให้มันดูเหมือนหลาย ๆ ชุดจะดี แต่พวกเขาไม่แน่ใจเกี่ยวกับ compat ที่สมบูรณ์แบบ Wikipedia ทำให้ดูเหมือนไม่มีชุดที่จะจัดการ subcarrier เสียงที่สูงขึ้น 0.1% IDK the ข้อเท็จจริง.)
อย่างไรก็ตามอัตราเฟรมที่น่ารำคาญเป็นหนึ่งในความบาปที่น้อยลงของการออกอากาศ มันเป็นการพัวพันกันจริง ๆ ว่าคุณภาพของวิดีโอบนหน้าจอที่ทันสมัย (พิกเซลทั้งหมดสว่างพร้อมกัน) หน้าจอและนั่นจะไม่เปลี่ยนแปลง ฉันยังไม่เข้าใจว่าทำไมการพัวพันจึงถูกเก็บไว้สำหรับ HDTV เหตุใดจึงมีการกำหนด 1080i60 แทนการใช้ 720p60 เพื่อให้ได้ความคมชัดชั่วคราวสำหรับกีฬาและสิ่งของ มันคล้ายกับ 1920x540p60 แต่มีการชดเชยแนวตั้งโง่ระหว่างเขตข้อมูลคี่และคู่ที่ต้องใช้การคำนวณจำนวนมากในตอนท้ายที่ได้รับเพื่อทำให้มันดูไม่น่ากลัว
แก้ไข:
สำหรับกรณีการใช้งานของคุณฉันขอแนะนำให้เก็บถาวรที่ FPS ดั้งเดิม อย่าทิ้งข้อมูลใด ๆ ด้วยการปล่อยเฟรม อย่าทำซ้ำเฟรมและทำให้ไฟล์ของคุณใหญ่ขึ้น (หรือทำให้ตัวเข้ารหัส h.264 ของคุณใช้เวลามากขึ้นในการสังเกตความซ้ำซ้อนและส่งออกเฟรมที่เต็มไปด้วยการข้าม macroblocks ที่ใช้เวลาเพียง 20 ไบต์สำหรับทั้งเฟรม)
ในอนาคตเมื่อเราหวังว่าทุกคนจะมีการแสดงผลแบบ freesync ที่สามารถเล่นแบบ framerate ใด ๆ คุณจะต้องยกเลิกการ pullup ของคุณเป็น 24fps เพื่อให้วิดีโอของคุณเล่นได้ราบรื่นขึ้น! หรือถ้า freesync ไม่ติดหรือจอแสดงผลหลังจาก LCD เป็น CFR ดังนั้นการแปลงอัตราอาจทำได้ดีที่สุดในเวลาที่เล่นอยู่ดี มันไม่เหมือน 24fps ที่เล่นได้อย่างสมบูรณ์แบบบนหน้าจอ 60Hz (ฉันไม่ได้สังเกตเห็นความจริงที่ว่าบางเฟรมแสดงเป็น 3 * 1 / 60th ในขณะที่บางเฟรมแสดงเป็น 2 * 1/60 แต่มันจริง)
หากคุณมีปัญหากับ Quicktime ให้ IDK อาจตรวจสอบให้แน่ใจว่า Handbrake กำลังสร้างไฟล์ที่มีอัตราเฟรมขวาใน h.264 บิตสตรีมเช่นเดียวกับคอนเทนเนอร์ (ใช่ส่วนหัว h.264 สามารถจัดเก็บอัตราเฟรมแยกจากที่กล่าวว่าคอนเทนเนอร์ดูเอกสารสำหรับmkvmerge --fix-bitstream-timing-informationและลองใช้มัน--default-duration 16fpsเพื่อสร้างไฟล์ mkv จากนั้น mux นั้นกลับไปเป็น mp4 และดูว่าจะแก้ไขปัญหา Quicktime หรือไม่? ) หรืออาจจะมีวิธีที่จะทำกับเครื่องมือ mp4 ในตอนแรก ดูตัวอย่าง: /ubuntu/370692/how-to-change-the-framerate-of-a-video-without-reencoding
ฉันสามารถรับประกันได้ว่า mp4 อัตราเฟรมเองนั้นถูกต้องและแม้กระทั่งตัวแปรเฟรม framerate ก็ใช้ได้ หาก Quicktime เล่นผิดมันอาจเป็นความผิดของ Quicktime ได้ หรืออาจเป็นความผิดของ Handbrake ที่ทำให้ไฟล์ผิด ฉันมักจะใช้ ffmpeg โดยตรงเพราะฉันเป็นนินจาบรรทัดคำสั่ง