FFMPEG / libx264: Làm cách nào để chỉ định tốc độ khung hình thay đổi nhưng với mức tối đa?


16

Thay vì cung cấp tốc độ khung hình cố định cho FFMPEG / libx264 (-r / -framerator), tôi muốn chỉ định tốc độ khung hình thay đổi với giá trị MAXIMUM và cho phép libx264 giảm tốc độ khung hình khi thấy phù hợp. Ý tưởng ở đây là để có được nén thêm khi có một cái gì đó giống như một khung hình tĩnh mở rộng (xảy ra RẤT NHIỀU trong các video nguồn của tôi).

Tôi nhận ra rằng khung MPEG dự đoán hoặc hai chiều sẽ nén rất tốt, nhưng cũng có thể tốc độ khung nguồn nhỏ hơn tốc độ tôi dự định chuyển mã (có thể dẫn đến luồng BIGGER!).


1
Trường hợp (hoặc làm thế nào) bạn thực sự nói với x264 để sử dụng VFR?
slhck

Đó là câu hỏi của tôi.
Mark Gerolimatos

2
Câu hỏi của bạn là làm thế nào để xác định VFR tối đa . Tôi thậm chí không biết bất kỳ cách nào để chỉ định mã hóa VFR, sử dụng x264. (Tôi cũng không nói về ffmpeg tại thời điểm này, bởi vì đó là một lớp khác giữa nguồn của bạn và x264.)
slhck

@MarkGerolimatos Bạn đã tìm thấy câu trả lời của mình chưa?!
Dr.jacky

Không, tôi không bao giờ làm.
Mark Gerolimatos

Câu trả lời:


19

Thất vọng vì bạn cũng không tìm thấy câu trả lời, tôi sẽ ít nhất trả lời câu hỏi của người khác về cách bật đầu ra VFR (không phải V B R) từ FFMPEG.

Câu trả lời cho điều đó là -vsynctùy chọn có tên kỳ quặc . Bạn có thể đặt nó thành một vài tùy chọn khác nhau, nhưng tùy chọn bạn muốn là '2' hoặc vfr. Từ trang người đàn ông:

-vsync tham số
Phương thức đồng bộ video. Vì lý do tương thích, các giá trị cũ có thể được chỉ định là số. Các giá trị mới được thêm vào sẽ phải được chỉ định dưới dạng chuỗi luôn.

  • 0, vượt qua

    • Mỗi khung hình được truyền với dấu thời gian của nó từ bộ chuyển đổi sang bộ trộn.
  • 1, trái cây

    • Các khung sẽ được nhân đôi và loại bỏ để đạt được chính xác tốc độ khung không đổi được yêu cầu.
  • 2, vfr

    • Các khung được truyền qua với dấu thời gian của chúng hoặc bị hủy để ngăn 2 khung có cùng dấu thời gian.
  • rơi vãi

    • Khi vượt qua nhưng phá hủy tất cả các dấu thời gian, làm cho muxer tạo ra các dấu thời gian mới dựa trên tốc độ khung hình.
  • -1, tự động

    • Lựa chọn giữa 1 và 2 tùy thuộc vào khả năng của muxer. Đây là phương pháp mặc định.

Lưu ý rằng dấu thời gian có thể được sửa đổi thêm bởi muxer, sau đó. Ví dụ: trong trường hợp tùy chọn định dạng né_negative_ts được bật.

Với -map, bạn có thể chọn luồng thời gian nào sẽ được thực hiện. Bạn có thể để video hoặc âm thanh không thay đổi và đồng bộ (các) luồng còn lại với luồng không thay đổi.

Tuy nhiên, tôi không đủ danh tiếng để đăng bình luận để trả lời "câu hỏi phụ" mà mọi người dường như đang có. Nhưng tôi đã có một vài ý tưởng mà tôi không thực sự rất lạc quan về ... Nhưng ý tưởng đầu tiên tôi đã thử thực sự có hiệu quả . Vì thế.

Bạn chỉ cần kết hợp -vsync 2tùy chọn với -r $maxfpstùy chọn, tất nhiên là nơi bạn thay thế $maxfpsvới tốc độ khung hình tối đa bạn muốn! Và nó hoạt động! Nó không trùng lặp các khung từ một tệp nguồn, nhưng nó sẽ bỏ các khung làm cho tệp vượt quá tốc độ khung hình tối đa!

Theo mặc định, có vẻ như -r $maxfpschính nó chỉ khiến nó nhân đôi / thả khung để đạt được tốc độ khung hình không đổi và -vsync 2chính nó khiến nó kéo khung hình trực tiếp mà không thực sự ảnh hưởng đến các giá trị PTS.

Tôi không lạc quan về điều này bởi vì tôi đã biết rằng -r $maxfpsđặt nó ở tốc độ khung hình không đổi. Tôi thành thật mong đợi một lỗi hoặc cho nó chỉ tuân theo bất cứ điều gì đến trước hoặc cuối cùng hoặc bất cứ điều gì. Việc nó thực hiện chính xác những gì tôi muốn làm cho tôi khá hài lòng với các nhà phát triển FFMPEG.

Tôi hy vọng điều này sẽ giúp bạn, hoặc người khác sau này nếu bạn không còn cần phải biết điều này.


3
-copytscũng có thể hữu ích
rogerdpack

1

Tôi muốn chỉ định tốc độ khung hình thay đổi với giá trị MAXIMUM và cho phép libx264 giảm tốc độ khung hình khi thấy phù hợp. Ý tưởng ở đây là để có thêm nén khi có một cái gì đó giống như một khung hình tĩnh mở rộng

Theo hiểu biết của tôi, điều này có thể có thể theo một cách tương đối vụng về, nhưng không mong muốn vì một số lý do phức tạp và phản trực giác

