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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, October 04, 2007 7:59 AM To: [EMAIL PROTECTED] Subject: live-devel Digest, Vol 48, Issue 3 Send live-devel mailing list submissions to live-devel@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 [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> Subject: [Live-devel] speed settings for mpeg4 To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel) To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: [Live-devel] RTP-over-TCP streaming To: LIVE555 Streaming Media - development & use <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel) To: LIVE555 Streaming Media - development & use <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: Re: [Live-devel] speed settings for mpeg4 To: LIVE555 Streaming Media - development & use <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel) To: "'LIVE555 Streaming Media - development & use'" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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@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 <[EMAIL PROTECTED]> Subject: Re: [Live-devel] RTP-over-TCP streaming (Noam Camiel) To: LIVE555 Streaming Media - development & use <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> 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 <http-port-number>" option to "openRTSP": <http://www.live555.com/openRTSP/#other-options> 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" <[EMAIL PROTECTED]> Subject: [Live-devel] testMPEG4VideoStreamer - Debug Assertion Failed! To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> 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@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel End of live-devel Digest, Vol 48, Issue 3 ***************************************** _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
