[Live-devel] Missing 44 bytes
Ross Finlayson
finlayson at live555.com
Sun Oct 16 18:21:50 PDT 2016
>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..>.. at .@......j
> 0020 c0 a8 01 0b 9c 40 c6 b4 00 2a 81 a3 80 e0 00 00 ..... at ...*......
> 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/
More information about the live-devel
mailing list