Biết tốc độ khung hình của video sẽ không hữu ích như bạn nghĩ.
Trình duyệt sử dụng một số thủ thuật để tạo kết hợp giữa tốc độ khung hình của phim và tốc độ làm mới của màn hình, vì vậy nếu bạn nhìn vào thuộc tính currentTime, bạn sẽ thấy thời lượng khung hình thực tế (== currentTime - trước đây currentTime) không phải là hằng số, nó thay đổi từ khung thành khung.
On video mẫu này: http://jsfiddle.net/3qs46n4z/3/ mô hình là:
4-1-5-1:
4 khung hình ở 21,3 + 1 khung tại 32 + 5 khung hình ở 21,3 + 1 khung tại 32.
Vì vậy, nếu bạn muốn luôn hiển thị khung hình mới nhất trên canvas trong khi tránh quá tải, giải pháp có thể là:
- Trên mỗi rAF, hãy xem thời gian hiện tại của video:
• Tương tự? -> không làm gì cả.
• Đã thay đổi? -> cập nhật khung.
Và bất cứ điều gì bạn muốn làm, so sánh hai currentTime === hai con số có thể là nhanh hơn so với so sánh hai imageDatas ;-)
Edit: nhìn vào thông số kỹ thuật để tìm bằng chứng về câu nói của tôi, tôi tìm thấy một sắc thái với chú giải này:
Which frame in a video stream corresponds to a particular playback position is defined by the video stream's format.
(Ghi chú của 4.8.6 tại http://www.w3.org/TR/2011/WD-html5-20110113/video.html)
Vì vậy, nghiêm nói rằng chúng tôi chỉ có thể nói đó (thời điểm hiện tại là như nhau) ngụ ý (các khung giống nhau).
Tôi chỉ có thể đặt cược rằng nghịch đảo là đúng => thời gian khác nhau có nghĩa là khung khác nhau.
Trong ví dụ trên, Chrome đang cố gắng khớp 24Hz của phim trên máy tính 60Hz của tôi bằng cách cố gắng nhận 45 Hz (= 60/2 + 60/4), gần nhất từ 48 = 2 * 24. Đối với 21 khung được tạo, tôi không biết liệu nó có nội suy hay chỉ sao chép các khung hình.Nó chắc chắn thay đổi tùy thuộc vào trình duyệt/thiết bị (đặc biệt là Gpu). Tôi đặt cược bất kỳ máy tính để bàn gần đây hoặc điện thoại thông minh mạnh mẽ nào nội suy.
Dù sao cho chi phí cao của việc kiểm tra bằng imageData, bạn sẽ vẽ tốt hơn hai lần so với kiểm tra.
Rq1: Tôi tự hỏi mức độ sử dụng chế độ Xor + thử nghiệm với 0 32 bit tại một thời điểm có thể tăng thời gian so sánh. (getImageData là chậm.)
Rq2: Tôi chắc chắn có cách sử dụng tốc độ phát lại để 'đồng bộ hóa' video và hiển thị và biết khung nào là chính hãng (== không được nội suy)) khung. (Vì vậy, hai vượt qua ở đây 1) đồng bộ 2) tua lại và lấy khung).
Rq3: Nếu mục đích của bạn là thu hút mỗi khung hình video và chỉ khung hình của video, trình duyệt không phải là cách để thực hiện. Như đã giải thích ở trên, các trình duyệt (desktop) làm nội suy để phù hợp với tốc độ khung hình hiển thị càng gần càng tốt. Các khung đó là không phải là trong luồng gốc. Thậm chí còn có một số thiết bị nội suy '3D' (2D + thời gian) cao cấp mà các khung hình ban đầu thậm chí không có nghĩa là được hiển thị (!). Mặt khác, nếu bạn đồng ý với luồng đầu ra (nội suy), việc bỏ phiếu trên rAF sẽ cung cấp mỗi khung hình mà bạn nhìn thấy (bạn không thể bỏ lỡ khung hình (ngoại trừ ứng dụng của bạn đang bận làm việc khác).
Rq4: nội suy (== không có khung trùng lặp) là 99,99% khả năng trên gần đây/GPU phong nha cung desktop
Rq5:. Hãy chắc chắn để làm ấm các chức năng của mình (gọi họ là 100 lần trên đầu) và để tạo ra không Để tránh jit/gc tạm dừng
hộp chứa mp4 (nguyên tử MOOV) chứa tốc độ khung hình mục tiêu, vì vậy tôi giả sử useragent đọc và sử dụng nó để kiểm soát mục tiêu playb tỷ lệ ack – Offbeatmammal
@Offbeatmammal, Cảm ơn, thuộc tính đó trên mp4 rất hữu ích ngay cả khi trình duyệt không sử dụng nó để kiểm soát tốc độ phát lại. Tuy nhiên, đó là một giải pháp từng phần vì tôi không thể tìm thấy các thuộc tính khung hình tương tự trên các mã hóa khác. : -/ – markE