From jnitin at ssdi.sharp.co.in Mon Oct 1 06:34:40 2007 From: jnitin at ssdi.sharp.co.in (Nitin Jain) Date: Mon, 1 Oct 2007 19:04:40 +0530 Subject: [Live-devel] Packet loss in case of high bitrate mpeg4 elementry streams Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB56323C@KABEX01.sharpamericas.com> Hi all, We are using Live555 media server and openRTSP client to stream and receive mpeg4 elementry stream.We observerd that when we stream high bitrate MPEG4 ES stream (3 or 6 or 15 Mbps )there is a huge packet loss(almost 20% ) .From wireshark trace on server side we found out that server is dropping rtp packets. However when we re-encode the same streams to low bitrate ( 1 Mbps) then there is no or very small packet loss. We also tested high bit rate streams on private network with no cross traffic but there also high packet loss is observed. We also change the OUTPACK_BUFFERSIZE to some high value. Please provide your feedback why it's happening or do we need to change some settings. Thanks and Regards Nitin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071001/af511704/attachment.html From ruru605 at 163.com Mon Oct 1 17:41:49 2007 From: ruru605 at 163.com (ruru605) Date: Tue, 2 Oct 2007 09:41:49 +0900 Subject: [Live-devel] how to add congestion control into live555 ? Message-ID: <200710020941490313105@163.com> Dear Ross, Thanks very much for helping me. I still have got a question to ask you as follows: Recently I am reading some papers about congestion control on RTP. I want to test those algorithms, however, the bitrate of source of live555 is fixed. I wonder how can I test congestion control by using live555, please give me some advices. I appreciate it very much. I think i have to add a real-time transcoder into live555, but it seems difficult. Best Regards Ru ruru605 2007-10-02 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071001/0cab69d7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: ? ?.vcf Type: text/x-vcard Size: 204 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20071001/0cab69d7/attachment-0001.vcf From finlayson at live555.com Mon Oct 1 20:51:05 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 1 Oct 2007 20:51:05 -0700 Subject: [Live-devel] how to add congestion control into live555 ? In-Reply-To: <200710020941490313105@163.com> References: <200710020941490313105@163.com> Message-ID: >however, the bitrate of source of live555 is fixed. That's not true at all. The bitrate of a "RTPSink" (subclass) is completely determined by what you feed into it - i.e., the size of the data frames that you feed into it, and the duration ("fDurationInMicroseconds") of each. These are determined by the upstream source, and therefore can change. -- 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/20071001/fb3f633c/attachment.html From finlayson at live555.com Mon Oct 1 21:15:05 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 1 Oct 2007 21:15:05 -0700 Subject: [Live-devel] Packet loss in case of high bitrate mpeg4 elementry streams In-Reply-To: <9219A756FBA09B4D8CE75D4D7987D6CB56323C@KABEX01.sharpamericas.com> References: <9219A756FBA09B4D8CE75D4D7987D6CB56323C@KABEX01.sharpamericas.com> Message-ID: >.From wireshark trace on server side we found out that server is >dropping rtp packets. Do you really mean to say that the *server* is dropping packets? I.e., are you seeing packet loss in the over-the-network packets traces? If so, then I don't know what might be causing this, and unfortunately I can't help you. (If however, you meant to say that the *client* is dropping packets, then you can get help by reading ) -- 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/20071001/78a7cdb6/attachment.html From noamatari at yahoo.com Tue Oct 2 17:10:25 2007 From: noamatari at yahoo.com (Noam Camiel) Date: Tue, 2 Oct 2007 17:10:25 -0700 (PDT) Subject: [Live-devel] RTP-over-TCP streaming Message-ID: <76628.29785.qm@web53302.mail.re2.yahoo.com> Hello I have a problem when accessing live server's stream using RTP-over-TCP as opposed to UDP. I have used the testOnDemandRTSPServer example to play a stream of of mpeg4 encodered frames (elementary stream) and was successful with both VLC and Quicktime as well as RealPlayer, using unicast UDP. But when I try to connect to the server via TCP (RTP over TCP), the video is played for a short time and then stops (with a reports - due to a network problem). This short time duration can be anywhere between 30 seconds and 10 minutes. Which is the right way to stream RTP over TCP? Should I use a different example from live than testOnDemandRTSPServer? Thanks, Noam Camiel ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ From finlayson at live555.com Tue Oct 2 17:20:26 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Oct 2007 17:20:26 -0700 Subject: [Live-devel] RTP-over-TCP streaming In-Reply-To: <76628.29785.qm@web53302.mail.re2.yahoo.com> References: <76628.29785.qm@web53302.mail.re2.yahoo.com> Message-ID: >I have a problem when accessing live server's stream using >RTP-over-TCP as opposed to UDP. > >I have used the testOnDemandRTSPServer example to play a stream of >of mpeg4 encodered frames (elementary stream) and was successful >with both VLC and Quicktime as well as RealPlayer, using unicast UDP. > >But when I try to connect to the server via TCP (RTP over TCP), the >video is played for a short time and then stops (with a reports - >due to a network problem). This short time duration can be anywhere >between 30 seconds and 10 minutes. > >Which is the right way to stream RTP over TCP? Should I use a >different example from live than testOnDemandRTSPServer? No, using "testOnDemandRTSPServer" should be sufficient. Our RTSP server implementation automatically supports RTP-over-TCP (for unicast streams), it requested. I don't know of any issue with the code that could be causing your problem. When you stream RTP-over-TCP, are you doing so using the same network as RTP-over-UDP? If not, then perhaps there's something (e.g., a firewall) in the middle of your RTP-over-TCP network that's causing your problems? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From noamatari at yahoo.com Wed Oct 3 00:34:12 2007 From: noamatari at yahoo.com (Noam Camiel) Date: Wed, 3 Oct 2007 00:34:12 -0700 (PDT) Subject: [Live-devel] RTP-over-TCP streaming Message-ID: <117246.23430.qm@web53301.mail.re2.yahoo.com> > I don't know of any issue with the code that could be causing your > problem. When you stream RTP-over-TCP, are you doing so using the > same network as RTP-over-UDP? If not, then perhaps there's something > (e.g., a firewall) in the middle of your RTP-over-TCP network that's > causing your problems? Yes, I'm using the same network for RTP-over-UDP and RTP-over-TCP, no firewall and on the same subnet. I will try using a sniffer and follow the communication TCP vs UDP. Should I look for specific packets in RTP-over-TCP that are some sort of keep-alive? Thanks Noam Camiel ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting From finlayson at live555.com Wed Oct 3 01:39:08 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Oct 2007 01:39:08 -0700 Subject: [Live-devel] RTP-over-TCP streaming In-Reply-To: <117246.23430.qm@web53301.mail.re2.yahoo.com> References: <117246.23430.qm@web53301.mail.re2.yahoo.com> Message-ID: >Should I look for specific packets in RTP-over-TCP that are some >sort of keep-alive? Yes, the client (should) send periodic RTCP "RR" packets - for both RTP/UDP and RTP/TCP. VLC and QuickTime Player should send these; for RealPlayer, I can't say for sure. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From alvin.cheung at TeleEye.com Wed Oct 3 02:27:34 2007 From: alvin.cheung at TeleEye.com (Alvin Cheung) Date: Wed, 3 Oct 2007 17:27:34 +0800 Subject: [Live-devel] Dynamic MPEG4 resolution streaming Message-ID: <000801c8059f$a27c6760$1c8b11d2@AlvinPC> Hello All, I'm ultilizing live555 to implement a streaming server for streaming MPEG4 ES video from a MPEG4 hardware encoder. Video is successfully send through RTP protocol started by RTSP (with SDP). I would like to ask if there is any way I can dynamically change the video resolution from the server side and announce to all live clients without starting a new session from beginning? The purpose of this is that the server is required to adaptively change the streaming video's resolution depends on the current network condition. Having done little research on RTSP that the "ANNOUNCE " command from server to client seems to be the right tools for this purpose. However, many server and client software, including Live555 server and VLC player, don't have this support. Can you provide any suggestions on how to implement this? Thank you! Alvin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071003/71436113/attachment.html From finlayson at live555.com Wed Oct 3 02:36:54 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Oct 2007 02:36:54 -0700 Subject: [Live-devel] Dynamic MPEG4 resolution streaming In-Reply-To: <000801c8059f$a27c6760$1c8b11d2@AlvinPC> References: <000801c8059f$a27c6760$1c8b11d2@AlvinPC> Message-ID: >I'm ultilizing live555 to implement a streaming server for streaming >MPEG4 ES video from a MPEG4 hardware encoder. Video is successfully >send through RTP protocol started by RTSP (with SDP). I would like >to ask if there is any way I can dynamically change the video >resolution from the server side and announce to all live clients >without starting a new session from beginning? Why note just change the resolution (at the server end), and keep streaming, as usual? Is there not enough information in-band (in the MPEG-4 video stream) for clients to detect this, and handle it 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/20071003/25adabee/attachment.html From shaswata at alumnux.com Wed Oct 3 04:27:27 2007 From: shaswata at alumnux.com (Shaswata Jash) Date: Wed, 3 Oct 2007 16:57:27 +0530 Subject: [Live-devel] Dynamic MPEG4 resolution streaming In-Reply-To: References: <000801c8059f$a27c6760$1c8b11d2@AlvinPC> Message-ID: <013a01c805b0$621f71b0$2e0aa8c0@alumnusshas> Instead of keeping the config data in the SDP (in that case, client may utilize those out of band data to pre-allocate buffers for its decoder), you may keep that data as part of RTP packets. However, if the client is implemented such a way that it does not refresh necessary information (e.g. size of buffers according to changed resolution) in accordance with the successive changes in the resolution, in-band config data will not help in anyway. There can be another hack (essentially for those clients, which do not refresh their internal data structures during change in resolution) - let the server start streaming with certain resolution. If the network condition drops off, the encoder in the server tries to reduce the effective resolution. By the term effective resolution, I mean, server maintains the original resolution but the effective viewing square is diminished and the rest of the original square is blackened. Certainly, the blackened area will take significantly less amount to pack its information in the MPEG4 video bit stream and your purpose will still be solved. Again, once the network condition is improved, you may increase the effective resolution. One problem in this hack will be - you cannot increase the resolution beyond your initial one (i.e. coming through the 'config'). With regards Shaswata _____ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, October 03, 2007 3:07 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Dynamic MPEG4 resolution streaming I'm ultilizing live555 to implement a streaming server for streaming MPEG4 ES video from a MPEG4 hardware encoder. Video is successfully send through RTP protocol started by RTSP (with SDP). I would like to ask if there is any way I can dynamically change the video resolution from the server side and announce to all live clients without starting a new session from beginning? Why note just change the resolution (at the server end), and keep streaming, as usual? Is there not enough information in-band (in the MPEG-4 video stream) for clients to detect this, and handle it 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/20071003/1a3905c3/attachment-0001.html From Ambra.Cristaldi at elsagdatamat.com Wed Oct 3 07:29:46 2007 From: Ambra.Cristaldi at elsagdatamat.com (Cristaldi Ambra) Date: Wed, 3 Oct 2007 16:29:46 +0200 Subject: [Live-devel] speed settings for mpeg4 Message-ID: <268315E5844A704AB431589863FE8EEFCED085@els00wmx04.elsag.it> Dear Ross, I have some questions for you about streaming of m4e files from a server at different speed: - does the "onDemandRTSPServer" already implement this functionality for m4e? We just wish to stream the test file (test.m4e) at speed x2 (or more...) - I read the FAQ and found that we can change the parameter "scale" in the function "playMediaSession()" of OpenRTSP.cpp to set the speed. Is it possible doing something similar for streaming? Thank you in advance. Best regards, Ambra -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071003/8eaae4c8/attachment.html From rmcouat at smartt.com Wed Oct 3 07:44:16 2007 From: rmcouat at smartt.com (Ron McOuat) Date: Wed, 03 Oct 2007 07:44:16 -0700 Subject: [Live-devel] RTP-over-TCP streaming (Noam Camiel) In-Reply-To: References: Message-ID: <4703AAC0.1080802@smartt.com> I have observed a similar sounding situation as follows: Use openRTSP to receive the video stream from an Axis camera, I have tried several models Using RTP over UDP (no -t or -T option) will run for hours Using RTP over TCP (-t option) will fail somewhere between 600 and 2000 seconds Using HTTP tunneling (-T 80 option) will run for hours Compiling the live555 code with debug on reveals the end sequence looks like this: ~~~~~~~~~~~~~~~ Debug trace ~~~~~~~~~~~~~~~ sendRTPOverTCP: 976 bytes over channel 0 (socket 8) sendRTPOverTCP: completed SocketDescriptor::tcpReadHandler() reading 16 bytes on channel 20 SocketDescriptor::tcpReadHandler() reading 16 bytes on channel 21 [0x300be0]saw incoming RTCP packet (from address 136.244.255.191, port 1280) 80c90001 6fc0e531 81cb0001 6fc0e531 RR validated RTCP subpacket (type 2): 0, 201, 0, 0x6fc0e531 BYE Received RTCP "BYE" on "video/MP4V-ES" subsession (after 672 seconds) Sending request: TEARDOWN rtsp://69.67.172.61:554/mpeg4/1/media.amp/ RTSP/1.0 CSeq: 8 Session: 2014422318 User-Agent: ./testProgs/openRTSP (LIVE555 Streaming Media v2007.08.03) RTCPInstance[0x300be0]::~RTCPInstance() sending BYE sending RTCP packet 81c90007 af22ce4c 6fc0e531 00000000 00023418 00000388 bfcf8f2c 000127e1 81cb0001 af22ce4c sendRTPOverTCP: 40 bytes over channel 21 (socket 3) sendRTPOverTCP: completed ~~~~~~~~~~~~ End of trace ~~~~~~~~~~~~~~~~ What appears to happen that is different when the stream ends is the 2 lines from SocketDescriptor::tcpReadHandler() gets a 16 byte read on channel 20 then another 16 bytes on channel 21. Often there is a REPORT just before this but not always. The end of stream does not go through any timeouts, the debug output just rolls up and stops when I have observed this in real time. Also the address and port numbers reported for the source for both -t and -T port reported in the trace are not valid but with UDP they are good. The correct source IP address is in the TEARDOWN message. I have not had a chance to dig into why this is happening yet because I have some other pressing issues to work on and have worked around this for my own purposes. However, seeing this on the mailing list prompted me to send in my observations. The system running the live555 code is OSX 10.4.10 with all patches. I was also going to verify on Linux in case this is a problem with the system interface to select(). Ron McOuat Message: 3 Date: Tue, 2 Oct 2007 17:10:25 -0700 (PDT) From: Noam Camiel Subject: [Live-devel] RTP-over-TCP streaming To: LIVE555 Streaming Media - development & use Message-ID: <76628.29785.qm at web53302.mail.re2.yahoo.com> Content-Type: text/plain; charset=us-ascii Hello I have a problem when accessing live server's stream using RTP-over-TCP as opposed to UDP. I have used the testOnDemandRTSPServer example to play a stream of of mpeg4 encodered frames (elementary stream) and was successful with both VLC and Quicktime as well as RealPlayer, using unicast UDP. But when I try to connect to the server via TCP (RTP over TCP), the video is played for a short time and then stops (with a reports - due to a network problem). This short time duration can be anywhere between 30 seconds and 10 minutes. Which is the right way to stream RTP over TCP? Should I use a different example from live than testOnDemandRTSPServer? Thanks, Noam Camiel From finlayson at live555.com Wed Oct 3 08:10:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Oct 2007 08:10:20 -0700 Subject: [Live-devel] RTP-over-TCP streaming (Noam Camiel) In-Reply-To: <4703AAC0.1080802@smartt.com> References: <4703AAC0.1080802@smartt.com> Message-ID: >Received RTCP "BYE" on "video/MP4V-ES" subsession (after 672 seconds) The RTCP "BYE" packet (from the server) is your server is explicitly saying "I'm ending the streaming of the stream now". The client then (correctly) handles this by shutting down. So, you will need to figure out why your server has chosen to end the stream. (You may need to ask Axis about this.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Oct 3 08:15:28 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Oct 2007 08:15:28 -0700 Subject: [Live-devel] speed settings for mpeg4 In-Reply-To: <268315E5844A704AB431589863FE8EEFCED085@els00wmx04.elsag.it> References: <268315E5844A704AB431589863FE8EEFCED085@els00wmx04.elsag.it> Message-ID: >I have some questions for you about streaming of m4e files from a >server at different speed: >- does the "onDemandRTSPServer" already implement this >functionality for m4e? No, our RTSP server implementation currently does not implement 'trick play' operations when streaming MPEG-4 Elementary Stream video files. See http://www.live555.com/liveMedia/faq.html#trick-mode and http://www.live555.com/mediaServer/#trick-play -- 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/20071003/44de5163/attachment.html From shaswata at alumnux.com Thu Oct 4 00:09:59 2007 From: shaswata at alumnux.com (Shaswata Jash) Date: Thu, 4 Oct 2007 12:39:59 +0530 Subject: [Live-devel] RTP-over-TCP streaming (Noam Camiel) In-Reply-To: References: <4703AAC0.1080802@smartt.com> Message-ID: <016201c80655$94b16660$2e0aa8c0@alumnusshas> >From our previous experience on working with Axis camera, it does not really support RTP interleaved packets over TCP (i.e. the specification you can find under rfc of RTSP). However, it supports RTSP tunneled over HTTP - this specification is proprietary and defined by Apple. On the configuration web-page of your Axis camera, you can verify about this. To best of my knowledge, Live555 does not yet support that RTSP tunneled over HTTP - probably Ross would be the best person to comment about this. With regards, Shaswata -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, October 03, 2007 8:40 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel) >Received RTCP "BYE" on "video/MP4V-ES" subsession (after 672 seconds) The RTCP "BYE" packet (from the server) is your server is explicitly saying "I'm ending the streaming of the stream now". The client then (correctly) handles this by shutting down. So, you will need to figure out why your server has chosen to end the stream. (You may need to ask Axis about this.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Thu Oct 4 00:21:06 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Oct 2007 00:21:06 -0700 Subject: [Live-devel] RTP-over-TCP streaming (Noam Camiel) In-Reply-To: <016201c80655$94b16660$2e0aa8c0@alumnusshas> References: <4703AAC0.108080 2@smartt.com> <016201c80655$94b16660$2e0aa8c0@alumnusshas> Message-ID: >To best of my knowledge, Live555 does not yet support that RTSP tunneled >over HTTP Yes it does - in our *client* implementation. Note, for example, the "-T " option to "openRTSP": Our RTSP *server* implementation, however, does not yet support RTSP-over-HTTP tunneling (but may, sometime in the future). -- 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/20071004/7e83256d/attachment.html From cshumway at airvisual.com Thu Oct 4 07:55:48 2007 From: cshumway at airvisual.com (Christopher Shumway) Date: Thu, 4 Oct 2007 10:55:48 -0400 Subject: [Live-devel] testMPEG4VideoStreamer - Debug Assertion Failed! Message-ID: <9A46651B1CC1FF4DB6275ACD19773C6A28B23D@airvisual1.airvisual.net> Greetings, I am working with VS 2005 on Windows XP and I can the testMPEG4VideoStreamer program to compile. However, when I run it from a command line I receive an error message (in the form of a pop-up) which reads, "Debug Assertion Failed!". In debugging the code, I believe I am having difficulty "joining a socket group". I can debug the code to the following point, at which time it drops into the "failed to join group" error. Groupsock::Groupsock(UsageEnvironment& env, struct in_addr const& groupAddr, Port port, u_int8_t ttl) : OutputSocket(env, port), deleteIfNoMembers(False), isSlave(False), fIncomingGroupEId(groupAddr, port.num(), ttl), fDests(NULL), fTTL(ttl) { addDestination(groupAddr, port); if (!socketJoinGroup(env, socketNum(), groupAddr.s_addr)) { if (DebugLevel >= 1) { env << *this << ": failed to join group: " << env.getResultMsg() << "\n"; } } BTW - I do have this compiled (along with the 555 Live Media Server) and working fine on a Linux (Red Hat) box. I can access the test stream using VLC on my Windows PC which is on the same network as the Linux box. Thanx! Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071004/fca4fb53/attachment-0001.html From kan at pisem.net Thu Oct 4 14:36:12 2007 From: kan at pisem.net (Karlov Andrey) Date: Fri, 05 Oct 2007 01:36:12 +0400 Subject: [Live-devel] reading from MPEG encoder Message-ID: <47055CCC.2030505@pisem.net> Hello Ross! In have read (in FAQ) about streaming live video from MPEG encoder (represents as a file in file system). It work fine for about several hours, but then encoder fails and notifies what it's buffer overflow because programm read from buffer not so fast (not enough fast). I have tried to read from encoder without MPEG2TransportStreamFramer, it works without decoder error, but too many TS packets sends to the network for once, VLC can't handle it show artifacts sometimes. How can I correctly change durationInMicroseconds to read from encoder bit faster, but not so fast to cause block live555 program while waiting readed bytes? Can you help me to solve this problem? I'm very thankfull to your help! Sorry for awful English =) Karlov Andrey. From finlayson at live555.com Thu Oct 4 16:14:51 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Oct 2007 16:14:51 -0700 Subject: [Live-devel] reading from MPEG encoder In-Reply-To: <47055CCC.2030505@pisem.net> References: <47055CCC.2030505@pisem.net> Message-ID: >I have tried to read from encoder without MPEG2TransportStreamFramer, it >works without decoder error, but too many TS packets sends to the >network for once, VLC can't handle it show artifacts sometimes. To overcome this, you need to accumulate 7 Transport Stream packets at a time (i.e., 7*188 bytes == 1316 bytes at a time), before passing the data to the "RTPSink". This will generate much larger packets, but not so large as to cause IP-level fragmentation. Because you're reading from a live source - and not a file - you don't need to set "fDurationInMicroseconds", because - even without it - you won't deliver be delivering the data faster than its natural rate. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From weirdfox at gmail.com Thu Oct 4 17:13:11 2007 From: weirdfox at gmail.com (M-A Loyer) Date: Thu, 04 Oct 2007 20:13:11 -0400 Subject: [Live-devel] Socket handling problem with live555 Message-ID: <200710042013.11680.weirdfox@gmail.com> Hi everyone, We are currently working on a voluntary-based university project which use a real time video streaming inside a ?vision server?. We use this software inside an AUV (Autonomous Underwater Vehicle, http://sonia.etsmtl.ca/en ) to send a video stream from the submarine's cameras or from the processed image (detection of objects in the image) to a remote client. We choose live555 for our streaming needs because the library is stable and well-maintained. But, we currently have a problem with socket hang inside LiveStreamer. The streaming works fine for a while, then it hang. Usually it happens either when creating a new stream or when we let it run for a while. We searched for a while and could not solve the problem or make a workaround as our knowledge of the library is still limited. So I thought someone here could help us. We use live version 2007-08-03a. I included a stack trace: #0 0xb7f68410 in __kernel_vsyscall () #1 0xb77e8521 in ?? () from /lib/libc.so.6 #2 0x080fdefe in readSocket (env=@0x8434df0, socket=21, buffer=0x896afb8 "PLAY rtsp://192.168.1.100:8554/PipeDetectorChainHSI_Gaussian_Probe RTSP/1.0\r\nCSeq: 3\r\nRange: npt=0.000000-\r\nx-prebuffer: maxtime=2.000000\r\nSession: 5\r\nUser-Agent: QTS (qtver=6.5.1;os=Windows NT 5.1Ser"..., bufferSize=10000, fromAddress=@0xb171f18c, timeout=0x0) at GroupsockHelper.cpp:229 #3 0x080dfbdf in RTSPServer::RTSPClientSession::incomingRequestHandler1 (this=0x896af90) at RTSPServer.cpp:315 #4 0x080dff5d in RTSPServer::RTSPClientSession::incomingRequestHandler (instance=0x896af90) at RTSPServer.cpp:304 #5 0x081031bd in BasicTaskScheduler::SingleStep (this=0x8434d38, maxDelayTime=0) at BasicTaskScheduler.cpp:119 #6 0x08102767 in BasicTaskScheduler0::doEventLoop (this=0x8434d38, watchVariable=0x0) at BasicTaskScheduler0.cpp:76 #7 0x080539dc in LiveStreamer::run (this=0xb4103430) at src/streaming/LiveStreamer.cpp:29 #8 0xb7db0b29 in ccxx_exec_handler () from /usr/lib/libccgnu2-1.5.so.0 #9 0xb7f36162 in start_thread () from /lib/libpthread.so.0 #10 0xb77eefee in clone () from /lib/libc.so.6 Here's the place where the streaming server hang: 224 FD_ZERO(&rd_set); 225 if (socket < 0) break; 226 FD_SET((unsigned) socket, &rd_set); 227 const unsigned numFds = socket+1; 228 *229 result = select(numFds, &rd_set, NULL, NULL, timeout); 230 if (timeout != NULL && result == 0) { 231 break; // this is OK - timeout occurred 232 } else if (result <= 0) { 233 #if defined(__WIN32__) || defined(_WIN32) Any help, pointers on a solution or idea are welcome ! Thanks for your help, Marc-Andr? & Pierre-Luc Loyer SONIA AUV, Vision Server team weirdfox at gmail.com, ployer at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071004/61c52a2e/attachment.html From uozef at opensoftAustralia.com.au Fri Oct 5 10:29:08 2007 From: uozef at opensoftAustralia.com.au (Yousef Hosseini) Date: Fri, 5 Oct 2007 10:29:08 -0700 Subject: [Live-devel] live-devel Digest, Vol 48, Issue 3 In-Reply-To: References: Message-ID: <000c01c80775$3cc85870$b6590950$@com.au> Hi guys, I am using Live555 with Amino 110 , I couldn't work it out how can I get rid of trick play problem and just wonder if anybody has any resolution for this, problem is when I press FF on remote , then pause then play it takes few seconds running in slow mode and then come back again into the normal mode. I already changed the RTSP_SCALE in amino settings file, nothing has happened. Regards, Yousef. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of live-devel-request at ns.live555.com Sent: Thursday, October 04, 2007 7:59 AM To: live-devel at ns.live555.com Subject: live-devel Digest, Vol 48, Issue 3 Send live-devel mailing list submissions to live-devel at lists.live555.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.live555.com/mailman/listinfo/live-devel or, via email, send a message with subject or body 'help' to live-devel-request at lists.live555.com You can reach the person managing the list at live-devel-owner at lists.live555.com When replying, please edit your Subject line so it is more specific than "Re: Contents of live-devel digest..." Today's Topics: 1. speed settings for mpeg4 (Cristaldi Ambra) 2. Re: RTP-over-TCP streaming (Noam Camiel) (Ron McOuat) 3. Re: RTP-over-TCP streaming (Noam Camiel) (Ross Finlayson) 4. Re: speed settings for mpeg4 (Ross Finlayson) 5. Re: RTP-over-TCP streaming (Noam Camiel) (Shaswata Jash) 6. Re: RTP-over-TCP streaming (Noam Camiel) (Ross Finlayson) 7. testMPEG4VideoStreamer - Debug Assertion Failed! (Christopher Shumway) ---------------------------------------------------------------------- Message: 1 Date: Wed, 3 Oct 2007 16:29:46 +0200 From: "Cristaldi Ambra" Subject: [Live-devel] speed settings for mpeg4 To: Message-ID: <268315E5844A704AB431589863FE8EEFCED085 at els00wmx04.elsag.it> Content-Type: text/plain; charset="us-ascii" Dear Ross, I have some questions for you about streaming of m4e files from a server at different speed: - does the "onDemandRTSPServer" already implement this functionality for m4e? We just wish to stream the test file (test.m4e) at speed x2 (or more...) - I read the FAQ and found that we can change the parameter "scale" in the function "playMediaSession()" of OpenRTSP.cpp to set the speed. Is it possible doing something similar for streaming? Thank you in advance. Best regards, Ambra -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071003/8eaae4c8/ attachment-0001.html ------------------------------ Message: 2 Date: Wed, 03 Oct 2007 07:44:16 -0700 From: Ron McOuat Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel) To: live-devel at ns.live555.com Message-ID: <4703AAC0.1080802 at smartt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I have observed a similar sounding situation as follows: Use openRTSP to receive the video stream from an Axis camera, I have tried several models Using RTP over UDP (no -t or -T option) will run for hours Using RTP over TCP (-t option) will fail somewhere between 600 and 2000 seconds Using HTTP tunneling (-T 80 option) will run for hours Compiling the live555 code with debug on reveals the end sequence looks like this: ~~~~~~~~~~~~~~~ Debug trace ~~~~~~~~~~~~~~~ sendRTPOverTCP: 976 bytes over channel 0 (socket 8) sendRTPOverTCP: completed SocketDescriptor::tcpReadHandler() reading 16 bytes on channel 20 SocketDescriptor::tcpReadHandler() reading 16 bytes on channel 21 [0x300be0]saw incoming RTCP packet (from address 136.244.255.191, port 1280) 80c90001 6fc0e531 81cb0001 6fc0e531 RR validated RTCP subpacket (type 2): 0, 201, 0, 0x6fc0e531 BYE Received RTCP "BYE" on "video/MP4V-ES" subsession (after 672 seconds) Sending request: TEARDOWN rtsp://69.67.172.61:554/mpeg4/1/media.amp/ RTSP/1.0 CSeq: 8 Session: 2014422318 User-Agent: ./testProgs/openRTSP (LIVE555 Streaming Media v2007.08.03) RTCPInstance[0x300be0]::~RTCPInstance() sending BYE sending RTCP packet 81c90007 af22ce4c 6fc0e531 00000000 00023418 00000388 bfcf8f2c 000127e1 81cb0001 af22ce4c sendRTPOverTCP: 40 bytes over channel 21 (socket 3) sendRTPOverTCP: completed ~~~~~~~~~~~~ End of trace ~~~~~~~~~~~~~~~~ What appears to happen that is different when the stream ends is the 2 lines from SocketDescriptor::tcpReadHandler() gets a 16 byte read on channel 20 then another 16 bytes on channel 21. Often there is a REPORT just before this but not always. The end of stream does not go through any timeouts, the debug output just rolls up and stops when I have observed this in real time. Also the address and port numbers reported for the source for both -t and -T port reported in the trace are not valid but with UDP they are good. The correct source IP address is in the TEARDOWN message. I have not had a chance to dig into why this is happening yet because I have some other pressing issues to work on and have worked around this for my own purposes. However, seeing this on the mailing list prompted me to send in my observations. The system running the live555 code is OSX 10.4.10 with all patches. I was also going to verify on Linux in case this is a problem with the system interface to select(). Ron McOuat Message: 3 Date: Tue, 2 Oct 2007 17:10:25 -0700 (PDT) From: Noam Camiel Subject: [Live-devel] RTP-over-TCP streaming To: LIVE555 Streaming Media - development & use Message-ID: <76628.29785.qm at web53302.mail.re2.yahoo.com> Content-Type: text/plain; charset=us-ascii Hello I have a problem when accessing live server's stream using RTP-over-TCP as opposed to UDP. I have used the testOnDemandRTSPServer example to play a stream of of mpeg4 encodered frames (elementary stream) and was successful with both VLC and Quicktime as well as RealPlayer, using unicast UDP. But when I try to connect to the server via TCP (RTP over TCP), the video is played for a short time and then stops (with a reports - due to a network problem). This short time duration can be anywhere between 30 seconds and 10 minutes. Which is the right way to stream RTP over TCP? Should I use a different example from live than testOnDemandRTSPServer? Thanks, Noam Camiel ------------------------------ Message: 3 Date: Wed, 3 Oct 2007 08:10:20 -0700 From: Ross Finlayson Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel) To: LIVE555 Streaming Media - development & use Message-ID: Content-Type: text/plain; charset="us-ascii" ; format="flowed" >Received RTCP "BYE" on "video/MP4V-ES" subsession (after 672 seconds) The RTCP "BYE" packet (from the server) is your server is explicitly saying "I'm ending the streaming of the stream now". The client then (correctly) handles this by shutting down. So, you will need to figure out why your server has chosen to end the stream. (You may need to ask Axis about this.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ ------------------------------ Message: 4 Date: Wed, 3 Oct 2007 08:15:28 -0700 From: Ross Finlayson Subject: Re: [Live-devel] speed settings for mpeg4 To: LIVE555 Streaming Media - development & use Message-ID: Content-Type: text/plain; charset="us-ascii" >I have some questions for you about streaming of m4e files from a >server at different speed: >- does the "onDemandRTSPServer" already implement this >functionality for m4e? No, our RTSP server implementation currently does not implement 'trick play' operations when streaming MPEG-4 Elementary Stream video files. See http://www.live555.com/liveMedia/faq.html#trick-mode and http://www.live555.com/mediaServer/#trick-play -- 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/20071003/44de5163/ attachment-0001.html ------------------------------ Message: 5 Date: Thu, 4 Oct 2007 12:39:59 +0530 From: "Shaswata Jash" Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel) To: "'LIVE555 Streaming Media - development & use'" Message-ID: <016201c80655$94b16660$2e0aa8c0 at alumnusshas> Content-Type: text/plain; charset="us-ascii" >From our previous experience on working with Axis camera, it does not really support RTP interleaved packets over TCP (i.e. the specification you can find under rfc of RTSP). However, it supports RTSP tunneled over HTTP - this specification is proprietary and defined by Apple. On the configuration web-page of your Axis camera, you can verify about this. To best of my knowledge, Live555 does not yet support that RTSP tunneled over HTTP - probably Ross would be the best person to comment about this. With regards, Shaswata -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, October 03, 2007 8:40 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel) >Received RTCP "BYE" on "video/MP4V-ES" subsession (after 672 seconds) The RTCP "BYE" packet (from the server) is your server is explicitly saying "I'm ending the streaming of the stream now". The client then (correctly) handles this by shutting down. So, you will need to figure out why your server has chosen to end the stream. (You may need to ask Axis about this.) -- 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 ------------------------------ Message: 6 Date: Thu, 4 Oct 2007 00:21:06 -0700 From: Ross Finlayson Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel) To: LIVE555 Streaming Media - development & use Message-ID: Content-Type: text/plain; charset="us-ascii" >To best of my knowledge, Live555 does not yet support that RTSP tunneled >over HTTP Yes it does - in our *client* implementation. Note, for example, the "-T " option to "openRTSP": Our RTSP *server* implementation, however, does not yet support RTSP-over-HTTP tunneling (but may, sometime in the future). -- 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/20071004/7e83256d/ attachment-0001.html ------------------------------ Message: 7 Date: Thu, 4 Oct 2007 10:55:48 -0400 From: "Christopher Shumway" Subject: [Live-devel] testMPEG4VideoStreamer - Debug Assertion Failed! To: Message-ID: <9A46651B1CC1FF4DB6275ACD19773C6A28B23D at airvisual1.airvisual.net> Content-Type: text/plain; charset="us-ascii" Greetings, I am working with VS 2005 on Windows XP and I can the testMPEG4VideoStreamer program to compile. However, when I run it from a command line I receive an error message (in the form of a pop-up) which reads, "Debug Assertion Failed!". In debugging the code, I believe I am having difficulty "joining a socket group". I can debug the code to the following point, at which time it drops into the "failed to join group" error. Groupsock::Groupsock(UsageEnvironment& env, struct in_addr const& groupAddr, Port port, u_int8_t ttl) : OutputSocket(env, port), deleteIfNoMembers(False), isSlave(False), fIncomingGroupEId(groupAddr, port.num(), ttl), fDests(NULL), fTTL(ttl) { addDestination(groupAddr, port); if (!socketJoinGroup(env, socketNum(), groupAddr.s_addr)) { if (DebugLevel >= 1) { env << *this << ": failed to join group: " << env.getResultMsg() << "\n"; } } BTW - I do have this compiled (along with the 555 Live Media Server) and working fine on a Linux (Red Hat) box. I can access the test stream using VLC on my Windows PC which is on the same network as the Linux box. Thanx! Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071004/fca4fb53/ attachment.html ------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel End of live-devel Digest, Vol 48, Issue 3 ***************************************** From finlayson at live555.com Thu Oct 4 17:33:21 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Oct 2007 17:33:21 -0700 Subject: [Live-devel] Socket handling problem with live555 In-Reply-To: <200710042013.11680.weirdfox@gmail.com> References: <200710042013.11680.weirdfox@gmail.com> Message-ID: I suspect (although am not 100% sure) that this is the same RTSP server issue that Peter Leese identified last month. I'm hoping to include a fix in the next release of the software (probably sometime later this month). In the meantime, you may be able to overcome the problem by using a different RTSP client. What RTSP client do you use now? (I don't think the VLC client will trigger this problem.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rtam at 2wire.com Thu Oct 4 18:46:39 2007 From: rtam at 2wire.com (Raymond Tam) Date: Thu, 4 Oct 2007 18:46:39 -0700 Subject: [Live-devel] Streaming a H.264 file Message-ID: Hi, I've implemented my own H.264 framer and testH264AudioVideoStreamer, and the test program is now streaming RTP/H.264 packets to a VLC client and I can see the video playing on the VLC client. But after running for a while, I get this error: About to throw NO_MORE_BUFFERED_INPUT! twH264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) *** glibc detected *** ./testH264AudioVideoStreamer: free(): invalid next size (normal): 0x086923a8 *** ======= Backtrace: ========= /lib/libc.so.6[0x9b9efd] /lib/libc.so.6(cfree+0x90)[0x9bd550] /usr/lib/libstdc++.so.6(__cxa_free_exception+0x3c)[0x255a4c] My test program runs on Linux. I've tried to increase "BANK_SIZE" in StreamParser.cpp from 150,000 to 1,5000,000 but no difference. It always happens when "throw" happens in StreamParser::ensureValidBytes1(). Any idea ? Thank you in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071004/f5f4e999/attachment.html From weirdfox at gmail.com Thu Oct 4 20:50:58 2007 From: weirdfox at gmail.com (M-A Loyer) Date: Thu, 04 Oct 2007 23:50:58 -0400 Subject: [Live-devel] Socket handling problem with live555 In-Reply-To: References: <200710042013.11680.weirdfox@gmail.com> Message-ID: <200710042350.58731.weirdfox@gmail.com> We're currently using quicktime for java, but we're in the process to switch to another RTSP client as the free java class set of QuickTime is not well maintained and not working on all our target platforms. Thanks for the pointer, we'll give VLC a try ! Marc-Andre Le October 4, 2007, Ross Finlayson a ?crit?: > I suspect (although am not 100% sure) that this is the same RTSP > server issue that Peter Leese identified last month. > > I'm hoping to include a fix in the next release of the software > (probably sometime later this month). > > In the meantime, you may be able to overcome the problem by using a > different RTSP client. What RTSP client do you use now? (I don't > think the VLC client will trigger this problem.) From Ambra.Cristaldi at elsagdatamat.com Fri Oct 5 01:16:21 2007 From: Ambra.Cristaldi at elsagdatamat.com (Cristaldi Ambra) Date: Fri, 5 Oct 2007 10:16:21 +0200 Subject: [Live-devel] audio stream problems Message-ID: <268315E5844A704AB431589863FE8EEFD23E2D@els00wmx04.elsag.it> Hi Ross, I have a problem streaming files recorded by an Ateme Camera. I record a complete (audio + video) flow coming from this camera: I store it in two separated files, that will be named "video-MP4V-ES-1" and "audio-MPEG4-GENERIC-2", as I found in documentation. The video one is in MPEG4 format, and I can stream it using "testOndemandRTSP" and VLC player, after renaming itself "test.m4e". The problem is with the audio one. The Ateme- producers ensure me that the file format is ADTS, so I try to rename it "test.aac" and stream it using "testOndemandRTSP" and VLC player, but nothing seems to work. Where is the problem? May it be possible that the file is not an ADTS one? I try to analyze it with some Stream-analyzer program, but I didn't get any information, so I thought the problem could be in the packets of the audio signal. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071005/135d3c27/attachment.html From finlayson at live555.com Fri Oct 5 01:20:12 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Oct 2007 01:20:12 -0700 Subject: [Live-devel] Streaming a H.264 file In-Reply-To: References: Message-ID: >I've implemented my own H.264 framer and testH264AudioVideoStreamer, >and the test program is now streaming RTP/H.264 packets to a VLC >client and I can see the video playing on the VLC client. >But after running for a while, I get this error: > >About to throw NO_MORE_BUFFERED_INPUT! >twH264VideoStreamParser::parse() EXCEPTION (This is normal behavior >- *not* an error) Why do you think that's an error, when the comment in the code explicitly says that it's not? There's nothing wrong here. This is just a C++ language exception (*not* an error) that is raised whenever the StreamParser's buffer runs out. (It tells the code that more data needs to be read from the upstream source.) The *real* error is this: >*** glibc detected *** ./testH264AudioVideoStreamer: free(): invalid >next size (normal): 0x086923a8 *** >======= Backtrace: ========= >/lib/libc.so.6[0x9b9efd] >/lib/libc.so.6(cfree+0x90)[0x9bd550] >/usr/lib/libstdc++.so.6(__cxa_free_exception+0x3c)[0x255a4c] I have no idea where this error is occurring, but I see no evidence that it's occurring in the "LIVE555 Streaming Media" code. Perhaps it's occurring in your new code - e.g., when it's handling a read from the downstream object? > >My test program runs on Linux. I've tried to increase "BANK_SIZE" in >StreamParser.cpp from 150,000 to 1,5000,000 but no difference. This is a 'red herring'. As I've noted, this C++ language exception is *not* an error; it's the code working normally. -- 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/20071005/7eb643d1/attachment.html From finlayson at live555.com Fri Oct 5 01:33:34 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Oct 2007 01:33:34 -0700 Subject: [Live-devel] audio stream problems In-Reply-To: <268315E5844A704AB431589863FE8EEFD23E2D@els00wmx04.elsag.it> References: <268315E5844A704AB431589863FE8EEFD23E2D@els00wmx04.elsag.it> Message-ID: >I record a complete (audio + video) flow coming from this camera: I >store it in two separated files, that will be named >"video-MP4V-ES-1" and "audio-MPEG4-GENERIC-2", as I found in >documentation. >The video one is in MPEG4 format, and I can stream it using >"testOndemandRTSP" and VLC player, after renaming itself "test.m4e". >The problem is with the audio one. The Ateme- producers ensure me >that the file format is ADTS No it's not. The file contains raw AAC audio data. An ADTS-format file, however, is different: it contains a short header in front of each audio frame. (To help understand this, see the code for "ADTSAudioFileSource".) -- 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/20071005/4fdc36b4/attachment.html From rtam at 2wire.com Fri Oct 5 07:34:08 2007 From: rtam at 2wire.com (Raymond Tam) Date: Fri, 5 Oct 2007 07:34:08 -0700 Subject: [Live-devel] Streaming a H.264 file References: Message-ID: Thanks Ross. Yes I know the exception is not an error, in fact I've been getting it all along while parsing the stream normally. ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Ross Finlayson Sent: Fri 10/5/2007 1:20 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Streaming a H.264 file I've implemented my own H.264 framer and testH264AudioVideoStreamer, and the test program is now streaming RTP/H.264 packets to a VLC client and I can see the video playing on the VLC client. But after running for a while, I get this error: About to throw NO_MORE_BUFFERED_INPUT! twH264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) Why do you think that's an error, when the comment in the code explicitly says that it's not? There's nothing wrong here. This is just a C++ language exception (*not* an error) that is raised whenever the StreamParser's buffer runs out. (It tells the code that more data needs to be read from the upstream source.) The *real* error is this: *** glibc detected *** ./testH264AudioVideoStreamer: free(): invalid next size (normal): 0x086923a8 *** ======= Backtrace: ========= /lib/libc.so.6[0x9b9efd] /lib/libc.so.6(cfree+0x90)[0x9bd550] /usr/lib/libstdc++.so.6(__cxa_free_exception+0x3c)[0x255a4c] I have no idea where this error is occurring, but I see no evidence that it's occurring in the "LIVE555 Streaming Media" code. Perhaps it's occurring in your new code - e.g., when it's handling a read from the downstream object? My test program runs on Linux. I've tried to increase "BANK_SIZE" in StreamParser.cpp from 150,000 to 1,5000,000 but no difference. This is a 'red herring'. As I've noted, this C++ language exception is *not* an error; it's the code working normally. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From weiyutao36 at 163.com Fri Oct 5 20:21:08 2007 From: weiyutao36 at 163.com (Yutao Wei) Date: Sat, 6 Oct 2007 11:21:08 +0800 (CST) Subject: [Live-devel] How can I write the received data to a buffer? Message-ID: <1510934430.423391191640868112.JavaMail.coremail@bj163app105.163.com> Hello everyone, The OpenRTSP writes the received data to a file defaultly, can it write received data to a buffer? I traced the code of *FileSink and can not find where it writes the data to a file.How can I write the data into a buffer?Please point me the right way. Thank you very much. Yutao Wei -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071005/c62af8ca/attachment.html From finlayson at live555.com Fri Oct 5 23:38:51 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Oct 2007 23:38:51 -0700 Subject: [Live-devel] How can I write the received data to a buffer? In-Reply-To: <1510934430.423391191640868112.JavaMail.coremail@bj163app105.163.com> References: <1510934430.423391191640868112.JavaMail.coremail@bj163app105.163.com> Message-ID: >The OpenRTSP writes the received data to a file defaultly, can it >write received data to a buffer? I traced the code of *FileSink and >can not find where it writes the data to a file. "FileSink" - like *all* sink objects, fills in a buffer by reading from its upstream source. Note the call to "getNextFrame()" in "FileSink::continuePlaying()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ruru605 at 163.com Sun Oct 7 07:05:39 2007 From: ruru605 at 163.com (ruru605) Date: Sun, 7 Oct 2007 23:05:39 +0900 Subject: [Live-devel] Why I can not openrtsp on a different PC? Message-ID: <200710072305348903440@163.com> Hi, Ross How are you? I have a problem like this: I used to test liveMedia in a VMware linux as a server and use vlc as a client. Today I used another PC (VMware linux) to use openrtsp as a client while the server is the same as before. However, I run testOnDemandRTSPServer at the server and openrtsp rtsp:*.*.*.*//:8554/mp3AudioTest I got message -- "Failed to get a SDP description from URL rtsp:*.*.*.*//:8554/mp3AudioTest : Connect() failed: No route to host". Actually, if I test the client in the same PC as the server, it works very well. Please help me. Thanks very much! Best Regards Ru ruru605 2007-10-07 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071007/4daf3657/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: ? ?.vcf Type: text/x-vcard Size: 204 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20071007/4daf3657/attachment.vcf From finlayson at live555.com Sun Oct 7 13:18:26 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 7 Oct 2007 13:18:26 -0700 Subject: [Live-devel] Why I can not openrtsp on a different PC? In-Reply-To: <200710072305348903440@163.com> References: <200710072305348903440@163.com> Message-ID: > I used to test liveMedia in a VMware linux as a server and use >vlc as a client. Today I used another PC (VMware linux) to use >openrtsp as a client while the server is the same as before. >However, I run testOnDemandRTSPServer at the server and openrtsp >rtsp:*.*.*.*//:8554/mp3AudioTest I got message -- "Failed to get a >SDP description from URL rtsp:*.*.*.*//:8554/mp3AudioTest : >Connect() failed: No route to host". This is a networking/OS problem, and has nothing to do with our software. -- 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/20071007/9c46da0e/attachment.html From uozef at opensoftAustralia.com.au Mon Oct 8 09:18:55 2007 From: uozef at opensoftAustralia.com.au (Yousef Hosseini) Date: Mon, 8 Oct 2007 09:18:55 -0700 Subject: [Live-devel] live-devel Digest, Vol 48, Issue 5 In-Reply-To: References: Message-ID: <001c01c809c6$ece786b0$c6b69410$@com.au> Hi Ross and other active friends, This is second time I am writing this email but I got no answer in my first attempt. Thought every body is busy. The trouble I have is with Trick Play using Amino 110 and Live555. I am using ts / tsx but I can see a 10-15 second stuttering and soft of delay while I am doing FF and then Play. does anybody faced with this problem before or something is wrong with my configuration??? Also there is 3 second static delay when I am playing a movie on the Amino with this configuration. Please advise. Cheers, Yousef. Opensoft Australia. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of live-devel-request at ns.live555.com Sent: Friday, October 05, 2007 7:37 AM To: live-devel at ns.live555.com Subject: live-devel Digest, Vol 48, Issue 5 Send live-devel mailing list submissions to live-devel at lists.live555.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.live555.com/mailman/listinfo/live-devel or, via email, send a message with subject or body 'help' to live-devel-request at lists.live555.com You can reach the person managing the list at live-devel-owner at lists.live555.com When replying, please edit your Subject line so it is more specific than "Re: Contents of live-devel digest..." Today's Topics: 1. Re: Streaming a H.264 file (Raymond Tam) 2. Re: Socket handling problem with live555 (M-A Loyer) 3. audio stream problems (Cristaldi Ambra) 4. Re: Streaming a H.264 file (Ross Finlayson) 5. Re: audio stream problems (Ross Finlayson) 6. Re: Streaming a H.264 file (Raymond Tam) ---------------------------------------------------------------------- Message: 1 Date: Thu, 4 Oct 2007 18:46:39 -0700 From: "Raymond Tam" Subject: Re: [Live-devel] Streaming a H.264 file To: Message-ID: Content-Type: text/plain; charset="us-ascii" Hi, I've implemented my own H.264 framer and testH264AudioVideoStreamer, and the test program is now streaming RTP/H.264 packets to a VLC client and I can see the video playing on the VLC client. But after running for a while, I get this error: About to throw NO_MORE_BUFFERED_INPUT! twH264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) *** glibc detected *** ./testH264AudioVideoStreamer: free(): invalid next size (normal): 0x086923a8 *** ======= Backtrace: ========= /lib/libc.so.6[0x9b9efd] /lib/libc.so.6(cfree+0x90)[0x9bd550] /usr/lib/libstdc++.so.6(__cxa_free_exception+0x3c)[0x255a4c] My test program runs on Linux. I've tried to increase "BANK_SIZE" in StreamParser.cpp from 150,000 to 1,5000,000 but no difference. It always happens when "throw" happens in StreamParser::ensureValidBytes1(). Any idea ? Thank you in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071004/f5f4e999/ attachment-0001.html ------------------------------ Message: 2 Date: Thu, 04 Oct 2007 23:50:58 -0400 From: M-A Loyer Subject: Re: [Live-devel] Socket handling problem with live555 To: LIVE555 Streaming Media - development & use Message-ID: <200710042350.58731.weirdfox at gmail.com> Content-Type: text/plain; charset=iso-8859-1 We're currently using quicktime for java, but we're in the process to switch to another RTSP client as the free java class set of QuickTime is not well maintained and not working on all our target platforms. Thanks for the pointer, we'll give VLC a try ! Marc-Andre Le October 4, 2007, Ross Finlayson a ?crit?: > I suspect (although am not 100% sure) that this is the same RTSP > server issue that Peter Leese identified last month. > > I'm hoping to include a fix in the next release of the software > (probably sometime later this month). > > In the meantime, you may be able to overcome the problem by using a > different RTSP client. What RTSP client do you use now? (I don't > think the VLC client will trigger this problem.) ------------------------------ Message: 3 Date: Fri, 5 Oct 2007 10:16:21 +0200 From: "Cristaldi Ambra" Subject: [Live-devel] audio stream problems To: Message-ID: <268315E5844A704AB431589863FE8EEFD23E2D at els00wmx04.elsag.it> Content-Type: text/plain; charset="us-ascii" Hi Ross, I have a problem streaming files recorded by an Ateme Camera. I record a complete (audio + video) flow coming from this camera: I store it in two separated files, that will be named "video-MP4V-ES-1" and "audio-MPEG4-GENERIC-2", as I found in documentation. The video one is in MPEG4 format, and I can stream it using "testOndemandRTSP" and VLC player, after renaming itself "test.m4e". The problem is with the audio one. The Ateme- producers ensure me that the file format is ADTS, so I try to rename it "test.aac" and stream it using "testOndemandRTSP" and VLC player, but nothing seems to work. Where is the problem? May it be possible that the file is not an ADTS one? I try to analyze it with some Stream-analyzer program, but I didn't get any information, so I thought the problem could be in the packets of the audio signal. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071005/135d3c27/ attachment-0001.html ------------------------------ Message: 4 Date: Fri, 5 Oct 2007 01:20:12 -0700 From: Ross Finlayson Subject: Re: [Live-devel] Streaming a H.264 file To: LIVE555 Streaming Media - development & use Message-ID: Content-Type: text/plain; charset="us-ascii" >I've implemented my own H.264 framer and testH264AudioVideoStreamer, >and the test program is now streaming RTP/H.264 packets to a VLC >client and I can see the video playing on the VLC client. >But after running for a while, I get this error: > >About to throw NO_MORE_BUFFERED_INPUT! >twH264VideoStreamParser::parse() EXCEPTION (This is normal behavior >- *not* an error) Why do you think that's an error, when the comment in the code explicitly says that it's not? There's nothing wrong here. This is just a C++ language exception (*not* an error) that is raised whenever the StreamParser's buffer runs out. (It tells the code that more data needs to be read from the upstream source.) The *real* error is this: >*** glibc detected *** ./testH264AudioVideoStreamer: free(): invalid >next size (normal): 0x086923a8 *** >======= Backtrace: ========= >/lib/libc.so.6[0x9b9efd] >/lib/libc.so.6(cfree+0x90)[0x9bd550] >/usr/lib/libstdc++.so.6(__cxa_free_exception+0x3c)[0x255a4c] I have no idea where this error is occurring, but I see no evidence that it's occurring in the "LIVE555 Streaming Media" code. Perhaps it's occurring in your new code - e.g., when it's handling a read from the downstream object? > >My test program runs on Linux. I've tried to increase "BANK_SIZE" in >StreamParser.cpp from 150,000 to 1,5000,000 but no difference. This is a 'red herring'. As I've noted, this C++ language exception is *not* an error; it's the code working normally. -- 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/20071005/7eb643d1/ attachment-0001.html ------------------------------ Message: 5 Date: Fri, 5 Oct 2007 01:33:34 -0700 From: Ross Finlayson Subject: Re: [Live-devel] audio stream problems To: LIVE555 Streaming Media - development & use Message-ID: Content-Type: text/plain; charset="us-ascii" >I record a complete (audio + video) flow coming from this camera: I >store it in two separated files, that will be named >"video-MP4V-ES-1" and "audio-MPEG4-GENERIC-2", as I found in >documentation. >The video one is in MPEG4 format, and I can stream it using >"testOndemandRTSP" and VLC player, after renaming itself "test.m4e". >The problem is with the audio one. The Ateme- producers ensure me >that the file format is ADTS No it's not. The file contains raw AAC audio data. An ADTS-format file, however, is different: it contains a short header in front of each audio frame. (To help understand this, see the code for "ADTSAudioFileSource".) -- 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/20071005/4fdc36b4/ attachment-0001.html ------------------------------ Message: 6 Date: Fri, 5 Oct 2007 07:34:08 -0700 From: "Raymond Tam" Subject: Re: [Live-devel] Streaming a H.264 file To: "LIVE555 Streaming Media - development & use" Message-ID: Content-Type: text/plain; charset="iso-8859-1" Thanks Ross. Yes I know the exception is not an error, in fact I've been getting it all along while parsing the stream normally. ________________________________ From: live-devel-bounces at ns.live555.com on behalf of Ross Finlayson Sent: Fri 10/5/2007 1:20 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Streaming a H.264 file I've implemented my own H.264 framer and testH264AudioVideoStreamer, and the test program is now streaming RTP/H.264 packets to a VLC client and I can see the video playing on the VLC client. But after running for a while, I get this error: About to throw NO_MORE_BUFFERED_INPUT! twH264VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an error) Why do you think that's an error, when the comment in the code explicitly says that it's not? There's nothing wrong here. This is just a C++ language exception (*not* an error) that is raised whenever the StreamParser's buffer runs out. (It tells the code that more data needs to be read from the upstream source.) The *real* error is this: *** glibc detected *** ./testH264AudioVideoStreamer: free(): invalid next size (normal): 0x086923a8 *** ======= Backtrace: ========= /lib/libc.so.6[0x9b9efd] /lib/libc.so.6(cfree+0x90)[0x9bd550] /usr/lib/libstdc++.so.6(__cxa_free_exception+0x3c)[0x255a4c] I have no idea where this error is occurring, but I see no evidence that it's occurring in the "LIVE555 Streaming Media" code. Perhaps it's occurring in your new code - e.g., when it's handling a read from the downstream object? My test program runs on Linux. I've tried to increase "BANK_SIZE" in StreamParser.cpp from 150,000 to 1,5000,000 but no difference. This is a 'red herring'. As I've noted, this C++ language exception is *not* an error; it's the code working normally. -- 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 End of live-devel Digest, Vol 48, Issue 5 ***************************************** From peter at maersk-moller.net Mon Oct 8 02:02:18 2007 From: peter at maersk-moller.net (Peter Maersk-Moller) Date: Mon, 08 Oct 2007 11:02:18 +0200 Subject: [Live-devel] TS Framer/Muxer Message-ID: <4709F21A.3070303@maersk-moller.net> Hi Though RTSP for me is the right way to stream, I have to provide a MPEG-2 TS stream with H.264 and AAC. I think I remember there once were som code in the Live555 project that might help me part of the way. Have I got Altzheimers or do I remember right ? Kind regards Peter Maersk-Moller From jnitin at ssdi.sharp.co.in Mon Oct 8 04:58:30 2007 From: jnitin at ssdi.sharp.co.in (Nitin Jain) Date: Mon, 8 Oct 2007 17:28:30 +0530 Subject: [Live-devel] Packet loss in case of high bit rate mpeg4 streams Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB563241@KABEX01.sharpamericas.com> Hi Ross, We further observed that there is no packet loss on the server side if we use testOnDemandRTSPServer.cpp demo program to stream high bit rate mpeg4 elementary stream as compared to RTSP LIVE555MediaServer program for the same. So what could be the possible reason for this behavior when both the programs are using the same library? Regards Nitin From finlayson at live555.com Mon Oct 8 06:32:41 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Oct 2007 06:32:41 -0700 Subject: [Live-devel] Packet loss in case of high bit rate mpeg4 streams In-Reply-To: <9219A756FBA09B4D8CE75D4D7987D6CB563241@KABEX01.sharpamericas.com> References: <9219A756FBA09B4D8CE75D4D7987D6CB563241@KABEX01.sharpamericas.com> Message-ID: >We further observed that there is no packet loss on the server side >if we use testOnDemandRTSPServer.cpp demo program to stream high bit >rate mpeg4 elementary stream as compared to RTSP LIVE555MediaServer >program for the same. So what could be the possible reason for this >behavior when both the programs are using the same library? As far as I can tell, there's no possible explanation for this. Again, are you sure you're really seeing packet loss at the *server*? I.e., are you seeing packet loss in the over-the-network packets traces? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Oct 8 06:37:14 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Oct 2007 06:37:14 -0700 Subject: [Live-devel] TS Framer/Muxer In-Reply-To: <4709F21A.3070303@maersk-moller.net> References: <4709F21A.3070303@maersk-moller.net> Message-ID: >Though RTSP for me is the right way to stream, I have to provide a >MPEG-2 TS stream with H.264 and AAC. I think I remember there once were >som code in the Live555 project that might help me part of the way. Have >I got Altzheimers or do I remember right ? Yes, our "MPEG2TransportStreamMultiplexor" class may be able to help you. See, for example, how it is used in the "testMPEG1or2ProgramToTransportStream" demo application. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From alvin.cheung at TeleEye.com Wed Oct 10 02:35:00 2007 From: alvin.cheung at TeleEye.com (Alvin Cheung) Date: Wed, 10 Oct 2007 17:35:00 +0800 Subject: [Live-devel] Up and down stream in a RTSP session Message-ID: <001001c80b20$d4b882a0$8f8b11d2@AlvinPC> Hello All, I'm implementing a server client program using live555 as server and vlc player as client to stream audio (adpcm) signal. The down audio stream (server to client) is working perfectly that I can hear live audio from the server side's mic. The next step, up stream audio (client to server), is really give me headache. I would like to ask if it is possible to use the same RTSP session and add the up stream for the system? I'm absolutely lost that I don't even know how the RTSP and RTP standard protocol work in this scenario. Can you please give me some hint where to start? Thank you, Alvin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071010/bf3170f1/attachment.html From finlayson at live555.com Wed Oct 10 02:56:12 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Oct 2007 02:56:12 -0700 Subject: [Live-devel] Up and down stream in a RTSP session In-Reply-To: <001001c80b20$d4b882a0$8f8b11d2@AlvinPC> References: <001001c80b20$d4b882a0$8f8b11d2@AlvinPC> Message-ID: >The next step, up stream audio (client to server), is really give >me headache. >I would like to ask if it is possible to use the same RTSP session >and add the up stream for the system? No. The data stream for a RTSP/RTP session is one-way only (server->client). > I'm absolutely lost that I don't even know how the RTSP and >RTP standard protocol work in this scenario. You probably can't. For two-way communication, you probably want SIP, rather than RTSP. However, we don't support SIP (except in a limited way, as a client only). -- 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/20071010/c475f0e9/attachment.html From xcsmith at rockwellcollins.com Wed Oct 10 15:29:39 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Wed, 10 Oct 2007 17:29:39 -0500 Subject: [Live-devel] Amino STB FF stutter / delay In-Reply-To: <001c01c809c6$ece786b0$c6b69410$@com.au> Message-ID: Have you reviewed earlier mail-list inqueries regarding Amino STB and trick play? This mail list does not support Amino, specifically. As I recall, Live Networks just happens to have 1 Amino STB sitting around the lab. Your troubles with Amino STB might need to be directed to the manufacturer. It is possible that nobody currently monitoring the list knew the answer to your problem. You asked if anyone faced this problem before - personally, I don't recall seeing this specific problem cross the list recently. Ross is very good about responding to questions that are specific to the LIVE555 source or interactions between LIVE555 test applications. Unfortunately, your problem relates to interaction between Amino and LIVE555, with the problem most likely caused on the Amino end. If my memory serves, Amino STB users have had many struggles with Amino and its compatibility with trick-play streams. I recommend that you search the mail list archive for other Amino-related posts and then contact the manufacturer if you don't get any leads from the archives. I also suggest that you download and use VLC client to test whether or not you have a similar problem there. My guess is, probably you won't. if you're able to capture the plain-text RTSP messages being sent between LIVE555 and Amino STB, you could post those to the list for examination. You'll also want to note, posting the same question too many times will get you banned. live-devel-bounces at ns.live555.com wrote on 10/08/2007 11:18:55 AM: > Hi Ross and other active friends, > This is second time I am writing this email but I got no answer in my first > attempt. Thought every body is busy. The trouble I have is with Trick Play > using Amino 110 and Live555. I am using ts / tsx but I can see a 10-15 > second stuttering and soft of delay while I am doing FF and then Play. does > anybody faced with this problem before or something is wrong with my > configuration??? Also there is 3 second static delay when I am playing a > movie on the Amino with this configuration. Please advise. > Cheers, > Yousef. > Opensoft Australia. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071010/48072309/attachment.html From chang.yiwen at tw.panasonic.com Wed Oct 10 23:18:29 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Thu, 11 Oct 2007 14:18:29 +0800 Subject: [Live-devel] H264 RTP Streaming: A Tutorial Message-ID: <00e301c80bce$8c2591a0$59085a0a@userd7c6bde7c0> Hi, I am also planing to design H.264 streaming. This tutorial is very helpful to me for understanding live555 basic idea. But, I have a question. I want to replace with or insert my H.264 transcoder in H.264 streaming. Do you know what classses or functions should be rewrited or implemented in live555 libraries? And, how to do? Thanks a lot. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071010/37aa7224/attachment.html From chang.yiwen at tw.panasonic.com Wed Oct 10 23:25:43 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Thu, 11 Oct 2007 14:25:43 +0800 Subject: [Live-devel] How to replace with my H.264 transcoder? Message-ID: <00f001c80bcf$904620f0$59085a0a@userd7c6bde7c0> Hi, I am also planing to design H.264 streaming. I want to replace with or insert my H.264 transcoder in H.264 streaming. Do you know what classses or functions should be rewrited or implemented in live555 libraries? And, how to do? Thanks a lot. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071010/a99d05a2/attachment.html From jnitin at ssdi.sharp.co.in Thu Oct 11 04:13:53 2007 From: jnitin at ssdi.sharp.co.in (Nitin Jain) Date: Thu, 11 Oct 2007 16:43:53 +0530 Subject: [Live-devel] Packet loss in case of high bit rate mpeg4 streams Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB563245@KABEX01.sharpamericas.com> Hi Ross, Thanks for the reply. We further debug this issue and trace the problem to ****************************************************************************** Line100 :- makeSocketNonBlocking(fGS->socketNum()) in RTPInterface.cpp file. ****************************************************************************** If we comment out this line there is no packet loss observed for high bit rate streams .This code is recently added in the codebase.We are using WinXP Pro for both RTSP server and client. We were using oldcodebase for testOnDemandRTSPServer and newcodebase for LIVE555MediaServer hence this explain the earlier mail.Sorry for that. Regards Nitin -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com]On Behalf Of Ross Finlayson Sent: Monday, October 08, 2007 7:03 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Packet loss in case of high bit rate mpeg4 streams >We further observed that there is no packet loss on the server side >if we use testOnDemandRTSPServer.cpp demo program to stream high bit >rate mpeg4 elementary stream as compared to RTSP LIVE555MediaServer >program for the same. So what could be the possible reason for this >behavior when both the programs are using the same library? As far as I can tell, there's no possible explanation for this. Again, are you sure you're really seeing packet loss at the *server*? I.e., are you seeing packet loss in the over-the-network packets traces? -- 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 bidibulle at operamail.com Thu Oct 11 05:33:59 2007 From: bidibulle at operamail.com (David Betrand) Date: Thu, 11 Oct 2007 13:33:59 +0100 Subject: [Live-devel] Packet loss in case of high bit rate mpeg4 streams Message-ID: <20071011123359.7CAC87B7D8@ws5-10.us4.outblaze.com> Hi Ross, hi Nitin, I am also experimenting packet lost or malformed packets when I use high bitrate clips and rtp over tcp streaming transport. When I turn on the DEBUG mode, I noticed that sendRTPoverTCP generally returns "failed" status. The errno is set to EAGAIN (or EWOULDBLOCK) and is not handled at all by the method. As a reminder, this eagain flag simply means that the ressource is not avalaible at the moment and we should try later. For some reason (in my case, OS socket buffer overflow) if we get a EAGAIN error value, this means that the socket will be triggered later and it should be possible to write the remaining data at that time. I think this mechanism is not handled for the moment. Ross, do we agree with this ? We simply do not send remaining data and read again from source. Do we? In my mind the potential solution would be : - use both signal at the task scheduler level : "readable" and "writeable"; - if we get a EAGAIN status while we are writing data, attach a callback to the service scheduler and block reading operation on the stream (from a file, another network socket,...) We should also store the remaining data to write, i.e. the data that has not be sent yet. At the time the socket will be ok, the task scheduler get an event that will trigger the callback, which will write remaining data. If the write operation is complete, read again from source. What do you think about this problem? Thanks in advance for your help. Best Regards, David -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze From finlayson at live555.com Thu Oct 11 07:33:33 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Oct 2007 07:33:33 -0700 Subject: [Live-devel] Packet loss in case of high bit rate mpeg4 streams In-Reply-To: <20071011123359.7CAC87B7D8@ws5-10.us4.outblaze.com> References: <20071011123359.7CAC87B7D8@ws5-10.us4.outblaze.com> Message-ID: As you've noted/realized, any packet loss - other than network packet loss - that occurs in a system that uses our code *must* be the fault of insufficient buffering inside the OS. I.e., this is an OS problem, and any fix/workaround needs to address this. Unfortunately there is no good way for our code to handle a failed network write (i.e., no good way to 'retry' the write later). Instead, we'll need to set things up to ensure (with high probability) that network writes do not fail. Note also that we can't try to avoid these write failures by making network sockets blocking. The calls to "makeSocketNonBlocking()" are there for a good reason (e.g., to overcome the problem that Marc Neuberger noted in ), so removing those calls is *not* an acceptable solution. The simplest solution, it seems, is simply to make sure that there is reasonable buffering inside the OS on writeable sockets. To do this, add increaseSendBufferTo(envir(), clientSocket, 50*1024); after the call to "makeSocketNonBlocking()" on line 235 of "liveMedia/RTSPServer.cpp". Similarly, add increaseSendBufferTo(envir(), fGS->socketNum(), 50*1024); after the call to "makeSocketNonBlocking()" on line 101 of "liveMedia/RTPInterface.cpp". These additions will be made to the next release of the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071011/9426c3fe/attachment.html From luen_2 at hotmail.com Thu Oct 11 07:42:47 2007 From: luen_2 at hotmail.com (fung ka luen) Date: Thu, 11 Oct 2007 14:42:47 +0000 Subject: [Live-devel] About OPENRSTP with -t -c -e 5 Message-ID: Dear live555 Friends, I am trying to modify the Live555 streaming server (testOnDemandRTSPServer.exe) with some added functions. After function added, i am using the OPENRTSP to do the tests. For test the new function , I needed to send a "PLAYING" again after the first "PLAYING" Therefore, I used the -e