From joao_dealmeida at hotmail.com Sat Oct 1 00:51:52 2011 From: joao_dealmeida at hotmail.com (Joao Almeida) Date: Sat, 1 Oct 2011 07:51:52 +0000 Subject: [Live-devel] SETUPrtsp for two different IP Message-ID: hi, For our work we are trying to stream a mp4 container with two movie track on it, but from two different IP (using only one streaming server and two interface). When we stream our MP4 container we get this with wireshark: No.,Time,Source,Destination,Protocol,Info 1,0.000000,195.134.1.2,195.134.1.6,RTSP,OPTIONSrtsp://195.134.1.6/spatialSoc_basenh3.mp4RTSP/1.0 2,0.000454,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK 3,0.000607,195.134.1.2,195.134.1.6,RTSP,DESCRIBErtsp://195.134.1.6/spatialSoc_basenh3.mp4RTSP/1.0 4,0.002474,195.134.1.6,195.134.1.2,RTSP/SDP,Reply:RTSP/1.0200OK,withsessiondescription 5,0.004125,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.6/spatialSoc_basenh3.mp4/trackID=65536RTSP/1.0 6,0.004885,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK 7,0.005351,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.6/spatialSoc_basenh3.mp4/trackID=65538RTSP/1.0 8,0.006363,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK 9,0.006605,195.134.1.2,195.134.1.6,RTSP,PLAYrtsp://195.134.1.6/spatialSoc_basenh3.mp4/RTSP/1.0 10,0.007841,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK 11,0.007854,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39746,Time=1652425076 12,0.007917,195.134.1.6,195.134.1.2,RTCP,SenderReportSourcedescriptionApplicationspecific(qtsi)subtype=1 13,0.007942,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39747,Time=1652425076 14,0.007948,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39748,Time=1652425076 15,0.008686,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39749,Time=1652425076 16,0.008699,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39750,Time=1652425076 17,0.008705,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39751,Time=1652425076 18,0.008711,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39752,Time=1652425076 19,0.008716,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39753,Time=1652425076 20,0.008721,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39754,Time=1652425076 21,0.008726,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39755,Time=1652425076 22,0.008730,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39756,Time=1652425076 23,0.008735,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39757,Time=1652425076 24,0.009474,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-97,SSRC=0x52C67564,Seq=39758,Time=1652425076,Mark 25,0.009487,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-96,SSRC=0x5AD78F4E,Seq=7486,Time=189610604 26,0.009524,195.134.1.6,195.134.1.2,RTCP,SenderReportSourcedescriptionApplicationspecific(qtsi)subtype=1 27,0.009549,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-96,SSRC=0x5AD78F4E,Seq=7487,Time=189610604 28,0.009555,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-96,SSRC=0x5AD78F4E,Seq=7488,Time=189610604 29,0.009561,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-96,SSRC=0x5AD78F4E,Seq=7489,Time=189610604 30,0.009566,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-96,SSRC=0x5AD78F4E,Seq=7490,Time=189610604 31,0.009571,195.134.1.6,195.134.1.2,RTP,PT=DynamicRTP-Type-96,SSRC=0x5AD78F4E,Seq=7491,Time=189610604,Mark Can you please tell us, what we can do to change the SETUPrtsp to indicate that the two track come from two different IP (interface) for example: 4,0.002474,195.134.1.6,195.134.1.2,RTSP/SDP,Reply:RTSP/1.0200OK,withsessiondescription 5,0.004125,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.3/spatialSoc_basenh3.mp4/trackID=65536RTSP/1.0 6,0.004885,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK 7,0.005351,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.6/spatialSoc_basenh3.mp4/trackID=65538RTSP/1.0 8,0.006363,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK Thks for your help Joao Almeida PS: I know you prefer institutional emails, this my university one jmdaa at iscte.pt but i dont like to use it (no cloud computing), this why i use this hotmail in staid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Oct 1 07:49:37 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 1 Oct 2011 07:49:37 -0700 Subject: [Live-devel] Get current playback position In-Reply-To: <4E866EF7.1090900@etr-usa.com> References: <4E834E97.6040104@etr-usa.com> <8D19BE3F-BD58-4757-BCFE-D37D8CC0C80E@live555.com> <4E847959.9030902@etr-usa.com> <731551FB-652B-4415-90F6-AD8DBA13E57B@live555.com> <4E866EF7.1090900@etr-usa.com> Message-ID: > In addition to the NPT, ServerMediaSubsession::seekStream() also takes a clientId, a streamToken, and a streamDuration. For your purpose, the "streamDuration" parameter can just be 0.0 - meaning: place no limit on how much data is streamed. The other parameters come from your "RTSPServer::RTSPClientSession" object: - "fStreamStates[i].subsession" is a member variable. For you, "i" is just 0 (because - for Transport Streams - there is only one 'substream' for each stream). - "fOurSessionId" is a member variable - "fStreamStates[i].streamToken" is also a member variable. (Once again, for you, "i" is just 0.) Similarly, for the new function that I proposed float ServerMediaSubsession::currentNPT(unsigned clientSessionId) const; for getting the current NPT time, the parameters you need are the member variables: - "fStreamStates[i].subsession" (with "i" == 0) - "fOurSessionId" All of these member variables are "protected:" within "RTSPServer::RTSPClientSession". So, you can call these functions from your "RTSPServer::RTSPClientSession" object, provided, of course, that you subclass this - which I assume you have already done (because you have a custom server implementation). I.e., you should be able to access these functions - "seekStream()" and "currentNPT()" (if I provide to to you) - by subclassing "RTSPServer::RTSPClientSession", without making *any* changes to the supplied library code. The only remaining issue is how to call your new member function(s) of your subclassed "RTSPClientSession" object from outside the server - e.g., from an external thread. The way to do this is using the new "EventTrigger" mechanism that's defined for "TaskScheduler". (The "triggerEvent()" function is the only LIVE555 function that you're allowed to call from a separate thread (i.e., other than the one that runs the LIVE555 event loop).) So, here's what I suggest you do. Start by demonstrating that - without making *any* changes to the supplied library code - you can subclass "RTSPServer::RTSPClientSession" in such a way that you can call "seekStream()" with a desired NPT value, and trigger this from an external thread. If (and only if) you can do this - and find that it works the way that you expect (i.e., changes the position of the stream without confusing the RTSP client) - then let me know, and I'll then go ahead and add the "currentNPT()" function (that you could use - in a similar way - to get the NPT 'bookmarks' that you want.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Oct 1 19:29:29 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 1 Oct 2011 19:29:29 -0700 Subject: [Live-devel] Save video stream to MP4 file, audio play normal, video play slow In-Reply-To: References: Message-ID: > I use live555 to record a mediastream by following command: > > testProgs/openRTSP.exe -d 10 -4 rtsp://192.168.1.174:5544 >live555.mp4 > > But when mp4 file is created, the video is much more slow than audio The problem here is that you must specify the video frame rate - and the video width & height - on the "openRTSP" command line, using the -f, -w and -h options. Unfortunately the "mp4" file format (which is rather ill-designed for recording a live stream like this) requires that these parameters be specified in advance. See http://www.live555.com/openRTSP/#quicktime Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuan.dn at anlab.vn Sun Oct 2 21:07:10 2011 From: tuan.dn at anlab.vn (Tuan DN) Date: Mon, 3 Oct 2011 11:07:10 +0700 Subject: [Live-devel] Save video stream to MP4 file, audio play normal, video play slow In-Reply-To: References: Message-ID: Thanks Ross Finlayson My problem has been solve. On Sun, Oct 2, 2011 at 9:29 AM, Ross Finlayson wrote: > I use live555 to record a mediastream by following command: > > *testProgs/openRTSP.exe -d 10 -4 rtsp://192.168.1.174:5544 >live555.mp4* > > But when mp4 file is created, the video is much more slow than audio > > > The problem here is that you must specify the video frame rate - and the > video width & height - on the "openRTSP" command line, using the -f, -w and > -h options. Unfortunately the "mp4" file format (which is rather > ill-designed for recording a live stream like this) requires that these > parameters be specified in advance. > > See http://www.live555.com/openRTSP/#quicktime > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwolff at xvdth.com Mon Oct 3 11:06:15 2011 From: rwolff at xvdth.com (Robert Wolff (XVD)) Date: Mon, 3 Oct 2011 11:06:15 -0700 (PDT) Subject: [Live-devel] How do I compile a 32-bit version of Live555 Streaming Media on OS X? Message-ID: <2100798435.141801.1317665175698.JavaMail.root@zimbra1.mindcentric.com> We had similar needs a few months back. And you may have gotten enough of an answer, but I didn't want to assume any particular experience with the config files. As was mentioned before, -m32 is the key. Here are our diffs between config.macosx and our config.macosx-32bit. ~/dev/neuron/Common/live555 $ diff config.macosx config.macosx-32bit 1c1 < COMPILE_OPTS = $(INCLUDES) -I. $(EXTRA_LDFLAGS) -DBSD=1 -O -DSOCKLEN_T=socklen_t -DHAVE_SOCKADDR_LEN=1 --- > COMPILE_OPTS = -m32 $(INCLUDES) -I. $(EXTRA_LDFLAGS) -DBSD=1 -O -DSOCKLEN_T=socklen_t -DHAVE_SOCKADDR_LEN=1 10c10 < LINK_OPTS = -L. --- > LINK_OPTS = -L. -m32 Adding -m32 to COMPILE_OPTS and also to LINK_OPTS Tada. Working great for our experiments. Thanks, Bob Wolff ~~~~~~~~~~~~~~~~~ The default compile of Live555 Streaming Media on OSX is x86_64. How can I configure the build system to create 32-bit versions of the static libraries? I am using the instructions at live555.com/liveMedia/#config-unix I first call ./genMakefiles macosx Then call make When using lipo -info, the library shows it is x86_64. From finlayson at live555.com Mon Oct 3 18:40:45 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 3 Oct 2011 18:40:45 -0700 Subject: [Live-devel] SETUPrtsp for two different IP In-Reply-To: References: Message-ID: > For our work we are trying to stream a mp4 container with two movie track on it, but from two different IP (using only one streaming server and two interface). [...] > Can you please tell us, what we can do to change the SETUPrtsp to indicate that the two track come from two different IP (interface) I don't know if you can do this, but I suggest just changing the "rtsp://" URL to include the IP address of whichever interface you want. That might (or might not) work... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Tue Oct 4 01:16:37 2011 From: rglobisch at csir.co.za (Ralf Globisch) Date: Tue, 4 Oct 2011 10:16:37 +0200 Subject: [Live-devel] RTSP over TCP advice Message-ID: Hi Ross, Please could you venture your expert opinion on the following: We are streaming from a live555 RTSP server to an android version of VLC built with live555 using RTSP over TCP. When streaming over wifi, there are no problems. When streaming over 3G/Edge, the VLC client never starts playing and we have observed the following: The RTSP reply to the PLAY is in the same TCP frame as some interleaved media as can be seen in the attached wireshark capture (rtsp_3g). It looks like the interleaved media precedes the RTSP response (unless wireshark reorders it). This is not the case when?streaming over wifi (see attached rtsp_wifi). Here each response is in it's own TCP frame. Is this permissible according to the standard? If this is the issue, how would we best go about solving this issue: - Do we solve the issue on the server side i.e. prevent the RTSP server from sending any media until the RTSP response has been sent. - Or do we look at the client (i.e. parsing such a TCP packet)? -------------- next part -------------- A non-text attachment was scrubbed... Name: rtsp_3g Type: application/octet-stream Size: 8226 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rtsp_wifi Type: application/octet-stream Size: 3445 bytes Desc: not available URL: From rglobisch at csir.co.za Tue Oct 4 02:19:24 2011 From: rglobisch at csir.co.za (Ralf Globisch) Date: Tue, 4 Oct 2011 11:19:24 +0200 Subject: [Live-devel] RTSP over TCP advice In-Reply-To: References: Message-ID: Correct me if I'm wrong but from what I can tell taking a *quick* look at RTSPClient::handleResponseBytes and RTSPClient::parseResponseCode, it could be that the parsing fails if there is an interleaved media packet before the actual RTSP response? On Tue, Oct 4, 2011 at 10:16 AM, Ralf Globisch wrote: > Hi Ross, > Please could you venture your expert opinion on the following: > > We are streaming from a live555 RTSP server to an android version of > VLC built with live555 using RTSP over TCP. > > When streaming over wifi, there are no problems. > When streaming over 3G/Edge, the VLC client never starts playing and > we have observed the following: > > The RTSP reply to the PLAY is in the same TCP frame as some > interleaved media as can be seen in the attached wireshark capture (rtsp_3g). > It looks like the interleaved media precedes the RTSP response (unless > wireshark reorders it). > > This is not the case when?streaming over wifi (see attached rtsp_wifi). > Here each response is in it's own TCP frame. > > Is this permissible according to the standard? > > If this is the issue, how would we best go about solving this issue: > ?- Do we solve the issue on the server side i.e. prevent the RTSP > server from sending any media until the RTSP response has been sent. > ?- Or do we look at the client (i.e. parsing such a TCP packet)? > From rglobisch at csir.co.za Tue Oct 4 05:11:44 2011 From: rglobisch at csir.co.za (Ralf Globisch) Date: Tue, 4 Oct 2011 14:11:44 +0200 Subject: [Live-devel] Patch suggestion for network send error notification Message-ID: Hi Ross, Please would you consider adding this patch (or a variation thereof) into the source tree. Currently there is no way to notify the application layer if a socket send error occurs. The patch addresses this by allowing the registration of a callback handler on the RTP sink. Uses: We use this functionality in our system to kick clients that have insufficient bandwidth to sustain the media session. Testing of the patch: - The patch has been tested over the period of about two months on an internal test system - We only considered the RTSP over TCP use case - During testing the client's TCP receiver buffer would typically fill first (after constraining the available network bandwidth), followed by the TCP send buffer filling on the server, followed by a send failure, at which point the callback handler is triggered that allows application developers to handle this if so desired. Patched against the current version of live555. (2011-09-19) with "diff -Naur". Best regards, Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: live.patch Type: text/x-patch Size: 5498 bytes Desc: not available URL: From nouri at soroush.net Tue Oct 4 06:30:08 2011 From: nouri at soroush.net (Mojtaba Nouri) Date: Tue, 4 Oct 2011 17:00:08 +0330 Subject: [Live-devel] Declaration of ClientTrickPlayState Message-ID: Hi Is there any reason not to put the definition of class ClientTrickPlayState in a header file, e.g., MPEG2TransportFileServerMediaSubsession.hh? Current implementation forced me to include MPEG2TransportFileServerMediaSubsession.cpp to be able to subclass it. But doing so, I can not have multiple subclasses of it at the same time. Could you consider moving the class declaration? Thanks Mojtaba Nouri -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail2ashi.86 at gmail.com Tue Oct 4 06:48:33 2011 From: mail2ashi.86 at gmail.com (Ashish Mathur) Date: Tue, 4 Oct 2011 19:18:33 +0530 Subject: [Live-devel] How to get the file size : RTSP client live555 Message-ID: Hi Ross, Is it possible for a RTSP client to find the size of the file at the time of establishing connection from the live555 RTSP server? Or there is any workaround by seeking to the end of file and getting the offset? If yes, then how? Regards, Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Oct 4 16:44:27 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Oct 2011 16:44:27 -0700 Subject: [Live-devel] How do I compile a 32-bit version of Live555 Streaming Media on OS X? In-Reply-To: <2100798435.141801.1317665175698.JavaMail.root@zimbra1.mindcentric.com> References: <2100798435.141801.1317665175698.JavaMail.root@zimbra1.mindcentric.com> Message-ID: <3C00CBB5-768B-4875-BBA1-704B64979481@live555.com> > We had similar needs a few months back. And you may have gotten enough of an answer, > but I didn't want to assume any particular experience with the config files. As was > mentioned before, -m32 is the key. Here are our diffs between config.macosx and > our config.macosx-32bit. Thanks for the note. A new configuration file "config.macosx-32bit" will appear in the next release of the software (very soon now). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehran at stretchinc.com Tue Oct 4 19:41:53 2011 From: mehran at stretchinc.com (Mehran Ansari) Date: Tue, 4 Oct 2011 19:41:53 -0700 (PDT) Subject: [Live-devel] delay in sending MPEG4 frame using MPEG4VideoStreamDiscreteFramer In-Reply-To: <544138272.16101317780576645.JavaMail.root@mail.stretchinc.com> Message-ID: <960395513.16291317782513105.JavaMail.root@mail.stretchinc.com> I am using Live555 library to send video streams of different CODEC types from an IP-Camera which produces H.264, MJPEG, and MPEG4 video stream. I can successfully stream video one frame at a time as it is ready from my hardware encoder for H.264 and MJPEG but for MPEG4 it appears the video frames do not get sent out until some internal live555 buffer is full. When I use openRTSP client to receive MPEG4 video frames no matter what buffer size I set (-b), it always tells me that it received frames are larger than my buffer size. I derived my class from MPEG4VideoStreamDiscreteFramer. each time doGetNextFrame() is called, - I copy a complete MPEG4 frame (VOL, I, or P frame) to fTo, - fFrameSize = sizeof fTo buffer - gettimeofday(&fPresentationTime,NULL) - fDurationInMicroseconds = 0 since frames are being read from an encoder as oppose to a file. - call FramedSource::afterGetting(this) In case my encoder did not have any video frame ready when doGetNextFrame() was called I call scheduleDelayedTask() Doing the above, immediately one full frame can be displayed in VLC once it is connected or openRTSP. But then, it takes VLC sometimes up to 40 seconds to display the next few frames and stops due to frames being arrived late. For openRTSP, I keep getting the buffer is too small regardless of what buffer size I specify. Is there anything in MPEG4 like H.264 that I need to set to tell live555 this is a complete MPEG4 frame and send it immediately. For H.264 I had to implement currentNALUnitEndsAccessUnit(), is there something similar for MPEG4? I read over most of the messages in the forum and it seems that I am doing exactly what others are doing except I am having this delayed problem. Again, I can stream H.264 and MJPEG video frame with no problem. One last thing, My encoder generate VOL frame separately from the I-Frame, which I use the same fPresentationTime for both VOL and the following I-frame but they are called twice to FramedSource::afterGetting() Thanks for your help. --Mehran From finlayson at live555.com Tue Oct 4 20:11:05 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Oct 2011 20:11:05 -0700 Subject: [Live-devel] RTSP over TCP advice In-Reply-To: References: Message-ID: Yes, our server starts sending out RTP packets just before sending back the RTSP "PLAY" response. The reason for this is that the RTSP response includes a "RTP-Info" header, whose contents (in part) depend upon parameters obtained as a result of starting to send out RTP packets. But this should not be a problem for our receiving code - even when using RTP/RTP-over-TCP - because RTP or RTCP packets - when included in a TCP stream - are framed beginning with a dollar ('$') character (plus channel id and length fields), and are demultiplexed and redirected properly: RTP or RTCP packets go to their appropriate reading objects ("RTPSource" or "RTCPInstance", respectively), and RTSP requests or responses go to the 'alternative byte handler' (which, for a "RTSPClient", is the "handleAlternativeRequestByte()" function - which ends up calling "handleResponseBytes()"). So I don't know why you might be having a problem receiving data like this - especially if you're seeing the problem on one kind of network, but not another. I wonder if perhaps you have a driver or network bug somewhere that's losing some data somewhere, even though it's part of a TCP stream?? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Oct 4 20:40:45 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Oct 2011 20:40:45 -0700 Subject: [Live-devel] Patch suggestion for network send error notification In-Reply-To: References: Message-ID: <6C6E1EB8-B30E-4167-853F-2D9CDABE50CE@live555.com> OK, this will be included in the next release of the software (likely appearing within hours...) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Oct 4 21:03:27 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Oct 2011 21:03:27 -0700 Subject: [Live-devel] Declaration of ClientTrickPlayState In-Reply-To: References: Message-ID: > Is there any reason not to put the definition of class ClientTrickPlayState in a header file, e.g., MPEG2TransportFileServerMediaSubsession.hh? > Current implementation forced me to include MPEG2TransportFileServerMediaSubsession.cpp to be able to subclass it. > But doing so, I can not have multiple subclasses of it at the same time. > Could you consider moving the class declaration? OK, this will appear in the next release of the software. I've also added a protected: virtual function virtual ClientTrickPlayState* newClientTrickPlayState(); that you can redefine in your subclass to create an object of a "ClientTrickPlayState" subclass, if desired. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Oct 4 21:22:15 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Oct 2011 21:22:15 -0700 Subject: [Live-devel] How to get the file size : RTSP client live555 In-Reply-To: References: Message-ID: <59B12496-FD24-4D48-8C4C-67ADF1CB5A5E@live555.com> > Is it possible for a RTSP client to find the size of the file No, because a RTSP client (and the RTSP protocol in general) does not know anything about "files". Instead, it knows about "streams". A RTSP server *may* choose to transmit its streams by reading data from files, but it doesn't have to; the stream data could come from other sources. What a RTSP client can know, however, is the start and end time of a stream - *provided that* the stream has a known end time. You can find these values using the functions "MediaSession::playStartTime()" and "MediaSession::playEndTime()". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Oct 4 23:20:12 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Oct 2011 23:20:12 -0700 Subject: [Live-devel] New LIVE55 version - supports streaming from Matroska (.mkv) files Message-ID: <84940BC1-E6C5-4FD0-B3F4-019B99F2B95B@live555.com> The latest version (2011.10.05) of the "LIVE555 Streaming Media" code supports RTSP/RTP streaming, on demand, from a Matroska ('.mkv') file. The video, audio, and subtitle tracks (if any) within the file are demultiplexed and streamed separately, via RTP. We currently support H.264 video, AAC, AC3 and MP3 audio, and text subtitles. (Sometime in the future, we will also support WEBM ('.webm') Matroska files, with VP8 video and Vorbis audio.) The "testOnDemandRTSPServer" demo application and the "LIVE555 Media Server" (currently, just the source-code version - not the prebuilt application binary versions) have also been updated to support streaming from '.mkv' files. Notes: - We currently support H.264 video tracks, MP3, AAC, and AC-3 audio tracks, and subtitle tracks. (Any other tracks within a Matroska file will be ignored.) - As noted above, VP8 video tracks and Vorbis audio tracks will be supported in the future. - I hope to someday support other codecs as well, but first, I'll need examples of Matroska files that use these codecs. If you have an example of a Matroska file that we don't currently support, then please post a link to it, and I'll take a look at it. - We don't currently support seeking within the underlying Matroska file (to implement RTSP seeking), but hope to do so in the future. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Oct 4 23:59:03 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Oct 2011 23:59:03 -0700 Subject: [Live-devel] delay in sending MPEG4 frame using MPEG4VideoStreamDiscreteFramer In-Reply-To: <960395513.16291317782513105.JavaMail.root@mail.stretchinc.com> References: <960395513.16291317782513105.JavaMail.root@mail.stretchinc.com> Message-ID: <79989332-1149-4E71-9894-160287D6361E@live555.com> > I can successfully stream video one frame at a time as it is ready from my hardware encoder for H.264 and MJPEG but for MPEG4 it appears the video frames do not get sent out until some internal live555 buffer is full. When I use openRTSP client to receive MPEG4 video frames no matter what buffer size I set (-b), it always tells me that it received frames are larger than my buffer size. > > I derived my class from MPEG4VideoStreamDiscreteFramer. Why not just use "MPEG4VideoStreamDiscreteFramer" as is? Unfortunately, because your problem is with your own custom code, I probably can't help you here. But what I suggest you do instead is write - to a file - a few seconds of MPEG-4 video from your encoder. Send me a link to this file (or post the file itself if it's small), and I'll take a look at it, to check whether it's legal MPEG-4 video. > For H.264 I had to implement currentNALUnitEndsAccessUnit() Arghh - you're using an old version of our code. That function is no longer required/used. We don't support old versions of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joao_dealmeida at hotmail.com Wed Oct 5 01:52:40 2011 From: joao_dealmeida at hotmail.com (Joao Almeida) Date: Wed, 5 Oct 2011 08:52:40 +0000 Subject: [Live-devel] SETUPrtsp for two different IP In-Reply-To: References: , Message-ID: Hi, 1) You mean?: rtsp://195.134.1.3/spatialSoc_basenh3.mp4/trackID=65536 rtsp://195.134.1.6/spatialSoc_basenh3.mp4/trackID=65538 2) Or are talking about?: rtsp://195.134.1.3/spatialSoc_base.mp4 rtsp://195.134.1.6/spatialSoc_enh.mp4 If you refer to the 2) situation, its work of course but then the base and enhanced layers are in two different mp4 container. But i was referring to the 1) situation, where we have the base and enhanced layers in a same mp4 container, with hinting tracks for base and enhanced layers, but rtsp don't accept the trackID part. In this case we need to the "SETUP request" from rtsp to specifies a specific trackID (representing a layer) for the IP address of the interface we want.We are asking if there as a way for us to change the SETUPrtsp to indicate that the two track in a same container come from two different IP (interface)? Thks for any help you can provide Joao Almeida From: finlayson at live555.com Date: Mon, 3 Oct 2011 18:40:45 -0700 To: live-devel at ns.live555.com Subject: Re: [Live-devel] SETUPrtsp for two different IP For our work we are trying to stream a mp4 container with two movie track on it, but from two different IP (using only one streaming server and two interface). [...] Can you please tell us, what we can do to change the SETUPrtsp to indicate that the two track come from two different IP (interface) I don't know if you can do this, but I suggest just changing the "rtsp://" URL to include the IP address of whichever interface you want. That might (or might not) work... Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanjeeva.reddy at sreesaila.com Wed Oct 5 06:53:17 2011 From: sanjeeva.reddy at sreesaila.com (Sanjeeva Reddy Dontireddy) Date: Wed, 5 Oct 2011 19:23:17 +0530 Subject: [Live-devel] Using openRTSP in a script / batch file Message-ID: <004701cc8366$29ce4ab0$7d6ae010$@reddy@sreesaila.com> Hi Team, Background: We would like to use openRTSP.exe in a Windows batch file to test the RTSP URLs (from Darwin Streaming Server). Job of the batch file is to check whether the URL is accessible and playing without any problems. The RTSP URLs requires MD5 checksum to access. My sequence of requirements in a batch file is: 1. Inputs: RTSP URL (e.g: rtsp://StreamingServer.com/live_media/program.sdp), current time stamp, Secret KEY (to generate MD5 checksum) 2. Using the inputs, generate MD5 checksum 3. Append the checksum to RTSP URL (rtsp://StreamingServer.com/live_media/program.sdp) 4. Using openRTSP.exe test the RTSP URL (rtsp://StreamingServer.com/live_media/program.sdp), SETUP, PLAY, RECORD, and TEARDOWN. From the recorded output file, we shall check the size if it is greater than 0 bytes to get confirmed whether data is there or not. 5. Check the results of each phase and return OK (if all are returning status '200-OK') or FAIL (if any or all are failing) status. Support Required: I tried compiling the source code following the instructions. As I am not familiar with development (coding/compiling), I used Borland compiler. I followed the instructions (step-by-step) as guidelined by Vassselin from your website. Everything was ok, but for in LiveMedia compiling (highlighted below). Error messages were "undefined function '_lseek64' in 'SeekFIle64' function" and "undefined function '_telli64' in 'Tellifile64' function" #if (defined(__WIN32__) || defined(_WIN32)) && !defined(_WIN32_WCE) return _lseeki64(_fileno(fid), offset, whence) == (int64_t)-1 ? -1 : 0; #else #if defined(_WIN32_WCE) return fseek(fid, (long)(offset), whence); #else return fseeko(fid, (off_t)(offset), whence); #endif #endif #if (defined(__WIN32__) || defined(_WIN32)) && !defined(_WIN32_WCE) return _telli64(_fileno(fid)); #else #if defined(_WIN32_WCE) return ftell(fid); #else return ftello(fid); #endif #endif Then, I commented all the above lines and run make again. Then it went through and giving errors (while building 'testprogs') about not able to find common (Borland's).obj and .lib files, which I copied to the directory. Then, it went ok and gave the .exe files. Now, when I run the 'openRTSP.exe' with -Q and -d