From markuss at sonicfoundry.com Thu May 2 11:52:02 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Thu, 2 May 2013 18:52:02 +0000 Subject: [Live-devel] playSIP - creates empty file Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D010EA889@postal.sonicfoundry.net> I am trying to record the audio from a Polycom Telepresence m100 SIP software client. On 10.0.71.24 I run a software VTC client configure to use SIP (Polycom Telepresence m100). The URI is sip:10.0.71.24 at 10.0.71.24 On 10.0.71.109 I run the live555 command line tool playSIP calling 10.0.71.24. playSIP creates only a zero length file named: audio-PCMU-1 Any advice? Thanks Markus. The connecting is established - output from playSIP: ==== START: playSIP debug output ========================================================================== Sending request: INVITE sip:10.0.71.24 at 10.0.71.24 SIP/2.0 From: 10.0.71.24 ;tag=4201176568 Via: SIP/2.0/UDP 10.0.71.109:64250 Max-Forwards: 70 To: sip:10.0.71.24 at 10.0.71.24 Contact: sip:10.0.71.24 at 10.0.71.109:64250 Call-ID: 2759522855 at 10.0.71.109 CSeq: 1 INVITE Content-Type: application/sdp User-Agent: Test_playSIP.exe (LIVE555 Streaming Media v2013.04.16) Content-Length: 123 v=0 o=- 2759522855 0 IN IP4 10.0.71.109 s=Test_playSIP.exe session c=IN IP4 10.0.71.109 t=0 0 m=audio 8000 RTP/AVP 0 Received INVITE response: SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.0.71.109:64250 From: "10.0.71.24" ;tag=4201176568 To: "markuss" ;tag=FA32ABC5-B2C76DF4 CSeq: 1 INVITE Call-ID: 2759522855 at 10.0.71.109 Contact: User-Agent: Polycom Telepresence m100/1.0.5.29417_4151 Content-Length: 0 Received INVITE response: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.0.71.109:64250 From: "10.0.71.24" ;tag=4201176568 To: "markuss" ;tag=FA32ABC5-B2C76DF4 CSeq: 1 INVITE Call-ID: 2759522855 at 10.0.71.109 Contact: User-Agent: Polycom Telepresence m100/1.0.5.29417_4151 Content-Length: 0 Received INVITE response: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.0.71.109:64250 From: "10.0.71.24" ;tag=4201176568 To: "markuss" ;tag=FA32ABC5-B2C76DF4 CSeq: 1 INVITE Call-ID: 2759522855 at 10.0.71.109 Contact: Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRAC K, UPDATE, REFER User-Agent: Polycom Telepresence m100/1.0.5.29417_4151 Content-Type: application/sdp Content-Length: 879 v=0 o=- 1367513200 1367513200 IN IP4 10.0.71.24 s=Polycom IP Phone c=IN IP4 10.0.71.24 b=AS:64 t=0 0 m=audio 8000 RTP/AVP 118 115 114 113 99 98 97 102 101 103 9 15 0 8 119 a=sendrecv a=rtpmap:118 SIRENLPR/16000 a=fmtp:118 bitrate=48000 a=rtpmap:115 G7221/32000 a=fmtp:115 bitrate=48000 a=rtpmap:114 G7221/32000 a=fmtp:114 bitrate=32000 a=rtpmap:113 G7221/32000 a=fmtp:113 bitrate=24000 a=rtpmap:99 SIREN14/16000 a=fmtp:99 bitrate=48000 a=rtpmap:98 SIREN14/16000 a=fmtp:98 bitrate=32000 a=rtpmap:97 SIREN14/16000 a=fmtp:97 bitrate=24000 a=rtpmap:102 G7221/16000 a=fmtp:102 bitrate=32000 a=rtpmap:101 G7221/16000 a=fmtp:101 bitrate=24000 a=rtpmap:103 G7221/16000 a=fmtp:103 bitrate=16000 a=rtpmap:9 G722/8000 a=fmtp:9 bitrate=64000 a=rtpmap:15 G728/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:119 telephone-event/8000 a=fmtp:119 0-15 Opened URL "sip:10.0.71.24 at 10.0.71.24", returning a SDP description: v=0 o=- 2759522855 0 IN IP4 10.0.71.109 s=Test_playSIP.exe session c=IN IP4 10.0.71.109 t=0 0 m=audio 8000 RTP/AVP 0 Created receiver for "audio/PCMU" subsession (client ports 8000-8001) Setup "audio/PCMU" subsession (client ports 8000-8001) Created output file: "audio-PCMU-1" Sending request: ACK sip:10.0.71.24 at 10.0.71.24 SIP/2.0 From: 10.0.71.24 ;tag=4201176568 Via: SIP/2.0/UDP 10.0.71.109:64250 Max-Forwards: 70 To: sip:10.0.71.24 at 10.0.71.24;tag=FA32ABC5-B2C76DF4 Call-ID: 2759522855 at 10.0.71.109 CSeq: 1 ACK Content-Length: 0 Started playing session Receiving streamed data (for up to 60.000000 seconds)... ==== END: playSIP debug output ========================================================================== ==== START: 10.0.71.109 (playSIP host) network log ============================================================ Captured on 10.0.71.109 17 1:34:56 PM 5/2/2013 1.4581485 10.0.71.109 10.0.71.24 SDP SDP:Request: INVITE sip:10.0.71.24 at 10.0.71.24 SIP/2.0; SDP:SessionName=Test_playSIP.exe session, Version=0, MediaDescription=audio 8000 RTP/AVP 0 {SIP:17, UDP:16, IPv4:15} 18 1:34:56 PM 5/2/2013 1.4617849 10.0.71.24 10.0.71.109 SIP SIP:Response: SIP/2.0 100 Trying {SIP:17, UDP:16, IPv4:15} 19 1:34:56 PM 5/2/2013 1.4716476 10.0.71.24 10.0.71.109 SIP SIP:Response: SIP/2.0 180 Ringing {SIP:17, UDP:16, IPv4:15} 42 1:34:59 PM 5/2/2013 4.6255978 10.0.71.24 10.0.71.109 SDP SDP:Response: SIP/2.0 200 OK; SDP:SessionName=Polycom IP Phone, Version=0, MediaDescription=audio 8000 RTP/AVP 118 115 114 113 99 98 97 102 101 103 9 15 0 8 119 {SIP:17, UDP:16, IPv4:15} 44 1:34:59 PM 5/2/2013 4.6385918 10.0.71.109 10.0.71.24 SIP SIP:Request: ACK sip:10.0.71.24 at 10.0.71.24 SIP/2.0 {SIP:17, UDP:16, IPv4:15} 50 1:35:00 PM 5/2/2013 5.5851924 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 0, TimeStamp = 0 {UDP:38, IPv4:15} 52 1:35:00 PM 5/2/2013 5.6130255 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 1, TimeStamp = 160 {UDP:38, IPv4:15} 53 1:35:00 PM 5/2/2013 5.6131312 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 2, TimeStamp = 320 {UDP:38, IPv4:15} 54 1:35:00 PM 5/2/2013 5.6452028 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 3, TimeStamp = 480 {UDP:38, IPv4:15} 55 1:35:01 PM 5/2/2013 5.6729429 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 4, TimeStamp = 640 {UDP:38, IPv4:15} 56 1:35:01 PM 5/2/2013 5.6729429 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 5, TimeStamp = 800 {UDP:38, IPv4:15} 58 1:35:01 PM 5/2/2013 5.7052129 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 6, TimeStamp = 960 {UDP:38, IPv4:15} 59 1:35:01 PM 5/2/2013 5.7330918 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 7, TimeStamp = 1120 {UDP:38, IPv4:15} 60 1:35:01 PM 5/2/2013 5.7331906 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 8, TimeStamp = 1280 {UDP:38, IPv4:15} 61 1:35:01 PM 5/2/2013 5.7650426 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 9, TimeStamp = 1440 {UDP:38, IPv4:15} 62 1:35:01 PM 5/2/2013 5.8048753 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 10, TimeStamp = 1600 {UDP:38, IPv4:15} 63 1:35:01 PM 5/2/2013 5.8048753 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 11, TimeStamp = 1760 {UDP:38, IPv4:15} 64 1:35:01 PM 5/2/2013 5.8327720 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 12, TimeStamp = 1920 {UDP:38, IPv4:15} 65 1:35:01 PM 5/2/2013 5.8328593 10.0.71.24 10.0.71.109 RTP RTP:PayloadType = PCMU Audio, 8000Hz [1 Channel], SSRC = 242919752, Seq = 13, TimeStamp = 2080 {UDP:38, IPv4:15} [snip] 164 1:35:02 PM 5/2/2013 7.5641524 10.0.71.109 10.0.71.24 RTCP RTCP:RTCP compound packet - Number of packets = 0x2 {UDP:49, IPv4:15} ==== END: 10.0.71.109 (playSIP host) network log ============================================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu May 2 12:48:43 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 2 May 2013 12:48:43 -0700 Subject: [Live-devel] playSIP - creates empty file In-Reply-To: <1ED2F9A76678E0428E90FB2B6F93672D010EA889@postal.sonicfoundry.net> References: <1ED2F9A76678E0428E90FB2B6F93672D010EA889@postal.sonicfoundry.net> Message-ID: <1A6C92E6-E541-49B7-A251-79A934CA123F@live555.com> > I am trying to record the audio from a Polycom Telepresence m100 SIP software client. > > On 10.0.71.24 I run a software VTC client configure to use SIP (Polycom Telepresence m100). > The URI is sip:10.0.71.24 at 10.0.71.24 > > On 10.0.71.109 I run the live555 command line tool playSIP calling 10.0.71.24. > > playSIP creates only a zero length file named: audio-PCMU-1 > > Any advice? The problem here is that our SDP parsing code currently only notes the first RTP payload format number in a SDP "m=" line (because our RTP processing code currently doesn't handle more than one RTP payload format code being used in a RTP stream). Your server's SDP "m=" line is m=audio 8000 RTP/AVP 118 115 114 113 99 98 97 102 101 103 9 15 0 8 119 > which is legal, but our code would be able to handle it if the "0" (i.e., PCMU) payload format code were first - e.g. m=audio 8000 RTP/AVP 0 118 115 114 113 99 98 97 102 101 103 9 15 8 119 because "0" (i.e., PCMU) RTP payload format happens to be the only RTP payload format that's used in this stream. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Thu May 2 12:08:10 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Thu, 2 May 2013 19:08:10 +0000 Subject: [Live-devel] H264 dropped P frames Message-ID: <615FD77639372542BF647F5EBAA2DBC22530D4EE@IL-BOL-EXCH01.smartwire.com> I have used live555 for years. I am updated to 2013.04.30. I tested with OpenRTSP on the command line with old and new versions of live555 and VLC on Linux and Windows, all work. I am trying to debug an issue with H264 from security cameras and my recorder/restreamer. I am hoping someone can give me an idea of where to look, I have been on this for days(longer). It appears at first debug to be deep in the live555 code; even though, to be honest, that is puzzling : If I run OpenRTSP on the command line and dump the frames into a file, all the frames are there and I can feed it back into VLC and it plays. In my code I am missing a lot of the P_FRAMES frame right after the I_FRAME. I then am randomly missing a few P_FRAMES randomly. The thing is I instrumented the code and all frames I am called back with in the afterGettingFrame are handled. I just do not get called on some frames. The entire NAL is dropped. Almost like there is some random drop packet test code going on. This has been happening for a long time but I now have a camera that is very sensitive to it and instead of occasional artifacts, It is a key frame then grey. TIA Jeff Shanab, Manager-Software Engineering D 630.633.4515 | C 630.453.7764 | F 630.633.4815 | jshanab at smartwire.com [MVSSig] This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 18265 bytes Desc: image001.gif URL: From finlayson at live555.com Thu May 2 13:09:30 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 2 May 2013 13:09:30 -0700 Subject: [Live-devel] H264 dropped P frames In-Reply-To: <615FD77639372542BF647F5EBAA2DBC22530D4EE@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC22530D4EE@IL-BOL-EXCH01.smartwire.com> Message-ID: <8210F492-CDEC-4508-82FE-00B2125241CE@live555.com> > If I run OpenRTSP on the command line and dump the frames into a file, all the frames are there and I can feed it back into VLC and it plays. > In my code I am missing a lot of the P_FRAMES frame right after the I_FRAME. I then am randomly missing a few P_FRAMES randomly. To me, this looks like packet loss - either on the network, or within your OS. In case of the latter, I suspect that there may be insufficient OS socket buffering. If so, your application should be able to increase this; see: http://www.live555.com/liveMedia/faq.html#packet-loss Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markuss at sonicfoundry.com Thu May 2 13:44:01 2013 From: markuss at sonicfoundry.com (Markus Schumann) Date: Thu, 2 May 2013 20:44:01 +0000 Subject: [Live-devel] playSIP - creates empty file In-Reply-To: <1A6C92E6-E541-49B7-A251-79A934CA123F@live555.com> References: <1ED2F9A76678E0428E90FB2B6F93672D010EA889@postal.sonicfoundry.net> <1A6C92E6-E541-49B7-A251-79A934CA123F@live555.com> Message-ID: <1ED2F9A76678E0428E90FB2B6F93672D010EA8C1@postal.sonicfoundry.net> How can I fix this? Thanks Markus. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, May 02, 2013 2:49 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] playSIP - creates empty file I am trying to record the audio from a Polycom Telepresence m100 SIP software client. On 10.0.71.24 I run a software VTC client configure to use SIP (Polycom Telepresence m100). The URI is sip:10.0.71.24 at 10.0.71.24 On 10.0.71.109 I run the live555 command line tool playSIP calling 10.0.71.24. playSIP creates only a zero length file named: audio-PCMU-1 Any advice? The problem here is that our SDP parsing code currently only notes the first RTP payload format number in a SDP "m=" line (because our RTP processing code currently doesn't handle more than one RTP payload format code being used in a RTP stream). Your server's SDP "m=" line is m=audio 8000 RTP/AVP 118 115 114 113 99 98 97 102 101 103 9 15 0 8 119 which is legal, but our code would be able to handle it if the "0" (i.e., PCMU) payload format code were first - e.g. m=audio 8000 RTP/AVP 0 118 115 114 113 99 98 97 102 101 103 9 15 8 119 because "0" (i.e., PCMU) RTP payload format happens to be the only RTP payload format that's used in this stream. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Thu May 2 13:38:45 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Thu, 2 May 2013 20:38:45 +0000 Subject: [Live-devel] H264 dropped P frames In-Reply-To: <8210F492-CDEC-4508-82FE-00B2125241CE@live555.com> References: <615FD77639372542BF647F5EBAA2DBC22530D4EE@IL-BOL-EXCH01.smartwire.com> <8210F492-CDEC-4508-82FE-00B2125241CE@live555.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC22530D5D3@IL-BOL-EXCH01.smartwire.com> Thankyou. I think I was able to confirm this with a printing breakpoint in doGetNextFrame1() inside the if (fPacketLossInFragmentedFrame). I also get a TCP_Zero window warning if tcp and socket unreachable if Udp Could it be that the packets are incorrect and live555 cannot find the beginning and end, so it doesn't clear out the buffer? Then it hits the max, dumps it and starts over. This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, May 02, 2013 3:10 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] H264 dropped P frames If I run OpenRTSP on the command line and dump the frames into a file, all the frames are there and I can feed it back into VLC and it plays. In my code I am missing a lot of the P_FRAMES frame right after the I_FRAME. I then am randomly missing a few P_FRAMES randomly. To me, this looks like packet loss - either on the network, or within your OS. In case of the latter, I suspect that there may be insufficient OS socket buffering. If so, your application should be able to increase this; see: http://www.live555.com/liveMedia/faq.html#packet-loss Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu May 2 13:50:02 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 2 May 2013 13:50:02 -0700 Subject: [Live-devel] playSIP - creates empty file In-Reply-To: <1ED2F9A76678E0428E90FB2B6F93672D010EA8C1@postal.sonicfoundry.net> References: <1ED2F9A76678E0428E90FB2B6F93672D010EA889@postal.sonicfoundry.net> <1A6C92E6-E541-49B7-A251-79A934CA123F@live555.com> <1ED2F9A76678E0428E90FB2B6F93672D010EA8C1@postal.sonicfoundry.net> Message-ID: <35D8A8C7-938B-4C98-95EA-9B3A48500063@live555.com> > How can I fix this? For now, only by (somehow) reconfiguring your Polycom server so that it puts "0" first in the list of RTP payload format types in the SDP "m=" line. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu May 2 14:04:08 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 2 May 2013 14:04:08 -0700 Subject: [Live-devel] H264 dropped P frames In-Reply-To: <615FD77639372542BF647F5EBAA2DBC22530D5D3@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC22530D4EE@IL-BOL-EXCH01.smartwire.com> <8210F492-CDEC-4508-82FE-00B2125241CE@live555.com> <615FD77639372542BF647F5EBAA2DBC22530D5D3@IL-BOL-EXCH01.smartwire.com> Message-ID: <2891CC22-85E8-4ED3-9B10-FCCC5300935F@live555.com> > Could it be that the packets are incorrect and live555 cannot find the beginning and end, so it doesn?t clear out the buffer? Then it hits the max, dumps it and starts over. No, but note that if - as with all payload formats - if one frame (in this case, one H.264 NAL unit) is fragmented over multiple RTP packets, then if any one of these RTP packets gets lost, then the entire NAL unit will get discarded. That's why - yet again - H.264 encoders should not create excessively large NAL units. In any case, everyone (and especially you :-) needs to read and understand this sentence that's at the end of the FAQ entry: ********** It's important to understand that because a LIVE555 Streaming Media application runs as a single thread (never writing to, or reading from, sockets concurrently), if packet loss occurs, then it MUST be happening either (i) on the network, or (ii) in the operating system of the sender or receiver. There's nothing in our code that can be 'losing' packets. ********** Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Thu May 2 14:37:30 2013 From: jshanab at smartwire.com (Jeff Shanab) Date: Thu, 2 May 2013 21:37:30 +0000 Subject: [Live-devel] H264 dropped P frames In-Reply-To: <2891CC22-85E8-4ED3-9B10-FCCC5300935F@live555.com> References: <615FD77639372542BF647F5EBAA2DBC22530D4EE@IL-BOL-EXCH01.smartwire.com> <8210F492-CDEC-4508-82FE-00B2125241CE@live555.com> <615FD77639372542BF647F5EBAA2DBC22530D5D3@IL-BOL-EXCH01.smartwire.com> <2891CC22-85E8-4ED3-9B10-FCCC5300935F@live555.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC22530D69C@IL-BOL-EXCH01.smartwire.com> Thanks. I do understand how the event model works (Quite eloquent BTW). The fact that it throws away complete NAL units if a piece of a fragment has loss explains why it appears as dropping NALs. Here is the only part I cannot figure out. Why does it not lose any packets if I use OpenRtsp on the command line. Why does VLC have no problem with the video live. Almost like the sender is not following standard flow control and only a simple flat out copy will grab it fast enough. This is not high resolution or large NALS. 21k for a key frame 1K-2K for the P-Frames 30fps with a GOP size that varies but averages 38. My class is almost identical to the PLayCommon.cpp + OpenRtsp.cpp code. I have a memorySink, filter, and async file writing queue. This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, May 02, 2013 4:04 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] H264 dropped P frames Could it be that the packets are incorrect and live555 cannot find the beginning and end, so it doesn't clear out the buffer? Then it hits the max, dumps it and starts over. No, but note that if - as with all payload formats - if one frame (in this case, one H.264 NAL unit) is fragmented over multiple RTP packets, then if any one of these RTP packets gets lost, then the entire NAL unit will get discarded. That's why - yet again - H.264 encoders should not create excessively large NAL units. In any case, everyone (and especially you :-) needs to read and understand this sentence that's at the end of the FAQ entry: ********** It's important to understand that because a LIVE555 Streaming Media application runs as a single thread (never writing to, or reading from, sockets concurrently), if packet loss occurs, then it MUST be happening either (i) on the network, or (ii) in the operating system of the sender or receiver. There's nothing in our code that can be 'losing' packets. ********** Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From megaplace at hotmail.com Fri May 3 23:48:39 2013 From: megaplace at hotmail.com (Krishna Patel) Date: Sat, 4 May 2013 06:48:39 +0000 Subject: [Live-devel] H264 dropped P frames In-Reply-To: <615FD77639372542BF647F5EBAA2DBC22530D69C@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC22530D4EE@IL-BOL-EXCH01.smartwire.com>, <8210F492-CDEC-4508-82FE-00B2125241CE@live555.com>, <615FD77639372542BF647F5EBAA2DBC22530D5D3@IL-BOL-EXCH01.smartwire.com>, <2891CC22-85E8-4ED3-9B10-FCCC5300935F@live555.com>, <615FD77639372542BF647F5EBAA2DBC22530D69C@IL-BOL-EXCH01.smartwire.com> Message-ID: I have no problems receiving 150+Kb K-frames over UDP with Live555. What I do is increase socket receive buffer and make sure I don't block CUMediaSink::continuePlaying() for too long. In fact, all my implementation of CUMediaSink::continuePlaying() does is move received sample into my private queue. All sample processing is done on separate thread. Krishna.From: jshanab at smartwire.com To: live-devel at ns.live555.com Date: Thu, 2 May 2013 21:37:30 +0000 Subject: Re: [Live-devel] H264 dropped P frames Thanks. I do understand how the event model works (Quite eloquent BTW). The fact that it throws away complete NAL units if a piece of a fragment has loss explains why it appears as dropping NALs. Here is the only part I cannot figure out. Why does it not lose any packets if I use OpenRtsp on the command line.Why does VLC have no problem with the video live. Almost like the sender is not following standard flow control and only a simple flat out copy will grab it fast enough. This is not high resolution or large NALS.21k for a key frame 1K-2K for the P-Frames 30fps with a GOP size that varies but averages 38. My class is almost identical to the PLayCommon.cpp + OpenRtsp.cpp code. I have a memorySink, filter, and async file writing queue. This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, May 02, 2013 4:04 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] H264 dropped P frames Could it be that the packets are incorrect and live555 cannot find the beginning and end, so it doesn?t clear out the buffer? Then it hits the max, dumps it and starts over. No, but note that if - as with all payload formats - if one frame (in this case, one H.264 NAL unit) is fragmented over multiple RTP packets, then if any one of these RTP packets gets lost, then the entire NAL unit will get discarded. That's why - yet again - H.264 encoders should not create excessively large NAL units. In any case, everyone (and especially you :-) needs to read and understand this sentence that's at the end of the FAQ entry: ********** It's important to understand that because a LIVE555 Streaming Media application runs as a single thread (never writing to, or reading from, sockets concurrently), if packet loss occurs, then it MUST be happening either (i) on the network, or (ii) in the operating system of the sender or receiver. There's nothing in our code that can be 'losing' packets. ********** 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From braden at blacksumac.com Mon May 6 16:41:38 2013 From: braden at blacksumac.com (Braden Ackerman) Date: Mon, 6 May 2013 19:41:38 -0400 Subject: [Live-devel] Buffer underrrun PCM->uLaw Message-ID: Greetings, I'm trying to stream uLaw audio from our ios-app to an arm based board via RTP. I've been following testWAVAudioStreamer and using uLawFromPCMAudioSource except that I'm getting the audio data from a call back that's sent from an AudioQueue (ios) instead of from file. Basically streaming from a device. I've written a sub class of FramedSource. The issue I'm having seems to be buffer under run. If I let the buffer build up a bit before starting the thread with live555 in it, the playback is perfect until the buffer gets closer to empty. Normally, (or after the built up buffer is depleted, which happens quickly) the audio then sounds like it's skipping. 0.5 second or so of audio, silence, repeat. I've tried: - Sleeping in deliverFrame() until the buffer has data (stupid, for sure). - Implementing an eventTrigger to call deliverFrame0() when the buffer has data. - I've investigated the "watchVariable" but I don't feel this is applicable to my problem. Currently the source is: 16-bit mono PCM @ 8k sample rate. mRecordFormat.mSampleRate = 8000.0; mRecordFormat.mChannelsPerFrame = 1; mRecordFormat.mFormatFlags = kLinearPCMFormatFlagIsSignedInteger | kLinearPCMFormatFlagIsPacked; mRecordFormat.mBitsPerChannel = 16; mRecordFormat.mBytesPerPacket = mRecordFormat.mBytesPerFrame = (mRecordFormat.mBitsPerChannel / 8) * mRecordFormat.mChannelsPerFrame; mRecordFormat.mFramesPerPacket = 1; I'm putting it through uLawFromPCMAudioSource, is there any chance it's expecting a different sample rate? I have the ability to record directly in uLaw, but I don't see a "Source" for uLaw audio. So, I used the uLawFromPCMAudioSource and record in 16bit mono PCM. I'm going to be posting the source of this portion of the app when it's working properly for all to use. Thanks for your time folks. As well, thanks for the work on an excellent library. -Braden Ackerman P.S. VLC complains like this: main warning: buffer way too early (-685667), clearing queue main warning: timing screwed, stopping resampling main warning: buffer too late (179500), up-sampling main warning: buffer way too late (358875), dropping buffer main warning: buffer way too late (230875), dropping buffer main warning: buffer way too late (355750), dropping buffer main warning: buffer way too late (227750), dropping buffer main warning: buffer way too late (355750), dropping buffer main warning: buffer way too late (227750), dropping buffer From finlayson at live555.com Mon May 6 18:08:43 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 6 May 2013 18:08:43 -0700 Subject: [Live-devel] Buffer underrrun PCM->uLaw In-Reply-To: References: Message-ID: <1648612F-5088-4C4B-932E-B8C7E7538F06@live555.com> I suspect that the problem is that you are not (in your "FramedSource" subclass) setting "fDurationInMicroseconds" before delivering each chunk of PCM data (to your downstream "uLawFromPCMAudioSource" filter). Before completing the delivery (i.e., before calling "FramedSource::afterGetting()"), you should set "fDurationInMicroseconds" based on the number of samples in the chunk of data, and the sampling frequency. (If you don't set "fDurationInMicroseconds", then it will get set to the default value of 0, which will cause the downstream "RTPSink" object to request new data immediately after sending each RTP packet. Because you're streaming from a buffer, that's probably not what you want.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fernandogrgo at gmail.com Tue May 7 05:53:58 2013 From: fernandogrgo at gmail.com (Fernando Gros Gonzalez) Date: Tue, 7 May 2013 14:53:58 +0200 Subject: [Live-devel] Live play OpenRTSP Message-ID: Hello, I'm using openRTSP to receive a stream from a server. Everything works well, I can output the stream to a file and watch it when the session is finished. The problem is that I would like to see it live, I mean at the same time I receive the stream I want to play it. Is there any way to do it? Thank you! Fernando -------------- next part -------------- An HTML attachment was scrubbed... URL: From johns at vbrick.com Tue May 7 15:24:00 2013 From: johns at vbrick.com (John Senior) Date: Tue, 7 May 2013 22:24:00 +0000 Subject: [Live-devel] Potential enhancement for SAP/SDP parser Message-ID: <53AE0F5E21A72D4DB9939B16C5B0BD830149B73F@EX2K10MB2.vb.loc> Hello live555 Support, I work for VBrick Systems and VLC is popular with our streaming appliance customers. We've received several requests to make VBrick's H.264 live streaming appliance SAPs compatible with the VLC SAP listener. (VBrick MPEG-2 and Windows Media streaming appliance SAPs are already compatible with VLC.) Our experiments show that one line in our H.264 SAP is causing the trouble -- the time description line, or "t=0,0". This is an example of our H.264 SAP message that will not appear on the VLC playlist: v=0 o=- 0000000000 1 IN IP4 172.22.113.64 s=JohnS-7000 Program 1 i=VBrick Streaming Video c=IN IP4 239.22.113.66/63 b=AS:8102 a=packetsize:1452 a=packetformat:RAW a=mux:m2t a=author:My Author a=copyright:My Copyright a=X-StreamID:T2 a=tool:VBrick 3.0.0 t=0,0 m=video 4444 udp 33 a=X-H264_TTSVidV1 m=audio 4444 udp 36 a=X-H264_TTSAudV1 But our experiments show that just a minor modification to move the t=0,0 line above the attribute lines will get it to appear on the VLC playlist, like this: v=0 o=- 0000000000 1 IN IP4 172.22.113.64 s=JohnS-7000 Program 1 i=VBrick Streaming Video c=IN IP4 239.22.113.66/63 b=AS:8102 t=0,0 a=packetsize:1452 a=packetformat:RAW a=mux:m2t a=author:My Author a=copyright:My Copyright a=X-StreamID:T2 a=tool:VBrick 3.0.0 m=video 4444 udp 33 a=X-H264_TTSVidV1 m=audio 4444 udp 36 a=X-H264_TTSAudV1 The VLC SAP configuration options "Try to parse the announce" and "SAP Strict mode" do not seem to affect VLC's behavior with our H.264 SAPs. Unfortunately, we are reluctant to change this on our side because we deliberately moved the "t=0,0" line in our newer H.264 appliances (as compared to our older MPEG-2 appliances) to achieve better alignment with Section 5 of RFC 4566: Some lines in each description are REQUIRED and some are OPTIONAL, but all MUST appear in exactly the order given here (the fixed order greatly enhances error detection and allows for a simple parser). OPTIONAL items are marked with a "*". Session description v= (protocol version) o= (originator and session identifier) s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information -- not required if included in all media) b=* (zero or more bandwidth information lines) One or more time descriptions ("t=" and "r=" lines; see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more media descriptions Time description t= (time the session is active) r=* (zero or more repeat times) Media description, if present m= (media name and transport address) i=* (media title) c=* (connection information -- optional if included at session level) b=* (zero or more bandwidth information lines) k=* (encryption key) a=* (zero or more media attribute lines) I posted this information to the VLC developer forum and I was told that in this case the SAP/SDP parsing is being handled by the live555 library that in integrated with VLC. (VLC version is 2.0.6) Would the live555 supporters consider enhancing their SAP/SDP parser to be more flexible and more compatible with RFC 4566? Thanks for your help. Regards, - John John Senior | VP of Systems Engineering | VBrick Systems, Inc. | 203-303-0117 | johns at vbrick.com From finlayson at live555.com Tue May 7 15:44:43 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 7 May 2013 15:44:43 -0700 Subject: [Live-devel] Potential enhancement for SAP/SDP parser In-Reply-To: <53AE0F5E21A72D4DB9939B16C5B0BD830149B73F@EX2K10MB2.vb.loc> References: <53AE0F5E21A72D4DB9939B16C5B0BD830149B73F@EX2K10MB2.vb.loc> Message-ID: <34218D44-A0C8-4519-B1A3-B733988B04A6@live555.com> > Unfortunately, we are reluctant to change this on our side because we deliberately moved the "t=0,0" line in our newer H.264 appliances (as compared to our older MPEG-2 appliances) to achieve better alignment with Section 5 of RFC 4566 I'm puzzled by this, because Section 5 of RFC 4566 (the section that you quoted) says that > One or more time descriptions ("t=" and "r=" lines; see below) must appear before: > a=* (zero or more session attribute lines) Therefore, putting the "t=0,0" line above the attributes line is *correct*, and so it's what you should be doing in the SDP descriptions that you generate. (Also, although not directly relevant to this email, another thing that's wrong with your SDP description is your use of the static payload type 36, which isn't defined anywhere.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ ps. If you haven't already done so, you should consider using the "LIVE555 Streaming Media" software in your own server products; it would likely save you a lot of work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue May 7 18:12:01 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 7 May 2013 18:12:01 -0700 Subject: [Live-devel] Live play OpenRTSP In-Reply-To: References: Message-ID: <7CB06C2A-F5CF-4623-8508-96640161A3A3@live555.com> > I'm using openRTSP to receive a stream from a server. Everything works well, I can output the stream to a file and watch it when the session is finished. The problem is that I would like to see it live, I mean at the same time I receive the stream I want to play it. Is there any way to do it? Probably the easiest way to do this would be to use the "LIVE555 Proxy Server": http://www.live555.com/proxyServer/ You can start up the proxy server, streaming from your server. Then, using the "rtsp://" URL that the proxy server displays, you can connect to this stream using both "openRTSP" (to record the stream) and a media play like VLC (to play it). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yogesh_marathe at ti.com Tue May 7 21:12:15 2013 From: yogesh_marathe at ti.com (Marathe, Yogesh) Date: Wed, 8 May 2013 04:12:15 +0000 Subject: [Live-devel] SRTP support Message-ID: <6EFDC7CD849764409289BF330AF9704A3EA45DE9@DBDE04.ent.ti.com> Does live555 support SRTP? Regards, Yogesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue May 7 21:27:46 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 7 May 2013 21:27:46 -0700 Subject: [Live-devel] SRTP support In-Reply-To: <6EFDC7CD849764409289BF330AF9704A3EA45DE9@DBDE04.ent.ti.com> References: <6EFDC7CD849764409289BF330AF9704A3EA45DE9@DBDE04.ent.ti.com> Message-ID: > Does live555 support SRTP? No, not yet, although it probably will someday. (It will likely be a "LIVE555 Funded Project") Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yogesh_marathe at ti.com Tue May 7 22:04:46 2013 From: yogesh_marathe at ti.com (Marathe, Yogesh) Date: Wed, 8 May 2013 05:04:46 +0000 Subject: [Live-devel] SRTP support In-Reply-To: References: <6EFDC7CD849764409289BF330AF9704A3EA45DE9@DBDE04.ent.ti.com> Message-ID: <6EFDC7CD849764409289BF330AF9704A3EA45E57@DBDE04.ent.ti.com> Ok. Thanks for the information. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, May 08, 2013 9:58 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] SRTP support Does live555 support SRTP? No, not yet, although it probably will someday. (It will likely be a "LIVE555 Funded Project") Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Thu May 9 12:04:03 2013 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Thu, 09 May 2013 12:04:03 -0700 Subject: [Live-devel] A couple of minor issues Message-ID: <518BF323.5010402@schuckmannacres.com> I just thought I'd bring up a couple of minor code issues that I recently ran into. 1. config.armlinux has carriage return line feed line endings and none of the other config files have this. Normally I wouldn't care but my automated build system uses quilt and patch to add -D defines to the compile options and patch under cygwin has problems with this type of line ending. I can work around it but it is annoying and it took me a while to figure out what the problem was. 2. Why is Boolean a #define, for MSC and BORLAND compilers this is really bad form. Currently it is causing me problems with boost template code that uses Boolean for a typename in a template, can it be a typedef? 3. What is the deal with header files directly in liveMeda (i.e. not in liveMedia/include) I would assume that we are not supposed to use them but one of my developers recently used the BitVector.hh header, which seems reasonably general purpose should it be moved to the include directory? Thanks, Matt S. From finlayson at live555.com Thu May 9 18:42:49 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 May 2013 18:42:49 -0700 Subject: [Live-devel] A couple of minor issues In-Reply-To: <518BF323.5010402@schuckmannacres.com> References: <518BF323.5010402@schuckmannacres.com> Message-ID: <7DB9A2EC-2887-47F6-817C-C9E175A4EE1F@live555.com> > 1. config.armlinux has carriage return line feed line endings and none of the other config files have this. OK, this will be fixed in the next release of the software. > 2. Why is Boolean a #define, for MSC and BORLAND compilers this is really bad form. Currently it is causing me problems with boost template code that uses Boolean for a typename in a template, can it be a typedef? I imagine so. I'll try making this change in the next release of the software. I'm a bit wary, though, because I've been burned so many times in the past. It seems that whenever I make a change to satisfy one Windows person, inevitably another Windows person pipes up several few weeks later saving that the change somehow breaks for them. But I'll make the change, and wait to see who complains about it :-) > 3. What is the deal with header files directly in liveMeda (i.e. not in liveMedia/include) I would assume that we are not supposed to use them That's correct. > but one of my developers recently used the BitVector.hh header, which seems reasonably general purpose should it be moved to the include directory? Yes, I suppose. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at honeywell.com Thu May 9 19:07:38 2013 From: Giridhara.Kalkere at honeywell.com (Kalkere, Giridhara(IE10)) Date: Fri, 10 May 2013 02:07:38 +0000 Subject: [Live-devel] Setting the frame rate and resolution during the rtsp connection Message-ID: <955512E27CA4E9478883ACDCA9CA40C6942DA8@IE1AEX3007.global.ds.honeywell.com> Dear Ross, I am using the LIVE555 Frame work for the IP camera streaming. Basically camera is set for a frame rate and resolution. I can set these parameters in the camera web page. But would like to stream the camera with my own framerate and resolution, this will be decided dynamically. I am using the RTSPClient class to establish the connection. It will be great if you can guide me to handle this scenario. Is there any facility or mechanism in the LIVE55 framework to do this? Thanks and Regards, Giri -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu May 9 23:03:36 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 May 2013 23:03:36 -0700 Subject: [Live-devel] Setting the frame rate and resolution during the rtsp connection In-Reply-To: <955512E27CA4E9478883ACDCA9CA40C6942DA8@IE1AEX3007.global.ds.honeywell.com> References: <955512E27CA4E9478883ACDCA9CA40C6942DA8@IE1AEX3007.global.ds.honeywell.com> Message-ID: <2AA41900-7DFF-4724-A59E-33EDAF2D3569@live555.com> > I am using the LIVE555 Frame work for the IP camera streaming. > > Basically camera is set for a frame rate and resolution. I can set these parameters in the camera web page. > But would like to stream the camera with my own framerate and resolution, this will be decided dynamically. Unfortunately I don't think I understand your question. You want to use parameters - that were passed to your camera's web server - to configure your camera's encoder (with a particular frame rate and resolution). So just do this. This has nothing to to with RTSP, and certainly has nothing to do with "RTSPClient". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at honeywell.com Fri May 10 04:56:34 2013 From: Giridhara.Kalkere at honeywell.com (Kalkere, Giridhara(IE10)) Date: Fri, 10 May 2013 11:56:34 +0000 Subject: [Live-devel] Setting the frame rate and resolution during the rtsp connection In-Reply-To: <2AA41900-7DFF-4724-A59E-33EDAF2D3569@live555.com> References: <955512E27CA4E9478883ACDCA9CA40C6942DA8@IE1AEX3007.global.ds.honeywell.com> <2AA41900-7DFF-4724-A59E-33EDAF2D3569@live555.com> Message-ID: <955512E27CA4E9478883ACDCA9CA40C6942FB5@IE1AEX3007.global.ds.honeywell.com> I am sorry for the confusion. I want to ask the camera to provide the mpeg/h264 stream at particular frame rate and resolution. Most of the IP cameras will have the in build webserver where we can login to the camera web page and configure it. During from my application I need to ask the camera to provide the stream with a particular frame rate and resolution irrespective of what is set in camera web page. Since I am using the LIVE555 framework I would like to understand is there any mechanism or facility to achieve this. For example. The MPEG url could be Rtsp://:/mpeg4 I need to pass frame rate and resolution along with this. I hope the question is clear. Thanks and Regards, Giri From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, May 10, 2013 2:04 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Setting the frame rate and resolution during the rtsp connection I am using the LIVE555 Frame work for the IP camera streaming. Basically camera is set for a frame rate and resolution. I can set these parameters in the camera web page. But would like to stream the camera with my own framerate and resolution, this will be decided dynamically. Unfortunately I don't think I understand your question. You want to use parameters - that were passed to your camera's web server - to configure your camera's encoder (with a particular frame rate and resolution). So just do this. This has nothing to to with RTSP, and certainly has nothing to do with "RTSPClient". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hackeron at gmail.com Fri May 10 06:55:35 2013 From: hackeron at gmail.com (Roman Gaufman) Date: Fri, 10 May 2013 14:55:35 +0100 Subject: [Live-devel] Setting the frame rate and resolution during the rtsp connection In-Reply-To: <955512E27CA4E9478883ACDCA9CA40C6942FB5@IE1AEX3007.global.ds.honeywell.com> References: <955512E27CA4E9478883ACDCA9CA40C6942DA8@IE1AEX3007.global.ds.honeywell.com> <2AA41900-7DFF-4724-A59E-33EDAF2D3569@live555.com> <955512E27CA4E9478883ACDCA9CA40C6942FB5@IE1AEX3007.global.ds.honeywell.com> Message-ID: Some cameras have rtsp://ip/media?width=640&height=480&fps=30 - other cameras have profiles like rtsp://ip/axis-media/media.amp?videocodec=h264&streamprofile=highquality - others will not allow specifying quality/profile/fps at all in the URL. These days, cameras that support ONVIF can be configured using WS-Discovery using a SOAP API over UDP e.g. http://stackoverflow.com/questions/13416193/how-to-discover-onvif-devices-in-c-sharp Once again, this is nothing to do with live555 but rather with your camera manufacturer and how they decided to implement it. On 10 May 2013 12:56, Kalkere, Giridhara(IE10) < Giridhara.Kalkere at honeywell.com> wrote: > I am sorry for the confusion. **** > > ** ** > > I want to ask the camera to provide the mpeg/h264 stream at particular > frame rate and resolution. **** > > ** ** > > Most of the IP cameras will have the in build webserver where we can login > to the camera web page and configure it. **** > > ** ** > > During from my application I need to ask the camera to provide the stream > with a particular frame rate and resolution irrespective of what is set in > camera web page.**** > > ** ** > > Since I am using the LIVE555 framework I would like to understand is there > any mechanism or facility to achieve this. **** > > ** ** > > For example. **** > > The MPEG url could be **** > > Rtsp://:/mpeg4 **** > > ** ** > > I need to pass frame rate and resolution along with this. **** > > ** ** > > I hope the question is clear.**** > > ** ** > > Thanks and Regards,**** > > Giri**** > > ** ** > > *From:* live-devel-bounces at ns.live555.com [mailto: > live-devel-bounces at ns.live555.com] *On Behalf Of *Ross Finlayson > *Sent:* Friday, May 10, 2013 2:04 AM > *To:* LIVE555 Streaming Media - development & use > *Subject:* Re: [Live-devel] Setting the frame rate and resolution during > the rtsp connection**** > > ** ** > > I am using the LIVE555 Frame work for the IP camera streaming.**** > > **** > > Basically camera is set for a frame rate and resolution. I can set these > parameters in the camera web page.**** > > But would like to stream the camera with my own framerate and resolution, > this will be decided dynamically. **** > > ** ** > > Unfortunately I don't think I understand your question.**** > > ** ** > > You want to use parameters - that were passed to your camera's web server > - to configure your camera's encoder (with a particular frame rate and > resolution). So just do this. This has nothing to to with RTSP, and > certainly has nothing to do with "RTSPClient".**** > > ** ** > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at honeywell.com Fri May 10 07:15:21 2013 From: Giridhara.Kalkere at honeywell.com (Kalkere, Giridhara(IE10)) Date: Fri, 10 May 2013 14:15:21 +0000 Subject: [Live-devel] Setting the frame rate and resolution during the rtsp connection In-Reply-To: References: <955512E27CA4E9478883ACDCA9CA40C6942DA8@IE1AEX3007.global.ds.honeywell.com> <2AA41900-7DFF-4724-A59E-33EDAF2D3569@live555.com> <955512E27CA4E9478883ACDCA9CA40C6942FB5@IE1AEX3007.global.ds.honeywell.com> Message-ID: <955512E27CA4E9478883ACDCA9CA40C694305F@IE1AEX3007.global.ds.honeywell.com> Thanks for the details. Regards, Giri From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Roman Gaufman Sent: Friday, May 10, 2013 9:56 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Setting the frame rate and resolution during the rtsp connection Some cameras have rtsp://ip/media?width=640&height=480&fps=30 - other cameras have profiles like rtsp://ip/axis-media/media.amp?videocodec=h264&streamprofile=highquality - others will not allow specifying quality/profile/fps at all in the URL. These days, cameras that support ONVIF can be configured using WS-Discovery using a SOAP API over UDP e.g. http://stackoverflow.com/questions/13416193/how-to-discover-onvif-devices-in-c-sharp Once again, this is nothing to do with live555 but rather with your camera manufacturer and how they decided to implement it. On 10 May 2013 12:56, Kalkere, Giridhara(IE10) > wrote: I am sorry for the confusion. I want to ask the camera to provide the mpeg/h264 stream at particular frame rate and resolution. Most of the IP cameras will have the in build webserver where we can login to the camera web page and configure it. During from my application I need to ask the camera to provide the stream with a particular frame rate and resolution irrespective of what is set in camera web page. Since I am using the LIVE555 framework I would like to understand is there any mechanism or facility to achieve this. For example. The MPEG url could be Rtsp://:/mpeg4 I need to pass frame rate and resolution along with this. I hope the question is clear. Thanks and Regards, Giri From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, May 10, 2013 2:04 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Setting the frame rate and resolution during the rtsp connection I am using the LIVE555 Frame work for the IP camera streaming. Basically camera is set for a frame rate and resolution. I can set these parameters in the camera web page. But would like to stream the camera with my own framerate and resolution, this will be decided dynamically. Unfortunately I don't think I understand your question. You want to use parameters - that were passed to your camera's web server - to configure your camera's encoder (with a particular frame rate and resolution). So just do this. This has nothing to to with RTSP, and certainly has nothing to do with "RTSPClient". 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Fri May 10 09:40:28 2013 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Fri, 10 May 2013 09:40:28 -0700 Subject: [Live-devel] A couple of minor issues In-Reply-To: <7DB9A2EC-2887-47F6-817C-C9E175A4EE1F@live555.com> References: <518BF323.5010402@schuckmannacres.com> <7DB9A2EC-2887-47F6-817C-C9E175A4EE1F@live555.com> Message-ID: <518D22FC.8060203@schuckmannacres.com> Thanks, I understand about the Windows thing, fyi I tried it as a typedef and it seemed fine. Matt S. On 5/9/2013 6:42 PM, Ross Finlayson wrote: >> 1. config.armlinux has carriage return line feed line endings and >> none of the other config files have this. > > OK, this will be fixed in the next release of the software. > > >> 2. Why is Boolean a #define, for MSC and BORLAND compilers this is >> really bad form. Currently it is causing me problems with boost >> template code that uses Boolean for a typename in a template, can it >> be a typedef? > > I imagine so. I'll try making this change in the next release of the > software. > > I'm a bit wary, though, because I've been burned so many times in the > past. It seems that whenever I make a change to satisfy one Windows > person, inevitably another Windows person pipes up several few weeks > later saving that the change somehow breaks for them. > > But I'll make the change, and wait to see who complains about it :-) > > >> 3. What is the deal with header files directly in liveMeda (i.e. not >> in liveMedia/include) I would assume that we are not supposed to use them > > That's correct. > >> but one of my developers recently used the BitVector.hh header, which >> seems reasonably general purpose should it be moved to the include >> directory? > > Yes, I suppose. > > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From braden at blacksumac.com Fri May 10 10:50:38 2013 From: braden at blacksumac.com (Braden Ackerman) Date: Fri, 10 May 2013 13:50:38 -0400 Subject: [Live-devel] Audio skipping - Seems to be timing related Message-ID: Greetings, Thank you Ross for your response mid-week. I believe I've correctly implemented your suggestion, but I'm still experiencing the same issue. Recap: I'm trying to send mu-law audio over RTP. The audio comes from the microphone on an ios device, via AudioQueue. I'm following testWaveAudioStreamer. I've subclassed FramedSource and pass the audio through uLawFromPCMAudioSource after it's stored in a circular FIFO buffer (after being returned from the ios AudioQueue callback after mic capture). Issue: I get "skipping" ~ 0.5 sec audio, then ~ 0.5 sec silence. The buffer is still under running (causing a sleep in deliverFrame() which I believe should never be happening once I have this correctly implemented). As per Ross' excellent suggestion I've set fDurationInMicroseconds like this: int fNumChannels =1; int fBitsPerSample = 16; int fSamplingFrequency = 8000; unsigned fPlayTimePerSample = 1e6/(double)fSamplingFrequency; unsigned bytesPerSample = (fNumChannels*fBitsPerSample)/8; fDurationInMicroseconds =(unsigned)((fPlayTimePerSample*fFrameSize)/ bytesPerSample); ----- The fDurationInMicroseconds works out to 500000 microseconds, which would make sense as each buffer returned from the ios AudioQueue is about 0.5 seconds. I'll paste some output from VLC. If anyone can point me in the right direction to correct my error here I'd appreciate it immensely. FYI, I'll be posting this code publicly once it's working for all to use. Thanks so much for your time, and the hard work on an excellent library. Best regards, Braden Ackerman VLC complains like this: main warning: timing screwed, stopping resampling main warning: buffer too late (179500), up-sampling main warning: buffer way too late (358875), dropping buffer main warning: buffer way too late (230875), dropping buffer main warning: buffer way too late (356000), dropping buffer main warning: buffer way too late (228000), dropping buffer main warning: buffer way too late (356000), dropping buffer main warning: buffer way too late (228000), dropping buffer main warning: buffer way too late (356000), dropping buffer main warning: buffer way too late (347500), dropping buffer main warning: buffer way too late (219500), dropping buffer main warning: buffer way too late (347500), dropping buffer main warning: buffer way too late (219500), dropping buffer main warning: buffer way too late (347500), dropping buffer main warning: buffer way too late (219500), dropping buffer main debug: audio output is starving (-720558), playing silence main warning: buffer way too late (322098), dropping buffer main warning: buffer way too late (194098), dropping buffer main warning: buffer way too late (322098), dropping buffer main warning: buffer way too late (194098), dropping buffer main warning: buffer way too early (-177606), clearing queue main warning: timing screwed, stopping resampling main warning: buffer too early (-51609), down-sampling main warning: timing screwed, stopping resampling main warning: buffer too late (128016), up-sampling main warning: buffer way too early (-231484), clearing queue main warning: timing screwed, stopping resampling main warning: buffer way too late (245727), dropping buffer main warning: buffer too late (117727), up-sampling main warning: buffer way too late (297227), dropping buffer main warning: buffer way too early (-126440), clearing queue main warning: timing screwed, stopping resampling main warning: buffer way too late (195604), dropping buffer main warning: buffer too late (67604), up-sampling main warning: audio output out of sync, adjusting dates (-44447 us) main warning: computed PTS is out of range (36360), clearing out main warning: timing screwed, stopping resampling main warning: not synchronized (-44445 us), resampling main warning: buffer too early (-44445), down-sampling main debug: audio output is starving (-971888), playing silence rtp warning: 1 packet(s) lost main debug: End of audio preroll rtp warning: 1 packet(s) lost main debug: End of audio preroll main warning: resampling stopped after 1060698 usec (drift: 0) main warning: buffer too late (179500), up-sampling rtp warning: 1 packet(s) lost rtp warning: 1 packet(s) lost main debug: End of audio preroll main warning: resampling stopped after 894671 usec (drift: -179375) rtp warning: 1 packet(s) lost main debug: End of audio preroll main warning: buffer too late (179500), up-sampling main warning: buffer way too early (-370330), clearing queue main warning: timing screwed, stopping resampling -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri May 10 15:17:44 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 May 2013 15:17:44 -0700 Subject: [Live-devel] Audio skipping - Seems to be timing related In-Reply-To: References: Message-ID: <768A0ABD-AA1A-4375-931B-88897F4F557A@live555.com> Make sure also that you're setting "fPresentationTime" correctly. It should be the time at which the first sample in the delivered buffer was captured. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex741 at idf.gov.il Sun May 12 22:38:10 2013 From: alex741 at idf.gov.il (Alex Shihmanter) Date: Mon, 13 May 2013 08:38:10 +0300 Subject: [Live-devel] Streaming H.264 Movie via RTP Message-ID: <053501ce4f9c$156a8d00$403fa700$@gov.il> Hi, I'm streaming an H264 movie using live555. I figured out you need an SDP file in order to play the stream in VLC, so I built one and was able to play my stream. The problem is, after I upgraded my VLC to 2.0.5, the VLC won't play my stream. The SDP file I use is: v=0 o=- 1277647151953158 1 IN IP4 190.40.14.100 s=Session streamed by "testH264VideoAudioStreamer" i=test-h264-mux.mpg t=0 0 a=tool:LIVE555 Streaming Media v2007.05.24 a=recvonly a=type:broadcast a=charset:UTF-8 a=source-filter: incl IN IP4 * 190.40.14.100 m=video 8554 RTP/AVP 96 c=IN IP4 190.40.15.10/7 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1; profile-level-id=64001f;sprop-parameter-sets=Z2QAH6zZQLQ9sBEAAAMD6QAB1MCPGDG W,aOvjyyLA; I know it's not a networking problem. Somehow, the VLC 2.0.5 won't play my SDP file, even though the 1.1.11 version of VLC can play it. The VLC 2.0.5 says: "live555 error: no data received in 10s, aborting" This could possibly be a problem in VLC as if I stream the movie through VLC (instead of live555) I can't see the movie also (same problem). After further examination, I found a workaround: I've discovered that the VLC 2.0.5 can stream the H.264 movie (any movie basically) in a method called RTP / MPEG Transport Stream. If I stream through VLC the H.264 movie, I can play it well in VLC 2.0.5 (without the need in an SDP file). Is there a streaming method like this in the live555 that I can choose to stream in (the SDP packets of VLC says it's MP2T)? Is something missing in my SDP? Or Is there an option in live555 that can stream H264 as MPEG Transport Stream? Any help would be much appreciated. Thanks, Guy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon May 13 00:50:00 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 13 May 2013 00:50:00 -0700 Subject: [Live-devel] Streaming H.264 Movie via RTP In-Reply-To: <053501ce4f9c$156a8d00$403fa700$@gov.il> References: <053501ce4f9c$156a8d00$403fa700$@gov.il> Message-ID: <32034562-7B32-45A9-9008-6B99632CF3AC@live555.com> > I'm streaming an H264 movie using live555. That's rather vague. It would help to know specifically how you're doing the streaming. In any case, though, it's best if you use RTSP - i.e., your streaming application should contain a RTSP server. By using RTSP (i.e., by giving VLC a "rtsp://" URL), the SDP description for the stream will be constructed and transferred to the client (VLC) automatically; you won't need to create a SDP file yourself. (Generally speaking, SDP files are recommended only for use with multicast streams.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex741 at idf.gov.il Mon May 13 01:35:59 2013 From: alex741 at idf.gov.il (Alex Shihmanter) Date: Mon, 13 May 2013 11:35:59 +0300 Subject: [Live-devel] Streaming H.264 Movie via RTP In-Reply-To: <32034562-7B32-45A9-9008-6B99632CF3AC@live555.com> References: <053501ce4f9c$156a8d00$403fa700$@gov.il> <32034562-7B32-45A9-9008-6B99632CF3AC@live555.com> Message-ID: <054601ce4fb4$e4eb0c40$aec124c0$@gov.il> Thanks for the quick answer. The problem with this construction is that even if I run the testH264RTSPVideoAudioStreamer, I can play the stream (using the URL "rtsp://.") in VLC 1.11 (and 0.8.6 for that matter) but not in VLC 2.0.5. What could be the problem, and how can I fix that? Thanks, Guy. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, May 13, 2013 10:50 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Streaming H.264 Movie via RTP I'm streaming an H264 movie using live555. That's rather vague. It would help to know specifically how you're doing the streaming. In any case, though, it's best if you use RTSP - i.e., your streaming application should contain a RTSP server. By using RTSP (i.e., by giving VLC a "rtsp://" URL), the SDP description for the stream will be constructed and transferred to the client (VLC) automatically; you won't need to create a SDP file yourself. (Generally speaking, SDP files are recommended only for use with multicast streams.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon May 13 01:41:15 2013 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 13 May 2013 01:41:15 -0700 Subject: [Live-devel] Streaming H.264 Movie via RTP In-Reply-To: <054601ce4fb4$e4eb0c40$aec124c0$@gov.il> References: <053501ce4f9c$156a8d00$403fa700$@gov.il> <32034562-7B32-45A9-9008-6B99632CF3AC@live555.com> <054601ce4fb4$e4eb0c40$aec124c0$@gov.il> Message-ID: <2E093673-AE8B-4355-A584-29494882614C@live555.com> > The problem with this construction is that even if I run the testH264RTSPVideoAudioStreamer I don't know what "testH264RTSPVideoAudioStreamer" is; it's not one of our applications :-) > , I can play the stream (using the URL "rtsp://?") in VLC 1.11 (and 0.8.6 for that matter) but not in VLC 2.0.5. What could be the problem, and how can I fix that? I'm not sure what the problem is (because VLC is not our software, even though it uses our software for its RTSP client implementation). However, I suggest running our "testRTSPClient" (and then "openRTSP") demo application, to see if it connects to and receives data from your server OK. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cypher.w at gmail.com Mon May 13 02:29:41 2013 From: cypher.w at gmail.com (Cyberman Wu) Date: Mon, 13 May 2013 17:29:41 +0800 Subject: [Live-devel] Can I use single BasicUsageEnvironment to handle multiple RTSP connections? In-Reply-To: References: Message-ID: Thanks, it really works. But I encounter another problem: the performance is even bad that what we did former. >From the profiling result, it's because BasicTaskScheduler::SingleStep() process at most one socket after select() returned, If we add all the socket into on scheduler, we call select() the same times with more fds in fdset, and time used by select() is almost linear with files in fdset. I've tried to select one time, and re-select() again only if we checked all fds ready, and got better performance than what we did early. But the design is ugly, and I'm not sure if it will works well under all the situation. We BasicTaskScheduler choose a design like that? Is there any way to make live555 suitable for cope with multiple RTSP streams? On Thu, Mar 21, 2013 at 12:44 PM, Ross Finlayson wrote: > openRTSP create a new BasicUsageEnvironment to handle command line > specified RTSP, but from source code, > it seems that single BasicUsageEnvironment can handle multiple RTSP > connections? Is there anyone have tried it? > > > Yes, the "testRTSPClient" demo application does this. You should use this > - rather than "openRTSP" - as a model for your own RTSP client > application(s). > > > 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 > > -- Cyberman Wu -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex741 at idf.gov.il Thu May 16 05:56:29 2013 From: alex741 at idf.gov.il (Alex Shihmanter) Date: Thu, 16 May 2013 15:56:29 +0300 Subject: [Live-devel] Streaming H.264 Movie via RTP In-Reply-To: <2E093673-AE8B-4355-A584-29494882614C@live555.com> References: <053501ce4f9c$156a8d00$403fa700$@gov.il> <32034562-7B32-45A9-9008-6B99632CF3AC@live555.com> <054601ce4fb4$e4eb0c40$aec124c0$@gov.il> <2E093673-AE8B-4355-A584-29494882614C@live555.com> Message-ID: <000f01ce5234$c8c45490$5a4cfdb0$@gov.il> Sorry about that J When I run the testOnDemandRTSPServer and run the play RTSP url of the H.264 video in vlc 2.0.5 it works just fine (unsurprisingly). But for my application I need to use RTP, not RTSP. What do I need to do in order for the live to stream RTP? From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, May 13, 2013 11:41 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Streaming H.264 Movie via RTP The problem with this construction is that even if I run the testH264RTSPVideoAudioStreamer I don't know what "testH264RTSPVideoAudioStreamer" is; it's not one of our applications :-) , I can play the stream (using the URL "rtsp://.") in VLC 1.11 (and 0.8.6 for that matter) but not in VLC 2.0.5. What could be the problem, and how can I fix that? I'm not sure what the problem is (because VLC is not our software, even though it uses our software for its RTSP client implementation). However, I suggest running our "testRTSPClient" (and then "openRTSP") demo application, to see if it connects to and receives data from your server OK. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu May 16 07:08:43 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 May 2013 07:08:43 -0700 Subject: [Live-devel] Streaming H.264 Movie via RTP In-Reply-To: <000f01ce5234$c8c45490$5a4cfdb0$@gov.il> References: <053501ce4f9c$156a8d00$403fa700$@gov.il> <32034562-7B32-45A9-9008-6B99632CF3AC@live555.com> <054601ce4fb4$e4eb0c40$aec124c0$@gov.il> <2E093673-AE8B-4355-A584-29494882614C@live555.com> <000f01ce5234$c8c45490$5a4cfdb0$@gov.il> Message-ID: > When I run the testOnDemandRTSPServer and run the play RTSP url of the H.264 video in vlc 2.0.5 it works just fine (unsurprisingly). But for my application I need to use RTP, not RTSP. > What do I need to do in order for the live to stream RTP? You are streaming "RTP" no matter what. "RTSP" is just the control protocol that's used to set up the parameters for the RTP stream. If you are streaming via RTP unicast - as you are doing - then you will need a RTSP server (embedded in your transmitting application) to control it. This is easy to do, however - you can just use "testOnDemandRTSPServer" as a model, and just use the handful of lines of code that set up the "h264ESVideoTest" stream. (If you are streaming via RTP *multicast*, then you *may* omit using RTSP as a control protocol, and instead pass just a SDP description to each of your receiving multicast client players. I don't recommend this, though, especially for streaming H.264 video, because the SDP description contains a configuration parameter that depends on the particular characteristic of the H.264 stream. It's better to just use our RTSP server code to figure out this parameter automatically.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at sound4.biz Thu May 16 08:06:14 2013 From: eric at sound4.biz (Eric HEURTEL) Date: Thu, 16 May 2013 17:06:14 +0200 Subject: [Live-devel] SDP first line is skipped In-Reply-To: References: Message-ID: <5194F5E6.8010404@sound4.biz> Hi, I think MediaSession::initializeWithSDP() is not parsing first SDP line (which is usually v=0, though unused). I've corrected it as follow: // Begin by processing all SDP lines until we see the first "m=" char const* sdpLine; char const* nextSDPLine = sdpDescription; while (1) { sdpLine = nextSDPLine; if (sdpLine == NULL) break; // there are no m= lines at all if (!parseSDPLine(sdpLine, nextSDPLine)) return False; //##### We should really check for: // - "a=control:" attributes (to set the URL for aggregate control) // - the correct SDP version (v=0) if (sdpLine[0] == 'm') break; // Check for various special SDP lines that we understand: if (parseSDPLine_s(sdpLine)) continue; ... } Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu May 16 11:56:08 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 May 2013 11:56:08 -0700 Subject: [Live-devel] SDP first line is skipped In-Reply-To: <5194F5E6.8010404@sound4.biz> References: <5194F5E6.8010404@sound4.biz> Message-ID: <1C320769-64F8-4813-9D12-CE40EAD958CB@live555.com> > I think MediaSession::initializeWithSDP() is not parsing first SDP line (which is usually v=0, though unused). No, that is incorrect. The existing code works correctly, parsing all SDP lines. You're on a 'wild goose chase'. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmedina at utility.com Thu May 16 10:51:52 2013 From: tmedina at utility.com (Terrance Medina) Date: Thu, 16 May 2013 13:51:52 -0400 Subject: [Live-devel] SDP - trouble separating audio/video tracks Message-ID: <9D2DB045-DABE-4D4D-8E44-B1C179C4A1B6@utility.com> I'm streaming audio/video from an IP camera through VLC as the client. I have no documentation on the camera. I need to use rtsp to stream the audio and video channels separately, but I can't seem to get it to work here. Also, from the SDP message it appears to use Live555 v2009.09.28 as its rtsp server. On other cameras I've been able to use something like rtsp://ip:port/control, but it's not working for me here. Below is the sdp message: Sending request: DESCRIBE rtsp://192.168.1.123/mpeg4 RTSP/1.0 CSeq: 3 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) Accept: application/sdp Received 1308 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Sun, Jan 02 2000 23:48:34 GMT Content-Base: rtsp://192.168.1.123/mpeg4/ Content-Type: application/sdp Content-Length: 1147 v=0 o=- 946855189887438 1 IN IP4 192.168.1.123 s=RTSP/RTP stream from Network Video Server i=mpeg4 t=0 0 a=tool:LIVE555 Streaming Media v2009.09.28 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:RTSP/RTP stream from Network Video Server a=x-qt-text-inf:mpeg4 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:2500 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=640028;sprop-parameter-sets=Z2QAKK2EBUViuKxUdCAqKxXFYqOhAVFYrisVHQgKisVxWKjoQFRWK4rFR0ICorFcVio6ECSFITk8nyfk/k/J8nm5s00IEkKQnJ5Pk/J/J+T5PNzZprQCgDzSpAAAAwHgAABwgYEAAJiWAACrqW974XhEI1A=,aO48sA==;config=0000000167640028ad84054562b8ac5474202a2b15c562a3a1015158ae2b151d080a8ac57158a8e84054562b8ac5474202a2b15c562a3a10248521393c9f27e4fe4fc9f279b9b34d081242909c9e4f93f27f27e4f93cdcd9a6b402803cd2a400000301e00000708181000098960000aba96f7be1784423500000000168ee3cb0 a=x-dimensions: 1280, 960 a=x-framerate: 30 a=control:track1 m=audio 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:256 a=rtpmap:96 MPEG4-GENERIC/16000/2 a=fmtp:96 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1408 a=control:track2 Here's what I've tried: rtsp://192.168.1.123/mpeg4 -- streams both a/v rtsp://192.168.1.123/track1 -- error, your input can't be opened rtsp://192.168.1.123/mpeg4/track1 -- error rtsp//192.168.1.123/mpeg4#track1 -- streams both a/v rtsp://192.168.1.123/foobar/mpeg4 -- streams both a/v rtsp://192.168.1.123/mpeg4/foobar -- error In the VLC toolbar, I can select Video-->VideoTrack-->Disable, to turn off the video, but I need to be able to do this with the rtsp url. Not sure if there's some finer point of the url syntax that I'm missing, but perusing the RFC's hasn't really helped so far. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu May 16 12:54:46 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 May 2013 12:54:46 -0700 Subject: [Live-devel] SDP - trouble separating audio/video tracks In-Reply-To: <9D2DB045-DABE-4D4D-8E44-B1C179C4A1B6@utility.com> References: <9D2DB045-DABE-4D4D-8E44-B1C179C4A1B6@utility.com> Message-ID: <93E42FB3-B5A3-4795-9084-17FC61F2739C@live555.com> As a RTSP client, you can ask to stream just a single track, but *not* by specifying the track in the URL that you give to the RTSP "DESCRIBE" command. (That URL must be one that represents the entire stream - i.e., in your example: "rtsp://192.168.1.123/mpeg4" ) Instead, the way you specify which track(s) you want is in the URL that you give to the RTSP "SETUP" command. (The RTSP client will issue one "SETUP" command for each track that it wants.) The RTSP "SETUP" command will use an URL that specifies each track that you want - i.e., in your example: "rtsp://192.168.1.123/mpeg4/track1" This will be done automatically by your RTSP client application, if (and only if) it allows you to choose which track(s) you want. Our "openRTSP" application does this (using the "-a" and/or "-v" options). VLC (although it's not our application) apparently does as well, as you noted. > In the VLC toolbar, I can select Video-->VideoTrack-->Disable, to turn off the video, but I need to be able to do this with the rtsp url. As I noted above, you can't do that. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From neuronetv at gmail.com Thu May 16 12:41:35 2013 From: neuronetv at gmail.com (Anthony Griffiths) Date: Thu, 16 May 2013 20:41:35 +0100 Subject: [Live-devel] newbie: several questions about openrtsp Message-ID: I'm running centos 5 server - command line only hi all, newbie here, firstly to my surprise openRTSP actually worked without too much hassle but did throw up a couple of problems. This is the command that works with my axis 207MW network camera: openRTSP -d 20 rtsp://@/mpeg4/media.amp The 20-second video file created has no extension but I can get the file to play by copying it to another location and adding .mp4 to the copy. However if I use -4 in the command the program throws back "mdatFloating point exception" and terminates. I did the google on this but there are no clear answers. If I add -i the program does create an avi but the resultant file crashes all my players. Am I missing some component? Also the audio file is silent. I don't know what kind of audio file rtsp is generating because the filename has no extension and none of my players will play it. Thanks for any pointers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at sound4.biz Fri May 17 04:19:11 2013 From: eric at sound4.biz (Eric HEURTEL) Date: Fri, 17 May 2013 13:19:11 +0200 Subject: [Live-devel] Patch : Modification of Client MediaSession & Subsession to extend SDP attributes in derived class. In-Reply-To: <519606AB.8010000@sound4.biz> References: <519606AB.8010000@sound4.biz> Message-ID: <5196122F.6010500@sound4.biz> >> I think MediaSession::initializeWithSDP() is not parsing first SDP line (which is usually v=0, though unused). > No, that is incorrect. The existing code works correctly, parsing all SDP lines. You're on a 'wild goose chase'. Perhaps I miss something, but the following spy shows that first SDP line is not analyzed. //##### We should really check for: // - "a=control:" attributes (to set the URL for aggregate control) // - the correct SDP version (v=0) if (sdpLine[0] == 'm') break; +fprintf( stderr, "Parsing %.3s\n", sdpLine ); // Check for various special SDP lines that we understand: Anyway, I had to modify Client MediaSession & MediaSubsession classes in order to be able to extend SDP attributes in derived class (as I exposed you some weeks ago). Here is the patch, including previous correction (is there a preferred way to publish code changes to fulfill the LGPL ?). diff -r 586a4d995691 -r 9b2ceb7000ee liveMedia/MediaSession.cpp --- a/liveMedia/MediaSession.cpp mer. sept. 12 13:13:54 2012 +0200 +++ b/liveMedia/MediaSession.cpp ven. mai 17 12:27:20 2013 +0200 @@ -102,25 +102,23 @@ if (sdpDescription == NULL) return False; // Begin by processing all SDP lines until we see the first "m=" - char const* sdpLine = sdpDescription; - char const* nextSDPLine; + char const* sdpLine; + char const* nextSDPLine = sdpDescription; while (1) { + sdpLine = nextSDPLine; + if (sdpLine == NULL) break; // there are no m= lines at all if (!parseSDPLine(sdpLine, nextSDPLine)) return False; + //##### We should really check for: // - "a=control:" attributes (to set the URL for aggregate control) // - the correct SDP version (v=0) if (sdpLine[0] == 'm') break; - sdpLine = nextSDPLine; - if (sdpLine == NULL) break; // there are no m= lines at all // Check for various special SDP lines that we understand: if (parseSDPLine_s(sdpLine)) continue; if (parseSDPLine_i(sdpLine)) continue; if (parseSDPLine_c(sdpLine)) continue; - if (parseSDPAttribute_control(sdpLine)) continue; - if (parseSDPAttribute_range(sdpLine)) continue; - if (parseSDPAttribute_type(sdpLine)) continue; - if (parseSDPAttribute_source_filter(sdpLine)) continue; + if (parseSDPAttributes(sdpLine)) continue; } while (sdpLine != NULL) { @@ -207,13 +205,7 @@ // Check for various special SDP lines that we understand: if (subsession->parseSDPLine_c(sdpLine)) continue; if (subsession->parseSDPLine_b(sdpLine)) continue; - if (subsession->parseSDPAttribute_rtpmap(sdpLine)) continue; - if (subsession->parseSDPAttribute_control(sdpLine)) continue; - if (subsession->parseSDPAttribute_range(sdpLine)) continue; - if (subsession->parseSDPAttribute_fmtp(sdpLine)) continue; - if (subsession->parseSDPAttribute_source_filter(sdpLine)) continue; - if (subsession->parseSDPAttribute_x_dimensions(sdpLine)) continue; - if (subsession->parseSDPAttribute_framerate(sdpLine)) continue; + if (subsession->parseSDPAttributes(sdpLine)) continue; // (Later, check for malformed lines, and other valid SDP lines#####) } @@ -330,6 +322,16 @@ return False; } +// new virtual method. Must be called by derived method. +Boolean MediaSession::parseSDPAttributes(char const* sdpLine) { + // Check for various special SDP lines that we understand: + if (parseSDPAttribute_control(sdpLine)) return True; + if (parseSDPAttribute_range(sdpLine)) return True; + if (parseSDPAttribute_type(sdpLine)) return True; + if (parseSDPAttribute_source_filter(sdpLine)) return True; + return False; +} + Boolean MediaSession::parseSDPAttribute_type(char const* sdpLine) { // Check for a "a=type:broadcast|meeting|moderated|test|H.332|recvonly" line: Boolean parseSuccess = False; @@ -919,6 +921,18 @@ return sscanf(sdpLine, "b=AS:%u", &fBandwidth) == 1; } +// new virtual method. Must be called by derived method. +Boolean MediaSubsession::parseSDPAttributes(char const* sdpLine) { + if (parseSDPAttribute_rtpmap(sdpLine)) return True; + if (parseSDPAttribute_control(sdpLine)) return True; + if (parseSDPAttribute_range(sdpLine)) return True; + if (parseSDPAttribute_fmtp(sdpLine)) return True; + if (parseSDPAttribute_source_filter(sdpLine)) return True; + if (parseSDPAttribute_x_dimensions(sdpLine)) return True; + if (parseSDPAttribute_framerate(sdpLine)) return True; + return False; +} + Boolean MediaSubsession::parseSDPAttribute_rtpmap(char const* sdpLine) { // Check for a "a=rtpmap: /" line: // (Also check without the "/"; RealNetworks omits this) diff -r 586a4d995691 -r 9b2ceb7000ee liveMedia/include/MediaSession.hh --- a/liveMedia/include/MediaSession.hh mer. sept. 12 13:13:54 2012 +0200 +++ b/liveMedia/include/MediaSession.hh ven. mai 17 12:27:20 2013 +0200 @@ -103,6 +103,7 @@ Boolean parseSDPLine_s(char const* sdpLine); Boolean parseSDPLine_i(char const* sdpLine); Boolean parseSDPLine_c(char const* sdpLine); + virtual Boolean parseSDPAttributes(char const* sdpLine); Boolean parseSDPAttribute_type(char const* sdpLine); Boolean parseSDPAttribute_control(char const* sdpLine); Boolean parseSDPAttribute_range(char const* sdpLine); @@ -284,6 +285,7 @@ Boolean parseSDPLine_c(char const* sdpLine); Boolean parseSDPLine_b(char const* sdpLine); + virtual Boolean parseSDPAttributes(char const* sdpLine); Boolean parseSDPAttribute_rtpmap(char const* sdpLine); Boolean parseSDPAttribute_control(char const* sdpLine); Boolean parseSDPAttribute_range(char const* sdpLine); Regards E. HEURTEL From finlayson at live555.com Fri May 17 06:59:18 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 17 May 2013 06:59:18 -0700 Subject: [Live-devel] Patch : Modification of Client MediaSession & Subsession to extend SDP attributes in derived class. In-Reply-To: <5196122F.6010500@sound4.biz> References: <519606AB.8010000@sound4.biz> <5196122F.6010500@sound4.biz> Message-ID: <1052701E-4909-4BCE-A0F2-785DB19E71AC@live555.com> >>> I think MediaSession::initializeWithSDP() is not parsing first SDP line (which is usually v=0, though unused). >> No, that is incorrect. The existing code works correctly, parsing all SDP lines. You're on a 'wild goose chase'. > > Perhaps I miss something, but the following spy shows that first SDP line is not analyzed. The code scans all lines in the SDP description, but never checks the 'version number' of the first ("v=") line. (E.g., the first line could be "v=mumble\r", and the code would still accept it.) In this respect, the code is being 'liberal in what it accepts'. (BTW, the comment in the code about not checking for // - "a=control:" attributes (to set the URL for aggregate control) was incorrect, and should be removed, because we *do* check for that.) > Anyway, I had to modify Client MediaSession & MediaSubsession classes in order to be able to extend SDP attributes in derived class What attributes are these, and which IETF RFC (or Internet-Draft) defines them? (I'm not going to add anything to the supplied code that encourages people to develop servers that generate non-standard SDP lines.) > is there a preferred way to publish code changes to fulfill the LGPL ? Anything that allows users of your product to apply the same changes to their own version of the LIVE555 code... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri May 17 22:22:57 2013 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 17 May 2013 22:22:57 -0700 Subject: [Live-devel] newbie: several questions about openrtsp In-Reply-To: References: Message-ID: > I'm running centos 5 server - command line only > hi all, newbie here, firstly to my surprise openRTSP actually worked without too much hassle but did throw up a couple of problems. First, you should make sure that you have the latest version of the "LIVE555 Streaming Media" code: http://www.live555.com/liveMedia/faq.html#latest-version > This is the command that works with my axis 207MW network camera: > openRTSP -d 20 rtsp://@/mpeg4/media.amp > The 20-second video file created has no extension but I can get the file to play by copying it to another location and adding .mp4 to the copy. The video file is a 'raw' (elementary stream) video file, and therefore is *not* a 'mp4'-format file - so you're lucky that you were able to play the file by adding '.mp4' to the filename :-) > However if I use -4 in the command the program throws back "mdatFloating point exception" and terminates. Unfortunately unless you can find a way for us to reproduce this ourselves, you're going to track down this problem yourself. > I did the google on this but there are no clear answers. If I add -i the program does create an avi but the resultant file crashes all my players. This, then is apparently a bug in these media player applications, so you'd need to report this to the organizations that develop those applications. > Am I missing some component? No. > Also the audio file is silent. I don't know what kind of audio file rtsp is generating because the filename has no extension The audio file (like the video file) will be a 'raw' (elementary stream) file, so it's not surprising that media players can't handle it. You can deduce the type of audio from the file name (whatever it is; you didn't say). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From neuronetv at gmail.com Sat May 18 01:26:04 2013 From: neuronetv at gmail.com (Anthony Griffiths) Date: Sat, 18 May 2013 09:26:04 +0100 Subject: [Live-devel] newbie: several questions about openrtsp In-Reply-To: References: Message-ID: thanks for your response, my further comments interwoven with your below: -------------------------------------------------- From: "Ross Finlayson" Sent: Saturday, May 18, 2013 6:22 AM To: "LIVE555 Streaming Media - development & use" Subject: Re: [Live-devel] newbie: several questions about openrtsp >> I'm running centos 5 server - command line only >> hi all, newbie here, firstly to my surprise openRTSP actually worked without too much hassle but did throw up a couple of problems. > > First, you should make sure that you have the latest version of the "LIVE555 Streaming Media" code: > http://www.live555.com/liveMedia/faq.html#latest-version yeah that's the version I got,, /usr/local/include/liveMedia/liveMedia_version.hh shows: #define LIVEMEDIA_LIBRARY_VERSION_STRING "2013.04.30" > > >> This is the command that works with my axis 207MW network camera: >> openRTSP -d 20 rtsp://@/mpeg4/media.amp >> The 20-second video file created has no extension but I can get the file to play by copying it to another location and adding .mp4 to the copy. > > The video file is a 'raw' (elementary stream) video file, and therefore is *not* a 'mp4'-format file - so you're lucky that you were able to play the file by adding '.mp4' to the filename :-) ok, then I suppose the next job is to convert this raw file into a usable file that players can recognize and play but so far I haven't found a program designed to do this and I have tried a couple. Can you recommend a program or procedure that will overcome this step? > >> However if I use -4 in the command the program throws back "mdatFloating point exception" and terminates. > > Unfortunately unless you can find a way for us to reproduce this ourselves, you're going to track down this problem yourself. well it's just a bog-standard install of centos 5 server and I've squeezed google as much as I can on this error but to no avail. I also installed loads of extras from here: http://cumulusclips.org/docs/install-ffmpeg-x264-on-centos/ in the hope it would work but the error still persists. I did run the openRTSP install again after putting these extras in. >> I did the google on this but there are no clear answers. If I add -i the program does create an avi but the resultant file crashes all my players. > > This, then is apparently a bug in these media player applications, so you'd need to report this to the organizations that develop those applications. I can't see the media player creators ever agreeing to such a bug in their players, multiple player all point to the video file being broken which takes me back to my previous comment about an application specifically designed to convert the openRTSP file into a usable format. >> Am I missing some component? > > No. > > >> Also the audio file is silent. I don't know what kind of audio file rtsp is generating because the filename has no extension > > The audio file (like the video file) will be a 'raw' (elementary stream) file, so it's not surprising that media players can't handle it. You can deduce the type of audio from the file name (whatever it is; you didn't say). the audio file generated in called 'audio-MPEG4-GENERIC-2' and the video file is named video-MP4V-ES-1. So far nothing I've found will bring sound out of it. Again thanks for your iniital response and any further light you can shed. I've love to bring opeRTSP up to being a usable application if I can. On Sat, May 18, 2013 at 6:22 AM, Ross Finlayson wrote: > I'm running centos 5 server - command line only > hi all, newbie here, firstly to my surprise openRTSP actually worked > without too much hassle but did throw up a couple of problems. > > > First, you should make sure that you have the latest version of the > "LIVE555 Streaming Media" code: > http://www.live555.com/liveMedia/faq.html#latest-version > > > This is the command that works with my axis 207MW network camera: > openRTSP -d 20 rtsp://@/mpeg4/media.amp > The 20-second video file created has no extension but I can get the file > to play by copying it to another location and adding .mp4 to the copy. > > > The video file is a 'raw' (elementary stream) video file, and therefore is > *not* a 'mp4'-format file - so you're lucky that you were able to play the > file by adding '.mp4' to the filename :-) > > > However if I use -4 in the command the program throws back "mdatFloating > point exception" and terminates. > > > Unfortunately unless you can find a way for us to reproduce this > ourselves, you're going to track down this problem yourself. > > > I did the google on this but there are no clear answers. If I add -i the > program does create an avi but the resultant file crashes all my players. > > > This, then is apparently a bug in these media player applications, so > you'd need to report this to the organizations that develop those > applications. > > > Am I missing some component? > > > No. > > > Also the audio file is silent. I don't know what kind of audio file rtsp > is generating because the filename has no extension > > > The audio file (like the video file) will be a 'raw' (elementary stream) > file, so it's not surprising that media players can't handle it. You can > deduce the type of audio from the file name (whatever it is; you didn't > say). > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at mikemccandless.com Sat May 18 14:42:34 2013 From: mail at mikemccandless.com (Michael McCandless) Date: Sat, 18 May 2013 17:42:34 -0400 Subject: [Live-devel] No data from the VND.ONVIF.METADATA subsession Message-ID: I'm using testRTSPClient to pull an RTSP stream, and I noticed the camera provides two subsessions: [URL:"..."]: Initiated the "video/H264" subsession (client ports 56266-56267) [URL:"..."]: Set up the "video/H264" subsession (client ports 56266-56267) [URL:"..."]: Created a data sink for the "video/H264" subsession [URL:"..."]: Initiated the "application/VND.ONVIF.METADATA" subsession (client ports 49032-49033) [URL:"..."]: Set up the "application/VND.ONVIF.METADATA" subsession (client ports 49032-49033) [URL:"..."]: Created a data sink for the "application/VND.ONVIF.METADATA" subsession [URL:"..."]: Started playing session... And then I proceed to get many frames, but only for the video/H264 subsession. I never see any data sent to the afterGettingFrame for the application/VND.ONVIF.METADATA subsession ... is this expected? I thought this subsession might provide details from the camera like maybe motion detection events or something (just a guess)... Or is there something different I need to do to "start" the metadata stream? Thanks! Mike http://blog.mikemccandless.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat May 18 15:09:35 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 18 May 2013 15:09:35 -0700 Subject: [Live-devel] No data from the VND.ONVIF.METADATA subsession In-Reply-To: References: Message-ID: On May 18, 2013, at 2:42 PM, Michael McCandless wrote: > I'm using testRTSPClient to pull an RTSP stream, and I noticed the > camera provides two subsessions: > > [URL:"..."]: Initiated the "video/H264" subsession (client ports 56266-56267) > [URL:"..."]: Set up the "video/H264" subsession (client ports 56266-56267) > [URL:"..."]: Created a data sink for the "video/H264" subsession > [URL:"..."]: Initiated the "application/VND.ONVIF.METADATA" subsession (client ports 49032-49033) > [URL:"..."]: Set up the "application/VND.ONVIF.METADATA" subsession (client ports 49032-49033) > [URL:"..."]: Created a data sink for the "application/VND.ONVIF.METADATA" subsession > [URL:"..."]: Started playing session... > > And then I proceed to get many frames, but only for the video/H264 > subsession. I never see any data sent to the afterGettingFrame for > the application/VND.ONVIF.METADATA subsession ... is this expected? No. It means that either - The server camera is not sending any "VND.ONVIF.METADATA" packets, or - The server is sending "VND.ONVIF.METADATA" packets, but none of them have the RTP "M" bit set. (The "VND.ONVIF.METADATA" RTP payload format uses the RTP "M" bit to mark the last packet of a 'metadata' (XML) document. Our client code does not deliver any received metadata until it knows that the whole document has been received.) In either case, the problem appears to be with your server (camera). > Or is there something different I need to do to "start" the metadata > stream? No. As long as the client sends a RTSP "SETUP" command for that track - which it should - then the server is supposed to send this data (along with the H.264 video data) after the client then sends the RTSP "PLAY" command. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at mikemccandless.com Sat May 18 15:20:21 2013 From: mail at mikemccandless.com (Michael McCandless) Date: Sat, 18 May 2013 18:20:21 -0400 Subject: [Live-devel] No data from the VND.ONVIF.METADATA subsession In-Reply-To: References: Message-ID: On Sat, May 18, 2013 at 6:09 PM, Ross Finlayson wrote: > > On May 18, 2013, at 2:42 PM, Michael McCandless > wrote: > > I'm using testRTSPClient to pull an RTSP stream, and I noticed the > camera provides two subsessions: > > [URL:"..."]: Initiated the "video/H264" subsession (client ports > 56266-56267) > [URL:"..."]: Set up the "video/H264" subsession (client ports > 56266-56267) > [URL:"..."]: Created a data sink for the "video/H264" subsession > [URL:"..."]: Initiated the "application/VND.ONVIF.METADATA" subsession > (client ports 49032-49033) > [URL:"..."]: Set up the "application/VND.ONVIF.METADATA" subsession > (client ports 49032-49033) > [URL:"..."]: Created a data sink for the > "application/VND.ONVIF.METADATA" subsession > [URL:"..."]: Started playing session... > > And then I proceed to get many frames, but only for the video/H264 > subsession. I never see any data sent to the afterGettingFrame for > the application/VND.ONVIF.METADATA subsession ... is this expected? > > > No. It means that either > - The server camera is not sending any "VND.ONVIF.METADATA" packets, or > - The server is sending "VND.ONVIF.METADATA" packets, but none of them > have the RTP "M" bit set. (The "VND.ONVIF.METADATA" RTP payload format > uses the RTP "M" bit to mark the last packet of a 'metadata' (XML) > document. Our client code does not deliver any received metadata until it > knows that the whole document has been received.) > > In either case, the problem appears to be with your server (camera). > OK, thanks for the quick response. Mike http://blog.mikemccandless.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.taylor at abaslabs.com Sun May 19 23:29:33 2013 From: scott.taylor at abaslabs.com (Scott Taylor) Date: Mon, 20 May 2013 16:29:33 +1000 Subject: [Live-devel] setRTSPResponse accessibility issue Message-ID: <5199C2CD.2020003@abaslabs.com> Hi, I'm following the instructions in RTSPClientSession::handleCmd_GET_PARAMETER() in order to handle RTSP GET_PARAMETER properly (using latest 2013.04.30). I've derived from RTSPClientSession and reimplemented handleCmd_GET_PARAMETER(), now I'd like to call RTSPClientConnection::setRTSPResponse() like the default implementation does (RTSPServer.cpp ln 1806). Unfortunately RTSPClientConnection is a separate object and setRTSPResponse() is protected; the default implementation in RTSPClientSession has friend access to call it, but my derived class doesn't inherit the friendship. What's the correct way for my derived class to write a response? Currently the only solution I can see is to also derive from RTSPClientConnection and add a new function that forwards to setRTSPResponse (it's not virtual, so I can't just override it). However it seems like setRTSPResponse() should simply be public. What say you? Thanks, Scott From finlayson at live555.com Sun May 19 23:46:37 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 19 May 2013 23:46:37 -0700 Subject: [Live-devel] setRTSPResponse accessibility issue In-Reply-To: <5199C2CD.2020003@abaslabs.com> References: <5199C2CD.2020003@abaslabs.com> Message-ID: <27A94201-EB1C-46B5-B668-0DDB6339A0E3@live555.com> > What's the correct way for my derived class to write a response? Currently the only solution I can see is to also derive from RTSPClientConnection and add a new function that forwards to setRTSPResponse (it's not virtual, so I can't just override it). However it seems like setRTSPResponse() should simply be public. Making the (4) "setRTSPResponse()" functions public wouldn't be ideal (because we don't want *anyone* to be able to call these functions), but because it solves your problem, it's probably a reasonable hack to make in the code. (It'll be included in the next release of the software.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Mon May 20 11:41:58 2013 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Mon, 20 May 2013 18:41:58 +0000 Subject: [Live-devel] Best way to get video width and height? Message-ID: I receive a mjpeg stream from a Cisco server. In the SDP I see this line: a=fmtp:26 width=704;height=480;4CIF=1 When looking at fVideoWidth & fVideoHeight in MediaSubsession they are always 0 and it looks like they're only populated if "a=x-dimensions:%d,%d" is found in the SDP. Is there another reliable way to grab the video resolution or would you need to "manually" parse the SDP line above? /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5739 bytes Desc: not available URL: From scott.taylor at abaslabs.com Mon May 20 21:29:40 2013 From: scott.taylor at abaslabs.com (Scott Taylor) Date: Tue, 21 May 2013 14:29:40 +1000 Subject: [Live-devel] setRTSPResponse accessibility issue In-Reply-To: <27A94201-EB1C-46B5-B668-0DDB6339A0E3@live555.com> References: <5199C2CD.2020003@abaslabs.com> <27A94201-EB1C-46B5-B668-0DDB6339A0E3@live555.com> Message-ID: <519AF834.9020601@abaslabs.com> >> What's the correct way for my derived class to write a response? >> Currently the only solution I can see is to also derive from >> RTSPClientConnection and add a new function that forwards to >> setRTSPResponse (it's not virtual, so I can't just override it). >> However it seems like setRTSPResponse() should simply be public. > > Making the (4) "setRTSPResponse()" functions public wouldn't be ideal > (because we don't want *anyone* to be able to call these functions), > but because it solves your problem, it's probably a reasonable hack to > make in the code. (It'll be included in the next release of the > software.) > Thanks Ross! I just realised it might be neater to provide forwarding functions in RTSPClientSession, eg: protected: void setRTSPResponse(RTSPServer::RTSPClientConnection* ourClientConnection, char const* responseStr) { ourClientConnection->setRTSPResponse(responseStr); } // Repeat for the other three variants That way, RTSPClientSession-derived classes can utilise the friend access to RTSPClientConnection. Still not ideal, but better than making them public? Regards, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From Subhankar_Saha at mindtree.com Wed May 22 03:34:27 2013 From: Subhankar_Saha at mindtree.com (Subhankar Saha) Date: Wed, 22 May 2013 10:34:27 +0000 Subject: [Live-devel] ProxyServerMediaSession not working correctly for more than one client per stream Message-ID: Hi, I am using 'ProxyServerMediaSession' for one of our projects, where we stream in from multiple cameras and stream out again. I am facing an issue where there are two clients connected and receiving one of the streams. But when one of the clients goes away or terminates its connection with the server, the live555 appears to disconnect the other client as well. This is easily simulated using the 'live555ProxyServer.exe' application as well (I ran this one to double-check if there is any issue in our application that is causing this). Here is the trace from the 'live555ProxyServer.exe' application: --- trace --- $ ./live555ProxyServer.exe -v rtsp://admin:admin at 172.22.66.111:42424/Stream LIVE555 Proxy Server (LIVE555 Streaming Media library version 2013.04.30) RTSP stream, proxying the stream "rtsp://admin:admin at 172.22.66.111:42424/Stream" Play this stream using the URL: rtsp://172.22.65.90/proxyStream (We use port 80 for optional RTSP-over-HTTP tunneling.) ProxyServerMediaSession["rtsp://172.22.66.111:42424/Stream/"] added new "ProxyServerMediaSubsession" for RTP/video/H264 track ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["H264"] ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 2553021356) ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() --- trace --- The 'closeStreamSource' is supposed to be called only when both clients are closed. But if I close one of them, the other gets closed too, and then I see 'closeStreamSource' is being invoked. However the comment in ProxyServerMediaSession.cpp says: // Because there's only one input source for this 'subsession' (regardless of how many downstream clients are proxying it), // we don't close the input source here. (Instead, we wait until *this* object gets deleted.) // However, because (as evidenced by this function having been called) we no longer have any clients accessing the stream, // then we "PAUSE" the downstream proxied stream, until a new client arrives: But... one client was definitely accessing the stream, and hence 'closeStreamSource' should not get called! Can someone throw light in this? What could be going wrong? Regards, Subhankar. ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.l at vglnt.com Wed May 22 08:12:24 2013 From: michael.l at vglnt.com (Michael Levin) Date: Wed, 22 May 2013 18:12:24 +0300 Subject: [Live-devel] Frames lost on TS file created with testH264VideoToTranspotStream test Message-ID: Hello, I have 264 file created from our encoder output, it is 1920x1088. Streaming this file to VLC works fine with no frame lost. After converting the file to ts (using testH264VideoToTranspotStream) I try to play the new file with VLC and get many frames lost cause of dealys: main debug: picture might be displayed late (missing 1 ms) main debug: picture might be displayed late (missing 1 ms) main debug: picture might be displayed late (missing 6 ms) main debug: picture might be displayed late (missing 1 ms) main warning: picture is too late to be displayed (missing 21 ms) main warning: picture is too late to be displayed (missing 21 ms) main debug: picture might be displayed late (missing 9 ms) main warning: picture is too late to be displayed (missing 84 ms) main warning: picture is too late to be displayed (missing 84 ms) main warning: picture is too late to be displayed (missing 160 ms What is the reason for the delays in frames ? Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Wed May 22 09:59:00 2013 From: warren at etr-usa.com (Warren Young) Date: Wed, 22 May 2013 10:59:00 -0600 Subject: [Live-devel] Frames lost on TS file created with testH264VideoToTranspotStream test In-Reply-To: References: Message-ID: <519CF954.8060004@etr-usa.com> On 5/22/2013 09:12, Michael Levin wrote: > > After converting the file to ts (using testH264VideoToTranspotStream) I > try to play the new file with VLC and get many frames lost cause of dealys: If you compile the library with the DEBUG macro set, you should get a line beginning with "MPEGVideoStreamFramer::computePresentationTime(" in the output. What appears after the parentheses? Also, what is the intended frame rate of the source stream, and have you verified that this is the actual frame rate in the output? From finlayson at live555.com Sun May 26 21:32:35 2013 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 26 May 2013 22:32:35 -0600 Subject: [Live-devel] Best way to get video width and height? In-Reply-To: References: Message-ID: <4C995E8E-921E-48B0-84D5-8096ACEE3B92@live555.com> > I receive a mjpeg stream from a Cisco server. In the SDP I see this line: > > a=fmtp:26 width=704;height=480;4CIF=1 > > When looking at fVideoWidth & fVideoHeight in MediaSubsession they are always 0 and it looks like they're only populated if "a=x-dimensions:%d,%d" is found in the SDP. > > > Is there another reliable way to grab the video resolution or would you need to "manually" parse the SDP line above? Well, I don't think the "width" and "height" parameters have been standardized in any RFC - but then again, neither has the "x-dimensions" attribute :-) So in the next version of the software I'll just go ahead and add parsing for the "width" and "height" attributes to the "MediaSubsession::parseSDPAttribute_fmtp()" function. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From stanley at gofuseit.com Tue May 28 01:36:24 2013 From: stanley at gofuseit.com (Stanley Biggs) Date: Tue, 28 May 2013 10:36:24 +0200 Subject: [Live-devel] RTSP Client sending RR messages before Play command is issued Message-ID: Hi I am experiencing the same problem as described in this thread: http://lists.live555.com/pipermail/live-devel/2012-August/015750.html and answered here http://lists.live555.com/pipermail/live-devel/2012-August/015755.html Basically, we are implementing an RTSP client and server. However, when RTSP messages are still being sent between client and server and before a client issues the "PLAY" command, the client already starts sending RR packets to the server. The result is that the server then responds with "405 Method not allowed". (I have also posted a detailed question on StackOverflow here: http://stackoverflow.com/questions/16775914/if-there-is-slight-network-delay-rtsp-client-starts-sending-rtcp-rtp-data-beforbut haven't had many views on the question and no answers.) The response to the thread that I reference indicates that a client upgrade to the latest version of live555 will solve the problem, yet I re-compiled my code with the 2013.04.13 version and this is still happening. It should be noted that we are using the older RTSP client interface. That is, we have defined RTSPCLIENT_SYNCHRONOUS_INTERFACE in our code such that we are able to use those methods. I am not sure if this is perhaps what's causing the problem (but I hope not). Any ideas on how to solve this problem? I have also tried a slightly older version of live555 and the problem also occurred there. -- Kind Regards *Stanley* -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue May 28 13:42:51 2013 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 28 May 2013 14:42:51 -0600 Subject: [Live-devel] setRTSPResponse accessibility issue In-Reply-To: <519AF834.9020601@abaslabs.com> References: <5199C2CD.2020003@abaslabs.com> <27A94201-EB1C-46B5-B668-0DDB6339A0E3@live555.com> <519AF834.9020601@abaslabs.com> Message-ID: > Thanks Ross! I just realised it might be neater to provide forwarding functions in RTSPClientSession, eg: > > protected: > void setRTSPResponse(RTSPServer::RTSPClientConnection* ourClientConnection, char const* responseStr) { ourClientConnection->setRTSPResponse(responseStr); } > // Repeat for the other three variants > > That way, RTSPClientSession-derived classes can utilise the friend access to RTSPClientConnection. Still not ideal, but better than making them public? Yes - good idea. I like that idea better. I'll include these functions in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed May 29 11:48:44 2013 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 29 May 2013 12:48:44 -0600 Subject: [Live-devel] ProxyServerMediaSession not working correctly for more than one client per stream In-Reply-To: References: Message-ID: > I am using ?ProxyServerMediaSession? for one of our projects, where we stream in from multiple cameras and stream out again. I am facing an issue where there are two clients connected and receiving one of the streams. But when one of the clients goes away or terminates its connection with the server, the live555 appears to disconnect the other client as well. I don't see how this can be happening, because the 'reference count' on the "StreamState" object (in the implementation of "OnDemandServerMediaSubsession") is supposed to take care of this. (Because proxied streams have "reuseFirstSource" set to True, the same "StreamState" object gets used, regardless of how many front-end clients are accessing the proxied stream. But when each client closes its stream, the "StreamState" object doesn't get closed down unless there are no more clients remaining (see the function "OnDemandServerMediaSubsession::deleteStream()"). This is assuming, of course, that you haven't modified the code at all. If you have modified the code, then all bets are off... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Subhankar_Saha at mindtree.com Wed May 29 23:33:09 2013 From: Subhankar_Saha at mindtree.com (Subhankar Saha) Date: Thu, 30 May 2013 06:33:09 +0000 Subject: [Live-devel] ProxyServerMediaSession not working correctly for more than one client per stream In-Reply-To: References: Message-ID: Hi Ross, This is assuming, of course, that you haven't modified the code at all. If you have modified the code, then all bets are off... No, we have not made any modification to the code at all, except changing "win32config" for TOOLS32 (to put correct VC path) and LINK_OPTS_0 (use msvcrt.lib instead of msvcirt.lib). Also, like I stated before, the issue can be reproduced using the included "proxyServer" application. We did some investigation with few older versions of live555 source base we have in store. It seems, the issue was not there in version 2013.04.21. It seemed to have first appeared in 2013.04.23. I diff-ed these two versions of source codes. Most of the changes did not appear to be related to the issue we are seeing, but one change in OnDemandServerMediaSubsession.cpp does look like it is contributing to the problem: In version 2013.04.23, following lines are added in function "StreamState::endPlaying": if (fRTCPInstance != NULL) { // Hack: Explicitly send a RTCP "BYE" packet now, because the code below will prevent that from happening later, // when "fRTCPInstance" gets deleted: fRTCPInstance->sendBYE(); } If we comment out the above lines then we find things working again as expected - that is, closing one client no longer closes the other client(s). Now, we know you have added the above code because of a problem we had raised earlier - it was to fix live555 not sending BYE when server sessions are closed on the server side. But we think this change is now contributing to the current problem! Once again, no change was done to code anywhere. And the problem can be seen just by running 'proxyServer' application. We used VLC as clients. Regards, Subhankar. ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From stanley at gofuseit.com Thu May 30 05:57:12 2013 From: stanley at gofuseit.com (Stanley Biggs) Date: Thu, 30 May 2013 14:57:12 +0200 Subject: [Live-devel] RTSP Client sending RR messages before Play command is issued In-Reply-To: References: Message-ID: It seems that it may not be RR packets. It is some other RTCP or RTP packet that the client sends. On Tue, May 28, 2013 at 10:36 AM, Stanley Biggs wrote: > Hi > > I am experiencing the same problem as described in this thread: > http://lists.live555.com/pipermail/live-devel/2012-August/015750.html and > answered here > http://lists.live555.com/pipermail/live-devel/2012-August/015755.html > > Basically, we are implementing an RTSP client and server. However, when > RTSP messages are still being sent between client and server and before a > client issues the "PLAY" command, the client already starts sending RR > packets to the server. The result is that the server then responds with > "405 Method not allowed". (I have also posted a detailed question on > StackOverflow here: > http://stackoverflow.com/questions/16775914/if-there-is-slight-network-delay-rtsp-client-starts-sending-rtcp-rtp-data-beforbut haven't had many views on the question and no answers.) > > The response to the thread that I reference indicates that a client > upgrade to the latest version of live555 will solve the problem, yet I > re-compiled my code with the 2013.04.13 version and this is still happening. > > It should be noted that we are using the older RTSP client interface. That > is, we have defined RTSPCLIENT_SYNCHRONOUS_INTERFACE in our code such that > we are able to use those methods. I am not sure if this is perhaps what's > causing the problem (but I hope not). > > Any ideas on how to solve this problem? I have also tried a slightly older > version of live555 and the problem also occurred there. > > -- > Kind Regards > > *Stanley* > -- Kind Regards *Stanley Biggs fuseIT **: System Engineer* +27 82 886 5994 stanley at gofuseit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From stanley at gofuseit.com Thu May 30 07:26:38 2013 From: stanley at gofuseit.com (Stanley Biggs) Date: Thu, 30 May 2013 14:26:38 +0000 (UTC) Subject: [Live-devel] Server getting confused with RTCP message before PLAY command (when using RTP over TCP) References: <49A3571C.8090906@schuckmannacres.com> Message-ID: Ross Finlayson writes: > > >Or perhaps the client code shouldn't be allowed to send RTCP > >messages until after the PLAY command has been issued. > > You're right - it shouldn't. You've discovered a bug. > > >PS. I should probably note my code isn't like openRTSP in that it > >doesn't do DESCRIBE, SETUP, and PLAY all at once I do DESCRIBE > >followed by SETUP, then I let the TaskScheduler run while I let my > >UI do some work, then I do a couple of SET_PARAMETER commands, then > >some more UI work followed by the PLAY command. > > Yes, that's why you managed to discover the bug. Thanks. > > I'll fix this as part of my forthcoming planned major upgrade of "RTSPClient". > Hi Ross I realize this is an old thread, but we are using the very latest version of live555 (as at today, 30 May 2013) and the exact same error occurs on our application. We are using the "old RTSP client interface" though, that is defined with RTSPCLIENT_SYNCHRONOUS_INTERFACE. Is that the reason? Was this only fixed in the newer interface or should it be working when we use functions from RTSPCLIENT_SYNCHRONOUS_INTERFACE as well? Stanley From finlayson at live555.com Thu May 30 08:15:36 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 May 2013 08:15:36 -0700 Subject: [Live-devel] ProxyServerMediaSession not working correctly for more than one client per stream In-Reply-To: References: Message-ID: > We did some investigation with few older versions of live555 source base we have in store. It seems, the issue was not there in version 2013.04.21. It seemed to have first appeared in 2013.04.23. I diff-ed these two versions of source codes. Most of the changes did not appear to be related to the issue we are seeing, but one change in OnDemandServerMediaSubsession.cpp does look like it is contributing to the problem: > > In version 2013.04.23, following lines are added in function ?StreamState::endPlaying?: > > if (fRTCPInstance != NULL) { > // Hack: Explicitly send a RTCP "BYE" packet now, because the code below will prevent that from happening later, > // when "fRTCPInstance" gets deleted: > fRTCPInstance->sendBYE(); > } > > If we comment out the above lines then we find things working again as expected ? that is, closing one client no longer closes the other client(s). Thanks for the note. Yes, you're correct - that code had this unwanted side effect. So I've removed it from the new version (2013.05.30) of the software - released just now. Please upgrade to this new version. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu May 30 08:20:12 2013 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 May 2013 08:20:12 -0700 Subject: [Live-devel] Server getting confused with RTCP message before PLAY command (when using RTP over TCP) In-Reply-To: References: <49A3571C.8090906@schuckmannacres.com> Message-ID: <4130DF8D-4596-4F9A-9CEA-37B08CCA86E6@live555.com> Stanley, I haven't had time yet to review and respond to your emails. You should note, however, that the old 'synchronous' "RTSPClient" interface has now been removed completely - as of the latest version (2013.05.30) of the code - and is no longer supported, at all. (This old interface has been out-of-date for three years now.) So, you should upgrade to the latest version of the code, and fix your code to use the current, 'asynchronous' "RTSPClient" interface. Your server application should also be using the latest version of our code. Then, and only then, please let us know what problems - if any - you are having with your new server and client. (Please stop referring to archived mailing list messages; they are usually referring to old, different problems that are no longer relevant.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuroueie at hotmail.com Fri May 24 22:12:49 2013 From: kuroueie at hotmail.com (Julien Vary) Date: Sat, 25 May 2013 01:12:49 -0400 Subject: [Live-devel] Bug analyze_sei_data() & Session timeout questions In-Reply-To: References: Message-ID: Code base : live.2013.04.30.tar.gz Question1: RtspServer: An OPTIONS with a proper "Session: XYZ" does not seem to trigger RTSPClientSession::noteLiveness(). Is that a wanted behavior ? If yes, apart from sending RTCP, what would be the best keep-alive from the client? requesting GET_PARAMETER ? If no, could it trigger 'handleCmd_withinSession()' the same way that TEARDOWN/PLAY/PAUSE/GET_PARAMETER/SET_PARAMETER do, so it could 'touch' the session liveness? Question2/Request : In void RTSPServer::RTSPClientSession ::handleCmd_SETUP(RTSPServer::RTSPClientConnection* ourClientConnection, char const* urlPreSuffix, char const* urlSuffix, char const* fullRequestStr) would it be possible to change the many snprintf((char*)ourClientConnection->fResponseBuffer, sizeof ourClientConnection->fResponseBuffer, "RTSP/1.0 200 OK\r\n" "CSeq: %s\r\n" "%s" "Transport: blablabla \r\n" "Session: %08X\r\n\r\n", to use "Session: %08X;timeout=%u\r\n\r\n", ..., fOurSessionId, fReclamationTestSeconds); instead, so the clients can be aware of custom timeouts, and 'ping' OPTIONS & RTCP accordingly ? (if I am mistaken on the usage of 'fReclamationTestSeconds', any suitable value instead ?) Searching the net/list, I found : http://lists.live555.com/pipermail/live-devel/2009-August/011129.html http://lists.live555.com/pipermail/live-devel/2007-August/007292.html It looks like people agreed on it, but 5 years later, it still absent ? Sorry if this has been already discussed and ruled out for a specific reason. Bug: In following code, if "if (NumBytesInNALunit > maxSize) return;" occurs, 'nalUnitCopySize' is not set to 0, 'seiSize' is unset/random, and it will most likely crash in the while loop. Solution : 1: Put 'nalUnitCopySize = 0;' before the return in H264VideoStreamParser::removeEmulationBytes 2: unsigned seiSize = 0; Code: void H264VideoStreamParser::analyze_sei_data() { // Begin by making a copy of the NAL unit data, removing any 'emulation prevention' bytes: u_int8_t sei[SEI_MAX_SIZE]; unsigned seiSize; removeEmulationBytes(sei, sizeof sei, seiSize); unsigned j = 1; // skip the initial byte (forbidden_zero_bit; nal_ref_idc; nal_unit_type); we've already seen it while (j < seiSize) { unsigned payloadType = 0; do { payloadType += sei[j]; ... } void H264VideoStreamParser::removeEmulationBytes(u_int8_t* nalUnitCopy, unsigned maxSize, unsigned& nalUnitCopySize) { u_int8_t* nalUnitOrig = fStartOfFrame + fOutputStartCodeSize; unsigned const NumBytesInNALunit = fTo - nalUnitOrig; if (NumBytesInNALunit > maxSize) return; nalUnitCopySize = 0; ... } Regards, Julien -------------- next part -------------- An HTML attachment was scrubbed... URL: From phuze9 at gmail.com Sat May 25 08:54:34 2013 From: phuze9 at gmail.com (phuze koj) Date: Sat, 25 May 2013 10:54:34 -0500 Subject: [Live-devel] testOnDemandRTSPServer Problem Message-ID: Hi, I'm having a problem getting the testprog RTSP Server to actually show a video file. I encoded the video file myself so it should be the correct format (MPEG4 H.264 Baseline AVC). I'm new to Live555, so I'm not sure if the server should be giving some output when a client connects to it or not, but I was hoping that someone could let me know if there's something wrong with what I'm doing. The only real things I've changed are the port/streamname/input file name, and commented out all of the other filetype blocks in the RTSPServer (I've tried it by using both h264 and mpeg4 video) with no luck. I've tried opening the stream on VLC and using the testRTSPClient, have disabled my firewall, and tried opening it from other computers. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MediaInfo.PNG Type: image/png Size: 9777 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTSP-Client.PNG Type: image/png Size: 47405 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTSP-Server.PNG Type: image/png Size: 4939 bytes Desc: not available URL: From barrybaleni at gmail.com Tue May 28 02:49:56 2013 From: barrybaleni at gmail.com (Barry Baleni) Date: Tue, 28 May 2013 16:49:56 +0700 Subject: [Live-devel] User-Agent Header Message-ID: Hello, How to add user agent option that allows to set the User-Agent header in openRTSP on the command line? Thank you, Barry