From pan_xiaolei at sina.com Sat Sep 1 04:26:58 2007 From: pan_xiaolei at sina.com (pan_xiaolei) Date: Sat, 1 Sep 2007 19:26:58 +0800 Subject: [Live-devel] memory leak? some questions References: Message-ID: <200709011926582554152@sina.com> I was puzzled when I'v read the following code: OnDemandServerMediaSubsession.cpp:447 StreamState::startPlaying() if (dests- >isTCP) { // Change RTP and RTCP to use the TCP socket instead of UDP: if (fRTPSink != NULL) { fRTPSink- >addStreamSocket(dests- >tcpSocketNum, dests- >rtpChannelId); } if (fRTCPInstance != NULL) { fRTCPInstance- >addStreamSocket(dests- >tcpSocketNum, dests- >rtcpChannelId); fRTCPInstance- >setSpecificRRHandler(dests- >tcpSocketNum, dests- >rtcpChannelId, rtcpRRHandler, rtcpRRHandlerClientData); } } else { // Tell the RTP and RTCP 'groupsocks' about this destination // (in case they don't already have it): if (fRTPgs != NULL) fRTPgs- >addDestination(dests- >addr, dests- >rtpPort); if (fRTCPgs != NULL) fRTCPgs- >addDestination(dests- >addr, dests- >rtcpPort); if (fRTCPInstance != NULL) { fRTCPInstance- >setSpecificRRHandler(dests- >addr.s_addr, dests- >rtcpPort, rtcpRRHandler, rtcpRRHandlerClientData); } } 1) why we have make sure the fRTPSink, fRTCPInstance, fRTPgs, fRTCPgs is not NULL. After the SETUP, all of them must have been allocated. 2) why not use fRTPSink and fRTCPInstance to instead of the fRTPgs and fRTCPgs when call addDestination? In my opionion, as the fRTPgs and fRTCPgs has been encapsulated into the fRTPSink and fRTCPInstance, they should be managed by the fRTPSink and fRTCPInstance only. I think the code "fRTPSink- >addDestination() fRTCPInstance - >addDestination()" may be more easily to understand, don't you? OnDemandServerMediaSubsession.cpp:200 StreamState::getStreamParameters() for (portNumBits serverPortNum = fInitialPortNum; ; serverPortNum += 2) { struct in_addr dummyAddr; dummyAddr.s_addr = 0; serverRTPPort = serverPortNum; rtpGroupsock = new Groupsock(envir(), dummyAddr, serverRTPPort, 255); if (rtpGroupsock- >socketNum() < 0) { delete rtpGroupsock; continue; // try again } serverRTCPPort = serverPortNum+1; rtcpGroupsock = new Groupsock(envir(), dummyAddr, serverRTCPPort, 255); if (rtcpGroupsock- >socketNum() < 0) { delete rtcpGroupsock; continue; // try again } break; // success } 1) As more and more client has connected to the server, the available port of the system may be very few. At that time, the searching for a pair of available port will become a block operation, which will affect to complete other requests effectively. 2) Consider the following scene: the port, 6640, 6642 and 6643, are free ports. The rtpSocket will be happy when she finds the 6640 is a free port, but the rtcpSocket will be unhappy, because 6641 has been ocupied for some reason. Then the loop continue, while the rtcpSocket is freed and rtpSocke is still allocated, MEMORY LEAK! David Pan 2007-09-01 From finlayson at live555.com Sat Sep 1 07:10:25 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 1 Sep 2007 07:10:25 -0700 Subject: [Live-devel] memory leak? some questions In-Reply-To: <200709011926582554152@sina.com> References: <200709011926582554152@sina.com> Message-ID: >1) why we have make sure the fRTPSink, fRTCPInstance, fRTPgs, >fRTCPgs is not NULL. After the SETUP, all of them must have been >allocated. No, not necessarily. If we are streaming via raw UDP (instead of via RTP/UDP), then "fRTPSink" and "fRTCPInstance" will be NULL (with "fUDPSink" being non-NULL). >2) why not use fRTPSink and fRTCPInstance to instead of the fRTPgs >and fRTCPgs when call addDestination? For the same reason. If we're streaming via raw UDP, then "fRTPSink" and "fRTCPInstance" will be NULL, but "fRTPgs" (in this case somewhat misnamed, because it won't be used for RTP) will not be NULL. >1) As more and more client has connected to the server, the >available port of the system may be very few. At that time, the >searching for a pair of available port will become a block >operation, which will affect to complete other requests effectively. No, the allocation of sockets is a non-blocking operation. >2) Consider the following scene: > the port, 6640, 6642 and 6643, are free ports. The rtpSocket will >be happy when she finds the 6640 is a free port, but the rtcpSocket >will be unhappy, because 6641 has been ocupied for some reason. Then >the loop continue, while the rtcpSocket is freed and rtpSocke is >still allocated, MEMORY LEAK! Yes, you're correct. The second "if" statement should contain delete rtpGroupsock; in addition to delete rtcpGroupsock; Thanks for reporting this; this will be fixed in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From pan_xiaolei at sina.com Sat Sep 1 23:04:50 2007 From: pan_xiaolei at sina.com (pan_xiaolei) Date: Sun, 2 Sep 2007 14:04:50 +0800 Subject: [Live-devel] RTSP over TCP References: Message-ID: <200709021404499298221@sina.com> Hi, When I use the realplayer to receive AV data from live555, I find the player will terminate the stream after 44mins' palying(I force the realplayer to use TCP only). I find the realplayer will send a OPTION to the server every 45 mininute, after analyzing the sniffer data: 1407 45.051016 192.168.1.2 192.168.1.101 RTP Payload type=MPEG-I/II Audio, SSRC=2140963863, Seq=60198, Time=3510955047 1408 45.056088 192.168.1.101 192.168.1.2 RTSP OPTIONS rtsp://192.168.1.2:8554/test.mp3 RTSP/1.0 1447 90.059581 192.168.1.101 192.168.1.2 RTSP OPTIONS rtsp://192.168.1.2:8554/test.mp3 RTSP/1.0 1449 92.549210 192.168.1.101 192.168.1.2 RTSP TEARDOWN rtsp://192.168.1.2:8554/test.mp3 RTSP/1.0 1451 92.549587 192.168.1.101 192.168.1.2 RTCP Receiver Report My question is how can I processs the RTSP while the server is receiving the RTCP. Must I modify the following code to deal with this? RTPInterface.cpp:292 SocketDescriptor::registerRTPInterface() if (isFirstRegistration) { // Arrange to handle reads on this TCP socket: TaskScheduler::BackgroundHandlerProc* handler = (TaskScheduler::BackgroundHandlerProc*)&tcpReadHandler; fEnv.taskScheduler(). turnOnBackgroundReadHandling(fOurSocketNum, handler, this); } BTW, VLC is perfect to deal with this, but i also wish the realplayer be OK. David Pan 2007-09-02 From finlayson at live555.com Sun Sep 2 01:47:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 2 Sep 2007 01:47:20 -0700 Subject: [Live-devel] RTSP over TCP In-Reply-To: <200709021404499298221@sina.com> References: <200709021404499298221@sina.com> Message-ID: >My question is how can I processs the RTSP while the server is >receiving the RTCP. Our current server implementation of RTP-over-RTSP does not handle any RTSP commands after "PLAY". Sorry. However, if your ciient is sending RTCP "RR" reports - which it should be - then those will be counted by the server as indicating client 'liveness'. >BTW, VLC is perfect to deal with this, but i also wish the realplayer be OK. RealPlayer is notoriously buggy, and has not been considered a serious application for many years. VLC (or QuickTime Player) is much better. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Ambra.Cristaldi at elsagdatamat.com Tue Sep 4 02:04:21 2007 From: Ambra.Cristaldi at elsagdatamat.com (Cristaldi Ambra) Date: Tue, 4 Sep 2007 11:04:21 +0200 Subject: [Live-devel] stream of audio/video separated files (corrected version) Message-ID: <268315E5844A704AB431589863FE8EEFC63C43@els00wmx04.elsag.it> Dear Ross, Thank you for replaying. About my last questions a) b), I read this thread http://lists.live555.com/pipermail/live-devel/2006-June/004556.html, and the FAQ (http://www.live555.com/openRTSP/#quicktime , http://www.live555.com/liveMedia/faq.html#m4e-file ). So, my doubts are: 1. I use the test program (openRTSP) of liveMedia, the server is DSS. I use the follow command line: ./openRTSP rtsp://xxx.xxx.xxx.xxx/sample_100kbit.mp4 and I obtain two files: "video-MP4V-ES-1" and "audio-MPEG4-GENERIC-2". If I rename the video one with the ".m4e" extension, I can't open it (I use VLC player). How can I see it in local? And at the same way, how can I open the audio one? I also tried to rename it as "test.aac" and stream it with "testOnDemandRTSP.exe" application, but it doesn't seem to work. 2. Then, I use the test program (openRTSP) of liveMedia, the server is DSS. I use the follow command line: ./openRTSP -4 rtsp://xxx.xxx.xxx.xxx/sample_100kbit.mp4 > test.mp4, but I obtain an empty file. What's wrong? Thank you so much. Ambra. ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: venerd? 31 agosto 2007 14.41 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] stream of audio/video separated files (corrected version) c) Is it possible to merge the audio and video files to a unique mpeg4 file and play it locally (not stream)? Yes, using the "-4" option to "openRTSP". Read the "openRTSP" online documentation. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ Hi Ross, I've got a couple of questions about stream of .m4e files: a) I've read all the FAQ and, as described there, I've tried the OpenRTSP to receive an mpeg4 file via RTSP, from a Darwin Streaming Server and record it. As described in the FAQ (http://www.live555.com/liveMedia/faq.html#separate-rtp-streams, http://www.live555.com/liveMedia/faq.html#m4e-file) I obtained two files, an audio one and a video one, but I can't open them. I've tried both with VLC and QuickTime. Can I play them locally? How? Which is the correct extension for the audio files? b) I try with the "testOnDemandRTSPServer.exe" and "testVideoStreamMPEG4.exe" applications to stream the video file (after renamed it with .m4e extension), I try to see it with VLC, and it works fine. How can I stream the audio too? I try with the other tests but they don't seem to work. c) Is it possible to merge the audio and video files to a unique mpeg4 file and play it locally (not stream)? d) I've read in this 3d your opinion about streaming m4e files (http://lists.live555.com/pipermail/live-devel/2007-August/007304.html), but I think this is the only way to stream mpeg4 files, isn't it? I mean: I stream from a device with OpenRTSP, I obtain the two separate files (audio and video) and, if I wish to stream them again, I can do it only using ".m4e" extension. Is it right? Thanks in advance, Ambra -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070904/6fc2501d/attachment-0001.html From Tomy.Joseph at lntinfotech.com Tue Sep 4 03:24:33 2007 From: Tomy.Joseph at lntinfotech.com (Tomy Joseph) Date: Tue, 4 Sep 2007 15:54:33 +0530 Subject: [Live-devel] Multicast_Problem Message-ID: Hi... I tried to deliver audio&video streams on multicast IP(224.0.0.1) by using live555 media server . I have selected rtp client ports 3456 for video & 3458 for audio.Then I started RTSP session between live555 Media server & client by using openRTSP command. Also I set the multicast IP & port on VLC player. But in VLC I found that I cannot set two ports on a single VLC player. If I set port as 3456 ,VLC plays only video & on port 3458 only audio. So is there any provision on live555 Mdia server to play audio&video on a single port or is there any other player ,which can play both audio & video on multicast IP?? Tomy P. Joseph Samsung ODC, L&T Infotech,Plot No. 25-30, EPIP I Phase Industrial Area, Whitefield,Bangalore-66. Mobile: +919448856102 Fax:+91-80-8525233. ( ) L&T Infotech Proprietary & Confidential ( ) L&T Infotech Confidential (+) L&T Infotech Internal Use only ( ) General Business Information Larsen & Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070904/b1ec1c28/attachment.html From vrushali at johotech.co.in Tue Sep 4 03:38:59 2007 From: vrushali at johotech.co.in (Vrushali Nandanwar) Date: Tue, 4 Sep 2007 16:08:59 +0530 Subject: [Live-devel] Multicast_Problem In-Reply-To: References: Message-ID: <000c01c7eedf$ce505f80$0adfdfdf@JTS10> Hi, I am also working on the same openrtsp program. I tried to establish a connection, but connectin fails at while sending the option request //Begin by sending an "OPTIONS" command: Can anybody please guide what is going to wrong to establish connection. Regards Vrushali Senior Embedded Engineer Johotech Solutions Pvt Ltd Mumbai India _____ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Tomy Joseph Sent: Tuesday, September 04, 2007 3:55 PM To: live-devel at ns.live555.com Subject: [Live-devel] Multicast_Problem Hi... I tried to deliver audio&video streams on multicast IP(224.0.0.1) by using live555 media server . I have selected rtp client ports 3456 for video & 3458 for audio.Then I started RTSP session between live555 Media server & client by using openRTSP command. Also I set the multicast IP & port on VLC player. But in VLC I found that I cannot set two ports on a single VLC player. If I set port as 3456 ,VLC plays only video & on port 3458 only audio. So is there any provision on live555 Mdia server to play audio&video on a single port or is there any other player ,which can play both audio & video on multicast IP?? Tomy P. Joseph Samsung ODC, L&T Infotech,Plot No. 25-30, EPIP I Phase Industrial Area, Whitefield,Bangalore-66. Mobile: +919448856102 Fax:+91-80-8525233. ( ) L&T Infotech Proprietary & Confidential ( ) L&T Infotech Confidential (+) L&T Infotech Internal Use only ( ) General Business Information Larsen & Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070904/31d86771/attachment.html From finlayson at live555.com Tue Sep 4 05:14:31 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Sep 2007 05:14:31 -0700 Subject: [Live-devel] Multicast_Problem In-Reply-To: References: Message-ID: >I tried to deliver audio&video streams on multicast IP(224.0.0.1) by >using live555 media server . The "live555MediaServer" application streams using unicast only, not multicast. If you want to stream via multicast, then you should use one of the "test*Streamer" demo applications (contained in the "testProgs" directory). >I started RTSP session between live555 Media server & client by >using openRTSP command. Also I set the multicast IP & port on VLC >player. I don't understand this. Why not just use VLC (not "openRTSP") as your RTSP client. I.e., enter the "rtsp://..." URL into VLC? Then it should be able to play the stream OK. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070904/0d198ecf/attachment.html From finlayson at live555.com Tue Sep 4 05:24:01 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Sep 2007 05:24:01 -0700 Subject: [Live-devel] stream of audio/video separated files (corrected version) In-Reply-To: <268315E5844A704AB431589863FE8EEFC63C43@els00wmx04.elsag.it> References: <268315E5844A704AB431589863FE8EEFC63C43@els00wmx04.elsag.it> Message-ID: >1. I use the test program (openRTSP) of liveMedia, the server is >DSS. I use the follow command line: ./openRTSP > rtsp://xxx.xxx.xxx.xxx/sample_100kbit.mp4 >and I obtain two files: "video-MP4V-ES-1" and >"audio-MPEG4-GENERIC-2". Are these files both non-empty? If these files are both empty, then that shows that you are not receiving RTP packets from your server, most likely because you have a firewall - between the client and the server - that is bocking RTP packets. In that case, either fix your firewall, or use the "-t" option to openRTSP, to request RTP-over-TCP streaming. >If I rename the video one with the ".m4e" extension, I can't open it >(I use VLC player). How can I see it in local? You can't. VLC cannot play MPEG-4 video Elementary Stream files. > And at the same way, how can I open the audio one? You can't. VLC cannot PLAY MPEG-4 audio (AAC) Elementary Stream files. However, VLC *should* be able to play the stream directly - i.e., enter the "rtsp://..." URL directly into VLC, and don't use "openRTSP" at all. > I also tried to rename it as "test.aac" and stream it with >"testOnDemandRTSP.exe" application, but it doesn't seem to work. That won't work, because the file was not in ADTS format. >2. Then, I use the test program (openRTSP) of liveMedia, the >server is DSS. I use the follow command line: ./openRTSP -4 >rtsp://xxx.xxx.xxx.xxx/sample_100kbit.mp4 > >test.mp4, but I obtain an empty file. What's wrong? When using the "-4" option, you need to make sure that the stream runs all the way through. You can't just -c it. You should also use the "-w", "-h" and "-f" options. If you are still not receiving any data, then - as noted above - you are probably behind a firewall. If so, then add the "-t" option. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070904/be551733/attachment-0001.html From Tomy.Joseph at lntinfotech.com Wed Sep 5 03:33:13 2007 From: Tomy.Joseph at lntinfotech.com (Tomy Joseph) Date: Wed, 5 Sep 2007 16:03:13 +0530 Subject: [Live-devel] Multicast_Problem In-Reply-To: Message-ID: Hi... I can't able to play the mpeg video in VLC player when I started testMPEG1or2AudioVideoStreamer(I have enabled the compiler flag IMPLEMENT_RTSP_SERVER in code) . I have specified rtsp url on VLC(with multicast address) and started.Also I tried with the IP address of the host on which I am running testMPEG1or2AudioVideoStreamer. can u kindly explain me if any other settings is requered on VLC or shall I need to invoke any other application ... Tomy P. Joseph Samsung ODC, L&T Infotech,Plot No. 25-30, EPIP I Phase Industrial Area, Whitefield,Bangalore-66. Mobile: +919448856102 Fax:+91-80-8525233. ( ) L&T Infotech Proprietary & Confidential ( ) L&T Infotech Confidential (+) L&T Infotech Internal Use only ( ) General Business Information Larsen & Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070905/5cce0ef1/attachment.html From finlayson at live555.com Wed Sep 5 07:13:50 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Sep 2007 07:13:50 -0700 Subject: [Live-devel] Multicast_Problem In-Reply-To: References: Message-ID: >Hi... > >I can't able to play the mpeg video in VLC player when I started >testMPEG1or2AudioVideoStreamer(I have enabled the compiler flag >IMPLEMENT_RTSP_SERVER in code) . I have specified rtsp url on >VLC(with multicast address) NO! The "rtsp://" URL does *not* contain the multicast address. The correct "rtsp://" URL will be displayed by "testMPEG1or2AudioVideoStreamer" (on its stderr output) when it starts out. Use that. If it still doesn't work, then make sure that 1/ Your file "test.mpg" is really a MPEG-1 or 2 Program Stream file, and 2/ Your client (VLC) is on the same LAN as the server (testMPEG1or2AudioVideoStreamer), or, if not, there is IP multicast routing set up between the server and client networks. If you don't have multicast routing between your server and client networks, then you will need to use unicast streaming ("testOnDemandRTSPServer" or "live555MediaServer") instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070905/9aa592c2/attachment.html From Tomy.Joseph at lntinfotech.com Wed Sep 5 22:52:32 2007 From: Tomy.Joseph at lntinfotech.com (Tomy Joseph) Date: Thu, 6 Sep 2007 11:22:32 +0530 Subject: [Live-devel] Multicast_Problem In-Reply-To: Message-ID: hi... I tried the way in which you suggested...I have a Mpeg file test.mpg 1. start ./testMPEG1or2AudioVideoStreamer ==> Displays Play this stream using the URL "rtsp://172.28.7.17/testStream" Beginning streaming... Beginning to read from file... 2. Open Vlc player & put "rtsp://172.28.7.17/testStream" (also "rtsp://172.28.7.17/test.mpg")in RTSP option on Open Network Stream. But nothing is playing.. When I tried with testOnDemandRTSPServer & live555MediaServer it isworking.. Tomy P. Joseph Samsung ODC, L&T Infotech,Plot No. 25-30, EPIP I Phase Industrial Area, Whitefield,Bangalore-66. Mobile: +919448856102 Fax:+91-80-8525233. ( ) L&T Infotech Proprietary & Confidential ( ) L&T Infotech Confidential (+) L&T Infotech Internal Use only ( ) General Business Information Larsen & Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070905/b1a07e0f/attachment.html From finlayson at live555.com Wed Sep 5 23:05:54 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Sep 2007 23:05:54 -0700 Subject: [Live-devel] Multicast_Problem In-Reply-To: References: Message-ID: >hi... > >I tried the way in which you suggested...I have a Mpeg file test.mpg >1. start ./testMPEG1or2AudioVideoStreamer >==> Displays >Play this stream using the URL "rtsp://172.28.7.17/testStream" >Beginning streaming... >Beginning to read from file... >2. Open Vlc player & put "rtsp://172.28.7.17/testStream" That should work, *if* you have multicast routing between your server and client networks. >(also "rtsp://172.28.7.17/test.mpg") But that won't work (because that's not the URL that the program prints out!) >in RTSP option on Open Network Stream. >But nothing is playing.. I suspect that you don't have multicast routing between your server and client networks. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070905/b0dcd2df/attachment.html From Tomy.Joseph at lntinfotech.com Wed Sep 5 23:40:34 2007 From: Tomy.Joseph at lntinfotech.com (Tomy Joseph) Date: Thu, 6 Sep 2007 12:10:34 +0530 Subject: [Live-devel] Multicast_Problem In-Reply-To: Message-ID: hi.... Your Assumption is correct.... There was some multicast problem with server and client... I tested with different machines it is working.... thank you very much.... Tomy P. Joseph Samsung ODC, L&T Infotech,Plot No. 25-30, EPIP I Phase Industrial Area, Whitefield,Bangalore-66. Mobile: +919448856102 Fax:+91-80-8525233. ( ) L&T Infotech Proprietary & Confidential ( ) L&T Infotech Confidential (+) L&T Infotech Internal Use only ( ) General Business Information Larsen & Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070905/b789d886/attachment.html From dimazzz80 at mail.ru Thu Sep 6 03:58:07 2007 From: dimazzz80 at mail.ru (=?koi8-r?Q?=E4=C9=CD=C1_=FA=C9=CE=DE=C5=CE=CB=CF?=) Date: Thu, 06 Sep 2007 14:58:07 +0400 Subject: [Live-devel] Multiple live and archived channels streaming for videoserver Message-ID: Hi, I' m writing some kind of video server that basically has to stream captured video from several cameras and also to allow access to video archive to stream video from specified time. Currently all this streams are MJPEG ones, containing JPEG buffer for every frame. Currently I am able to stream any specific «live» channel by making subclass of JPEGVideoSource to take arriving JPEG frames from memory buffers (similar to Elphel example). To stream second channel, I created second RTSP server with another port, so to access different streams I connect to «rtsp://:/» and «rtsp://:/», but it seems like a wrong way to go. After reading some more of the source I decided that the right thing is to make subclass of RTSPServer with reimplemented lookupServerMediaSession that will analyze passed from client and select proper «live» source or archived one. But this makes sense only if one RTSPServer can stream simultaneously several sources to one client. Is it so? Then, it seems that I should stream «live» video as multicast and archive as unicast (because there will be several clients who will receive «live» video and only one for each archive access), is it possible to do simultaneously with one RTSPServer? (Actually I can stream «live» as unicast also, if not). Then I have the question about navigation in archived source. As I understand I should make a subclass of ServerMediaSubsession with implementation of seekStream, setStreamScale and something else (mentioned somewhere), but the problem is that the archive contains many files for each channel and I should somehow tell the «Source» class which file to use (actually I haven't read the example implementation of trick play functions yet, so I'm not sure here). Thanks, Dmitry Zinchenko From finlayson at live555.com Thu Sep 6 04:55:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Sep 2007 04:55:20 -0700 Subject: [Live-devel] Multiple live and archived channels streaming for videoserver In-Reply-To: References: Message-ID: >To stream second channel, I created second RTSP server with another port No, you shouldn't need to do this. It's best to use just a single RTSP server, but with separate "ServerMediaSession"s for each 'channel'. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From xcsmith at rockwellcollins.com Thu Sep 6 15:13:27 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Thu, 6 Sep 2007 17:13:27 -0500 Subject: [Live-devel] ByteStreamFileSource Message-ID: Q: What is ByteStreamFileSource::fPlayTimePerFrame for? xochitl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070906/274c5921/attachment.html From finlayson at live555.com Thu Sep 6 16:17:11 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Sep 2007 16:17:11 -0700 Subject: [Live-devel] ByteStreamFileSource In-Reply-To: References: Message-ID: >Q: What is ByteStreamFileSource::fPlayTimePerFrame for? It's used to implement the (optional) "playTimePerFrame" parameter in "ByteStreamFileSource::createNew()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070906/f2b52b19/attachment.html From Ambra.Cristaldi at elsagdatamat.com Fri Sep 7 02:10:32 2007 From: Ambra.Cristaldi at elsagdatamat.com (Cristaldi Ambra) Date: Fri, 7 Sep 2007 11:10:32 +0200 Subject: [Live-devel] Audio format for openRTSP Message-ID: <268315E5844A704AB431589863FE8EEFC64234@els00wmx04.elsag.it> Hi Ross, I'm trying to record a video stream coming from an "Axis" camera using openRTSP application. I would know if is it possible to record this A/V stream (setting the "-4" flag in command arguments) when audio flow is in "G.711 PCM" format or "G.726 ADPCM" format. Moreover this should be possible if camera has AAC format instead. Is it right? Thank you very much. Ambra. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070907/70d8ac86/attachment.html From dimazzz80 at mail.ru Fri Sep 7 04:19:30 2007 From: dimazzz80 at mail.ru (=?koi8-r?Q?=E4=C9=CD=C1_=FA=C9=CE=DE=C5=CE=CB=CF?=) Date: Fri, 07 Sep 2007 15:19:30 +0400 Subject: [Live-devel] =?koi8-r?b?TXVsdGlwbGUgbGl2ZSBhbmQgYXJjaGl2ZWQgY2hh?= =?koi8-r?b?bm5lbHMgc3RyZWFtaW5nIGZvcnZpZGVvc2VydmVy?= In-Reply-To: References: Message-ID: > > >To stream second channel, I created second RTSP server with another port > > No, you shouldn't need to do this. It's best to use just a single > RTSP server, but with separate "ServerMediaSession"s for each > 'channel'. > -- Ok, now I have 2 ServerMediaSessions for 2 channels with streamnames like "channel0" and "channel1", so I access the streams with VLC by URL "rtsp://:/channelX". Now, the problem is that somehow usually only 1 stream is actually transmitted. Sometimes (rarely) it works fine, I mean I can watch both channels simultaneously using VLC, but usually only one works, although 1) the url is correct and VLC sees the it's MJPEG stream, only no actual data is transmitted (wiresharks shows the same - only one of assigned RTP ports is in use) 2) the "deliverFrametoClient" function works fine, ie it copies my JPEG buffer (without header) to fTo and calls "afterGetting". From finlayson at live555.com Fri Sep 7 04:26:45 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Sep 2007 04:26:45 -0700 Subject: [Live-devel] Audio format for openRTSP In-Reply-To: <268315E5844A704AB431589863FE8EEFC64234@els00wmx04.elsag.it> References: <268315E5844A704AB431589863FE8EEFC64234@els00wmx04.elsag.it> Message-ID: >I'm trying to record a video stream coming from an "Axis" camera >using openRTSP application. >I would know if is it possible to record this A/V stream (setting >the "-4" flag in command arguments) when audio flow is in "G.711 >PCM" format Perhaps > or "G.726 ADPCM" format. Definitely not. >Moreover this should be possible if camera has AAC format instead. >Is it right? Yes. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070907/a750ceba/attachment.html From H.Oztoprak at surrey.ac.uk Sat Sep 8 07:15:27 2007 From: H.Oztoprak at surrey.ac.uk (H.Oztoprak at surrey.ac.uk) Date: Sat, 8 Sep 2007 15:15:27 +0100 Subject: [Live-devel] Hello Message-ID: <603BF90EB2E7EB46BF8C226539DFC207093AAB@EVS-EC1-NODE1.surrey.ac.uk> Hello there, There is no test program about aac latm streaming in the library. I believe I will have to create some classes before writing the test program. Is that right? Would you give me some suggestions about that? Thanks a lot in advance. Huseyin. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070908/9669c009/attachment.html From finlayson at live555.com Sat Sep 8 08:11:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 8 Sep 2007 08:11:15 -0700 Subject: [Live-devel] Hello In-Reply-To: <603BF90EB2E7EB46BF8C226539DFC207093AAB@EVS-EC1-NODE1.surrey.ac.uk> References: <603BF90EB2E7EB46BF8C226539DFC207093AAB@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: >There is no test program about aac latm streaming in the library. I >believe I will have to create some classes before writing the test >program. Is that right? Yes, you;ll need to write a class that delivers discrete LATM-formatted AAC frames (one at a time, with proper presentation times), and then feed this into a "MPEG4LATMAudioRTPSink". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070908/24582460/attachment.html From ruru605 at 163.com Sun Sep 9 22:42:16 2007 From: ruru605 at 163.com (ruru605) Date: Mon, 10 Sep 2007 14:42:16 +0900 Subject: [Live-devel] congestion control exits or not Message-ID: <200709101442157814316@163.com> Hi, everyone Is there any congestion control in liveMedia? I haven't found yet. Ben ruru605 2007-09-10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070909/2c87f020/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: ? ?.vcf Type: text/x-vcard Size: 204 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070909/2c87f020/attachment.vcf From finlayson at live555.com Mon Sep 10 00:08:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2007 00:08:55 -0700 Subject: [Live-devel] congestion control exits or not In-Reply-To: <200709101442157814316@163.com> References: <200709101442157814316@163.com> Message-ID: > Is there any congestion control in liveMedia? No. The IETF has recently defined RTP/AVPCC - a congestion controlled variant of the basic RTP profile - but we do not currently implement this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070910/feb698d1/attachment-0001.html From kan at pisem.net Mon Sep 10 00:15:29 2007 From: kan at pisem.net (Karlov Andrey) Date: Mon, 10 Sep 2007 11:15:29 +0400 Subject: [Live-devel] some problems with ByteStreamMultiFileSource Message-ID: <46E4EF11.8090408@pisem.net> Then one file is over, ByteStreamFileSource switch us to another file, for this purpoise it has method: "void ByteStreamMultiFileSource::onSourceClosure1() { // This routine was called because the currently-read source was closed // (probably due to EOF). Close this source down, and move to the // next one: ... .... this method called from here, as I understand: void ByteStreamFileSource::doGetNextFrame() { if (feof(fFid) || ferror(fFid)) { handleClosure(this); return; } ... but there are exists some cases, when the file is over , but it doesn't handled correctly I see the next reasons of this problem here: void ByteStreamFileSource::doReadFromFile() { // Try to read as many bytes as will fit in the buffer provide // (or "fPreferredFrameSize" if less) if (fPreferredFrameSize > 0 && fPreferredFrameSize < fMaxSize) { fMaxSize = fPreferredFrameSize; } fFrameSize = fread(fTo, 1, fMaxSize, fFid); .... 1. usually fMaxSize = (7*188)=1316 and then in file remain in exact 1316 unreaded bytes, then EOF don't happens 2. if in file remain little then 188 bytes (TS packet) EOF dont't happens too These two cases handled here: void MPEG2TransportStreamFramer::afterGettingFrame1(unsigned frameSize, struct timeval presentationTime) { fFrameSize += frameSize; unsigned const numTSPackets = fFrameSize/TRANSPORT_PACKET_SIZE; fFrameSize = numTSPackets*TRANSPORT_PACKET_SIZE; // an integral # of TS packets if (fFrameSize == 0) { // We didn't read a complete TS packet; assume that the input source has closed. handleClosure(this); return; } but calling "handleClosure(this)" don't rezult for switching to another file there, instead of this it call function "afterPlaying", which defined here: videoSink->startPlaying(*videoSource, afterPlaying, videoSink); What correct way switch to another file in these cases? I try to do folowing: void ByteStreamFileSource::doReadFromFile() { // Try to read as many bytes as will fit in the buffer provided // (or "fPreferredFrameSize" if less) if (fPreferredFrameSize > 0 && fPreferredFrameSize < fMaxSize) { fMaxSize = fPreferredFrameSize; } fFrameSize = fread(fTo, 1, fMaxSize, fFid); if (fFrameSize < 188) { handleClosure(this); // < --------------- switch t another file here return; } ..... But I think that it isn't the most right way What can you adwise? I'm very thankfull to your help! Sorry for awful English =) Karlov Andrey. From finlayson at live555.com Mon Sep 10 00:51:39 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2007 00:51:39 -0700 Subject: [Live-devel] some problems with ByteStreamMultiFileSource In-Reply-To: <46E4EF11.8090408@pisem.net> References: <46E4EF11.8090408@pisem.net> Message-ID: >1. usually fMaxSize = (7*188)=1316 and then in file remain in exact 1316 >unreaded bytes, > then EOF don't happens >2. if in file remain little then 188 bytes (TS packet) EOF dont't >happens too The size of all Transport Stream files should be a multiple of 188 bytes. If you have a Transport Stream size whose size is *not* a multiple of 188 bytes, then I suggest rewriting the file to truncate the excess bytes. Then you won't have this problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kan at pisem.net Mon Sep 10 01:22:03 2007 From: kan at pisem.net (Karlov Andrey) Date: Mon, 10 Sep 2007 12:22:03 +0400 Subject: [Live-devel] some problems with ByteStreamMultiFileSource Message-ID: <46E4FEAB.8030505@pisem.net> Ok, I agree with you in that case. But that about first case? Sometimes it's happens =) For example I have file with size 6011488 bytes. 6011488 = 4568*1316=4568*(7*188) <--it's correct transport stream file, but then we read last portion of this file: fFrameSize = fread(fTo, 1, fMaxSize, fFid); we read exactly 1316 bytes, the file is no longer left bytes!!! but also we haven't EOF state, for this reason, we will not be able to handle the situation properly and in the right place. > >1. usually fMaxSize = (7*188)=1316 and then in file remain in exact >1316 >>unreaded bytes, >> then EOF don't happens >>2. if in file remain little then 188 bytes (TS packet) EOF dont't >>happens too > >The size of all Transport Stream files should be a multiple of 188 >bytes. If you have a Transport Stream size whose size is *not* a >multiple of 188 bytes, then I suggest rewriting the file to truncate >the excess bytes. Then you won't have this problem. >-- From finlayson at live555.com Mon Sep 10 01:32:21 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2007 01:32:21 -0700 Subject: [Live-devel] some problems with ByteStreamMultiFileSource In-Reply-To: <46E4FEAB.8030505@pisem.net> References: <46E4FEAB.8030505@pisem.net> Message-ID: >\For example I have file with size 6011488 bytes. >6011488 = 4568*1316=4568*(7*188) <--it's correct transport stream file, >but then we read last portion of this file: > fFrameSize = fread(fTo, 1, fMaxSize, fFid); >we read exactly 1316 bytes, the file is no longer left bytes!!! >but also we haven't EOF state, In that case, you should get EOF on the file the next time you try to read from it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kan at pisem.net Mon Sep 10 02:01:51 2007 From: kan at pisem.net (Karlov Andrey) Date: Mon, 10 Sep 2007 13:01:51 +0400 Subject: [Live-devel] some problems with ByteStreamMultiFileSource Message-ID: <46E507FF.5070800@pisem.net> but we haven't! in first mail I have explained why. This is because we check for EOF only before reading! Then we read next time, we before check for EOF, but there's no EOF state and we try to read, and of course we read 0 bytes, but now we have EOF state =) and it's handled not here, as it should be: void ByteStreamFileSource::doGetNextFrame() { if (feof(fFid) || ferror(fFid)) { handleClosure(this); <--- SWITCH TO NEXT FILE return; } .... but here: void MPEG2TransportStreamFramer::afterGettingFrame1(unsigned frameSize, struct timeval presentationTime) { fFrameSize += frameSize; unsigned const numTSPackets = fFrameSize/TRANSPORT_PACKET_SIZE; fFrameSize = numTSPackets*TRANSPORT_PACKET_SIZE; if (fFrameSize == 0) { // We didn't read a complete TS packet; //assume that the input source has closed. handleClosure(this); <-- EXIT FROM PROGRAM, NO SWITCH TO ANOTHER FILE return; } ...... >>\For example I have file with size 6011488 bytes. >>6011488 = 4568*1316=4568*(7*188) <--it's correct transport stream >file, >>but then we read last portion of this file: >> fFrameSize = fread(fTo, 1, fMaxSize, fFid); >>we read exactly 1316 bytes, the file is no longer left bytes!!! >>but also we haven't EOF state, > >In that case, you should get EOF on the file the next time you try to >read from it. >-- From finlayson at live555.com Mon Sep 10 02:34:26 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2007 02:34:26 -0700 Subject: [Live-devel] some problems with ByteStreamMultiFileSource In-Reply-To: <46E507FF.5070800@pisem.net> References: <46E507FF.5070800@pisem.net> Message-ID: >but we haven't! in first mail I have explained why. > >This is because we check for EOF only before reading! > >Then we read next time, we before check for EOF, >but there's no EOF state and we try to read, >and of course we read 0 bytes, but now we have EOF state =) OK, try adding the following, after the call to "fread()" (line 138) in "ByteStreamFileSource.cpp": if (fFrameSize == 0) { handleClosure(this); return; } Please let us know if that works for you. (If so, I'll add it to the next source code release.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From peterleese at lineone.net Mon Sep 10 08:30:55 2007 From: peterleese at lineone.net (peterleese at lineone.net) Date: Mon, 10 Sep 2007 16:30:55 +0100 (GMT+01:00) Subject: [Live-devel] RTP over TCP sometimes locks up the server Message-ID: <23781504.1189438255267.JavaMail.root@ps36.mc.tiscali.sys> In live555 release 0.18 (1st July 2007), I have occassional found that the server can "appear" to lock up when streaming RTP over TCP. After much analysis I think I have traced the problem to the tcpReaderHandler method in RTP_Interface.cpp. Specifically lines 332 to 337 do { if (readSocket(env, socketNum, &c, 1, fromAddress) != 1) { // error reading TCP socket env.taskScheduler().turnOffBackgroundReadHandling(socketNum); // stops further calls to us return; } } while (c != '$'); The problem is that the readSocket() function can block and will block if the next (and last) character to read is not a '$'. That is the function gets 'tcpReadHandler' gets called from the scheduler because there is something to read. The function reads the characters and that could be some RTSP command from the client which is discarded (I'm happy with that) but if there is no '$' then we are stuck in that do while loop forever (no return back to the scheduler) until the socket dies. My suggested solution is to pass a timeout to the readSocket() of 0 seconds (as opposed to the default of NULL - i.e. infinity) something like so: struct timeval wait; wait.tv_sec = 0; wait.tv_usec = 0; do { int retval = readSocket(env, socketNum, &c, 1, fromAddress, &wait); if(retVal != 1) { // error reading TCP socket if(retVal < 0) { env.taskScheduler().turnOffBackgroundReadHandling(socketNum); // stops further calls to us } return; } } while (c != '$'); This will make sure that if there is nothing left to read then at least the function will return. P.S. I've using real-player as the client so you may say that's a bad idea, but I think the above change should be done? regards Peter lines __________________________________________________ Tiscali Broadband only ?7.99 a month for your first 3 months! http://www.tiscali.co.uk/products/broadband/ From xcsmith at rockwellcollins.com Mon Sep 10 11:06:12 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Mon, 10 Sep 2007 13:06:12 -0500 Subject: [Live-devel] ByteStreamFileSource In-Reply-To: Message-ID: > Q: What is ByteStreamFileSource::fPlayTimePerFrame for? > > It's used to implement the (optional) "playTimePerFrame" parameter > in "ByteStreamFileSource::createNew()". > -- Yes, I did look at the code for this, but I don't understand what "playTimePerFrame" actually does. Does it request that each "getNextFrame" call grab a "frame" that represents a specific amount of play-time in the stream? As an application programmer, when would I want to specify playTimePerFrame to ByteStreamFileSource? Thanks! Xo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070910/edf79c46/attachment.html From finlayson at live555.com Mon Sep 10 15:39:09 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2007 15:39:09 -0700 Subject: [Live-devel] ByteStreamFileSource In-Reply-To: References: Message-ID: >As an application programmer, when would I want to specify >playTimePerFrame to ByteStreamFileSource? When you are streaming directly from a file, by reading/streaming one fixed-size chunk of data at a time. This happens for many simple audio codecs (although not for more complex audio codecs like AAC or MP3, because their frames are typically variable-sized). Because you're streaming directly from the file - without any separate intermediate 'framer' object - you need to tell the downstream "RTPSink" object the duration and presentation time of each (fixed-size) chunk of data that you're delivering. Therefore, in this case, you need to tell the "ByteStreamFileSource" the duration of each chunk ('frame'). If, however, you are using a separate 'framer' object to parse the file data, then you should not specify "playTimePerFrame". Instead, it will be up to the 'framer' object to specify the duration and presentation time of each parsed frame. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070910/3e438a92/attachment.html From finlayson at live555.com Mon Sep 10 18:30:35 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Sep 2007 18:30:35 -0700 Subject: [Live-devel] RTP over TCP sometimes locks up the server In-Reply-To: <23781504.1189438255267.JavaMail.root@ps36.mc.tiscali.sys> References: <23781504.1189438255267.JavaMail.root@ps36.mc.tiscali.sys> Message-ID: Peter, Thanks for the report. Yes, you're correct that the current code is buggy - it should not be doing more than one potentially blocking socket read inside the read handler (because the second and subsequent reads might, indeed, block). It seems a bit strange that a client would behave in such a way as to make this a problem, but certainly the server should not be relying upon correct client behavior. In the next released version of the code, I'll see if I can find a way to make this code more bullet-proof - most likely using timeouts on the socket reads, as you suggested. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Tomy.Joseph at lntinfotech.com Mon Sep 10 19:46:17 2007 From: Tomy.Joseph at lntinfotech.com (Tomy Joseph) Date: Tue, 11 Sep 2007 08:16:17 +0530 Subject: [Live-devel] testMPEG4VideoStreamer_problem In-Reply-To: Message-ID: When I try to run testMPEG4VideoStreamer, I am getting the following errors continuously.. MPEG4VideoStreamParser::analyzeVOLHeader(): marker_bit 1 not set! MPEG4VideoStreamParser::analyzeVOLHeader(): vop_time_increment_resolution is zero! MPEG4VideoStreamParser::analyzeVOLHeader(): marker_bit 2 not set! MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be a 'short v ideo header', which we current don't support I tried with so many .mp4 files... But errors...is it the problem with .mp4 files or any other??? Tomy P. Joseph Samsung ODC, L&T Infotech,Plot No. 25-30, EPIP I Phase Industrial Area, Whitefield,Bangalore-66. Mobile: +919448856102 Fax:+91-80-8525233. ( ) L&T Infotech Proprietary & Confidential ( ) L&T Infotech Confidential (+) L&T Infotech Internal Use only ( ) General Business Information Larsen & Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070910/98d98785/attachment.html From Tomy.Joseph at lntinfotech.com Mon Sep 10 20:03:41 2007 From: Tomy.Joseph at lntinfotech.com (Tomy Joseph) Date: Tue, 11 Sep 2007 08:33:41 +0530 Subject: [Live-devel] testMPEG1or2AudioVideoStreamer_multiChannelProblem Message-ID: HI.. For Playing Multiple channels in testMPEG1or2AudioVideoStreamer application , I created multiple instances of serverMediaSession. But the server is streaming one file after another...it is not streaming all the files(channels) simultaneously. So the clients cannot play all the channels simultaneously. So can you pls explain me abut the exact problem?? Tomy P. Joseph Samsung ODC, L&T Infotech,Plot No. 25-30, EPIP I Phase Industrial Area, Whitefield,Bangalore-66. Mobile: +919448856102 Fax:+91-80-8525233. ( ) L&T Infotech Proprietary & Confidential ( ) L&T Infotech Confidential (+) L&T Infotech Internal Use only ( ) General Business Information Larsen & Toubro Infotech Ltd. www.Lntinfotech.com This Document is classified as: L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070910/f7fae2f2/attachment.html From kan at pisem.net Mon Sep 10 23:39:38 2007 From: kan at pisem.net (Karlov Andrey) Date: Tue, 11 Sep 2007 10:39:38 +0400 Subject: [Live-devel] some problems with ByteStreamMultiFileSource Message-ID: <46E6382A.6080305@pisem.net> >OK, try adding the following, after the call to "fread()" (line 138) >in "ByteStreamFileSource.cpp": > if (fFrameSize == 0) { > handleClosure(this); > return; > } > >Please let us know if that works for you. (If so, I'll add it to the >next source code release.) I think this code more suitable, it's work fine then TS file has not multiple of 188 bytes. if (fFrameSize < 188) { handleClosure(this); return; } From kan at pisem.net Mon Sep 10 23:48:44 2007 From: kan at pisem.net (Karlov Andrey) Date: Tue, 11 Sep 2007 10:48:44 +0400 Subject: [Live-devel] is it possible to change PTS, DTS, PCR in stream? Message-ID: <46E63A4C.2090605@pisem.net> For example when we covert Program Stream to Transport Stream in "testMPEG1or2ProgramToTransportStream" is it possible to change another time base and replase PTS, DTS, PCR? if any means allowing realize that opportunity? From finlayson at live555.com Tue Sep 11 00:17:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2007 00:17:07 -0700 Subject: [Live-devel] is it possible to change PTS, DTS, PCR in stream? In-Reply-To: <46E63A4C.2090605@pisem.net> References: <46E63A4C.2090605@pisem.net> Message-ID: >For example when we covert Program Stream to Transport Stream >in "testMPEG1or2ProgramToTransportStream" > >is it possible to change another time base and replase PTS, DTS, PCR? Not without writing new software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Sep 11 00:31:32 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2007 00:31:32 -0700 Subject: [Live-devel] some problems with ByteStreamMultiFileSource In-Reply-To: <46E6382A.6080305@pisem.net> References: <46E6382A.6080305@pisem.net> Message-ID: > >OK, try adding the following, after the call to "fread()" (line 138) > >in "ByteStreamFileSource.cpp": > > if (fFrameSize == 0) { > > handleClosure(this); > > return; > > } > > > >Please let us know if that works for you. (If so, I'll add it to the > >next source code release.) I assume this worked OK for you, so I'll add it to the next source code release. > > >I think this code more suitable, it's work fine then TS file has not >multiple of 188 bytes. > >if (fFrameSize < 188) { > handleClosure(this); > return; >} No, because that's specific to Transport Stream files. I suggest that you ensure that all of your Transport Stream files are a multiple of 188 bytes in size. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Sep 11 00:34:04 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2007 00:34:04 -0700 Subject: [Live-devel] testMPEG1or2AudioVideoStreamer_multiChannelProblem In-Reply-To: References: Message-ID: >HI.. >For Playing Multiple channels in testMPEG1or2AudioVideoStreamer >application , I created multiple instances of serverMediaSession. >But the server is streaming one file after another...it is not >streaming all the files(channels) simultaneously. So the clients >cannot play all the channels simultaneously. So can you pls explain >me abut the exact problem?? No, because I don't know what modifications you made (nor to I have the time to look at them :-). However, if you do this right, it should work. Make sure that you're calling "startPlaying()" on all the sinks at the same time. Also, of course, each stream should use different multicast addresses and ports. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070911/f7c2338f/attachment.html From finlayson at live555.com Tue Sep 11 00:35:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2007 00:35:07 -0700 Subject: [Live-devel] testMPEG4VideoStreamer_problem In-Reply-To: References: Message-ID: >When I try to run testMPEG4VideoStreamer, I am getting the following >errors continuously.. > >MPEG4VideoStreamParser::analyzeVOLHeader(): marker_bit 1 not set! >MPEG4VideoStreamParser::analyzeVOLHeader(): vop_time_increment_resolution is > zero! >MPEG4VideoStreamParser::analyzeVOLHeader(): marker_bit 2 not set! > >MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be a 'short v >ideo header', which we current don't support > >I tried with so many .mp4 files... But errors...is it the problem >with .mp4 files or any other??? ".mp4" files ARE NOT MPEG-4 Video Elementary Stream files. ".mp4" files currently cannot be streamed by our libraries. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070911/9177868b/attachment.html From glen.gray at lincor.com Tue Sep 11 14:45:09 2007 From: glen.gray at lincor.com (Glen Gray) Date: Tue, 11 Sep 2007 22:45:09 +0100 Subject: [Live-devel] RTSP Server 'Keep Alive' support Message-ID: <46E70C65.4040000@lincor.com> Hey Guys, Wondering if the liveMedia/RTSPServer.cpp code has support for 'Keep Alive' functionality ? I see from the source code that it accepts the GET_PARAMETER calls and responds to the client, but doesn't seem to do anything regarding the session. I assume this means that KeepAlive isn't enforced and is simply sending a dummy response to keep some clients happy ? What happens in the situation where a client is killed without doing a TEARDOWN and then re-establishes a connection ? My experience has been with Kasenna's which didn't handle this well and simply created a second stream to the same IP resulting in a corrupted playback experience. -- Glen Gray > Digital Depot, Thomas Street Senior Software Engineer Dublin 8, Ireland Lincor Solutions Ltd. Ph: +353 (0) 1 4893682 From finlayson at live555.com Tue Sep 11 14:57:19 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Sep 2007 14:57:19 -0700 Subject: [Live-devel] RTSP Server 'Keep Alive' support In-Reply-To: <46E70C65.4040000@lincor.com> References: <46E70C65.4040000@lincor.com> Message-ID: >Wondering if the liveMedia/RTSPServer.cpp code has support for 'Keep >Alive' functionality ? Yes. Note the "reclamationTestSeconds" parameter (default value, 45 seconds) in "RTSPServer::createNew()". > >I see from the source code that it accepts the GET_PARAMETER calls and >responds to the client, but doesn't seem to do anything regarding the >session. Yes it does. The server treats either an incoming RTCP "RR" packet, or any RTSP command (not just "GET_PARAMETER") as indicating client liveness. Note, though, that if you requested RTP-over-TCP streaming, then (because of software limitations) the server will not see any RTSP requests after "PLAY". However, incoming RTCP "RR" packets will always be handled (and used to indicate client liveness). All standards-clompliant RTSP/RTP clients should send RTCP "RR" packets. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gcleary at sightlogix.com Wed Sep 12 12:54:55 2007 From: gcleary at sightlogix.com (Geoff Cleary) Date: Wed, 12 Sep 2007 15:54:55 -0400 Subject: [Live-devel] Race condition bug fix Message-ID: <200709121955.l8CJtkdk085437@ns.live555.com> The following fix prevents a bug when two requests are processed in close proximity. Should pass the parser the pointer to the new request not the address of the buffer. *** lib/live/liveMedia/RTSPServer.cpp 2007-06-15 14:44:10.811882441 -0400 --- ./lib/live/liveMedia/RTSPServer.cpp 2007-09-12 15:01:55.216824905 -0400 *************** *** 350,356 **** char urlPreSuffix[RTSP_PARAM_STRING_MAX]; char urlSuffix[RTSP_PARAM_STRING_MAX]; char cseq[RTSP_PARAM_STRING_MAX]; ! if (!parseRTSPRequestString((char*)fRequestBuffer, fRequestBytesAlreadySeen, cmdName, sizeof cmdName, urlPreSuffix, sizeof urlPreSuffix, urlSuffix, sizeof urlSuffix, --- 350,356 ---- char urlPreSuffix[RTSP_PARAM_STRING_MAX]; char urlSuffix[RTSP_PARAM_STRING_MAX]; char cseq[RTSP_PARAM_STRING_MAX]; ! if (!parseRTSPRequestString((char*)ptr, bytesRead, cmdName, sizeof cmdName, urlPreSuffix, sizeof urlPreSuffix, urlSuffix, sizeof urlSuffix, ======================= Geoff Cleary, Principal Software Engineer SightLogix, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070912/66deea3e/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1836 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070912/66deea3e/attachment.gif From finlayson at live555.com Wed Sep 12 18:01:09 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Sep 2007 18:01:09 -0700 Subject: [Live-devel] Race condition bug fix In-Reply-To: <200709121955.l8CJtkdk085437@ns.live555.com> References: <200709121955.l8CJtkdk085437@ns.live555.com> Message-ID: >The following fix prevents a bug when two requests are processed in >close proximity. No, the original code was correct. It's possible that an incoming RTSP request will require more than one socket read in order to obtain all the data for the request. In that case, the length of the request data - as passed to "parseRTSPRequestString()" - must be "fRequestBytesAlreadySeen", not "bytesRead". What specifically was causing you problems with the original code? Can you describe a specific sequence of incoming RTSP requests that was causing problems?? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070912/ec5ba8ca/attachment.html From taknevski at gmail.com Thu Sep 13 00:14:49 2007 From: taknevski at gmail.com (Anand Anand) Date: Thu, 13 Sep 2007 12:44:49 +0530 Subject: [Live-devel] open source mp3 player to play streams received from testMP3Receievr.cpp Message-ID: <713fe210709130014u1abf5a10ha0e39d77615d292f@mail.gmail.com> Hi Is there any open source mp3 player that i can use to play the streams receiver from the sample program testMP3Receiver.cpp?.. currently the stream is encoded in mp3 format i need to decode and play it as it is being received. simlarly is there some open source to play mpg video files as they are being received ? Thank you, Anand Venkat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070913/345b7394/attachment.html From finlayson at live555.com Thu Sep 13 00:52:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Sep 2007 00:52:57 -0700 Subject: [Live-devel] open source mp3 player to play streams received from testMP3Receievr.cpp In-Reply-To: <713fe210709130014u1abf5a10ha0e39d77615d292f@mail.gmail.com> References: <713fe210709130014u1abf5a10ha0e39d77615d292f@mail.gmail.com> Message-ID: >Is there any open source mp3 player that i can use to play the >streams receiver from the sample program testMP3Receiver.cpp? The demo application "testMP3Receiver" outputs its received data as a regular MP3 file, so any MP3 player will be able to play it. Did you mean to ask about a player application that could play the stream that is sent by "testMP3Streamer" (not "testMP3Receiver")? If so, then VLC can play the stream. First, however, you will need to modify the "testMP3Streamer.cpp" code to uncomment the line #define IMPLEMENT_RTSP_SERVER 1 and then recompile. The application will then print out a "rtsp://..." URL, which you can enter into VLC. >simlarly is there some open source to play mpg video files as they >are being received Ditto - VLC. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From prn57r at gmail.com Thu Sep 13 01:55:25 2007 From: prn57r at gmail.com (prn 57r) Date: Thu, 13 Sep 2007 18:55:25 +1000 Subject: [Live-devel] Can't connect to BBC Radio WMA streams via rtsp In-Reply-To: References: Message-ID: Hi, I'm in the process of creating an RTSP client and have run into problems with connecting to the BBC's radio stations. Like vlc, I am using the livemedia libraries to provide rtsp support and have done a fair amount of work getting my client to receive mms streams via RTSP. Both vlc and my RTSP client can connect to most mms urls if you change the "mms://" to "rtsp://", but have problems downloading particular BBC radio stations in this way. So I was wondering if anyone can shed any light on the problems that I'm having. I'm having problems when trying to connect to some BBC Radio WMA streams via rtsp. My current setup is: Ubuntu 7.04 (Feisty Fawn), VLC media player 0.8.6 Janus. And my problem is: running: vlc mms://wmlive.bbc.co.uk/wms/bbc7/hi_s1 succeeds in connecting to and playing the bbc radio stream. However when i run: vlc rtsp://wmlive.bbc.co.uk/wms/bbc7/hi_s1 vlc fails to connect and i get the following result: ------------------------------------------------------------------------------ VLC media player 0.8.6 Janus Sending request: OPTIONS rtsp://wmlive.bbc.co.uk/wms/bbc7/hi_s1 RTSP/1.0 CSeq: 1 User-Agent: VLC media player (LIVE555 Streaming Media v2006.03.16) Received OPTIONS response: RTSP/1.0 200 OK Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, com.microsoft.wm.eosmsg, com.microsoft.wm.fastcache, com.microsoft.wm.packetpairssrc, com.microsoft.wm.startupprofile Date: Thu, 13 Sep 2007 07:25:44 GMT CSeq: 1 Server: WMServer/9.1.1.3814 Sending request: DESCRIBE rtsp://wmlive.bbc.co.uk/wms/bbc7/hi_s1 RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2006.03.16) Received DESCRIBE response: RTSP/1.0 200 OK Content-Type: application/sdp Vary: Accept X-Playlist-Gen-Id: 7239577 X-Broadcast-Id: 5581321 Content-Length: 4452 Date: Thu, 13 Sep 2007 07:25:44 GMT CSeq: 2 Server: WMServer/9.1.1.3814 Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, com.microsoft.wm.eosmsg, com.microsoft.wm.fastcache, com.microsoft.wm.packetpairssrc, com.microsoft.wm.startupprofile Last-Modified: Sat, 30 Dec 1899 00:00:00 GMT Cache-Control: x-wms-stream-type="broadcast", no-cache, no-user-cache, private Need to read 4452 extra bytes Read 1049 extra bytes: v=0 o=- 200709050605210616 200709050605210616 IN IP4 127.0.0.1 s=BBC7 c=IN IP4 0.0.0.0 b=AS:49 a=maxps:2261 t=0 0 a=control:rtsp://wmlive.bbc.co.uk/wms%5Cbbc7%5Chi_s1/ a=etag:{4805447C-964F-4983-1A7B-29FF715BA671} a=range:npt=3.064-3.064 a=type:broadcast a=recvonly a=pgmpu:data:application/x-wms-contentdesc,8,language,31,0,,42,WMS_CONTENT_DESCRIPTION_PLAYLIST_ENTRY_URL,31,1,/,58,WMS_CONTENT_DESCRIPTION_COPIED_METADATA_FROM_PLAYLIST_FILE,3,1,1,47,WMS_CONTENT_DESCRIPTION_PLAYLIST_ENTRY_DURATION,3,1,0,51,WMS_CONTENT_DESCRIPTION_PLAYLIST_ENTRY_START_OFFSET,3,4,3064,5,title,31,4,BBC7,6,author,31,4,BBC7,9,copyright,31,35,%C2%A9%20British%20Broadcasting%20Corporation,35,WMS_CONTENT_DESCRIPTION_DESCRIPTION,31,0,,30,WMS_CONTENT_DESCRIPTION_RATING,31,0,,44,WMS_CONTENT_DESCRIPTION_SERVER_BRANDING_INFO,31,12,WMServer/9.0%0D%0A a=pgmpu:data:application/vnd.ms.wms-hdr.asfv1 ;base64,MCaydY5mzxGm2QCqAGLObJUJAAAAAAAABwAAAAECMyaydY5mzxGm2QCqAGLObIAAAAAAAAAACgAKAEYAAgACAEIAQgBDADcAAABCAEIAQwA3AAAAqQAgAEIAcgBpAHQAaQBzAGgAIABCAHIAbwBhAGQAYwBh Read 1048 extra bytes: AHMAdABpAG4AZwAgAEMAbwByAHAAbwByAGEAdABpAG8AbgAAAAAAAADOdfh7jUbREY2CAGCXyaKyIAAAAAAAAAABAAEABr4AAKHcq4xHqc8RjuQAwAwgU2VoAAAAAAAAAEdCODRZFkJCrKyqRDJhJtHHCQAAAAAAAGDiZot778cB/////wAAAAAAAAAAAAAAAAAAAAAAAAAA+AsAAAAAAAAJAAAA1QgAANUIAAAGvgAAtQO/Xy6pzxGO4wDADCBTZbEGAAAAAAAAEdLTq7qpzxGO5gDADCBTZQYAgwYAAKlGQ3zg7/xLsik5Pt5BXIUnAAAAAAAAAAEADGUAbgAtAGcAYgAAAMul5hRyxjJDg5mpaVIGW1pYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACYuwAA+AsAAAAAAACYuwAA+AsAAAAAAAC2CAAAAAAAAAEAAAAAAAAAAAAAAAAAAABdi/EmhEXsR59fDmUfBFLJGgAAAAAAAAACAerL+MWvW3dIhGeqjET6TMp6AAAAAAAAAAIAAAABAAwAAgACAAAASQBzAFYAQgBSAAAAAAAAAAEANAAAAAYAAABEAGUAdgBpAGMAZQBDAG8AbgBmAG8AcgBtAGEAbgBjAGUAVABlAG0AcABsAGEAdABlAAAATAAyAAAAdNQGGN/KCUWkupqry5aq6HAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Read 524 extra bytes: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Read 1048 extra bytes: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkQfct7epzxGO5gDADCBTZXIAAAAAAAAAQJ5p+E1bzxGo/QCAX1xEK1DNw7+PYc8Ri7IAqgC04iAAAAAAAAAAABwAAAAIAAAAAQAA Read 524 extra bytes: Ys5sYQECAESsAABzFwAAtggQAAoAAIgAAB8A2SIAAAG2CLYIAQAAQKTQ0gfj0hGX8ACgyV6oUKIAAAAAAAAAAwAcAFcATQBGAFMARABLAFYAZQByAHMAaQBvAG4AAAAAABoAOQAuADAAMAAuADAAMAAuADMAMgA1ADAAAAAaAFcATQBGAFMARABLAE4AZQBlAGQAZQBkAAAAAAAWADAALgAwAC4AMAAuADAAMAAwADAAAAAMAEkAcwBWAEIAUgAAAAIABAAAAAAAQFLRhh0x0BGjpACgyQNI9qoAAAAAAAAAQVLRhh0x0BGjpACgyQNI9gEAAAACABYAVwBpAG4AZABvAHcAcwAgAE0AZQBkAGkAYQAgAEEAdQBkAGkAbwAgADkAAAAkACAANAA4ACAAawBiAHAAcwAsACAANAA0ACAAawBIAHoALAAgAHMAdABlAHIAZQBvACAAMQAtAHAAYQBzAHMAIABDAEIAUgAAAAIAYQE2JrJ1jmbPEabZAKoAYs5sMgAAAAAA Read 259 extra bytes: AABHQjg0WRZCQqysqkQyYSbRAAAAAAAAAAABAQ== m=audio 0 RTP/AVP 96 b=AS:49 b=X-AV:49 b=RS:0 b=RR:0 a=rtpmap:96 x-asf-pf/1000 a=control:audio a=stream:1 m=application 0 RTP/AVP 96 b=RS:0 b=RR:0 a=rtpmap:96 x-wms-rtx/1000 a=control:rtx a=stream:65536 Sending request: SETUP rtsp://wmlive.bbc.co.uk/wms/bbc7/hi_s1/audio RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=33094-33095 User-Agent: VLC media player (LIVE555 Streaming Media v2006.03.16) Received SETUP response: RTSP/1.0 400 Bad Request Date: Thu, 13 Sep 2007 07:25:45 GMT CSeq: 3 Server: WMServer/9.1.1.3814 Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, com.microsoft.wm.eosmsg, com.microsoft.wm.fastcache, com.microsoft.wm.packetpairssrc, com.microsoft.wm.startupprofile [00000291] live555 demuxer error: SETUP of'audio/X-ASF-PF' failed SETUP: cannot handle response: RTSP/1.0 400 Bad Request [00000291] live555 demuxer error: Nothing to play for rtsp://wmlive.bbc.co.uk/wms/bbc7/hi_s1 [00000289] main input error: no suitable access module for `rtsp://wmlive.bbc.co.uk/wms/bbc7/hi_s1' [00000280] main playlist: nothing to play -------------------------------------------------------------------------- I get the same result when i try to play rtsp://wmlive.bbc.co.uk/wms/bbc7/hi_s1 with vlc 0.8.6c running on Windows XP. Other streams that show the same problem include: mms://wmlive.bbc.net.uk/wms/radio5/5Live_int_s1 mms://wmlive.bbc.co.uk/wms/1xtra/hi_s1 where simply replacing the "mms://" with "rtsp://" creates a stream that WMP11 can play, but that vlc can not. What is especially confusing for me is the fact that Windows Media Player 11, running on Windows XP successfully connects, using a very similar pattern of RTSP commands (the messages sent during this exchange are in the attached file). I have tried altering my own RTSP client (which runs on Linux) so that it uses an identical sequence of commands to WMP11, but this still results in 400 errors - I can successfully issue the OPTIONS and DESCRIBE requests and get meaningful responses, yet every time i try to issue a GET_PARAMETER or SETUP request after this, I receive a response of RTSP/1.0 400 Bad Request. My own rtsp client is not able to download mms streams, as I haven't and don't plan to implement mms as it's a deprecated protocol. If anyone could shed any light on this problem, or let me know a place where i might get some answers, then please let me know. Thanks heaps, Mark Hingston. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070913/6fad6299/attachment-0001.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wmp11-rtsp-to-bbc.txt Url: http://lists.live555.com/pipermail/live-devel/attachments/20070913/6fad6299/attachment-0001.txt From taknevski at gmail.com Thu Sep 13 02:50:41 2007 From: taknevski at gmail.com (Anand Anand) Date: Thu, 13 Sep 2007 15:20:41 +0530 Subject: [Live-devel] open source mp3 player to play streams received from testMP3Receievr.cpp In-Reply-To: References: <713fe210709130014u1abf5a10ha0e39d77615d292f@mail.gmail.com> Message-ID: <713fe210709130250v2fd5cf45y798fe060d93ccd9f@mail.gmail.com> Hi, Thanks for the prompt reply. Ya I understand that the output from testMP3Receiver.cpp can be played by any mp3 player, however I find that open source players such as vlc are highly integrated and complicated so, I cant see how the file is being played in the code.. So, my question is is there any code snippet that can be added to testMP3Receiver.cpp that would enable it to play the mp3 file as it is received? Is it a simple task to add such code or is mp3 decoding in software very complicated because I cant seem to find any simple small scale mp3 player software. Could you suggest one for me please? Thank you, Anand On 9/13/07, Ross Finlayson wrote: > > >Is there any open source mp3 player that i can use to play the > >streams receiver from the sample program testMP3Receiver.cpp? > > The demo application "testMP3Receiver" outputs its received data as a > regular MP3 file, so any MP3 player will be able to play it. > > Did you mean to ask about a player application that could play the > stream that is sent by "testMP3Streamer" (not "testMP3Receiver")? If > so, then VLC can play the stream. > First, however, you will need to modify the "testMP3Streamer.cpp" > code to uncomment the line > #define IMPLEMENT_RTSP_SERVER 1 > and then recompile. The application will then print out a > "rtsp://..." URL, which you can enter into VLC. > > > >simlarly is there some open source to play mpg video files as they > >are being received > > Ditto - VLC. > -- > > 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: http://lists.live555.com/pipermail/live-devel/attachments/20070913/e6e69c1b/attachment.html From finlayson at live555.com Thu Sep 13 06:36:39 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Sep 2007 06:36:39 -0700 Subject: [Live-devel] Can't connect to BBC Radio WMA streams via rtsp In-Reply-To: References: Message-ID: >Sending request: SETUP rtsp://wmlive.bbc.co.uk/wms/bbc7/hi_s1/audio RTSP/1.0 >CSeq: 3 >Transport: RTP/AVP;unicast;client_port=33094-33095 >User-Agent: VLC media player (LIVE555 Streaming Media v2006.03.16) > > >Received SETUP response: RTSP/1.0 400 Bad Request >Date: Thu, 13 Sep 2007 07:25:45 GMT >CSeq: 3 >Server: WMServer/9.1.1.3814 >Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, >com.microsoft.wm.eosmsg, com.microsoft.wm.fastcache, >com.microsoft.wm.packetpairssrc, com.microsoft.wm.startupprofile Blame Microsoft for this. Their server ("WMServer") is not a standards-compliant RTSP server. You will need to find out - from Microsoft - why their server is not handling our RTSP "SETUP" request. (Good luck :-) In any case, though, even if you could get Microsoft's server to work with our RTSP client, VLC would not be able to play this stream, because we do not handle the (Microsoft-proprietary) "x-asf-pf" and "x-wms-rtx" RTP payload formats, nor the codecs that these RTP payload formats carry. (See ) To summarize: Don't bother trying to play streams from a "WMServer". Use a non-Microsoft server instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070913/601f36b1/attachment.html From gcleary at sightlogix.com Thu Sep 13 07:26:10 2007 From: gcleary at sightlogix.com (Geoff Cleary) Date: Thu, 13 Sep 2007 10:26:10 -0400 Subject: [Live-devel] Race condition bug fix In-Reply-To: Message-ID: <200709131427.l8DER22X077511@ns.live555.com> I agree that in the case of two reads to build a request, my code does not pass the correct length, however there is still a problem. Sorry I did not explain it fully in my original mail. In our use of the server, the client often makes two requests for a pair of streams from the server. Therefore two requests arrive very closely in time. The second starts processing after the first is read but before resetRequestBuffer() resets the fRequestBytesAlreadySeen. So the second request is added to the end of the first in the fRequestBuffer and parseRTSPRequestString is called with a pointer to the beginning of the buffer (which now has both requests, first then second). My patch partially solves the problem in this case because our requests are always satisfied by one read and using ptr will pass parseRTSPRequestString the second request. Perhaps the correct protection for this lies at a higher level where we can prevent the next request from being handled until the resetRequestBuffer is complete? Geoff ======================= CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. _____ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, September 12, 2007 9:01 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Race condition bug fix The following fix prevents a bug when two requests are processed in close proximity. No, the original code was correct. It's possible that an incoming RTSP request will require more than one socket read in order to obtain all the data for the request. In that case, the length of the request data - as passed to "parseRTSPRequestString()" - must be "fRequestBytesAlreadySeen", not "bytesRead". What specifically was causing you problems with the original code? Can you describe a specific sequence of incoming RTSP requests that was causing problems?? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070913/36028968/attachment.html From finlayson at live555.com Thu Sep 13 12:17:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Sep 2007 12:17:23 -0700 Subject: [Live-devel] Race condition bug fix In-Reply-To: <200709131427.l8DER22X077511@ns.live555.com> References: <200709131427.l8DER22X077511@ns.live555.com> Message-ID: >I agree that in the case of two reads to build a request, my code >does not pass the correct length, however there is still a problem. >Sorry I did not explain it fully in my original mail. > >In our use of the server, the client often makes two requests for a >pair of streams from the server. Therefore two requests arrive very >closely in time. The second starts processing after the first is >read but before resetRequestBuffer() resets the >fRequestBytesAlreadySeen. That's because the first request must not have ended correctly - i.e., with > So the second request is added to the end of the first in the >fRequestBuffer and parseRTSPRequestString is called with a pointer >to the beginning of the buffer (which now has both requests, first >then second). Ditto. I suspect that the first request is not well-formed, so the server is not recognizing when it's ending. Mostl likely this is because it doesn't end with . What is your RTSP client? (If your RTSP client used our software, then you wouldn't have this problem :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070913/e90f014c/attachment.html From dimazzz80 at mail.ru Fri Sep 14 00:30:57 2007 From: dimazzz80 at mail.ru (=?koi8-r?Q?=E4=C9=CD=C1_=FA=C9=CE=DE=C5=CE=CB=CF?=) Date: Fri, 14 Sep 2007 11:30:57 +0400 Subject: [Live-devel] =?koi8-r?b?IlRoZSB0b3RhbCByZWNlaXZlZCBmcmFtZSBzaXpl?= =?koi8-r?b?IGV4Y2VlZHMgdGhlIGNsaWVudCdzIGJ1ZmZlciBzaXplIg==?= In-Reply-To: References: Message-ID: After I connect to the server openRTSP starts to output messages like "MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (20000). 123 bytes of trailing data will be dropped!" Where can I increase this buffer size? Thanks, Dmitry Zinchenko PS I found the bug that prevented transmitting my stream - it was wrong fDurationInMicroseconds passed for the first frame (I calculated it as an average for previous frames). From finlayson at live555.com Fri Sep 14 01:30:17 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Sep 2007 01:30:17 -0700 Subject: [Live-devel] =?koi8-r?b?IlRoZSB0b3RhbCByZWNlaXZlZCBmcmFtZSBzaXpl?= =?koi8-r?b?IGV4Y2VlZHMgdGhlIGNsaWVudCdzIGJ1ZmZlciBzaXplIg==?= In-Reply-To: References: Message-ID: >After I connect to the server openRTSP starts to output messages >like "MultiFramedRTPSource::doGetNextFrame1(): The total received >frame size exceeds the client's buffer size (20000). 123 bytes of >trailing data will be dropped!" >Where can I increase this buffer size? See the online "openRTSP" documentation. This is explained there. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Ambra.Cristaldi at elsagdatamat.com Fri Sep 14 01:57:48 2007 From: Ambra.Cristaldi at elsagdatamat.com (Cristaldi Ambra) Date: Fri, 14 Sep 2007 10:57:48 +0200 Subject: [Live-devel] Continous Streaming of m4e files Message-ID: <268315E5844A704AB431589863FE8EEFCA91EC@els00wmx04.elsag.it> Hello. We're trying to use Live555 code in order to implement a H24 network video recorder (NVR). Apparently, the Live555 stuff performs quite well both in recording m4e files, and in restreaming the recorded files, but we're in deep troubles trying to customize a detail in the mechanism of restreaming when switching from one file to the next: simply, we can't find where in the code this is implemented. I know we're admitting some sort of incompetence, but it's been several days of code hunting, and we got nothing. So, let's first explain why we're having this peculiar problem, and why the playlist mechanism already implemented in Live555 doesn't suit our needs. The H24 continuous recording is based on a circular queue of files that are recorded and cyclically deleted at the end of the queue to keep a roughly constant space on hard disk. Upon this, let's say, circular playlist, you may ask the NVR to start streaming from a given time in the past on, and in H24 mode as well. This means that the DVR will stream, perhaps, files that still have to be created at the time you issue the play command. Even the m4e pathnames are not fully determined in advance. So, the basic idea is the following: find out where Live555 is becoming aware of the end of a m4e file and, through a callback routine that wouldn't impact on the Live555 project source code, insert a new m4e file to the current playlist, maybe deleting also the last file just streamed. In this way the streaming process may continue indefinitely (if requested to) adding one file at a time whose pathname may be calculated at runtime depending on the particular naming policy of the NVR. Also, we hope that in this way we should be able to stream files upon the very same RTSP/RTP session with no noticeable delay when the file switch occurs, exactly as if we were streaming a single endless file. We don't know whether this situation may be general enough to interest a wider audience, but we're stuck, as I said, in the effort of trying to find out where the callback routine should be invoked. Could you provide us some direction? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070914/9b801fb8/attachment.html From weiyutao36 at 163.com Fri Sep 14 02:07:23 2007 From: weiyutao36 at 163.com (Yutao Wei) Date: Fri, 14 Sep 2007 17:07:23 +0800 (CST) Subject: [Live-devel] about a movie transmission Message-ID: <869075381.1126481189760843996.JavaMail.coremail@bj163app119.163.com> Hello everyone, I have a question: can live555 transmit a movie clip which has a H.264video and some type of audio, e.g. AAC? If it can do this, what should Ido more? Now I can only transmit H.264 video file(of RTP format andAnnex B format). And, where can I get a video clip which contains video (of H.264 type) and audio (a certain type)? I searched on the Internet but got nothing.What file format does such a video clip have? What suffix does it use as its extension name? (maybe .mov/.mp4). Now, I even do not know what the format of such a video clip looks like. Does it has a fixed format? Thanks in advance. -- Wei Yu-tao2007-09-14 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070914/18b877fb/attachment.html From finlayson at live555.com Fri Sep 14 02:15:50 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Sep 2007 02:15:50 -0700 Subject: [Live-devel] Continous Streaming of m4e files In-Reply-To: <268315E5844A704AB431589863FE8EEFCA91EC@els00wmx04.elsag.it> References: <268315E5844A704AB431589863FE8EEFCA91EC@els00wmx04.elsag.it> Message-ID: >the playlist mechanism already implemented in Live555 Are you referring to "ByteStreamMultiFileSource"? From your description, it sounds like you could use this as the basis for your implementation. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070914/3e0ee883/attachment.html From finlayson at live555.com Fri Sep 14 02:23:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Sep 2007 02:23:07 -0700 Subject: [Live-devel] about a movie transmission In-Reply-To: <869075381.1126481189760843996.JavaMail.coremail@bj163app119.163.com> References: <869075381.1126481189760843996.JavaMail.coremail@bj163app119.163.com> Message-ID: > I have a question: can live555 transmit a movie clip which has a > >H.264 video and some type of audio, e.g. AAC? No, not at present. (Such a file would be a MPEG-4 file (i.e., ".mp4"), but we currently do not have a demultipexor for such files.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Ambra.Cristaldi at elsagdatamat.com Fri Sep 14 02:58:24 2007 From: Ambra.Cristaldi at elsagdatamat.com (Cristaldi Ambra) Date: Fri, 14 Sep 2007 11:58:24 +0200 Subject: [Live-devel] Continous Streaming of m4e files Message-ID: <268315E5844A704AB431589863FE8EEFCA9246@els00wmx04.elsag.it> Thanks for your quick replay. In effect, we're tring to use the "ByteStreamMultiFileSource" class to do a sort of "playlist". We'd like to understand where/how, during the streaming, this object manages the step from one file to the next one, in the input Array. In fact, we can't know previously the array dimension, because we have no idea about the number of files we're going to stream. We would also modify the array runtime (*if possible* can we do this operation without recreating the ByteStreamMultiFileSource object?) ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: venerd? 14 settembre 2007 11.16 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Continous Streaming of m4e files the playlist mechanism already implemented in Live555 Are you referring to "ByteStreamMultiFileSource"? >From your description, it sounds like you could use this as the basis for your implementation. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070914/d788cb26/attachment-0001.html From gcleary at sightlogix.com Fri Sep 14 04:10:06 2007 From: gcleary at sightlogix.com (Geoff Cleary) Date: Fri, 14 Sep 2007 07:10:06 -0400 Subject: [Live-devel] Race condition bug fix Message-ID: <7066473a0709140410q422028cek2161fa7ec5460d10@mail.gmail.com> Ross I have found out more about what the client (Genetec V4.0) is doing. It is trying to pipeline requests for two Unicast streams. It expects the two streams to play concurrently, however the server assigns the same session IDs. What do you think standard behavior should be in this regard? I have attached a trace from Wireshark. The race condition occurs when two pipelined requests come in. Thanks for your help, Geoff -------------- next part -------------- >I agree that in the case of two reads to build a request, my code >does not pass the correct length, however there is still a problem. >Sorry I did not explain it fully in my original mail. > >In our use of the server, the client often makes two requests for a >pair of streams from the server. Therefore two requests arrive very >closely in time. The second starts processing after the first is >read but before resetRequestBuffer() resets the >fRequestBytesAlreadySeen. That's because the first request must not have ended correctly - i.e., with > So the second request is added to the end of the first in the >fRequestBuffer and parseRTSPRequestString is called with a pointer >to the beginning of the buffer (which now has both requests, first >then second). Ditto. I suspect that the first request is not well-formed, so the server is not recognizing when it's ending. Mostl likely this is because it doesn't end with . What is your RTSP client? (If your RTSP client used our software, then you wouldn't have this problem :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Pipelined.txt Url: http://lists.live555.com/pipermail/live-devel/attachments/20070914/63819432/attachment.txt From finlayson at live555.com Fri Sep 14 07:04:21 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Sep 2007 07:04:21 -0700 Subject: [Live-devel] Continous Streaming of m4e files In-Reply-To: <268315E5844A704AB431589863FE8EEFCA9246@els00wmx04.elsag.it> References: <268315E5844A704AB431589863FE8EEFCA9246@els00wmx04.elsag.it> Message-ID: >In effect, we're tring to use the "ByteStreamMultiFileSource" >class to do a sort of "playlist". >We'd like to understand where/how, during the streaming, this object >manages the step from one file to the next one This is done in "ByteStreamMultiFileSource::onSourceClosure()" and "ByteStreamMultiFileSource::onSourceClosure1()". Note that you should not modify the existing "ByteStreamMultiFileSource " code, but instead write your own, new class. That way, you won't be affected each time you need to upgrade to the latest version of the "LIVE555 Streaming Media" code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070914/9b8acc00/attachment.html From finlayson at live555.com Fri Sep 14 07:49:26 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Sep 2007 07:49:26 -0700 Subject: [Live-devel] Race condition bug fix In-Reply-To: <7066473a0709140410q422028cek2161fa7ec5460d10@mail.gmail.com> References: <7066473a0709140410q422028cek2161fa7ec5460d10@mail.gmail.com> Message-ID: First, there is non't really a "race condition" going on here, because our server code is single-threaded. Also, you are using an old version of the "LIVE555 Streaming Media" code. You will need to upgrade to the latest version of the code. (No support is given for old versions of the code.) Also, your trace shows that you have modified the server code (because the "PLAY" responses include a header "Range: npt=now-", which our server code does not generate. In general, we don't support the code once it has been modified. But anyway, your real problem simply seems to be that you have given your client incorrect "rtsp://" URLs. You should not include the "/trackID=1". Instead, just use rtsp://192.168.50.163:554/mpeg1 and rtsp://192.168.50.163:554/mpeg2 You are getting away with this with "DESCRIBE", "SETUP" and "PLAY" (although for "PLAY" I'm not sure how), but you are finally tripping up when you get to "TEARDOWN". From what I can tell, the problem has nothing to do with 'two requests coming in one after the other'. Try again, using the latest (unmodified) version of the code, and giving your client a correct "rtsp://" URL. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gcleary at sightlogix.com Fri Sep 14 09:40:47 2007 From: gcleary at sightlogix.com (Geoff Cleary) Date: Fri, 14 Sep 2007 12:40:47 -0400 Subject: [Live-devel] Race condition bug fix In-Reply-To: Message-ID: <200709141641.l8EGfYTi098576@ns.live555.com> See embedded comment below. Geoff > -----Original Message----- > From: live-devel-bounces at ns.live555.com [mailto:live-devel- > bounces at ns.live555.com] On Behalf Of Ross Finlayson > Sent: Friday, September 14, 2007 10:49 AM > To: LIVE555 Streaming Media - development & use > Subject: Re: [Live-devel] Race condition bug fix > > First, there is non't really a "race condition" going on here, > because our server code is single-threaded. The handling of the request buffer has not changed in the latest code, and when two DESCRIBE requests are pipelined, the second is not handled correctly. I think this is a problem in your latest version too. This problem caused the sever to seg fault. Could it be that the send of the response could block and allow the main loop to start handling of the second DESCRIBE before the request buffer has been reset? > But anyway, your real problem simply seems to be that you have given > your client incorrect "rtsp://" URLs. You should not include the > "/trackID=1". Instead, just use > rtsp://192.168.50.163:554/mpeg1 > and > rtsp://192.168.50.163:554/mpeg2 Thanks so much for your help. I'll try your suggestion. We do understand your position regarding modified code and use of the latest versions. From finlayson at live555.com Fri Sep 14 12:43:04 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Sep 2007 12:43:04 -0700 Subject: [Live-devel] Race condition bug fix In-Reply-To: <200709141641.l8EGfYTi098576@ns.live555.com> References: <200709141641.l8EGfYTi098576@ns.live555.com> Message-ID: >when two DESCRIBE requests are pipelined, But that's not what you showed in the trace that you included in your earlier message. That trace showed DESCRIBE, SETUP, PLAY, DESCRIBE, SETUP, PLAY - all handled correctly - with only a trailing TEARDOWN not handled correctly (because the URL was bad). > the second is not handled >correctly. I think this is a problem in your latest version too. You should upgrade, to confirm this. > This >problem caused the sever to seg fault. This is the first time you've mentioned a seg fault. If that happens, then there's definitely a bug in the server code. Please add #define DEBUG 1 to the start of "RTSPServer.cpp", and recompile. This will generate debugging output. Then try to reproduce the problem that's causing the crash, then please send us the debugging output. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From lroels at hotmail.com Sun Sep 16 23:42:41 2007 From: lroels at hotmail.com (Luc Roels) Date: Mon, 17 Sep 2007 06:42:41 +0000 Subject: [Live-devel] ScheduleDelayedTask Message-ID: Hi, I am expiriencing a strange problem. I have written a video client capable of receiving up to 16 simultaneous video streams, decode and display them. Here's a snippet from my reception routine... All very standard. while(m_bSourceActive) { g_cWatchVariable = 0x00; psData = &m_sTrack.sPostReadData; if(psData->iWaiting==0x00) { psData->iWaiting= 0x01; psData->uiSize = 0; m_sTrack.poSource->getNextFrame(psData->pucBuffer,psData->iMaxBufLen,HandlePostRead,(void*) psData,NULL,NULL); } // Create a task that will be called if no data is received for over 10 seconds task = m_poTaskScheduler->scheduleDelayedTask( i64TimeOut, NoDataReceived, (void*)this ); // Stop the current thread of control from proceeding, // but allows delayed tasks (and/or background I/O handling) to proceed. // A 'g_cWatchVariable' != 0 resumes the program flow, // so HandlePostRead should set g_cWatchVariable to nonzero m_poTaskScheduler->doEventLoop(&g_cWatchVariable); // Remove the task m_poTaskScheduler->unscheduleDelayedTask( task ); .... } The reception routine runs in a thread, so when decoding 16 video streams I have 16 simultaneous threads running. It all works fine for a while ( sometimes several hours ) but then occasionally I fall into the NoDataReceived callback, which would mean I have not received any data for over 10 seconds. However, if I point the camera at myself I see real time movement up to the moment that the callback is triggered, so there is no way I could have had no reception of data for more than 10 seconds. Any ideas what could be wrong? Is the scheduleDelayedTask malfunctioning under certain conditions ( heavy CPU load?? ) best regards, Luc Roels _________________________________________________________________ Ontwerp je eigen Space op het net en deel wat je lief is met je vrienden! http://spaces.live.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070916/1c32e6e9/attachment.html From finlayson at live555.com Sun Sep 16 23:47:45 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 16 Sep 2007 23:47:45 -0700 Subject: [Live-devel] ScheduleDelayedTask In-Reply-To: References: Message-ID: >The reception routine runs in a thread, so when decoding 16 video >streams I have 16 simultaneous threads running. Have you read the FAQ entry that discusses threads?? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From lroels at hotmail.com Mon Sep 17 00:22:12 2007 From: lroels at hotmail.com (Luc Roels) Date: Mon, 17 Sep 2007 07:22:12 +0000 Subject: [Live-devel] (no subject) Message-ID: Hi Ross, Yes I have. Each thread runs its own "UsageEnvironment" and "TaskScheduler" objects, so it should be okay! Luc Message: 7Date: Sun, 16 Sep 2007 23:47:45 -0700From: Ross Finlayson Subject: Re: [Live-devel] ScheduleDelayedTaskTo: LIVE555 Streaming Media - development & useMessage-ID: Content-Type: text/plain; charset='us-ascii' ; format='flowed'>The reception routine runs in a thread, so when decoding 16 video >streams I have 16 simultaneous threads running.Have you read the FAQ entry that discusses threads??-- _________________________________________________________________ Een dagje naar het strand? Neem je vrienden mee! http://get.libe.com/mobile/messenger -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070917/e8ad28b6/attachment.html From bobbygao at gmail.com Mon Sep 17 03:01:31 2007 From: bobbygao at gmail.com (Bo Gao) Date: Mon, 17 Sep 2007 12:01:31 +0200 Subject: [Live-devel] Why does Live555 not support mp4? Message-ID: Dear Ross Finlayson, Could you tell me what the reason is for not supporting mpeg-4? We can imagine it is just lack of time, or not a high priority for the live555 developers. In that case, we (if we have the time) or someone else could jump in and contribute code. On the other hand, if there are licensing issues or other legal or "political" reasons this is not an option, and it would be good to know those reasons. Thanks a lot, Bo Gao From finlayson at live555.com Mon Sep 17 07:03:24 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Sep 2007 07:03:24 -0700 Subject: [Live-devel] Why does Live555 not support mp4? In-Reply-To: References: Message-ID: >Could you tell me what the reason is for not supporting mpeg-4? Not every feature can be implemented at the same time. Support for demultiplexing (and thus streaming) ".mp4" files is on our 'to do' list, and will be implemented someday (don't ask when), but to date other features have had higher priority. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gcleary at sightlogix.com Mon Sep 17 12:27:07 2007 From: gcleary at sightlogix.com (Geoff Cleary) Date: Mon, 17 Sep 2007 15:27:07 -0400 Subject: [Live-devel] Pipelined request Seg Fault In-Reply-To: Message-ID: <200709171927.l8HJRpo3060089@ns.live555.com> > This problem caused the sever to seg fault. > > This is the first time you've mentioned a seg fault. If that > happens, then there's definitely a bug in the server code. > > Please add > #define DEBUG 1 > to the start of "RTSPServer.cpp", and recompile. This will generate > debugging output. Then try to reproduce the problem that's causing > the crash, then please send us the debugging output. > -- > > 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 Ross Attached is the command line log as you requested. The client sends two Describes on the same rtsp connection: DESCRIBE rtsp://192.168.50.123:554/mpeg4/1/media.amp/trackID=1 RTSP/1.0 CSeq: 1 Authorization: Basic c2lnaHRsb2dpeDpwdXNoMmVkZw== DESCRIBE rtsp://192.168.50.123:554/mpeg4/2/media.amp/trackID=1 RTSP/1.0 CSeq: 2 Authorization: Basic c2lnaHRsb2dpeDpwdXNoMmVkZw== The Response is: RTSP/1.0 200 OK CSeq: 1 Date: Mon, Sep 17 2007 18:58:20 GMT Content-Base: rtsp://192.168.50.123/mpeg4/1/media.amp/ Content-Type: application/sdp Content-Length: 532 v=0 o=- 1190055486773173 1 IN IP4 192.168.50.123 s=Video Stream 1 i=SightLogix Intelligent Surveillance Camera t=0 0 a=tool:LIVE555 Streaming Media v2006.12.31 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Video Stream 1 a=x-qt-text-inf:SightLogix Intelligent Surveillance Camera m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=245;config=000001B0F5000001B50D4F000001000000012008C4F80815 8BA98514041E1498000001B2656D347620342E352E302E3300C6FF a=control:track1 And the client sends: SETUP rtsp://192.168.50.123:554/mpeg4/1/media.amp/trackID=1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=15020-15021 The log shows that the second describe causes parseRTSPRequestString()to be called with a pointer to the first DESCRIBE. Thanks for looking at this, Geoff -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SegFaultLog.txt Url: http://lists.live555.com/pipermail/live-devel/attachments/20070917/10127e0c/attachment.txt From prn57r at gmail.com Mon Sep 17 19:47:38 2007 From: prn57r at gmail.com (Mark Hingston) Date: Tue, 18 Sep 2007 12:47:38 +1000 Subject: [Live-devel] Can't connect to BBC Radio WMA streams via rtsp Message-ID: >>Sending request: SETUP rtsp://wmlive.bbc.co.uk/wms/bbc7/hi_s1/audio RTSP/1.0 >>CSeq: 3 >>Transport: RTP/AVP;unicast;client_port=33094-33095 >>User-Agent: VLC media player (LIVE555 Streaming Media v2006.03.16) >> >> >>Received SETUP response: RTSP/1.0 400 Bad Request >>Date: Thu, 13 Sep 2007 07:25:45 GMT >>CSeq: 3 >>Server: WMServer/9.1.1.3814 >>Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, >>com.microsoft.wm.eosmsg, com.microsoft.wm.fastcache, >>com.microsoft.wm.packetpairssrc, com.microsoft.wm.startupprofile > >Blame Microsoft for this. Their server ("WMServer") is not a >standards-compliant RTSP server. You will need to find out - from >Microsoft - why their server is not handling our RTSP "SETUP" >request. (Good luck :-) > >In any case, though, even if you could get Microsoft's server to work >with our RTSP client, VLC would not be able to play this stream, >because we do not handle the (Microsoft-proprietary) "x-asf-pf" and >"x-wms-rtx" RTP payload formats, nor the codecs that these RTP >payload formats carry. (See >) > >To summarize: Don't bother trying to play streams from a "WMServer". >Use a non-Microsoft server instead. Unfortunately, I don't have the option to just ignore Microsoft servers. Fortunately though, I've solved the problem and it turns out to be quite a simple solution. I've attached the entire RTSP conversation that successfully connects to a WM Server at the BBC. The important part seems to be that the WM server returns a control parameter that looks like: a=control:rtsp://wmlive.bbc.co.uk/wms%5Cbbc7%5Chi_s1/ but, in the failed attempts to connect to the WM Server, I was sending the SETUP and PLAY commands to: rtsp://wmlive.bbc.co.uk/wms/bbc7/hi_s1/ because it seems that the live555 client ignores the control parameter returned in the DESCRIBE and continues to use the original URL that I gave it. SO, when i send SETUP and PLAY to: rtsp://wmlive.bbc.co.uk/wms%5Cbbc7%5Chi_s1/ I can connect to the BBC and download their stream without a problem (using a SimpleRTPSource). I'm not sure whether the server or client is at fault here, I'll leave that up to you guys to decide. Mark Hingston -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070917/0085520d/attachment-0001.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: markClient-successful.txt Url: http://lists.live555.com/pipermail/live-devel/attachments/20070917/0085520d/attachment-0001.txt From finlayson at live555.com Tue Sep 18 00:55:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Sep 2007 00:55:07 -0700 Subject: [Live-devel] Pipelined request Seg Fault In-Reply-To: <200709171927.l8HJRpo3060089@ns.live555.com> References: <200709171927.l8HJRpo3060089@ns.live555.com> Message-ID: Thanks for sending the debug trace. However, I'm puzzled by this, because (for now, at least) I can't see how it is possible (in the current version of the code) for the server to receive two "DESCRIBE" commands in succession, without sending a response to the first command inbetween. (I assume that you're not doing something dumb like running the RTSP server code in more than one thread.) Please upgrade to the latest version of the code, and let us know if the problem still occurs. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From slaine at slaine.org Tue Sep 18 09:05:52 2007 From: slaine at slaine.org (Glen Gray) Date: Tue, 18 Sep 2007 17:05:52 +0100 Subject: [Live-devel] RTSP Server 'Keep Alive' support In-Reply-To: References: <46E70C65.4040000@lincor.com> Message-ID: <46EFF760.3040305@slaine.org> Hey guys, Further to my previous questions on this. I'm wondering how to activate this feature and I'm still not sure on the standards as it's not my area of expertise. From what I can see in RFC2326, the servers response to SETUP is to populate the Transport: field with the timeout period in seconds ("...; timeout=60;"). I can't see this in the RTSPServer.cpp code (lines 797 - 838 is where I looked) or in the response I'm getting back from the server (attached below) To get this to work on the Kasenna's you've to notify the server that you want it to use KeepAlive support. This is done in a pretty strange way, by setting the User-Agent string to have an _KA appended to the end. Is there anything I should be doing in VLC's demuxer to get mediaServer to use KeepAlive ? I'd previously submitted a patch to parse out the timeout value in the RTSPClient code. VLC checks for this value and then sets up the GET_PARAMETER sending function to fire every timeout-2 seconds I'm testing with vlc-0.8.6c against the current live release and the mediaServer streaming an mpeg2 file. As you can see below, there's nothing coming back for me to trap. And with no activity (vlc doesn't send RTCP "RR" packets) live's mediaServer just keeps on serving to the client. Thanks in advance for any help you can give on this. Remote control interface initialized. Type `help' for help. Sending request: OPTIONS rtsp://192.168.2.31:8554/bourne.ts RTSP/1.0 CSeq: 1 User-Agent: VLC media player (LIVE555 Streaming Media v2007.08.03) Received OPTIONS response: RTSP/1.0 200 OK CSeq: 1 Date: Tue, Sep 18 2007 15:13:04 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: DESCRIBE rtsp://192.168.2.31:8554/bourne.ts RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2007.08.03) Received DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Tue, Sep 18 2007 15:13:04 GMT Content-Base: rtsp://192.168.2.31:8554/bourne.ts/ Content-Type: application/sdp Content-Length: 393 Need to read 393 extra bytes Read 393 extra bytes: v=0 o=- 1190128384983870 1 IN IP4 192.168.2.31 s=MPEG Transport Stream, streamed by the LIVE555 Media Server i=bourne.ts t=0 0 a=tool:LIVE555 Streaming Media v2007.08.03 a=type:broadcast a=control:* a=range:npt=0-6238.254 a=x-qt-text-nam:MPEG Transport Stream, streamed by the LIVE555 Media Server a=x-qt-text-inf:bourne.ts m=video 0 RTP/AVP 33 c=IN IP4 0.0.0.0 a=control:track1 Sending request: SETUP rtsp://192.168.2.31:8554/bourne.ts/track1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=32784-32785 User-Agent: VLC media player (LIVE555 Streaming Media v2007.08.03) Received SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Tue, Sep 18 2007 15:13:04 GMT Transport: RTP/AVP;unicast;destination=192.168.2.215;source=192.168.2.31;client_port=32784-32785;server_port=6970-6971 Session: 1 Sending request: PLAY rtsp://192.168.2.31:8554/bourne.ts/ RTSP/1.0 CSeq: 4 Session: 1 Range: npt=0.000- User-Agent: VLC media player (LIVE555 Streaming Media v2007.08.03) Received PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Tue, Sep 18 2007 15:13:04 GMT Range: npt=0.000- Session: 1 RTP-Info: url=rtsp://192.168.2.31:8554/bourne.ts/track1;seq=7191;rtptime=1800190741 Ross Finlayson wrote: >> Wondering if the liveMedia/RTSPServer.cpp code has support for 'Keep >> Alive' functionality ? >> > > Yes. Note the "reclamationTestSeconds" parameter (default value, 45 > seconds) in "RTSPServer::createNew()". > > >> I see from the source code that it accepts the GET_PARAMETER calls and >> responds to the client, but doesn't seem to do anything regarding the >> session. >> > > Yes it does. The server treats either an incoming RTCP "RR" packet, > or any RTSP command (not just "GET_PARAMETER") as indicating client > liveness. > > Note, though, that if you requested RTP-over-TCP streaming, then > (because of software limitations) the server will not see any RTSP > requests after "PLAY". However, incoming RTCP "RR" packets will > always be handled (and used to indicate client liveness). > > All standards-clompliant RTSP/RTP clients should send RTCP "RR" packets. > -- Glen Gray From slaine at slaine.org Tue Sep 18 10:53:46 2007 From: slaine at slaine.org (Glen Gray) Date: Tue, 18 Sep 2007 18:53:46 +0100 Subject: [Live-devel] RTSP Server 'Keep Alive' support In-Reply-To: <46EFF760.3040305@slaine.org> References: <46E70C65.4040000@lincor.com> <46EFF760.3040305@slaine.org> Message-ID: <46F010AA.7050803@slaine.org> Sorry, meant to say Session field not Transport field in the below paragraph Glen Gray wrote: > SETUP is to populate the Transport: field with the timeout period in > seconds ("...; timeout=60;"). I can't see this in the RTSPServer.cpp > code (lines 797 - 838 is where I looked) or in the response I'm getting > back from the server (attached below) > -- Glen Gray From finlayson at live555.com Tue Sep 18 12:13:34 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Sep 2007 12:13:34 -0700 Subject: [Live-devel] RTSP Server 'Keep Alive' support In-Reply-To: <46EFF760.3040305@slaine.org> References: <46E70C65.4040000@lincor.com> <46EFF760.3040305@slaine.org> Message-ID: >Further to my previous questions on this. I'm wondering how to activate >this feature It is activated by default! You already have it. Our server does not set the "timeout=" field in its responses (because it uses incoming RTCP "RR" packets, as well as incoming RTSP commands, to indicate client liveness - therefore, for our server, clients don't need to send periodic "GET_PARAMETER" RTSP commands), but it is activated by default. As I noted earlier: > > Yes. Note the "reclamationTestSeconds" parameter (default value, 45 > > seconds) in "RTSPServer::createNew()". >Is there anything I should be doing in VLC's demuxer to get mediaServer >to use KeepAlive ? > >I'd previously submitted a patch to parse out the timeout value in the >RTSPClient code. VLC checks for this value and then sets up the >GET_PARAMETER sending function to fire every timeout-2 seconds You don't need this with our server. As long as VLC sends periodic RTCP "RR" packets - which it does - then our server will use that to indicate client liveness. >And with no activity (vlc doesn't send RTCP "RR" packets) Yes it does! Where did you get the idea that it doesn't? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yyang at commscope.com Tue Sep 18 14:31:01 2007 From: yyang at commscope.com (yyang at commscope.com) Date: Tue, 18 Sep 2007 16:31:01 -0500 Subject: [Live-devel] can't stream - unsupported RTSP server error Message-ID: Hi, I have two FC6 boxes. One is named server the other called workstation. They are back to back connected via a Gigabit ethernet link. There is no switch, router or any firewall in between. The network connectivity between them works fine ( I can ping, I can mount a directory using nfs, etc...). My goal is to stream a video from the server to workstation using mplayer. The video clip is called hd.avi and is saved in /root/share. One Server, I downloaded the Live server (live555MediaServer for Linux), and made it running. On workstation, I had built and installed (copied) the live555 client (that is live.2007.08.03a.tar.gz). I donwloaded the mplayer source (the latest Subversion snapshot). Configured it and saw it detected the live555 libs. Then did make and make install, no error. I can play the same video file locally on workstation. The mplayer works fine. But when I ran mplayer stream. I got the "unsupported RTSP server" error as below. Any idea what's wrong? [root at workstation mplayer-checkout-2007-09-18]# mplayer rtsp://server/root/share/hd.avi MPlayer dev-SVN-r24562-4.1.1 (C) 2000-2007 MPlayer Team CPU: AMD Opteron(tm) Processor 256 (Family: 15, Model: 37, Stepping: 1) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 Playing rtsp://server/root/share/hd.avi. Resolving server for AF_INET6... Couldn't resolve name for AF_INET6: server Resolving server for AF_INET... Connecting to server server[169.254.15.100]: 554... librtsp: server responds: 'RTSP/1.0 404 Stream Not Found' rtsp_session: unsupported RTSP server. Server type is 'unknown'. STREAM_LIVE555, URL: rtsp://server/root/share/hd.avi Stream not seekable! file format detected. Failed to get a SDP description from URL "rtsp://server/root/share/hd.avi": cannot handle DESCRIBE response: RTSP/1.0 404 Stream Not Found Exiting... (End of file) root at workstation mplayer-checkout-2007-09-18]# Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070918/279cdac6/attachment.html From finlayson at live555.com Tue Sep 18 14:41:02 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Sep 2007 14:41:02 -0700 Subject: [Live-devel] can't stream - unsupported RTSP server error In-Reply-To: References: Message-ID: >But when I ran mplayer stream. I got the "unsupported RTSP server" >error as below. Any idea what's wrong? The real error is the "404 Stream Not Found" error from the RTSP server. The "LIVE555 Media Server" returns this error because it does not support ".avi" files. See for a description of the types of files that can be streamed by the "LIVE555 Media Server". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070918/23caaeb5/attachment.html From yyang at commscope.com Tue Sep 18 15:06:01 2007 From: yyang at commscope.com (yyang at commscope.com) Date: Tue, 18 Sep 2007 17:06:01 -0500 Subject: [Live-devel] can't stream - unsupported RTSP server error In-Reply-To: Message-ID: Ross, The instructioins say media file must be stored in the current working directory. What is the current working directory? My Live server is saved in /root. Frank Ross Finlayson Sent by: live-devel-bounces at ns.live555.com 09/18/2007 04:41 PM Please respond to LIVE555 Streaming Media - development & use To LIVE555 Streaming Media - development & use cc Subject Re: [Live-devel] can't stream - unsupported RTSP server error But when I ran mplayer stream. I got the "unsupported RTSP server" error as below. Any idea what's wrong? The real error is the "404 Stream Not Found" error from the RTSP server. The "LIVE555 Media Server" returns this error because it does not support ".avi" files. See for a description of the types of files that can be streamed by the "LIVE555 Media 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070918/596e7376/attachment-0001.html From yyang at commscope.com Tue Sep 18 15:31:31 2007 From: yyang at commscope.com (yyang at commscope.com) Date: Tue, 18 Sep 2007 17:31:31 -0500 Subject: [Live-devel] can't stream - unsupported RTSP server error In-Reply-To: Message-ID: Ross, > The real error is the "404 Stream Not Found" error from the RTSP server. The "LIVE555 Media Server" returns this error because it does not support >".avi" files. >See for a description of the types of files that can be streamed by the "LIVE555 Media Server". I have a MPEG-1 or 2 Program Stream file (with file name suffix ".mpg"). I tried it, same error. When I ran the server, since it is executible, I ran it by entering /root/livemediaserver but the video clip (video2.mpg) is saved in /root/share How should run mplayer rtsp://server should I mplayer rtsp://server/share/video2.mpg or mplayer rtsp://server/video2.mpg Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070918/