Video được chuyển đổi bởi FFMPEG có thời lượng khác nhau, tại sao?


9

Tôi chuyển đổi video bằng FFMPEG. Mục tiêu của tôi là chuyển đổi chúng sang định dạng chứa MP4 ( MPEG-4 Phần 14 ) với luồng âm thanh được mã hóa AAC và luồng video 10-phần MPEG-4 .

Tôi sử dụng dòng sau để chuyển đổi video:

ffmpeg -y -i "{inputFile}" "{outputFile}"

Video được chuyển đổi trông ổn, tuy nhiên thời lượng của luồng trong tệp được chuyển đổi và tệp đầu vào không phải lúc nào cũng khớp.

Tôi đã thực hiện một số thử nghiệm và sự khác biệt về thời lượng chắc chắn là có, tuy nhiên, nó không nhiều - dù sao tôi cũng đang thử nghiệm với các video nhỏ. Đây là kết quả của tôi:

| InputFile  | InputAudio | InputVideo | OutputAudio | OutputVideo  |
|------------|------------|------------|-------------|--------------|
| h.avi      | 3s 631ms   | 3s 567ms   | 3s 668ms    | 3s 567ms     |
| h.flv      | 3s 631ms   | 3s 558ms   | 3s 668ms    | 3s 567ms     |
| h.mov      | 3s 532ms   | 3s 533ms   | 3s 682ms    | 3s 534ms     |
| h.mp4      | 3s 605ms   | 3s 534ms   | 3s 682ms    | 3s 567ms     |
| h.mpg      | 3s 605ms   | 3s 533ms   | 3s 563ms    | 3s 534ms     |
| h.wmv      | 3s 620ms   | 3s 633ms   | 3s 659ms    | 3s 567ms     |

Vì tôi sẽ xây dựng một phần mềm trên đỉnh FFMPEG, tôi sẽ hạnh phúc hơn nếu ít nhất tôi có thể hiểu lý do của sự khác biệt này. Có phải vì một số chuyển mã không cần thiết?

Trong trường hợp này, tôi có thể tắt chuyển mã này để ngăn FFMPEG lấy mẫu lại tệp video đầu vào của mình không?

Nếu tôi không thể tắt nó đi, làm sao tôi có thể chắc chắn (ngoài việc kiểm tra) rằng sự khác biệt này không tỷ lệ thuận với kích thước của video?

Nếu tôi chuyển đổi ví dụ video 10 giờ, sự khác biệt nhiều giây hoặc thậm chí vài phút là không phù hợp với tôi.


1
Tôi nghĩ rằng nó phụ thuộc vào codec đầu vào và đầu ra của bạn. Các codec GOP dài có thể thay đổi thời lượng luồng video để đặt các khung chính ở nơi chúng cần và đóng GOP. Bạn không nên đối mặt với vấn đề này khi chuyển mã từ codec nội bộ sang codec nội bộ. Nếu bạn không cần phải mã hóa lại video, hãy sử dụng tùy chọn 'c: v copy' nếu bộ chứa đích hỗ trợ codec này.
audionuma

Tôi hy vọng sự khác biệt về độ dài sẽ không trở nên tồi tệ hơn với các video dài hơn. Đây có thể là một vấn đề bắt đầu / kết thúc, không phải là tốc độ hay sự cố. Khi tôi xcode thứ với ffmpeg, số lượng khung hình, tốc độ khung hình và độ dài tính bằng giây luôn giữ nguyên. (trừ khi tôi muốn nó thay đổi!).
Peter Cordes

@audionuma: không có codec lành mạnh sẽ thêm / xóa khung. mencoder đôi khi làm, vì đồng bộ hóa / v, TRƯỚC KHI cho khung hình vào codec video. Một codec sẽ đặt các khung hình chính ở nơi mà nó thấy phù hợp (khoảng thời gian cố định hoặc tại các khung cảnh) và khi bộ mã hóa nói với codec rằng đây là khung cuối cùng, nó sẽ đóng GOP cuối cùng, tuy nhiên nó sẽ dài. Ngay cả với vị trí khung hình không thích ứng, không có codec sẽ thêm các khung bổ sung chỉ để làm cho GOP cuối cùng có cùng độ dài!
Peter Cordes

Câu trả lời:


7

