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

[Live-devel] Missing 44 bytes

[Len Day]

Hi,

I've been working on capturing an RTSP stream from a Sunba H.264 camera. 
O/S is Linux, I have gotten the same result for X86-64 and for ARM 
(Raspbian).


Linux len 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40 
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Linux pi5 4.1.13-v7+ #826 SMP PREEMPT Fri Nov 13 20:19:03 GMT 2015 
armv7l GNU/Linux



I am getting what appeares to be garbage data in fReceiveBuffer in 
testRTSPclient..


I seem to have boiled down the problem to this. Here's the first RTP 
packet after PLAY as reported by wireshark:


Internet Protocol Version 4, Src: 192.168.1.106 (192.168.1.106), Dst: 
192.168.1.11 (192.168.1.11)

Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: 
Not-ECT (Not ECN-Capable Transport))

Total Length: 62
Identification: 0x (0)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xb6e9 [validation disabled]
Source: 192.168.1.106 (192.168.1.106)
Destination: 192.168.1.11 (192.168.1.11)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: safetynetp (4), Dst Port: 50868 
(50868)

Source port: safetynetp (4)
Destination port: 50868 (50868)
Length: 42
Checksum: 0x81a3 [validation disabled]
Real-Time Transport Protocol
[Stream setup by RTSP (frame 11)]
10..  = Version: RFC 1889 Version (2)
..0.  = Padding: False
...0  = Extension: False
  = Contributing source identifiers count: 0
1...  = Marker: True
Payload type: DynamicRTP-Type-96 (96)
Sequence number: 0
[Extended sequence number: 65536]
Timestamp: 749264400
Synchronization Source identifier: 0x (0)
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...

I instrumented readSocket in GroupsocketHelper to display the data right 
after the recvfrom:


Read 34 bytes from socket
10/15/16 22:00:50: 80 E0 00 00 2C A8 DE 10 00 00 00 00 67 4D 00 2A  
,...gM.*
10/15/16 22:00:50: 95 A8 1E 00 89 F9 61 00 00 03 00 01 00 00 03 00  
..a.

10/15/16 22:00:50: 02 84  ..

Note that somebody ate the first 44 bytes of the received packet.

Any thoughts? Maybe it has something to do with the socket options, I 
haven't made it to that in the code yet but I thought maybe someone 
would know what is going on and have a suggestion.


Also, when I show what gets into fReceiveBuffer:

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

so I lost 12 more bytes in live555. Maybe that's a side effect of the 
malformed data above, I haven't managed to make it all the way through 
the code.


Interestingly vlc will play this stream albeit badly with lots of 
dropped frames.


TIA,
Len

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

Re: [Live-devel] ProxyServerMediaSession for Transcoding

[Ross Finlayson]

> Based on your earlier post I was able to understand how to use filter for 
> transcoding.and I'am able to transcode the video stream.
> 
> However I have one problem in it. I cannot use 1 stream coming from the 
> camera to be transcoded to multiple transcoded images. 

When you say “1 stream from the camera […] transcoded to multiple transcoded 
images” do you mean:
1) the ability for multiple 'front-end' clients to access the proxy 
stream concurrently, with each of these front-end clients getting an 
(identical) copy of the transcoded stream, or
2) allowing the proxy server to serve two (or more) different named 
streams that come from a single input ‘back-end’ stream, with each of the 
proxied streams being transcoded into a different codec and/or a different 
resolution?

If you’re asking for 1), then this already happens automatically.  If multiple 
‘front-end’ clients access the proxy server, then they will each automatically 
get a copy of the transcoded stream (yet the transcoding will be done only 
once).

However, if you’re asking for 2), then this is not possible with the current 
proxy server.  What you *can* do, however, is have two (or more) separate 
“ProxyServerMediaSession” objects, each using the same ‘back-end’ “rtsp://“ 
URL, but transcoded differently.  This will cause multiple copies of the 
‘back-end’ stream to come from the camera to the proxy server.  (You could 
avoid this, however, by putting *another* proxy server between the proxy server 
and the ‘back-end’ camera stream.)


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