Có một số tốc độ khung hình "tiêu chuẩn", nhưng có rất nhiều tốc độ mà việc hỗ trợ khung hình tùy ý dễ dàng hơn là hỗ trợ cụ thể cho nhiều tốc độ cụ thể. Điều này đặc biệt đúng đối với người chơi phần mềm, như VLC.
Ngày càng có nhiều hỗ trợ cho các khung hình VARIABLE. (VFR, tốc độ khung hình thay đổi). Đây là nơi khoảng thời gian giữa các khung hình trong cùng một video không phải là hằng số. Nhiều định dạng tệp chứa video (như Matroska ( .mkv) hoặc MPEG-4 ( .mp4, có liên quan chặt chẽ với Apple .mov)) thậm chí không lưu trữ số FPS, mà thay vào đó là cơ sở thời gian (ví dụ: 1/30 giây), sau đó mỗi khung hình có dấu thời gian là bội số của cơ sở thời gian đó. Nó chỉ xảy ra rằng khoảng thời gian giữa mỗi khung hình là một hoặc một số lượng nhỏ đơn vị cơ sở thời gian trong video CFR (tốc độ khung hình không đổi).
Cảnh quay camera an ninh với các khung hình gần như bị trùng lặp sẽ là trường hợp sử dụng rõ ràng cho VFR. Ngay cả khi nó được nén với một codec video đơn giản mà không tận dụng tốt sự dư thừa tạm thời (với các khung (p và b)). (chơi xung quanh ffmpeg -vf mpdecimateđể giảm các khung hình gần như song công. Sử dụng -vsync 2nếu xuất ra mp4, vì một số lý do, nó không phải là mặc định cho muxer đó, nhưng nó là cho mkv.)
Một trường hợp khác là điện thoại thông minh hiện đại. Ví dụ: Moto G (thế hệ 2) của anh tôi ghi lại video VFR. Nó làm giảm tốc độ khung hình khi cảm biến cần nhiều ánh sáng hơn. Một số đầu ra từ việc chạy mediainfo trên mp4 được tạo bởi phần mềm điện thoại, được ghi trong nhà:
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
Phát lại một luồng video VFR không khó. Phần mềm chỉ cần có khung hình tiếp theo sẵn sàng để hiển thị, ngủ cho đến khi nó được hiển thị, sau đó thức dậy và hiển thị nó.
Mọi thứ trở nên phức tạp hơn một chút khi bạn tính đến thực tế là con người chỉ có thể nhìn thấy các khung hình video khi màn hình hiển thị chúng. Màn hình VFR tồn tại, nhưng vẫn còn hiếm. (google cho g-sync freesync).
Thay đổi hình ảnh được hiển thị trong khi nó được quét ra màn hình dẫn đến việc xé video xấu xí (thường thấy khi chơi trò chơi tắt vsync). Điều này giới hạn người chơi thay đổi hình ảnh hiển thị ở 50 hoặc 60Hz. (CRT hỗ trợ tốc độ vrefresh tùy ý, trong một phạm vi, nhưng rất khó để nấu các chế độ với tất cả các thời gian chính xác, vì vậy hầu hết mọi người chỉ sử dụng một vài tốc độ làm mới cố định. Và bây giờ mọi người có màn hình LCD chỉ hỗ trợ tốc độ làm mới cố định. Màn hình freesync vẫn phổ biến rộng rãi hơn. Tôi thực sự mong đợi điều đó. :)
Vì vậy, với tốc độ khung hình video không phải là một hoặc nhiều yếu tố của tốc độ làm mới màn hình, một số khung hình sẽ được hiển thị cho 3 lần làm mới màn hình, và một số cho 2, ví dụ, ngay cả khi video có nghĩa là ở mức 25FPS không đổi (trên màn hình 60Hz).
Mọi thứ trở nên phức tạp hơn khi bạn muốn làm việc với nhiều clip và mờ dần giữa chúng, hoặc hình ảnh trong ảnh hoặc nhiều hiệu ứng khác. Việc viết phần mềm chỉnh sửa video sẽ dễ dàng hơn rất nhiều nếu bạn có thể cho rằng tất cả các clip đều có khung mới cùng một lúc. (Họ buộc căn chỉnh clip để chụp vào toàn bộ khung).
Đây là lý do tại sao các NLE (như kdenlive hoặc pitivi, để chọn các ví dụ phần mềm miễn phí ngẫu nhiên), có nhiều khả năng buộc bạn phải cố định FPS và thả / sao chép khung hình từ các clip của bạn để làm cho chúng khớp với tốc độ khung hình đó. CFR bạn chọn có thể tùy ý, nhưng nó thường phải là hằng số cho toàn bộ "dự án".
(Có bất kỳ NLE nào hoạt động hoàn toàn với clip VFR và tạo đầu ra VFR trong trường hợp đó không?)
Vì vậy, tóm lại, một khi chúng ta có màn hình và hệ điều hành đồng bộ hóa biến, điều duy nhất giữ chúng ta lại là chỉnh sửa video, tôi đoán vậy. Và phát sóng, vì rõ ràng CFR cũng là một vấn đề lớn cho điều đó?
Trong trường hợp bạn đang tự hỏi, 29.970 (thực tế là 30000/1001) và 23.976 (thực tế là 24000/1001, từ telecining) tốc độ khung hình không nguyên là phiền toái của NTSC màu. tìm kiếm 1.001 . Nếu chỉ họ sẵn sàng mạo hiểm với một vài bộ B & W không thể xử lý thêm 0,1% tần số cho sóng mang âm thanh, thế giới sẽ không bị ảnh hưởng bởi điều này. (Tôi nghĩ rằng tôi đã thấy một bài viết khác ở đâu đó khiến nó nghe giống như nhiều bộ sẽ ổn, nhưng họ không chắc chắn về compat hoàn hảo. Wikipedia làm cho nó có vẻ như không có bộ nào xử lý sóng mang âm thanh cao hơn 0,1%. IDK sự thật.)
Mặc dù vậy, tốc độ khung hình gây phiền nhiễu là một trong những tội ít phát sóng hơn. Nó thực sự xen kẽ đó là nguyên nhân của chất lượng video trên màn hình hiện đại (tất cả các pixel được chiếu sáng cùng một lúc) và điều đó sẽ không thay đổi. Tôi vẫn không hiểu tại sao xen kẽ được giữ xung quanh cho HDTV. Tại sao 1080i60 đã từng được xác định, thay vì sử dụng 720p60 để có cùng độ phân giải thời gian cho thể thao và nội dung? Nó tương tự như 1920x540p60, nhưng với phần bù dọc ngu ngốc giữa các trường lẻ và chẵn đòi hỏi nhiều tính toán ở đầu nhận để khiến nó trông không tệ.
biên tập:
Đối với trường hợp sử dụng của bạn, tôi hoàn toàn khuyên bạn nên lưu trữ ở FPS gốc. Đừng vứt bỏ bất kỳ thông tin bằng cách thả khung. Không ghép các khung và làm cho các tệp của bạn lớn hơn (hoặc làm cho bộ mã hóa h.264 của bạn dành nhiều thời gian hơn để nhận thấy các bản sao và xuất ra một khung chứa đầy các macroblocks bỏ qua chỉ mất 20 byte cho toàn khung).
Trong tương lai khi chúng tôi hy vọng tất cả đều có màn hình freesync có thể phát bất kỳ tốc độ khung hình nào, bạn sẽ muốn hoàn tác pullup của mình lên 24fps để video của bạn phát mượt mà hơn! Hoặc nếu freesync bằng cách nào đó không bắt kịp hoặc màn hình xuất hiện sau LCD là CFR, thì chuyển đổi tốc độ có thể được thực hiện tốt nhất vào lúc phát lại. Nó không giống như 24fps thậm chí chơi hoàn hảo trên màn hình 60Hz. (Tôi không để ý một cách trực quan rằng một số khung hình được hiển thị cho 3 * 1/60 trong khi một số khung hình được hiển thị cho 2 * 1/60, nhưng đó là sự thật).
Nếu bạn gặp vấn đề với Quicktime, thì IDK. Có thể đảm bảo Handbrake đang tạo các tệp với tốc độ khung hình phù hợp được đặt trong dòng bit h.264, cũng như vùng chứa. (Vâng, h.264 tiêu đề rõ ràng có thể lưu trữ một tỷ lệ khung hình, tách biệt với những gì container nói. Xem tài liệu cho mkvmerge --fix-bitstream-timing-information. Và cố gắng sử dụng nó với --default-duration 16fpsđể làm cho một tập tin mkv. Sau đó MUX lại cho rằng mp4 và thấy rằng nếu sửa quicktime? ) Hoặc có thể có một cách để làm điều đó với các công cụ mp4 ở nơi đầu tiên. Xem ví dụ: https://askubfox.com/questions/370692/how-to-change-the-framerator-of-a-video-without-reencoding
Tôi có thể đảm bảo rằng tốc độ khung hình mp4 tùy ý là hợp lệ và thậm chí cả tốc độ khung hình mp4 biến đổi cũng hợp lệ. Nếu Quicktime chơi sai, đó cũng có thể là lỗi của Quicktime. Hoặc có thể lỗi của Handbrake vì làm cho tệp sai. Tôi thường chỉ sử dụng ffmpeg trực tiếp, vì tôi là ninja dòng lệnh.