Re: [Live-devel] Missing 44 bytes

[Len Day]

Thanks, guys. That did it. There's some other issus with the stream from 
the camera but I have it working well enough for what I need.


Len

On 10/16/2016 09:35 PM, Ross Finlayson wrote:

Well, an H264 NAL must begin with 00 00 00 01.

No.  “00 00 00 01” is a standard ‘start code’ that is often put in front NAL 
units when they appear in a byte stream.  But it’s not part of the NAL unit 
itself, and it is not used at all when NAL units are carried within RTP 
packets.  (That’s why it’s not present within the H.264 RTP payload.)

HOWEVER, depending on your decoder, you may need to insert that 4-byte start 
code (“00 00 00 01”) in front of each NAL unit before you pass it to your 
decoder.  I think that’s the case for “libav”.

Also, make sure you read:
http://live555.com/liveMedia/faq.html#testRTSPClient-how-to-decode-data



Here's the DESCRIBE response I'm getting:

[…]
Again, this looks fine.  There seems to be no problem at all with your data; 
just the way you’re handling it.


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


___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Missing 44 bytes

[Ross Finlayson]

> Well, an H264 NAL must begin with 00 00 00 01.

No.  “00 00 00 01” is a standard ‘start code’ that is often put in front NAL 
units when they appear in a byte stream.  But it’s not part of the NAL unit 
itself, and it is not used at all when NAL units are carried within RTP 
packets.  (That’s why it’s not present within the H.264 RTP payload.)

HOWEVER, depending on your decoder, you may need to insert that 4-byte start 
code (“00 00 00 01”) in front of each NAL unit before you pass it to your 
decoder.  I think that’s the case for “libav”.

Also, make sure you read:
http://live555.com/liveMedia/faq.html#testRTSPClient-how-to-decode-data


> Here's the DESCRIBE response I'm getting:
[…]
Again, this looks fine.  There seems to be no problem at all with your data; 
just the way you’re handling it.


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

Re: [Live-devel] Missing 44 bytes

[Len Day]

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=Peek_Spy=1=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=Peek_Spy=1=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/9
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,
 _data,
 _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,
_picture, );

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: 674d002a95a81e0089f96103000103000284

  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” 
, 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


___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Missing 44 bytes

[Ross Finlayson]

> A usual Ethernet header is 14 bytes.   Why do we have 16?

Dunno.  Ask the OP’s ‘Wireshark’.  The rest of the bytes are as I described, 
though.

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

Re: [Live-devel] Missing 44 bytes

[hemant]

A usual Ethernet header is 14 bytes.   Why do we have 16?

Hemant

-Original Message-
From: live-devel [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross 
Finlayson
Sent: Sunday, October 16, 2016 9:52 PM
To: LIVE555 Streaming Media - development & use <live-de...@ns.live555.com>
Subject: Re: [Live-devel] Missing 44 bytes

Just to clarify some more - your ‘missing’ 44 bytes are just the Ethernet 
header (16 bytes), the IP header (20 bytes), and the UDP header (8 bytes).  
Specifically breaking down your ‘Wireshark’ output:




___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Re: [Live-devel] Missing 44 bytes

[Ross Finlayson]

Just to clarify some more - your ‘missing’ 44 bytes are just the Ethernet 
header (16 bytes), the IP header (20 bytes), and the UDP header (8 bytes).  
Specifically breaking down your ‘Wireshark’ output:

>   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………..

We get:
- Ethernet header:
>   00 00 00 01 00 06 00 12 14 1b f7 78 00 00 08 00 ...x….
- IP header:
> 0010  45 00 00 3e 00 00 40 00 40 11 b6 e9 c0 a8 01 6a E..>..@.@..j
> 0020  c0 a8 01 0b
- UDP header:
> 9c 40 c6 b4 00 2a 81 a3
- RTP header (12 bytes):
> 80 e0 00 00 .@...*..
> 0030  2c a8 de 10 00 00 00 00
- RTP payload (i.e., H.264 NAL unit):
> 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………..

Of course, only the last part (the RTP payload - i.e., the H.264 NAL unit) gets 
delivered to your receive buffer.  The OS and our library code handles the rest.

It all looks good to me...


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

Re: [Live-devel] Missing 44 bytes

[Ross Finlayson]

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: 674d002a95a81e0089f96103000103000284
> 
>   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” , 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