[Live-devel] Missing 44 bytes

Sun Oct 16 21:24:11 PDT 2016

Thanks for getting back so quickly. I do see the MAC for the camera in 
the first 16 bytes.

Well, an H264 NAL must begin with 00 00 00 01. At least that's what I 
read... Maybe I'm not reading enough. Do I have some other format?

When I pass the data that I do get to avcodec_decode_video2 I get a 
message that says it can't find the start word and it seg faults. That's 
what got me going down this path... Maybe I need a different codec? I 
don't find an AVC or MP4 codec. Of course I realize that libav isn't 
yours... But maybe you know anyway...

Here's the DESCRIBE response I'm getting:

Sending request: DESCRIBE 
rtsp://192.168.1.106:554/user=led&password=Peek_Spy&channel=1&stream=0.sdp?real_stream 
RTSP/1.0
CSeq: 2
User-Agent: scd (LIVE555 Streaming Media v2016.09.22)
Accept: application/sdp

Received 650 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
Content-Type: application/sdp
Server: H264DVR 1.0
Cseq: 2
Content-Base: 
rtsp://192.168.1.106:554/user=led&password=Peek_Spy&channel=1&stream=0./
Cache-Control: private
x-Accept-Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Content-Length: 374

v=0
o=- 38990265062388 38990265062388 IN IP4 192.168.1.106
s=RTSP Session
c=IN IP4 192.168.1.106
t=0 0
a=control:*
a=range:npt=0-
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=range:npt=0-
a=framerate:0S
a=fmtp:96 profile-level-id=4d002a; packetization-mode=1; 
sprop-parameter-sets=Z00AKpWoHgCJ+WEAAAMAAQAAAwAChA==,aO48gA==
a=framerate:25
a=control:trackID=3

BTW, wireshark says that packet is malformed bit it seems to decode OK.

Yes, I know avcodec_decode_video2 is deprecated, is that the problem? 
I'm trying to make some code I lifted from an example work before 
messing with it too much... Maybe you know a better example you can 
point me at?

This is my init for libav (error checking removed for brevity), do I 
need to use a different codec?

     avcodec_register_all();

     m_av_codec = avcodec_find_decoder(AV_CODEC_ID_H264);
     m_av_codec_ctx = avcodec_alloc_context3(m_av_codec);
     if (m_av_codec->capabilities & CODEC_CAP_TRUNCATED)
     {
     m_av_codec_ctx->flags |= CODEC_FLAG_TRUNCATED;
     }

     stat = avcodec_open2(m_av_codec_ctx, m_av_codec, 0);
     m_av_parser = av_parser_init(AV_CODEC_ID_H264);

When my after frame gets called, I do

     f_len = av_parser_parse2(m_av_parser,
                  m_av_codec_ctx,
                  &f_data,
                  &f_size,
                  m_frame_buffer,
                  m_buf_bytes,
                  0,
                  0,
                  AV_NOPTS_VALUE);

If f_len > 0 && size > 0 I do

     len = avcodec_decode_video2(m_av_codec_ctx,
                 m_av_frame,
                 &got_picture, &pkt);

which is where my seg fault is.

Len

On 10/16/2016 06:21 PM, Ross Finlayson wrote:
>  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/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel