From saba at jogajog.com Sun Dec 2 20:45:00 2007 From: saba at jogajog.com (Noor-E-Saba Hakim) Date: Sun, 2 Dec 2007 23:45:00 -0500 (EST) Subject: [Live-devel] audio capture from webcam Message-ID: <20771.24.91.7.35.1196657100.squirrel@www.jogajog.com> Dear all, I need a cross-platform application to grab audio and vido data from webcams to analyze the data. I started with omnimeeting which uses live555 libraries. I compiled it, and it works fine for video (streaming, receiving, playing etc.), but if I enable audio grab then it crashes. I did not get any reply after writing to omnimeeting's mailing list. Could anyone help me here please. I'm working on Windows XP now. Is there any other application or test program or template which grabs audio from webcams using live555's libraries? I'd appreciate your help. Saba From peter at topsdigitalsecurity.com Mon Dec 3 11:51:11 2007 From: peter at topsdigitalsecurity.com (Peter) Date: Mon, 3 Dec 2007 11:51:11 -0800 Subject: [Live-devel] Q:connection time Message-ID: <001c01c835e5$db8b46e0$641e0a0a@PeterMobile> Hi everyone, In playCommon.cpp What do you think it takes about 1 sec to execute these line ? In playCommon.cpp ourClient = createClient(*env, verbosityLevel, progName); char* optionsResponse = getOptionsResponse(ourClient, url); char* sdpDescription = getSDPDescriptionFromURL(ourClient, url, username, password, proxyServerName, proxyServerPortNum,desiredPortNum); session = MediaSession::createNew(*env, sdpDescription); subsession->initiate(simpleRTPoffsetArg) setupStreams(); Please tell me why it does take so long. And if there is a way to reduce time, please give me an advice. Regards. Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071203/d4108abe/attachment.html From jegadishd at gmail.com Mon Dec 3 13:55:11 2007 From: jegadishd at gmail.com (Jegadish) Date: Mon, 3 Dec 2007 23:55:11 +0200 Subject: [Live-devel] Regarding- using '-4' option in openRTSP Message-ID: <87f8e3860712031355l7d77eca0of4d70ba54f4097b7@mail.gmail.com> Hi All, I am using openRTSP program to receive a H.264 encoded video RTP packets. I am using the '-4' options to convert it to a .mp4 file. At the end of the execution, I get a .mp4 file. But it is not in a playable state(vlc does not recognize the contents). The documentation at the live555 web pages say that '-4' option is supported for limited number of codecs. So my question is: does the -4 option creates a complete playable .mp4 file or do I need to edit the file physically, to make it playable. Thanks for any information in this regard. (What I am trying to do with openRTSP:: I am making small modifications to openRTSP, so as to make it establish a media session using a sdp file provided by the user(instead of getting it over RTSP). Similar to what vlc does. ex: vlc ) Regards, jegadish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071203/ddcc8c22/attachment.html From finlayson at live555.com Mon Dec 3 14:38:47 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 3 Dec 2007 14:38:47 -0800 Subject: [Live-devel] Regarding- using '-4' option in openRTSP In-Reply-To: <87f8e3860712031355l7d77eca0of4d70ba54f4097b7@mail.gmail.com> References: <87f8e3860712031355l7d77eca0of4d70ba54f4097b7@mail.gmail.com> Message-ID: >The documentation at the live555 web pages say that '-4' option is >supported for limited number of codecs. So my question is: does the >-4 option creates a complete playable .mp4 file or do I need to edit >the file physically, to make it playable. H.264 support in MPEG-4 format files is supported, but apparently not completely. (Support for the H.264 video codec was provided by someone else.) If you're inclined to look into this, then the code to look at is "QuickTimeFileSink.cpp". As always, when you're using the "-4" or "-q" option with a video stream, be sure to specify the correct frame width, height and frame rate, using the "-w", "-h" and "-f" options respectively. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Dec 3 14:43:45 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 3 Dec 2007 14:43:45 -0800 Subject: [Live-devel] Q:connection time In-Reply-To: <001c01c835e5$db8b46e0$641e0a0a@PeterMobile> References: <001c01c835e5$db8b46e0$641e0a0a@PeterMobile> Message-ID: > What do you think it takes about 1 sec to execute these line ? > >In playCommon.cpp [...] > char* optionsResponse = getOptionsResponse(ourClient, url); [...] > char* sdpDescription = getSDPDescriptionFromURL(ourClient, >url, username, password, proxyServerName, >proxyServerPortNum,desiredPortNum); [...] > setupStreams(); These statements each involve round-trip communication with the server, to send the RTSP "OPTIONS", "DESCRIBE", and "SETUP" commands, respectively, and get back a response. Almost all of the elapsed time for these commands comes from the communication with the server. >Please tell me why it does take so long. > >And if there is a way to reduce time, please give me an advice. Yes, communicate with a faster, more responsive 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/20071203/66a869ea/attachment.html From thiyagu_tvr at hotmail.com Mon Dec 3 20:59:57 2007 From: thiyagu_tvr at hotmail.com (thiyaga rajan) Date: Tue, 4 Dec 2007 10:29:57 +0530 Subject: [Live-devel] hi In-Reply-To: References: Message-ID: ________________________________ > Date: Mon, 5 Nov 2007 12:42:13 +0530 > From: pavithra.sd at gmail.com > To: thiyagu_tvr at hotmail.com > Subject: hi > > Hi sneha, > I am pavithra .I got your e-maild id from blackfin forum.I am trying to load a C application into coreb i am not able to compile the kernel along with the C application ,it is showing error such as unable to linke the script bfin-elf-ld.real not such file or directory. > Could you please let me know how you compiled and any modifications needed in the linker script. > Please help me.It is a great favour. > > > Thanks and Regards, > pavithra hi pavi sorry for late reply.i have finished compilation and linking of c++ applications to run on coreB. If u send me ur Makefile,i can help u.And i used this mail-id less frequently.. Use this mail-id:::::: thiyagu.in at gmail.com regards _________________________________________________________________ Tried the new MSN Messenger? It?s cool! Download now. http://messenger.msn.com/Download/Default.aspx?mkt=en-in From finlayson at live555.com Mon Dec 3 21:14:50 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 3 Dec 2007 21:14:50 -0800 Subject: [Live-devel] hi In-Reply-To: References: Message-ID: This mailing list is for discussion of the "LIVE555 Streaming Media" software: . Does your problem relate to this software, and if so, how? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jegadishd at gmail.com Tue Dec 4 13:48:10 2007 From: jegadishd at gmail.com (Jegadish) Date: Tue, 4 Dec 2007 23:48:10 +0200 Subject: [Live-devel] Regarding- using '-4' option in openRTSP In-Reply-To: References: <87f8e3860712031355l7d77eca0of4d70ba54f4097b7@mail.gmail.com> Message-ID: <87f8e3860712041348y29768496ubb475542f5b3f636@mail.gmail.com> Hi, Thanks for your quick reply..it was very helpful.. I looked in the file being produced by the QuickTimeFileSink.cpp. It does not write some mandatory container boxes(like ftyp, moov etc) that are needed to make it a playable mp4 file. Currently looking at the mandatory container box related details. Hope to get it working. If there are any pointers that may help us, in this regard, please let us know. Regards, jegadish On Dec 4, 2007 12:38 AM, Ross Finlayson wrote: > >The documentation at the live555 web pages say that '-4' option is > >supported for limited number of codecs. So my question is: does the > >-4 option creates a complete playable .mp4 file or do I need to edit > >the file physically, to make it playable. > > H.264 support in MPEG-4 format files is supported, but apparently not > completely. (Support for the H.264 video codec was provided by > someone else.) If you're inclined to look into this, then the code > to look at is "QuickTimeFileSink.cpp". > > As always, when you're using the "-4" or "-q" option with a video > stream, be sure to specify the correct frame width, height and frame > rate, using the "-w", "-h" and "-f" options respectively. > -- > > 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/20071204/0f9c67fd/attachment-0001.html From finlayson at live555.com Tue Dec 4 13:55:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Dec 2007 13:55:55 -0800 Subject: [Live-devel] Regarding- using '-4' option in openRTSP In-Reply-To: <87f8e3860712041348y29768496ubb475542f5b3f636@mail.gmail.com> References: <87f8e3860712031355l7d77eca0of4d70ba54f4097b7@mail.gmail.com> <87f8e3860712041348y29768496ubb475542f5b3f636@mail.gmail.com> Message-ID: >Hi, Thanks for your quick reply..it was very helpful.. >I looked in the file being produced by the QuickTimeFileSink.cpp. It >does not write some mandatory container boxes(like ftyp, moov etc) >that are needed to make it a playable mp4 file. Yes it does! Look at the code again. Are you sure that you are ending "openRTSP" properly? You can't just 'kill' the application (e.g., by typing -C). You *must* let "openRTSP" terminate normally (perhaps using the "-d " option), or (if you're on Unix) signalling it with SIGUSR1 or SIGHUP. If you do this, then the 'ftyp' and 'moov' atoms will be added to the file properly at the end. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From lcj.liu at gmail.com Wed Dec 5 00:22:01 2007 From: lcj.liu at gmail.com (lcj.liu at gmail.com) Date: Wed, 5 Dec 2007 16:22:01 +0800 Subject: [Live-devel] RTP Retransmission Message-ID: <47565fa6.1f588c0a.754a.1b7e@mx.google.com> Hello everyone, I've read http://lists.live555.com/pipermail/live-devel/2005-March/002170.html and know that RTP retransmission is not implemented in liveMedia. Could anyone give me some hint what I should do if I want to implement RTP retransmission in liveMedia? Thanks lcj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071205/4b8e2a1f/attachment.html From RGlobisch at csir.co.za Wed Dec 5 03:48:03 2007 From: RGlobisch at csir.co.za (Ralf Globisch) Date: Wed, 05 Dec 2007 13:48:03 +0200 Subject: [Live-devel] Newbie question: Simple RTP/RTCP Server/Client implementation Message-ID: <4756AC12.5DA9.004D.0@csir.co.za> Hi, I'd like to write a simple RTP/RTCP server and client using the live555 libraries. I've previously managed to do the same with jrtplib, but it looks like the live555 libraries are more comprehensive since they offer RTSP and other functionality too. At the same time I'm not quite sure where to start. I'd just like to get a few pointers and want to know if I'm on the right track: So far it looks like I can base a simple test application on testMP3Streamer and testMP3Receiver? One major difference is that I want to control the sending of packets manually and it looks like the scheduler is taking care of it in the examples? In my environment I have a DirectShow filter which is receiving frames and I want to package each of these in an RTP packet and then unicast it to another RTP DirectShow filter. Any suggestions or ideas? Any help is greatly appreciated, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From finlayson at live555.com Wed Dec 5 05:47:17 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Dec 2007 05:47:17 -0800 Subject: [Live-devel] Newbie question: Simple RTP/RTCP Server/Client implementation In-Reply-To: <4756AC12.5DA9.004D.0@csir.co.za> References: <4756AC12.5DA9.004D.0@csir.co.za> Message-ID: >I'd just like to get a few pointers and want to know if I'm on the >right track: >So far it looks like I can base a simple test application on >testMP3Streamer and testMP3Receiver? >One major difference is that I want to control the sending of >packets manually and it looks like the scheduler is taking care of >it in the examples? Not really. Each packet gets sent whenever enough input data arrives for it. For the "testMP3Streamer" example, this happens because the input data is coming from a "MP3FileSource" object. In your application, you would need to write your own "FramedSource" subclass - to use instead of "MP3FileSource" - that encapsulates your input source. (See the FAQ for hints on how you might do that.) You might also be interested in the "Morgan Multimedia RTP DirectShow Filters" - http://www.morgan-multimedia.com/RTP/ - a third-party product that uses the "LIVE555 Streaming Media" software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From RGlobisch at csir.co.za Wed Dec 5 06:02:15 2007 From: RGlobisch at csir.co.za (Ralf Globisch) Date: Wed, 05 Dec 2007 16:02:15 +0200 Subject: [Live-devel] Newbie question: Simple RTP/RTCP Server/Client implementation Message-ID: <4756CB86.5DA9.004D.0@csir.co.za> Hi Ross, Thanks for the prompt feedback and hints ;) It's much appreciated. I actually came across your library via the Morgan RTP Direct Show filters ;) Thanks again, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From oscar.youx at gmail.com Wed Dec 5 06:46:46 2007 From: oscar.youx at gmail.com (oscar lima) Date: Wed, 5 Dec 2007 15:46:46 +0100 Subject: [Live-devel] Video & Audio Properties at RTP Receivers Message-ID: <351e7d280712050646k23ac3c86p754b9e9bd47de0a6@mail.gmail.com> Hi all, I am implementing an RTSP Client using the livemedia and much of work has been done successfully using the lib. Many thanks to developpers. What I need is to discover the properties of any stream, i.e. video width and height for audio and frequency/channels for audio in different formats (for some of them, they are staightforward as they are static with the codec name). I have successfully integrated an MPEG extra data parser, but have some difficulties with the others. So my questions are : 1. For MPA, MPEG1, and 2, H.261 and H.263 where such information seem to be integrated in RTP packets, is there any support in the library that returns them. I have seen soem parsers such as MPEGVideoStreamParser but they are not used at the receiver side. ? 2. For H.264, is there any parser for the extra info returned by parseH264ConfigStr ? Thanks in advance, Youx From finlayson at live555.com Wed Dec 5 09:17:38 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Dec 2007 09:17:38 -0800 Subject: [Live-devel] Video & Audio Properties at RTP Receivers In-Reply-To: <351e7d280712050646k23ac3c86p754b9e9bd47de0a6@mail.gmail.com> References: <351e7d280712050646k23ac3c86p754b9e9bd47de0a6@mail.gmail.com> Message-ID: The properties that you're asking about - video width & height, video frame rate, audio sampling frequency, audio number of channels are almost always contained within the media data themselves, and are therefore accessed by your decoding software (or hardware), when it parses this media data. (A reminder that the "LIVE555 Streaming Media" software does not include decoding software.) I.e., it is the job of your decoder to parse the media data and extract this information. One exception to this is that *some* simple audio codecs (e.g., PCM) do not include the audio sampling frequency and number of channels 'in band'. For these codecs (only), these properties are carried separately, in the stream's SDP description, and can be accessed from the stream's "MediaSubession" object. >2. For H.264, is there any parser for the extra info returned by >parseH264ConfigStr ? This data is a sequence of H.264 NAL units, and are therefore parsed/interpreted by your H.264 decoder. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From xcsmith at rockwellcollins.com Wed Dec 5 11:06:11 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Wed, 5 Dec 2007 13:06:11 -0600 Subject: [Live-devel] Q: incomingRequestHandler1, bytesRead == fRequestSpaceRemaining Message-ID: In RTSPServer::incomingRequestHandler1() conditional "if (bytesRead <= 0 || (unsigned)bytesRead >= fRequestSpaceRemaining)" Q: Is it really a failure if the number of bytes read == the amount of space available? I was thinking that it would be because we wouldn't know if there was more to read or not. Is that right? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071205/a5e2a6ea/attachment.html From jegadishd at gmail.com Wed Dec 5 11:56:15 2007 From: jegadishd at gmail.com (Jegadish) Date: Wed, 5 Dec 2007 21:56:15 +0200 Subject: [Live-devel] Regarding- using '-4' option in openRTSP In-Reply-To: References: <87f8e3860712031355l7d77eca0of4d70ba54f4097b7@mail.gmail.com> <87f8e3860712041348y29768496ubb475542f5b3f636@mail.gmail.com> Message-ID: <87f8e3860712051156p5a4cdb7cr1d6adc09c18ffe7f@mail.gmail.com> Yes, this was the problem. I was ending with CTR+C. Now I see the ftyp box. Then, I got a segmentaion fault in QuickTimeFileSink.cpp (line no. 1775) char* psets = strDup(fCurrentIOState->fOurSubsession.fmtp_spropparametersets()); size_t comma_pos = strcspn(psets, ","); here psets returns null, as I *do not* pass parameter set information in the sdp file. ****sprop-parameter-sets (like a=fmtp:99 profile-level-id=42A01E; packetization-mode=1; sprop-parameter-sets=Z0IACpZTBYmI ) Later a sprop-parameter-sets value was copied from a sample sdp file in rfc 3984. This results in a *playable .mp4 file*. (although the quality was not good..) Based on rfc 3984, it appears that parameter set (sequence and picture are sent in RTP packets, with different NAL type). So, I plan to change the code, so as to pick the parameter set information from RTP packets in addition to sdp file. ---> Please provide informantion on this, if any. (like, if this would make sense) And regarding picture width, height and frame rate information: >From the available information, it appears that width, height information can be retrieved from the parameter sets information. (but not sure about frame rate). If this turns out to be true, then a valid file can be generated without the -w, -h and -f options..Hope this turns to be true.. Thanks for your earlier quick reply...it has really put me on track..Thanks a lot.. Please inform, if you have suggestions/comments on the above data.. Regards, jegadish On Dec 4, 2007 11:55 PM, Ross Finlayson wrote: > >Hi, Thanks for your quick reply..it was very helpful.. > >I looked in the file being produced by the QuickTimeFileSink.cpp. It > >does not write some mandatory container boxes(like ftyp, moov etc) > >that are needed to make it a playable mp4 file. > > Yes it does! Look at the code again. > > Are you sure that you are ending "openRTSP" properly? You can't just > 'kill' the application (e.g., by typing -C). You *must* let > "openRTSP" terminate normally (perhaps using the "-d " > option), or (if you're on Unix) signalling it with SIGUSR1 or SIGHUP. > If you do this, then the 'ftyp' and 'moov' atoms will be added to the > file properly at the end. > -- > > 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/20071205/c5ea038c/attachment-0001.html From oscar.youx at gmail.com Wed Dec 5 13:02:32 2007 From: oscar.youx at gmail.com (oscar lima) Date: Wed, 5 Dec 2007 22:02:32 +0100 Subject: [Live-devel] Video & Audio Properties at RTP Receivers In-Reply-To: References: <351e7d280712050646k23ac3c86p754b9e9bd47de0a6@mail.gmail.com> Message-ID: <351e7d280712051302l19bb6dctc45fbdd2780ec95f@mail.gmail.com> 2007/12/5, Ross Finlayson : > The properties that you're asking about - video width & height, video > frame rate, audio sampling frequency, audio number of channels are > almost always contained within the media data themselves, and are > therefore accessed by your decoding software (or hardware), when it > parses this media data. (A reminder that the "LIVE555 Streaming > Media" software does not include decoding software.) I.e., it is the > job of your decoder to parse the media data and extract this > information. Yes. It is just I am implementing the Livemedia inside a plugin for Windows Media Player where they are required *before* the begining of data processing. I know it's a dshow design problem, so i will have to wait for data and process the first packets to get them. > One exception to this is that *some* simple audio codecs (e.g., PCM) > do not include the audio sampling frequency and number of channels > 'in band'. For these codecs (only), these properties are carried > separately, in the stream's SDP description, and can be accessed from > the stream's "MediaSubession" object. > >2. For H.264, is there any parser for the extra info returned by > >parseH264ConfigStr ? > > This data is a sequence of H.264 NAL units, and are therefore > parsed/interpreted by your H.264 decoder. Just a suggestion... For MPEG4, and H264, these infos are in the SDP so it is possible to have a parser in the livemedia stack I think. Thanks for the answer again, Oscar From peter at topsdigitalsecurity.com Wed Dec 5 15:38:24 2007 From: peter at topsdigitalsecurity.com (Peter) Date: Wed, 5 Dec 2007 15:38:24 -0800 Subject: [Live-devel] Q:error message Message-ID: <000801c83797$ee02cf10$6d01a8c0@PeterMobile> Hi everyone, Please give me an advice about this error message. 19:55:30 Groupsock(-1: 239.100.0.10, 32770, 255): failed to group setsockopt(ID_ADD_MEMBERSHIP) error: Bad file descriptor Regards. Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071205/7e2c8161/attachment.html From finlayson at live555.com Wed Dec 5 16:35:06 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Dec 2007 16:35:06 -0800 Subject: [Live-devel] Q: incomingRequestHandler1, bytesRead == fRequestSpaceRemaining In-Reply-To: References: Message-ID: >In RTSPServer::incomingRequestHandler1() conditional "if (bytesRead ><= 0 || (unsigned)bytesRead >= fRequestSpaceRemaining)" >Q: Is it really a failure if the number of bytes read == the amount >of space available? Yes, because there would then be no room for us to add a trailing '\0' character (which we use for parsing). -- 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/20071205/d08e6266/attachment.html From finlayson at live555.com Wed Dec 5 16:36:01 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Dec 2007 16:36:01 -0800 Subject: [Live-devel] Q:error message In-Reply-To: <000801c83797$ee02cf10$6d01a8c0@PeterMobile> References: <000801c83797$ee02cf10$6d01a8c0@PeterMobile> Message-ID: >Hi everyone, > >Please give me an advice about this error message. > > 19:55:30 Groupsock(-1: 239.100.0.10, 32770, 255): failed to group >setsockopt(ID_ADD_MEMBERSHIP) error: Bad file descriptor The problem is the "-1" - this is an invalid socket number. For some reason, your socket didn't get created properly. -- 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/20071205/b2f4aa85/attachment.html From finlayson at live555.com Wed Dec 5 16:38:53 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Dec 2007 16:38:53 -0800 Subject: [Live-devel] Video & Audio Properties at RTP Receivers In-Reply-To: <351e7d280712051302l19bb6dctc45fbdd2780ec95f@mail.gmail.com> References: <351e7d280712050646k23ac3c86p754b9e9bd47de0a6@mail.gmail.com> <351e7d280712051302l19bb6dctc45fbdd2780ec95f@mail.gmail.com> Message-ID: > > >2. For H.264, is there any parser for the extra info returned by >> >parseH264ConfigStr ? >> >> This data is a sequence of H.264 NAL units, and are therefore >> parsed/interpreted by your H.264 decoder. > >Just a suggestion... For MPEG4, and H264, these infos are in the SDP >so it is possible to have a parser in the livemedia stack I think. I think you misunderstand. The data that's in the SDP description is in Base-64 text format. Our routine "parseH264ConfigStr()" converts this data into raw binary form (i.e., a sequence of NAL units). That binary data is meant to be passed to the H.264 decoder. Once again, our libraries do not include any decoding software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From belloni at imavis.com Thu Dec 6 09:23:12 2007 From: belloni at imavis.com (Cristiano Belloni) Date: Thu, 06 Dec 2007 18:23:12 +0100 Subject: [Live-devel] RTSP H263+ streaming oddities. Message-ID: <47583000.7070700@imavis.com> Hi to everybody, I tried to modify the testOnDemandRTSPServer.cpp source to stream H263+ video. First, I try to read the stream from a file. In the future, I'd like to encode and stream on the fly. The problem is, I simply added this code to the source file: { char const* streamName = "H263ESVideoTest"; char const* inputFileName = "video-H263-1998-1.3pg"; ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); sms->addSubsession(H263plusVideoFileServerMediaSubsession ::createNew(*env, inputFileName, reuseFirstSource)); rtspServer->addServerMediaSession(sms); announceStream(rtspServer, sms, streamName, inputFileName); } mainly imitating the pre-existing code. RTSP Server waits correctly on port 8554. When I try to play it either with VLC or openRTSP, the client-server communication goes like that: ---------------------- VLC media player 0.8.6c Janus Sending request: OPTIONS rtsp://217.133.231.30:8554/H263ESVideoTest RTSP/1.0 CSeq: 1 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) Received OPTIONS response: RTSP/1.0 200 OK CSeq: 1 Date: Thu, Dec 06 2007 16:55:58 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: DESCRIBE rtsp://217.133.231.30:8554/H263ESVideoTest RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) Received DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Thu, Dec 06 2007 16:55:58 GMT Content-Base: rtsp://217.133.231.30:8554/H263ESVideoTest/ Content-Type: application/sdp Content-Length: 369 Need to read 369 extra bytes Read 369 extra bytes: v=0 o=- 1196960112744027 1 IN IP4 217.133.231.30 s=Session streamed by "testOnDemandRTSPServer" i=H263ESVideoTest t=0 0 a=tool:LIVE555 Streaming Media v2007.02.20 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer" a=x-qt-text-inf:H263ESVideoTest m=video 0 RTP/AVP 34 c=IN IP4 0.0.0.0 a=control:track1 [00000292] live555 demuxer error: Nothing to play for rtsp://217.133.231.30:8554/H263ESVideoTest [00000290] main input error: no suitable access module for `rtsp://217.133.231.30:8554/H263ESVideoTest' [00000281] main playlist: nothing to play [00000281] main playlist: stopping playback ---------------------------------- It seems that the SDP misses the a=rtpmap:96 H263-1998/90000 line. It also yelds the strange m=video 0 RTP/AVP 34, as if it would send RTP contents on port 0. After that, I tried to modify the testMPEG1or2VideoStreamer.cpp program, again simply substituting the Mpeg 1/2 sink with H263plusVideoRTPSink and the Mpeg 1/2 framer with H263plusVideoStreamFramer, and activating the RTSP server defining IMPLEMENT_RTSP_SERVER. It works, but with several problems: 1. Won't do RTP over TCP when requested (RTSP server returns with a 460 and something code, complaining it's not supported). It only works with UDP. 2. Port is fixed to 8888 (it makes sense, since we define it at the beginning of the program) 3. In addiction of streaming on demand, it also streams multicast on 239.255.42.42 (it also makes sense, but I don't know how to avoid it). I think the correct solution is using the onDemand approach, but does someone know the reason of its strange behaviour (and how to crcumvent it, of course)? Best regards, Cristiano. -- Belloni Cristiano From finlayson at live555.com Thu Dec 6 09:41:11 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Dec 2007 09:41:11 -0800 Subject: [Live-devel] RTSP H263+ streaming oddities. In-Reply-To: <47583000.7070700@imavis.com> References: <47583000.7070700@imavis.com> Message-ID: > char const* inputFileName = "video-H263-1998-1.3pg"; What is the format of this file? Our 'H.263+ parsing' code assumes that the input file contains raw H.263+ video elementary stream data *only*. If (judging by the ".3gp" filename suffix) your file is instead a MPEG-4-format file, then our code will definitely *not* work, as we currently do not have a parser for such files. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From belloni at imavis.com Thu Dec 6 10:09:17 2007 From: belloni at imavis.com (Cristiano Belloni) Date: Thu, 06 Dec 2007 19:09:17 +0100 Subject: [Live-devel] RTSP H263+ streaming oddities. In-Reply-To: <47583000.7070700@imavis.com> References: <47583000.7070700@imavis.com> Message-ID: <47583ACD.5090809@imavis.com> Ross Finlayson wrote: >/ char const* inputFileName = "video-H263-1998-1.3pg"; / > What is the format of this file? Our 'H.263+ parsing' code assumes > that the input file contains raw H.263+ video elementary stream data > *only*. If (judging by the ".3gp" filename suffix) your file is > instead a MPEG-4-format file, then our code will definitely *not* > work, as we currently do not have a parser for such files. Actually, I'm quite sure it's H.263-1998 (I added the misleading extension). I downloaded the file with openRTSP from rtsp://rtsp.youtube.com/youtube/videos/57hSqLLfOv4/video.3gp (which i found on http://m.youtube.com/). Here's the output of openRTSP: $openRTSP rtsp://rtsp.youtube.com/youtube/videos/57hSqLLfOv4/video.3gp Opened URL "rtsp://rtsp.youtube.com/youtube/videos/57hSqLLfOv4/video.3gp", returning a SDP description: v=0 o=StreamingServer 3405952677 1196730790000 IN IP4 208.65.153.241 s=/youtube/videos/57hSqLLfOv4/video.3gp u=http:/// e=admin@ c=IN IP4 0.0.0.0 b=AS:86 t=0 0 a=control:* a=range:npt=0- 35.53300 m=video 0 RTP/AVP 96 b=AS:81 a=rtpmap:96 H263-1998/90000 a=control:trackID=65536 a=cliprect:0,0,144,176 a=framesize:96 176-144 m=audio 0 RTP/AVP 97 b=AS:5 a=rtpmap:97 AMR/8000/1 a=control:trackID=65537 a=fmtp:97 octet-align Created receiver for "video/H263-1998" subsession (client ports 32996-32997) Created receiver for "audio/AMR" subsession (client ports 32998-32999) Setup "video/H263-1998" subsession (client ports 32996-32997) Setup "audio/AMR" subsession (client ports 32998-32999) Created output file: "video-H263-1998-1" Created output file: "audio-AMR-2" Started playing session Receiving streamed data (for up to 40.533001 seconds)... I discarded the samr audio file, and i'm only using the video file. Regards, Cristiano. From finlayson at live555.com Thu Dec 6 11:11:19 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Dec 2007 11:11:19 -0800 Subject: [Live-devel] RTSP H263+ streaming oddities. In-Reply-To: <47583ACD.5090809@imavis.com> References: <47583000.7070700@imavis.com> <47583ACD.5090809@imavis.com> Message-ID: >Actually, I'm quite sure it's H.263-1998 (I added the misleading >extension). I downloaded the file with openRTSP from >rtsp://rtsp.youtube.com/youtube/videos/57hSqLLfOv4/video.3gp (which i >found on http://m.youtube.com/). OK, that's good. (However, you shouldn't really have renamed the file to have a ".3gp" filename extension; that confused me :-) It seems, then that there is likely a problem with our "H263plusVideoStreamFramer" and (especially) "H263plusVideoStreamParser" classes, which are the classes that parse the raw H.263+ data from your file into individual frames, for transmission. Unfortunately, those classes were written by a 3rd party, and I haven't had the chance yet to scrutinize the code in detail. At some point, I hope to find the time to look at this code in more detail. Until then, if you find anything in that code that looks like a problem, then please let us know. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Dec 6 11:11:19 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Dec 2007 11:11:19 -0800 Subject: [Live-devel] RTSP H263+ streaming oddities. In-Reply-To: <47583ACD.5090809@imavis.com> References: <47583000.7070700@imavis.com> <47583ACD.5090809@imavis.com> Message-ID: >Actually, I'm quite sure it's H.263-1998 (I added the misleading >extension). I downloaded the file with openRTSP from >rtsp://rtsp.youtube.com/youtube/videos/57hSqLLfOv4/video.3gp (which i >found on http://m.youtube.com/). OK, that's good. (However, you shouldn't really have renamed the file to have a ".3gp" filename extension; that confused me :-) It seems, then that there is likely a problem with our "H263plusVideoStreamFramer" and (especially) "H263plusVideoStreamParser" classes, which are the classes that parse the raw H.263+ data from your file into individual frames, for transmission. Unfortunately, those classes were written by a 3rd party, and I haven't had the chance yet to scrutinize the code in detail. At some point, I hope to find the time to look at this code in more detail. Until then, if you find anything in that code that looks like a problem, then please let us know. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vmehrotra at rgbnetworks.com Thu Dec 6 17:06:54 2007 From: vmehrotra at rgbnetworks.com (Vivek Mehrotra) Date: Thu, 6 Dec 2007 17:06:54 -0800 Subject: [Live-devel] Question on RTSPClientSession Message-ID: <9964EE0EF7D1234C8ADD051DB304E0CC1AEF9F@MSG10001.rgbnetworks.com> Hi, Is there any way to send a response asynchronously from RTSPServer when there are no incoming packets any longer? (Assuming of course that I know the clientSocket I need to perform a send() on.) If another thread sets the watchVariable and the Server thread is able to see the watchVariable (using your dummyTask principle), how can I send the response from the context of the RTSP Server? The incomingConnectionHandler() is no longer in use. Thanks in advance, vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071206/0cd58301/attachment.html From finlayson at live555.com Thu Dec 6 18:25:36 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Dec 2007 18:25:36 -0800 Subject: [Live-devel] RTSP H263+ streaming oddities. In-Reply-To: <47583ACD.5090809@imavis.com> References: <47583000.7070700@imavis.com> <47583ACD.5090809@imavis.com> Message-ID: I looked into the code, and found that the problem was the "H263plusVideoFileServerMediaSubsession" class. It was (incorrectly) using a (now-obsolete) static RTP payload type. I have now fixed it to use a dynamic RTP payload type. I have now installed a new version (2007.12.07) of the "LIVE555 Streaming Media" software that includes this fix. Please try it; it will likely fix your problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From RGlobisch at csir.co.za Fri Dec 7 00:35:04 2007 From: RGlobisch at csir.co.za (Ralf Globisch) Date: Fri, 07 Dec 2007 10:35:04 +0200 Subject: [Live-devel] Video & Audio Properties at RTP Receivers Message-ID: <475921D4.5DA9.004D.0@csir.co.za> Hi, I've got the same problem with DShow, maybe we can exchange ideas to see what the best solution is: Since the pipeline has to be set up before streaming I was thinking of doing the following: 1) sending a DESCRIBE request to the rtsp server (in the windows media player plug-in initialisation code) 2) Adding an extra parameter to the SDP file similar to the "RTP Payload Format for JPEG 2000 Video Streams": m=video 49170/2 RTP/AVP 98 a=rtpmap:98 jpeg2000/90000 a=fmtp:98 rate=90000;sampling=YCbCr-4:2:0;width=128;height=128 a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128 3) Parsing this sdp to get the width and height, etc out. I'm still very new to RTP, etc and I'm not sure how to judge it, is this a "bad" hack? -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From oscar.youx at gmail.com Fri Dec 7 00:58:26 2007 From: oscar.youx at gmail.com (oscar lima) Date: Fri, 7 Dec 2007 09:58:26 +0100 Subject: [Live-devel] Video & Audio Properties at RTP Receivers In-Reply-To: <475921D4.5DA9.004D.0@csir.co.za> References: <475921D4.5DA9.004D.0@csir.co.za> Message-ID: <351e7d280712070058u19145f01g896e4bf5a0e27b68@mail.gmail.com> Hi Ralf, I will be glad to share ideas, or even code with you. > 2) Adding an extra parameter to the SDP file similar to the "RTP Payload Format for >JPEG > 2000 Video Streams": This is not in the standard, and will be possible only if you use your "custom" client and server. My goal is to have a universal (thus Standard-compliant) implementation. As Ross said in previous posts on this topic, we must have some extra code (which is more related to Media Decoding than RTP and SDP) that discovers these information. There will be two cases, depending on the media type : 1. For some codecs, (mainly MPEG4 (audio and video), QuickTime and H.264), we need to parse the fmtp config param given in the SDP. 2. For the others, (H.261, H.263, .....), such information are included in the payload or in the extra header (RTP payload format). So I think we have to "Sniff" first RTP packets to retreive such information. I hope this will help, Oscar From RGlobisch at csir.co.za Fri Dec 7 02:49:32 2007 From: RGlobisch at csir.co.za (Ralf Globisch) Date: Fri, 07 Dec 2007 12:49:32 +0200 Subject: [Live-devel] Video & Audio Properties at RTP Receivers Message-ID: <47594159.5DA9.004D.0@csir.co.za> Hi Oscar, That would be nice, it's always great exchanging ideas with some one else. I'd would also be glad to share info or code. I must just get my skills up to scratch since I just started looking at the live555 libraries and am still in the beginning stages. I'm fairly comfortable with DShow at the moment. >This is not in the standard, and will be possible only if you use your "custom" client and server. My goal is to have a universal (thus Standard-compliant) implementation. I figured as much and agree, it would be better to achieve a standard compliant implementation. Just one question so I have a better idea about what you're doing and how we can help each other: Are you catering exclusively for DShow or also other players? Am I correct in assuming that your media player plugin is a custom DShow Source filter? Regards, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From RGlobisch at csir.co.za Fri Dec 7 02:59:27 2007 From: RGlobisch at csir.co.za (Ralf Globisch) Date: Fri, 07 Dec 2007 12:59:27 +0200 Subject: [Live-devel] Video & Audio Properties at RTP Receivers Message-ID: <475943AC.5DA9.004D.0@csir.co.za> Hi Oscar, >2. For the others, (H.261, H.263, .....), such information are included in the payload or in the extra header (RTP payload format). So I think we have to "Sniff" first RTP packets to retreive such information. That sounds like a good solution. Another option would be a dynamic format change as described at http://msdn2.microsoft.com/en-us/library/ms867156.aspx though I think this would probably be a bit more complicated. Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From slaine at slaine.org Fri Dec 7 04:11:07 2007 From: slaine at slaine.org (Glen Gray) Date: Fri, 7 Dec 2007 12:11:07 +0000 Subject: [Live-devel] Commercial version of live555 Media Server ? In-Reply-To: References: <4757EEC1.3020208@lincor.com> Message-ID: <4759385B.8000804@slaine.org> Hey Ross, Thanks for the response. While agree that "Live555 Media Server" as currently released is an excellent product, it's lacking some of the surrounding fluff that most non-techie customers would expect to available but which have no bearing on whether it's a capable streaming server or not. So I should have said "commercial" as opposed to "production". I'm talking about mostly server management related stuff like a webUI for movie management or status information. No rocket science there. It would be this kind of stuff that would take up my or one of my teams time. In the long run I think it's a worthwhile investment for us to have that kind of surrounding infrastructure. However, it's also prudent to see if there's already a commercial product offering based on Live555 that does all this, so as per your suggestion, I'll put this out to the list and see if any of you guys have any suggestions. Regards, Ross Finlayson wrote: > Glen, > > The "LIVE555 Media Server", as currently released, is intended to > already be a product (albeit a free and deliberately simple one). (I > view simplicity, in this case, as being a benefit.) > > If, however, you're looking for an alternative, more complex (and > perhaps not free :-) media server that uses our libraries, then feel > free to ask about it on the mailing list. (Perhaps some people on the > list will be able to point you at one.) -- Glen Gray (slaine at slaine.org) From belloni at imavis.com Fri Dec 7 08:22:16 2007 From: belloni at imavis.com (Cristiano Belloni) Date: Fri, 07 Dec 2007 17:22:16 +0100 Subject: [Live-devel] RTSP H263+ streaming oddities. In-Reply-To: <47583ACD.5090809@imavis.com> References: <47583000.7070700@imavis.com> <47583ACD.5090809@imavis.com> Message-ID: <47597338.30409@imavis.com> Ross Finlayson wrote: > I looked into the code, and found that the problem was the > "H263plusVideoFileServerMediaSubsession" class. It was (incorrectly) > using a (now-obsolete) static RTP payload type. I have now fixed it > to use a dynamic RTP payload type. > > I have now installed a new version (2007.12.07) of the "LIVE555 > Streaming Media" software that includes this fix. Please try it; it > will likely fix your problem. > Now it works! It was the if (false) statement which forced the payload to be assigned to 34 instead of dynamic, wasn't it ? (tonight I was reading the code and couldn't explain that sort of behaviour). Thank you so much, regards, Belloni Cristiano From finlayson at live555.com Fri Dec 7 10:02:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 7 Dec 2007 10:02:40 -0800 Subject: [Live-devel] Video & Audio Properties at RTP Receivers In-Reply-To: <475921D4.5DA9.004D.0@csir.co.za> References: <475921D4.5DA9.004D.0@csir.co.za> Message-ID: The solution here is simply for someone to implement the RTP Payload Format for JPEG 2000, as described in ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-avt-rtp-jpeg2000-18.txt I.e., this would involve defining and implementing two new classes - "JPEG2000VideoRTPSource" and "JPEG2000VideoRTPSink". These would be similar to the (but different from and not just subclasses of) the existing "JPEGVideoRTPSource" and "JPEGVideoRTPSink" classes. You cannot send or receive JPEG 2000 frames in RTP using our existing code; you must write new code to implement this new RTP payload format. >2) Adding an extra parameter to the SDP file similar to the "RTP >Payload Format for JPEG 2000 Video Streams": > >m=video 49170/2 RTP/AVP 98 >a=rtpmap:98 jpeg2000/90000 >a=fmtp:98 rate=90000;sampling=YCbCr-4:2:0;width=128;height=128 >a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128 > >3) Parsing this sdp to get the width and height, etc out. > >I'm still very new to RTP, etc and I'm not sure how to judge it, is >this a "bad" hack? Note (from the Internet-Draft) that these "width" and "height" parameters, passed in the SDP description, are *optional* parameters (i.e., servers cannot be expected to include them), and, more importantly, that they represent the *maximum possible* width and height of the JPEG 2000 frames. Therefore, you cannot rely upon these parameters to denote the *actual* width/height of the stream's frames. The ony reliable way to get the width and height of each JPEG 2000 frame is to actually parse the JPEG 2000 frame data, which is what you will need to do anyway in order to decode/display the frame. I'm a bit puzzled here. Over the last few days, we've seen several messages posted by people who want to get codec-specific information from received RTP data, but don't want to actually decode that data. I don't understand. What is the point of receiving audio or video data if you don't want to decode it? (Unless, of course, you just want to write the received data into a file - as "openRTSP" does - in which case you don't need to care about the codec-specific internal parameters.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bruneaujulien at gmail.com Sun Dec 9 06:32:12 2007 From: bruneaujulien at gmail.com (Julien Bruneau) Date: Sun, 9 Dec 2007 15:32:12 +0100 Subject: [Live-devel] How to parameter the SETUP request using the RTSPClient object Message-ID: <66abaf320712090632q3f045534x149ad921b448c2a1@mail.gmail.com> Hello, I am developing a RTSP client that has to send RTSP requests to a RTSP server. To do that, I use the RTSPClient object. I would like to know if it is possible to parameter the SETUP request so that the media will be sent to another address that the address of the client. In the RTSP RFC, it is said that the string "destination=..." can be added to the Transport field of the SETUP request to specify where you want the media to be sent. Is it possible in the LiveMedia library? If it is, how can I specify this address? The client port can be specified, is it possible to specify the client address? Here is the code where my SETUP request is sent : RTSPClient client; ... MediaSession* session = MediaSession::createNew(*usage_environment, sdp_message); MediaSubsessionIterator iter(*session); MediaSubsession *subsession; while ((subsession = iter.next()) != NULL) { subsession->setClientPortNum(port); if (strcmp(transportType,"unicast") == 0) client->setupMediaSubsession(*subsession, False, False); if (strcmp(transportType,"multicast") == 0) client->setupMediaSubsession(*subsession, False, False, True); port += 2; } Best regards, Julien -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071209/393c49e0/attachment-0001.html From finlayson at live555.com Sun Dec 9 07:45:19 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 9 Dec 2007 07:45:19 -0800 Subject: [Live-devel] How to parameter the SETUP request using the RTSPClient object In-Reply-To: <66abaf320712090632q3f045534x149ad921b448c2a1@mail.gmail.com> References: <66abaf320712090632q3f045534x149ad921b448c2a1@mail.gmail.com> Message-ID: >I am developing a RTSP client that has to send RTSP requests to a >RTSP server. To do that, I use the RTSPClient object. > >I would like to know if it is possible to parameter the SETUP >request so that the media will be sent to another address that the >address of the client. In the RTSP RFC, it is said that the string >"destination=..." can be added to the Transport field of the SETUP >request to specify where you want the media to be sent. Is it >possible in the LiveMedia library? No, not without modifying the existing code. Note, though, that most RTSP servers, by default, will *not* handle a "destination=" parameter in the RTSP "SETUP" "Transport:" header, because this would make it possible for a client to use this to set up a denial-of-service attack against a third party. Therefore, you should not depend upon being to ask a server to send a stream to a different address. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bruneaujulien at gmail.com Sun Dec 9 08:06:16 2007 From: bruneaujulien at gmail.com (Julien Bruneau) Date: Sun, 9 Dec 2007 17:06:16 +0100 Subject: [Live-devel] How to parameter the SETUP request using the RTSPClient object In-Reply-To: References: <66abaf320712090632q3f045534x149ad921b448c2a1@mail.gmail.com> Message-ID: <66abaf320712090806n3a1b7cc3tc0b0b6fa40de3843@mail.gmail.com> Ok, thank you very much for the information! 2007/12/9, Ross Finlayson : > > >I am developing a RTSP client that has to send RTSP requests to a > >RTSP server. To do that, I use the RTSPClient object. > > > >I would like to know if it is possible to parameter the SETUP > >request so that the media will be sent to another address that the > >address of the client. In the RTSP RFC, it is said that the string > >"destination=..." can be added to the Transport field of the SETUP > >request to specify where you want the media to be sent. Is it > >possible in the LiveMedia library? > > No, not without modifying the existing code. > > Note, though, that most RTSP servers, by default, will *not* handle a > "destination=" parameter in the RTSP "SETUP" "Transport:" header, > because this would make it possible for a client to use this to set > up a denial-of-service attack against a third party. Therefore, you > should not depend upon being to ask a server to send a stream to a > different address. > -- > > 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/20071209/7ca9890d/attachment.html From tan_koklim at yahoo.com Sun Dec 9 23:56:51 2007 From: tan_koklim at yahoo.com (kok lim Tan) Date: Sun, 9 Dec 2007 23:56:51 -0800 (PST) Subject: [Live-devel] question: possibility to extend the code to support 3g video streaming Message-ID: <568046.71553.qm@web44916.mail.sp1.yahoo.com> hi , I am new to this forum. i am an electronic and electrical student and currently i am doing my final year project on 3G live video streaming from a network camera. i was wondering is it possible to extend the source code posted in live555 to support 3G video streaming ? the only hardware i have now is just a network camera, a router, modem and a PC. these are the only items that i am allow to buy. my job is to create the server to stream live video to the mobile device. since i am new to video streaming, with limited knowledge in c++ programing and java, i wasn't sure which open source code should i use. i will appreciate if you can give me some guidance. thanks in advance --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071210/c9460867/attachment.html From swapnil.indore at gmail.com Mon Dec 10 00:34:48 2007 From: swapnil.indore at gmail.com (Swapnil Jain) Date: Mon, 10 Dec 2007 14:04:48 +0530 Subject: [Live-devel] Howto create MPEG Transport Stream Message-ID: <475CFA28.7080202@gmail.com> Hi, I have mp4 video, how do i convert it to transport stream so that i can play it on amino stb Swapnil Jain Indore From finlayson at live555.com Mon Dec 10 01:55:06 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Dec 2007 01:55:06 -0800 Subject: [Live-devel] question: possibility to extend the code to support 3g video streaming In-Reply-To: <568046.71553.qm@web44916.mail.sp1.yahoo.com> References: <568046.71553.qm@web44916.mail.sp1.yahoo.com> Message-ID: > i was wondering is it possible to extend the source code posted in >live555 to support 3G video streaming ? We already support streaming all of the audio and video codecs (and protocols) used by so-called '3G' clients. (However, we don't yet support streaming from pre-recorded MPEG-4-format files.) > the only hardware i have now is just a network camera, a router, >modem and a PC. Unless your "network camera" already encodes (compresses) the video (and audio, if any), you will also need video/audio encoding hardware (or software). >my job is to create the server to stream live video to the mobile device. You might find our "wis-streamer" server useful (it requires a particular type of encoder hardware, however): http://www.live555.com/wis-streamer/ -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From brainlai at gmail.com Mon Dec 10 05:41:02 2007 From: brainlai at gmail.com (Brain Lai) Date: Mon, 10 Dec 2007 21:41:02 +0800 Subject: [Live-devel] Just in case the server responses nothing Message-ID: Dear Sir: When I try to connect AXIS IP camera several times(one to many, no regular pattern), the RTSPClient::describeURL() never retruns. After doing some source tracing, I find that it is blocked in readSocket() in RTSPClient::getResponse1(). This is because the readSocket() calls blockUntilReadable() without timeout setting. I also apply Wireshark to capture the protocol negotiation and verify that the RTSPClient really sends the DESCRIBE request but the RTSP server responses nothing. Since I can not step inside the AXIS RTSP server to see if it really receives the request, it is not easy to confirm the cause of the problem. Maybe the server does receive the request but cannot response for some reason or something else. Anyway, I suggest the RTSPClient chooses a reasonable timeout for safety before calling readSocket() in case the server misbehaves. Actually, when this condition is detected, the next time calling RTSPClient::describeURL() succeeds. It seems nobody should be blamed. BR. Brain Lai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071210/3901c80f/attachment.html From gbonneau at matrox.com Mon Dec 10 07:35:52 2007 From: gbonneau at matrox.com (Guy Bonneau) Date: Mon, 10 Dec 2007 10:35:52 -0500 Subject: [Live-devel] Input Buffer Consumed Message-ID: <027001c83b42$590f14a0$aa42a8c0@dorvalmatrox.matrox.com> Hello, I'm new to LiveMedia library and I am experimented with it under Windows OS. I have found in the file ByteStreamFileSource.cpp the code that synchronously read the source buffer from a file. I need to know however when the library will have finished of using the buffer. Is there some feedback mechanism or any other means in the library that can provide a callback when the source buffer is all consumed. Thanks Guy Bonneau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071210/5422cc7d/attachment.html From bd at landform.com Mon Dec 10 11:53:14 2007 From: bd at landform.com (Bill Dolson) Date: Mon, 10 Dec 2007 14:53:14 -0500 Subject: [Live-devel] Problem with VLC and wis-streamer Message-ID: <475D992A.1020503@landform.com> Hi, Weird one. Running wis-streamer from composite video wis-streaner -r 64000 -na Using VLC 0.8.6d Windows running on the same LAN as the server will play the stream all day. Using the same VLC version Windows or Linux (el5) from anywhere on the Internet playback freezes after approx 45 seconds (very repeatable, always 45-50 seconds). The server is on a consumer DSL circuit (we are experimenting with low-bitrates). Client location connections vary from consumer DSL to high-bandwidth fiber. Running FFplay on Windows the stream plays continuously. I know it sounds like a VLC problem but since VLC uses Live555... It this related to: http://forum.videolan.org/viewtopic.php?f=2&t=42623&p=133393&hilit=Live555#p133393 I can point you to the stream off channel. Thanks, Bill Dolson From bd at landform.com Mon Dec 10 12:15:51 2007 From: bd at landform.com (Bill Dolson) Date: Mon, 10 Dec 2007 15:15:51 -0500 Subject: [Live-devel] Problem with VLC and wis-streamer In-Reply-To: <475D992A.1020503@landform.com> References: <475D992A.1020503@landform.com> Message-ID: <475D9E77.8050507@landform.com> Bill Dolson wrote: > Hi, > > Weird one. Running wis-streamer from composite video > > wis-streaner -r 64000 -na > > Using VLC 0.8.6d Windows running on the same LAN as the server will play > the stream all day. > > Using the same VLC version Windows or Linux (el5) from anywhere on the > Internet playback freezes after approx 45 seconds (very repeatable, > always 45-50 seconds). The server is on a consumer DSL circuit (we are > experimenting with low-bitrates). Client location connections vary from > consumer DSL to high-bandwidth fiber. > > Running FFplay on Windows the stream plays continuously. > > I know it sounds like a VLC problem but since VLC uses Live555... > > It this related to: > http://forum.videolan.org/viewtopic.php?f=2&t=42623&p=133393&hilit=Live555#p133393 > > I can point you to the stream off channel. > > Thanks, > Bill Dolson I can confirm with Wireshark that VLC on Windows is not sending any RCTP RRs back to the server (FFplay is). Is there a patch for VLC or any way to prevent wis-streamer from requiring them? Thanks, Bill From bd at landform.com Mon Dec 10 12:54:46 2007 From: bd at landform.com (Bill Dolson) Date: Mon, 10 Dec 2007 15:54:46 -0500 Subject: [Live-devel] Problem with VLC and wis-streamer In-Reply-To: <475D9E77.8050507@landform.com> References: <475D992A.1020503@landform.com> <475D9E77.8050507@landform.com> Message-ID: <475DA796.6090405@landform.com> Bill Dolson wrote: > Bill Dolson wrote: >> Hi, >> >> Weird one. Running wis-streamer from composite video >> >> wis-streaner -r 64000 -na >> >> Using VLC 0.8.6d Windows running on the same LAN as the server will play >> the stream all day. >> >> Using the same VLC version Windows or Linux (el5) from anywhere on the >> Internet playback freezes after approx 45 seconds (very repeatable, >> always 45-50 seconds). The server is on a consumer DSL circuit (we are >> experimenting with low-bitrates). Client location connections vary from >> consumer DSL to high-bandwidth fiber. >> >> Running FFplay on Windows the stream plays continuously. >> >> I know it sounds like a VLC problem but since VLC uses Live555... >> >> It this related to: >> http://forum.videolan.org/viewtopic.php?f=2&t=42623&p=133393&hilit=Live555#p133393 >> >> I can point you to the stream off channel. >> >> Thanks, >> Bill Dolson > > I can confirm with Wireshark that VLC on Windows is not sending any RCTP > RRs back to the server (FFplay is). Is there a patch for VLC or any way > to prevent wis-streamer from requiring them? > > Thanks, > Bill The RTCP RRs are being sent, but apparently to the un-NATed local network address of the server, which is behind a NATing rounter, not the public address. How come FFmpeg gets it right and VLC doesn't? Thanks, Bill From ninive at gmx.at Mon Dec 10 13:58:11 2007 From: ninive at gmx.at (double) Date: Mon, 10 Dec 2007 22:58:11 +0100 Subject: [Live-devel] Vatican CTV live stream Message-ID: <475DB673.9000901@gmx.at> Hi, The Vatican CTV live stream - rtsp://212.77.7.133:80/h264lan.sdp does not work with openRTSP. On the vatican homepage there is a note, that VLC media player should play them, but it does not. Is this a problem of live555? Currently, the stream should be on. Thank you very much Markus Doppelbauer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071210/73c77dc7/attachment.html From finlayson at live555.com Mon Dec 10 15:16:59 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Dec 2007 15:16:59 -0800 Subject: [Live-devel] Input Buffer Consumed In-Reply-To: <027001c83b42$590f14a0$aa42a8c0@dorvalmatrox.matrox.com> References: <027001c83b42$590f14a0$aa42a8c0@dorvalmatrox.matrox.com> Message-ID: >I'm new to LiveMedia library and I am experimented with it under >Windows OS. I have found in the file ByteStreamFileSource.cpp the >code that synchronously read the source buffer from a file. I need >to know however when the library will have finished of using the >buffer. Note that the buffer that "ByteStreamFileSource" (or any "FramedSource" class, for that matter), is provided by the upstream object, and it - not "ByteStreamFileSource" - is the object that knows when the buffer data is no longer needed. Therefore, the answer to your question depends upon the upstream object that provided the buffer. -- 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/20071210/2cbdb3d4/attachment.html From finlayson at live555.com Mon Dec 10 15:19:52 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Dec 2007 15:19:52 -0800 Subject: [Live-devel] Just in case the server responses nothing In-Reply-To: References: Message-ID: This is a know problem with the current implementation of "RTSPClient". It should be doing asynchronous socket reads (within the event loop), rather than a (potentially blocking) synchronous read. Fixing this is on my 'to do' list. In the meantime, your immediate priority should be to figure out why your Axis camera server is not responding properly. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Dec 10 15:43:22 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Dec 2007 15:43:22 -0800 Subject: [Live-devel] Problem with VLC and wis-streamer In-Reply-To: <475DA796.6090405@landform.com> References: <475D992A.1020503@landform.com> <475D9E77.8050507@landform.com> <475DA796.6090405@landform.com> Message-ID: >The RTCP RRs are being sent, but apparently to the un-NATed local >network address of the server They should be getting sent to whichever server IP address was specified in the "rtsp://" URL, or - if a server domain name was specified instead - whatever IP address that domain name resolved to when it was looked up (via DNS). RTSP/RTP cannot reliably be expected to work across NATs. (If you're behind a NAT, then you're not really on the Internet.) Instead, you can ask for RTP-over-TCP streaming, which should work. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Dec 10 15:52:50 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Dec 2007 15:52:50 -0800 Subject: [Live-devel] Vatican CTV live stream In-Reply-To: <475DB673.9000901@gmx.at> References: <475DB673.9000901@gmx.at> Message-ID: >Hi, > >The Vatican CTV live stream - rtsp://212.77.7.133:80/h264lan.sdp >does not work with openRTSP. > >On the vatican homepage there is a note, that VLC media player >should play them, but it does not. Both "openRTSP" and "VLC" (and "QuickTime Player") play the stream OK for me. Perhaps you're stuck behind a firewall that is (for whatever reason) blockig RTP packets? You could try again with the "-t" option to "openRTSP", to request RTP-over-TCP streaming. -- 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/20071210/610030f0/attachment.html From bd at landform.com Mon Dec 10 16:39:03 2007 From: bd at landform.com (Bill Dolson) Date: Mon, 10 Dec 2007 19:39:03 -0500 Subject: [Live-devel] Problem with VLC and wis-streamer In-Reply-To: References: <475D992A.1020503@landform.com> <475D9E77.8050507@landform.com> <475DA796.6090405@landform.com> Message-ID: <475DDC27.5040301@landform.com> Ross Finlayson wrote: >> The RTCP RRs are being sent, but apparently to the un-NATed local >> network address of the server > > They should be getting sent to whichever server IP address was > specified in the "rtsp://" URL, or - if a server domain name was > specified instead - whatever IP address that domain name resolved to > when it was looked up (via DNS). > > RTSP/RTP cannot reliably be expected to work across NATs. (If you're > behind a NAT, then you're not really on the Internet.) Instead, you > can ask for RTP-over-TCP streaming, which should work. Ross, thanks for the reply. So, it is a VLC bug correct? (I'm just trying to figure out which one to fix, actively developing with both). Haven't read the RTSP RFC yet. Using VLC the RTCP RRs are being sent to the local IP of the server, as reported as the Content-Base in the DESCRIBE response and in the sdp. Is this just plain wrong or is it following the letter of the RFC? FFmpeg sends the RTCP RRs to the original IP specified in the rtsp://... Is this right or a expedient NAT work-around? I see no reason why RTP/UDP should not work through NATs. I'm well aware of the badness of NATs but it is an imperfect world we live in and delivering video over TCP seems equally bad if not worse. Best, Bill From finlayson at live555.com Mon Dec 10 17:25:10 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Dec 2007 17:25:10 -0800 Subject: [Live-devel] Problem with VLC and wis-streamer In-Reply-To: <475DDC27.5040301@landform.com> References: <475D992A.1020503@landform.com> <475D9E77.8050507@landform.com> <475DA796.6090405@landform.com> <475DDC27.5040301@landform.com> Message-ID: > > They should be getting sent to whichever server IP address was >> specified in the "rtsp://" URL, or - if a server domain name was >> specified instead - whatever IP address that domain name resolved to >> when it was looked up (via DNS). >> >> RTSP/RTP cannot reliably be expected to work across NATs. (If you're >> behind a NAT, then you're not really on the Internet.) Instead, you >> can ask for RTP-over-TCP streaming, which should work. > >Ross, thanks for the reply. So, it is a VLC bug correct? No, I have no evidence that there's any bug at all (except perhaps with your NAT). >Using VLC the RTCP RRs are being sent to the local IP of the server, as >reported as the Content-Base in the DESCRIBE response and in the sdp. >Is this just plain wrong or is it following the letter of the RFC? No, this is correct. So, why on Earth is the server returning a local NAT address in its SDP response?? Or is your NAT somehow translating the SDP description somehow? (unlikely) You should mail us the debugging output from "openRTSP" (i.e., showing the complete RTSP protocol exchange), so we can figure out exactly what is going wrong. Otherwise we can only speculate. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bd at landform.com Mon Dec 10 17:57:56 2007 From: bd at landform.com (Bill Dolson) Date: Mon, 10 Dec 2007 20:57:56 -0500 Subject: [Live-devel] Problem with VLC and wis-streamer In-Reply-To: References: <475D992A.1020503@landform.com> <475D9E77.8050507@landform.com> <475DA796.6090405@landform.com> <475DDC27.5040301@landform.com> Message-ID: <475DEEA4.8050209@landform.com> Ross Finlayson wrote: >> > They should be getting sent to whichever server IP address was >>> specified in the "rtsp://" URL, or - if a server domain name was >>> specified instead - whatever IP address that domain name resolved to >>> when it was looked up (via DNS). >>> >>> RTSP/RTP cannot reliably be expected to work across NATs. (If you're >>> behind a NAT, then you're not really on the Internet.) Instead, you >>> can ask for RTP-over-TCP streaming, which should work. >> Ross, thanks for the reply. So, it is a VLC bug correct? > > No, I have no evidence that there's any bug at all (except perhaps > with your NAT). > >> Using VLC the RTCP RRs are being sent to the local IP of the server, as >> reported as the Content-Base in the DESCRIBE response and in the sdp. >> Is this just plain wrong or is it following the letter of the RFC? > > No, this is correct. So, why on Earth is the server returning a > local NAT address in its SDP response?? Or is your NAT somehow > translating the SDP description somehow? (unlikely) > > You should mail us the debugging output from "openRTSP" (i.e., > showing the complete RTSP protocol exchange), so we can figure out > exactly what is going wrong. Otherwise we can only speculate. Ross, I think you're making this way too complicated. Simple question: As per the RFC, should the RTCP RRs go to the IP in the original rtsp://... or to the IP reported as the Content-Base (due to the horrible, nasty, abominable NATing the private address not the public address is returned here and in the sdp). FFmpeg does the former, VLC the latter. I assume only one is correct. Below is the protocol exchange debug from VLC Thanks, Bill Sending request: OPTIONS rtsp://69.2.183.250:8554 RTSP/1.0 CSeq: 1 User-Agent: VLC media player (LIVE555 Streaming Media v2006.12.08) Received OPTIONS response: RTSP/1.0 200 OK CSeq: 1 Date: Tue, Dec 11 2007 01:15:50 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: DESCRIBE rtsp://69.2.183.250:8554 RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2006.12.08) Received DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Tue, Dec 11 2007 01:15:50 GMT Content-Base: rtsp://192.168.10.55:8554// Content-Type: application/sdp Content-Length: 511 Need to read 511 extra bytes Read 511 extra bytes: v=0 o=- 1197324166449418 1 IN IP4 192.168.10.55 s=RTSP/RTP stream from a WIS GO7007 encoder i=LIVE555 Streaming Media v t=0 0 a=tool:LIVE555 Streaming Media v2007.10.31 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:RTSP/RTP stream from a WIS GO7007 encoder a=x-qt-text-inf:LIVE555 Streaming Media v 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=000001B0F5000001B509000001000000012000C88889C463E98A021E0A0C1F a=control:track1 [00000304] live555 demuxer debug: RTP subsession 'video/MP4V-ES' Sending request: SETUP rtsp://192.168.10.55:8554//track1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=34740-34741 User-Agent: VLC media player (LIVE555 Streaming Media v2006.12.08) Received SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Tue, Dec 11 2007 01:15:50 GMT Transport: RTP/AVP;unicast;destination=4.79.212.141;source=192.168.10.55;client_port=34740-34741;server_port=6970-6971 Session: 42 Sending request: PLAY rtsp://192.168.10.55:8554// RTSP/1.0 CSeq: 4 Session: 42 Range: npt=0.000- User-Agent: VLC media player (LIVE555 Streaming Media v2006.12.08) Received PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Tue, Dec 11 2007 01:15:50 GMT Range: npt=0.000- Session: 42 RTP-Info: url=rtsp://192.168.10.55:8554//track1;seq=55317;rtptime=1494175137 ... FFmpeg sends RTCP RRs to 69.2.183.250 VLC sends RTCP RRs to 192.168.10.55 By the RFC, which is correct? Other than this problem it works fine with both server and client behind NATs. From finlayson at live555.com Mon Dec 10 18:21:19 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Dec 2007 18:21:19 -0800 Subject: [Live-devel] Problem with VLC and wis-streamer In-Reply-To: <475DEEA4.8050209@landform.com> References: <475D992A.1020503@landform.com> <475D9E77.8050507@landform.com> <475DA796.6090405@landform.com> <475DDC27.5040301@landform.com> <475DEEA4.8050209@landform.com> Message-ID: >I think you're making this way too complicated. No, your NAT is making this way too complicated! > Simple question: As >per the RFC, should the RTCP RRs go to the IP in the original rtsp://... >or to the IP reported as the Content-Base The latter. > (due to the horrible, nasty, >abominable NATing the private address not the public address is returned >here and in the sdp). Here's the problem: >Received DESCRIBE response: RTSP/1.0 200 OK >CSeq: 2 >Date: Tue, Dec 11 2007 01:15:50 GMT Content-Base: rtsp://192.168.10.55:8554// But why is this happening?? That's my question. How could the server possibly know about the private IP address 192.168.10.55? I don't see how it can, so I don't see how it could be putting that address in the "Content-Base:" header in the RTSP "DESCRIBE" response. So, is your NAT box intercepting and translating the contents of the "Content-Base:" header? WTF?? Suggestion: You might be able to overcome your brain-damaged NAT box by putting a domain name, rather than an IP address, in the original "rtsp://" URL. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bd at landform.com Mon Dec 10 19:44:16 2007 From: bd at landform.com (Bill Dolson) Date: Mon, 10 Dec 2007 22:44:16 -0500 Subject: [Live-devel] Problem with VLC and wis-streamer In-Reply-To: References: <475D992A.1020503@landform.com> <475D9E77.8050507@landform.com> <475DA796.6090405@landform.com> <475DDC27.5040301@landform.com> <475DEEA4.8050209@landform.com> Message-ID: <475E0790.5090603@landform.com> Ross, Hope you don't mind if I don't bottom post. This seems to be a cardinal sin on FFmpeg-devel and vlc-devel. Anyway thanks for your help. > No, your NAT is making this way too complicated! Agreed. but we're (I'm) stuck with it. Not even mine, another vendor I'm trying to integrate with. >> Simple question: As >> per the RFC, should the RTCP RRs go to the IP in the original rtsp://... >> or to the IP reported as the Content-Base > The latter. So, the "working" FFmpeg is actually in error. Somehow I suspected this. Maybe they were anticipating this scenario, or were just lazy... > Here's the problem: > >> Received DESCRIBE response: RTSP/1.0 200 OK >> CSeq: 2 >> Date: Tue, Dec 11 2007 01:15:50 GMT > Content-Base: rtsp://192.168.10.55:8554// Yep, the bad news finally comes to light. > > But why is this happening?? That's my question. How could the > server possibly know about the private IP address 192.168.10.55? I > don't see how it can, so I don't see how it could be putting that > address in the "Content-Base:" header in the RTSP "DESCRIBE" > response. So, is your NAT box intercepting and translating the > contents of the "Content-Base:" header? WTF?? Don't get paranoid on me Ross. The "server" doesn't have a public IP. It is behind a NAT (behind a consumer DSL modem) and doesn't even know what it is NATed to. The rtsp requests are being sent to the DSL modem's IP. Not my choice of setup but what I have been dealt. The joke is it almost works. By disabling timeouts it sort of works. > > Suggestion: You might be able to overcome your brain-damaged NAT box > by putting a domain name, rather than an IP address, in the original > "rtsp://" URL. No domain names here. Not even any static IPs. But the fact that this almost works from this pathetic configuration is somehow encouraging. Anyway, not to hijack a thread, but I may get back to you on looking at how to add private data streams (containing geospatial camera positioning data) to RTSP. Thanks again for the help and most importantly thanks for the excellent work on the Live555 stuff. Best, Bill From finlayson at live555.com Mon Dec 10 21:15:26 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Dec 2007 21:15:26 -0800 Subject: [Live-devel] Problem with VLC and wis-streamer In-Reply-To: <475E0790.5090603@landform.com> References: <475D992A.1020503@landform.com> <475D9E77.8050507@landform.com> <475DA796.6090405@landform.com> <475DDC27.5040301@landform.com> <475DEEA4.8050209@landform.com> <475E0790.5090603@landform.com> Message-ID: >The "server" doesn't have a public IP. >It is behind a NAT (behind a consumer DSL modem) and doesn't even know >what it is NATed to. Yes, that's the problem. In general, you can't expect a RTSP sorry to work if it's behind a NAT. The IETF is working on overcoming this, but for now that's just the way it is. Sorry. (If only the RTSP *client* is behind a NAT - the setup that I originally thought you had - then that has more chance of working.) > The rtsp requests are being sent to the DSL >modem's IP. Not my choice of setup but what I have been dealt. The >joke is it almost works. By disabling timeouts it sort of works. Yes, count yourself lucky that it works at all. (You could also remove the "Content-Base:" header from the RTSP "OK" response ("RTSPServer.cpp", line 511).) And of course, RTP-over-TCP, which, right now, is the highest-probability way to get RTSP/RTP across NATs. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Dec 10 21:20:11 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Dec 2007 21:20:11 -0800 Subject: [Live-devel] Problem with VLC and wis-streamer Message-ID: Oops, of course, I *meant* to say: "In general, you can't expect a RTSP *server* to work if it's behind a NAT." -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From enrico.butera at edpi.it Tue Dec 11 00:45:45 2007 From: enrico.butera at edpi.it (Enrico Butera) Date: Tue, 11 Dec 2007 09:45:45 +0100 Subject: [Live-devel] Vatican CTV live stream In-Reply-To: <475DB673.9000901@gmx.at> References: <475DB673.9000901@gmx.at> Message-ID: <475E4E39.8090209@edpi.it> double ha scritto: > Hi, > > The Vatican CTV live stream - rtsp://212.77.7.133:80/h264lan.sdp > does not work with openRTSP. > > On the vatican homepage there is a note, that VLC media player > should play them, but it does not. If you remove :80 it plays ok with vlc 0.8.6b on windows, maybe http tunneling is not working server-side? From RGlobisch at csir.co.za Tue Dec 11 07:02:26 2007 From: RGlobisch at csir.co.za (Ralf Globisch) Date: Tue, 11 Dec 2007 17:02:26 +0200 Subject: [Live-devel] Design question: transferring control of sending RTP packets to source Message-ID: <475EC2A1.5DA9.004D.0@csir.co.za> Hi Ross, Thanks for your previous feedback, it's helped me get up and running quickly ;) Following your advice I've managed to do the following: I've written an RTP server and client based on the testMp3Streamer examples in which I'm just streaming a bunch of random data from the server to the client. On the server side I've written these classes - class MyTestRTPSource: public FramedSource - class MyTestVideoRTPSink: public VideoRTPSink On the client side: - class MyTestVideoRTPSource: public MultiFramedRTPSource - class MyCustomSink : public MediaSink Everything works as it should and all data transmitted from the server is received at the client ;) The next thing I would like to do is integrate the library into a DirectShow RTP filter server-side (I'll worry about the client side later). However I'm unsure how to change the overall design structure of the code in order to integrate it into a DirectShow pipeline without hacking it too much. Please correct me if I'm wrong: As far as I can see, all processing (sending of RTP data) occurs server side because of the task scheduler's event loop once the first packet has been scheduled by calling the sink's startPlaying() method: sessionState.sink->startPlaying(*sessionState.source, afterPlaying, NULL); env->taskScheduler().doEventLoop(); Structurally the MultiFramedRTPSink::sendPacketIfNecessary() is calling the following line right at the end nextTask() = envir().taskScheduler().scheduleDelayedTask(uSecondsToGo, (TaskFunc*)sendNext, this); This is causing the whole process to loop if I'm not mistaken: In a sense the sending of one packet schedules the sending of the next one? How would I transfer control of the sending of messages to the DirectShow pipeline i.e. every time a frame arrives in my DirectShow filter I want to send an RTP packet instead of the letting the aforementioned event loop of the live library schedule events? Do I need to write my own version of the MultiFramedRTPSink to transfer RTP control to the DirectShow pipeline and then call a method on my "FramedSource" subclass, which schedules another send every time I receive a frame in the DirectShow filter? Apologies if this post sounds messy, I'm finding it difficult to communicate my problem. Thanks, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From swapnil.indore at gmail.com Tue Dec 11 09:14:33 2007 From: swapnil.indore at gmail.com (Swapnil Jain) Date: Tue, 11 Dec 2007 22:44:33 +0530 Subject: [Live-devel] DVD to .ts Message-ID: <475EC579.1090000@gmail.com> Hi, have DVD video, there are VIDEO_TS and AUDIO_TS dir containing .vob and other files. How i convert it to .ts (MPEG Transport Stream). Any help appreciated. Swapnil Jain Indore From finlayson at live555.com Tue Dec 11 10:18:42 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Dec 2007 10:18:42 -0800 Subject: [Live-devel] Design question: transferring control of sending RTP packets to source In-Reply-To: <475EC2A1.5DA9.004D.0@csir.co.za> References: <475EC2A1.5DA9.004D.0@csir.co.za> Message-ID: >How would I transfer control of the sending of messages to the >DirectShow pipeline i.e. every time a frame arrives in my DirectShow >filter I want to send an RTP packet instead of the letting the >aforementioned event loop of the live library schedule events? You can't - you must use the event loop. ("LIVE555 Streaming Media" code is event-based; the event loop is its core.) You need to (somehow) make the arrival of a frame an event, which you will handle in a "FramedSource" subclass (which you would write) - to implement the "doGetNextFrame()" virtual function. Unfortunately I don't know enough about "DirectShow" to say how you would do this, but I suspect that you might need to write your own subclass of "TaskScheduler" and use that instead of "BasicTaskScheduler". >Do I need to write my own version of the MultiFramedRTPSink to >transfer RTP control to the DirectShow pipeline No, you won't need to write a new "RTPSink" subclass (other than the one that you already have). >and then call a method on my "FramedSource" subclass That method already exists: "doGetNextFrame()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Dec 11 10:21:35 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 11 Dec 2007 10:21:35 -0800 Subject: [Live-devel] DVD to .ts In-Reply-To: <475EC579.1090000@gmail.com> References: <475EC579.1090000@gmail.com> Message-ID: > have DVD video, there are VIDEO_TS and AUDIO_TS dir containing .vob and >other files. How i convert it to .ts (MPEG Transport Stream). ".vob" files are just MPEG Program Stream files. Therefore, you can convert each one into a Transport Stream file using our demo application "testMPEG1or2ProgramToTransportStream". (Rename each ".vob" file to "in.mpg" beforehand.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From akalingking at gmail.com Tue Dec 11 17:08:35 2007 From: akalingking at gmail.com (Ariel Kalingking) Date: Wed, 12 Dec 2007 09:08:35 +0800 Subject: [Live-devel] rtsp proxy Message-ID: Hi Ross, I am thinking of implementing a back to back server and client from the library acting as a proxy. I would like to ask for some points/ideas how is it possible or if has anyone implement rtsp *only* proxy, meaning the accompanying rtp would not be flowing through the proxy but instead directly between the participating endpoints? Regards, Ariel Kalingking From tl11305 at salle.url.edu Wed Dec 12 02:46:58 2007 From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis) Date: Wed, 12 Dec 2007 11:46:58 +0100 (CET) Subject: [Live-devel] HD Frames Message-ID: <1345.172.16.11.128.1197456418.squirrel@webmail.salle.url.edu> Hi all, I am trying to send a HD H.264 video and I found a problem when the frame size is bigger than unsigned range (0-65535) and I try to copy it to fTo pointer. First I thougt to change frameSize from unsigned to long, but error still apeared. I think it's not only a frameSize problem, so maximum packetSize is also set to a unsigned maxPacketSize. It's that right? Could someone give me a relatively easy solution to my problem? Maybe change system unsigned definition to a 32-bits word? Thanks in advance, Ramon From finlayson at live555.com Wed Dec 12 05:03:09 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Dec 2007 05:03:09 -0800 Subject: [Live-devel] HD Frames In-Reply-To: <1345.172.16.11.128.1197456418.squirrel@webmail.salle.url.edu> References: <1345.172.16.11.128.1197456418.squirrel@webmail.salle.url.edu> Message-ID: >Hi all, >I am trying to send a HD H.264 video and I found a problem when the frame size >is bigger than unsigned range (0-65535 Huh? That's the range for "unsigned short", not "unsigned". Where specifically in the code are you having trouble? (I hope you're using our "H264VideoRTPSink" class. It automatically fragments RTP packets - as specified by the H.264/RTP payload format - if H.264 NAL units are too large for outgoing RTP packets.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From RGlobisch at csir.co.za Wed Dec 12 05:30:16 2007 From: RGlobisch at csir.co.za (Ralf Globisch) Date: Wed, 12 Dec 2007 15:30:16 +0200 Subject: [Live-devel] Design question: transferring control of sending RTP packets to source Message-ID: <475FFE86.5DA9.004D.0@csir.co.za> Thanks for the help and the quick response Ross, I'll post my findings once I've figured it out, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. From howard at starvedia.com Wed Dec 12 06:53:17 2007 From: howard at starvedia.com (howard) Date: Wed, 12 Dec 2007 22:53:17 +0800 Subject: [Live-devel] compilation problem of VLC with live555 library built by myself Message-ID: <200712121451.lBCEosk7013030@mail.starvedia.com> HI all, I was trying to compile VLC with live555 enabled which was built by myself. The live555 I built was working fine. However, when I used it as a library for compiling VLC, I got some errors which said "undefined references to certain functions such as '_fcntl', '__errno', _recvfrom', '_sendto', '__getreent', '_fseeko', '_ftello', and '_getsockname' etc. Could anyone help me with it? Is there any DEFINE I missed or so? Thanks a lot in advance! Best Regards, Howard. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071212/0ecc4b92/attachment.html From finlayson at live555.com Wed Dec 12 11:37:53 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Dec 2007 11:37:53 -0800 Subject: [Live-devel] compilation problem of VLC with live555 library built by myself In-Reply-To: <200712121451.lBCEosk7013030@mail.starvedia.com> References: <200712121451.lBCEosk7013030@mail.starvedia.com> Message-ID: > I was trying to compile VLC with live555 enabled which >was built by myself. The live555 I built was working fine. Did the demo applications in the "testProgs" directory build and link OK? If so, then any subsequent problem you had linking VLC is something that you should ask about on a VLC mailing list. -- 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/20071212/8a8a6435/attachment.html From howard at starvedia.com Wed Dec 12 18:14:41 2007 From: howard at starvedia.com (howard) Date: Thu, 13 Dec 2007 10:14:41 +0800 Subject: [Live-devel] compilation problem of VLC with live555 library built by myself In-Reply-To: Message-ID: <200712130213.lBD2DKw0016170@mail.starvedia.com> Hi, The demo applications in the "testProgs" were built successfully. However, they could not work. In the beginning, it could not find the cygwin1.dll and then I copied it to testProgs/ to fix that problem. But when I ran anyone of the demo applications, it showed "segmentation fault"! What could be the cause of it?? How should I do with it? Thanks again for the help! Best Regards, Howard. _____ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, December 13, 2007 3:38 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] compilation problem of VLC with live555 library built by myself I was trying to compile VLC with live555 enabled which was built by myself. The live555 I built was working fine. Did the demo applications in the "testProgs" directory build and link OK? If so, then any subsequent problem you had linking VLC is something that you should ask about on a VLC mailing list. -- 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/20071212/d289cd02/attachment.html From chang.yiwen at tw.panasonic.com Wed Dec 12 19:37:02 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Thu, 13 Dec 2007 11:37:02 +0800 Subject: [Live-devel] how to play received stream via mplayer in local Message-ID: <00f901c83d39$6e794290$59085a0a@userd7c6bde7c0> Dear, I have written a h264 media sender and receiver, and they can work successfully. But, so far, in receiver, frames are received and saved to a file. We always to play the file via mplayer. I am asking a question: how can I play streaming in the receiver local via mplayer? I tried "mplayer rtp://localhost:8888". It can't not work. Thank you for answering. Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071212/4a41491c/attachment.html From finlayson at live555.com Wed Dec 12 20:53:12 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Dec 2007 20:53:12 -0800 Subject: [Live-devel] how to play received stream via mplayer in local In-Reply-To: <00f901c83d39$6e794290$59085a0a@userd7c6bde7c0> References: <00f901c83d39$6e794290$59085a0a@userd7c6bde7c0> Message-ID: >Dear, > >I have written a h264 media sender and receiver, >and they can work successfully. > >But, so far, in receiver, frames are received and saved to a file. >We always to play the file via mplayer. > >I am asking a question: >how can I play streaming in the receiver local via mplayer? > >I tried "mplayer rtp://localhost:8888". "rtp://" URLs are a non-standard hack, and work only for some media types. For H.264 RTP streams, the media player client needs to get extra codec and stream-specific information from the server before it can play the stream, and for that you need RTSP. So, you should add a RTSP server to your 'sender' application, and play the stream using a "rtsp://" URL. -- 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/20071212/35af6ea6/attachment.html From tl11305 at salle.url.edu Thu Dec 13 00:58:05 2007 From: tl11305 at salle.url.edu (=?ISO-8859-1?Q?Ramon_Mart=EDn_de_Pozuelo?=) Date: Thu, 13 Dec 2007 09:58:05 +0100 Subject: [Live-devel] HD Frames References: 1345.172.16.11.128.1197456418.squirrel@webmail.salle.url.edu Message-ID: <4760F41D.2000206@salle.url.edu> Hi Ross, my application stopped at this point: MyH264VideoStreamFramer::doGetNextFrame(){ getPayload(); // loading RTP payload information on pszBuff fMaxSize=1000000; fFrameSize=frameSize; memcpy(fTo,pszBuff,fFrameSize); ... when frameSize is bigger than unsigned short range. Program tries an invalid memory access: Instruction at 0x77c17000 referenced memory at 0x00bc2000. Memory could not be "written" I use H264VideoRTPSink and my source implementing virtual H264VideoStreamFramer functions. Wouldn't it part frame using H264FUAFragmenter whatever size of frame is? Or is there a maximum fMaxSize value? Thanks in advance, Ramon From aaditya_vik at yahoo.com Thu Dec 13 02:43:21 2007 From: aaditya_vik at yahoo.com (aditya vikram) Date: Thu, 13 Dec 2007 02:43:21 -0800 (PST) Subject: [Live-devel] Packet loss Message-ID: <462882.57661.qm@web33002.mail.mud.yahoo.com> Hi Ross, I am a novice programmer.I am doing video streaming over WAN(using TCP).I am testing mpeg4 video with 25fps and 100kb bitrate.I was getting very jerky stream on client side.When I tested I found error 10035 on server.So I increment the os buffer size from 50kb to 128 kb.Now I am getting better video but still packets are getting loss(near about 5-10%).As well I want to know the role of presentation time which is calculating after recieving the packet on the client side .I am testing server with vlc player as a client, I have also seen If all the packets are tranporting successfully from server then why vlc player is dropping some frames. Aditya --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071213/b6c6c52e/attachment.html From finlayson at live555.com Thu Dec 13 13:33:39 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Dec 2007 13:33:39 -0800 Subject: [Live-devel] HD Frames In-Reply-To: <4760F41D.2000206@salle.url.edu> References: 1345.172.16.11.128.1197456418.squirrel@webmail.salle.url.edu <4760F41D.2000206@salle.url.edu> Message-ID: >my application stopped at this point: > >MyH264VideoStreamFramer::doGetNextFrame(){ > > getPayload(); // loading RTP payload information on >pszBuff > fMaxSize=1000000; There's your problem. "fMaxSize" is an 'in' parameter. It is specified by the downstream object, and is the (maximum) size of the buffer that you can write into. You do not set it yourself. Your code should look something like: fFrameSize=frameSize; if (fFrameSize > fMaxSize) { fNumTruncatedBytes = fFrameSize - fMaxSize; fFrameSize = fMaxSize; } memcpy(fTo,pszBuff,fFrameSize); -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Dec 13 13:45:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Dec 2007 13:45:40 -0800 Subject: [Live-devel] Packet loss In-Reply-To: <462882.57661.qm@web33002.mail.mud.yahoo.com> References: <462882.57661.qm@web33002.mail.mud.yahoo.com> Message-ID: I suggest first running "openRTSP", with the "-Q" option, to see if you really are seeing network packet loss. If your packet loss is really due to lost packets on the network, then there isn't much you can do about this, except get a better network. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From swapnil.indore at gmail.com Fri Dec 14 00:10:18 2007 From: swapnil.indore at gmail.com (Swapnil Jain) Date: Fri, 14 Dec 2007 13:40:18 +0530 Subject: [Live-devel] DVD to .ts In-Reply-To: References: <475EC579.1090000@gmail.com> Message-ID: <47623A6A.7010905@gmail.com> where will i find this program to download, and what do u mean by "demo" Swapnil Jain Indore Ross Finlayson wrote: >> have DVD video, there are VIDEO_TS and AUDIO_TS dir containing .vob and >> other files. How i convert it to .ts (MPEG Transport Stream). >> > > ".vob" files are just MPEG Program Stream files. Therefore, you can > convert each one into a Transport Stream file using our demo > application "testMPEG1or2ProgramToTransportStream". (Rename each > ".vob" file to "in.mpg" beforehand.) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071214/83f2fd66/attachment.html From tl11305 at salle.url.edu Fri Dec 14 00:42:44 2007 From: tl11305 at salle.url.edu (=?ISO-8859-1?Q?Ramon_Mart=EDn_de_Pozuelo?=) Date: Fri, 14 Dec 2007 09:42:44 +0100 Subject: [Live-devel] HD Frames References: 4760F41D.2000206@salle.url.edu Message-ID: <47624204.1060009@salle.url.edu> Perfect. I changed it. Thank you very much Ross! Ramon From finlayson at live555.com Fri Dec 14 03:42:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Dec 2007 03:42:57 -0800 Subject: [Live-devel] DVD to .ts In-Reply-To: <47623A6A.7010905@gmail.com> References: <475EC579.1090000@gmail.com> <47623A6A.7010905@gmail.com> Message-ID: >where will i find this program to download "testMPEG1or2ProgramToTransportStream" is one of the applications in the "testProgs" directory. > and what do u mean by "demo" demonstration -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gbonneau at matrox.com Fri Dec 14 09:34:18 2007 From: gbonneau at matrox.com (Guy Bonneau) Date: Fri, 14 Dec 2007 12:34:18 -0500 Subject: [Live-devel] push and pull streaming Message-ID: <02c601c83e77$8e6c9450$aa42a8c0@dorvalmatrox.matrox.com> I read in the FAQ section that it is possible to modify the test*Streamer application to stream from an Mpeg encoder. Doing that change will switch the library from a pulling to pushing streaming model. Does the library have that capability? I'm also concerned by the fact that a hardware encoder might have a different system clock (hardware based) than the library which seems to be CPU based? Could you provide some insight? Thanks Guy Bonneau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071214/22567f75/attachment.html From mailinglist at mbs-technet.com Fri Dec 14 10:07:09 2007 From: mailinglist at mbs-technet.com (Maik Brauer) Date: Fri, 14 Dec 2007 19:07:09 +0100 Subject: [Live-devel] openRTSP Command Line Tool Message-ID: <3781D714-4D1E-472F-A782-F6619FB241A8@mbs-technet.com> Hi there, I've tried now several times to save a Stream with openRTSP to play it afterwards with (VLC, or other Player-Applications) The stream which is arriving is a H.264 Stream with AMR Audio Codec. After a while (2 Minutes) of recording and writing it into a file I've stopped it and have tried to open it via a player like mentions above. But what I can see is only a picture. It is not possible to hear the audio-layer. I've tried to record it in separate files, which means a file for: video-H264-1 and Audio file: audio-AMR-2 This is as well not working. Is there any problem in the openRTSP tool, maybe a known bug, or did I make something wrong? If you need some samples, please let me know, so that I can send you some traces or details. Many Thanks in advance. Cheers, Maik Brauer From finlayson at live555.com Fri Dec 14 17:28:47 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Dec 2007 17:28:47 -0800 Subject: [Live-devel] openRTSP Command Line Tool In-Reply-To: <3781D714-4D1E-472F-A782-F6619FB241A8@mbs-technet.com> References: <3781D714-4D1E-472F-A782-F6619FB241A8@mbs-technet.com> Message-ID: >I've tried now several times to save a Stream with openRTSP to play it >afterwards with (VLC, or other Player-Applications) >The stream which is arriving is a H.264 Stream with AMR Audio Codec. >After a while (2 Minutes) of recording and writing it into a file I've >stopped it and have tried to open it via a player like mentions above. > >But what I can see is only a picture. It is not possible to hear the >audio-layer. I think the problem here is only that VLC (at least, by default) does not include an AMR audio decoder, and therefore cannot play the audio from your stream. >I've tried to record it in separate files, which means a file for: >video-H264-1 and Audio file: audio-AMR-2 If you rename the audio file to have a ".amr" filename suffix, then you should be able to play it in QuickTime Player (which has an AMR decoder). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Dec 14 22:43:27 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Dec 2007 22:43:27 -0800 Subject: [Live-devel] push and pull streaming In-Reply-To: <02c601c83e77$8e6c9450$aa42a8c0@dorvalmatrox.matrox.com> References: <02c601c83e77$8e6c9450$aa42a8c0@dorvalmatrox.matrox.com> Message-ID: >I read in the FAQ section that it is possible to modify the > test*Streamer application to stream from an Mpeg encoder. Doing >that change will switch the library from a pulling to pushing >streaming model. No. The library always works by having each downstream object call its upstream object, asking for data. However, when you're streaming from a live source (such as an encoder), the key point to note is that the arrival of data from the live source is best handled as an event in the event loop (rather than a synchronous read). In any case, the live source is encapsulated in a subclass (that you would write) of "FramedSource", and new data is delivered to the downstream object in your implementation of the virtual function "doGetNextFrame()". >I'm also concerned by the fact that a hardware encoder might have a >different system clock (hardware based) than the library which seems >to be CPU based? This should not be a problem. If - in your "FramedSource" subclass - you *don't* set the "fDurationInMicroseconds" field. By not setting this field, it remains at its default value of 0, and the (RTP) sink object will ask for new data immediately after it sends a packet. -- 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/20071214/b8666a2a/attachment-0001.html From eric.pheatt at gmail.com Sun Dec 16 13:29:20 2007 From: eric.pheatt at gmail.com (Eric Pheatt) Date: Sun, 16 Dec 2007 13:29:20 -0800 Subject: [Live-devel] Mpeg Audio missing or corrupted in MPEG-2 Transport Stream or seperate sreams Message-ID: <56ad9b8c0712161329l7d74ae09g912ff4718037d4c5@mail.gmail.com> I'm using wisremote as a channel changing script for wis-streamer so that I can record tv using MythTV's Freebox rtsp recorder. While I get the video just fine the audio appears to be missing. I'm wondering if anyone else can confirm that the following command should work. wis-streamer -i 2 -c ntsc-cable:57 -t ntsc -p 8554 -w 720 -h 480 -mpeg2 -r 1500000 -mpegaudio 192 -mpegtransport 192 -D "Streaming COMEDYP" VLC reports that there is an audio stream in addition to the video, but I no matter how high I crank the volume I can't hear anything. If I don't use the mpegtransport option and use pcm for the audio instead of mpegaudio so that I have separate streams I can hear the audio just fine in VLC so I don't think it is a driver or VLC issue. Any thoughts? Thanks, Eric From finlayson at live555.com Sun Dec 16 15:08:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 16 Dec 2007 15:08:15 -0800 Subject: [Live-devel] Mpeg Audio missing or corrupted in MPEG-2 Transport Stream or seperate sreams In-Reply-To: <56ad9b8c0712161329l7d74ae09g912ff4718037d4c5@mail.gmail.com> References: <56ad9b8c0712161329l7d74ae09g912ff4718037d4c5@mail.gmail.com> Message-ID: >I'm using wisremote as a channel changing script for wis-streamer so >that I can record tv using MythTV's Freebox rtsp recorder. While I get >the video just fine the audio appears to be missing. > >I'm wondering if anyone else can confirm that the following command >should work. > >wis-streamer -i 2 -c ntsc-cable:57 -t ntsc -p 8554 -w 720 -h 480 >-mpeg2 -r 1500000 -mpegaudio 192 -mpegtransport 192 -D "Streaming >COMEDYP" If you use "-mpegtransport ", then that specifies both the video codec (MPEG-2) and the audio codec (MPEG-2), so you should *not* also use "-mpeg2" or "-mpegaudio". >VLC reports that there is an audio stream in addition to the video, >but I no matter how high I crank the volume I can't hear anything. If >I don't use the mpegtransport option and use pcm for the audio instead >of mpegaudio so that I have separate streams I can hear the audio just >fine in VLC What happens if you specify "-mpegaudio 192" and "-mpeg2" *instead* of "-mpegtransport 192"? What happens if you specify "-mpegaudio 192" *only* (and not "-mpeg2" or "-mpegtransport 192")? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From eric.pheatt at gmail.com Sun Dec 16 15:44:00 2007 From: eric.pheatt at gmail.com (Eric Pheatt) Date: Sun, 16 Dec 2007 15:44:00 -0800 Subject: [Live-devel] Mpeg Audio missing or corrupted in MPEG-2 Transport Stream or seperate sreams In-Reply-To: References: <56ad9b8c0712161329l7d74ae09g912ff4718037d4c5@mail.gmail.com> Message-ID: <56ad9b8c0712161544wc1e25cap39be550d73795628@mail.gmail.com> On Dec 16, 2007 3:08 PM, Ross Finlayson wrote: > >I'm using wisremote as a channel changing script for wis-streamer so > >that I can record tv using MythTV's Freebox rtsp recorder. While I get > >the video just fine the audio appears to be missing. > > > >I'm wondering if anyone else can confirm that the following command > >should work. > > > >wis-streamer -i 2 -c ntsc-cable:57 -t ntsc -p 8554 -w 720 -h 480 > >-mpeg2 -r 1500000 -mpegaudio 192 -mpegtransport 192 -D "Streaming > >COMEDYP" > > If you use "-mpegtransport ", then that > specifies both the video codec (MPEG-2) and the audio codec (MPEG-2), > so you should *not* also use "-mpeg2" or "-mpegaudio". Ok tried that and still no audio. > > >VLC reports that there is an audio stream in addition to the video, > >but I no matter how high I crank the volume I can't hear anything. If > >I don't use the mpegtransport option and use pcm for the audio instead > >of mpegaudio so that I have separate streams I can hear the audio just > >fine in VLC > > What happens if you specify "-mpegaudio 192" and "-mpeg2" *instead* > of "-mpegtransport 192"? This produces no audio. > What happens if you specify "-mpegaudio 192" *only* (and not "-mpeg2" > or "-mpegtransport 192")? This produces no audio and but the video is the default mpeg4 with default rate. next steps? From finlayson at live555.com Sun Dec 16 16:09:41 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 16 Dec 2007 16:09:41 -0800 Subject: [Live-devel] Mpeg Audio missing or corrupted in MPEG-2 Transport Stream or seperate sreams In-Reply-To: <56ad9b8c0712161544wc1e25cap39be550d73795628@mail.gmail.com> References: <56ad9b8c0712161329l7d74ae09g912ff4718037d4c5@mail.gmail.com> <56ad9b8c0712161544wc1e25cap39be550d73795628@mail.gmail.com> Message-ID: > > What happens if you specify "-mpegaudio 192" and "-mpeg2" *instead* >> of "-mpegtransport 192"? > >This produces no audio. > >> What happens if you specify "-mpegaudio 192" *only* (and not "-mpeg2" >> or "-mpegtransport 192")? > >This produces no audio and but the video is the default mpeg4 with >default rate. That's odd. It seems that the (software) MPEG audio encoder is not working properly for you. I don't know why that would be, though... > >next steps? 1/ Try streaming MPEG audio, but no video: -mpegaudio 192 -nv 2/ Try changing the audio output bitrate -mpegaudio 128 3/ Try changing the audio sampling frequency -f 44100 -mpegaudio 192 4/ Try combining 2/ and 3/ -f 44100 -mpegaudio 128 Unfortunately I'm just grasping at straws at this point... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From chang.yiwen at tw.panasonic.com Mon Dec 17 01:47:21 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Mon, 17 Dec 2007 17:47:21 +0800 Subject: [Live-devel] RTSP of H264 Message-ID: <015c01c84091$d7d38ba0$59085a0a@userd7c6bde7c0> Hi, I have question about mplayer & H264 RTSP. We implemented a H264 stream sender and receiver, and they works successfully. Now, we tried to connect our stream sender and play from MPlayer. (For that, a RTSP server is implemented in the stream sender.) But, MPlayer shows the error: "decode_slice_header error... error while decoding frame". I am also asking help for MPlayer developers. But, I tried "testMPEG1or2VideoStream.cpp". MPlayer can play the streaming normally. I wonder if the problem results from our stream server, not MPlayer. I want to ask that, when a RTSP server is enabled, doGetNextFrame() in H264VideoStreamFramer also works as before (copy a NAL/frame into fTo)? RTSP server always sends frames out before MPlayer ask for streaming. Please help us to solve the problem... Many thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071217/47b13907/attachment.html From finlayson at live555.com Mon Dec 17 02:00:35 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Dec 2007 02:00:35 -0800 Subject: [Live-devel] RTSP of H264 In-Reply-To: <015c01c84091$d7d38ba0$59085a0a@userd7c6bde7c0> References: <015c01c84091$d7d38ba0$59085a0a@userd7c6bde7c0> Message-ID: >We implemented a H264 stream sender and receiver, and they works successfully. > >Now, we tried to connect our stream sender and play from MPlayer. >(For that, a RTSP server is implemented in the stream sender.) > >But, MPlayer shows the error: "decode_slice_header error... error >while decoding frame". > >I am also asking help for MPlayer developers. That's good, because that error indicates a problem with the decoder, *not* with our software > But, I tried "testMPEG1or2VideoStream.cpp". MPlayer can play the >streaming normally. I don't see how, because the data is not MPEG-1 or MPEG-2. > I wonder if the problem results from our stream server, not MPlayer. Possibly. Have you also tried using VLC as your client? -- 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/20071217/596d35e7/attachment.html From belloni at imavis.com Mon Dec 17 03:48:30 2007 From: belloni at imavis.com (Cristiano Belloni) Date: Mon, 17 Dec 2007 12:48:30 +0100 Subject: [Live-devel] Questions on streaming live H263 videos Message-ID: <4766620E.5000707@imavis.com> Hi to everybody, I've got a couple hopefully basic questions about live streaming with live555. I'd like to stream h263-encoded videos to various media players (mainly realplayer on mobile phones). What I do now is starting a thread that captures live frames and encodes them in H263 with ffmpeg. The thread writes on a Unix named pipe (FIFO). Then I create a RTSPServer instance, create a ServerMediaSession and add a subsession, passing the FIFO file name as the subsession parameter. A few problems arise, in order of importance: 1) VLC and Mplayer are able to play the live video, while RealPlayer isn't. I captured the network conversation with wireshark, and it seems the RTSP negotiation is done correctly, but the server just won't send RTP packets (while with VLC or MPlayer it does). Here's the captured RTSP conversation: User-Agent: RealMedia Player/mc.28.16.01 (s60; epoc_av21_thumb) CSeq: 1 RTSP/1.0 200 OK CSeq: 1 Date: Mon, Dec 17 2007 11:26:51 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE DESCRIBE rtsp://217.133.231.30/H263ESVideoTest RTSP/1.0 x-wap-profile: "http://nds1.nds.nokia.com/uaprof/NN70-1r100.xml" ClientID: RealOnePlayer_s60.28.16.01_21-Apr-2006_10:28:59_epoc_av21_thumb Accept: application/sdp Bandwidth: 298368 GUID: 00000000-0000-0000-0000-000000000000 User-Agent: RealMedia Player/mc.28.16.01 (s60; epoc_av21_thumb) CSeq: 2 RTSP/1.0 200 OK CSeq: 2 Date: Mon, Dec 17 2007 11:26:51 GMT Content-Base: rtsp://217.133.231.30/H263ESVideoTest/ Content-Type: application/sdp Content-Length: 384 v=0 o=- 1197890794075912 1 IN IP4 217.133.231.30 s=Session streamed live by "rtspServer" i=H263ESVideoTest t=0 0 a=tool:LIVE555 Streaming Media v2007.12.06 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session streamed live by "rtspServer" a=x-qt-text-inf:H263ESVideoTest m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 a=rtpmap:96 H263-1998/90000 a=control:track1 SETUP rtsp://217.133.231.30/H263ESVideoTest/track1 RTSP/1.0 x-wap-profile: "http://nds1.nds.nokia.com/uaprof/NN70-1r100.xml" Transport: RTP/AVP;unicast;client_port=26022-26023;mode=play User-Agent: RealMedia Player/mc.28.16.01 (s60; epoc_av21_thumb) CSeq: 3 RTSP/1.0 200 OK CSeq: 3 Date: Mon, Dec 17 2007 11:26:52 GMT Transport: RTP/AVP;unicast;destination=217.201.153.216;source=217.133.231.30;client_port=26022-26023;server_port=6970-6971 Session: 1 PLAY rtsp://217.133.231.30/H263ESVideoTest/ RTSP/1.0 Range: npt=0.000- Session: 1 User-Agent: RealMedia Player/mc.28.16.01 (s60; epoc_av21_thumb) CSeq: 4 RTSP/1.0 200 OK CSeq: 4 Date: Mon, Dec 17 2007 11:26:52 GMT Range: npt=0.000- Session: 1 RTP-Info: url=rtsp://217.133.231.30/H263ESVideoTest/track1;seq=1723;rtptime=1928192185 (The client was RealPlayer from a Nokia N70 mobile, same behaviour with RealPlayer for Linux on the same host of the server, so it's not a network problem). The client will then send RTCP control packets regularly, along with some strange RTP packets with payload = 73, but the server won't send any RTP or RTCP packet, even if the PLAY command was accepted by the server. 2) VLC and Mplayer correctly view the live video, but they often will play a chunk of it, then "freeze" the frame for a few seconds, then play another chunk, then freeze again. What could the problem be? Buffering? Too many packets? (I acquire at 25 fps, but vlc is on the same host as the server). Please note all this problems disappear when i stream from a file containing raw h263 data @ 25 fps. 3) In my naive implementation, I start the encoder thread after adding the subsession and before the taskScheduler().doEventLoop() call. I'd like, instead, to start my decoder thread when and only when a client does a request for the stream (sparing resources when the server is idle), in an "on demand" fashion. How can I do that? I thought about starting the decoder thread in specialClientAccessCheck method, subclassing RTSPServer class, but I don't think it's the right way to do it (after all, specialClientAccessCheck is for checking IPs and request URLs). Best regards and thanks in advance for your help, Cristiano. -- Belloni Cristiano From finlayson at live555.com Mon Dec 17 07:03:11 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Dec 2007 07:03:11 -0800 Subject: [Live-devel] Questions on streaming live H263 videos In-Reply-To: <4766620E.5000707@imavis.com> References: <4766620E.5000707@imavis.com> Message-ID: >I'd like to stream h263-encoded videos to various media players (mainly >realplayer on mobile phones). > >What I do now is starting a thread that captures live frames and encodes >them in H263 with ffmpeg. The thread writes on a Unix named pipe (FIFO). >Then I create a RTSPServer instance, create a ServerMediaSession and add >a subsession, passing the FIFO file name as the subsession parameter. I presume you're using a "H263plusVideoFileServerMediaSubsession" object for your video. Be sure to set the "reuseFirstSource" parameter to "True", because you are streaming from a single (live) source, rather than from a file that's stored on disk. >1) VLC and Mplayer are able to play the live video, while RealPlayer >isn't. I captured the network conversation with wireshark, and it seems >the RTSP negotiation is done correctly, but the server just won't send >RTP packets (while with VLC or MPlayer it does). You're going to have to figure out yourself why the server is not streaming. (Remember, You Have Complete Source Code (for the server), and also a working client.) I'm not surprised, however, that RealPlayer doesn't wor; it's notoriously non-standards compliant. >2) VLC and Mplayer correctly view the live video, but they often will >play a chunk of it, then "freeze" the frame for a few seconds, then play >another chunk, then freeze again. What could the problem be? Buffering? That's my guess. Can you increase the buffer size of your pipe? >3) In my naive implementation, I start the encoder thread after adding >the subsession and before the taskScheduler().doEventLoop() call. I'd >like, instead, to start my decoder thread when and only when a client >does a request for the stream (sparing resources when the server is >idle), in an "on demand" fashion. First, remember to set "reuseFirstSource" to "True" (as noted above), so that you create only one source object, regardless of the number of clients. I suggest defining a subclass of "H263plusVideoFileServerMediaSubsession", and redefining the "createNewStreamSource()" virtual function to start your encoder(sic) thread, and then call the parent class ("H263plusVideoFileServerMediaSubsession")'s "createNewStreamSource()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From belloni at imavis.com Mon Dec 17 07:31:32 2007 From: belloni at imavis.com (Cristiano Belloni) Date: Mon, 17 Dec 2007 16:31:32 +0100 Subject: [Live-devel] Questions on streaming live H263 videos In-Reply-To: <4766620E.5000707@imavis.com> References: <4766620E.5000707@imavis.com> Message-ID: <47669654.2050809@imavis.com> >I presume you're using a "H263plusVideoFileServerMediaSubsession" >object for your video. I do. >Be sure to set the "reuseFirstSource" >parameter to "True", because you are streaming from a single (live) >source, rather than from a file that's stored on disk. I did. >You're going to have to figure out yourself why the server is not >streaming. (Remember, You Have Complete Source Code (for the >server), and also a working client.) I'm not surprised, however, >that RealPlayer doesn't wor; it's notoriously non-standards compliant. Yeah, but the RTSP negotiation goes well, and after that it would be RTSPServer's turn to start sending RTP packets, which it doesn't. Could it be a server-related problem? What I can see is Realplayer terminating its RTSP dialogue and waiting for packets that should come (but never come). Isn't it what the client is supposed to do? >That's my guess. Can you increase the buffer size of your pipe? I can and I will try. >I suggest defining a subclass of >"H263plusVideoFileServerMediaSubsession", and redefining the >"createNewStreamSource()" virtual function to start your encoder(sic) >thread, and then call the parent class >("H263plusVideoFileServerMediaSubsession")'s >"createNewStreamSource()". Great. Thank you. Best Regards, Cristiano From belloni at imavis.com Mon Dec 17 07:39:55 2007 From: belloni at imavis.com (Cristiano Belloni) Date: Mon, 17 Dec 2007 16:39:55 +0100 Subject: [Live-devel] Questions on streaming live H263 videos In-Reply-To: <4766620E.5000707@imavis.com> References: <4766620E.5000707@imavis.com> Message-ID: <4766984B.70206@imavis.com> >You're going to have to figure out yourself why the server is not >streaming. (Remember, You Have Complete Source Code (for the >server), and also a working client.) I'm not surprised, however, >that RealPlayer doesn't wor; it's notoriously non-standards compliant. Also, the odd thing is that server + RealPlayer works perfectly with pre-recorded raw H263 files, but doesn't send RTP packets only when working with live streams on FIFO. The only difference I can see is that files are seekable, while FIFO aren't. Could it be the source of the problem? Regards, Cristiano. From mailinglist at mbs-technet.com Mon Dec 17 10:17:12 2007 From: mailinglist at mbs-technet.com (Maik Brauer) Date: Mon, 17 Dec 2007 19:17:12 +0100 Subject: [Live-devel] openRTSP Command Line Tool In-Reply-To: References: <3781D714-4D1E-472F-A782-F6619FB241A8@mbs-technet.com> Message-ID: <3F08F8BB-CCAE-408B-95CB-D109CFF2E1F3@mbs-technet.com> Hi, I've compiled the AMR audio codes into the VLC Software. I'm able to play video and audio when I'm connection directly to the streaming source, for example a Darwin Streaming Server. But if I try it via openRTSP, where I'm opening a saved file it is not possible, So something must be wrong with the saved files. Renaming in AMR (suffix) is not working as well. The suffix is at least not that interesting if you force an application to open it. It is only a cosmetical an Plug and play feature, twith this suffixes. So what can I do else? Any suggestions?? Cheers, Maik On Dec 15, 2007, at 2:28 AM, Ross Finlayson wrote: >> I've tried now several times to save a Stream with openRTSP to play >> it >> afterwards with (VLC, or other Player-Applications) >> The stream which is arriving is a H.264 Stream with AMR Audio Codec. >> After a while (2 Minutes) of recording and writing it into a file >> I've >> stopped it and have tried to open it via a player like mentions >> above. >> >> But what I can see is only a picture. It is not possible to hear the >> audio-layer. > > I think the problem here is only that VLC (at least, by default) does > not include an AMR audio decoder, and therefore cannot play the audio > from your stream. > >> I've tried to record it in separate files, which means a file for: >> video-H264-1 and Audio file: audio-AMR-2 > > If you rename the audio file to have a ".amr" filename suffix, then > you should be able to play it in QuickTime Player (which has an AMR > decoder). > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Mon Dec 17 14:24:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Dec 2007 14:24:20 -0800 Subject: [Live-devel] openRTSP Command Line Tool In-Reply-To: <3F08F8BB-CCAE-408B-95CB-D109CFF2E1F3@mbs-technet.com> References: <3781D714-4D1E-472F-A782-F6619FB241A8@mbs-technet.com> <3F08F8BB-CCAE-408B-95CB-D109CFF2E1F3@mbs-technet.com> Message-ID: >I've compiled the AMR audio codes into the VLC Software. >I'm able to play video and audio when I'm connection directly to the >streaming source, >for example a Darwin Streaming Server. >But if I try it via openRTSP, where I'm opening a saved file it is not >possible, >So something must be wrong with the saved files. Not necessarily. Are you able to play the file in QuickTime Player (after you change the name to have the ".amr" filename suffix)? If so, but you're not able to play the file in VLC, then the problem is that VLC is not properly interpreting the content of ".amr" files. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Dec 17 14:38:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Dec 2007 14:38:43 -0800 Subject: [Live-devel] Questions on streaming live H263 videos In-Reply-To: <4766984B.70206@imavis.com> References: <4766620E.5000707@imavis.com> <4766984B.70206@imavis.com> Message-ID: > >You're going to have to figure out yourself why the server is not >>streaming. (Remember, You Have Complete Source Code (for the >>server), and also a working client.) I'm not surprised, however, >>that RealPlayer doesn't wor; it's notoriously non-standards compliant. > >Also, the odd thing is that server + RealPlayer works perfectly with >pre-recorded raw H263 files, but doesn't send RTP packets only when >working with live streams on FIFO. The only difference I can see is >that files are seekable, while FIFO aren't. Could it be the source >of the problem? I don't see how. When you try streaming from a live source to RealPlayer, are RTP packets not getting sent by the server at all, or are they getting sent by the server, but ignored by the client (RealPlayer). If it's the former, then this is something you should be able to figure out. If it's the latter, then it's probably a problem with RealPlayer (and you will need to ask about it on a RealPlayer mailing list). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From eric.pheatt at gmail.com Mon Dec 17 16:09:48 2007 From: eric.pheatt at gmail.com (Eric Pheatt) Date: Mon, 17 Dec 2007 16:09:48 -0800 Subject: [Live-devel] Mpeg Audio missing or corrupted in MPEG-2 Transport Stream or seperate sreams In-Reply-To: References: <56ad9b8c0712161329l7d74ae09g912ff4718037d4c5@mail.gmail.com> <56ad9b8c0712161544wc1e25cap39be550d73795628@mail.gmail.com> Message-ID: <56ad9b8c0712171609g6b9c62cck8192ee68669c417b@mail.gmail.com> On Dec 16, 2007 4:09 PM, Ross Finlayson wrote: > > > What happens if you specify "-mpegaudio 192" and "-mpeg2" *instead* > >> of "-mpegtransport 192"? > > > >This produces no audio. > > > >> What happens if you specify "-mpegaudio 192" *only* (and not "-mpeg2" > >> or "-mpegtransport 192")? > > > >This produces no audio and but the video is the default mpeg4 with > >default rate. > > That's odd. It seems that the (software) MPEG audio encoder is not > working properly for you. I don't know why that would be, though... > > > > >next steps? > > 1/ Try streaming MPEG audio, but no video: > -mpegaudio 192 -nv Nothing here either. > 2/ Try changing the audio output bitrate > -mpegaudio 128 Nope nothing either. > 3/ Try changing the audio sampling frequency > -f 44100 -mpegaudio 192 Still nothing. > 4/ Try combining 2/ and 3/ > -f 44100 -mpegaudio 128 > > Unfortunately I'm just grasping at straws at this point... Still nothing on those. I had updated WISInput.cpp neat line 208 to look more like gorecord for audio device selection because the I was getting an "Unable to find emulated OSS device node" message. But since I am getting pcm audio I doubt that is the issue. + char *c; + printf(line, "%d: [%u-%*u]: digital audio\n", &m, &n); - //if (sscanf(line, "%d: [%u-%*u]: digital audio\n", &m, &n) != 2) continue; + if ((c = strrchr(line, ':')) == NULL || + strcmp(c, ": digital audio\n") || + sscanf(line, "%d: [%u-%*u]:", &m, &n) != 2) + continue; Also with aac I no sound. With amr I get no sound but I also get the following from wis-streamer: RTCPInstance::RTCPInstance error: totSessionBW parameter should not be zero! And with ulaw all I get is static. Here is some sound device info from my system: #ls -ltr /dev/dsp* crw-rw---- 1 root audio 14, 3 Dec 14 17:38 /dev/dsp 3cat /proc/asound/oss/devices 0: [0- 0]: mixer 3: [0- 0]: digital audio 4: [0- 0]: digital audio #cat /sys/class/sound/dsp/dev 14:3 #cat /proc/asound/oss/sndstatcat /proc/asound/oss/sndstat Sound Driver:3.8.1a-980706 (ALSA v1.0.14 emulation code) Kernel: Linux KUROHG 2.6.23.9 #2 Fri Dec 7 13:43:42 PST 2007 ppc Config options: 0 Installed drivers: Type 10: ALSA emulation Card config: Plextor PX-TV402 Audio devices: 0: Synth devices: NOT ENABLED IN CONFIG Midi devices: NOT ENABLED IN CONFIG Timers: 7: system timer Mixers: 0: mixer00 Could this be an endian issue with the audio encoders that are currently being used? Im running this on a KuroHG PowerPC (http://www.nas-central.org/index.php/Category:Kurobox) that I have used with mythtv as regular recording device but the current mythtv support does not include mpeg2 video at the moment. Adding mythtv support for mpeg2 is out of my league, so I had hoped that wis-streamer would meet my needs. It appears that the mpegaudio.c in wis-streamer is close to an older version of ffmpeg based on the comments, do you recall when this was included? Thanks for helping track this issue for me down. -Eric From chang.yiwen at tw.panasonic.com Mon Dec 17 16:38:28 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Tue, 18 Dec 2007 08:38:28 +0800 Subject: [Live-devel] RTSP of H264 Message-ID: <001001c8410e$50416630$59085a0a@userd7c6bde7c0> Hi, >>But, MPlayer shows the error: "decode_slice_header error... error >>while decoding frame". >> >>I am also asking help for MPlayer developers. >That's good, because that error indicates a problem with the decoder, >*not* with our software I tried to send some frames, not a whole file. I found that, MPlayer just receives date from the fifth frame and not a complete frame, so that results in no complete header and error while decoding frame in MPlayer. > I wonder if the problem results from our stream server, not MPlayer. Possibly. Have you also tried using VLC as your client? I will try VLC (although it is not easy to install comparing with MPlayer). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071217/eea3977f/attachment.html From finlayson at live555.com Mon Dec 17 18:11:26 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Dec 2007 18:11:26 -0800 Subject: [Live-devel] Mpeg Audio missing or corrupted in MPEG-2 Transport Stream or seperate sreams In-Reply-To: <56ad9b8c0712171609g6b9c62cck8192ee68669c417b@mail.gmail.com> References: <56ad9b8c0712161329l7d74ae09g912ff4718037d4c5@mail.gmail.com> <56ad9b8c0712161544wc1e25cap39be550d73795628@mail.gmail.com> <56ad9b8c0712171609g6b9c62cck8192ee68669c417b@mail.gmail.com> Message-ID: >And with ulaw all I get is static. Interesting.... >Could this be an endian issue with the audio encoders that are >currently being used? > >Im running this on a KuroHG PowerPC Interesting. Byte ordering could well be the problem. The "wis-streamer" code assumes that the input (16-bit PCM) audio samples have the same byte order as the computer host. PowerPC is big-endian (at least by default). Is it possible that your audio PCM input source is, instead, little-endian? If so, can you change this? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Dec 17 18:55:44 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Dec 2007 18:55:44 -0800 Subject: [Live-devel] RTSP of H264 In-Reply-To: <001001c8410e$50416630$59085a0a@userd7c6bde7c0> References: <001001c8410e$50416630$59085a0a@userd7c6bde7c0> Message-ID: >Possibly. Have you also tried using VLC as your client? >I will try VLC (although it is not easy to install comparing with MPlayer). Huh? VLC has pre-built binary versions for many platforms. -- 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/20071217/713a231d/attachment.html From motze2000 at gmx.de Mon Dec 17 23:12:48 2007 From: motze2000 at gmx.de (motze) Date: Tue, 18 Dec 2007 08:12:48 +0100 Subject: [Live-devel] UDP-Lite Message-ID: <476772F0.7050001@gmx.de> Hi, currently i am working on biterror conceilment and want to use live555 as a platform to test some algorithms to recover corrupted packets. is there a possibility to implement udp-lite into the framework? because usually packets are discarded if an error in the udp packet occurs, but with udp-lite i can set the checksum coverage only for the really important parts (e.g. header) thanks! motze From finlayson at live555.com Tue Dec 18 00:57:06 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Dec 2007 00:57:06 -0800 Subject: [Live-devel] UDP-Lite In-Reply-To: <476772F0.7050001@gmx.de> References: <476772F0.7050001@gmx.de> Message-ID: >Hi, >currently i am working on biterror conceilment and want to use live555 >as a platform to test some algorithms to >recover corrupted packets. is there a possibility to implement udp-lite >into the framework? I suppose. If you wanted to do this, the best place to do this would be to modify the "groupsock" library. Personally, though, I think UDP-lite is rather pointless, because almost all link-layer protocols (and certainly all the common ones, like Ethernet and 'WiFi) checksum each data packet, and reject those that contain bit errors (so a higher-level 'UDP-lite protocol would never get to see the packet). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From chang.yiwen at tw.panasonic.com Tue Dec 18 02:17:33 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Tue, 18 Dec 2007 18:17:33 +0800 Subject: [Live-devel] RTSP of H264 Message-ID: <00d801c8415f$364306c0$59085a0a@userd7c6bde7c0> >>Possibly. Have you also tried using VLC as your client? >>I will try VLC (although it is not easy to install comparing with MPlayer). > Huh? VLC has pre-built binary versions for many platforms. Maybe, but we lack some dependent libraries, and these libraries lack other dependencies. I think, before mplayer connect to RTSP server successfully, RTSP server has already copyed data in doGetNextFrame() and sent out frames to the rtpport of destination. So that results in no complete frame and slice header is received by mplayer and can't play. How can we let a h264 rtsp server start streaming after mplayer request to get streaming? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071218/8ec58459/attachment.html From chang.yiwen at tw.panasonic.com Tue Dec 18 02:43:14 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Tue, 18 Dec 2007 18:43:14 +0800 Subject: [Live-devel] RTSP of H264 Message-ID: <00e001c84162$cff1f440$59085a0a@userd7c6bde7c0> >Maybe, but we lack some dependent libraries, and these libraries lack other dependencies. >I think, before mplayer connect to RTSP server successfully, RTSP server has already copyed data >in doGetNextFrame() and sent out frames to the rtpport of destination. >So that results in no complete frame and slice header is received by mplayer and can't play. >How can we let a h264 rtsp server start streaming after mplayer request to get streaming? If we connect to mpeg1or2 rtsp server (testMPEG1or2VideoStreamer.cpp) via MPlayer? MPlayer still can't decode successfully because of data loss. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071218/05ec24ad/attachment.html From rtc_ru at mail.ru Tue Dec 18 05:40:27 2007 From: rtc_ru at mail.ru (=?windows-1251?B?wO3g8u7r6Okg0OXs7eXi?=) Date: Tue, 18 Dec 2007 19:40:27 +0600 Subject: [Live-devel] MPEG2 Stream receiving Message-ID: <567257011.20071218194027@mail.ru> Hi all! I need to receive mpeg2 stream from some address. There is a excellent sample to receive video stream and write it into a file - testMPEG1or2VideoReceiver.cpp But how I can receive audio stream too? I.e. I need to receive audio and video streams together and write them to a file. Thanks!!!! With best regards, Anatoliy From jnitin at ssdi.sharp.co.in Tue Dec 18 05:45:15 2007 From: jnitin at ssdi.sharp.co.in (Nitin Jain) Date: Tue, 18 Dec 2007 19:15:15 +0530 Subject: [Live-devel] How to get NPT of a received RTP Packet in openRTSP Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB563275@KABEX01.sharpamericas.com> Hi all, >From the LIVE mailing lists I found that :- How does one obtain the current NPT (normal playing time) of a received packet? The closests thing I can find is FramedSource::fPresentationTime, which is in UTC format... o.0 You will need to use this presentation time, but subtract from it the presentation time for the first-received RTP packet. (You can also get the latter presentation time from the "RTPInfo" header - i.e., from the field "MediaSubsession.rtpInfo.timestamp"). Hence I try to use the same logic to derive npt time in sec of latest RTP Packet i.e nptTime = (((current_presentationTime.tv_sec - FirstReceivedPacket_presentationTime.tv_sec)) + (((current_presentationTime.tv_usec - FirstReceivedPacket_presentationTime.tv_usec))/1000000)); But I am getting very big no i.e 1197953352.0000000. Do i need to convert it to some other format . I want to set the start time in playMediaSession for seeking purpose using npt time so that client should forward 2 sec from the current media timeline which i think is npt . Regards Nitin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071218/e4976f3a/attachment.html From mailinglist at mbs-technet.com Tue Dec 18 06:27:05 2007 From: mailinglist at mbs-technet.com (Maik Brauer) Date: Tue, 18 Dec 2007 15:27:05 +0100 Subject: [Live-devel] openRTSP Command Line Tool In-Reply-To: References: <3781D714-4D1E-472F-A782-F6619FB241A8@mbs-technet.com> <3F08F8BB-CCAE-408B-95CB-D109CFF2E1F3@mbs-technet.com> Message-ID: <2BEFB119-F8E0-4AFB-ABFB-DB76660E10E0@mbs-technet.com> With the Quicktime it is not working as well. You will get a Error -2002: a bad public movie atom was found in the movie. I tried to stream again with openRTSP and I have saved the stream again. After opening it with Quicktime I'll get the same error. If you are using directly the VLC or Quicktime together with the Streaming Server it is working. So the Saved stream is not OK then. What else can I do ? Is that a common behavior of openRTSP. Cheers, Maik On Dec 17, 2007, at 11:24 PM, Ross Finlayson wrote: >> I've compiled the AMR audio codes into the VLC Software. >> I'm able to play video and audio when I'm connection directly to the >> streaming source, >> for example a Darwin Streaming Server. >> But if I try it via openRTSP, where I'm opening a saved file it is >> not >> possible, >> So something must be wrong with the saved files. > > Not necessarily. Are you able to play the file in QuickTime Player > (after you change the name to have the ".amr" filename suffix)? If > so, but you're not able to play the file in VLC, then the problem is > that VLC is not properly interpreting the content of ".amr" files. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From belloni at imavis.com Tue Dec 18 06:54:18 2007 From: belloni at imavis.com (Cristiano Belloni) Date: Tue, 18 Dec 2007 15:54:18 +0100 Subject: [Live-devel] Re: Questions on streaming live H263 videos Message-ID: <4767DF1A.4060809@imavis.com> >I suggest defining a subclass of >"H263plusVideoFileServerMediaSubsession", and redefining the >"createNewStreamSource()" virtual function to start your encoder(sic) >thread, and then call the parent class >("H263plusVideoFileServerMediaSubsession")'s >"createNewStreamSource()" Uhm, I'm having an hard time subclassing "H263plusVideoFileServerMediaSubsession". I just added this code: class EncH263plusVideoFileServerMediaSubsession: public H263plusVideoFileServerMediaSubsession { private: FramedSource* createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate); }; FramedSource* EncH263plusVideoFileServerMediaSubsession::createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate) { std::cout << "Started a new Stream Source" << std::endl; /* Code to start the encoder thread */ return H263plusVideoFileServerMediaSubsession::createNewStreamSource(clientSessionId, estBitrate); } And i get these errors: ~/develop/lib/live-debug/liveMedia/include/H263plusVideoFileServerMediaSubsession.hh: In member function ?virtual FramedSource* EncH263plusVideoFileServerMediaSubsession::createNewStreamSource(unsigned int, unsigned int&)?: ~/develop/lib/live-debug/liveMedia/include/H263plusVideoFileServerMediaSubsession.hh:42: error: ?virtual FramedSource* H263plusVideoFileServerMediaSubsession::createNewStreamSource(unsigned int, unsigned int&)? is private rtspServer.cpp:56: error: within this context ~/develop/lib/live-debug/liveMedia/include/H263plusVideoFileServerMediaSubsession.hh: In destructor ?virtual EncH263plusVideoFileServerMediaSubsession::~EncH263plusVideoFileServerMediaSubsession()?: ~/develop/lib/live-debug/liveMedia/include/H263plusVideoFileServerMediaSubsession.hh:38: error: ?H263plusVideoFileServerMediaSubsession::~H263plusVideoFileServerMediaSubsession()? is private rtspServer.cpp:44: error: within this context rtspServer.cpp: At global scope: rtspServer.cpp:114: note: synthesized method ?virtual EncH263plusVideoFileServerMediaSubsession::~EncH263plusVideoFileServerMediaSubsession()? first required here Complaining that the destructor of H263plusVideoFileServerMediaSubsession is private (and indeed it is). If I try to override the destructor in my class, I get similar errors. Where am I doing wrong? Can you point me to some sample code where it is done right? Thanks, Regards, Cristiano Belloni. From belloni at imavis.com Tue Dec 18 08:57:06 2007 From: belloni at imavis.com (Cristiano Belloni) Date: Tue, 18 Dec 2007 17:57:06 +0100 Subject: [Live-devel] Questions on streaming live H263 videos In-Reply-To: <4767DF1A.4060809@imavis.com> References: <4767DF1A.4060809@imavis.com> Message-ID: <4767FBE2.1070407@imavis.com> Well, i solved the problem creating another class, modeled after "H263plusVideoFileServerMediaSubsession", which starts my thread. I don't know if it's the right solution, but I couldn't find another. By the way, why createNewStreamSource() is called twice per requested stream? Now I'm testing if thread is already started, because starting it in createNewStreamSource would have it started twice. Am I doing the right thing? Regards, Cristiano Belloni. Cristiano Belloni wrote: >> I suggest defining a subclass of >> "H263plusVideoFileServerMediaSubsession", and redefining the >> "createNewStreamSource()" virtual function to start your encoder(sic) >> thread, and then call the parent class >> ("H263plusVideoFileServerMediaSubsession")'s >> "createNewStreamSource()" >> > > Uhm, I'm having an hard time subclassing "H263plusVideoFileServerMediaSubsession". > I just added this code: > > class EncH263plusVideoFileServerMediaSubsession: public H263plusVideoFileServerMediaSubsession > { > > private: > > FramedSource* createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate); > > }; > > FramedSource* EncH263plusVideoFileServerMediaSubsession::createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate) > { > std::cout << "Started a new Stream Source" << std::endl; > > /* Code to start the encoder thread */ > > return H263plusVideoFileServerMediaSubsession::createNewStreamSource(clientSessionId, estBitrate); > } > > And i get these errors: > > ~/develop/lib/live-debug/liveMedia/include/H263plusVideoFileServerMediaSubsession.hh: In member function ?virtual FramedSource* EncH263plusVideoFileServerMediaSubsession::createNewStreamSource(unsigned int, unsigned int&)?: > ~/develop/lib/live-debug/liveMedia/include/H263plusVideoFileServerMediaSubsession.hh:42: error: ?virtual FramedSource* H263plusVideoFileServerMediaSubsession::createNewStreamSource(unsigned int, unsigned int&)? is private > rtspServer.cpp:56: error: within this context > ~/develop/lib/live-debug/liveMedia/include/H263plusVideoFileServerMediaSubsession.hh: In destructor ?virtual EncH263plusVideoFileServerMediaSubsession::~EncH263plusVideoFileServerMediaSubsession()?: > ~/develop/lib/live-debug/liveMedia/include/H263plusVideoFileServerMediaSubsession.hh:38: error: ?H263plusVideoFileServerMediaSubsession::~H263plusVideoFileServerMediaSubsession()? is private > rtspServer.cpp:44: error: within this context > rtspServer.cpp: At global scope: > rtspServer.cpp:114: note: synthesized method ?virtual EncH263plusVideoFileServerMediaSubsession::~EncH263plusVideoFileServerMediaSubsession()? first required here > > > Complaining that the destructor of H263plusVideoFileServerMediaSubsession is private (and indeed it is). > If I try to override the destructor in my class, I get similar errors. > > Where am I doing wrong? Can you point me to some sample code where it is done right? > > Thanks, > > Regards, > > Cristiano Belloni. > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > From xcsmith at rockwellcollins.com Tue Dec 18 09:21:07 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Tue, 18 Dec 2007 11:21:07 -0600 Subject: [Live-devel] Ok to daemonize live555MediaServer? Message-ID: Is it OK to daemonize the live555MediaServer? I do not really know about daemonize, but my team is trying to do this and they are having trouble. So I wonder if there are known reasons why this could not be done? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071218/eb7ab057/attachment.html From finlayson at live555.com Tue Dec 18 13:51:16 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Dec 2007 13:51:16 -0800 Subject: [Live-devel] Ok to daemonize live555MediaServer? In-Reply-To: References: Message-ID: >Is it OK to daemonize the live555MediaServer? I do not really know >about daemonize, but my team is trying to do this and they are >having trouble. So I wonder if there are known reasons why this >could not be done? None that I know of. (But be sure to specify the proper working directory.) -- 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/20071218/743a6e85/attachment.html From finlayson at live555.com Tue Dec 18 13:53:21 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Dec 2007 13:53:21 -0800 Subject: [Live-devel] openRTSP Command Line Tool In-Reply-To: <2BEFB119-F8E0-4AFB-ABFB-DB76660E10E0@mbs-technet.com> References: <3781D714-4D1E-472F-A782-F6619FB241A8@mbs-technet.com> <3F08F8BB-CCAE-408B-95CB-D109CFF2E1F3@mbs-technet.com> <2BEFB119-F8E0-4AFB-ABFB-DB76660E10E0@mbs-technet.com> Message-ID: >With the Quicktime it is not working as well. >You will get a Error -2002: a bad public movie atom was found in the >movie. > >I tried to stream again with openRTSP and I have saved the stream again. >After opening it with Quicktime I'll get the same error. That's odd. Are you sure you're renaming the file so that it has a ".amr" filename suffix (*not* ".mov" or ".mp4")? Playing received AMR files with QuickTime Player (after renaming them to have a ".amr" suffix) should work. I've done it several times. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From chang.yiwen at tw.panasonic.com Tue Dec 18 18:22:37 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Wed, 19 Dec 2007 10:22:37 +0800 Subject: [Live-devel] RTSP of H264 Message-ID: <005501c841e6$0a8793c0$59085a0a@userd7c6bde7c0> >If we connect to mpeg1or2 rtsp server (testMPEG1or2VideoStreamer.cpp) via MPlayer? >MPlayer still can't decode successfully because of data loss. We found that, in testMPEG1or2VideoStreamer.cpp, a video is sent repeatedlym so Mplayer will not lost data. But, if sent a video just one time, data loss occur in Mplayer. So, for our h264 rtsp server, we solved the problem by repeating to send the first frame for 5 or 6 times and then continue sending the successive frames. And, now mplayer can play streaming normally. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071218/535aff60/attachment.html From sapanaj at aftek.com Wed Dec 19 01:14:32 2007 From: sapanaj at aftek.com (Sapana Jogwadikar) Date: 19 Dec 2007 14:44:32 +0530 Subject: [Live-devel] How to generate Program stream? Message-ID: <1198055672.5197.63.camel@sapanaj> Hi, Is it possible to generate a program stream by providing MPEG-2 video and MPEG-2 audio as input to live555? If yes, does live555 have any sample application to demonstrate this? If no, does live555 provide any classes to implement this? Thanks and Regards, Sapana Jogwadikar From finlayson at live555.com Wed Dec 19 01:55:52 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Dec 2007 01:55:52 -0800 Subject: [Live-devel] How to generate Program stream? In-Reply-To: <1198055672.5197.63.camel@sapanaj> References: <1198055672.5197.63.camel@sapanaj> Message-ID: >Is it possible to generate a program stream by providing MPEG-2 video >and MPEG-2 audio as input to live555? Sorry, no - we don't have a multipexor for MPEG Program Streams (only a demultiplexor). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From hchen54321 at hotmail.com Fri Dec 21 10:36:14 2007 From: hchen54321 at hotmail.com (h chen) Date: Fri, 21 Dec 2007 18:36:14 +0000 Subject: [Live-devel] How to Get MPlayer to Support RTSP Pause Message-ID: Hi, I am very new in video streaming and RTSP protocol. From RFC2326, it described the PAUSE command will pause the stream on the server side. So there will be not packet streaming across the network after pausing. I had set up live555MediaPlayer to play a RTSP url stream and mplayer as a client to play the stream. On the mplayer, I am running the '-V' option to show the RTSP status under slave mode. When I pause, I didn't see the RTSP 'Pause' command and still see the packets coming over from the server to the client machine (in ethereal). How do I set up mplayer to support the 'pause' and other RTSP commands? I did see the RTSP 'setup', 'play', and 'teardown' statuses. Thanks, _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071221/6d0a28fd/attachment.html From finlayson at live555.com Fri Dec 21 16:09:31 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 21 Dec 2007 16:09:31 -0800 Subject: [Live-devel] How to Get MPlayer to Support RTSP Pause In-Reply-To: References: Message-ID: >How do I set up mplayer to support the 'pause' and other RTSP commands? That is a question for a MPlayer mailing list. Note, however, that our API does support the RTSP "PAUSE" operation, using the "RTSPClient::pauseMediaSession()" or "RTSPClient::pauseMediaSubsession()" functions. Alternatively, you could use the VLC media player , which also uses our libraries, and *does* implement RTSP "PAUSE". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From prabhakar_raju at hotmail.com Mon Dec 24 16:34:26 2007 From: prabhakar_raju at hotmail.com (Prabhakar Raju) Date: Mon, 24 Dec 2007 19:34:26 -0500 Subject: [Live-devel] a question on class name... Message-ID: Hi, I'm running a simple server for streaming mp3(the 555 server). The calls seems to go through a class named MultiFramedRTPSink. why have you named it as sink? Why not source? It reads a file and streams out the data. right? regards _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071224/66555e81/attachment.html From finlayson at live555.com Mon Dec 24 19:57:36 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Dec 2007 19:57:36 -0800 Subject: [Live-devel] a question on class name... In-Reply-To: References: Message-ID: >I'm running a simple server for streaming mp3(the 555 server). The >calls seems to go through a class named MultiFramedRTPSink. why have >you named it as sink? It's a 'sink' because it reads data from another (upstream) object, but does not pass any data to another (downstream) object. See http://www.live555.com/liveMedia/faq.html#control-flow -- Ross Finlayson Live Networks, Inc. http://www.live555.com/