Hy vọng lời giải thích này là những gì bạn đang tìm kiếm:

  • Khi bạn chuyển mã sang mã hóa, chẳng hạn như H.264 (MPEG-4 phần 10), bạn cũng nhất thiết phải lấy mẫu lại video, đó là một phần của kỹ thuật nén H.264. Không cần thiết, tôi nghi ngờ nếu đây là lý do bạn gặp phải khoảng cách về thời gian vì việc lấy mẫu lại không nhất thiết ảnh hưởng đến tốc độ xung nhịp của phương tiện truyền thông. Vì vậy, tôi sẽ không lo lắng quá nhiều về việc lấy mẫu lại, nó có thể gây ra một số phương sai, nhưng có lẽ rất khó khăn.

  • Các định dạng chứa mà bạn liệt kê là không liên quan, bởi vì chúng xác định cách nén luồng được đóng gói, trong khi nguồn gốc của sự khác biệt về thời gian là chính việc nén. Các .flvtập tin, ví dụ, có thể chứa một dòng mã hóa bởi những di sản flash Sorenson H.264 codec hoặc các phiên bản mới hơn. Trong trường hợp đầu tiên, bạn sẽ chuyển mã luồng video, nhưng trong trường hợp sau, có thể bạn không - tùy thuộc vào codec âm thanh được sử dụng. Các container .avi.wmvcontainer là bất khả tri về codec, vì vậy không có cách nào để đoán được mã hóa nội dung của chúng.

  • Bạn đã không đề cập đến thời lượng đã được thử nghiệm. Lưu ý rằng ffmpeg theo mặc định hiển thị cho bạn thời lượng xuất hiện trong siêu dữ liệu của tệp và không phải là giá trị được tính toán. Nếu danh sách của bạn dựa trên dữ liệu mà ffmpeg kết xuất như một phần của thông báo giật gân thì bạn nên lưu ý rằng đây là siêu dữ liệu rõ ràng và không phải là giá trị đo thực tế.

  • Đồng bằng trong thời lượng bạn trình bày nằm trong phạm vi của một hoặc hai khung hình trong phạm vi 25 hoặc 30 khung hình / giây. Điều hợp lý là các codec có thể đệm hoặc tách các khung trống theo thuật toán của chúng (hoặc sự gọn gàng của nhà phát triển ...). Nó không ảnh hưởng đến dấu thời gian khi bạn kết hợp các luồng chính xác.

  • Chỉ có hai lý do tôi có thể nghĩ về điều đó có thể thay đổi đáng kể thời lượng phương tiện của bạn, không áp dụng trong trường hợp cụ thể của bạn:

    1. Mã hóa lại ở một tốc độ mục tiêu khác nhau. Đôi khi điều này xảy ra ngoài ý muốn do siêu dữ liệu xấu trong tệp đầu vào. Nhưng không phải trong trường hợp của bạn, như đã lưu ý ở trên, tương ứng với một khung hình duy nhất bị giảm hoặc tăng.

    2. Khi bạn áp dụng một codec tạo lại một trong hai luồng. Ví dụ như tước quảng cáo, phát hiện im lặng, làm sạch tiếng ồn, v.v.

Tóm lại, nếu bạn lo ngại điều gì sẽ xảy ra với video 10 giờ - chỉ cần chạy thử nghiệm thực tế. Nếu bạn gặp rắc rối và tìm kiếm sự trợ giúp thì hãy ghi nhớ để đăng chi tiết codec của tệp đầu vào và phương pháp mà bạn đã đo thời lượng luồng.

Hi vọng điêu nay co ich.


Trên thực tế, định dạng container có lẽ có liên quan. Các container khác nhau lưu trữ dấu thời gian / thời lượng khung khác nhau. Và máy tính độ dài cần mã khác nhau cho các định dạng chứa khác nhau và mã đó có thể hoạt động khác nhau. ví dụ: đếm thời lượng khung hình cuối cùng được hiển thị trong một, nhưng không hiển thị trong một khung khác.
Peter Cordes

@PeterCordes, ý nghĩa của bạn là "độ dài" trong nhận xét của bạn là gì? Nếu bạn muốn có nghĩa là "thời lượng" thì bạn đã nhầm, thời lượng luôn là số khung hình nhân với thời gian. Nếu bạn có ý gì khác thì xin vui lòng cho biết ý của bạn là "chiều dài".
avnr

Ý tôi là thời lượng. Không phải tất cả các video là tốc độ khung hình liên tục. Và cách thời lượng khung được lưu trữ (dưới dạng phân số hoặc bất cứ thứ gì, thường là bội số của một cơ sở thời gian) là khác nhau đối với các thùng chứa khác nhau. Đây là loại lượn sóng và trang điểm bằng tay của tôi, vì tôi đã không xem chi tiết, nhưng tôi khá chắc chắn rằng nó không đơn giản như chúng tôi mong muốn.
Peter Cordes

@PeterCordes, được thôi, nhưng điều này rất hiếm và không thực sự thuộc về nó, nó chỉ được sử dụng trong một số trường hợp cạnh như ghi màn hình, trình chiếu, v.v ... Có một số sử dụng sai thuật ngữ Biến tốc độ khung hình trong phần mềm chỉnh sửa, nhưng thuật ngữ ngắn gọn hơn trong trường hợp của họ là video lai (nghĩa là các luồng có tốc độ hoặc cơ sở thời gian khác nhau, giữ nguyên tốc độ không đổi ban đầu của chúng khi được nối với nhau). Trong trường hợp "phim thông thường" hầu như luôn có tốc độ khung hình đã biết, bất kể thùng chứa thể hiện nó như thế nào trong siêu dữ liệu của nó.
avnr
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.