2012-02-23 35 views
7

Thật không may là tôi vẫn bị mắc kẹt với một chút triển khai giao tiếp RTP/RTCP để truy cập máy ảnh IP của tôi đúng cách.Vấn đề liên lạc RTCP/RTP

gì tôi muốn làm

Chiếc máy ảnh này có một bộ đệm bên trong mà tôi muốn đọc. Vì vậy, tôi giao tiếp với máy ảnh thông qua RTSP và yêu cầu nó truyền dữ liệu. Khi máy ảnh đi qua toàn bộ bộ đệm, quá trình phát trực tuyến sẽ dừng lại.

gì tôi có cho đến nay

  1. Một kết nối TCP mà giao tiếp qua RTSP cho DESCRIBE/SETUP/PLAY Request (RTSP) để có được những dòng bắt đầu. Kết nối này phải vẫn mở khi Máy ảnh truyền dữ liệu của nó.

  2. Cổng mà tôi nhận dữ liệu được gửi qua RTP (dựa trên UDP) - việc xử lý này không phải là mối quan tâm của tôi, tôi thậm chí hoàn toàn không có quyền truy cập vào nó, tôi chỉ muốn đề cập đến nó. .

  3. Ổ cắm UDP nhận RTCP Sender Reports/Source Descriptions. Điều này quan trọng vì tôi không biết khi nào luồng dừng lại (như đã đề cập ở điểm 2, tôi không thể chỉ xem khi nào luồng dừng lại). Trên Ổ cắm này tôi đọc cho đến khi RTCP Sender Report Goodbye xuất hiện, có nghĩa là quá trình phát trực tuyến đã kết thúc. Sau đó, tôi có thể đóng TCP Socket (từ giao tiếp RTSP ).

gì đang xảy ra sai

Nó đang làm việc cho kích thước bộ đệm nhỏ như 2MB hoặc 4MB. Tôi nhận được một số Mô tả nguồn và sau đó là Goodbye. Nhưng trong trường hợp thử nghiệm cụ thể của tôi, tôi muốn sử dụng 16MB (mà vẫn còn ít hơn một nửa những gì máy ảnh có khả năng). Tôi nhận được Báo cáo người gửi nhưng tại một số điểm (luôn ở mức 8MB +/- 300KB) máy ảnh chỉ dừng gửi.

Đáng chú ý là thực tế tôi có thể truy cập bộ đệm thông qua VLC mà không gặp vấn đề gì. Tôi thậm chí còn nhìn vào thông tin liên lạc (RTSP và RTCP) là gần như hoàn toàn giống như trong ứng dụng của tôi ... một điều thiếu tôi đề cập đến sẽ dưới đây:

lý do có thể

này là phần mà tôi cần lời khuyên của bạn.

Khả năng: Thiếu Receiver Reports

Khi truyền qua VLC tôi nhận thấy rằng có một số RTCP Receiver Reports gửi từ VLC để camera (cyclic như Sender Reports). Vì vậy, nó có thể được rằng camere hy vọng ít nhất một Receiver Report trong một thời gian cụ thể (hoặc sau khi một số tiền cụ thể của byte gửi)? Hiện tại tôi không thể nghĩ ra bất kỳ lý do nào khác.

Giải pháp?

  • Nếu chúng ta giả định rằng camera ngừng chảy vì không có Receiver Reports Tôi muốn biết nếu có một cách để thực hiện chúng mà không mang đến nhiều thông tin. Tôi đã đọc một số trong số RFC 3550 và tôi đoán vẫn còn một loạt logic đằng sau các thông báo Báo cáo đó. Bây giờ tôi thực sự không cần và vì vậy tôi cũng không muốn để triển khai giao thức RTCP hoàn chỉnh tại đây. Có đủ để gửi một số khung hình giả Receiver Report để máy ảnh tiếp tục phát trực tiếp không? Nếu vậy, họ trông như thế nào?

  • Nếu nó không liên quan đến việc thiếu Receiver Reports và tôi không cần đến chúng, thì lý do gì để máy ảnh ngừng phát trực tuyến? Bất kỳ đề xuất?

Edit:

