Tôi đã chơi xung quanh với việc biến một loạt ảnh tĩnh thành trình chiếu h.264, chủ yếu là để so sánh hiệu quả nén của JPG so với h.264. Tôi đã nhận được một số câu trả lời hữu ích về ý nghĩa kỹ thuật của việc này từ x264 dev trên doom9. ví dụ: buộc x264 không sử dụng khung B cho việc này, vì các hình ảnh không liên quan sẽ cần rất nhiều macroblocks và mã hóa chúng trong khung B đắt hơn.
Trước đây, hành vi của người chơi phần mềm với video tốc độ thấp không phải là lý tưởng. Tôi nghĩ rằng một người chơi lớn tuổi hơn chỉ kiểm tra đầu vào bàn phím khi nó hiển thị một khung. Vì vậy, có độ trễ giữa đầu vào của người dùng và phản ứng của người chơi. mplayer2 và mpv không có vấn đề này. Ngoài ra, những người chơi chỉ có thể tìm kiếm các khung hình chính sẽ tìm kiếm trong các khối thực sự lớn (2 phút hoặc lâu hơn!) Nếu bạn không giảm khoảng cách khung hình chính. x264 sẽ không chèn IDR (ranh giới GOP) ở mọi nơi nếu các hình ảnh có liên quan với nhau.
Sử dụng x264 -tune stillimage. Nó tăng cường tối ưu hóa psy , bởi vì sự ổn định theo thời gian không phải là vấn đề đối với trường hợp sử dụng này. Kết quả tìm kiếm thêm: từ google .
Tôi đồng ý với các đề xuất khác để có một số khung hình trùng lặp, để đưa FPS lên tối thiểu 5 hoặc một cái gì đó, chỉ trong trường hợp người chơi xấu. Tuy nhiên, điện thoại thông minh / máy tính bảng sẽ không gặp vấn đề gì khi phát video FPS biến đổi, vì chúng thường ghi theo cách đó khi mức độ ánh sáng giảm. Vì các video FPS biến đổi từ điện thoại hiện đã có, nên hỗ trợ trình phát phần cứng cho chúng. Tôi sẽ không mong đợi vấn đề, nhưng tôi cũng sẽ không ngạc nhiên nếu có ít nhất một số người chơi phần cứng cũ không xử lý tốt.
Một khung của tất cả các macroblocks "bỏ qua" chỉ mất khoảng 20byte ở 1080p, IIRC. Tuy nhiên, một lý do tôi không thích các khung trùng lặp là vì nó cản trở bước đơn để đi qua các hình ảnh theo cách thủ công.
Tuy nhiên, có một nhược điểm nén khi sao chép các khung : Nếu có nhiều dư thừa giữa các hình ảnh khác nhau (nghĩa là vẫn là video chứ không phải trình chiếu), việc đệm bằng các hình ảnh giống hệt nhau sẽ khiến bộ mã hóa khó tìm và khai thác hơn.
Tùy thuộc vào cài đặt mã hóa, bộ mã hóa sẽ chỉ giữ một số số khung cũ như các tham chiếu có thể có cho các khung mới và chỉ có thể tìm kiếm trong GOP (ví dụ: 250 khung mặc định cho x264). Nếu tất cả các ứng cử viên đó là cùng một hình ảnh, điều đó không cung cấp cho nó nhiều tùy chọn để tìm một tài liệu tham khảo tốt hơn cho mỗi khối.
ví dụ: Sau khi một đối tượng tiền cảnh di chuyển trước một số chi tiết nền, bộ mã hóa có thể lưu các bit bằng cách tham chiếu giao diện của nó trong một khung cũ hơn trước khi nó bị che khuất. h.264 có thể chọn các khung tham chiếu trên cơ sở mỗi khối. Đây là một hiệu ứng tương đối nhỏ; Bộ mã hóa h.264 tốt vẫn hoạt động tốt chỉ với 1 khung tham chiếu, nhưng nó vẫn có hại cho hiệu quả nén và lãng phí thời gian sử dụng pin / pin / thời gian CPU để sao chép bộ nhớ xung quanh giải mã và hiển thị thêm khung.
Khôi phục VFR sau khi NLE buộc tất cả các clip của bạn đạt tốc độ khung hình cao:
FFmpeg có một mpdecimatebộ lọc loại bỏ các khung tương tự. Bạn có thể đặt giới hạn cho số lượng khung hình có thể giảm. Với ngưỡng tương tự chặt chẽ, bạn nên làm cho nó chỉ giảm các bản sao thực tế.
ví dụ: ffmpeg -i input.mp4 -vf mpdecimate=max=9:hi=400 -c:a copy -c:v libx264 -preset veryslow -tune film output_vfr.mkvgiảm tối đa 9 khung hình liên tiếp và chỉ khi khối khác biệt nhất khác nhau dưới "400" và (mặc định): không quá 33% số khối khác nhau bởi các đơn vị "320". IIRC, về cơ bản, nó là SAD 8x8 trên các thành phần pixel.
(FFmpeg mặc định là CFR cho .mp4đầu ra, tuy nhiên, vì vậy hãy sử dụng -vsync 2cho .mp4đầu ra tốc độ khung hình thay đổi . Tôi nghĩ rằng điều đó an toàn: Sự cố với tốc độ khung hình khi chuyển đổi video bằng ffmpeg với libx264 )