[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