Hi,
I've been working on capturing an RTSP stream from a Sunba H.264 camera.
O/S is Linux, I have gotten the same result for X86-64 and for ARM
(Raspbian).
Linux len 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Linux pi5 4.1.13-v7+ #826 SMP PREEMPT Fri Nov 13 20:19:03 GMT 2015
armv7l GNU/Linux
I am getting what appeares to be garbage data in fReceiveBuffer in
testRTSPclient..
I seem to have boiled down the problem to this. Here's the first RTP
packet after PLAY as reported by wireshark:
Internet Protocol Version 4, Src: 192.168.1.106 (192.168.1.106), Dst:
192.168.1.11 (192.168.1.11)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
Total Length: 62
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xb6e9 [validation disabled]
Source: 192.168.1.106 (192.168.1.106)
Destination: 192.168.1.11 (192.168.1.11)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: safetynetp (40000), Dst Port: 50868
(50868)
Source port: safetynetp (40000)
Destination port: 50868 (50868)
Length: 42
Checksum: 0x81a3 [validation disabled]
Real-Time Transport Protocol
[Stream setup by RTSP (frame 11)]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
1... .... = Marker: True
Payload type: DynamicRTP-Type-96 (96)
Sequence number: 0
[Extended sequence number: 65536]
Timestamp: 749264400
Synchronization Source identifier: 0x00000000 (0)
Payload: 674d002a95a81e0089f9610000030001000003000284
0000 00 00 00 01 00 06 00 12 14 1b f7 78 00 00 08 00 ...........x....
0010 45 00 00 3e 00 00 40 00 40 11 b6 e9 c0 a8 01 6a E..>..@.@......j
0020 c0 a8 01 0b 9c 40 c6 b4 00 2a 81 a3 80 e0 00 00 .....@...*......
0030 2c a8 de 10 00 00 00 00 67 4d 00 2a 95 a8 1e 00 ,.......gM.*....
0040 89 f9 61 00 00 03 00 01 00 00 03 00 02 84 ..a...........
Looks like a well-formed NAL to my in-expert eyes...
I instrumented readSocket in GroupsocketHelper to display the data right
after the recvfrom:
Read 34 bytes from socket
10/15/16 22:00:50: 80 E0 00 00 2C A8 DE 10 00 00 00 00 67 4D 00 2A
....,.......gM.*
10/15/16 22:00:50: 95 A8 1E 00 89 F9 61 00 00 03 00 01 00 00 03 00
......a.........
10/15/16 22:00:50: 02 84 ..
Note that somebody ate the first 44 bytes of the received packet.
Any thoughts? Maybe it has something to do with the socket options, I
haven't made it to that in the code yet but I thought maybe someone
would know what is going on and have a suggestion.
Also, when I show what gets into fReceiveBuffer:
10/15/16 22:00:50: 67 4D 00 2A 95 A8 1E 00 89 F9 61 00 00 03 00 01
gM.*......a.....
10/15/16 22:00:50: 00 00 03 00 02 84 ......
so I lost 12 more bytes in live555. Maybe that's a side effect of the
malformed data above, I haven't managed to make it all the way through
the code.
Interestingly vlc will play this stream albeit badly with lots of
dropped frames.
TIA,
Len
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
