h264 Dấu thời gian RTP

Question

Tôi có sự nhầm lẫn về dấu thời gian của gói RTP h264. Tôi biết tốc độ đồng hồ treo tường của video là 90KHz mà tôi đã xác định trong SIP SDP. Tốc độ khung hình của bộ mã hóa của tôi không chính xác là 30 FPS, nó biến đổi. Nó thay đổi từ 15 FPS đến 30 FPS khi đang bay. Vì vậy, tôi không thể sử dụng bất kỳ dấu thời gian cố định nào.

Có thể bất kỳ ai cho tôi biết dấu thời gian của gói được mã hóa sau đây không.
Sau 0 milisecond được mã hóa Dấu thời gian RTP = 0 (Để dấu thời gian bắt đầu 0)
Sau 50 milisecond được mã hóa Dấu thời gian RTP =?
Sau 40 milisecond được mã hóa RTP timestamp =?
Sau 33 giây được mã hóa RTP dấu thời gian =?

Công thức khi tốc độ khung hình được mã hóa là gì?

Cảm ơn bạn trước.

Answer 1

Không quan trọng nếu bộ mã hóa của bạn mã hóa video ở 10FPS hoặc 30FPS, với dấu thời gian RTP bạn cho người nhận biết khoảng thời gian tạm dừng giữa hai khung là bao nhiêu. Vì vậy, bạn xác định rằng trên bay cho mỗi khung hình. Bằng cách đó bạn có thể gửi 10 khung hình trong một giây (10 khung hình/giây) và trong giây khác, bạn có thể gửi 30 khung hình (30 khung hình/giây). Bạn chỉ cần đặt dấu thời gian RTP chính xác. Và nếu tôi nhận được câu hỏi của bạn, bạn đang nghi ngờ cách thực hiện việc này ...

Để dấu thời gian bắt đầu bằng 0, bạn thêm thời gian đồng hồ treo tường bằng mili giây nhân với 100 vào dấu thời gian RTP cuối cùng hoặc bạn có thể sử dụng bất kỳ thang thời gian nào bạn muốn. Để thực hiện các bộ giải mã giải mã video 10fps với tốc độ 30fps, thêm 333.000 đến RTP timestamp cho mỗi gói ... nhưng cho phép nhìn vào ví dụ của bạn:

Frame #  RTP Time Time between frames [ms] 
[ 1]    0 0 
[ 2]   50000 50 
[ 3]   90000 40 
[ 4]   420000 33 

Vì vậy, nếu bạn thiết lập RTP timestamp như (Time in ms * 100000) này, bạn sẽ làm cho tải bộ giải mã và giải mã Frame 1, sau đó tải và giải mã Frame 2, nhưng nó sẽ ngủ 50 ms (khác biệt thời gian giữa Frame 1 và Frame 2) trước khi nó vẽ Frame 2, và ...

Và như bạn có thể thấy, bộ giải mã sử dụng dấu thời gian RTP để biết khi nào hiển thị từng dấu thời gian và nó không quan tâm nếu video được mã hóa ở mức 30 hoặc 10 khung hình/giây.

Ngoài ra, nếu video là 30 khung hình/giây, điều đó không có nghĩa là mỗi giây sẽ có 30 gói RTP. Đôi khi có thể có nhiều hơn 100, do đó bạn không thể có công thức đảm bảo tính toán dấu thời gian RTP chính xác.

Tôi đoán rằng đây là những gì bạn cần ... hy vọng tôi đã giúp, không -1 tôi nếu tôi didnt ... =)

Answer 2

Không có công thức đơn giản cho việc này.

Ngay lập tức được sử dụng để lấy mẫu khung trước khi mã hóa được gọi là PTS (dấu thời gian trình bày). Nó nằm ngoài phạm vi của bộ mã hóa, bạn phải nhớ nó trong luồng dữ liệu của bạn khi bạn chụp các khung hình.

Từ đó, bạn có 2 khả năng:

1. Các bộ mã hóa H264 không tạo B-frame, sau đó dấu thời gian RTP nên là PTS + ngẫu nhiên bù đắp (giống nhau cho tất cả các phiên truyền)
2. Nếu bộ mã hóa tạo ra các khung B (hoặc B-lát), thì thứ tự giải mã cần được sửa đổi, vì khung B yêu cầu khung tiếp theo phải được giải mã, vì vậy nó phải được gửi trước đó.

Trong trường hợp thứ hai, RFC6184 tuyên bố rằng bạn có nhiều cách để truyền đơn vị NAL được mã hóa.

Phần lớn phần mềm phát trực tuyến sẽ sử dụng chế độ "Không xen kẽ", trong đó, bạn phải đặt dấu thời gian RTP thành bù PTS +, nhưng gửi chúng theo thứ tự giải mã sao cho dấu thời gian sẽ không tăng đơn điệu. Điều này cũng có nghĩa là khách hàng sẽ phải giải mã theo thứ tự nhận được và không sắp xếp lại các khung theo thứ tự PTS.

tôi không sử dụng thuật ngữ DTS đây vì một lý do, bởi vì bạn không cần giải mã timestamp để làm việc này, chỉ có đơn đặt hàng.

Chế độ cuối cùng được mô tả trong RFC6184 là cái gọi là thứ tự xen kẽ nơi bạn có thể sắp xếp lại các đơn vị NAL. Trong trường hợp đó, bạn phải thực hiện một số logic ứng dụng để sắp xếp lại các đơn vị, tham khảo RFC6184 để biết chi tiết.