Mặc dù một luồng x264 có tốc độ khung hình, tốc độ khung hình là vấn đề ở cấp độ chứa nhiều hơn so với codec.

Trong mã hóa VFR thông qua, về cơ bản, tệp văn bản sẽ nêu chi tiết tốc độ khung hình so với khung hình / lần nào và trong mã hóa một nguồn, một chức năng như tcfile-in hoặc tcfile-out chuyển các dấu thời gian qua mã hóa , để ánh xạ các vị trí tỷ lệ và giữ cho video phù hợp chủ quan từ nguồn.

Ý tưởng tốc độ khung hình thấp là một ý tưởng hợp lý, nhưng không giải quyết được vì nhiều lý do. Mặc dù x264 có khả năng nhận biết VFR với một số khả năng, tôi không nghĩ có một chức năng phân tích sẽ thay đổi tốc độ khung hình liên quan đến chuyển động để giảm kích thước tệp (theo cách dễ hiểu với nhiều điều khiển bitrate).

Nguồn cũng là một vấn đề: Các nguồn VFR theo mặc định sẽ giữ nguyên độ biến thiên khung của chúng, nhưng rõ ràng mã hóa tệp CFR ở tốc độ bit thay đổi (đôi khi là một ý tưởng tốt, đặc biệt là khi cần telecine) sẽ tạo ra cùng CFR.

Điều này có nghĩa là bạn có thể phải viết lại bitrate bằng tay (tức là dấu thời gian của các cảnh chậm được nhập vào tệp) hoặc sử dụng thuật toán xác định khung hình như dup, depup và chính xácDedup cho avisynth . Nếu video của bạn có chuyển động cực thấp, một số khung hình (thậm chí một nửa?) Sẽ bị loại bỏ. Vấn đề là các thuật toán này không tiên tiến và không đưa ra lựa chọn tốt với cảnh quay "đời thực" như những gì sẽ đóng góp cho mã hóa tốt nhất.

Ngoài ra, việc loại bỏ các khung có chứa những thứ như khung I và B làm giảm lượng chi tiết có sẵn theo thời gian, khiến chuyển động trông có vẻ "nguy hiểm" và có thể can thiệp vào các tham số video cơ bản khác và gây ra hiện tượng như răng cưa.

Và do cách thức hoạt động của bộ lượng tử hóa, x264 sẽ thực sự giảm tốc độ bit một cách không tương xứng hơn nữa trong những cảnh chuyển động thấp này. Trừ khi bạn có một slideshow hình ảnh giống hệt nhau, sẽ có chuyển động (nếu chỉ có hạt và các tạo tác khác) và sẽ có sự mất chất lượng sẽ không được nhìn thấy nếu không có sự thay đổi mạnh mẽ đối với bitrate.

Và cuối cùng, lý do không có nhiều tùy chọn để làm những gì bạn muốn là x264 thực sự tốt trong việc quản lý bitrate chỉ bằng cách sử dụng nén tạm thời (ghi lại các thay đổi trong các khung một phần). Đi tới 1/2 tốc độ khung hình sẽ không giảm kích thước tệp xuống một nửa; 10% có lẽ là một lợi ích thực tế để mong đợi từ chuyển động thấp hoặc hoạt hình.

Vì vậy, trong ngắn hạn, việc giảm tốc độ bit của các cảnh tĩnh sẽ làm rất ít cho kích thước tệp của bạn, nhưng sẽ thêm một loạt các vấn đề về chất lượng và đồng bộ hóa, chưa kể đến việc không tương thích với phần mềm chỉnh sửa video.

Nếu bạn muốn thử dùng bộ giải mã, bạn có thể giới hạn tốc độ khung hình mới tối đa bằng cách sử dụng các tùy chọn cấp độ , mỗi loại có độ phân giải tối đa và tốc độ khung hình. Thật không may, bạn có thể sẽ phải làm việc ở độ phân giải rất thấp để có được tốc độ khung hình bạn muốn, sử dụng các cấu hình. Nó quay trở lại để chỉnh sửa tỷ lệ bằng tay, hoàn toàn hoặc để điều chỉnh tốc độ khung hình mà bạn cho là quá cao. Dù bằng cách nào, sẽ phải tung hứng để giữ âm thanh đồng bộ với các bộ khung mới nếu các thay đổi được thực hiện sau quá trình mã hóa khi tcfile được bảo tồn.

Điều đáng nói là việc dành thời gian tối ưu hóa nhiều cài đặt bitrate sẽ mang lại hiệu quả cao hơn trong cách quản lý kích thước tệp và cải thiện chất lượng video của bạn, thay vì gây ra sự phức tạp khi thu được ít. Giữ nguyên FPS gốc có lẽ là ý tưởng tốt nhất trừ khi bạn nhắm đến các tiêu chuẩn phát sóng hoặc truyền thông. Người chơi có khả năng chơi bitrate biến đổi (không giống như biên tập viên) và càng nhiều khung hình trong video của bạn, phát lại càng mượt và có lẽ kích thước tệp càng nhỏ, do thay đổi chuyển động giữa các khung nhỏ hơn.

Đây là một tập hợp các liên kết đến thông tin tiêu chuẩn và các cuộc thảo luận diễn đàn sẽ giúp với khía cạnh khó hiểu này của mã hóa:

- công cụ decimation avisynth

- Công tắc fps và -r
- x264 Chung (tcfile, fps)
- tiêu chuẩn tệp mã thời gian
- Cấp độ và cấu hình
- Tóm tắt cài đặt CFR / VFR ngắn, rõ ràng (phần "khung hình")

doom9, videohelp và thảo luận lý thuyết
1 2 3 4 5 6 7

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.