[Live-devel] Receiving H.264 RTP stream from Sony network cameras ...

[Ganesh V]

Hi Kamil,

In Livemedia exmaple applications, you attach a 0x00 00 00 01 after you receive the packet. In the packet which you received, the first octet is as per the standard which has F, NRI, NALU Type. Attaching the pattern above (which is actually NALU start code) is for file dump cases. 

Decoders require that start code to distinguish between NALUs. However, if a decoder is connected at the back-end of Livemedia streaming application, the same can also be made to decode directly (prob without start code). 

Livemedia library follows RFC 3984 correctly and its implementation is to cater to a large variety of decoders.

Hope this help.

Cheers,
Ganesh




________________________________
From: kd <kamildobk at poczta.onet.pl>
To: live-devel at ns.live555.com
Sent: Sunday, June 21, 2009 11:22:34 PM
Subject: [Live-devel] Receiving H.264 RTP stream from Sony network cameras ...

 
Hi,
 
Each packet passed 
to ProcessSpecialHeader() is prefixed with 001 but I noticed that 
for this functions the first byte in a packet is always a NAL type, so it always 
reads NAL of type 0. I'm not sure but it doesn't look like RFC 3984. 
Maybe is this a some separate standard of streaming, which is not 
supported by LiveMedia ?  
Why 224.0.0.x multicast addresses dont work in 
LiveMedia ? This camera has a default multicast address in 224.0.0.x 
group, which is, for some unknown reasons, blocked out in LiveMedia. I've 
made changes to IsMulticastAddress(), and now it is working fine, but I don't 
know if this modification won't have some side 
effects. 
And a one more general question, what would be the 
best way to transform the unit h264 stream ( without prefixes ) into a byte 
stream ( with NAL prefixes ) without parsing a whole media stream. Is there any 
requirement that one rtp packet can contain at most one NAL unit ? If 
not, how to detect a packets which contains more than one NAL unit ? How to find 
NAL unit boundaries in such packets ?
 
Regards,
Kamil 


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20090621/0f69987c/attachment.html>