From finlayson at live555.com Wed Aug 1 14:37:08 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 1 Aug 2012 14:37:08 -0700 Subject: [Live-devel] FYI: An RTSP/RTP media player client app for iOS (iPhones and iPads) Message-ID: A number of people have asked about RTSP/RTP media player client apps for iOS (iPhones and iPads) that could be used to play streams from the LIVE555 RTSP server (and other standards-compliant RTSP/RTP servers, such as network cameras). FYI, one that I found today is "GoodPlayer": . Coincidentally, it uses the "LIVE555 Streaming Media" libraries (with libVLC for rendering) for its RTSP client implementation. There may be other such public apps out there (I know that some people on this mailing list have been working on developing iOS apps, at least for their own use). If you know of any, feel free to let us know. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lshl.shlomi at gmail.com Wed Aug 1 02:53:53 2012 From: lshl.shlomi at gmail.com (Shlomi) Date: Wed, 1 Aug 2012 12:53:53 +0300 Subject: [Live-devel] CPU intensive on ARM using testH264VideoStreamer with TI encoder Message-ID: <5018fcb7.08030e0a.52e9.ffffd1e1@mx.google.com> Hi all, I am using a TI DaVinci processor to create a h264 file. When trying to stream this file with testH264VideoStreamer, the cpu goes up to 80% (which is bad for me since it is already in use by other applications). When trying to stream the slamtv60.264 found on the live555 site, all is good (cpu consumption is about 4-10%). At first the testH264VideoStreamer complained that the h264 frames were too big, so I enlarged OutPacketBuffer::maxSize. This eliminated the truncation of the frames, but not the intensive cpu usage. I guess (and again it is ONLY a guess) the intensive cpu usage comes from the need to break the big h264 frames to MTU fragments (i.e. ~1450 B). I can't reduce the size of the h264 frames because the stream bandwidth (8Mbps) must be retained (part of the requirements). Does anybody have any idea/solution on how to lessen the cpu usage? Thanks, Shlomi From zhanm at join.net.cn Thu Aug 2 02:35:35 2012 From: zhanm at join.net.cn (=?gb2312?B?1bLD9w==?=) Date: Thu, 2 Aug 2012 17:35:35 +0800 Subject: [Live-devel] VLC playback problem using live555MediaServer with RTP over TCP Message-ID: <000601cd7092$2bb809f0$83281dd0$@net.cn> Hi Ross, With the latest live555MediaServer , when I use VLC test a mp3 stream, it works fine when VLC?s live55 stream transport mode setting is HTTP. However, if the setting is changed to RTP over RTSP(TCP) . live555MediaServer does receive the request, produce and send back the stream output. But live555MediaServer will fail in sending packets back before the stream finish, and I can?t hear any sound. I don?t know what might caused the issue, could you give advice? FYI, here is some live555MediaServer output shown below: accept()ed connection from 127.0.0.1 Liveness indication from client at 127.0.0.1 Liveness indication from client at 127.0.0.1 RTSPClientSession[00397058]::handleRequestBytes() read 224 new bytes:GET /sample.mp3 HTTP/1.0 CSeq: 1 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) x-sessioncookie: 807ad86b495889a5551c5b9 Accept: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache parseRTSPRequestString() failed parseHTTPRequestString() succeeded, returning cmdName "GET", urlSuffix "sample.mp3", sessionCookie "807ad86b495889a5551c5b9", acceptStr "application/x-rtsp-tunn elled" Handled HTTP "GET" request (client output socket: 172) sending response: HTTP/1.0 200 OK Date: Thu, 19 Aug 1982 18:30:00 GMT Cache-Control: no-cache Pragma: no-cache Content-Type: application/x-rtsp-tunnelled accept()ed connection from 127.0.0.1 Liveness indication from client at 127.0.0.1 Liveness indication from client at 127.0.0.1 RTSPClientSession[00CC0068]::handleRequestBytes() read 457 new bytes:POST /sample.mp3 HTTP/1.0 CSeq: 1 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) x-sessioncookie: 807ad86b495889a5551c5b9 Content-Type: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Content-Length: 32767 Expires: Sun, 9 Jan 1972 00:00:00 GMT T1BUSU9OUyBydHNwOi8vbG9jYWxob3N0L3NhbXBsZS5tcDMgUlRTUC8xLjANCkNTZXE6IDINClVz ZXItQWdlbnQ6IExpYlZMQy8yLjAuMyAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTEuMTIu MjMpDQoN Cg== parseRTSPRequestString() failed parseHTTPRequestString() succeeded, returning cmdName "POST", urlSuffix "sample.mp3", sessionCookie "807ad86b495889a5551c5b9", acceptStr "" Handled HTTP "POST" request (client input socket: 432) Liveness indication from client at 127.0.0.1 RTSPClientSession[00397058]::handleRequestBytes() read 164 new bytes:T1BUSU9OUyBydHNwOi8vbG9jYWxob3N0L3NhbXBsZS5tcDMgUlRTUC8xLjANCkNTZXE6ID INClVzZXItQWdlbnQ6IEx pYlZMQy8yLjAuMyAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTEuMTIuMjMpDQoNCg== Base64-decoded 164 input bytes into 121 new bytes:OPTIONS rtsp://localhost/sample.mp3 RTSP/1.0 CSeq: 2 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "sample.mp3", CSeq "2", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 2 Date: Thu, Aug 02 2012 09:10:18 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Liveness indication from client at 127.0.0.1 RTSPClientSession[00397058]::handleRequestBytes() read 196 new bytes:REVTQ1JJQkUgcnRzcDovL2xvY2FsaG9zdC9zYW1wbGUubXAzIFJUU1AvMS4wDQpDU2VxOi AzDQpVc2VyLUFnZW50OiB MaWJWTEMvMi4wLjMgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDExLjEyLjIzKQ0KQWNjZXB 0OiBhcHBsaWNhdGlvbi9zZHANCg0K Base64-decoded 196 input bytes into 147 new bytes:DESCRIBE rtsp://localhost/sample.mp3 RTSP/1.0 CSeq: 3 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) Accept: application/sdp parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "sample.mp3", CSeq "3", Content-Length 0, with 0 bytes following th e message. sending response: RTSP/1.0 200 OK CSeq: 3 Date: Thu, Aug 02 2012 09:10:18 GMT Content-Base: rtsp://127.0.0.1:8554/sample.mp3/ Content-Type: application/sdp Content-Length: 395 v=0 o=- 1343898618406946 1 IN IP4 192.168.1.36 s=MPEG-1 or 2 Audio, streamed by the LIVE555 Media Server i=sample.mp3 t=0 0 a=tool:LIVE555 Streaming Media v2012.07.18 a=type:broadcast a=control:* a=range:npt=0-89.572 a=x-qt-text-nam:MPEG-1 or 2 Audio, streamed by the LIVE555 Media Server a=x-qt-text-inf:sample.mp3 m=audio 0 RTP/AVP 14 c=IN IP4 0.0.0.0 b=AS:160 a=control:track1 Liveness indication from client at 127.0.0.1 RTSPClientSession[00397058]::handleRequestBytes() read 240 new bytes:U0VUVVAgcnRzcDovLzEyNy4wLjAuMTo4NTU0L3NhbXBsZS5tcDMvdHJhY2sxIFJUU1AvMS 4wDQpDU2VxOiA0DQpVc2V yLUFnZW50OiBMaWJWTEMvMi4wLjMgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDExLjEyLjI zKQ0KVHJhbnNwb3J0OiBSVFAvQVZQL1RDUDt1bmljYXN0O2ludGVybGVhdmVkPTAtMQ0KDQo= Base64-decoded 240 input bytes into 179 new bytes:SETUP rtsp://127.0.0.1:8554/sample.mp3/track1 RTSP/1.0 CSeq: 4 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "sample.mp3", urlSuffix "track1", CSeq "4", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 4 Date: Thu, Aug 02 2012 09:10:18 GMT Transport: RTP/AVP/TCP;unicast;destination=127.0.0.1;source=127.0.0.1;interleaved=0-1 Session: E7490178 Liveness indication from client at 127.0.0.1 RTSPClientSession[00397058]::handleRequestBytes() read 216 new bytes:UExBWSBydHNwOi8vMTI3LjAuMC4xOjg1NTQvc2FtcGxlLm1wMy8gUlRTUC8xLjANCkNTZX E6IDUNClVzZXItQWdlbnQ 6IExpYlZMQy8yLjAuMyAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTEuMTIuMjMpDQpTZXN zaW9uOiBFNzQ5MDE3OA0KUmFuZ2U6IG5wdD0wLjAwMC0NCg0K Base64-decoded 216 input bytes into 162 new bytes:PLAY rtsp://127.0.0.1:8554/sample.mp3/ RTSP/1.0 CSeq: 5 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) Session: E7490178 Range: npt=0.000- parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "sample.mp3", urlSuffix "", CSeq "5", Content-Length 0, with 0 bytes following the me ssage. RTCPInstance[00CCB698]::RTCPInstance() schedule(1.549158->1343898619.982103) mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 0 m->a:read frame 0<-0, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 0<-0, nbr:36, sis:32, dh:486, (descriptor size: 1) mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 0 a->m:read frame 0<-0, fs:522, sis:32, dh:486, (descriptor size: 1) mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 0 m->a:read frame 0<-0, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 0<-0, nbr:36, sis:32, dh:486, (descriptor size: 1) mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 0 a->m:read frame 0<-0, fs:522, sis:32, dh:486, (descriptor size: 1) a->m:outputting frame for 0<-0 (fs 522, dh 486), (descriptorSize: 1) a->m:outputting 486 zero bytes (486, 0, 486, 0) mp3GetADUInfoFromFrame: hdr: fffba260, frameSize: 523, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 438 m->a:read frame 0<-438, fs:523, sis:32, dh:487, (descriptor size: 0) m->a:outputting ADU 0<-438, nbr:36, sis:32, dh:487, (descriptor size: 1) mp3GetADUInfoFromFrame: hdr: fffba260, frameSize: 523, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 438 a->m:read frame 0<-438, fs:523, sis:32, dh:487, (descriptor size: 1) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 207, 2177,165,1749, aduSize: 538, backpointer: 437 m->a:read frame 538<-437, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 538<-437, nbr:574, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 207, 2177,165,1749, aduSize: 538, backpointer: 437 a->m:read frame 538<-437, fs:522, sis:32, dh:486, (descriptor size: 2) a->m:outputting frame for 0<-0 (fs 522, dh 486), (descriptorSize: 1) a->m:outputting 48 zero bytes (48, 0, 486, 438) sendRTPOverTCP: 1060 bytes over channel 0 (socket 172) sendRTPOverTCP: completed sending response: RTSP/1.0 200 OK CSeq: 5 Date: Thu, Aug 02 2012 09:10:18 GMT Range: npt=0.000- Session: E7490178 RTP-Info: url=rtsp://127.0.0.1:8554/sample.mp3/track1;seq=17164;rtptime=160052885 a->m:outputting frame for 0<-438 (fs 523, dh 487), (descriptorSize: 1) a->m:outputting 50 zero bytes (50, 0, 487, 437) a->m:outputting 437 bytes from 538<-437 mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 1889,69,1950,160, aduSize: 509, backpointer: 385 m->a:read frame 509<-385, fs:523, sis:32, dh:487, (descriptor size: 0) m->a:outputting ADU 509<-385, nbr:545, sis:32, dh:487, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 1889,69,1950,160, aduSize: 509, backpointer: 385 a->m:read frame 509<-385, fs:523, sis:32, dh:487, (descriptor size: 2) a->m:outputting frame for 538<-437 (fs 522, dh 486), (descriptorSize: 2) a->m:outputting 101 bytes from 538<-437 a->m:outputting 385 bytes from 509<-385 sendRTPOverTCP: 1061 bytes over channel 0 (socket 172) sendRTPOverTCP: completed mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 22,42,914,1128, aduSize: 264, backpointer: 363 m->a:read frame 264<-363, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 264<-363, nbr:300, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 22,42,914,1128, aduSize: 264, backpointer: 363 a->m:read frame 264<-363, fs:522, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 1777,1309,1598,1536, aduSize: 778, backpointer: 438 m->a:read frame 778<-438, fs:523, sis:32, dh:487, (descriptor size: 0) m->a:outputting ADU 778<-438, nbr:814, sis:32, dh:487, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 1777,1309,1598,1536, aduSize: 778, backpointer: 438 a->m:read frame 778<-438, fs:523, sis:32, dh:487, (descriptor size: 2) a->m:outputting frame for 509<-385 (fs 523, dh 487), (descriptorSize: 2) a->m:outputting 124 bytes from 509<-385 a->m:outputting 264 bytes from 264<-363 a->m:outputting frame for 264<-363 (fs 522, dh 486), (descriptorSize: 2) a->m:outputting 48 zero bytes (48, 0, 486, 438) a->m:outputting 438 bytes from 778<-438 sendRTPOverTCP: 1061 bytes over channel 0 (socket 172) sendRTPOverTCP: completed ... ... schedule(4.364644->1343898627.575027) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1160,1223,633,605, aduSize: 453, backpointer: 157 m->a:read frame 453<-157, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 453<-157, nbr:489, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1160,1223,633,605, aduSize: 453, backpointer: 157 a->m:read frame 453<-157, fs:522, sis:32, dh:486, (descriptor size: 2) a->m:outputting frame for 459<-129 (fs 523, dh 487), (descriptorSize: 2) a->m:outputting 330 bytes from 459<-129 a->m:outputting 157 bytes from 453<-157 mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1248,1177,651,623, aduSize: 463, backpointer: 190 m->a:read frame 463<-190, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 463<-190, nbr:499, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1248,1177,651,623, aduSize: 463, backpointer: 190 a->m:read frame 463<-190, fs:522, sis:32, dh:486, (descriptor size: 2) a->m:outputting frame for 453<-157 (fs 522, dh 486), (descriptorSize: 2) a->m:outputting 296 bytes from 453<-157 a->m:outputting 190 bytes from 463<-190 sendRTPOverTCP: 1061 bytes over channel 0 (socket 172) sendRTPOverTCP: failed! mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 976, 969,959,964, aduSize: 484, backpointer: 213 m->a:read frame 484<-213, fs:523, sis:32, dh:487, (descriptor size: 0) m->a:outputting ADU 484<-213, nbr:520, sis:32, dh:487, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 976, 969,959,964, aduSize: 484, backpointer: 213 a->m:read frame 484<-213, fs:523, sis:32, dh:487, (descriptor size: 2) a->m:outputting frame for 463<-190 (fs 522, dh 486), (descriptorSize: 2) a->m:outputting 273 bytes from 463<-190 a->m:outputting 213 bytes from 484<-213 mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1203,1211,672,636, aduSize: 466, backpointer: 216 m->a:read frame 466<-216, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 466<-216, nbr:502, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1203,1211,672,636, aduSize: 466, backpointer: 216 a->m:read frame 466<-216, fs:522, sis:32, dh:486, (descriptor size: 2) a->m:outputting frame for 484<-213 (fs 523, dh 487), (descriptorSize: 2) a->m:outputting 271 bytes from 484<-213 a->m:outputting 216 bytes from 466<-216 sendRTPOverTCP: 1061 bytes over channel 0 (socket 172) sendRTPOverTCP: failed! ... ... Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhanm at join.net.cn Thu Aug 2 02:35:35 2012 From: zhanm at join.net.cn (=?gb2312?B?1bLD9w==?=) Date: Thu, 2 Aug 2012 17:35:35 +0800 Subject: [Live-devel] VLC playback problem using live555MediaServer with RTP over TCP Message-ID: <000601cd7092$2bb809f0$83281dd0$@net.cn> Hi Ross, With the latest live555MediaServer , when I use VLC test a mp3 stream, it works fine when VLC?s live55 stream transport mode setting is HTTP. However, if the setting is changed to RTP over RTSP(TCP) . live555MediaServer does receive the request, produce and send back the stream output. But live555MediaServer will fail in sending packets back before the stream finish, and I can?t hear any sound. I don?t know what might caused the issue, could you give advice? FYI, here is some live555MediaServer output shown below: accept()ed connection from 127.0.0.1 Liveness indication from client at 127.0.0.1 Liveness indication from client at 127.0.0.1 RTSPClientSession[00397058]::handleRequestBytes() read 224 new bytes:GET /sample.mp3 HTTP/1.0 CSeq: 1 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) x-sessioncookie: 807ad86b495889a5551c5b9 Accept: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache parseRTSPRequestString() failed parseHTTPRequestString() succeeded, returning cmdName "GET", urlSuffix "sample.mp3", sessionCookie "807ad86b495889a5551c5b9", acceptStr "application/x-rtsp-tunn elled" Handled HTTP "GET" request (client output socket: 172) sending response: HTTP/1.0 200 OK Date: Thu, 19 Aug 1982 18:30:00 GMT Cache-Control: no-cache Pragma: no-cache Content-Type: application/x-rtsp-tunnelled accept()ed connection from 127.0.0.1 Liveness indication from client at 127.0.0.1 Liveness indication from client at 127.0.0.1 RTSPClientSession[00CC0068]::handleRequestBytes() read 457 new bytes:POST /sample.mp3 HTTP/1.0 CSeq: 1 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) x-sessioncookie: 807ad86b495889a5551c5b9 Content-Type: application/x-rtsp-tunnelled Pragma: no-cache Cache-Control: no-cache Content-Length: 32767 Expires: Sun, 9 Jan 1972 00:00:00 GMT T1BUSU9OUyBydHNwOi8vbG9jYWxob3N0L3NhbXBsZS5tcDMgUlRTUC8xLjANCkNTZXE6IDINClVz ZXItQWdlbnQ6IExpYlZMQy8yLjAuMyAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTEuMTIu MjMpDQoN Cg== parseRTSPRequestString() failed parseHTTPRequestString() succeeded, returning cmdName "POST", urlSuffix "sample.mp3", sessionCookie "807ad86b495889a5551c5b9", acceptStr "" Handled HTTP "POST" request (client input socket: 432) Liveness indication from client at 127.0.0.1 RTSPClientSession[00397058]::handleRequestBytes() read 164 new bytes:T1BUSU9OUyBydHNwOi8vbG9jYWxob3N0L3NhbXBsZS5tcDMgUlRTUC8xLjANCkNTZXE6ID INClVzZXItQWdlbnQ6IEx pYlZMQy8yLjAuMyAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTEuMTIuMjMpDQoNCg== Base64-decoded 164 input bytes into 121 new bytes:OPTIONS rtsp://localhost/sample.mp3 RTSP/1.0 CSeq: 2 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "sample.mp3", CSeq "2", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 2 Date: Thu, Aug 02 2012 09:10:18 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Liveness indication from client at 127.0.0.1 RTSPClientSession[00397058]::handleRequestBytes() read 196 new bytes:REVTQ1JJQkUgcnRzcDovL2xvY2FsaG9zdC9zYW1wbGUubXAzIFJUU1AvMS4wDQpDU2VxOi AzDQpVc2VyLUFnZW50OiB MaWJWTEMvMi4wLjMgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDExLjEyLjIzKQ0KQWNjZXB 0OiBhcHBsaWNhdGlvbi9zZHANCg0K Base64-decoded 196 input bytes into 147 new bytes:DESCRIBE rtsp://localhost/sample.mp3 RTSP/1.0 CSeq: 3 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) Accept: application/sdp parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "sample.mp3", CSeq "3", Content-Length 0, with 0 bytes following th e message. sending response: RTSP/1.0 200 OK CSeq: 3 Date: Thu, Aug 02 2012 09:10:18 GMT Content-Base: rtsp://127.0.0.1:8554/sample.mp3/ Content-Type: application/sdp Content-Length: 395 v=0 o=- 1343898618406946 1 IN IP4 192.168.1.36 s=MPEG-1 or 2 Audio, streamed by the LIVE555 Media Server i=sample.mp3 t=0 0 a=tool:LIVE555 Streaming Media v2012.07.18 a=type:broadcast a=control:* a=range:npt=0-89.572 a=x-qt-text-nam:MPEG-1 or 2 Audio, streamed by the LIVE555 Media Server a=x-qt-text-inf:sample.mp3 m=audio 0 RTP/AVP 14 c=IN IP4 0.0.0.0 b=AS:160 a=control:track1 Liveness indication from client at 127.0.0.1 RTSPClientSession[00397058]::handleRequestBytes() read 240 new bytes:U0VUVVAgcnRzcDovLzEyNy4wLjAuMTo4NTU0L3NhbXBsZS5tcDMvdHJhY2sxIFJUU1AvMS 4wDQpDU2VxOiA0DQpVc2V yLUFnZW50OiBMaWJWTEMvMi4wLjMgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDExLjEyLjI zKQ0KVHJhbnNwb3J0OiBSVFAvQVZQL1RDUDt1bmljYXN0O2ludGVybGVhdmVkPTAtMQ0KDQo= Base64-decoded 240 input bytes into 179 new bytes:SETUP rtsp://127.0.0.1:8554/sample.mp3/track1 RTSP/1.0 CSeq: 4 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "sample.mp3", urlSuffix "track1", CSeq "4", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 4 Date: Thu, Aug 02 2012 09:10:18 GMT Transport: RTP/AVP/TCP;unicast;destination=127.0.0.1;source=127.0.0.1;interleaved=0-1 Session: E7490178 Liveness indication from client at 127.0.0.1 RTSPClientSession[00397058]::handleRequestBytes() read 216 new bytes:UExBWSBydHNwOi8vMTI3LjAuMC4xOjg1NTQvc2FtcGxlLm1wMy8gUlRTUC8xLjANCkNTZX E6IDUNClVzZXItQWdlbnQ 6IExpYlZMQy8yLjAuMyAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTEuMTIuMjMpDQpTZXN zaW9uOiBFNzQ5MDE3OA0KUmFuZ2U6IG5wdD0wLjAwMC0NCg0K Base64-decoded 216 input bytes into 162 new bytes:PLAY rtsp://127.0.0.1:8554/sample.mp3/ RTSP/1.0 CSeq: 5 User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2011.12.23) Session: E7490178 Range: npt=0.000- parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "sample.mp3", urlSuffix "", CSeq "5", Content-Length 0, with 0 bytes following the me ssage. RTCPInstance[00CCB698]::RTCPInstance() schedule(1.549158->1343898619.982103) mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 0 m->a:read frame 0<-0, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 0<-0, nbr:36, sis:32, dh:486, (descriptor size: 1) mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 0 a->m:read frame 0<-0, fs:522, sis:32, dh:486, (descriptor size: 1) mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 0 m->a:read frame 0<-0, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 0<-0, nbr:36, sis:32, dh:486, (descriptor size: 1) mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 0 a->m:read frame 0<-0, fs:522, sis:32, dh:486, (descriptor size: 1) a->m:outputting frame for 0<-0 (fs 522, dh 486), (descriptorSize: 1) a->m:outputting 486 zero bytes (486, 0, 486, 0) mp3GetADUInfoFromFrame: hdr: fffba260, frameSize: 523, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 438 m->a:read frame 0<-438, fs:523, sis:32, dh:487, (descriptor size: 0) m->a:outputting ADU 0<-438, nbr:36, sis:32, dh:487, (descriptor size: 1) mp3GetADUInfoFromFrame: hdr: fffba260, frameSize: 523, part2_3_lengths: 0,0, 0,0, aduSize: 0, backpointer: 438 a->m:read frame 0<-438, fs:523, sis:32, dh:487, (descriptor size: 1) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 207, 2177,165,1749, aduSize: 538, backpointer: 437 m->a:read frame 538<-437, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 538<-437, nbr:574, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 207, 2177,165,1749, aduSize: 538, backpointer: 437 a->m:read frame 538<-437, fs:522, sis:32, dh:486, (descriptor size: 2) a->m:outputting frame for 0<-0 (fs 522, dh 486), (descriptorSize: 1) a->m:outputting 48 zero bytes (48, 0, 486, 438) sendRTPOverTCP: 1060 bytes over channel 0 (socket 172) sendRTPOverTCP: completed sending response: RTSP/1.0 200 OK CSeq: 5 Date: Thu, Aug 02 2012 09:10:18 GMT Range: npt=0.000- Session: E7490178 RTP-Info: url=rtsp://127.0.0.1:8554/sample.mp3/track1;seq=17164;rtptime=160052885 a->m:outputting frame for 0<-438 (fs 523, dh 487), (descriptorSize: 1) a->m:outputting 50 zero bytes (50, 0, 487, 437) a->m:outputting 437 bytes from 538<-437 mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 1889,69,1950,160, aduSize: 509, backpointer: 385 m->a:read frame 509<-385, fs:523, sis:32, dh:487, (descriptor size: 0) m->a:outputting ADU 509<-385, nbr:545, sis:32, dh:487, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 1889,69,1950,160, aduSize: 509, backpointer: 385 a->m:read frame 509<-385, fs:523, sis:32, dh:487, (descriptor size: 2) a->m:outputting frame for 538<-437 (fs 522, dh 486), (descriptorSize: 2) a->m:outputting 101 bytes from 538<-437 a->m:outputting 385 bytes from 509<-385 sendRTPOverTCP: 1061 bytes over channel 0 (socket 172) sendRTPOverTCP: completed mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 22,42,914,1128, aduSize: 264, backpointer: 363 m->a:read frame 264<-363, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 264<-363, nbr:300, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba040, frameSize: 522, part2_3_lengths: 22,42,914,1128, aduSize: 264, backpointer: 363 a->m:read frame 264<-363, fs:522, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 1777,1309,1598,1536, aduSize: 778, backpointer: 438 m->a:read frame 778<-438, fs:523, sis:32, dh:487, (descriptor size: 0) m->a:outputting ADU 778<-438, nbr:814, sis:32, dh:487, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 1777,1309,1598,1536, aduSize: 778, backpointer: 438 a->m:read frame 778<-438, fs:523, sis:32, dh:487, (descriptor size: 2) a->m:outputting frame for 509<-385 (fs 523, dh 487), (descriptorSize: 2) a->m:outputting 124 bytes from 509<-385 a->m:outputting 264 bytes from 264<-363 a->m:outputting frame for 264<-363 (fs 522, dh 486), (descriptorSize: 2) a->m:outputting 48 zero bytes (48, 0, 486, 438) a->m:outputting 438 bytes from 778<-438 sendRTPOverTCP: 1061 bytes over channel 0 (socket 172) sendRTPOverTCP: completed ... ... schedule(4.364644->1343898627.575027) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1160,1223,633,605, aduSize: 453, backpointer: 157 m->a:read frame 453<-157, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 453<-157, nbr:489, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1160,1223,633,605, aduSize: 453, backpointer: 157 a->m:read frame 453<-157, fs:522, sis:32, dh:486, (descriptor size: 2) a->m:outputting frame for 459<-129 (fs 523, dh 487), (descriptorSize: 2) a->m:outputting 330 bytes from 459<-129 a->m:outputting 157 bytes from 453<-157 mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1248,1177,651,623, aduSize: 463, backpointer: 190 m->a:read frame 463<-190, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 463<-190, nbr:499, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1248,1177,651,623, aduSize: 463, backpointer: 190 a->m:read frame 463<-190, fs:522, sis:32, dh:486, (descriptor size: 2) a->m:outputting frame for 453<-157 (fs 522, dh 486), (descriptorSize: 2) a->m:outputting 296 bytes from 453<-157 a->m:outputting 190 bytes from 463<-190 sendRTPOverTCP: 1061 bytes over channel 0 (socket 172) sendRTPOverTCP: failed! mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 976, 969,959,964, aduSize: 484, backpointer: 213 m->a:read frame 484<-213, fs:523, sis:32, dh:487, (descriptor size: 0) m->a:outputting ADU 484<-213, nbr:520, sis:32, dh:487, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba240, frameSize: 523, part2_3_lengths: 976, 969,959,964, aduSize: 484, backpointer: 213 a->m:read frame 484<-213, fs:523, sis:32, dh:487, (descriptor size: 2) a->m:outputting frame for 463<-190 (fs 522, dh 486), (descriptorSize: 2) a->m:outputting 273 bytes from 463<-190 a->m:outputting 213 bytes from 484<-213 mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1203,1211,672,636, aduSize: 466, backpointer: 216 m->a:read frame 466<-216, fs:522, sis:32, dh:486, (descriptor size: 0) m->a:outputting ADU 466<-216, nbr:502, sis:32, dh:486, (descriptor size: 2) mp3GetADUInfoFromFrame: hdr: fffba060, frameSize: 522, part2_3_lengths: 1203,1211,672,636, aduSize: 466, backpointer: 216 a->m:read frame 466<-216, fs:522, sis:32, dh:486, (descriptor size: 2) a->m:outputting frame for 484<-213 (fs 523, dh 487), (descriptorSize: 2) a->m:outputting 271 bytes from 484<-213 a->m:outputting 216 bytes from 466<-216 sendRTPOverTCP: 1061 bytes over channel 0 (socket 172) sendRTPOverTCP: failed! ... ... Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Aug 2 05:45:27 2012 From: warren at etr-usa.com (Warren Young) Date: Thu, 02 Aug 2012 06:45:27 -0600 Subject: [Live-devel] CPU intensive on ARM using testH264VideoStreamer with TI encoder In-Reply-To: <5018fcb7.08030e0a.52e9.ffffd1e1@mx.google.com> References: <5018fcb7.08030e0a.52e9.ffffd1e1@mx.google.com> Message-ID: <501A7667.6070701@etr-usa.com> On 8/1/2012 3:53 AM, Shlomi wrote: > I am using a TI DaVinci processor to create a h264 file. > When trying to stream this file with testH264VideoStreamer, the cpu goes up > to 80% (which is bad for me since it is already in use by other > applications). > When trying to stream the slamtv60.264 found on the live555 site, all is > good (cpu consumption is about 4-10%). What is the bit rate of your encoded video? I don't know what the bit rate is for the test file you downloaded -- no tool I threw at it could make much sense of it -- but I'll bet it's pretty low. If, say, the test file is 1 Mbit/s and you're encoding to 9 Mbit/s, there's your CPU differential right there. It takes CPU power to pump I/O unless you're using DMA. From finlayson at live555.com Thu Aug 2 05:52:41 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 2 Aug 2012 05:52:41 -0700 Subject: [Live-devel] CPU intensive on ARM using testH264VideoStreamer with TI encoder In-Reply-To: <5018fcb7.08030e0a.52e9.ffffd1e1@mx.google.com> References: <5018fcb7.08030e0a.52e9.ffffd1e1@mx.google.com> Message-ID: <70FBB0DA-38F2-45E2-9D5B-B908889644E7@live555.com> > I am using a TI DaVinci processor to create a h264 file. > When trying to stream this file with testH264VideoStreamer, the cpu goes up > to 80% (which is bad for me since it is already in use by other > applications). http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work Please put your ".264" file on a (publicly accessible) web server, and send us the URL, so we can download and test it for ourselves. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 2 05:56:42 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 2 Aug 2012 05:56:42 -0700 Subject: [Live-devel] VLC playback problem using live555MediaServer with RTP over TCP In-Reply-To: <000601cd7092$2bb809f0$83281dd0$@net.cn> References: <000601cd7092$2bb809f0$83281dd0$@net.cn> Message-ID: <2F27AC01-F03E-4322-B687-A155277E1BC1@live555.com> > With the latest live555MediaServer No, the latest released version of the source code is 2012.07.26; you are using version 2012.07.18. > , when I use VLC test a mp3 stream, it works fine when VLC?s live55 stream transport mode setting is HTTP. However, if the setting is changed to RTP over RTSP(TCP) . live555MediaServer does receive the request, produce and send back the stream output. The best client to use, initially, to test things like this is "openRTSP" - not VLC (which is not our application). In particular, note the "-t" and "-T " options in "openRTSP". You should also note the difference between "RTP-over-RTSP' tunneling (specified by the "-t" option in "openRTSP"), and "RTSP-over-HTTP" tunneling (specified by the "-T " option in "openRTSP"). ("RTSP-over-HTTP" tunneling implies "RTP-over-RTSP' tunneling, but not vice versa.) Also, you should do your initial testing without modifying the supplied code. I notice that you have enabled streaming using MP3 'ADUs'. You should not do this at first. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 2 06:05:35 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 2 Aug 2012 06:05:35 -0700 Subject: [Live-devel] Reminder: Experimental new RTSP server implementation available for testing Message-ID: A reminder that if you use our RTSP server code in your application (*especially* if you have subclassed the "RTSPServer" class), you are encouraged to download and test the experimental new RTSP server implementation, described here: http://lists.live555.com/pipermail/live-devel/2012-July/015571.html Unless bugs are reported, this version will become *the* lone supported version - perhaps in just a few days. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.orry at em-sys.fr Thu Aug 2 08:05:25 2012 From: lionel.orry at em-sys.fr (Lionel Orry) Date: Thu, 02 Aug 2012 17:05:25 +0200 Subject: [Live-devel] Reminder: Experimental new RTSP server implementation available for testing In-Reply-To: References: Message-ID: <1343919925.31331.3.camel@localhost.localdomain> On Thu, 2012-08-02 at 06:05 -0700, Ross Finlayson wrote: > A reminder that if you use our RTSP server code in your application > (*especially* if you have subclassed the "RTSPServer" class), you are > encouraged to download and test the experimental new RTSP server > implementation, described here: > http://lists.live555.com/pipermail/live-devel/2012-July/015571.html > Hello Ross, I ported my development on this branch and for now it seems to work nicely. I could also verify that the session is kept while the client is sending requests with the same session id throught different TCP connections. I am extremely happy about that! I still have to check that several sessions can be handled in a single connection but according to the comments I found in the code, it should work as well. Congrats for the good work, I'll report any issue I find as soon as possible. Cheers, Lionel > > Unless bugs are reported, this version will become *the* lone > supported version - perhaps in just a few days. > > > 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 From lshl.shlomi at gmail.com Thu Aug 2 06:38:48 2012 From: lshl.shlomi at gmail.com (Shlomi) Date: Thu, 2 Aug 2012 16:38:48 +0300 Subject: [Live-devel] CPU intensive on ARM using testH264VideoStreamer with TI encoder In-Reply-To: <70FBB0DA-38F2-45E2-9D5B-B908889644E7@live555.com> References: <5018fcb7.08030e0a.52e9.ffffd1e1@mx.google.com> <70FBB0DA-38F2-45E2-9D5B-B908889644E7@live555.com> Message-ID: <501a82ed.c6d80e0a.7761.3cbd@mx.google.com> The file is available at http://minicomdsje.sytes.net:8090/Support/video.264 Thanks From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: ? 02 ?????? 2012 15:53 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] CPU intensive on ARM using testH264VideoStreamer with TI encoder I am using a TI DaVinci processor to create a h264 file. When trying to stream this file with testH264VideoStreamer, the cpu goes up to 80% (which is bad for me since it is already in use by other applications). http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work Please put your ".264" file on a (publicly accessible) web server, and send us the URL, so we can download and test it for ourselves. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Thu Aug 2 11:58:51 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Thu, 2 Aug 2012 18:58:51 +0000 Subject: [Live-devel] Cleanup problems when passing non-valid URL? Message-ID: I'm writing a playback client based on the testRTSPClient example. For each new stream to connect to, I setup a new environment, i.e. create new UsageEnvironment, StreamClientState etc. Everything works great and I can start and stop streams multiple times without seeing any issues. There is one exception, and it's when I try to connect to a totally messed up URL, e.g. "rtsp://coooow". The stream then appears to correctly "shut down" when ending up in continueAfterDESCRIBE(), but whatever stream I try connect to after that will end up in a fatal crash. As long as I send in valid URL's it doesn't crash, i.e. it behaves correctly even if there is no stream available. It is only when I send in non-valid URL's something bad happens. Example of stream connections; everything works fine until after rtsp://coooow: rtsp://192.168.1.103/live/MyWorkingCamera1 rtsp://192.168.1.103/live/NoStreamHere1 rtsp://192.168.1.103/live/MyWorkingCamera2 rtsp://192.168.1.103/live/MyWorkingCamera1 rtsp://192.168.1.103/live/NoStreamHere2 rtsp://192.168.1.103/live/MyWorkingCamera2 rtsp://coooow -> Whatever URL I try to connect to after this will trigger a fatal error I've tried to debug this a lot, but am kind of stuck. A solution is of course to validate the URL before passing it, but now I'm kind of curious what the issue is. I haven't been able narrow it down, but it appears to usually occur when a new RTSPClient is created, i.e. on OurRTSPClient::createNew(). Has anyone else experienced this? /Claes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5740 bytes Desc: not available URL: From finlayson at live555.com Thu Aug 2 12:29:21 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 2 Aug 2012 12:29:21 -0700 Subject: [Live-devel] Cleanup problems when passing non-valid URL? In-Reply-To: References: Message-ID: It would be useful to find out if this problem is caused by the LIVE555 code itself, or just by the way that you are using it in your application. To test this, it would be useful if a "valgrind" enthusiast (aka. a 'valgrinerd' :-) out there could try running "valgrind" on testRTSPClient rtsp://coooow (using the unmodified "testRTSPClient" code), and let us know if you see any signs of bad memory access. (Unfortunately I'm traveling right now, and don't have access to a computer with "valgrind".) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vautieri at geoweb3d.com Thu Aug 2 13:58:18 2012 From: vautieri at geoweb3d.com (Vincent A. Autieri II) Date: Thu, 2 Aug 2012 16:58:18 -0400 Subject: [Live-devel] raw h264 Message-ID: <000001cd70f1$8baa8590$a2ff90b0$@geoweb3d.com> Hello, I'm in the process of evaluating Live555, and I'm trying to send out a live H264 stream using the Intel's Media SDK H264 encoder. To ensure I was encoding properly, I made a raw h264 file and made sure I could stream out the file with mediaserver.exe, which with VLC it acted like the frame time was off(played quickly), but using SMPlayer everything worked fine(so I think that particular issue is VLC and not with the encoding). My second test is to see if I can get Live555 to now stream the output, meaning, instead of writing to a file, send out through RTSP. I was thinking I could just inherit FramedSource and when a mfxBitstream is completed with the intel encoder, in the FrameSource deliverReadyFrame, write into the Live555 libarary the binary data that was getting dumped to the raw h264 file. void EncoderSource::deliverReadyFrame() { if (!isCurrentlyAwaitingData()) return; if(pmfxBitstream) { u_int8_t* newFrameDataStart = pmfxBitstream ->Data + pmfxBitstream ->DataOffset; unsigned newFrameSize = pmfxBitstream ->DataLength; if (newFrameSize > fMaxSize) { fFrameSize = fMaxSize; fNumTruncatedBytes = newFrameSize - fMaxSize; } else { fFrameSize = newFrameSize; } gettimeofday(&fPresentationTime, NULL); memcpy(fTo, newFrameDataStart, fFrameSize); } FramedSource::afterGetting(this); } If it is support to work, please advise where I can look into what I might be doing wrong. With that said, when I run SMPlayer (mplayer) and connect through RTSP, I start to see video coming through (but it looks to be only the parts of the video that are changing), where SMPlayer then tosses up an exception dialog which I think is indicating an issue with the PPF and SPS exists. Initiated "video/H264" RTP subsession on port 18888 [NULL @ 002b8250]non-existing PPS referenced [NULL @ 002b8250]non-existing SPS 6 referenced in buffering period [NULL @ 002b8250]non-existing PPS referenced [NULL @ 002b8250]non-existing SPS 6 referenced in buffering period [NULL @ 002b8250]non-existing PPS referenced [NULL @ 002b8250]non-existing SPS 1 referenced in buffering period .. demux_rtp: Guessed the video frame rate as 25 frames-per-second. (If this is wrong, use the "-fps " option instead.) [ass] Init [ass] Updating font cache [h264 @ 01CDB8F4]non-existing PPS 0 referenced [h264 @ 01CDB8F4]decode_slice_header error [h264 @ 01CDB8F4]no frame! Error while decoding frame! [h264 @ 01CDB8F4]non-existing SPS 6 referenced in buffering period ... [NULL @ 002b8250]non-existing SPS 4 referenced in buffering period [NULL @ 002b8250]non-existing PPS referenced [NULL @ 002b8250]non-existing SPS 4 referenced in buffering period [NULL @ 002b8250]non-existing PPS referenced [NULL @ 002b8250]non-existing SPS 4 referenced in buffering period [NULL @ 002b8250]non-existing PPS referenced [NULL @ 002b8250]non-existing SPS 4 referenced in buffering period .. Doing a search within this group history, it seems I might need to inject the SPS and PPS? If I do, I think the code has changed since that post, and it's not clear how to set these, as I think the SPS and PPS can change at any time during a stream(to control the quality of the connection etc., changing bitrates etc.). Can you point me into the right direction with the Live555 library? I'm not an expert with the Live555 library nor the Intel Library, so I'm probably missing something simple.. Thanks, Vincent -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 2 14:54:27 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 2 Aug 2012 14:54:27 -0700 Subject: [Live-devel] CPU intensive on ARM using testH264VideoStreamer with TI encoder In-Reply-To: <5018fcb7.08030e0a.52e9.ffffd1e1@mx.google.com> References: <5018fcb7.08030e0a.52e9.ffffd1e1@mx.google.com> Message-ID: <70E03333-DAFF-41B4-9181-A88A74F31DE3@live555.com> > I guess (and again it is ONLY a guess) the intensive cpu usage comes from > the need to break the big h264 frames to MTU fragments (i.e. ~1450 B). Because the high CPU usage (at least, what I observed when I streamed your file using "testH264VideoStreamer") occurred in bursts, rather than during the entire streaming of the file, I suspect that yes, indeed, your very large IDR picture frames (76950 bytes and 106365 bytes) are to blame. Note that the fact that these frames need to be fragmented is not an issue; most of the overhead occurs from having to parse and copy the frames, regardless of whether they're being fragmented. (In any case, it turns out that almost all of your frames end up being fragmented, because they're almost all larger than the MTU.) > I can't reduce the size of the h264 frames because the stream bandwidth > (8Mbps) must be retained (part of the requirements). You might not be able to reduce the bandwidth of the stream, but you can reduce your NAL unit sizes, by getting your encoder to encode each IDR picture into multiple 'slice' NAL units. This is a good idea, because if packets forming a 'slice' NAL unit get lost, then that will cause only that slice to be non-renderable. On the other hand, if the IDR picture is a complete NAL unit, then the loss of *any* packet (and note that your 106365 byte picture will be sent in at least 70 RTP packets!) will cause the whole picture to be non-renderable. Another thing that you can do to reduce overhead is read your NAL units from your decoder one at a time, and use "H264VideoStreamDiscreteFramer" rather than "H264VideoStreamFramer" to parse them. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Thu Aug 2 15:12:04 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Thu, 02 Aug 2012 15:12:04 -0700 Subject: [Live-devel] CPU intensive on ARM using testH264VideoStreamer with TI encoder In-Reply-To: <501a82ed.c6d80e0a.7761.3cbd@mx.google.com> References: <5018fcb7.08030e0a.52e9.ffffd1e1@mx.google.com> <70FBB0DA-38F2-45E2-9D5B-B908889644E7@live555.com> <501a82ed.c6d80e0a.7761.3cbd@mx.google.com> Message-ID: <501AFB34.50906@schuckmannacres.com> Shlomi, I'm doing pretty much the same thing you are on the same processor (except with my own app and a live 3Mpix camera source) and I've seen the same thing, and in my experience the CPU utilization goes up in direct relationship to the streaming bit rate. For me anything over about 20mbps pretty much swamps the ARM CPU at about 85%, note when I'm not streaming, i.e. just capture and encode the ARM CPU is only about 4% I've determined that big part of this is plain old memcpy(), it's really not all that efficient on this processor and you have do it to use liveMedia. The IP stack isn't all that efficient either. I've done experiments with iperf and streaming 20Mbps in UDP mode consumes about 30% of the ARM CPU. It gets even worse with TCP streaming. For my application I think I'll be ok, as there isn't whole lot more going on on the proc, other than streaming and my bit rates should be sub 15Mbps but it sure would be nice if we could avoid the memcpy() in liveMedia, I know all the reasons why it is there and that there is a hope to some day get rid of it but who knows when that will happen. Matt S. On Thursday, August 02, 2012 6:38:48 AM, Shlomi wrote: > The file is available at > http://minicomdsje.sytes.net:8090/Support/video.264 > > Thanks > > *From:*live-devel-bounces at ns.live555.com > [mailto:live-devel-bounces at ns.live555.com] *On Behalf Of *Ross Finlayson > *Sent:* ?02 ??????2012 15:53 > *To:* LIVE555 Streaming Media - development & use > *Subject:* Re: [Live-devel] CPU intensive on ARM using > testH264VideoStreamer with TI encoder > > I am using a TI DaVinci processor to create a h264 file. > When trying to stream this file with testH264VideoStreamer, the > cpu goes up > to 80% (which is bad for me since it is already in use by other > applications). > > http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work > > Please put your ".264" file on a (publicly accessible) web server, and > send us the URL, so we can download and test it for ourselves. > > 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 From finlayson at live555.com Thu Aug 2 15:54:08 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 2 Aug 2012 15:54:08 -0700 Subject: [Live-devel] raw h264 In-Reply-To: <000001cd70f1$8baa8590$a2ff90b0$@geoweb3d.com> References: <000001cd70f1$8baa8590$a2ff90b0$@geoweb3d.com> Message-ID: <31EFD35D-78A6-4D5D-AC2A-1A07FB64CDD5@live555.com> > I?m in the process of evaluating Live555, and I?m trying to send out a live H264 stream using the Intel?s Media SDK H264 encoder. To ensure I was encoding properly, I made a raw h264 file and made sure I could stream out the file with mediaserver.exe, which with VLC it acted like the frame time was off(played quickly), but using SMPlayer everything worked fine(so I think that particular issue is VLC and not with the encoding). That's odd, because VLC is usually more reliable than (S)MPlayer. But anyway... > My second test is to see if I can get Live555 to now stream the output, meaning, instead of writing to a file, send out through RTSP. I found this confusing, because that ("sending it out through RTSP") is what you were doing before, when you ran the "LIVE555MediaServer". However, from the rest of your message, I inferred that what you were really talking about was having the server take your H.264 input directly from your encoder, rather than from a file. So, because you've read the FAQ, I assume that you have written your own subclass of "OnDemandServerMediaSubsession" (that sets the "reuseFirstSource" parameter to True), and have redefined the "createNewStreamSource()" and "createNewRTPSink()" virtual functions. Your "createNewRTPSink()" implementation can be exactly the same as the one that's in "H264VideoFileServerMediaSubsession.cpp". Your "createNewStreamSource()" implementation, however, would create a new instance of your "EncoderSource" class, and feed it to a "H264VideoStreamDiscreteFramer" (note, *not* a "H264VideoStreamFramer"). The function would then return a pointer to the 'framer' object. There are two important things to note: 1/ Each NAL unit delivered by your "EncoderSource" class must be a single, complete NAL unit, *without* a preceding 'start code' (i.e., with *no* preceding 0x00000001) 2/ You need to provide SPS and PPS NAL units. If they occur frequently in the encoder's output, then there is nothing more that you need to do. If, however, the SPS and PPS NAL units do not occur frequently (or at all) in the encoder's output, then you need to supply them directly. (In this case we assume that the SPS and PPS NAL units are static - i.e., do not change within the stream.) There are two ways you can do this: 1/ In your "createNewStreamSource()" function, call "H264VideoStreamFramer::setSPSandPPS()" on the "H264VideoStreamDiscreteFramer" object (which is a subclass of "H264VideoStreamFramer"), before you return it. 2/ Alternatively, in your "createNewRTPSink()" function, use one of the variants of "H264VideoRTPSink::createNew()" that take SPS/PPS NAL units as parameters. Finally, when you are streaming directly from your encoder, rather than from a file, you should consider using VLC - rather than MPlayer - as a client. The timing problems that you saw when you streamed from a file will probably not occur when you're streaming from your encoder. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hh3.kim at samsung.com Thu Aug 2 22:06:42 2012 From: hh3.kim at samsung.com (HYUN HO KIM) Date: Fri, 03 Aug 2012 05:06:42 +0000 (GMT) Subject: [Live-devel] EINTR, EAGAIN, EINPROGRESS, EDOULDBLOCK Compile warning Message-ID: <0M8500FOVY76U4L0@mailout1.samsung.com> An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 3 01:11:39 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 3 Aug 2012 01:11:39 -0700 Subject: [Live-devel] EINTR, EAGAIN, EINPROGRESS, EDOULDBLOCK Compile warning In-Reply-To: <0M8500FOVY76U4L0@mailout1.samsung.com> References: <0M8500FOVY76U4L0@mailout1.samsung.com> Message-ID: > When i compile my program with live555 header files, compile warning is occurring. > I'm developing the application in MSVC-2010, it seems to groupsock/include/netcommon.h file is comflicted with msvc2010/include/errno.h. > Your consideration in this matter will be appreciated. > A compiler warning is not necessarily a problem. (Sometimes it can just be an annoyance.) How are those four macros - EINTR, EAGAIN, EINPROGRESS, EDOULDBLOCK - defined in your "msvc2010/include/errno.h" file? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Sun Aug 5 08:26:39 2012 From: jshanab at smartwire.com (Jeff Shanab) Date: Sun, 5 Aug 2012 15:26:39 +0000 Subject: [Live-devel] CPU intensive on ARM using testH264VideoStreamer with TI encoder Message-ID: <615FD77639372542BF647F5EBAA2DBC225207DEA@IL-BOL-EXCH01.smartwire.com> This situation with the large keyframes reminds me to ask if live555 can handle the Periodic Intra Refresh protocol? X264 supports it and If i can find an embedded device that can handle it it would help me a lot on my project. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Aug 5 10:00:57 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 5 Aug 2012 11:00:57 -0600 Subject: [Live-devel] CPU intensive on ARM using testH264VideoStreamer with TI encoder In-Reply-To: <615FD77639372542BF647F5EBAA2DBC225207DEA@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC225207DEA@IL-BOL-EXCH01.smartwire.com> Message-ID: > This situation with the large keyframes reminds me to ask if live555 can handle the Periodic Intra Refresh protocol? Yes, it can handle any valid NAL unit - including "Periodic Intra Refresh" NAL units. (Note that the LIVE555 code just transports (packs/unpacks) NAL units in RTP packets; it doesn't process the contents of NAL units at all.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hh3.kim at samsung.com Tue Aug 7 19:05:00 2012 From: hh3.kim at samsung.com (=?euc-kr?B?sejH9sij?=) Date: Wed, 08 Aug 2012 02:05:00 +0000 (GMT) Subject: [Live-devel] EINTR, EAGAIN, EINPROGRESS, EDOULDBLOCK Compile warning Message-ID: <0M8E00226Z4DVYA0@mailout4.samsung.com> An HTML attachment was scrubbed... URL: From lionel.orry at em-sys.fr Fri Aug 10 01:00:34 2012 From: lionel.orry at em-sys.fr (Lionel Orry) Date: Fri, 10 Aug 2012 10:00:34 +0200 Subject: [Live-devel] Make all RTSP requests potentially session-aware Message-ID: <1344585634.8658.22.camel@localhost.localdomain> Hi Ross, I would like to know if that would be interesting to make all RTSP requests handling in RTSPServer session-aware; an example of flow would be, for a request XXX currently unaware of session (OPTIONS for instance): - detect presence of Session header - if present: - call RTSPServer::RTSPClientSession::handleCmd_XXX() - default implementation of handleCmd_XXX() is to call RTSPServer::RTSPClientConnection::handleCmd_XXX() - implementation in RTSPClientConnection as usual - if absent: - call RTSPServer::RTSPClientConnection::handleCmd_XXX() directly That way, if one needs a special handling of such a request in a session context, he can override RTSPServer::RTSPClientSession::handleCmd_XXX(). What do you think about it? Regards, Lionel From sidprice at softtools.com Fri Aug 10 12:11:23 2012 From: sidprice at softtools.com (Sid Price) Date: Fri, 10 Aug 2012 13:11:23 -0600 Subject: [Live-devel] Problems using testOnDemandRTSPServer Message-ID: <000901cd772b$efc90480$cf5b0d80$@softtools.com> Ross, I have been trying to get the testOnDemandRTSPServer application running on my Windows Compact 7 device. All appears to have compiled OK and I am able to connect to the server using VLC to play a WAV file on the embedded device. The issue I am having is that the playback is just not stable, i.e. the audio stops and starts. This behavior goes on for about 20 seconds into the file after which the playback goes fine. All the time the audio is not playing the progress bar of VLS appears to be advancing normally. I have looked at the Wireshark capture of the network activity and it looks OK to me. I have posted the capture here: https://dl.dropbox.com/u/53358015/RTP_StreamingWAV.zip Is it possible you, or someone else on the list who is familiar with this to take a look at the capture and give me some guidance as to where the problem lies. I am a novice with RTP/RTSP and hoping to move my knowledge forward with this test program before I need to implement the actual code. Many thanks, Sid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 10 13:55:58 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Aug 2012 13:55:58 -0700 Subject: [Live-devel] Make all RTSP requests potentially session-aware In-Reply-To: <1344585634.8658.22.camel@localhost.localdomain> References: <1344585634.8658.22.camel@localhost.localdomain> Message-ID: <870DB6E0-B235-4199-A95D-1685F86CA983@live555.com> > I would like to know if that would be interesting to make all RTSP > requests handling in RTSPServer session-aware; an example of flow would > be, for a request XXX currently unaware of session (OPTIONS for > instance) No, because the "OPTIONS" command - for listing the RTSP commands that the server supports - applies to the server as a whole, rather than to a particular session. If you want to redefine the handling of the "OPTIONS" command, then the way to do this is to subclass "RTSPClientConnection" (not "RTSPClientSession"), and reimplement the "handleCmd_OPTIONS()" virtual function. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 10 15:00:23 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Aug 2012 15:00:23 -0700 Subject: [Live-devel] Problems using testOnDemandRTSPServer In-Reply-To: <000901cd772b$efc90480$cf5b0d80$@softtools.com> References: <000901cd772b$efc90480$cf5b0d80$@softtools.com> Message-ID: > I have been trying to get the testOnDemandRTSPServer application running on my Windows Compact 7 device. All appears to have compiled OK and I am able to connect to the server using VLC to play a WAV file on the embedded device. The issue I am having is that the playback is just not stable, i.e. the audio stops and starts. This behavior goes on for about 20 seconds into the file after which the playback goes fine. Does the problem happen with all WAV files that you try, or just one? Does the problem happen only when the server runs on your 'Windows Compact 7 device', or also when it runs on some other computer (e.g., a Windows, Mac OS or Linux desktop computer)? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Fri Aug 10 15:50:45 2012 From: sidprice at softtools.com (Sid Price) Date: Fri, 10 Aug 2012 16:50:45 -0600 Subject: [Live-devel] Problems using testOnDemandRTSPServer In-Reply-To: References: <000901cd772b$efc90480$cf5b0d80$@softtools.com> Message-ID: <004101cd774a$94fce7a0$bef6b6e0$@softtools.com> Ross, I have tried another WAV file and it performs in a similar manner. I have not built the application to run on another platform. Does the Wireshark capture look right? Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, August 10, 2012 4:00 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Problems using testOnDemandRTSPServer I have been trying to get the testOnDemandRTSPServer application running on my Windows Compact 7 device. All appears to have compiled OK and I am able to connect to the server using VLC to play a WAV file on the embedded device. The issue I am having is that the playback is just not stable, i.e. the audio stops and starts. This behavior goes on for about 20 seconds into the file after which the playback goes fine. Does the problem happen with all WAV files that you try, or just one? Does the problem happen only when the server runs on your 'Windows Compact 7 device', or also when it runs on some other computer (e.g., a Windows, Mac OS or Linux desktop computer)? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.orry at gmail.com Fri Aug 10 15:46:26 2012 From: lionel.orry at gmail.com (Lionel Orry) Date: Sat, 11 Aug 2012 00:46:26 +0200 Subject: [Live-devel] Make all RTSP requests potentially session-aware In-Reply-To: <870DB6E0-B235-4199-A95D-1685F86CA983@live555.com> References: <1344585634.8658.22.camel@localhost.localdomain> <870DB6E0-B235-4199-A95D-1685F86CA983@live555.com> Message-ID: On Fri, Aug 10, 2012 at 10:55 PM, Ross Finlayson wrote: > I would like to know if that would be interesting to make all RTSP > requests handling in RTSPServer session-aware; an example of flow would > be, for a request XXX currently unaware of session (OPTIONS for > instance) > > > No, because the "OPTIONS" command - for listing the RTSP commands that the > server supports - applies to the server as a whole, rather than to a > particular session. > > If you want to redefine the handling of the "OPTIONS" command, then the way > to do this is to subclass "RTSPClientConnection" (not "RTSPClientSession"), > and reimplement the "handleCmd_OPTIONS()" virtual function. That's what I did, and I put in it additional parsing code for the Session header and could retrieve the corresponding session with a Lookup. Thanks anyway, Lionel > > > 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 > From finlayson at live555.com Fri Aug 10 17:10:55 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Aug 2012 17:10:55 -0700 Subject: [Live-devel] Problems using testOnDemandRTSPServer In-Reply-To: <004101cd774a$94fce7a0$bef6b6e0$@softtools.com> References: <000901cd772b$efc90480$cf5b0d80$@softtools.com> <004101cd774a$94fce7a0$bef6b6e0$@softtools.com> Message-ID: <3AC759BD-9202-4382-9161-8712BFC3E8E8@live555.com> > I have tried another WAV file and it performs in a similar manner. > > I have not built the application to run on another platform. I suggest you try this. > Does the Wireshark capture look right? I didn't have time to look at it in detail. But problems like this are usually the fault of VLC - which we can't do anything about, because it's not our software. However, you should make sure that you haven't disabled (or reduced) any of VLC's buffering (perhaps called 'caching' in VLC's GUI). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 10 17:15:07 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Aug 2012 17:15:07 -0700 Subject: [Live-devel] Make all RTSP requests potentially session-aware In-Reply-To: References: <1344585634.8658.22.camel@localhost.localdomain> <870DB6E0-B235-4199-A95D-1685F86CA983@live555.com> Message-ID: > That's what I did, and I put in it additional parsing code for the > Session header and could retrieve the corresponding session with a > Lookup. But there's no guarantee that an "OPTIONS" request will even contain a session header. And even if it does, there's nothing session-specific that you could/should be doing to handle it, because the only thing an "OPTIONS" response should contain is a list of request names that the server handles. And that has nothing to do with session-specific state. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionel.orry at gmail.com Fri Aug 10 17:37:50 2012 From: lionel.orry at gmail.com (Lionel Orry) Date: Sat, 11 Aug 2012 02:37:50 +0200 Subject: [Live-devel] Make all RTSP requests potentially session-aware In-Reply-To: References: <1344585634.8658.22.camel@localhost.localdomain> <870DB6E0-B235-4199-A95D-1685F86CA983@live555.com> Message-ID: On Sat, Aug 11, 2012 at 2:15 AM, Ross Finlayson wrote: > That's what I did, and I put in it additional parsing code for the > Session header and could retrieve the corresponding session with a > Lookup. > > > But there's no guarantee that an "OPTIONS" request will even contain a > session header. And even if it does, there's nothing session-specific that > you could/should be doing to handle it, because the only thing an "OPTIONS" > response should contain is a list of request names that the server handles. > And that has nothing to do with session-specific state. I agree with you. But I am working with a kind of proprietary RTSP superset which need this (they use OPTIONS to keep-alive sessions), and I am not responsible for these choices. :) Lionel > > > 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 > From finlayson at live555.com Sat Aug 11 02:40:55 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Aug 2012 02:40:55 -0700 Subject: [Live-devel] Make all RTSP requests potentially session-aware In-Reply-To: References: <1344585634.8658.22.camel@localhost.localdomain> <870DB6E0-B235-4199-A95D-1685F86CA983@live555.com> Message-ID: <06A67B39-A512-411D-B415-1E6B338CD363@live555.com> > I agree with you. But I am working with a kind of proprietary RTSP > superset which need this (they use OPTIONS to keep-alive sessions), > and I am not responsible for these choices. :) Even though you might feel that you're "not responsible for these choices" made by the developers of this client, I hope that you contact them, asking them to fix their clients so that they adhere to the standard, which is to use RTCP "RR" packets (or, failing that, RTSP "GET_PARAMETER" requests) as keep-alives. But if you can't do that, then - because all of the important member variables and member functions of "RTSPClientConnection" and "RTSPClientSession" are "protected" rather than "private" - you should be able to reimplement the "OPTIONS" handler to parse the session id and use it to look up the "RTSPClientSession" object (and then do whatever you want with it). You'll get no help from me on this, though. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaarj1 at gmail.com Sun Aug 12 02:33:34 2012 From: skaarj1 at gmail.com (Skaarj NaPali) Date: Sun, 12 Aug 2012 11:33:34 +0200 Subject: [Live-devel] EINTR, EAGAIN, EINPROGRESS, EDOULDBLOCK Compile warning Message-ID: The patch which was introduced in 2012.08.08 of live555 "solves" the compile time problem, but leads to wrong error numbers in the binary. The reason for this is because VS2010 does define those error constants in "errno.h" but the Windows socket API does not use them. The Windows socket API still returns WSAE error codes only. But the WSAE error codes do not match the error codes which are defined "errno.h". There other ways to solve that problem. You may want to compile the library code with "-DNO_SSTREAM" which is the originator of the problem, because including of "" in "groupsock" library also pulls in the problematic "errno.h" indirectly. You can undefine any already defined constants from "errno.h" like shown below. <<>> ... ... ... #define closeSocket closesocket #ifdef EWOULDBLOCK #undef EWOULDBLOCK #endif #ifdef EINPROGRESS #undef EINPROGRESS #endif #ifdef EAGAIN #undef EAGAIN #endif #ifdef EINTR #undef EINTR #endif #define EWOULDBLOCK WSAEWOULDBLOCK #define EINPROGRESS WSAEWOULDBLOCK #define EAGAIN WSAEWOULDBLOCK #define EINTR WSAEINTR ... ... ... Personally I am using both solutions to be on the safe side. However, the proper solution would be to map WSAE error codes to "errno.h" error codes within "BasicUsageEnvironment::getErrno()" -- this would be the most portable and clean solution. But because not all of the WSAE error codes do have a respective "errno.h" error code, it would most likely again cause some quirks here and there throughout the source code in future. Therefore I am recommending to "undef" any existing error codes right before defining new ones in "NetCommon.h". From finlayson at live555.com Sun Aug 12 06:31:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 12 Aug 2012 06:31:51 -0700 Subject: [Live-devel] EINTR, EAGAIN, EINPROGRESS, EDOULDBLOCK Compile warning In-Reply-To: References: Message-ID: <9EF37382-A9C1-4EEA-8076-81F7ABB849B4@live555.com> > You can undefine any already defined constants from "errno.h" like shown below. > > <<>> > ... > ... > ... > #define closeSocket closesocket > #ifdef EWOULDBLOCK > #undef EWOULDBLOCK > #endif > #ifdef EINPROGRESS > #undef EINPROGRESS > #endif > #ifdef EAGAIN > #undef EAGAIN > #endif > #ifdef EINTR > #undef EINTR > #endif > #define EWOULDBLOCK WSAEWOULDBLOCK > #define EINPROGRESS WSAEWOULDBLOCK > #define EAGAIN WSAEWOULDBLOCK > #define EINTR WSAEINTR OK, I've just installed a new version of the code that makes this change, (Quite frankly, Windows is becoming more trouble than it's worth...) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From edenlee at gorilla-technology.com Sun Aug 12 18:11:10 2012 From: edenlee at gorilla-technology.com (Eden Lee (Gorilla)) Date: Mon, 13 Aug 2012 09:11:10 +0800 Subject: [Live-devel] FW: A Problem of RTSP Server In-Reply-To: References: Message-ID: Dear Sir., I build a RTST server according to testOnDemandRTSPServer.cpp. It works fine on small image video files. But, it is failure when serving large-scale (high resolution video, such as 720*576 or 1920*1080) image video files. Please refer to the attached file. You can see that the lower half image is not correctly displayed. What's wrong? How do I modify the sample program? Would you please kindly provide some comment? Thank you so much for quickly reply. Sincerely, Eden Lee Technical Lead, IVS Surveillance & Security Business Gorilla Technology Inc. Taipei, Taiwan. TEL: +886-2-2627-7996 Ext.2007 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: picture.jpg Type: image/jpeg Size: 111076 bytes Desc: picture.jpg URL: From finlayson at live555.com Sun Aug 12 20:14:55 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 12 Aug 2012 20:14:55 -0700 Subject: [Live-devel] FW: A Problem of RTSP Server In-Reply-To: References: Message-ID: <05FFBC8A-683E-4DE3-A7B8-2033345CBD06@live555.com> It's simply impossible to answer questions like this, because you haven't provided nearly enough information. For starters, you haven't said what type of file you are trying to stream - i.e., what is the format of the file, and what codec(s) does it contain. It's also quite possible that the problem is caused not by our server, but instead by your RTSP video player client, which you haven't told us anything about (and which we can't do anything about, unless perhaps it happens to use our RTSP client implementation). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From edenlee at gorilla-technology.com Sun Aug 12 20:50:07 2012 From: edenlee at gorilla-technology.com (Eden Lee (Gorilla)) Date: Mon, 13 Aug 2012 11:50:07 +0800 Subject: [Live-devel] FW: A Problem of RTSP Server In-Reply-To: <05FFBC8A-683E-4DE3-A7B8-2033345CBD06@live555.com> References: <05FFBC8A-683E-4DE3-A7B8-2033345CBD06@live555.com> Message-ID: Dear Ross, First of all, thanks for the reply. The file type is .264, that is, H.264 elementary file. I try your mediaServer, it has the same problem. We also try to save H264 elementary source as MPEG4 file. And, Windows Movie Player plays it correctly. Is it possible that we can contact by MSN? I can also transfer the file to you for checking. My MSN: edenleego at hotmail.com. The time to me is very urgent. I really need your kindly support. Thank you so much in advance. Best regards, Eden From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, August 13, 2012 11:15 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] FW: A Problem of RTSP Server It's simply impossible to answer questions like this, because you haven't provided nearly enough information. For starters, you haven't said what type of file you are trying to stream - i.e., what is the format of the file, and what codec(s) does it contain. It's also quite possible that the problem is caused not by our server, but instead by your RTSP video player client, which you haven't told us anything about (and which we can't do anything about, unless perhaps it happens to use our RTSP client implementation). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Aug 12 20:57:59 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 12 Aug 2012 20:57:59 -0700 Subject: [Live-devel] A Problem of RTSP Server In-Reply-To: References: <05FFBC8A-683E-4DE3-A7B8-2033345CBD06@live555.com> Message-ID: > The file type is .264, that is, H.264 elementary file. > Is it possible that we can contact by MSN? No. Support for the "LIVE555 Streaming Media" software is via this mailing list. > I can also transfer the file to you for checking. Please put it on a web server, and send us the URL. See http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work (Remember, you were asked to read the FAQ before posting to this mailing list :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From edenlee at gorilla-technology.com Sun Aug 12 21:37:35 2012 From: edenlee at gorilla-technology.com (Eden Lee (Gorilla)) Date: Mon, 13 Aug 2012 12:37:35 +0800 Subject: [Live-devel] Request to mailing list live-devel rejected In-Reply-To: References: Message-ID: Sir., Here is the URL https://docs.google.com/open?id=0B6Nd9tNkZgo5YzJfSm9MaHVIRGc Eden -----Original Message----- From: Eden Lee (Gorilla) Sent: Monday, August 13, 2012 12:28 PM To: live-devel-owner at ns.live555.com; Eden Lee (Gorilla) Subject: RE: Request to mailing list live-devel rejected Dear Sir., Yes, I will try to find a web server and send you the URL. Thank you very much. Eden -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of live-devel-owner at ns.live555.com Sent: Monday, August 13, 2012 12:24 PM To: Eden Lee (Gorilla) Subject: Request to mailing list live-devel rejected Your request to the live-devel mailing list Posting of your message titled "RE: [Live-devel] FW: A Problem of RTSP Server" has been rejected by the list moderator. The moderator gave the following reason for rejecting your request: "Your message was too big. Please do what I said: Put the file on a web server, and send the URL (*not* the file itself) to the mailing list." Any questions or comments should be directed to the list administrator at: live-devel-owner at lists.live555.com From finlayson at live555.com Sun Aug 12 21:50:58 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 12 Aug 2012 21:50:58 -0700 Subject: [Live-devel] A Problem of RTSP Server In-Reply-To: References: <05FFBC8A-683E-4DE3-A7B8-2033345CBD06@live555.com> Message-ID: <5137E5A4-BB43-4AAD-9387-663E7CAC9272@live555.com> The problem with your file can be seen clearly if you look at the warning messages that are clearly being output on your console. For example: MultiFramedRTPSink::afterGettingFrame1(): The input frame data was too large for our buffer size (101348). 35198 bytes of trailing data was dropped! Correct this by increasing "OutPacketBuffer::maxSize" to at least 135198, *before* creating this 'RTPSink'. (Current value is 100000.) (Did you not notice these messages in your console output??) I.e., the problem is that your file contains several extremely large (I might say ridiculously large - see below[*]) NAL unit. By default, the "LIVE555 Media Server" code uses a buffer that is not large enough to handle such huge NAL units. However, you can fix it by changing line 117 of "mediaServer/DynamicRTSPServer.cpp" from OutPacketBuffer::maxSize = 100000; // allow for some possibly large H.264 frames to OutPacketBuffer::maxSize = 200000; // allow for some possibly large H.264 frames and recompiling the LIVE555 Media Server. If you do this, you will eliminate the problem at the server end. However, your client - VLC - will still have a problem when it receives the first of these extremely large NAL units. It also uses a buffer that is, by default, too small to receive these large NAL units. The first time it notices that its buffer is too small, it will increase the buffer size, and then that will prevent the problem reoccurring for subsequent NAL units. [*]The only way to overcome this (other than by modifying and recompiling VLC, but that's not our software) is to not send such ridiculously large NAL units. You should reconfigure your encoder to encode each IDR picture (i.e., 'I-frame') into multiple 'slice' NAL units. This is a good idea, because if packets forming a 'slice' NAL unit get lost, then that will cause only that slice to be non-renderable. On the other hand, if the IDR picture is a complete NAL unit, then the loss of *any* packet will cause the whole picture to be non-renderable. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From edenlee at gorilla-technology.com Wed Aug 15 00:42:43 2012 From: edenlee at gorilla-technology.com (Eden Lee (Gorilla)) Date: Wed, 15 Aug 2012 15:42:43 +0800 Subject: [Live-devel] A Problem of RTSP Server In-Reply-To: <5137E5A4-BB43-4AAD-9387-663E7CAC9272@live555.com> References: <05FFBC8A-683E-4DE3-A7B8-2033345CBD06@live555.com> <5137E5A4-BB43-4AAD-9387-663E7CAC9272@live555.com> Message-ID: Yes Sir., I change OutPacketBuffer::maxSize to be 300000. The display of local RTSP client is correct. Unfortunately, the remote client's display is still incorrect. Do you have any idea about this situation? Expect your response. Thank you. Best regards, Eden From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, August 13, 2012 12:51 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] A Problem of RTSP Server The problem with your file can be seen clearly if you look at the warning messages that are clearly being output on your console. For example: MultiFramedRTPSink::afterGettingFrame1(): The input frame data was too large for our buffer size (101348). 35198 bytes of trailing data was dropped! Correct this by increasing "OutPacketBuffer::maxSize" to at least 135198, *before* creating this 'RTPSink'. (Current value is 100000.) (Did you not notice these messages in your console output??) I.e., the problem is that your file contains several extremely large (I might say ridiculously large - see below[*]) NAL unit. By default, the "LIVE555 Media Server" code uses a buffer that is not large enough to handle such huge NAL units. However, you can fix it by changing line 117 of "mediaServer/DynamicRTSPServer.cpp" from OutPacketBuffer::maxSize = 100000; // allow for some possibly large H.264 frames to OutPacketBuffer::maxSize = 200000; // allow for some possibly large H.264 frames and recompiling the LIVE555 Media Server. If you do this, you will eliminate the problem at the server end. However, your client - VLC - will still have a problem when it receives the first of these extremely large NAL units. It also uses a buffer that is, by default, too small to receive these large NAL units. The first time it notices that its buffer is too small, it will increase the buffer size, and then that will prevent the problem reoccurring for subsequent NAL units. [*]The only way to overcome this (other than by modifying and recompiling VLC, but that's not our software) is to not send such ridiculously large NAL units. You should reconfigure your encoder to encode each IDR picture (i.e., 'I-frame') into multiple 'slice' NAL units. This is a good idea, because if packets forming a 'slice' NAL unit get lost, then that will cause only that slice to be non-renderable. On the other hand, if the IDR picture is a complete NAL unit, then the loss of *any* packet will cause the whole picture to be non-renderable. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Aug 15 00:50:23 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 15 Aug 2012 00:50:23 -0700 Subject: [Live-devel] A Problem of RTSP Server In-Reply-To: References: <05FFBC8A-683E-4DE3-A7B8-2033345CBD06@live555.com> <5137E5A4-BB43-4AAD-9387-663E7CAC9272@live555.com> Message-ID: <2F533FDD-2E45-4A30-8229-937E655D41B1@live555.com> > I change OutPacketBuffer::maxSize to be 300000. The display of local RTSP client is correct. Unfortunately, the remote client?s display is still incorrect. Do you have any idea about this situation? No, but because you're seeing problems only with a remote (networked) VLC RTSP client, I suspect you're seeing some network packet loss. As I said before: "[You should not be sending] such ridiculously large NAL units. You should reconfigure your encoder to encode each IDR picture (i.e., 'I-frame') into multiple 'slice' NAL units. This is a good idea, because if packets forming a 'slice' NAL unit get lost, then that will cause only that slice to be non-renderable. On the other hand, if the IDR picture is a complete NAL unit, then the loss of *any* packet will cause the whole picture to be non-renderable." Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorpha at gmail.com Wed Aug 15 02:12:29 2012 From: jorpha at gmail.com (=?GB2312?B?0O2zpLeo?=) Date: Wed, 15 Aug 2012 17:12:29 +0800 Subject: [Live-devel] live555 proxy server issue In-Reply-To: References: Message-ID: Below is the log, FYI. Appreciate to get your response :-) E:\DELTA\Item\VidaGrid\M2\RTSP\open-source\live555-delta\bin\Debug>proxyServer.e xe -V rtsp://172.17.92.36:8557/h264 LIVE555 Proxy Server (LIVE555 Streaming Media library version 2012.07.26) Opening connection to 172.17.92.36, port 8557... RTSP stream, proxying the stream "rtsp://172.17.92.36:8557/h264" Play this stream using the URL "rtsp://172.17.92.116/proxyStream" (We use port 80 for optional RTSP-over-HTTP tunneling.) ...remote connection opened Sending request: DESCRIBE rtsp://172.17.92.36:8557/h264 RTSP/1.0 CSeq: 2 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.26) Accept: application/sdp Received 632 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Sat, Jan 01 2000 00:36:39 GMT Content-Base: rtsp://172.17.92.36:8557/h264/ Content-Type: application/sdp Content-Length: 469 v=0 o=- 946684820211305 1 IN IP4 172.17.92.36 s=RTSP/RTP stream from IPNC i=h264 t=0 0 a=tool:LIVE555 Streaming Media v2008.04.02 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:RTSP/RTP stream from IPNC a=x-qt-text-inf:h264 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=000042;sprop-parameter-sets=h264 a=control:track1 m=audio 0 RTP/AVP 0 c=IN IP4 0.0.0.0 a=control:track2 ProxyServerMediaSession["rtsp://172.17.92.36:8557/h264/"] added new "ProxyServer MediaSubsession" for RTP/video/H264 track ProxyServerMediaSession["rtsp://172.17.92.36:8557/h264/"] added new "ProxyServer MediaSubsession" for RTP/audio/PCMU track ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["H264"] ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["H264"]::closeStreamSource() ProxyServerMediaSubsession["PCMU"]::createNewStreamSource(session id 0) Initiated: ProxyServerMediaSubsession["PCMU"] ProxyServerMediaSubsession["PCMU"]::createNewRTPSink() ProxyServerMediaSubsession["PCMU"]::closeStreamSource() ProxyServerMediaSubsession["H264"]::createNewStreamSource(session id 3684920956) Sending request: SETUP rtsp://172.17.92.36:8557/h264/track1 RTSP/1.0 CSeq: 3 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.26) Transport: RTP/AVP;unicast;client_port=3602-3603 ProxyServerMediaSubsession["H264"]::createNewRTPSink() ProxyServerMediaSubsession["PCMU"]::createNewStreamSource(session id 3684920956) ProxyServerMediaSubsession["PCMU"]::createNewRTPSink() Received 196 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Sat, Jan 01 2000 00:36:42 GMT Transport: RTP/AVP;unicast;destination=172.17.92.116;source=172.17.92.36;client_ port=3602-3603;server_port=6970-6971 Session: 24 ProxyRTSPClient["rtsp://172.17.92.36:8557/h264/"]::continueAfterSETUP(): head co dec: H264; numSubsessions 2 queue: H264 PCMU Sending request: SETUP rtsp://172.17.92.36:8557/h264/track2 RTSP/1.0 CSeq: 4 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.26) Transport: RTP/AVP;unicast;client_port=3606-3607 Session: 24 Received 196 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Sat, Jan 01 2000 00:36:42 GMT Transport: RTP/AVP;unicast;destination=172.17.92.116;source=172.17.92.36;client_ port=3606-3607;server_port=6972-6973 Session: 24 ProxyRTSPClient["rtsp://172.17.92.36:8557/h264/"]::continueAfterSETUP(): head co dec: PCMU; numSubsessions 2 queue: PCMU Sending request: PLAY rtsp://172.17.92.36:8557/h264/ RTSP/1.0 CSeq: 5 User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2012.07.26) Session: 24 Received 228 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 5 Date: Sat, Jan 01 2000 00:36:42 GMT Session: 24 RTP-Info: url=rtsp:// 172.17.92.36:8557/h264/track1;seq=22905;rtptime=3193791389, url=rtsp://172.17.92.36:8557/h264/track2;seq=7153;rtptime=2252408833 H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input ....... 2012/8/15 ??? > Dear live dev team: > > i download the latest version of live555 source code and compile it > successfully. > Then i use proxy server to a ip camera(TEXAS) and use VLC to connect to > the proxy to see the video(H264), > Then i met below log : > H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the > input. > > and i can only see the video active only for about 5s, After 5s i can > only see a static picutre instead active video. > but if i use VLC to connect to the ip camera directly, i can see the > active video normally. > > my ip camera url : rtsp://172.17.92.36:8557/h264 > proxy server url : rtsp://172.17.92.116/proxyStream > > -- > Best Regards! > Jorpha > > -- Best Regards! Jorpha -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Aug 15 02:21:57 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 15 Aug 2012 02:21:57 -0700 Subject: [Live-devel] live555 proxy server issue In-Reply-To: References: Message-ID: > H264VideoStreamDiscreteFramer error: MPEG 'start code' seen in the input We had a similar report back in July. See http://lists.live555.com/pipermail/live-devel/2012-July/015474.html In short: The camera is sending invalid H.264/RTP packets, violating the standard. It needs to be fixed before it can work with the proxy server. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 503430770 at qq.com Wed Aug 15 18:32:04 2012 From: 503430770 at qq.com (=?ISO-8859-1?B?Li4u?=) Date: Thu, 16 Aug 2012 09:32:04 +0800 Subject: [Live-devel] rtp over rtsp error Message-ID: Hi,I'm using live555 as a server of realtime H264 data. The client reseive RTP data over tcp success. But the server will close after a few minites . I grasp network packets. I found server send RTCP packet and RTP packet on RTSP port(554). Our client just drop the RTCP packets.Our client must send the RTCP packet too? Now,how i can do with the RTCP packet to avoid server closeing. Thranks!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Aug 15 18:38:47 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 15 Aug 2012 18:38:47 -0700 Subject: [Live-devel] rtp over rtsp error In-Reply-To: References: Message-ID: <029943B7-E750-4F7A-BCA1-36E1EE137DF2@live555.com> > Hi,I'm using live555 as a server of realtime H264 data. The client reseive RTP data over tcp success. But the server will close after a few minites . I grasp network packets. I found server send RTCP packet and RTP packet on RTSP port(554). Our client just drop the RTCP packets.Our client must send the RTCP packet too? Yes, your client should implement RTCP, and send periodic RTCP "RR" (reception report) packets, as documented in RFC 3550. You can do this easily if you use our software to implement your client (not just your server). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorpha at gmail.com Wed Aug 15 19:34:12 2012 From: jorpha at gmail.com (=?GB2312?B?0O2zpLeo?=) Date: Thu, 16 Aug 2012 10:34:12 +0800 Subject: [Live-devel] rtp over rtsp error In-Reply-To: <029943B7-E750-4F7A-BCA1-36E1EE137DF2@live555.com> References: <029943B7-E750-4F7A-BCA1-36E1EE137DF2@live555.com> Message-ID: I guess my issue is caused by the same reason with you. RTCP "RR" is sent in OnExpire in rtcp_from_spec.c schedulely. But why server still close after about 5s ? 2012/8/16 Ross Finlayson > Hi,I'm using live555 as a server of realtime H264 data. The client > reseive RTP data over tcp success. But the server will close after a few > minites . I grasp network packets. I found server send RTCP packet and > RTP packet on RTSP port(554). Our client just drop the RTCP packets.Our > client must send the RTCP packet too? > > > Yes, your client should implement RTCP, and send periodic RTCP "RR" > (reception report) packets, as documented in RFC 3550. > > You can do this easily if you use our software to implement your client > (not just your server). > > > 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 > > -- Best Regards! Jorpha -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Aug 15 21:20:33 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 15 Aug 2012 21:20:33 -0700 Subject: [Live-devel] rtp over rtsp error In-Reply-To: References: <029943B7-E750-4F7A-BCA1-36E1EE137DF2@live555.com> Message-ID: <638477D2-F685-4D87-8DC3-C74E3119B1C0@live555.com> > I guess my issue is caused by the same reason with you. > RTCP "RR" is sent in OnExpire in rtcp_from_spec.c schedulely. > But why server still close after about 5s ? I don't know. Before, you said that the server closed "after a few minutes". Now, you say that the server closes "after 5s". I suggest that you add #define DEBUG 1 to the start of "liveMedia/RTSPServer.cpp", and then recompile. This will display a lot more information about what's happening with your server. (Be sure, of course, to use the latest version of the server code; the only version we support.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Thu Aug 16 12:58:59 2012 From: sidprice at softtools.com (Sid Price) Date: Thu, 16 Aug 2012 13:58:59 -0600 Subject: [Live-devel] Do the test applications ever sleep? Message-ID: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> Ross, While investigating another issue I began to dig a little deeper into how the library operates and it appears to me that the process running the servers never sleeps, is this correct? If so, since this process will run on an embedded system and we try not to waste cycles I would like to investigate letting the process sleep when there is no activity required. The application I have would only need to stream (multicast) linear PCM audio sources, a well-defined task. Do you think that sub-classing "BasicTaskScheduler::SingleStep would be the way to go to achieve this? Thanks, Sid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 16 13:28:04 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Aug 2012 13:28:04 -0700 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> Message-ID: > While investigating another issue I began to dig a little deeper into how the library operates and it appears to me that the process running the servers never sleeps, is this correct? Not really. I don't know what specifically you mean by 'sleep', but - as you know - LIVE555-based applications are event driven, and execute code only when handling an event. When there are no events to be handled, then the application does not run. You can call this 'sleeping' if you like. What you might be referring to, however, is the fact that - in the "BasicTaskScheduler" implementation - there is a periodic delayed task called "schedulerTickTask()" that runs every 10 milliseconds (not 10 microseconds as the comment in the code incorrectly says). This task does no work, and exists only to ensure that the code periodically returns from "select()", to handle any triggered events. But this causes only a brief period of activity (with almost no overhead) every 10 ms; for the rest of the time, the application is effectively 'sleeping' if there are no other events to be handled. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Thu Aug 16 14:16:25 2012 From: sidprice at softtools.com (Sid Price) Date: Thu, 16 Aug 2012 15:16:25 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> Message-ID: <007301cd7bf4$65f14600$31d3d200$@softtools.com> Thanks Ross. I used the word "sleeping" to mean that the process gives up any remaining time from its current time-slice for the OS to allocate as required. Using your information I did some more digging and if I measure the execution time of "SingleStep" when the OnDemandRTSPServer application is running with no client connections I see <1mS execution time. I think my test code is good: void BasicTaskScheduler0::doEventLoop(char* watchVariable) { // Repeatedly loop, handling readble sockets and timed events: while (1) { if (watchVariable != NULL && *watchVariable != 0) break; DWORD dwTick_1, dwTick_2 ; DWORD dwTickDelta ; dwTick_1 = GetTickCount(); SingleStep(); dwTick_2 = GetTickCount() ; dwTickDelta = dwTick_2 - dwTick_1 ; dwTick_1 = 0 ; // Place to breakpoint } } GetTickCount is a Windows API that retrieves the number of milliseconds that have elapsed since the system was started, up to 49.7 days, then it wraps. Syntax. "dwTickDelta" is always zero, meaning <1mS. What led me here was that I used a process monitor to measure the CPU % that the test application was consuming and when I have no client attached and therefore no streaming happening I see higher CPU usage than I expected. In the range 15-25% of CPU. The CPU is a fast ARM that should be more than enough horsepower for this task. Sid. Since there is nothing else in the "doEventLoop" I terms of calls I have to assume the 10mS you mentioned should be the execution time of the "SingleStep" method. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, August 16, 2012 2:28 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Do the test applications ever sleep? While investigating another issue I began to dig a little deeper into how the library operates and it appears to me that the process running the servers never sleeps, is this correct? Not really. I don't know what specifically you mean by 'sleep', but - as you know - LIVE555-based applications are event driven, and execute code only when handling an event. When there are no events to be handled, then the application does not run. You can call this 'sleeping' if you like. What you might be referring to, however, is the fact that - in the "BasicTaskScheduler" implementation - there is a periodic delayed task called "schedulerTickTask()" that runs every 10 milliseconds (not 10 microseconds as the comment in the code incorrectly says). This task does no work, and exists only to ensure that the code periodically returns from "select()", to handle any triggered events. But this causes only a brief period of activity (with almost no overhead) every 10 ms; for the rest of the time, the application is effectively 'sleeping' if there are no other events to be handled. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 16 14:43:55 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Aug 2012 14:43:55 -0700 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <007301cd7bf4$65f14600$31d3d200$@softtools.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> Message-ID: <8473682C-224E-4AF6-AB22-5855496AF0B7@live555.com> > Since there is nothing else in the ?doEventLoop? I terms of calls I have to assume the 10mS you mentioned should be the execution time of the ?SingleStep? method. That's correct. If the server really is doing nothing, and there is nothing happening on any on any of its sockets, then "SingleStep()" - specifically, the call to "select()" at line 80 of "BasicTaskScheduler.cpp" - should take about 10ms on average. (The reason for this is that there will be no activity on any of the sockets specified by "readSet", "writeSet", "exceptionSet", but "tv_timeToDelay" will be 10 ms (on average).) If, however, you find that the call to "select()" is consistently taking much less than 10ms on your system, then you'll have to figure out what's going wrong. (For starters, I suggest looking at the value of "selectResult" returned by the "select()" call; that should tell you why "select()" is returning early.) Remember, You Have Complete Source Code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikolai.vorontsov at quadrox.be Fri Aug 17 04:18:22 2012 From: nikolai.vorontsov at quadrox.be (Nikolai Vorontsov) Date: Fri, 17 Aug 2012 13:18:22 +0200 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <007301cd7bf4$65f14600$31d3d200$@softtools.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> Message-ID: Hello Sid, GetTickCount() is inaccurate in milliseconds interval. You better use timeGetTime() one (you will need to link a mm library). In any case I suppose that Ross holds the working thread on an event or something and thus efficiently release any time slices. Do a simple test - run idle server and check how much CPU it uses. Nikolai. ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Sid Price Sent: Thursday, August 16, 2012 11:16 PM To: 'LIVE555 Streaming Media - development & use' Subject: Re: [Live-devel] Do the test applications ever sleep? Thanks Ross. I used the word "sleeping" to mean that the process gives up any remaining time from its current time-slice for the OS to allocate as required. Using your information I did some more digging and if I measure the execution time of "SingleStep" when the OnDemandRTSPServer application is running with no client connections I see <1mS execution time. I think my test code is good: void BasicTaskScheduler0::doEventLoop(char* watchVariable) { // Repeatedly loop, handling readble sockets and timed events: while (1) { if (watchVariable != NULL && *watchVariable != 0) break; DWORD dwTick_1, dwTick_2 ; DWORD dwTickDelta ; dwTick_1 = GetTickCount(); SingleStep(); dwTick_2 = GetTickCount() ; dwTickDelta = dwTick_2 - dwTick_1 ; dwTick_1 = 0 ; // Place to breakpoint } } GetTickCount is a Windows API that retrieves the number of milliseconds that have elapsed since the system was started, up to 49.7 days, then it wraps. Syntax. "dwTickDelta" is always zero, meaning <1mS. What led me here was that I used a process monitor to measure the CPU % that the test application was consuming and when I have no client attached and therefore no streaming happening I see higher CPU usage than I expected. In the range 15-25% of CPU. The CPU is a fast ARM that should be more than enough horsepower for this task. Sid. Since there is nothing else in the "doEventLoop" I terms of calls I have to assume the 10mS you mentioned should be the execution time of the "SingleStep" method. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, August 16, 2012 2:28 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Do the test applications ever sleep? While investigating another issue I began to dig a little deeper into how the library operates and it appears to me that the process running the servers never sleeps, is this correct? Not really. I don't know what specifically you mean by 'sleep', but - as you know - LIVE555-based applications are event driven, and execute code only when handling an event. When there are no events to be handled, then the application does not run. You can call this 'sleeping' if you like. What you might be referring to, however, is the fact that - in the "BasicTaskScheduler" implementation - there is a periodic delayed task called "schedulerTickTask()" that runs every 10 milliseconds (not 10 microseconds as the comment in the code incorrectly says). This task does no work, and exists only to ensure that the code periodically returns from "select()", to handle any triggered events. But this causes only a brief period of activity (with almost no overhead) every 10 ms; for the rest of the time, the application is effectively 'sleeping' if there are no other events to be handled. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Fri Aug 17 08:17:50 2012 From: sidprice at softtools.com (Sid Price) Date: Fri, 17 Aug 2012 09:17:50 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> Message-ID: <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> Hello Nikolai, Thank you for taking the time to reply to my questions. I am well aware of the resolution of "GetTickCount()," I even mentioned it in an earlier post. Gicen the times we are trying to confirm it is more than adequate. Also, Ross has explained very well the way the process operates in a response to me earlier and events are not involved. I have run performance monitoring, again mentioned in an earlier post and I know pretty well that the "OnDemandRTSPServer" is consuming about 7% of my CPU time when Idle (just ran the tests and the earlier figure I quoted was not accurate). My hope was to reduce this to an absolute minimum by changing to a true event driven server. However I am not sure how practical that is without changing Ross' basic code and I do not want to do that. Again, thank you, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Nikolai Vorontsov Sent: Friday, August 17, 2012 5:18 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Do the test applications ever sleep? Hello Sid, GetTickCount() is inaccurate in milliseconds interval. You better use timeGetTime() one (you will need to link a mm library). In any case I suppose that Ross holds the working thread on an event or something and thus efficiently release any time slices. Do a simple test - run idle server and check how much CPU it uses. Nikolai. _____ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Sid Price Sent: Thursday, August 16, 2012 11:16 PM To: 'LIVE555 Streaming Media - development & use' Subject: Re: [Live-devel] Do the test applications ever sleep? Thanks Ross. I used the word "sleeping" to mean that the process gives up any remaining time from its current time-slice for the OS to allocate as required. Using your information I did some more digging and if I measure the execution time of "SingleStep" when the OnDemandRTSPServer application is running with no client connections I see <1mS execution time. I think my test code is good: void BasicTaskScheduler0::doEventLoop(char* watchVariable) { // Repeatedly loop, handling readble sockets and timed events: while (1) { if (watchVariable != NULL && *watchVariable != 0) break; DWORD dwTick_1, dwTick_2 ; DWORD dwTickDelta ; dwTick_1 = GetTickCount(); SingleStep(); dwTick_2 = GetTickCount() ; dwTickDelta = dwTick_2 - dwTick_1 ; dwTick_1 = 0 ; // Place to breakpoint } } GetTickCount is a Windows API that retrieves the number of milliseconds that have elapsed since the system was started, up to 49.7 days, then it wraps. Syntax. "dwTickDelta" is always zero, meaning <1mS. What led me here was that I used a process monitor to measure the CPU % that the test application was consuming and when I have no client attached and therefore no streaming happening I see higher CPU usage than I expected. In the range 15-25% of CPU. The CPU is a fast ARM that should be more than enough horsepower for this task. Sid. Since there is nothing else in the "doEventLoop" I terms of calls I have to assume the 10mS you mentioned should be the execution time of the "SingleStep" method. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, August 16, 2012 2:28 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Do the test applications ever sleep? While investigating another issue I began to dig a little deeper into how the library operates and it appears to me that the process running the servers never sleeps, is this correct? Not really. I don't know what specifically you mean by 'sleep', but - as you know - LIVE555-based applications are event driven, and execute code only when handling an event. When there are no events to be handled, then the application does not run. You can call this 'sleeping' if you like. What you might be referring to, however, is the fact that - in the "BasicTaskScheduler" implementation - there is a periodic delayed task called "schedulerTickTask()" that runs every 10 milliseconds (not 10 microseconds as the comment in the code incorrectly says). This task does no work, and exists only to ensure that the code periodically returns from "select()", to handle any triggered events. But this causes only a brief period of activity (with almost no overhead) every 10 ms; for the rest of the time, the application is effectively 'sleeping' if there are no other events to be handled. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 17 08:21:48 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 17 Aug 2012 08:21:48 -0700 Subject: [Live-devel] Range Header In-Reply-To: References: <8CE79E3CB2664753A3AA216BB47D82A7@Work><51CECC72-536F-4271-B8D1-52585B908E67@live555.com><527BA5F8C28A4D9982F00935D661DF2B@Work><6E9B28C2-B5CF-4637-B708-ED6B496F9C30@live555.com><34E799C37151466AA8D7E20E680FC8D7@Work> Message-ID: <0B54CF3F-3823-4D34-A59E-869B6C91D18A@live555.com> > Just wondering if this bug is a priority or if it may be a while. FYI, I have just installed a new version (2012.08.17) of the "LIVE555 Streaming Media" code that - I hope - fixes this bug. If the "Range:" header contains an end time, then (when serving a Transport Stream file) the server will recognize this, even for scales other than 1. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 17 08:40:01 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 17 Aug 2012 08:40:01 -0700 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> Message-ID: > I have run performance monitoring, again mentioned in an earlier post and I know pretty well that the ?OnDemandRTSPServer? is consuming about 7% of my CPU time when Idle (just ran the tests and the earlier figure I quoted was not accurate). > My hope was to reduce this to an absolute minimum by changing to a true event driven server. I don't understand this comment at all. The server *is* a "true event driven" server. All LIVE555 applications are event driven. It's difficult to see how a 'null' task running every 10 ms (which is also an event, BTW) could be consuming 7% of your CPU. However, if (and only if) you don't use any event triggers in your application, then I suggest that you - as an experiment - comment out the line schedulerTickTask(this); // ensures that we handle events frequently on line 46 of "BasicUsageEnvironment/BasicTaskScheduler.cpp", recompile, and check how this affects your server's CPU time. Please let me know. If - even after commenting out that line - your server still consumes CPU when idle, then you have a problem somewhere in your system. However, if your CPU time drops to zero when you comment out that line, then I'll add an (optional) parameter to "BasicTaskScheduler::createNew()" to allow you to disable the 'schedulerTickTask'. (Note, though, that you could use this only if you *don't* use event triggers at all.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Fri Aug 17 09:00:06 2012 From: warren at etr-usa.com (Warren Young) Date: Fri, 17 Aug 2012 10:00:06 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> Message-ID: <502E6A86.4050005@etr-usa.com> On 8/17/2012 9:17 AM, Sid Price wrote: > > My hope was to reduce this to an absolute > minimum by changing to a true event driven server. Is this WinCE or WinRT? WinCE has a lot of hacks in it w.r.t. sockets, in order to minimize kernel size. Basically, a lot of stuff is either unsupported or emulated in user space, as compared to Winsock on "real" Windows. I have no idea of the state of Winsock's capability on WinRT. I assume since it's newer and intended to support tablets and such that it's nearer to the full capabilities of "real" Windows, but again, I don't actually know that. > I am not sure how practical that is without changing Ross? basic code You wouldn't have to change any existing code. You'd write replacements for BasicUsageEnvironment and BasicTaskScheduler. sloccount on that sub-tree says there's only about a thousand lines of code there. I don't see that a rewrite using Windows' event mechanisms would be much bigger. From warren at etr-usa.com Fri Aug 17 09:02:24 2012 From: warren at etr-usa.com (Warren Young) Date: Fri, 17 Aug 2012 10:02:24 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> Message-ID: <502E6B10.7040200@etr-usa.com> On 8/17/2012 9:40 AM, Ross Finlayson wrote: >> My hope was to reduce this to an absolute minimum by changing to a >> true event driven server. > > I don't understand this comment at all. The server *is* a "true event > driven" server. All LIVE555 applications are event driven. He's referring to Windows events. WSAEventSelect() and such. http://msdn.microsoft.com/en-us/library/windows/desktop/ms741576.aspx From sidprice at softtools.com Fri Aug 17 09:12:22 2012 From: sidprice at softtools.com (Sid Price) Date: Fri, 17 Aug 2012 10:12:22 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> Message-ID: <002301cd7c93$167426c0$435c7440$@softtools.com> Ross, When I comment out the line you suggested the CPU utilization by the process does indeed go to 0%. Before you make changes I would like to know more about the use of your event triggers so that I can understand if I do need them or not. So, if you could spare a few minutes describing them I would much appreciate it. Many thanks, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, August 17, 2012 9:40 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Do the test applications ever sleep? I have run performance monitoring, again mentioned in an earlier post and I know pretty well that the "OnDemandRTSPServer" is consuming about 7% of my CPU time when Idle (just ran the tests and the earlier figure I quoted was not accurate). My hope was to reduce this to an absolute minimum by changing to a true event driven server. I don't understand this comment at all. The server *is* a "true event driven" server. All LIVE555 applications are event driven. It's difficult to see how a 'null' task running every 10 ms (which is also an event, BTW) could be consuming 7% of your CPU. However, if (and only if) you don't use any event triggers in your application, then I suggest that you - as an experiment - comment out the line schedulerTickTask(this); // ensures that we handle events frequently on line 46 of "BasicUsageEnvironment/BasicTaskScheduler.cpp", recompile, and check how this affects your server's CPU time. Please let me know. If - even after commenting out that line - your server still consumes CPU when idle, then you have a problem somewhere in your system. However, if your CPU time drops to zero when you comment out that line, then I'll add an (optional) parameter to "BasicTaskScheduler::createNew()" to allow you to disable the 'schedulerTickTask'. (Note, though, that you could use this only if you *don't* use event triggers at all.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 17 09:17:10 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 17 Aug 2012 09:17:10 -0700 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <502E6B10.7040200@etr-usa.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> <502E6B10.7040200@etr-usa.com> Message-ID: <312742A7-B587-4746-978C-7AC9E5FDCE26@live555.com> > He's referring to Windows events. WSAEventSelect() and such. OK, but he needs to remember that Microsoft did not invent the term "event" :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 17 11:51:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 17 Aug 2012 11:51:51 -0700 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <002301cd7c93$167426c0$435c7440$@softtools.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> <002301cd7c93$167426c0$435c7440$@softtools.com> Message-ID: <7302CFC6-0C8A-4804-B342-2C1AC35F06F3@live555.com> > When I comment out the line you suggested the CPU utilization by the process does indeed go to 0%. > > Before you make changes I would like to know more about the use of your event triggers so that I can understand if I do need them or not. So, if you could spare a few minutes describing them I would much appreciate it. Event triggers are described in "UsageEnvironment/include/UsageEnvironment.hh". They provide a way for an external thread (i.e., outside the LIVE555 event loop) to signal an event that the LIVE555 event loop thread can handle. That's why the LIVE555 event loop has to wake up on occasion - to check whether an external thread has triggered an event (using an 'event trigger). So the question here is: Will you server ever be signaled by an external thread - e.g., by a GUI? If not, then you won't need event triggers. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Fri Aug 17 14:34:18 2012 From: sidprice at softtools.com (Sid Price) Date: Fri, 17 Aug 2012 15:34:18 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <502E6B10.7040200@etr-usa.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> <502E6B10.7040200@etr-usa.com> Message-ID: <006001cd7cc0$0f549960$2dfdcc20$@softtools.com> No you are wrong! That is not what I meant by events. As an embedded programmer for more than 40 years I use the term events to mean any stimulus, internal or external to the current process that signals a requirement for the attention of that process. Sid. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Warren Young Sent: Friday, August 17, 2012 10:02 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Do the test applications ever sleep? On 8/17/2012 9:40 AM, Ross Finlayson wrote: >> My hope was to reduce this to an absolute minimum by changing to a >> true event driven server. > > I don't understand this comment at all. The server *is* a "true event > driven" server. All LIVE555 applications are event driven. He's referring to Windows events. WSAEventSelect() and such. http://msdn.microsoft.com/en-us/library/windows/desktop/ms741576.aspx _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From sidprice at softtools.com Fri Aug 17 14:41:50 2012 From: sidprice at softtools.com (Sid Price) Date: Fri, 17 Aug 2012 15:41:50 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <7302CFC6-0C8A-4804-B342-2C1AC35F06F3@live555.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> <002301cd7c93$167426c0$435c7440$@softtools.com> <7302CFC6-0C8A-4804-B342-2C1AC35F06F3@live555.com> Message-ID: <006101cd7cc1$1ca09230$55e1b690$@softtools.com> Aha! Thanks Ross that is clear. My application does not require any external stimuli to cause actions within the server. It has no UI. If external stimuli were needed I would hope to be able to subclass "BasicUsageEnvironment" to achieve this without the need for periodic running of the task scheduler, but at this point I don't see a need for that. I will be doing some more testing on this with this new knowledge in mind. Many thanks for valuable help, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, August 17, 2012 12:52 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Do the test applications ever sleep? When I comment out the line you suggested the CPU utilization by the process does indeed go to 0%. Before you make changes I would like to know more about the use of your event triggers so that I can understand if I do need them or not. So, if you could spare a few minutes describing them I would much appreciate it. Event triggers are described in "UsageEnvironment/include/UsageEnvironment.hh". They provide a way for an external thread (i.e., outside the LIVE555 event loop) to signal an event that the LIVE555 event loop thread can handle. That's why the LIVE555 event loop has to wake up on occasion - to check whether an external thread has triggered an event (using an 'event trigger). So the question here is: Will you server ever be signaled by an external thread - e.g., by a GUI? If not, then you won't need event triggers. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 20 00:44:05 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Aug 2012 00:44:05 -0700 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <006101cd7cc1$1ca09230$55e1b690$@softtools.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> <002301cd7c93$167426c0$435c7440$@softtools.com> <7302CFC6-0C8A-4804-B342-2C1AC35F06F3@live555.com> <006101cd7cc1$1ca09230$55e1b690$@softtools.com> Message-ID: FYI, I've now installed a new version (2012.08.20) of the "LIVE555 Streaming Media" code that updates the "BasicTaskScheduler" class to add an optional "maxSchedulerGranularity" parameter to "BasicTaskScheduler::createNew()". (The default value is the same as before: 10000 - i.e., 10 ms.) If you know that you won't be using 'event triggers' at all, you can specify a special value of 0 - i.e., create your scheduler object by calling: BasicTaskScheduler::createNew(0); If you do this, then the scheduler will remain blocked in "select()" until a socket event or delayed task occurs. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 20 00:50:44 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Aug 2012 00:50:44 -0700 Subject: [Live-devel] RTSP - Absolute Time In-Reply-To: References: Message-ID: > After doing some testing with openRTSP and looking through the code it appears like "Absolute Time" is currently not supported for RTSP streams. I.e. I can't specify a specific time that the stream should seek to, e.g. Range: clock=20120629T070000.00Z, all according to paragraph 3.7 at http://www.ietf.org/rfc/rfc2326.txt. FYI, the latest version (2012.08.20) of the "LIVE555 Streaming Media" code adds optional RTSP server and RTSP client support for streams that are indexed by 'absolute' time - i.e., using strings of the form "YYYYMMDDTHHMMSSZ" or "YYYYMMDDTHHMMSS.Z". For RTSP server developers (i.e., developers who have their own subclasses of "OnDemandServerMediaSubsession"): - To automatically have your streams advertised (in their SDP description) as supporting absolute time indexing, reimplement (in your subclass) the virtual function: "virtual void getAbsoluteTimeRange(char*& absStartTime, char*& absEndTime) const;" (see "liveMedia/include/ServerMediaSession.hh"). This function should set "absStartTime" to a string value (of the form noted above), and should set "absEndTime" to a corresponding string value, if the stream has an end time, otherwise NULL. - To implement seeking by absolute time, reimplement (in your subclass) the virtual function: "virtual void seekStreamSource(FramedSource* inputSource, char*& absStart, char*& absEnd);" (see "liveMedia/include/OnDemandServerMediaSubsession.hh"). "absStart" (and "absEnd", if non-NULL) are strings (of the form noted above). (The function *may* change them, to make them more accurate.) For RTSP client developers: - To check whether a stream supports indexing by absolute time, call "MediaSession::absStartTime()" or "MediaSubsession::absStartTime()", and check whether this (string) value is non-NULL. - To play a stream, indexed by absolute time, call one of the new, alternative forms of "RTSPClient::sendPlayCommand()" that take "absStartTime" (and optional "absEndTime") strings as parameters. (see "liveMedia/include/RTSPClient.hh") Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorpha at gmail.com Sun Aug 19 20:18:44 2012 From: jorpha at gmail.com (=?GB2312?B?0O2zpLeo?=) Date: Mon, 20 Aug 2012 11:18:44 +0800 Subject: [Live-devel] rtp over rtsp error In-Reply-To: <638477D2-F685-4D87-8DC3-C74E3119B1C0@live555.com> References: <029943B7-E750-4F7A-BCA1-36E1EE137DF2@live555.com> <638477D2-F685-4D87-8DC3-C74E3119B1C0@live555.com> Message-ID: hi, i open VLC's debug message and get below log from VCL: packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS packetizer_h264 warning: waiting for SPS/PPS main warning: buffer way too late (206500), dropping buffer main warning: PTS is out of range (121096556), dropping buffer main warning: PTS is out of range (121037464), dropping buffer main warning: PTS is out of range (120976991), dropping buffer main warning: PTS is out of range (120894893), dropping buffer Then i get the static picture from ip camera, someone tell me how to solve this issue ? 2012/8/16 Ross Finlayson > I guess my issue is caused by the same reason with you. > RTCP "RR" is sent in OnExpire in rtcp_from_spec.c schedulely. > But why server still close after about 5s ? > > > I don't know. Before, you said that the server closed "after a few > minutes". Now, you say that the server closes "after 5s". > > I suggest that you add > > #define DEBUG 1 > > to the start of "liveMedia/RTSPServer.cpp", and then recompile. This will > display a lot more information about what's happening with your server. > > (Be sure, of course, to use the latest version of the server code; the > only version we support.) > > 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 > > -- Best Regards! Jorpha -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Mon Aug 20 07:13:03 2012 From: sidprice at softtools.com (Sid Price) Date: Mon, 20 Aug 2012 08:13:03 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> <002301cd7c93$167426c0$435c7440$@softtools.com> <7302CFC6-0C8A-4804-B342-2C1AC35F06F3@live555.com> <006101cd7cc1$1ca09230$55e1b690$@softtools.com> Message-ID: <01eb01cd7edd$eabefdf0$c03cf9d0$@softtools.com> Thank you very much Ross, your ongoing support is much appreciated, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, August 20, 2012 1:44 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Do the test applications ever sleep? FYI, I've now installed a new version (2012.08.20) of the "LIVE555 Streaming Media" code that updates the "BasicTaskScheduler" class to add an optional "maxSchedulerGranularity" parameter to "BasicTaskScheduler::createNew()". (The default value is the same as before: 10000 - i.e., 10 ms.) If you know that you won't be using 'event triggers' at all, you can specify a special value of 0 - i.e., create your scheduler object by calling: BasicTaskScheduler::createNew(0); If you do this, then the scheduler will remain blocked in "select()" until a socket event or delayed task occurs. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Mon Aug 20 15:09:45 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Mon, 20 Aug 2012 22:09:45 +0000 Subject: [Live-devel] RTSP - Absolute Time In-Reply-To: References: Message-ID: FYI, the latest version (2012.08.20) of the "LIVE555 Streaming Media" code adds optional RTSP server and RTSP client support for streams that are indexed by 'absolute' time - i.e., using strings of the form "YYYYMMDDTHHMMSSZ" or "YYYYMMDDTHHMMSS.Z". Ross Finlayson Ross, Thank you very much for getting this implemented! I've been playing around with it a bit today, and will continue to test. I'm using Cisco Video Surveillance Media Server, and liveMedia for the client. I've experienced some issues today that I haven't really seen before, but I'm fairly sure liveMedia is not to blame. Still thought I could mention it in case someone else is playing around with absolute seeking too. - Seeking using absolute time takes 5-15s. - The absolute timestamp I ask for doesn't match what I receive, Many hours off, but at least it's consistent. The functionality works ok when using the Cisco Active X control, but I get the exact same issue when sending RTSP commands manually via a telnet client (which is expected, just confirming liveMedia doesn't introduce anything). At one time the Cisco server suddenly refused to accept new connections (from any computer); something I've never seen before. Worked ok after a reboot. Will investigate more and maybe create new archive files on the server... Thanks again! /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: 5740 bytes Desc: not available URL: From finlayson at live555.com Mon Aug 20 15:22:45 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Aug 2012 15:22:45 -0700 Subject: [Live-devel] RTSP - Absolute Time In-Reply-To: References: Message-ID: <59C902E2-B242-4A92-B9F3-707F1CEFD1A1@live555.com> > The functionality works ok when using the Cisco Active X control, but I get the exact same issue when sending RTSP commands manually via a telnet client (which is expected, just confirming liveMedia doesn't introduce anything). OK, so it should be easy to figure out what RTSP commands the "Cisco Active X control" is sending, and how this differs from what a LIVE555-based RTSP client is sending. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From TWiser at logostech.net Mon Aug 20 15:34:22 2012 From: TWiser at logostech.net (Wiser, Tyson) Date: Mon, 20 Aug 2012 15:34:22 -0700 Subject: [Live-devel] RTSP - Absolute Time In-Reply-To: References: Message-ID: <8CD7A9204779214D9FDC255DE48B9521013B5C3ECA@EXPMBX105-1.exch.logostech.net> - The absolute timestamp I ask for doesn't match what I receive, Many hours off, but at least it's consistent. For what it's worth, this sounds like it could potentially be a time zone issue. I've run into issues in the past where some of the routines I used interpreted my UTC timestamp as a timestamp in the local time zone (or vice versa), thus adding or subtracting a fixed number of hours. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 20 15:45:49 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Aug 2012 15:45:49 -0700 Subject: [Live-devel] RTSP - Absolute Time In-Reply-To: <8CD7A9204779214D9FDC255DE48B9521013B5C3ECA@EXPMBX105-1.exch.logostech.net> References: <8CD7A9204779214D9FDC255DE48B9521013B5C3ECA@EXPMBX105-1.exch.logostech.net> Message-ID: <43DDE729-13C1-47A0-8573-843E82FA714B@live555.com> > - The absolute timestamp I ask for doesn't match what I receive, Many hours off, but at least it's consistent. > > For what it?s worth, this sounds like it could potentially be a time zone issue. I?ve run into issues in the past where some of the routines I used interpreted my UTC timestamp as a timestamp in the local time zone (or vice versa), thus adding or subtracting a fixed number of hours. Note that according to the RTSP specification (RFC 2326, section 3.7) 'absolute' time - in both RTSP requests and RTSP responses - must be expressed as a UTC time - i.e., using a string of the form "YYYYMMDDTHHMMSSZ" or "YYYYMMDDTHHMMSS.Z". (Note the "Z" at the end.) But how a 3rd-party server interprets such strings is anyone's guess... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhwei409 at gmail.com Mon Aug 20 08:43:07 2012 From: zhwei409 at gmail.com (Victor Wei) Date: Mon, 20 Aug 2012 23:43:07 +0800 Subject: [Live-devel] build rtsp server supports TCP and Multicast from 264encoder at the same time Message-ID: Dear experts, I have read some of the FAQs and mail list. Thank you for your effort. Now the live555 server can stream out from encoder with unicast udp/tcp or multicast respectively. But my problem is that how to build rtsp server supports TCP and Mulitcast at the same. I refer to the mail list above, create two stream name, but it seems to be difficulty when the source is encoder, not the file. Thank you in advanced. --------------------------------------------------------------------------------------- > When TCP/UDP mode, the subsession needs to inherit from >class OnDemandServerMediaSubsession. > When multicast mode, it needs to inherit from >PassiveServerMediaSubsession. > How can I make a path support both mode in the same time?? It is the server - not the client - that decides whether a stream is sent via unicast or multicast. Therefore it makes no sense to use the same stream (path) name for both kinds of streaming. Instead, the only way that a client can request unicast or multicast streaming is to use a different stream name for each, and have the server use the stream name to determine which type of streaming is desired. This is what we support. -- --------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 20 16:27:09 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Aug 2012 16:27:09 -0700 Subject: [Live-devel] build rtsp server supports TCP and Multicast from 264encoder at the same time In-Reply-To: References: Message-ID: <2389844E-5CC6-4807-AF5D-F1888F4276CF@live555.com> > Now the live555 server can stream out from encoder with unicast udp/tcp or multicast respectively. > > But my problem is that how to build rtsp server supports TCP and Mulitcast at the same. I presume you mean that you want some clients to receive a RTP-over-TCP stream, and other clients to access a separate multicast stream (because, of course, a multicast stream cannot be sent via TCP). To do this, you add - to your RTSP server - two *separate* "ServerMediaSession" objects, each with a different "streamName". (E.g., you could give one of them the streamName "multicastStream", and could give the other one the streamName "unicastStream".) Then, you would add a "PassiveServerMediaSubsession" object to the "multicastStream" object, and would add a "OnDemandServerMediaSubsession" (subclass) object to the "unicastStream" object. Now, the only remaining issue is that you may want the same H.264 video source (e.g., from an encoder) to be used by both kinds of stream. To do this, you may need to replicate the stream using our "StreamReplicator" class. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Mon Aug 20 17:04:22 2012 From: sidprice at softtools.com (Sid Price) Date: Mon, 20 Aug 2012 18:04:22 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> <002301cd7c93$167426c0$435c7440$@softtools.com> <7302CFC6-0C8A-4804-B342-2C1AC35F06F3@live555.com> <006101cd7cc1$1ca09230$55e1b690$@softtools.com> Message-ID: <02b601cd7f30$85d10c00$91732400$@softtools.com> Ross, I have built to new code and run into an issue with my test WAV file no longer playing. Your new WAV parser is rejecting the WAV file because of the audio format entry which is 0x0012 which is said to be "Videologic Mediaspace ADPCM". I am not terribly familiar with codecs so do you know if there is a tool available that would allow me to reformat the WAV file? I was having some playback issues before so this may be the reason. Thanks, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, August 20, 2012 1:44 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Do the test applications ever sleep? FYI, I've now installed a new version (2012.08.20) of the "LIVE555 Streaming Media" code that updates the "BasicTaskScheduler" class to add an optional "maxSchedulerGranularity" parameter to "BasicTaskScheduler::createNew()". (The default value is the same as before: 10000 - i.e., 10 ms.) If you know that you won't be using 'event triggers' at all, you can specify a special value of 0 - i.e., create your scheduler object by calling: BasicTaskScheduler::createNew(0); If you do this, then the scheduler will remain blocked in "select()" until a socket event or delayed task occurs. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 20 17:50:11 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Aug 2012 17:50:11 -0700 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <02b601cd7f30$85d10c00$91732400$@softtools.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> <002301cd7c93$167426c0$435c7440$@softtools.com> <7302CFC6-0C8A-4804-B342-2C1AC35F06F3@live555.com> <006101cd7cc1$1ca09230$55e1b690$@softtools.com> <02b601cd7f30$85d10c00$91732400$@softtools.com> Message-ID: > I have built to new code and run into an issue with my test WAV file no longer playing. Your new WAV parser is rejecting the WAV file because of the audio format entry which is 0x0012 which is said to be ?Videologic Mediaspace ADPCM?. We have never been able to stream WAV files that use this format, so I don't know why you thought that this was working before. (If you look at "WAVAudioFileServerMediaSubsession.cpp", you'll see that we do not handle (and have never handled) WAV format code 0x12.) It would not be possible to stream "Videologic Mediaspace ADPCM" audio unless/until we see a definition of the RTP payload format for this audio format. (We can stream "IMA ADPCM" audio OK, because this is the same as DVI4 audio, for which a payload format is defined. But, assuming that "Videologic Mediaspace ADPCM" audio is different (because it if weren't different, then why would it use a different WAV format code?), then the RTP payload format - at least, the codec name string - has to be different.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Mon Aug 20 19:27:31 2012 From: sidprice at softtools.com (Sid Price) Date: Mon, 20 Aug 2012 20:27:31 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> <002301cd7c93$167426c0$435c7440$@softtools.com> <7302CFC6-0C8A-4804-B342-2C1AC35F06F3@live555.com> <006101cd7cc1$1ca09230$55e1b690$@softtools.com> <02b601cd7f30$85d10c00$91732400$@softtools.com> Message-ID: <02d001cd7f44$8514f7e0$8f3ee7a0$@softtools.com> Ross, I completely understand. As I asked, do you know of a tool I could use to convert the test files I have been supplied with to plain PCM (format 1). This is part of a proof on concept so I do not have to play the WAV files as they are. They can be re-encoded. Thanks, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, August 20, 2012 6:50 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Do the test applications ever sleep? I have built to new code and run into an issue with my test WAV file no longer playing. Your new WAV parser is rejecting the WAV file because of the audio format entry which is 0x0012 which is said to be "Videologic Mediaspace ADPCM". We have never been able to stream WAV files that use this format, so I don't know why you thought that this was working before. (If you look at "WAVAudioFileServerMediaSubsession.cpp", you'll see that we do not handle (and have never handled) WAV format code 0x12.) It would not be possible to stream "Videologic Mediaspace ADPCM" audio unless/until we see a definition of the RTP payload format for this audio format. (We can stream "IMA ADPCM" audio OK, because this is the same as DVI4 audio, for which a payload format is defined. But, assuming that "Videologic Mediaspace ADPCM" audio is different (because it if weren't different, then why would it use a different WAV format code?), then the RTP payload format - at least, the codec name string - has to be different.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Mon Aug 20 21:43:25 2012 From: warren at etr-usa.com (Warren Young) Date: Mon, 20 Aug 2012 22:43:25 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: <02d001cd7f44$8514f7e0$8f3ee7a0$@softtools.com> References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> <002301cd7c93$167426c0$435c7440$@softtools.com> <7302CFC6-0C8A-4804-B342-2C1AC35F06F3@live555.com> <006101cd7cc1$1ca09230$55e1b690$@softtools.com> <02b601cd7f30$85d10c00$91732400$@softtools.com> <02d001cd7f44$8514f7e0$8f3ee7a0$@softtools.com> Message-ID: <503311ED.7050904@etr-usa.com> On 8/20/2012 8:27 PM, Sid Price wrote: > > As I asked, do you know of a tool I could use > to convert the test files I have been supplied with to plain PCM Try http://sox.sf.net/ I don't see your format on the codec page[*] but it's too easy not to just try it. If you don't have it installed, it's probably available through your OS's package system already. Please be aware that you've already stepped outside the list's topic. If you can't make sox do what you want, this isn't the list to pursue the topic still further. [*] http://sox.sf.net/Docs/Features From sidprice at softtools.com Tue Aug 21 10:39:47 2012 From: sidprice at softtools.com (Sid Price) Date: Tue, 21 Aug 2012 11:39:47 -0600 Subject: [Live-devel] Do the test applications ever sleep? In-Reply-To: References: <003f01cd7be9$948939b0$bd9bad10$@softtools.com> <007301cd7bf4$65f14600$31d3d200$@softtools.com> <000b01cd7c8b$77f81da0$67e858e0$@softtools.com> <002301cd7c93$167426c0$435c7440$@softtools.com> <7302CFC6-0C8A-4804-B342-2C1AC35F06F3@live555.com> <006101cd7cc1$1ca09230$55e1b690$@softtools.com> <02b601cd7f30$85d10c00$91732400$@softtools.com> Message-ID: <003d01cd7fc3$f6466050$e2d320f0$@softtools.com> Hi Ross, Just an FYI for you, I encoded the WAV files for audio format of "PCM" (no codec) and the server now plays them out. Also, I tested the new feature "maxSchedulerGranularity" and it also appears to be working. Many thanks I much appreciate your patience, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, August 20, 2012 6:50 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Do the test applications ever sleep? I have built to new code and run into an issue with my test WAV file no longer playing. Your new WAV parser is rejecting the WAV file because of the audio format entry which is 0x0012 which is said to be "Videologic Mediaspace ADPCM". We have never been able to stream WAV files that use this format, so I don't know why you thought that this was working before. (If you look at "WAVAudioFileServerMediaSubsession.cpp", you'll see that we do not handle (and have never handled) WAV format code 0x12.) It would not be possible to stream "Videologic Mediaspace ADPCM" audio unless/until we see a definition of the RTP payload format for this audio format. (We can stream "IMA ADPCM" audio OK, because this is the same as DVI4 audio, for which a payload format is defined. But, assuming that "Videologic Mediaspace ADPCM" audio is different (because it if weren't different, then why would it use a different WAV format code?), then the RTP payload format - at least, the codec name string - has to be different.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Tue Aug 21 11:19:01 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Tue, 21 Aug 2012 18:19:01 +0000 Subject: [Live-devel] RTSP - Absolute Time In-Reply-To: <43DDE729-13C1-47A0-8573-843E82FA714B@live555.com> References: <8CD7A9204779214D9FDC255DE48B9521013B5C3ECA@EXPMBX105-1.exch.logostech.net> <43DDE729-13C1-47A0-8573-843E82FA714B@live555.com> Message-ID: - The absolute timestamp I ask for doesn't match what I receive, Many hours off, but at least it's consistent. For what it's worth, this sounds like it could potentially be a time zone issue. I've run into issues in the past where some of the routines I used interpreted my UTC timestamp as a timestamp in the local time zone (or vice versa), thus adding or subtracting a fixed number of hours. Note that according to the RTSP specification (RFC 2326, section 3.7) 'absolute' time - in both RTSP requests and RTSP responses - must be expressed as a UTC time - i.e., using a string of the form "YYYYMMDDTHHMMSSZ" or "YYYYMMDDTHHMMSS.Z". (Note the "Z" at the end.) Thanks to everyone for your response. A new day and another restart of the server and everything appears to work fine. I think I might have messed up the UTC conversion yesterday, as I did it manually, but it was also confusing as it was not always whole hours off, which potentially could have been due to incomplete archives (for unknown reasons). Well, today it appears to work fine and even the delay is gone. No idea what that was about, but it must have been something on the server. I've re-created a few of the archives and will continue to test more. Thanks! /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: 5740 bytes Desc: not available URL: From gunslingor at gmail.com Tue Aug 21 13:58:21 2012 From: gunslingor at gmail.com (WADE POLK) Date: Tue, 21 Aug 2012 16:58:21 -0400 Subject: [Live-devel] Fwd: live555 on demand, apache and win 7 64bit In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: WADE POLK Date: Tue, Aug 21, 2012 at 4:45 PM Subject: live555 on demand, apache and win 7 64bit To: live-devel at lists.live555.com Hi all, I have good web page setup, the only thing lacking is the streaming server and I've been scouring the internet for many weeks studying and looking for the best possible solution. I'm using the latest version of WAMP server on win 7 64 bit. A few questions: 1. is there a way to get live555 to work in 64 bit windows? 2. Can it handle "true" rtsp on demand streaming effectively? I think it can from what I am reading in the documentation. 3. Assuming I get live555 up and running on the same server that runs apache, how the heck do I get my webpage to communicate with the streaming server? Its a console application right? There needs to be a way to integrate on demand streaming with my existing page. What gets played to who will be dictated by what hyperlinks my users press on the webpage, some hyper links need to open streams of my radio station, others need to open streams of a users playlist, and some of just a single file... who has access to what is dictated by my sql database. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From tayeb at tmxvoip.com Tue Aug 21 14:57:28 2012 From: tayeb at tmxvoip.com (Meftah Tayeb) Date: Wed, 22 Aug 2012 00:57:28 +0300 Subject: [Live-devel] Fwd: live555 on demand, apache and win 7 64bit References: Message-ID: <9F0D40F348AC4527B362DFEE28E3AF84@work> ----- Original Message ----- From: "WADE POLK" To: Sent: Tuesday, August 21, 2012 11:58 PM Subject: [Live-devel] Fwd: live555 on demand, apache and win 7 64bit > ---------- Forwarded message ---------- > From: WADE POLK > Date: Tue, Aug 21, 2012 at 4:45 PM > Subject: live555 on demand, apache and win 7 64bit > To: live-devel at lists.live555.com > > > Hi all, > > I have good web page setup, the only thing lacking is the streaming server > and I've been scouring the internet for many weeks studying and looking > for > the best possible solution. I'm using the latest version of WAMP server on > win 7 64 bit. A few questions: there is Live555 On-demand streaming RTSP server. > > 1. is there a way to get live555 to work in 64 bit windows? i think yes, just need to generate the apropriate makefile. please see the FAQS > > 2. Can it handle "true" rtsp on demand streaming effectively? I think it > can from what I am reading in the documentation. yes, the best in the Open source world. > > 3. Assuming I get live555 up and running on the same server that runs > apache, how the heck do I get my webpage to communicate with the streaming > server? Its a console application right? There needs to be a way to > integrate on demand streaming with my existing page. What gets played to > who will be dictated by what hyperlinks my users press on the webpage, > some > hyper links need to open streams of my radio station, others need to open > streams of a users playlist, and some of just a single file... who has > access to what is dictated by my sql database. that depand, you should chouse if you play it in the web page itself or open it in a media player if you decide to play it on the web you should use a flash or a java app that support rtsp, and i'm not sure if there's one. > > thanks no problem > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7404 (20120821) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > -------------------------------------------------------------------------------- > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7404 (20120821) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From Marlon at scansoft.co.za Wed Aug 22 07:24:29 2012 From: Marlon at scansoft.co.za (Marlon Reid) Date: Wed, 22 Aug 2012 16:24:29 +0200 Subject: [Live-devel] Using RTSP to copy files Message-ID: <002962EA5927BE45B2FFAB0B5B5D67970A8F94@SSTSVR1.sst.local> Hi everyone, We are thinking of using RTSP streaming in a way that can be considered untraditional (at least according to me) and I was wondering if it will be possible using Live555. Lets assume that we have an mp3 file of 1 minute duration on the machine with the RTSP server, and we want to copy the file to machine B which will have an RTSP client. We are able to stream the mp3 file, but it takes 1 minute (the duration of the file) to get the data from A to B. Would it be possible to stream the file as quickly as possible to the other machine in order to 'copy' the file in much less time than the 1 minute duration of the file? If it is possible, I assume that one will need to create something like a CopyFile media source, and just set fFrameSize to a nice big number. Will presentationTime matter in a scenario like this? And is there a limit to fFrameSize? Any ideas or suggestions will be appreciated. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marlon at scansoft.co.za Wed Aug 22 07:47:17 2012 From: Marlon at scansoft.co.za (Marlon Reid) Date: Wed, 22 Aug 2012 16:47:17 +0200 Subject: [Live-devel] Using RTSP to copy files In-Reply-To: <002962EA5927BE45B2FFAB0B5B5D67970A8F94@SSTSVR1.sst.local> References: <002962EA5927BE45B2FFAB0B5B5D67970A8F94@SSTSVR1.sst.local> Message-ID: <002962EA5927BE45B2FFAB0B5B5D67970A8F95@SSTSVR1.sst.local> I believe that the solution will be to create a custom file source and set fDurationInMicroseconds to zero. If I am correct, the client will than request packets as quickly as it can. I will test this later today. Regards. ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Marlon Reid Sent: 22 August 2012 04:24 PM To: LIVE555 Streaming Media - development & use Subject: [Live-devel] Using RTSP to copy files Hi everyone, We are thinking of using RTSP streaming in a way that can be considered untraditional (at least according to me) and I was wondering if it will be possible using Live555. Lets assume that we have an mp3 file of 1 minute duration on the machine with the RTSP server, and we want to copy the file to machine B which will have an RTSP client. We are able to stream the mp3 file, but it takes 1 minute (the duration of the file) to get the data from A to B. Would it be possible to stream the file as quickly as possible to the other machine in order to 'copy' the file in much less time than the 1 minute duration of the file? If it is possible, I assume that one will need to create something like a CopyFile media source, and just set fFrameSize to a nice big number. Will presentationTime matter in a scenario like this? And is there a limit to fFrameSize? Any ideas or suggestions will be appreciated. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Aug 22 09:14:43 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 22 Aug 2012 09:14:43 -0700 Subject: [Live-devel] Using RTSP to copy files In-Reply-To: <002962EA5927BE45B2FFAB0B5B5D67970A8F95@SSTSVR1.sst.local> References: <002962EA5927BE45B2FFAB0B5B5D67970A8F94@SSTSVR1.sst.local> <002962EA5927BE45B2FFAB0B5B5D67970A8F95@SSTSVR1.sst.local> Message-ID: <231CC170-BFF1-4A89-AD41-EE774EDBBC72@live555.com> > I believe that the solution will be to create a custom file source and set fDurationInMicroseconds to zero. Yes, that would work. However, because this will cause packets to get sent as quickly as possible (which is what you say you want), then you need to worry about packet loss. Even if you stream RTP-over-TCP, if you try to stream faster than your underlying network will support, then you will also get data loss (at the sender end, when the sender overflows the OS's buffer for the socket). That's why what you are suggesting is extremely silly. Instead, because you want to do file transfer, then you should just use a file transfer utility - e.g., "scp". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Wed Aug 22 04:03:52 2012 From: jshanab at smartwire.com (Jeff Shanab) Date: Wed, 22 Aug 2012 11:03:52 +0000 Subject: [Live-devel] Fwd: live555 on demand, apache and win 7 64bit In-Reply-To: References: , Message-ID: <615FD77639372542BF647F5EBAA2DBC22520EFAF@IL-BOL-EXCH01.smartwire.com> RTSP is a protocol, so is HTTP, you need a plugin. Browsers natively handle HTTP but they do not yet directly support RTSP, it requires a plug-in. Players like VLC, Quicktime and Flash can handle RTSP and usually have a plugin avail, indeed flash is the most common defacto plugin out there. I personally am on a team responsible for our own plugin and it uses livee555 as the client together with libavcodec for the decoding part. 1)Running on 64 bit windows: most apps running on windows 64 bit are still running 32bit. Windows provided a set of emulation libraries called "Windows on Windows" that seemlessly handles running 32 bit code on 64 bit windows. This still is a big step forward because each 32 bit app runs with an up to 2Gig memory space so it allows you to use all that extra memory (my boxes have 4G - 12G). You can aso compile for 64 bit, but in for a penny, in for a pound; check and make sure the browser or rest of your app is also compiled for 64bit! 2)True RTSP: I connect directly to various RTSP sources directly from the browser. From commercial restreamers to embedded devices. I have seen at least 10 differnt brands work fine and 2 that will not connect for a yet unknown reason, but I need to update. 3) see description in 1 of who's responsibility for what protocols and how it is used. RTSP will be listening by default on port 554, apache by default is port 80. These are defined as default by the protocol and apache's job ends at telling other software the address and specs of the connection string. Remember, data obtained from RTSP is encoded (compressed) the other main part of any client is to decode it. Some browser can handle decodeing directly if you use HTTP Live Streaming. Which apache can serve out and live555 can do part of the transformation, but it is a missnomer that it is live, it has a built in delay. WIkipedia is your friend on all this. ________________________________ From: live-devel-bounces at ns.live555.com [live-devel-bounces at ns.live555.com] on behalf of WADE POLK [gunslingor at gmail.com] Sent: Tuesday, August 21, 2012 3:58 PM To: live-devel at ns.live555.com Subject: [Live-devel] Fwd: live555 on demand, apache and win 7 64bit ---------- Forwarded message ---------- From: WADE POLK > Date: Tue, Aug 21, 2012 at 4:45 PM Subject: live555 on demand, apache and win 7 64bit To: live-devel at lists.live555.com Hi all, I have good web page setup, the only thing lacking is the streaming server and I've been scouring the internet for many weeks studying and looking for the best possible solution. I'm using the latest version of WAMP server on win 7 64 bit. A few questions: 1. is there a way to get live555 to work in 64 bit windows? 2. Can it handle "true" rtsp on demand streaming effectively? I think it can from what I am reading in the documentation. 3. Assuming I get live555 up and running on the same server that runs apache, how the heck do I get my webpage to communicate with the streaming server? Its a console application right? There needs to be a way to integrate on demand streaming with my existing page. What gets played to who will be dictated by what hyperlinks my users press on the webpage, some hyper links need to open streams of my radio station, others need to open streams of a users playlist, and some of just a single file... who has access to what is dictated by my sql database. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhg84 at gmail.com Wed Aug 22 03:39:19 2012 From: saurabhg84 at gmail.com (Saurabh Gandhi) Date: Wed, 22 Aug 2012 16:09:19 +0530 Subject: [Live-devel] Behavior of OpenRTSP during non-availability of RTSP stream Message-ID: Hello everyone, I am using openRTSP for recording video clips of 5 seconds duration. I am doing this continuously, so my code looks like this: while(1) { // some code to generate a unique file-name for video clip based on date and time system("openrtsp.exe -4 -b 100000 -d 5 -w 640 -h 480 -f 30 -N "); } This seems to be working fine. I can see video clips getting generated of 5 seconds duration. However, when the IP camera stops giving an RTSP stream for a prolonged duration (2-3 hours) there are no video clips generated. That behavior is obvious, but what bothers me is that even when the IP camera recovers and starts giving an RTSP stream the openrtsp.exe just hangs. Then when I go to task manager and kill this process "openrtsp.exe", the application seems to recover and I can see new video clips being generated. Could someone explain this behavior and how it can be resolved? -- Regards, Saurabh Gandhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From spheretesting at gmail.com Wed Aug 22 12:50:48 2012 From: spheretesting at gmail.com (Jennifer Sphere) Date: Wed, 22 Aug 2012 12:50:48 -0700 Subject: [Live-devel] using live555 on iOS device Message-ID: Is it possible to have a streaming server on one iOS device and a RTP client on another using the live555 libraries? Thanks! -Jen -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Wed Aug 22 18:53:03 2012 From: kingaceck at 163.com (kingaceck) Date: Thu, 23 Aug 2012 09:53:03 +0800 Subject: [Live-devel] A Problem of proxy server Message-ID: <201208230953026715635@163.com> Dear live dev team: (1) When I use proxy server,I get the flow message RTCPInstance::RTCPInstance error: totSessionBW parameter should not be zero! (2)If the back-end RTSP/RTP stream server restarted,Should I need to restart the proxy server? Please help me,Thank you very much! ------------------------------------------------------------ root at ck-laptop:/diske/myc/live555/live555/proxyServer# ./live555ProxyServer rtsp://129.1.5.155:8554/test LIVE555 Proxy Server (LIVE555 Streaming Media library version 2012.05.17) RTSP stream, proxying the stream "rtsp://129.1.5.155:8554/test" Play this stream using the URL "rtsp://129.1.5.156/proxyStream" (We use port 80 for optional RTSP-over-HTTP tunneling.) RTCPInstance::RTCPInstance error: totSessionBW parameter should not be zero! 2012-08-23 kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrixshopping at yahoo.com Wed Aug 22 19:00:50 2012 From: matrixshopping at yahoo.com (matrixshopping at yahoo.com) Date: Thu, 23 Aug 2012 02:00:50 +0000 Subject: [Live-devel] Using RTSP to copy files In-Reply-To: <002962EA5927BE45B2FFAB0B5B5D67970A8F94@SSTSVR1.sst.local> References: <002962EA5927BE45B2FFAB0B5B5D67970A8F94@SSTSVR1.sst.local> Message-ID: <1462653149-1345689129-cardhu_decombobulator_blackberry.rim.net-2135837416-@b28.c12.bise6.blackberry> I want to know how do I stream live from my lab top so someone on a blackberry can see me using rtsp Sent from my BlackBerry? device from Digicel -----Original Message----- From: "Marlon Reid" Sender: live-devel-bounces at ns.live555.com Date: Wed, 22 Aug 2012 16:24:29 To: LIVE555 Streaming Media - development & use Reply-To: LIVE555 Streaming Media - development & use Subject: [Live-devel] Using RTSP to copy files _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Wed Aug 22 23:59:48 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 22 Aug 2012 23:59:48 -0700 Subject: [Live-devel] A Problem of proxy server In-Reply-To: <201208230953026715635@163.com> References: <201208230953026715635@163.com> Message-ID: <3CB694A3-2541-41B4-B077-857EC22525B2@live555.com> > When I use proxy server,I get the flow message > > RTCPInstance::RTCPInstance error: totSessionBW parameter should not be zero! You're using an out-of-date (at least 2 months old!) version of the code. Please upgrade! (Everyone should check that they are using the latest version of the code before asking about problems.) > > (2)If the back-end RTSP/RTP stream server restarted,Should I need to restart the proxy server? No (although it can take up to 1 minute for the proxy server to restore the connection after the back-end server is restarted). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago777 at gmail.com Thu Aug 23 00:01:12 2012 From: thiago777 at gmail.com (Thiago Alencar) Date: Thu, 23 Aug 2012 09:01:12 +0200 Subject: [Live-devel] using live555 on iOS device In-Reply-To: References: Message-ID: <4083D184-7A9A-4C03-B298-EB939CDE946C@gmail.com> Hi I know some people managed to get the client running on iOS. But I haven't done this myself and couldn't get any help either (I also want / need this).. BR, Thiago On Aug 22, 2012, at 9:50 PM, Jennifer Sphere wrote: > Is it possible to have a streaming server on one iOS device and a RTP client on another using the live555 libraries? > > Thanks! > > -Jen > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From michel.promonet at thalesgroup.com Thu Aug 23 01:11:28 2012 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 23 Aug 2012 10:11:28 +0200 Subject: [Live-devel] openRTSP and seek using TimeZulu Message-ID: <20770_1345709530_5035E5DA_20770_3543_1_1BE8971B6CFF3A4F97AF4011882AA25501560059E75E@THSONEA01CMS01P.one.grp> Hi Ross, Thanks for the evolution in release 20120820 that support seeking using TimeZulu encoding (alias ISO 8601). It allow us to drop an ugly workaround that path the RTSP header on the fly between the overloaded PLAY and the live555 implemetation. Do you think it could be helpful to add in openRTSP such a feature ? I attached a rough implementation that I used to test the feature. Best Regards, Michel. [@@THALES GROUP RESTRICTED@@] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openRTSP.cpp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: playSIP.cpp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: playCommon.cpp URL: From finlayson at live555.com Thu Aug 23 02:46:56 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 23 Aug 2012 02:46:56 -0700 Subject: [Live-devel] openRTSP and seek using TimeZulu In-Reply-To: <20770_1345709530_5035E5DA_20770_3543_1_1BE8971B6CFF3A4F97AF4011882AA25501560059E75E@THSONEA01CMS01P.one.grp> References: <20770_1345709530_5035E5DA_20770_3543_1_1BE8971B6CFF3A4F97AF4011882AA25501560059E75E@THSONEA01CMS01P.one.grp> Message-ID: <2A1C6DF9-DCF9-4AD2-A057-581F6B370959@live555.com> > Do you think it could be helpful to add in openRTSP such a feature ? Yes, good idea. It will 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 friky31 at gmail.com Fri Aug 24 04:18:53 2012 From: friky31 at gmail.com (Friky 31) Date: Fri, 24 Aug 2012 13:18:53 +0200 Subject: [Live-devel] Dropped frames when using non-blocking sockets Message-ID: Hi everyone. First of all I will like to say congratulations for all your hard work and for this successful project. I have a question regarding the usage of non-blocking sockets for streaming video. I am streaming video through unicasting rtp on udp and it seems that even with the best network conditions, some frames (those that are bigger than 20KB) do not arrive to the destination. I have monitored the network traffic using wireshark and it seems that the last packets of each frame are not being transmitted from the host. It looks like the function writeSocket in GroupsockHelper.cpp is discarding the end of each frame if they overrun the buffer. When I prevent the function makeSocketNonBlocking from being called this problem does not happen. Has anyone else experienced this problem? Is there any way to prevent this problem to happen without leaving the sockets blocking. Thank you very much in advance. Alfredo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Sat Aug 25 11:33:52 2012 From: sidprice at softtools.com (Sid Price) Date: Sat, 25 Aug 2012 12:33:52 -0600 Subject: [Live-devel] RTP packet size Message-ID: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> I need to do some integration testing with a proprietary piece of hardware as part of the continuing proof of concept for the project I am working on. The hardware I need to stream audio (from an uncompressed WAV file for the test) to requires a sample rate of 48KHz and we have sources prepared for that. It also requires that the audio frames being streamed are not fragmented and so I need to send a 4mS frame of audio data rather than the 8mS that the server appears to send right now. Could someone point me to the setting or parameter for the library that would enable me to set the frame size to achieve this please? I have searched through the code but so far I have not been able to identify where this is controlled. Thanks, Sid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Aug 25 14:32:22 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 25 Aug 2012 14:32:22 -0700 Subject: [Live-devel] RTP packet size In-Reply-To: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> References: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> Message-ID: <6F1F191F-95D7-425E-ACC8-74A8B089B43C@live555.com> > I need to do some integration testing with a proprietary piece of hardware as part of the continuing proof of concept for the project I am working on. The hardware I need to stream audio (from an uncompressed WAV file for the test) to requires a sample rate of 48KHz and we have sources prepared for that. It also requires that the audio frames being streamed are not fragmented and so I need to send a 4mS frame of audio data rather than the 8mS that the server appears to send right now. Could someone point me to the setting or parameter for the library that would enable me to set the frame size to achieve this please? I have searched through the code but so far I have not been able to identify where this is controlled. There's a bit of confusion here, I think. First, audio from a WAV file are 'samples', not 'frames'. Each sample is usually only 16 bits (i.e., 2 bytes), I think. So WAV (really PCM) audio samples are nowhere near large enough to get fragmented over outgoing RTP packets. OTOH, the LIVE555 code works with 'frames' - delivering one frame at a time. For the code to run efficiently, frames need to be much larger than 2 bytes, so, for streaming PCM audio, we group samples into much larger 'frames'. We also want these 'frames' to be small enough to fit within an outgoing RTP packet. The code for computing this 'preferred frame size' is at 201-204 of "WAVAudioFileSource.cpp". In your case - 48 kHz audio, 2 channels, 16 bits-per-sample (I think) - this will give you a preferred frame size of 1400 bytes: i.e., 350 samples. For a 48 kHz sample rate, this means that each outgoing RTP packet will contain about 7 ms of audio. Now, you seem to be saying that you want want a smaller RTP packet, one that contains only 4 ms of audio - i.e., 192 samples. But why? Having a smaller RTP packet (almost 1/2 as small) will lead to increased overhead (because of the need for almost twice as many Ethernet packets, each with their own RTP header). So it's probably not something that you really want. (Note also that RTP packets do not get seen by receivers - only by the lower-level LIVE555 reception code. An audio receiver still sees only a sequence of audio samples, regardless of the underlying RTP packet size that was used to transmit them.) So, I don't think that you have any real need to change anything. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Sat Aug 25 15:21:33 2012 From: sidprice at softtools.com (Sid Price) Date: Sat, 25 Aug 2012 16:21:33 -0600 Subject: [Live-devel] RTP packet size In-Reply-To: <6F1F191F-95D7-425E-ACC8-74A8B089B43C@live555.com> References: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> <6F1F191F-95D7-425E-ACC8-74A8B089B43C@live555.com> Message-ID: <00e601cd830f$fcb152c0$f613f840$@softtools.com> Thank you, excellent insight. I apologize for not using the correct terminology, still learning here. The requirement is being set by the third party, it is a system used in broadcasting and is a proprietary, closed system, with their own RTP implementation, so I need for these trials to follow their specification. >>> Now, you seem to be saying that you want a smaller RTP packet, one that contains only 4 ms of audio - i.e., 192 samples. But why? Yes I understand this, it is a requirement of the client we need to work with. I also realize, and told them, that it would increase the overhead. Since this piece of equipment (the client) is in production we need to comply with what it needs, at least for the trial. I am sure that changes may be possible later once the project gets a green light. Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Saturday, August 25, 2012 3:32 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTP packet size I need to do some integration testing with a proprietary piece of hardware as part of the continuing proof of concept for the project I am working on. The hardware I need to stream audio (from an uncompressed WAV file for the test) to requires a sample rate of 48KHz and we have sources prepared for that. It also requires that the audio frames being streamed are not fragmented and so I need to send a 4mS frame of audio data rather than the 8mS that the server appears to send right now. Could someone point me to the setting or parameter for the library that would enable me to set the frame size to achieve this please? I have searched through the code but so far I have not been able to identify where this is controlled. There's a bit of confusion here, I think. First, audio from a WAV file are 'samples', not 'frames'. Each sample is usually only 16 bits (i.e., 2 bytes), I think. So WAV (really PCM) audio samples are nowhere near large enough to get fragmented over outgoing RTP packets. OTOH, the LIVE555 code works with 'frames' - delivering one frame at a time. For the code to run efficiently, frames need to be much larger than 2 bytes, so, for streaming PCM audio, we group samples into much larger 'frames'. We also want these 'frames' to be small enough to fit within an outgoing RTP packet. The code for computing this 'preferred frame size' is at 201-204 of "WAVAudioFileSource.cpp". In your case - 48 kHz audio, 2 channels, 16 bits-per-sample (I think) - this will give you a preferred frame size of 1400 bytes: i.e., 350 samples. For a 48 kHz sample rate, this means that each outgoing RTP packet will contain about 7 ms of audio. Now, you seem to be saying that you want want a smaller RTP packet, one that contains only 4 ms of audio - i.e., 192 samples. But why? Having a smaller RTP packet (almost 1/2 as small) will lead to increased overhead (because of the need for almost twice as many Ethernet packets, each with their own RTP header). So it's probably not something that you really want. (Note also that RTP packets do not get seen by receivers - only by the lower-level LIVE555 reception code. An audio receiver still sees only a sequence of audio samples, regardless of the underlying RTP packet size that was used to transmit them.) So, I don't think that you have any real need to change anything. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yukselyigit at yahoo.com Fri Aug 24 12:44:05 2012 From: yukselyigit at yahoo.com (Yuksel Yigit) Date: Fri, 24 Aug 2012 20:44:05 +0100 (BST) Subject: [Live-devel] Multicast Streaming From Live source Message-ID: <1345837445.97802.YahooMailNeo@web171403.mail.ir2.yahoo.com> I'm trying to make multicast streaming using testH264VideoStreamer. I would like to change file source, because i have to get video stream from live rtp source. Have can i use Live555 RTP source to make multicast streaming instead file source? I mean source is Live555(from live source, eg a IP camera), destination is Live555(Multicast). Is it possible? Is there any example before you completed? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Aug 25 20:50:45 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 25 Aug 2012 20:50:45 -0700 Subject: [Live-devel] Multicast Streaming From Live source In-Reply-To: <1345837445.97802.YahooMailNeo@web171403.mail.ir2.yahoo.com> References: <1345837445.97802.YahooMailNeo@web171403.mail.ir2.yahoo.com> Message-ID: <1164D660-74AE-4264-949D-5FBD4FAEFE74@live555.com> > I'm trying to make multicast streaming using testH264VideoStreamer. > I would like to change file source, because i have to get video stream from live rtp source. > Have can i use Live555 RTP source to make multicast streaming instead file source? > I mean source is Live555(from live source, eg a IP camera), destination is Live555(Multicast). > Is it possible? Yes, and how to do this is explained in the FAQ that you were asked to read before posting to the mailing list. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fraph at free.fr Sun Aug 26 02:23:40 2012 From: fraph at free.fr (Raph) Date: Sun, 26 Aug 2012 11:23:40 +0200 Subject: [Live-devel] RTP packet size In-Reply-To: <00e601cd830f$fcb152c0$f613f840$@softtools.com> References: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> <6F1F191F-95D7-425E-ACC8-74A8B089B43C@live555.com> <00e601cd830f$fcb152c0$f613f840$@softtools.com> Message-ID: Can we guess to stream 48khz 24 bits uncompressed wav file one day with Live555 ? best regrads > Thank you, excellent insight. > > > I apologize for not using the correct terminology, still learning here. > > > The requirement is being set by the third party, it is a system used in > broadcasting and is a proprietary, closed system, with their own RTP > implementation, so I need for these trials to follow their specification. > > >>>> Now, you seem to be saying that you want a smaller RTP packet, one >>>> that > contains only 4 ms of audio - i.e., 192 samples. But why? > > > Yes I understand this, it is a requirement of the client we need to work > with. I also realize, and told them, that it would increase the overhead. > Since this piece of equipment (the client) is in production we need to > comply with what it needs, at least for the trial. I am sure that changes > may be possible later once the project gets a green light. > > > Sid. > > > From: live-devel-bounces at ns.live555.com > [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson > Sent: Saturday, August 25, 2012 3:32 PM > To: LIVE555 Streaming Media - development & use > Subject: Re: [Live-devel] RTP packet size > > > I need to do some integration testing with a proprietary piece of > hardware > as part of the continuing proof of concept for the project I am working > on. > The hardware I need to stream audio (from an uncompressed WAV file for > the > test) to requires a sample rate of 48KHz and we have sources prepared for > that. It also requires that the audio frames being streamed are not > fragmented and so I need to send a 4mS frame of audio data rather than > the > 8mS that the server appears to send right now. Could someone point me to > the > setting or parameter for the library that would enable me to set the > frame > size to achieve this please? I have searched through the code but so far > I > have not been able to identify where this is controlled. > > > There's a bit of confusion here, I think. First, audio from a WAV file > are > 'samples', not 'frames'. Each sample is usually only 16 bits (i.e., 2 > bytes), I think. So WAV (really PCM) audio samples are nowhere near > large > enough to get fragmented over outgoing RTP packets. > > > OTOH, the LIVE555 code works with 'frames' - delivering one frame at a > time. > For the code to run efficiently, frames need to be much larger than 2 > bytes, > so, for streaming PCM audio, we group samples into much larger > 'frames'. We > also want these 'frames' to be small enough to fit within an outgoing RTP > packet. > > > The code for computing this 'preferred frame size' is at 201-204 of > "WAVAudioFileSource.cpp". In your case - 48 kHz audio, 2 channels, 16 > bits-per-sample (I think) - this will give you a preferred frame size of > 1400 bytes: i.e., 350 samples. For a 48 kHz sample rate, this means that > each outgoing RTP packet will contain about 7 ms of audio. > > > Now, you seem to be saying that you want want a smaller RTP packet, one > that > contains only 4 ms of audio - i.e., 192 samples. But why? Having a > smaller > RTP packet (almost 1/2 as small) will lead to increased overhead > (because of > the need for almost twice as many Ethernet packets, each with their own > RTP > header). So it's probably not something that you really want. > > > (Note also that RTP packets do not get seen by receivers - only by the > lower-level LIVE555 reception code. An audio receiver still sees only a > sequence of audio samples, regardless of the underlying RTP packet size > that > was used to transmit them.) > > > So, I don't think that you have any real need to change anything. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From finlayson at live555.com Sun Aug 26 02:34:15 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 26 Aug 2012 02:34:15 -0700 Subject: [Live-devel] RTP packet size In-Reply-To: References: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> <6F1F191F-95D7-425E-ACC8-74A8B089B43C@live555.com> <00e601cd830f$fcb152c0$f613f840$@softtools.com> Message-ID: > Can we guess to stream 48khz 24 bits uncompressed wav file one day with Live555 ? I don't know. Can we? If you have a WAV (or other file) that you believe cannot currently be streamed by our code, then please put it on a web site, send us the URL, and we can download and test it for ourself. http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work Ross Finlayson Live Networks, Inc. http://www.live555.com/ ps. In the future, when replying to a message, please trim it before sending. This is basic 'netiquette'. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fraph at free.fr Sun Aug 26 06:53:59 2012 From: fraph at free.fr (Raph) Date: Sun, 26 Aug 2012 15:53:59 +0200 Subject: [Live-devel] RTP packet size In-Reply-To: References: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> <6F1F191F-95D7-425E-ACC8-74A8B089B43C@live555.com> <00e601cd830f$fcb152c0$f613f840$@softtools.com> Message-ID: I mean that there is no RFC about streaming 48khz/24bit. The official RTSP allow only 48khz/16bit. So from, it needs to modify the source code to allow 24 bits streaming. The result is that there is no free software (that cover the 3 main OS) that people can dowload that allows to ear 48k/24bits audio stream. So from, I hope : - A new rfc will add 48khz/24bits streaming audio - Live555 people add this feature. so from I can send to people from mac osX, win or linux, rstp client to dowload and allow them to get this kind of wav stream. Is there some way of doing it ? Best regards. >> Can we guess to stream 48khz 24 bits uncompressed wav file one day with >> Live555 ? > > I don't know. Can we? > > If you have a WAV (or other file) that you believe cannot currently be > streamed by our code, then please put it on a web site, send us the URL, > and we can download and test it for ourself. > > http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > ps. In the future, when replying to a message, please trim it before > sending. This is basic 'netiquette'. > -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From finlayson at live555.com Sun Aug 26 07:40:16 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 26 Aug 2012 07:40:16 -0700 Subject: [Live-devel] RTP packet size In-Reply-To: References: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> <6F1F191F-95D7-425E-ACC8-74A8B089B43C@live555.com> <00e601cd830f$fcb152c0$f613f840$@softtools.com> Message-ID: > I mean that there is no RFC about streaming 48khz/24bit. Actually, there is: RFC 3190, which defines RTP payloads for 20 and 24-bit linear audio (as well as 12-bit DAT audio). We already support the reception of 24-bit (and 20-bit) linear audio over RTP. We don't yet support the *transmission* of 24-bit (or 20-bit) linear audio over RTP, but it would be quite straightforward to update the code to support this. However, doing this would not be a priority for me, *unless* you can provide us an example of a 24-bit WAV audio file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fraph at free.fr Sun Aug 26 17:54:00 2012 From: fraph at free.fr (Raph) Date: Mon, 27 Aug 2012 02:54:00 +0200 Subject: [Live-devel] RTP packet size In-Reply-To: References: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> <6F1F191F-95D7-425E-ACC8-74A8B089B43C@live555.com> <00e601cd830f$fcb152c0$f613f840$@softtools.com> Message-ID: It's very easy to provide such a file ! But if you tell me where to look in the code, I can look in it and try to adapt it to 24 bits. So form I will able to test it on my Linux server. Thanks a lot. But if you prefer an short stereo 48k 24 bits ask me. Best regards. Grag38 >> I mean that there is no RFC about streaming 48khz/24bit. > > Actually, there is: RFC 3190, which defines RTP payloads for 20 and > 24-bit linear audio (as well as 12-bit DAT audio). > > We already support the reception of 24-bit (and 20-bit) linear audio > over RTP. We don't yet support the *transmission* of 24-bit (or 20-bit) > linear audio over RTP, but it would be quite straightforward to update > the code to support this. > > However, doing this would not be a priority for me, *unless* you can > provide us an example of a 24-bit WAV audio file. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From finlayson at live555.com Sun Aug 26 21:03:05 2012 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 26 Aug 2012 21:03:05 -0700 Subject: [Live-devel] RTP packet size In-Reply-To: References: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> <6F1F191F-95D7-425E-ACC8-74A8B089B43C@live555.com> <00e601cd830f$fcb152c0$f613f840$@softtools.com> Message-ID: <19698667-BB8A-41E4-AA8D-231EB009D7F1@live555.com> > It's very easy to provide such a file ! Then please provide an example of one (i.e., a 24-bit WAV audio file)! That's what I've been asking for all along! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinkuokingking at hotmail.com Mon Aug 27 00:35:17 2012 From: kevinkuokingking at hotmail.com (kingking kuo) Date: Mon, 27 Aug 2012 07:35:17 +0000 Subject: [Live-devel] Problem! If Matroska file not exist Message-ID: Hi, If Matroska if is not exist the program will crash. 1. In MatroskaFile.cpp fParserForInitialization = new MatroskaFileParser(*this, ByteStreamFileSource::createNew(envir(), fileName), handleEndOfTrackHeaderParsing, this, NULL); 2. In MatroskaFileParser.cpp if (ourDemux == NULL) { // Initialization fCurrentParseState = PARSING_START_OF_FILE; continueParsing(); } void MatroskaFileParser::continueParsing() { // ... if (fOnEndFunc != NULL) (*fOnEndFunc)(fOnEndClientData);} 3. In MatroskaFile.cpp void MatroskaFile::handleEndOfTrackHeaderParsing() { // Delete our parser, because it's done its job now: // if Matroska file is not exist, the fParserForInitialization is a invalid pointer. delete fParserForInitialization; fParserForInitialization = NULL; // Finally, signal our caller that we've been created and initialized: if (fOnCreation != NULL) (*fOnCreation)(this, fOnCreationClientData);} -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 27 01:06:24 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 27 Aug 2012 01:06:24 -0700 Subject: [Live-devel] Problem! If Matroska file not exist In-Reply-To: References: Message-ID: > If Matroska if is not exist the program will crash. > > 1. In MatroskaFile.cpp > > fParserForInitialization > = new MatroskaFileParser(*this, ByteStreamFileSource::createNew(envir(), fileName), > handleEndOfTrackHeaderParsing, this, NULL); [...] > // if Matroska file is not exist, the fParserForInitialization is a invalid pointer. No, that should not be the case. If the file "fileName" does not exist, then the call to "ByteStreamFileSource::createNew(envir(), fileName)" will return NULL, and therefore the "MatroskaFileParser" constructor will be called with an "inputSource" parameter of NULL. This will cause the "fInputSource" member variable to get set to NULL. That should be OK, because we always check that "fInputSource" is NULL before we try to dereference it. But in any case, a valid "MatroskaFileParser" object should be constructed, and thus "fParserForInitialization" should be valid (and non-NULL). I won't rule out the possibility of there being some problem with the code if the file "fileName" does not exist, but if there is, then it's not what you described. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fraph at free.fr Mon Aug 27 03:36:53 2012 From: fraph at free.fr (Raph) Date: Mon, 27 Aug 2012 12:36:53 +0200 Subject: [Live-devel] RTP packet size In-Reply-To: <19698667-BB8A-41E4-AA8D-231EB009D7F1@live555.com> References: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> <6F1F191F-95D7-425E-ACC8-74A8B089B43C@live555.com> <00e601cd830f$fcb152c0$f613f840$@softtools.com> <19698667-BB8A-41E4-AA8D-231EB009D7F1@live555.com> Message-ID: Here is one you can download. Hope you will love this song ;o) http://fraph.free.fr/WAV48K24B/FEVERTIME.wav thanks. Can you just tell me the source file you will modify ? I suppose it's : WAVAudioFileSource.cpp in the live/media directory. Thanks a lot and best regards. Grag38 >> It's very easy to provide such a file ! > > Then please provide an example of one (i.e., a 24-bit WAV audio file)! > That's what I've been asking for all along! > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From nathan at rnrkoester.com Mon Aug 27 04:37:48 2012 From: nathan at rnrkoester.com (Nathan RNR) Date: Mon, 27 Aug 2012 07:37:48 -0400 Subject: [Live-devel] Question about live streaming Message-ID: <001f01cd8448$633baf20$29b30d60$@rnrkoester.com> Hello, I am currently building an Android application designed to stream encoded video (live) from each phone to a different phone, and I play to use Live555 as the server. I read that to support live streaming to edit the OnDemandRTSPServer, as well as make a few other changes. I did said changes and have yet to get it to work. I changed the port, the unicast, the RawUDP Boolean, etc. Is there anyway you can help me to solve this problem? Thank you, NM -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 27 07:44:19 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 27 Aug 2012 07:44:19 -0700 Subject: [Live-devel] Question about live streaming In-Reply-To: <001f01cd8448$633baf20$29b30d60$@rnrkoester.com> References: <001f01cd8448$633baf20$29b30d60$@rnrkoester.com> Message-ID: <2F1CF5E2-E40E-43CC-98F6-23489E1E1A0F@live555.com> > I am currently building an Android application designed to stream encoded video (live) from each phone to a different phone, and I play to use Live555 as the server. I read that to support live streaming to edit the OnDemandRTSPServer, as well as make a few other changes. I did said changes and have yet to get it to work. I changed the port, the unicast, the RawUDP Boolean, etc. Is there anyway you can help me to solve this problem? No, but I do not recommend streaming from a raw UDP input source (note that that will usually work *only* for MPEG Transport Stream data). Instead, if your encoded video comes from the same computer (phone) that you wish to stream from, then your server should just read directly from the encoder. See and Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at rnrkoester.com Mon Aug 27 10:04:45 2012 From: nathan at rnrkoester.com (Nathan) Date: Mon, 27 Aug 2012 13:04:45 -0400 Subject: [Live-devel] Question about live streaming Message-ID: It does not. I am going to be streaming globally and am using a global server to direct all the traffic, creating rtsp streams for each device. -------- Original message -------- Subject: Re: [Live-devel] Question about live streaming From: Ross Finlayson To: LIVE555 Streaming Media - development & use CC: I am currently building an Android application designed to stream encoded video (live) from each phone to a different phone, and I play to use Live555 as the server. I read that to support live streaming to edit the OnDemandRTSPServer, as well as make a few other changes. I did said changes and have yet to get it to work. I changed the port, the unicast, the RawUDP Boolean, etc. Is there anyway you can help me to solve this problem? No, but I do not recommend streaming from a raw UDP input source (note that that will usually work *only* for MPEG Transport Stream data). ?Instead, if your encoded video comes from the same computer (phone) that you wish to stream from, then your server should just read directly from the encoder. ?See and Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 27 12:23:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 27 Aug 2012 12:23:51 -0700 Subject: [Live-devel] Question about live streaming In-Reply-To: References: Message-ID: <1E48793B-DBC2-4266-BFA5-127C0582A526@live555.com> > It does not. I am going to be streaming globally and am using a global server to direct all the traffic, creating rtsp streams for each device. I'm not sure I understand this, but from your description, I suspect that you don't want to be using RTSP at all. RTSP is used for one-way streaming: From a server to one or more receiving clients. If you, instead, want your phones to be both sending and receiving audio+video - e.g., for a two-party audio+video phone call, or for a multi-party audio+video conference - then you definitely don't want to be using the RTSP protocol. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at rnrkoester.com Mon Aug 27 13:24:34 2012 From: nathan at rnrkoester.com (Nathan RNR) Date: Mon, 27 Aug 2012 16:24:34 -0400 Subject: [Live-devel] Question about live streaming In-Reply-To: <1E48793B-DBC2-4266-BFA5-127C0582A526@live555.com> References: <1E48793B-DBC2-4266-BFA5-127C0582A526@live555.com> Message-ID: <006601cd8491$f9ffaee0$edff0ca0$@rnrkoester.com> But why would I not want the protocol? I would stream to the server, that server would then make the stream global for other devices to connect. The purpose for this is I only want to view a single stream at one time, denoted by the username of the user, which will be the name of the stream, if that makes sense. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, August 27, 2012 3:24 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Question about live streaming It does not. I am going to be streaming globally and am using a global server to direct all the traffic, creating rtsp streams for each device. I'm not sure I understand this, but from your description, I suspect that you don't want to be using RTSP at all. RTSP is used for one-way streaming: >From a server to one or more receiving clients. If you, instead, want your phones to be both sending and receiving audio+video - e.g., for a two-party audio+video phone call, or for a multi-party audio+video conference - then you definitely don't want to be using the RTSP protocol. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Mon Aug 27 15:43:02 2012 From: sidprice at softtools.com (Sid Price) Date: Mon, 27 Aug 2012 16:43:02 -0600 Subject: [Live-devel] Subclassing WAVAudioFileSource Message-ID: <007101cd84a5$521328b0$f6397a10$@softtools.com> Since my original thread (RTP Packet Size) has been hijacked into a different subject I thought I would start a new one, I trust that is the correct list protocol. In order to address the trails I mentioned I need to subclass WAVAudioFileSource to set "fPreferredFrameSize" to achieve the required RTP packet. This is a "private" variable. Is it possible to have you move it to "protected?" Sid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Aug 27 16:12:17 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 27 Aug 2012 16:12:17 -0700 Subject: [Live-devel] Subclassing WAVAudioFileSource In-Reply-To: <007101cd84a5$521328b0$f6397a10$@softtools.com> References: <007101cd84a5$521328b0$f6397a10$@softtools.com> Message-ID: <67B4C3AD-3979-43FD-A1A8-B9589F5D49A9@live555.com> > In order to address the trails I mentioned I need to subclass WAVAudioFileSource to set ?fPreferredFrameSize? to achieve the required RTP packet. This is a ?private? variable. Is it possible to have you move it to ?protected?? Yes; this change will appear 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 sidprice at softtools.com Mon Aug 27 16:42:36 2012 From: sidprice at softtools.com (Sid Price) Date: Mon, 27 Aug 2012 17:42:36 -0600 Subject: [Live-devel] Subclassing WAVAudioFileSource In-Reply-To: <67B4C3AD-3979-43FD-A1A8-B9589F5D49A9@live555.com> References: <007101cd84a5$521328b0$f6397a10$@softtools.com> <67B4C3AD-3979-43FD-A1A8-B9589F5D49A9@live555.com> Message-ID: <008301cd84ad$a4294870$ec7bd950$@softtools.com> Thank you Ross, much appreciated, Sid. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, August 27, 2012 5:12 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Subclassing WAVAudioFileSource In order to address the trails I mentioned I need to subclass WAVAudioFileSource to set "fPreferredFrameSize" to achieve the required RTP packet. This is a "private" variable. Is it possible to have you move it to "protected?" Yes; this change will appear 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 Mon Aug 27 19:05:18 2012 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 27 Aug 2012 19:05:18 -0700 Subject: [Live-devel] RTP packet size In-Reply-To: References: <00c301cd82f0$2e4c0bb0$8ae42310$@softtools.com> <6F1F191F-95D7-425E-ACC8-74A8B089B43C@live555.com> <00e601cd830f$fcb152c0$f613f840$@softtools.com> <19698667-BB8A-41E4-AA8D-231EB009D7F1@live555.com> Message-ID: <08327A31-8ED0-4F62-944A-0612A49B9E79@live555.com> > Here is one you can download. Hope you will love this song ;o) > > http://fraph.free.fr/WAV48K24B/FEVERTIME.wav Thanks. I have now installed a new version (2012.08.28) of the "LIVE555 Streaming Media" code that supports streaming this, and other, 24-bit WAV files. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkhaike at gmail.com Mon Aug 27 21:12:09 2012 From: kkhaike at gmail.com (Dexter.O) Date: Tue, 28 Aug 2012 12:12:09 +0800 Subject: [Live-devel] TCP Zero Window /Full using openRTSP with RTP over TCP Message-ID: 1.I run openRTSP on win7 2.Here is my command line input: openrtsp -t rtsp://192.168.36.166:8554/cam00 3.H264 video i think recvfrom call too often,when tcp send TCP Zero Window /Full,select still set frecv,and recvfrom still return EWOULDBLOCK,so it into a unlimit loop, how can i fix it. thx From kevinkuokingking at hotmail.com Mon Aug 27 21:53:48 2012 From: kevinkuokingking at hotmail.com (kingking kuo) Date: Tue, 28 Aug 2012 04:53:48 +0000 Subject: [Live-devel] Problem! If Matroska file not exist In-Reply-To: References: Message-ID: > > > If Matroska if is not exist the program will crash.> > > > 1. In MatroskaFile.cpp > > > > fParserForInitialization> > = new MatroskaFileParser(*this, ByteStreamFileSource::createNew(envir(), fileName),> > handleEndOfTrackHeaderParsing, this, NULL); > [...]> > // if Matroska file is not exist, the fParserForInitialization is a invalid pointer.> > No, that should not be the case. If the file "fileName" does not exist, then the call to "ByteStreamFileSource::createNew(envir(), fileName)" will return NULL, and therefore the "MatroskaFileParser" constructor will be called with an "inputSource" parameter of NULL. This will cause the "fInputSource" member variable to get set to NULL. That should be OK, because we always check that "fInputSource" is NULL before we try to dereference it. But in any case, a valid "MatroskaFileParser" object should be constructed, and thus "fParserForInitialization" should be valid (and non-NULL).> > I won't rule out the possibility of there being some problem with the code if the file "fileName" does not exist, but if there is, then it's not what you described.> > Yes, If the file "filename" does not exist, then "ByteStreamFileSource::createNew(envir(), fileName)" will return NULL, and therefore the "MatroskaFileParser" constructor will be called with an "inputSource" parameter of NULL. This will cause the "fInputSource" member variable to get set to NULL. but, In void MatroskaFileParser::continueParsing() call, the "if (fOnEndFunc != NULL) (*fOnEndFunc)(fOnEndClientData);" will call, then will call "void MatroskaFile::handleEndOfTrackHeaderParsing()", and this time the "fParserForInitialization" is a invalid pointer, delete the invalid pointer will crash. note: I create a solution in vs 2008 ,and i add the file into the solution, I can complie and build the solution, If I need additions settings? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 28 00:56:03 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 28 Aug 2012 00:56:03 -0700 Subject: [Live-devel] Problem! If Matroska file not exist In-Reply-To: References: Message-ID: <2F5B59CD-B368-487D-8455-39CACF5864D1@live555.com> > but, In void MatroskaFileParser::continueParsing() call, the "if (fOnEndFunc != NULL) (*fOnEndFunc)(fOnEndClientData);" will call, then will call "void MatroskaFile::handleEndOfTrackHeaderParsing()", and this time the "fParserForInitialization" is a invalid pointer, delete the invalid pointer will crash. Unfortunately you're still describing the *symptoms* of an apparent bug, but I'm not seeing the *cause* of the bug. There are only two possible ways that the "fParserForInitialization" pointer could become invalid: 1/ "handleEndOfTrackHeaderParsing()" is being called on a "MatroskaFile" object after its destructor has already been called, or 2/ Something is (somehow) writing over the "fParserForInitialization" field in (what would otherwise be) a still-valid "MatroskaFile" object. So I now need to know which of these is happening, and why. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From edenlee at gorilla-technology.com Tue Aug 28 01:54:47 2012 From: edenlee at gorilla-technology.com (Eden Lee (Gorilla)) Date: Tue, 28 Aug 2012 16:54:47 +0800 Subject: [Live-devel] A Problem of RTSP Server In-Reply-To: <2F533FDD-2E45-4A30-8229-937E655D41B1@live555.com> References: <05FFBC8A-683E-4DE3-A7B8-2033345CBD06@live555.com> <5137E5A4-BB43-4AAD-9387-663E7CAC9272@live555.com> <2F533FDD-2E45-4A30-8229-937E655D41B1@live555.com> Message-ID: Dear Ross, Currently, we have many PCs on which VLC Media Player is installed. Most of them (VLC RTSP clients) can correctly display the image from our RTSP server. However, some can't with black screen (no any image). I don't know Why? The following message is shown by VLC Media Player: main error: ES_OUT_RESET_PCR is called I debug our RTSP server. It seems that image frames are continuously and correctly delivered out. Do you have any idea about this? Thank you again for your comment in advance. BR, Eden From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, August 15, 2012 3:50 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] A Problem of RTSP Server I change OutPacketBuffer::maxSize to be 300000. The display of local RTSP client is correct. Unfortunately, the remote client's display is still incorrect. Do you have any idea about this situation? No, but because you're seeing problems only with a remote (networked) VLC RTSP client, I suspect you're seeing some network packet loss. As I said before: "[You should not be sending] such ridiculously large NAL units. You should reconfigure your encoder to encode each IDR picture (i.e., 'I-frame') into multiple 'slice' NAL units. This is a good idea, because if packets forming a 'slice' NAL unit get lost, then that will cause only that slice to be non-renderable. On the other hand, if the IDR picture is a complete NAL unit, then the loss of *any* packet will cause the whole picture to be non-renderable." Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Tue Aug 28 07:32:56 2012 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Tue, 28 Aug 2012 16:32:56 +0200 Subject: [Live-devel] Is it possible to add some arguments to live555mediaServer Message-ID: <22306_1346164430_503CD6CE_22306_6389_1_1BE8971B6CFF3A4F97AF4011882AA255015601F202A4@THSONEA01CMS01P.one.grp> Hi Ross, We used live555MediaServer for test purpose and it is nice because it is very simple, but as there is no parameter it choose it behaviour by itself (depending of available ports). You will find attached a small modification in order to specify a port as an argument. An other behaviour we would like to control using arguments is the availibility to loop on the source file (I means without closing the RTSP session). Could you advise us, how to looping on the file source when end is reached. Best Regards, Michel. [@@THALES GROUP RESTRICTED@@] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: live555MediaServer.cpp URL: From finlayson at live555.com Tue Aug 28 09:10:30 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 28 Aug 2012 09:10:30 -0700 Subject: [Live-devel] Is it possible to add some arguments to live555mediaServer In-Reply-To: <22306_1346164430_503CD6CE_22306_6389_1_1BE8971B6CFF3A4F97AF4011882AA255015601F202A4@THSONEA01CMS01P.one.grp> References: <22306_1346164430_503CD6CE_22306_6389_1_1BE8971B6CFF3A4F97AF4011882AA255015601F202A4@THSONEA01CMS01P.one.grp> Message-ID: <95CA7053-4277-4892-81E2-675B8906F2A6@live555.com> > We used live555MediaServer for test purpose and it is nice because it is very simple, but as there is no parameter it choose it behaviour by itself (depending of available ports). > You will find attached a small modification in order to specify a port as an argument. No, the "LIVE555 Media Server" application is intended to be a simple, self-contained 'appliance' that - for most people - will work well 'as is', with no extra 'knobs' to turn - i.e., with no command-line parameters. Note, in particular, that the server automatically first tries to use port 554 for RTSP, and then, if that fails (usually because the user didn't have permission to use port 554) will then try to use the IANA-defined alternative port 8554 instead. That will be sufficient for most people (because few people will/should already have RTSP servers running on other ports). (Note also that 554 and 8554 are the only port numbers officially registered by IANA for use for RTSP; if users arbitrarily choose some other port number, then there's a possibility that it might have been registered for some other use. However, the application code is, of course, Open Source, which means that anyone can write their own server code that happens to use the "LIVE555 Media Server" code as a model. (Of course, it's best that they not modify the supplied code 'in place'.) > An other behaviour we would like to control using arguments is the availibility to loop on the source file (I means without closing the RTSP session). > Could you advise us, how to looping on the file source when end is reached. The best way to do this is to write your own "FramedSource" subclass that presents the illusion of a single, continuous stream of data - i.e., by automatically reseeking to the front of the file (or closing/reopening it) whenever the end of the file is reached. Then use this subclass in a new "OnDemandServerMediaSubsession" subclass (that you would also write). That way, none of the other server code would need to change - it would act just as if the data source happened to be infinite. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidprice at softtools.com Tue Aug 28 15:03:05 2012 From: sidprice at softtools.com (Sid Price) Date: Tue, 28 Aug 2012 16:03:05 -0600 Subject: [Live-devel] Release 2012.08.28 Message-ID: <001701cd8568$e78e0630$b6aa1290$@softtools.com> Ross, I just tried to do the subclass of WAVAudioFileSource and discovered that the "fPreferredFrameSize" variable in that class is still private. In checking the release notes for 2012.08.28 I see that the variable was moved from private to protected in "ByteStreamFileSource." Is this what you intended? Sid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Aug 28 16:05:45 2012 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 28 Aug 2012 16:05:45 -0700 Subject: [Live-devel] Release 2012.08.28 In-Reply-To: <001701cd8568$e78e0630$b6aa1290$@softtools.com> References: <001701cd8568$e78e0630$b6aa1290$@softtools.com> Message-ID: > I just tried to do the subclass of WAVAudioFileSource and discovered that the ?fPreferredFrameSize? variable in that class is still private. In checking the release notes for 2012.08.28 I see that the variable was moved from private to protected in ?ByteStreamFileSource.? Is this what you intended? No, I had mistakenly thought that "WAVAudioFileSource" was a subclass of "ByteStreamFileSource". The change should have been made to "WAVAudioFileSource.hh" instead. I'll fix this in the next release (coming within an hour). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinkuokingking at hotmail.com Tue Aug 28 19:12:47 2012 From: kevinkuokingking at hotmail.com (kingking kuo) Date: Wed, 29 Aug 2012 02:12:47 +0000 Subject: [Live-devel] Problem! If Matroska file not exist In-Reply-To: References: Message-ID: > > > but, In void MatroskaFileParser::continueParsing() call, the "if (fOnEndFunc != NULL) (*fOnEndFunc)(fOnEndClientData);" will call, then will call "void MatroskaFile::handleEndOfTrackHeaderParsing()", and this time the "fParserForInitialization" is a invalid pointer, delete the invalid pointer will crash. > > Unfortunately you're still describing the *symptoms* of an apparent bug, but I'm not seeing the *cause* of the bug. There are only two possible ways that the "fParserForInitialization" pointer could become invalid: > 1/ "handleEndOfTrackHeaderParsing()" is being called on a "MatroskaFile" object after its destructor has already been called, or > 2/ Something is (somehow) writing over the "fParserForInitialization" field in (what would otherwise be) a still-valid "MatroskaFile" object. > > So I now need to know which of these is happening, and why. > The reason is destructor "fParserForInitialization" before its Init complete, If "MatroskaFile" is not exist. see following setps. 1. "MatroskaFile" construct function { 2. fParserForInitialization = new MatroskaFileParser() { 3. call MatroskaFileParser's construct funciton 4. call MatroskaFileParser's member function "continueParsing" (when MatroskaFile is not exist, the fInputSource is NULL, but fOnEndFunc is not NULL, so continue next setup.) 5. call MatroskaFile's member function "handleEndOfTrackHeaderParsing" 6. call delete fParserForInitialization. (but this time fParserForInitialization Initialize is not completed, the MatroskaFileParser's construct function is not return, so fParserForInitialization is a invalid pointer) } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Aug 29 13:54:24 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 29 Aug 2012 13:54:24 -0700 Subject: [Live-devel] Problem! If Matroska file not exist In-Reply-To: References: Message-ID: > The reason is destructor "fParserForInitialization" before its Init complete, If "MatroskaFile" is not exist. OK, thanks. This is the explanation that I was looking for. The next release of the software (in a few hours) should fix this bug. Thanks again. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at metamachine.com Wed Aug 29 16:09:01 2012 From: owen at metamachine.com (owen at metamachine.com) Date: Wed, 29 Aug 2012 16:09:01 -0700 Subject: [Live-devel] live streaming media server bug report In-Reply-To: <2e47ab8853fa08bf37e4f788c24ce448.squirrel@www.metamachine.com> References: <2e47ab8853fa08bf37e4f788c24ce448.squirrel@www.metamachine.com> Message-ID: <33e755cd959cd29b70eb366625ea329c.squirrel@www.metamachine.com> > Hi. > > I downloaded live.2012.08.29.tar.gz a few minutes ago, and built in on my > linux box*. > > I saw several warnings issued by the compiler. > > I've been looking closely at each, and I think there's an actual problem > with one of them. > ---- > c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. > -O2 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 > -Wall -DBSD=1 MatroskaFileParser.cpp > MatroskaFileParser.cpp: In member function ?Boolean > MatroskaFileParser::parseEBMLVal_float(EBMLDataSize&, float&)?: > MatroskaFileParser.cpp:1138:26: warning: dereferencing type-punned pointer > will break strict-aliasing rules [-Wstrict-aliasing] > MatroskaFileParser.cpp:1145:34: warning: dereferencing type-punned pointer > will break strict-aliasing rules [-Wstrict-aliasing] > c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. > -O2 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 > -Wall -DBSD=1 EBMLNumber.cpp > ---- > > complains about the following statement: > ---- > result = *(float*)&resultAsUnsigned; > > ---- > result is a float passed in by reference, and resultAsUnsigned is an > unsigned int. > > This little snippet, and it's compiled output, illustrate the problem: > ---- > #include > > using namespace std; > > void func(float &f) > { > unsigned val = 3; > unsigned *vptr = &val; > f = *(float*)vptr; > } > > int main(int ac, char **av) > { > float f; > > func(f); > > cout << "f == " << f << endl; > > return 0; > } > -- > owen at owen ~/src/tests $ ./test_unsigned_float > f == 4.2039e-45 > owen at owen ~/src/tests $ > -- > ---- > Note that the output should have been 3.0, but to get that, the code would > have to be changed to: > ---- > f = (float)*vptr; > ---- > > > // Wally > > > * Linux Mint 13 32-bit; gcc 4.6; c++ lib 4.6.3 > From kevinkuokingking at hotmail.com Wed Aug 29 22:51:54 2012 From: kevinkuokingking at hotmail.com (kingking kuo) Date: Thu, 30 Aug 2012 05:51:54 +0000 Subject: [Live-devel] =?cp1256?q?problem_about_uninitialized_local_unsigne?= =?cp1256?q?d_variable=FE?= Message-ID: Hi, I use mplayer to visit rtsp://localhost:8854/mp3test, If RTSPServer recv the request , RTSPServer will call the function "handleRequestBytes",In this function we see the local unsigned variable "contentLength", and this local variable is not init , thus the variable's init value is not sure is 0xffffffff,0xcccccccc,or other values. then the first rtsp request is "rtsp://localhost:8854" and not contain "mp3test", this time the next function call "parseRTSPRequestString" will failed, and the var "contentLength" is not a sure value. when continue to this setup "unsigned requestSize = (fLastCRLF+4-fRequestBuffer) + contentLength;" in function "handleRequestByte" , if "contentLength" is 0xffffffff then "requestSize" is the request buffer size - 1, if "contentLength" is 0xcccccccc the "requestSize" is a big num,or other posible value. next setup " memmove(fRequestBuffer, &fRequestBuffer[requestSize], numBytesRemaining);" if requestSize is a big num , this call will crashed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Aug 29 23:13:29 2012 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 29 Aug 2012 23:13:29 -0700 Subject: [Live-devel] =?utf-8?q?problem_about_uninitialized_local_unsigned?= =?utf-8?b?IHZhcmlhYmxl4oCP?= In-Reply-To: References: Message-ID: > then the first rtsp request is "rtsp://localhost:8854" and not contain "mp3test", this time the next function call "parseRTSPRequestString" will failed, and the var "contentLength" is not a sure value. Yes, this is a bug. The "contentLength" needs to be initialized (to 0) before calling "parseRTSPRequestString()", in case this call returns False. The latest version (2012.08.30) of the code fixes this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 30 00:44:51 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Aug 2012 00:44:51 -0700 Subject: [Live-devel] live streaming media server bug report In-Reply-To: <33e755cd959cd29b70eb366625ea329c.squirrel@www.metamachine.com> References: <2e47ab8853fa08bf37e4f788c24ce448.squirrel@www.metamachine.com> <33e755cd959cd29b70eb366625ea329c.squirrel@www.metamachine.com> Message-ID: >> complains about the following statement: >> ---- >> result = *(float*)&resultAsUnsigned; No, this compiler warning message does not indicate a bug in the code. "resultAsUnsigned" is a 4-byte value that stores a 'float'; it is not an unsigned value that gets converted to a float. >> This little snippet, and it's compiled output, illustrate the problem: No, a more accurate 'snippet', which illustrates what the code really does, would be: void func(float &f) { float val = 3.0; unsigned *vptr = (unsigned*)&val; unsigned resultAsUnsigned = *vptr; // a 4-byte value that stores a 'float' f = *(float*)&resultAsUnsigned; } (and then "main()" as you originally wrote it) If you can suggest an alternative coding that eliminates your compiler warning, then that would be great. But the code - as it stands - is not in error. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Thu Aug 30 03:28:48 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Thu, 30 Aug 2012 12:28:48 +0200 Subject: [Live-devel] RTP over RTSP: client sending RR "early" Message-ID: <503F5C800200004D000724C4@pta-emo.csir.co.za> Hi Ross,We've run into a new issue using RTP over RTSP mode over Edge and really slow wireless connections. This happens in our client application (that was based on openRTSP) as well as in VLC, which also uses live555. In the case where the TCP connection is really slow, it can happen that the client sends the first RR before the client and server have completed the entire RTSP interchange i.e. before the client has read the response to PLAY. In this case the server reads the RR, but since the TCP connection handler is in the incorrect state, the server responds with a "method not allowed". There are a couple of ways to fix this though I would assume that the problem is on the client side. Please could we have your input since you know the code best. 1) The server could of course be made more robust by detecting the '$' char and ignoring such requests. Would this work as a quick fix? 2) The (more correct?) approach would be to only allow the client to send an RR after it has received a PLAY response. The RTCPInstance is created in MediaSubsession::initiate which IIRC happens after the client receives the DESCRIBE response. I don't know the code well enough to see how to fix it. Should the creation of the RTCPInstance be deferred until after the PLAY has been received? Any pointers/advice would be appreciated. Regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From Shaheed at scansoft.co.za Thu Aug 30 04:41:47 2012 From: Shaheed at scansoft.co.za (Shaheed Abdol) Date: Thu, 30 Aug 2012 13:41:47 +0200 Subject: [Live-devel] Access violation in StramParser::testBytes() Message-ID: <002962EA5927BE45B2FFAB0B5B5D67970A8FAF@SSTSVR1.sst.local> Good afternoon Ross, I have updated to the latest version of the code, have read the FAQ and have studied the included code samples. I am having some trouble within my rtsp server code (based on the provided source code) which creates subsessions on demand. These subsessions could be file sources or live sources - based on the DeviceSource example. I have subclassed the OnDemandServerMediaSubsession, and have overridden the createNewStreamSource and createNewRTPSink functions as the FAQ instructs and can successfully receive an MPEG2 Program stream, demux it into an MPEG1or2DemuxedElementaryStream and pass data that into an H264VideoStreamFramer. The above process seems correct, and I can stream the resulting H264 data smoothly to both the openRTSP client (the resulting file is playable) and VLC. The problem I seem to be having is that whenever I disconnect the client application (openRTSP or VLC), the server experiences an Access violation. I have scoured the logs and have found that the TEARDOWN is received by RTSPClientSession and seems to be handled properly, except that the testBytes function (in StreamParser.hh) is referencing an invalid pointer (line: 85 - memmove(to, nextToParse(), numBytes) which is causing the violation - the "to" pointer has been deleted. Should I be overriding some other function to handle the stream closure? I have checked the FramedSource header file and can see a static void handleClosure(void* clientData); Which hints that it's possible to handle the closing stream in my derived classes, but that method is static and not virtual, is there another mechanism in place which I could use? Any advice would be appreciated. Thank you Regards ___________________________________ Shaheed Abdol Web: www.scansoft.co.za Tel: +27 21 913 8664 Cell: +27 79 835 8771 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SST Email.png Type: image/png Size: 32497 bytes Desc: SST Email.png URL: From Viatcheslav.Sysoltsev at h-d-gmbh.de Thu Aug 30 03:02:19 2012 From: Viatcheslav.Sysoltsev at h-d-gmbh.de (Viatcheslav.Sysoltsev at h-d-gmbh.de) Date: Thu, 30 Aug 2012 12:02:19 +0200 Subject: [Live-devel] MultiFramedRTPSink flush collected packet Message-ID: Hi people, I am using SimpleRTPSink with my frame source (based on FramedSource). The frame may be small, so SimpleRTPSink packs several frames into a single packet. That's right, I wish it to do so. I have nevertheless troubles to realize, how to make SimpleRTPSink flush its packets in a time manner, after for example the first frame of a packet has 10ms overdue time. Is there an easy way to achieve sending the not-yet-full packets in time? I think of calling MultiFramedRTPSink::sendPacketIfNecessary() on timer, but I'm not not sure. -- Slava From fraph at free.fr Thu Aug 30 03:03:44 2012 From: fraph at free.fr (Raph) Date: Thu, 30 Aug 2012 12:03:44 +0200 Subject: [Live-devel] WAV 48Khz 24 bits and VLC strange thing Message-ID: I just compiled and tested live555MediaServer. I stream some wav audio files, they are 48khz 24 bits. Every thing is working perfect ! but with long files with VLC when I move the cursor around 31:06 (minutes) or more I get a sound like with/pink noise. If I put the cursor before (let's say 30 minutes) , VLC plays it well and the streaming continues to be ok, even after 31:06. I suppose there is a trouble about seeking in the file when the time requested is above 31:06... May be the value of the offset is not enough huge (is it an int or a long ? may be an unsigned long would be ok...), I don't know. Best regards. Grag38 From finlayson at live555.com Thu Aug 30 05:36:42 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Aug 2012 05:36:42 -0700 Subject: [Live-devel] WAV 48Khz 24 bits and VLC strange thing In-Reply-To: References: Message-ID: <0DFB9C7A-63DD-40BD-8BCE-16E88B7C61ED@live555.com> > If I put the cursor before (let's say 30 minutes) , VLC plays it well and the streaming continues to be ok, even after 31:06. > > I suppose there is a trouble about seeking in the file when the time requested is above 31:06... Yes, it seems so. Once again, please post (the URL of) an example of a WAV audio file that illustrates this problem. (Why do I have to keep asking your this? :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fraph at free.fr Thu Aug 30 05:58:10 2012 From: fraph at free.fr (Raph) Date: Thu, 30 Aug 2012 14:58:10 +0200 Subject: [Live-devel] WAV 48Khz 24 bits and VLC strange thing In-Reply-To: <0DFB9C7A-63DD-40BD-8BCE-16E88B7C61ED@live555.com> References: <0DFB9C7A-63DD-40BD-8BCE-16E88B7C61ED@live555.com> Message-ID: I can give you an address, but I would like to give it only to you because our dedicated server is only for bands, producers. So from I prefer not to send this link on a public area as is this mailing list, just because the files it contains are not dedicated for public streaming, because of the copyright. Our company records around 160 live concerts a year (video + audio) and the server is dedicated for only the owner of these concerts (musicien, producer, cd editors, ...). Can you give me an personnal mail so from I will send you the RTSP address of one of our file on this server. thanks a lot. Grag39 >> If I put the cursor before (let's say 30 minutes) , VLC plays it well >> and the streaming continues to be ok, even after 31:06. >> >> I suppose there is a trouble about seeking in the file when the time >> requested is above 31:06... > > Yes, it seems so. Once again, please post (the URL of) an example of a > WAV audio file that illustrates this problem. (Why do I have to keep > asking your this? :-) > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From finlayson at live555.com Thu Aug 30 06:14:30 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Aug 2012 06:14:30 -0700 Subject: [Live-devel] MultiFramedRTPSink flush collected packet In-Reply-To: References: Message-ID: <004FFF90-D13F-428F-8BAE-2BD596C80DE8@live555.com> > I am using SimpleRTPSink with my frame source (based on FramedSource). By this I hope you mean "a subclass of FramedSource". > The frame may be small, so SimpleRTPSink packs several frames into a single packet. That's right, I wish it to do so. I have nevertheless troubles to realize, how to make SimpleRTPSink flush its packets in a time manner, after for example the first frame of a packet has 10ms overdue time. Is there an easy way to achieve sending the not-yet-full packets in time? Yes, you should be able to do this by using a subclass (that you would write) of "SimpleRTPSink", and reimplement the virtual function virtual Boolean frameCanAppearAfterPacketStart(unsigned char const* frameStart, unsigned numBytesInFrame) const; This function is called whenever a frame is small enough to fit within an outgoing packet, at other the first position within the frame. By default (in "SimpleRTPSink") this function returns True (because you have presumably created "SimpleRTPSink" with the "allowMultipleFramesPerPacket" parameter set to True (its default value). However, you can redefine this function - in your "SimpleRTPSink" subclass - to return either True or False, depending on whether or not you want to include this frame in this outgoing packet. Now, because "frameCanAppearAfterPacketStart()" is called only for the (potentially) second and subsequent frames within each outgoing packet, you probably don't have enough information to make your decision just by subclassing that function. So you will probably also need to redefine another virtual function - "doSpecialFrameHandling()". That function is called for each frame - regardless of its position within the outgoing packet. You'll probably need to redefine that function - in particular, noting the "fragmentationOffset" parameter. If that parameter is 0, then the frame is the first frame in the outgoing packet; otherwise, it's the second or subsequent frame within the packet. Of course, your subclass's implementation of "doSpecialFrameHandling()" will need to call the base class implementation - i.e. SimpleRTPSink::doSpecialFrameHandling( ... ) at the end. > I think of calling MultiFramedRTPSink::sendPacketIfNecessary() on timer Absolutely not! And you should not even have considered doing this, because that function is "private:", and you know that you're not supposed to modify the supplied code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 30 06:20:32 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Aug 2012 06:20:32 -0700 Subject: [Live-devel] WAV 48Khz 24 bits and VLC strange thing In-Reply-To: References: <0DFB9C7A-63DD-40BD-8BCE-16E88B7C61ED@live555.com> Message-ID: > I can give you an address, but I would like to give it only to you OK, so email the url just to me: finlayson (at) live555.com > Our company records around 160 live concerts a year (video + audio) and the server is dedicated for only the owner of these concerts (musicien, producer, cd editors, ...). The why on earth do you use a "free.fr" email address? Serious professionals do not use email addresses like this. (This is why all of your emails to the mailing list are being moderated; you're using the same kind of email address that would be used by a n00b sitting in his parents' basement :-) As explained clearly in the FAQ: If you want to be taken seriously on this mailing list, you should use a professional email address. > Can you give me an personnal mail so from I will send you the RTSP address of one of our file on this server. No, I don't want a RTSP URL; I want a HTTP URL, so I can download a copy of the file, to use for testing. Don't worry, I promise that I won't distribute it to anyone else. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 30 06:35:33 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Aug 2012 06:35:33 -0700 Subject: [Live-devel] Access violation in StramParser::testBytes() In-Reply-To: <002962EA5927BE45B2FFAB0B5B5D67970A8FAF@SSTSVR1.sst.local> References: <002962EA5927BE45B2FFAB0B5B5D67970A8FAF@SSTSVR1.sst.local> Message-ID: <65855D9B-66F3-49B1-BC6D-D72E77EFB7D3@live555.com> > I have subclassed the OnDemandServerMediaSubsession, and have overridden the createNewStreamSource and createNewRTPSink functions as the FAQ instructs and can successfully receive an MPEG2 Program stream, demux it into an MPEG1or2DemuxedElementaryStream and pass data that into an H264VideoStreamFramer. I'm puzzled by this, because "Program Streams" usually contain only MPEG-1 or MPEG-2 video. This is the first time I've heard of a Program Stream file containing H.264 video. (In fact, I didn't know that anyone used Program Streams anymore; they're pretty much a legacy of the 1990s :-) Anyway, our code was not intended to be used for Program Stream files that contain H.264 data, so it's no surprise that things aren't working for you. If you are sure, however, that this is the kind of file that you are trying to stream, then please post the URL of such a file, so we can download and test it for ourselves (and possibly update our code, as appropriate). > > The above process seems correct, and I can stream the resulting H264 data smoothly to both the openRTSP client (the resulting file is playable) and VLC. The problem I seem to be having is that whenever I disconnect the client application (openRTSP or VLC), the server experiences an Access violation. I have scoured the logs and have found that the TEARDOWN is received by RTSPClientSession and seems to be handled properly, except that the testBytes function (in StreamParser.hh) is referencing an invalid pointer (line: 85 - memmove(to, nextToParse(), numBytes) No, that statement's on line 89, not line 85. (This suggests to me that you've modified the supplied source code. A reminder: If you modify the supplied source code - at all - you can't expect any support.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Aug 30 06:44:00 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Aug 2012 06:44:00 -0700 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <503F5C800200004D000724C4@pta-emo.csir.co.za> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> Message-ID: <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> > 1) The server could of course be made more robust by detecting the '$' char and ignoring such requests. > Would this work as a quick fix? Perhaps. But is this really a problem worth worrying about? If this happens only occasionally (in extreme situations), and merely causes the server to send back a "method not allowed" RTSP response, then is this a major problem? It seems to be merely an 'annoyance'. > 2) The (more correct?) approach would be to only allow the client to send an RR after it has received a PLAY response. Maybe, but that would require a major change to the client code that might break other things - and wouldn't help with existing clients anyway. So I'm not going to go down that route just to deal with a rare issue that - as noted above - appears to be just an annoyance. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Thu Aug 30 07:37:19 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Thu, 30 Aug 2012 16:37:19 +0200 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> Message-ID: <503F96BF0200004D00072533@pta-emo.csir.co.za> > Perhaps. But is this really a problem worth worrying about? If this happens only occasionally (in extreme situations), and merely causes the server to send back a > "method not allowed" RTSP response, then is this a major problem? It seems to be merely an 'annoyance'. We are working on a platform delivering live video to mobile devices in the South African market and in our national infrastructure it occurs frequently. A part of the issue is that e.g. when using VLC on mobile devices as a client, the user does not know that the attempt to play the stream has failed, which is arguably a VLC user interaction issue. But even if this behaviour were detected in the VLC code, it would be hack to re-setup an RTSP session after having received a "method not allowed" from the server so I don't think the issue can be fixed inside VLC. In practice it can take up to 10 attempts to get a playing stream which I would argue is more than an annoyance. > Maybe, but that would require a major change to the client code that might break other things - and wouldn't help with existing clients anyway. So I'm not going to > go down that route just to deal with a rare issue that - as noted above - appears to be just an annoyance. I figured it was a big change, just needed some confirmation from you in case there was a quick fix. It is a real issue though, I am currently working in Germany and when trying to play the stream (RTSP server in South Africa) over my ADSL connection (so not even an edge connection) the same issue occurs most of the time. For us, such a user experience would make the service unusable. I will implement the first suggestion as an intermediary fix then and if it works we will contribute the patch back to live555. Thanks for the input. Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From Viatcheslav.Sysoltsev at h-d-gmbh.de Thu Aug 30 07:57:50 2012 From: Viatcheslav.Sysoltsev at h-d-gmbh.de (Viatcheslav.Sysoltsev at h-d-gmbh.de) Date: Thu, 30 Aug 2012 16:57:50 +0200 Subject: [Live-devel] MultiFramedRTPSink flush collected packet References: <004FFF90-D13F-428F-8BAE-2BD596C80DE8@live555.com> Message-ID: >> The frame may be small, so SimpleRTPSink packs several frames into a >> single packet. That's right, I wish it to do so. I have nevertheless >> troubles to realize, how to make SimpleRTPSink flush its packets in a >> time manner, after for example the first frame of a packet has 10ms >> overdue time. Is there an easy way to achieve sending the not-yet-full >> packets in time? > > Yes, you should be able to do this by using a subclass (that you would > write) of "SimpleRTPSink", and reimplement the virtual function > virtual Boolean frameCanAppearAfterPacketStart(unsigned char const* > frameStart, unsigned numBytesInFrame) const; Thanks, it works like a charm :) -- Slava From owen at metamachine.com Thu Aug 30 09:51:41 2012 From: owen at metamachine.com (owen at metamachine.com) Date: Thu, 30 Aug 2012 09:51:41 -0700 Subject: [Live-devel] Possible bug in H263plusVideoRTPSink.cpp In-Reply-To: <002962EA5927BE45B2FFAB0B5B5D67970A8FAF@SSTSVR1.sst.local> References: <002962EA5927BE45B2FFAB0B5B5D67970A8FAF@SSTSVR1.sst.local> Message-ID: <97a9f71a6b3aced8b22e1cfd1a4b72de.squirrel@www.metamachine.com> I got several complaints from g++ 4.6 while building. This is the second one I'm reporting - because it looks like the casts are not needed. Why are there casts to void* here? 65 if (frameStart[0] != 0 || frameStart[1] != 0) { 66 envir() << "H263plusVideoRTPSink::doSpecialFrameHandling(): unexpected non-zero first two bytes: " 67 << (void*)(frameStart[0]) << "," << (void*)(frameStart[1]) << "\n"; 68 } // Wally Owen From finlayson at live555.com Thu Aug 30 10:45:53 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Aug 2012 10:45:53 -0700 Subject: [Live-devel] Possible bug in H263plusVideoRTPSink.cpp In-Reply-To: <97a9f71a6b3aced8b22e1cfd1a4b72de.squirrel@www.metamachine.com> References: <002962EA5927BE45B2FFAB0B5B5D67970A8FAF@SSTSVR1.sst.local> <97a9f71a6b3aced8b22e1cfd1a4b72de.squirrel@www.metamachine.com> Message-ID: <132DF6C4-B899-42FF-9EA0-7B8652A03BB1@live555.com> > Why are there casts to void* here? Because I want the 'void*' version of "operator<<" to be used, not the 'char*' version. I.e., I want the value to the right of "<<" to be printed as a %p, not as a %s Once again, not all compiler warning messages indicate bugs. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Thu Aug 30 10:50:04 2012 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Thu, 30 Aug 2012 10:50:04 -0700 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> Message-ID: <503FA7CC.7020404@schuckmannacres.com> I actually ran into this very same problem a while back. We had a customer trying to stream live low frame rate/low bit rate video over a slow military 3G cellular network and things weren't working, I can't remember all the details now but either the client or the server was hanging up because of an unexpected response or something like that. It wasn't crashing but things also weren't operational. Eventually I figured out the same thing that Ralf discovered, i.e. that one of the RTCP packets were coming in before the server expected and messing up the server RTSP over TCP parsing code. I have to go back and reproduce the problem to be sure, but I think it was more than a mere annoyance. At the time the customer figured out a work around (I think it was a different network or something like that ) and I didn't have time to figure out a proper fix for the code and I put it on my to do list to report the problem to you Ross. But as often happens with to do lists that item never came up. A fix for this would be appreciated. Matt S. On 8/30/2012 6:44 AM, Ross Finlayson wrote: >> 1) The server could of course be made more robust by detecting the >> '$' char and ignoring such requests. >> Would this work as a quick fix? > > Perhaps. But is this really a problem worth worrying about? If this > happens only occasionally (in extreme situations), and merely causes > the server to send back a "method not allowed" RTSP response, then is > this a major problem? It seems to be merely an 'annoyance'. > > >> 2) The (more correct?) approach would be to only allow the client to >> send an RR after it has received a PLAY response. > > Maybe, but that would require a major change to the client code that > might break other things - and wouldn't help with existing clients > anyway. So I'm not going to go down that route just to deal with a > rare issue that - as noted above - appears to be just an annoyance. > > > 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 finlayson at live555.com Thu Aug 30 11:11:19 2012 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Aug 2012 11:11:19 -0700 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <503F96BF0200004D00072533@pta-emo.csir.co.za> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> Message-ID: <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> > A part of the issue is that e.g. when using VLC on mobile devices as a client Out of curiosity, what VLC iPhone 'app' are you using? 'GoodPlayer'? Or your own custom iOS app? > the user does not know that the attempt to play the stream has failed OK, beforehand you didn't say that this (the server seeing an incoming RTCP-over-TCP '$' 'packet' and responding "Method not allowed") was causing whole connections to fail. I'm curious about why that is happening. Is this because the "Method not allowed" response is being seen as a response to the "PLAY" command (because it's being sent back before the "PLAY" response)? (Because I would have thought that any client that received an arbitrary "Method not allowed" RTSP response after having already received a successful "PLAY" response would be able to handle that OK.) > I will implement the first suggestion as an intermediary fix then and if it > works we will contribute the patch back to live555. Yes, please do. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at metamachine.com Thu Aug 30 13:06:58 2012 From: owen at metamachine.com (owen at metamachine.com) Date: Thu, 30 Aug 2012 13:06:58 -0700 Subject: [Live-devel] Probable bug In-Reply-To: <132DF6C4-B899-42FF-9EA0-7B8652A03BB1@live555.com> References: <002962EA5927BE45B2FFAB0B5B5D67970A8FAF@SSTSVR1.sst.local> <97a9f71a6b3aced8b22e1cfd1a4b72de.squirrel@www.metamachine.com> <132DF6C4-B899-42FF-9EA0-7B8652A03BB1@live555.com> Message-ID: <3aa39a2b9f30aba18eaafe044eaf39ec.squirrel@www.metamachine.com> Sorry about the non-bugs. I've not used that cast trick to see the value as a hex number without having to drag in and use manipulators, but I should have guessed. This one is, I believe, an actual coding error, in the area of order-of-evaluation. In the macro GET_ENCODED_VAL, in VorbisAudioRTPSink.cpp on line 129 (in the 2012.089.30 release), there's a possibly unintended evaluation of the phrase: "n = n*128 + byte&0x7F;" I think, looking at the spacing around the statement, you intended: "n = (n*128) + (byte & 0x7f);" What you're getting is: "n = (n*128 + byte)&0x7f;" // Wally From chris at gotowti.com Thu Aug 30 14:09:34 2012 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Thu, 30 Aug 2012 14:09:34 -0700 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <503FA7CC.7020404@schuckmannacres.com> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503FA7CC.7020404@schuckmannacres.com> Message-ID: <015101cd86f3$c26bc4f0$47434ed0$@com> Hi All, I also have run into this issue on more than one occasion, with customers using relatively high latency DSL or cellular modems. I agree it is more than an annoyance (RTP over RTSP in this case is too unreliable to even use at all) and any kind of fix or workaround would be greatly appreciated. Thanks, Chris Richardson WTI From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Matt Schuckmann Sent: Thursday, August 30, 2012 10:50 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTP over RTSP: client sending RR "early" I actually ran into this very same problem a while back. We had a customer trying to stream live low frame rate/low bit rate video over a slow military 3G cellular network and things weren't working, I can't remember all the details now but either the client or the server was hanging up because of an unexpected response or something like that. It wasn't crashing but things also weren't operational. Eventually I figured out the same thing that Ralf discovered, i.e. that one of the RTCP packets were coming in before the server expected and messing up the server RTSP over TCP parsing code. I have to go back and reproduce the problem to be sure, but I think it was more than a mere annoyance. At the time the customer figured out a work around (I think it was a different network or something like that ) and I didn't have time to figure out a proper fix for the code and I put it on my to do list to report the problem to you Ross. But as often happens with to do lists that item never came up. A fix for this would be appreciated. Matt S. On 8/30/2012 6:44 AM, Ross Finlayson wrote: 1) The server could of course be made more robust by detecting the '$' char and ignoring such requests. Would this work as a quick fix? Perhaps. But is this really a problem worth worrying about? If this happens only occasionally (in extreme situations), and merely causes the server to send back a "method not allowed" RTSP response, then is this a major problem? It seems to be merely an 'annoyance'. 2) The (more correct?) approach would be to only allow the client to send an RR after it has received a PLAY response. Maybe, but that would require a major change to the client code that might break other things - and wouldn't help with existing clients anyway. So I'm not going to go down that route just to deal with a rare issue that - as noted above - appears to be just an annoyance. 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 rglobisch at csir.co.za Thu Aug 30 15:27:05 2012 From: rglobisch at csir.co.za (Ralf Globisch) Date: Fri, 31 Aug 2012 00:27:05 +0200 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> Message-ID: <504004D90200004D0007257E@pta-emo.csir.co.za> > Out of curiosity, what VLC iPhone 'app' are you using? 'GoodPlayer'? Or > your own custom iOS app? Actually, it's an Android application based on the Android port of VLC. > OK, beforehand you didn't say that this (the server seeing an incoming > RTCP-over-TCP '$' 'packet' and responding "Method not allowed") was causing > whole connections to fail. I'm curious about why that is happening. Is this > because the "Method not allowed" response is being seen as a response to the > "PLAY" command (because it's being sent back before the "PLAY" response)? Yes, exactly, a colleague actually found the issue when he ran a network trace: FYI: OPTIONS rtsp://mss-build.dhcp/shebeen.mm1 RTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2012.08.12) RTSP/1.0 200 OK CSeq: 2 Date: Wed, Aug 22 2012 15:05:55 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER DESCRIBE rtsp://mss-build.dhcp/shebeen.mm1 RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2012.08.12) Accept: application/sdp RTSP/1.0 200 OK CSeq: 3 Date: Wed, Aug 22 2012 15:05:57 GMT Content-Base: rtsp://xxx.xxx.xxx.xxx/shebeen.mm1/ Content-Type: application/sdp Content-Length: 552 v=0 o=- 1345634589003910 1 IN IP4 xxx.xxx.xxx.xxx s=Session streamed by "MSS" i=shebeen.mm1 t=0 0 a=tool:LIVE555 Streaming Media v2011.10.09 a=type:broadcast a=control:* a=source-filter: incl IN IP4 * xxx.xxx.xxx.xxx a=rtcp-unicast: reflection a=range:npt=0- a=x-qt-text-nam:Session streamed by "MSS" a=x-qt-text-inf:shebeen.mm1 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:24000 a=rtpmap:96 H263-1998/90000 a=control:track1 m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:128 a=rtpmap:97 AMR/8000 a=fmtp:97 octet-align=1 a=control:track2 SETUP rtsp://xxx.xxx.xxx.xxx/shebeen.mm1/track1 RTSP/1.0 CSeq: 4 User-Agent: ./openRTSP (LIVE555 Streaming Media v2012.08.12) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 RTSP/1.0 200 OK CSeq: 4 Date: Wed, Aug 22 2012 15:05:59 GMT Transport: RTP/AVP/TCP;unicast;destination=146.64.19.76;source=xxx.xxx.xxx.xxx;interleaved=0-1 Session: 078333B5 SETUP rtsp://xxx.xxx.xxx.xxx/shebeen.mm1/track2 RTSP/1.0 CSeq: 5 User-Agent: ./openRTSP (LIVE555 Streaming Media v2012.08.12) Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 078333B5 RTSP/1.0 200 OK CSeq: 5 Date: Wed, Aug 22 2012 15:06:01 GMT Transport: RTP/AVP/TCP;unicast;destination=146.64.19.76;source=xxx.xxx.xxx.xxx;interleaved=2-3 Session: 078333B5 $.....................ljjoubert.PLAY rtsp://xxx.xxx.xxx.xxx/shebeen.mm1/ RTSP/1.0 CSeq: 6 User-Agent: ./openRTSP (LIVE555 Streaming Media v2012.08.12) Session: 078333B5 Range: npt=0.000- RTSP/1.0 405 Method Not Allowed CSeq: 6 Date: Wed, Aug 22 2012 15:06:05 GMT Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER TEARDOWN rtsp://xxx.xxx.xxx.xxx/shebeen.mm1/ RTSP/1.0 CSeq: 7 User-Agent: ./openRTSP (LIVE555 Streaming Media v2012.08.12) Session: 078333B5 RTSP/1.0 200 OK CSeq: 7 Date: Wed, Aug 22 2012 15:06:07 GMT $.....................ljjoubert.$.......k..A....k..A..ljjoubert.$...................$.......k..A....k..A -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From Shaheed at scansoft.co.za Fri Aug 31 04:45:59 2012 From: Shaheed at scansoft.co.za (Shaheed Abdol) Date: Fri, 31 Aug 2012 13:45:59 +0200 Subject: [Live-devel] Access violation in StramParser::testBytes() In-Reply-To: <002962EA5927BE45B2FFAB0B5B5D67970A8FAF@SSTSVR1.sst.local> References: <002962EA5927BE45B2FFAB0B5B5D67970A8FAF@SSTSVR1.sst.local> Message-ID: <002962EA5927BE45B2FFAB0B5B5D67970A8FC1@SSTSVR1.sst.local> Good morning Ross, You are indeed correct: Program streams are a big "no-no" for any streaming situation, and I believe it's a testament to the robust, flexible design of the live555 library for it to recognize and correctly demux the stream. Unfortunately this is the constraint I have been given - we are fetching footage from a SecureWise DVR which only supports very limited encodings - all of which are encapsulated in an MPEG2 program stream. I have a link to the file: https://rapidshare.com/files/2840761585/MP2(PS)-H264.mp4 I have updated (again) to the 30 August version of live555, I had been testing with the previous version, compiled it and have run the same tests - with much better success, disconnecting from a stream no longer causes a crash. The stream plays erratically though (sporadically gets stuck on one frame for a few seconds), which the previous version did not do. One last note: The line numbers I quoted were incorrect because of a few #pragma directives which were automatically added to the top of all includes (mostly for cross-platform compilation)- I have replaced those with the unmodified versions and recompiled. Thank you Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 31 05:14:55 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Aug 2012 05:14:55 -0700 Subject: [Live-devel] Access violation in StramParser::testBytes() In-Reply-To: <002962EA5927BE45B2FFAB0B5B5D67970A8FC1@SSTSVR1.sst.local> References: <002962EA5927BE45B2FFAB0B5B5D67970A8FAF@SSTSVR1.sst.local> <002962EA5927BE45B2FFAB0B5B5D67970A8FC1@SSTSVR1.sst.local> Message-ID: <702049CD-CCE2-4CF6-A549-166A119E4EDF@live555.com> > You are indeed correct: Program streams are a big "no-no" for any streaming situation, and I believe it's a testament to the robust, flexible design of the live555 library for it to recognize and correctly demux the stream. Unfortunately this is the constraint I have been given - we are fetching footage from a SecureWise DVR which only supports very limited encodings - all of which are encapsulated in an MPEG2 program stream. > > I have a link to the file: https://rapidshare.com/files/2840761585/MP2(PS)-H264.mp4 FYI, you should not be using the filename suffix ".mp4" for these files, because that filename suffix is usually used for ISO MPEG-4 format files (which our software currently does not support, BTW). Instead, you should always use ".mpg" for Program Stream files. Note, BTW, that if I rename your file to "MP2(PS)-H264.mpg", QuickTimePlayer will play it. I'll take a look at whether I can handle this type of file (Program Stream files containing H.264 video) more directly in the LIVE555 code. > I have updated (again) to the 30 August version of live555, I had been testing with the previous version, compiled it and have run the same tests - with much better success, disconnecting from a stream no longer causes a crash. Attention everybody: If you're having problems with the LIVE555 code, then the *first* thing you should do is check whether you have the most up-to-date version! > The stream plays erratically though (sporadically gets stuck on one frame for a few seconds), which the previous version did not do. That's strange, because there have not been changes to the Program Stream demultiplexing code for several years... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 31 05:34:20 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Aug 2012 05:34:20 -0700 Subject: [Live-devel] Probable bug In-Reply-To: <3aa39a2b9f30aba18eaafe044eaf39ec.squirrel@www.metamachine.com> References: <002962EA5927BE45B2FFAB0B5B5D67970A8FAF@SSTSVR1.sst.local> <97a9f71a6b3aced8b22e1cfd1a4b72de.squirrel@www.metamachine.com> <132DF6C4-B899-42FF-9EA0-7B8652A03BB1@live555.com> <3aa39a2b9f30aba18eaafe044eaf39ec.squirrel@www.metamachine.com> Message-ID: <1BCFC8E7-CAF2-47EE-8ABF-14521DCB893F@live555.com> > This one is, I believe, an actual coding error, in the area of > order-of-evaluation. > > In the macro GET_ENCODED_VAL, in VorbisAudioRTPSink.cpp on line 129 (in > the 2012.089.30 release), there's a possibly unintended evaluation of the > phrase: > > "n = n*128 + byte&0x7F;" > > I think, looking at the spacing around the statement, you intended: > > "n = (n*128) + (byte & 0x7f);" > > What you're getting is: > > "n = (n*128 + byte)&0x7f;" Yes, thanks. This bug is fixed in the latest release (2012.08.31) of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 31 05:40:17 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Aug 2012 05:40:17 -0700 Subject: [Live-devel] WAV 48Khz 24 bits and VLC strange thing In-Reply-To: References: Message-ID: > If I put the cursor before (let's say 30 minutes) , VLC plays it well and the streaming continues to be ok, even after 31:06. > > I suppose there is a trouble about seeking in the file when the time requested is above 31:06... FYI, this bug should be fixed in the latest release (2012.08.31) of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Aug 31 06:23:05 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Aug 2012 06:23:05 -0700 Subject: [Live-devel] RTP over RTSP: client sending RR "early" In-Reply-To: <504004D90200004D0007257E@pta-emo.csir.co.za> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> Message-ID: OK, thanks for the RTSP protocol trace that illustrates the problem. I've changed my mind on this: I now think it should be relatively straightforward to fix the RTSP client code so that it no longer sends out these early RTCP 'RR' packets (when streaming RTP-over-TCP). This will be better than adding an ugly hack to the server code. This means, however, that you will need to upgrade your clients (something that you should really be doing anyway :-) Once I've updated the code (with this RTSP client code fix), I'll let you know). Stay tuned... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Fri Aug 31 12:06:09 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Fri, 31 Aug 2012 19:06:09 +0000 Subject: [Live-devel] Re-connection handling In-Reply-To: References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> Message-ID: Best possible uptime is essential for the RTSP client I'm implementing. I've therefore looked into how to best handle reconnection if the stream for any reason is disconnected. I noticed fairly quickly that liveMedia is taking care of that really good and there is no reason for me to try to implement any general disconnect handling, as I can't possible reconnect any faster than liveMedia already does. There is one case where it doesn't work though, and I'm not sure how to handle it. This is if I do a seek while the stream is disconnected, then it never reconnects. In some cases I play a 10s loop where a timer do a seek every 10s and jumps back (using absolute seeking). Those streams never reconnect after a disconnection. I see a few alternatives: 1. I continuously try to reconnect myself, but I don't want to mess up liveMedia's reconnection handling, so not sure how to detect when I should handle a disconnect myself. 2. Make sure I don't issue a seek, or any PLAY-command (i.e. call sendPlayCommand()) when the stream is down. Is there a status flag I can check somewhere to determine this? 3. Look at the reconnect-handling in liveMedia. No idea what could be done to make sure the re-connect functionality isn't disrupted, but maybe buffer the PLAY-commands until they can be performed, or just discard them. Any comments would be appreciated. Can anyone confirm that my theories are correct, i.e. that a stream doesn't reconnect if a PLAY-command is issued while the stream is down? /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: 5740 bytes Desc: not available URL: From finlayson at live555.com Fri Aug 31 14:27:13 2012 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Aug 2012 14:27:13 -0700 Subject: [Live-devel] Re-connection handling In-Reply-To: References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> Message-ID: <4EE959A2-046E-46BD-9951-FB3279CBCA89@live555.com> > I've therefore looked into how to best handle reconnection if the stream for any reason is disconnected. I noticed fairly quickly that liveMedia is taking care of that really good and there is no reason for me to try to implement any general disconnect handling, as I can't possible reconnect any faster than liveMedia already does. Agreed. > There is one case where it doesn't work though, and I'm not sure how to handle it. This is if I do a seek while the stream is disconnected, then it never reconnects. In some cases I play a 10s loop where a timer do a seek every 10s and jumps back (using absolute seeking). Those streams never reconnect after a disconnection. > OK, so unless you can tell me a reliable way to reproduce this problem (perhaps using "openRTSP), then you'll need to figure out yourself why the LIVE555 library's connection reestablishment code is not working in this case (and then I'll try to fix it). Remember, You Have Complete Source Code. The place to look in the code is near the start of "RTSPClient::sendRequest()" (line 535 of "liveMedia/RTSPClient.cpp"). When you do your 'seek' (really "PLAY") operation (that's failing), then is "fInputSocketNum" <0? If so, then what value does "openConnection()" return. If, however, "fInputSocketNum" is >= 0 (in practice, it will be >0), then we will (eventually) call "send()" (at line 787) to transmit the command. Is this "send()" call succeeding, or not? > I see a few alternatives: No, there's only one 'alternative': Figure out why the LIVE55 code is (apparently) failing in this case, so I can fix the problem. Trying instead to work around this problem yourself might help you in the short term, but wouldn't help anyone else. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From CERLANDS at arinc.com Fri Aug 31 14:58:28 2012 From: CERLANDS at arinc.com (Erlandsson, Claes P (CERLANDS)) Date: Fri, 31 Aug 2012 21:58:28 +0000 Subject: [Live-devel] Re-connection handling In-Reply-To: <4EE959A2-046E-46BD-9951-FB3279CBCA89@live555.com> References: <503F5C800200004D000724C4@pta-emo.csir.co.za> <65360213-B62D-4142-A9C3-FCDA5050A963@live555.com> <503F96BF0200004D00072533@pta-emo.csir.co.za> <796437FE-D307-4AAA-BAC3-685E6B667417@live555.com> <504004D90200004D0007257E@pta-emo.csir.co.za> <4EE959A2-046E-46BD-9951-FB3279CBCA89@live555.com> Message-ID: There is one case where it doesn't work though, and I'm not sure how to handle it. This is if I do a seek while the stream is disconnected, then it never reconnects. In some cases I play a 10s loop where a timer do a seek every 10s and jumps back (using absolute seeking). Those streams never reconnect after a disconnection. OK, so unless you can tell me a reliable way to reproduce this problem (perhaps using "openRTSP), then you'll need to figure out yourself why the LIVE555 library's connection reestablishment code is not working in this case (and then I'll try to fix it). Remember, You Have Complete Source Code. The place to look in the code is near the start of "RTSPClient::sendRequest()" (line 535 of "liveMedia/RTSPClient.cpp"). When you do your 'seek' (really "PLAY") operation (that's failing), then is "fInputSocketNum" <0? If so, then what value does "openConnection()" return. If, however, "fInputSocketNum" is >= 0 (in practice, it will be >0), then we will (eventually) call "send()" (at line 787) to transmit the command. Is this "send()" call succeeding, or not? I don't believe there is a loop functionality in openRTSP, so I can't think of a way to recreate it there. In simple words, what I do is: 1. Play a non-live stream. 2. Pull the plug on the server side (shouldn't matter if client side though), and put it back. 3. Do one, or many, seek (PLAY-command using absolute time) on the stream while not connected. 4. When connection works again, the stream will not continue, while other streams will. I will do some testing and look up the lines you're referring to. Will get back when I've some answers for you. I see a few alternatives: No, there's only one 'alternative': Figure out why the LIVE55 code is (apparently) failing in this case, so I can fix the problem. Trying instead to work around this problem yourself might help you in the short term, but wouldn't help anyone else. I of course totally agree on that. Guess I considered that it potentially could be a known issue that was hard to fix. /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: 5740 bytes Desc: not available URL: From tbatra18 at gmail.com Fri Aug 31 05:34:24 2012 From: tbatra18 at gmail.com (Tarun Batra) Date: Fri, 31 Aug 2012 18:04:24 +0530 Subject: [Live-devel] RTSP Server Problem Message-ID: Hello ~ Sir i made an RTSP client,it works when first time the request is made to RTSP SERVER(made from your code .i.e.test on demand rtsp server.cpp) over TCP Protocol. But there is a problem that when i close the socket through which i have made the TCP socket connection with server and again open the socket after 30seconds the data is get from the server is at very slow rate for some time(30 seconds). Before closing the socket connection with the RTSP server i am sending the "TEARDOWN" Request and when i re-open the socket again after 30 or more than 30 seconds,i make a "SETUP","PLAY" request. There is no problem if we continuously open the socket,receive data and close the socket without any delay in open and closing the socket Thanks Tarun -------------- next part -------------- An HTML attachment was scrubbed... URL: