From what I can tell, you’re on a ‘wild goose chase’. Your code seems to be working just fine:
> Here's the first RTP packet after PLAY as reported by wireshark: […] > 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… Yes it is. Note that the payload (NAL unit) starts with 0x674D. > Also, when I show what gets into fReceiveBuffer: That’s the only thing you should care about. > 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 …… This is exactly right. It’s the NAL unit - i.e., starting with 0x674D. Note that the “7” means that it a SPS (Sequence Parameter Set) NAL unit. > so I lost 12 more bytes in live555. No, you didn’t ‘lose’ 12 bytes. Those 12 bytes were the RTP header - which our code automatically handles. So, your code’s working just fine, as far as I can tell. (If you were to replace “DummySink” in the “testRTSPClient.cpp” code with “H264VideoFileSink”, you’d end up with a file that (after renaming it to have a “.h264” filename suffix) would probably play just fine in VLC. Alternatively, you can run “openRTSP” <http://www.live555.com/openRTSP/>, and that will also give you a raw H.264 output file that (again, after renaming it to have a “.h264” filename suffix) should play OK in VLC.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