Được rồi tôi chỉ quản lý để tạo ra một số loại Dummy Receiver Report và có vẻ như để làm việc (tôi chỉ có thể nhận được 12MB Rồi tôi bị mong muốn Tạm biệt)

Tôi chỉ đã điền vào bộ đệm 28Byte và chỉ sử dụng một số giá trị trong trường Tiêu đề, có nghĩa là:

buffer[0] = 0x80; // Version 2 , Padding = false, Reception Count = 0 
buffer[1] = 0xC9; // Packet Type 201 Receiver Report 
buffer[2] = 0x00; // Higher byte for total length 
buffer[3] = 0x06; // Lower byte for total length (in 32 Bit words -> 28 Byte) 

Phần còn lại của bộ đệm tôi chỉ chứa đầy số không. Vâng, tôi biết nó chỉ là một hack và bạn không nên nói với trẻ em của bạn để chương trình như thế này.

Bây giờ câu hỏi của tôi thay đổi một chút: Điều này có ổn với bản hack này không? Dường như nó hoạt động, nhưng tôi vẫn hơi lo lắng rằng máy ảnh của tôi sẽ sử dụng những dữ liệu giả và thay đổi cấu hình này vì nó sẽ xen lẫn một số thứ lạ trong đó?

+0

Bạn đã cân nhắc sử dụng thư viện RTP hiện có để xử lý việc này? – nos

+0

@nos Tất nhiên đây sẽ là một sự thay thế nhưng tôi thực sự muốn tránh việc sử dụng bất kỳ thư viện nào vì tôi chỉ muốn luồng được giữ sống - Thậm chí không cần phải phân tích cú pháp từ RTCP (mong đợi nếu đó là lời tạm biệt) Thông báo tất nhiên). Thứ hai toàn bộ ứng dụng cần phải được hoàn toàn không đồng bộ vì vậy tôi muốn quản lý tất cả các ổ cắm vv của bản thân mình. Hầu hết các libs sẽ kiểm soát các ổ cắm và kết nối của riêng họ. Nhưng nếu tôi thực sự cần phải điền vào các báo cáo nhận đúng (với một số dữ liệu "phức tạp") tôi có thể thực sự xem xét một lib – Toby

+0

Bạn đã thực hiện một capture gói wireshark trong khi các ứng dụng đang chạy? Điều này sẽ cho bạn biết chính xác những gì đang xảy ra hoặc không xảy ra với dữ liệu của bạn. –

Trả lời

1

Bạn nên tự mình đọc dữ liệu từ luồng. Bằng cách đó bạn có thể cung cấp cho các báo cáo nhận thực sự thay vì các báo cáo giả.

Nếu bạn cần chuyển tiếp nó đến một cổng khác cho một ứng dụng hoặc thư viện khác, bạn chỉ cần làm điều đó.

+0

Tôi thực sự muốn tiết kiệm bất kỳ tài nguyên nào tôi có (thiết bị nhúng), vì vậy tôi muốn tránh đọc tất cả dữ liệu này. Nó sẽ là khá không cần thiết vì tôi không cần nó (ngoại trừ RTCP) anyway. Vì vậy, tôi thực sự thích làm điều đó với một số giá trị giả. – Toby

+0

Trong khi bạn có thể không "cần" nó, máy chủ làm như vậy nó có thể điều chỉnh/điều tiết dữ liệu để ngăn chặn lũ lụt mạng và mất gói. – Deanna

1

Báo cáo bộ thu (RR) có thể được sử dụng bởi một số máy ảnh dưới dạng tin nhắn "giữ nguyên". Thay vào đó, bạn có thể thử gửi cho bạn máy ảnh GET_PARAMETER mỗi phút để giữ tin nhắn còn sống, nếu GET_PARAMETER được máy ảnh chấp nhận. Xem những gì nó cho bạn biết để đáp ứng với DESCRIBE.

Một số máy ảnh IP không thể phân tích cú pháp RR đúng cách. Tôi thực sự đang cố gắng ngăn chặn thư viện Live555 mà tôi sử dụng trong ứng dụng khách của tôi từ việc gửi tin nhắn RR vì một số kiểu máy ảnh Samsung bỏ kết nối (theo sự hỗ trợ kỹ thuật của họ).