From david.stegbauer at acision.com Thu Jul 1 03:44:09 2010 From: david.stegbauer at acision.com (David Stegbauer) Date: Thu, 1 Jul 2010 12:44:09 +0200 Subject: [Live-devel] [PATCH] Enable logging levels, part1 Message-ID: <201007011244.09834.david.stegbauer@acision.com> Hi Ross, attached please find patch which enables logging levels. It is diff against live.2010.06.22. It is tested. Please let me know whether you accept this patch or if it should be improved or if you deny it (I'd like to know why in this case). Motivation: There are many calls in form envir() << something; or similar. These messages are either emitted or could be completely disabled by subclassing [Basic]UsageEnvironment. There is nothing in between, however some are just debug ones and others are warnings or even errors. I think there should be more fine grained control. It also should be possible (but not required) to log messages using 3rd party logging frameworks (for example rLog or glog). Overview: Actual patch (part 1) is compatible with old code and makes minimum changes. Old code will continue to work. Next patch (if this one will be accepted) will remove operator<< form UsageEnvironment and will modify envir() << something; to envir().log(level) << something; Implementation (in the attached patch): UsageEnvironment.hh , UsageEnvironment.cpp: Class Logger accepts usual log levels. It defines operator<< the same way as UsageEnvironment does. It however is not abstract class, it does just no output. Class UsageEnvironment adds new member (field) fLogger and new method log(LogLevel) which returns either current logger (fLogger) or null logger (Logger::nullLogger()) based on level. BasicUsageEnvironment.hh , BasicUsageEnvironment.cpp: Class BasicLogger defines its operator<< to print values to stderr (as BasicUsageEnvironment did) and sets its default log level to print all messages. Class BasicUsageEnvironment redirects processing from its operator<< to its method log(...). Best Regards David Stegbauer This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: live555-logger.patch Type: text/x-patch Size: 23154 bytes Desc: live555-logger.patch URL: From victor at dialog.su Thu Jul 1 04:39:49 2010 From: victor at dialog.su (Victor V. Vinokurov) Date: Thu, 01 Jul 2010 15:39:49 +0400 Subject: [Live-devel] patch to make MPEG1or2FileServerDemux seekable Message-ID: <4C2C7E85.8010809@dialog.su> Good day! For some reasons i want to have class MPEG1or2FileServerDemux seekable to have the possibility to seek on the input file. My small patch do this work. I hope that this possibility will be usefull not only for me and will be included in future releases of live555. -- See you! --- Vityusha V. Vinokurov - programmer mailto:victor at dialog.su http://www.dialog.su -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: From finlayson at live555.com Thu Jul 1 15:57:37 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Jul 2010 15:57:37 -0700 Subject: [Live-devel] [PATCH] Enable logging levels, part1 In-Reply-To: <201007011244.09834.david.stegbauer@acision.com> References: <201007011244.09834.david.stegbauer@acision.com> Message-ID: >There are many calls in form envir() << something; or similar. These messages >are either emitted or could be completely disabled by subclassing >[Basic]UsageEnvironment. The intention of the "UsageEnvironment" virtual base class is to allow various environment and application-specific custom behaviors to be implemented by defining and implementing a custom subclass of "UsageEnvironment" (or perhaps a subclass of "BasicUsageEnvironment", which is the 'default' subclass that we provide). Ideally, this avoids the need to have to make custom modifications to the provided library source code (the "live/" directory), which is something that I hope can be avoided as much as possible. In particular, the intention was that any custom output ('logging') mechanism that you desire for your own application code could be implemented by subclassing "[Basic]UsageEnvironment", and reimplementing the various "operator<<" virtual functions. There should be no need to introduce a second customizable virtual base class (named "Logger" or anything else) that developers need to concern themselves with. One customizable virtual base class ("UsageEnvironment") should be sufficient. So, your starting point should have been not to modify the provided code, but instead to try to get the functionality that you want by creating your own subclass of "[Basic]UsageEnvironment", and reimplementing the various "operator<<" virtual functions. How to do this? One possibility is to add (to your "[Basic]UsageEnvironment" subclass) a member function: setLoggingLevel(logLevelType level) and call yourEnvir.setLoggingLevel(someLevel); before each call to yourEnvir << someOutput; in your application code. Note that this would only be for *your* code; the existing (provided) code would not change. Therefore, you would need to have some 'default' logging level that would be used by all calls to "envir() <<" in the provided code. A cleaner and more sophisticated approach, however, would be to define new operators specifically for logging, so you could do (for example): int msgNum = 42; yourEnvir << log(someLevel) << "This is a log message number " << msgNum << endLog; By defining something like: YourUsageEnvironmentSubclass& log(YourUsageEnvironmentSubclass& env, logLevelType level) { env. setLoggingLevel(level); return env; } YourUsageEnvironmentSubclass& endLog(YourUsageEnvironmentSubclass& env) { env. setLoggingLevel(TheDefaultLevel); return env; } Having said all this, I do admit, though, that the diagnostic/debugging output in the provided code is a bit inconsistent right now: Some parts of the code use #ifdef DEBUG/#endif, and other parts use a 'verbosity level' variable to enable/disable diagnostic/debugging output. Over time, I will likely be making this more consistent (most likely by making more of the code use 'verbosity levels', and perhaps moving the 'verbosity level' variable into "UsageEnvironment"). But I'd prefer not to make any such changes right now, which is why I suggested above that you make the existing code use some 'default' logging level (that you can choose to do whatever you like with). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From david.stegbauer at acision.com Fri Jul 2 02:13:50 2010 From: david.stegbauer at acision.com (David Stegbauer) Date: Fri, 2 Jul 2010 11:13:50 +0200 Subject: [Live-devel] [PATCH] Enable logging levels, part1 In-Reply-To: References: <201007011244.09834.david.stegbauer@acision.com> Message-ID: <201007021113.50287.david.stegbauer@acision.com> Hi Ross, Thank you for long reply. I understand how UsageEnvironment works and I also know how to derive and re implement "operator<<" virtual functions. > Having said all this, I do admit, though, that the > diagnostic/debugging output in the provided code is a bit > inconsistent right now I'd rather say insufficient. For example in RTSPClient.cpp there are if (fVerbosityLevel >= 1) envir() << something; all over the code. But IMHO it looks not enough fine grained. Some of such "messages" are at debug level, some are at info level and some could even be on warning level. Even more important is, that my code (like MyUsageEnvironment) does not receive "verbosity level" in my operator<< for particular messages . So I'm not able to fiter them (or redirect to different destinations - console, file, syslog, ...). I think proper logging is vital part of any non-trivial code. I'm willing to cooperate with you to introduce it in live555 library. > But I'd prefer not to make any such changes right now Well, but proper logging is really important for me right now. I have feeling you are actively trying to discourage me from making any changes to the library. So the crucial questions are: Are you willing to discuss modifications? Are you willing to incorporate patches? Best Regards David Stegbauer This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From finlayson at live555.com Fri Jul 2 02:58:49 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Jul 2010 02:58:49 -0700 Subject: [Live-devel] [PATCH] Enable logging levels, part1 In-Reply-To: <201007021113.50287.david.stegbauer@acision.com> References: <201007011244.09834.david.stegbauer@acision.com> <201007021113.50287.david.stegbauer@acision.com> Message-ID: > > Having said all this, I do admit, though, that the >> diagnostic/debugging output in the provided code is a bit >> inconsistent right now > >I'd rather say insufficient. >For example in RTSPClient.cpp there are >if (fVerbosityLevel >= 1) envir() << something; >all over the code. >But IMHO it looks not enough fine grained. Some of such "messages" >are at debug >level, some are at info level and some could even be on warning level. > >Even more important is, that my code (like MyUsageEnvironment) does not >receive "verbosity level" in my operator<< for particular messages . So I'm >not able to fiter them (or redirect to different destinations - console, file, >syslog, ...). ("verbosityLevel", right now, is a parameter just to "RTSPClient::createNew()". At some point in the future, this will likely be generalized. But not right now.) As I noted in my earlier message, your "[Basic]UsageEnvironment" subclass can redefine "operator<<" to do whatever it wants with all of the output from the supplied library code (e.g., give it some 'default' logging level) - and, if you wish, you can do other things with output from your own application code. >I think proper logging is vital part of any non-trivial code. I'm willing to >cooperate with you to introduce it in live555 library. No. Logging is necessarily application specific. As I noted in my earlier message, you can do it however you want in your "[Basic]UsageEnvironment" subclass. But I won't be adding any specific 'logging' functionality to the supplied "LIVE555 Streaming Media" library code. >Well, but proper logging is really important for me right now. And I've told you how you can do it. If you don't want to write your application-specific code in the proper way - by defining your own subclass of "[Basic]UsageEnvironment", then you're on you own. Sorry. >Are you willing to discuss modifications? As I noted in my earlier message: At some point I will likely be cleaning up the debugging/diagnostic output that's done in the library code. But not right now. But you can do whatever you want with the output from your own application code, and that's all that you should be concerning yourself with right now. >Are you willing to incorporate patches? Yes - if they fit with the overall architecture of the code. Yours did not, for the reasons I explained in my earlier message. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From david.stegbauer at acision.com Fri Jul 2 03:37:06 2010 From: david.stegbauer at acision.com (David Stegbauer) Date: Fri, 2 Jul 2010 12:37:06 +0200 Subject: [Live-devel] [PATCH] Enable logging levels, part1 In-Reply-To: References: <201007011244.09834.david.stegbauer@acision.com> <201007021113.50287.david.stegbauer@acision.com> Message-ID: <201007021237.06369.david.stegbauer@acision.com> > >I think proper logging is vital part of any non-trivial code. I'm willing > >to cooperate with you to introduce it in live555 library. > > No. Logging is necessarily application specific. Then why do you ever have it in the library? Either get rid of it completely or do it correctly. > As I noted in my > earlier message, you can do it however you want in your > "[Basic]UsageEnvironment" subclass. But I won't be adding any > specific 'logging' functionality to the supplied "LIVE555 Streaming > Media" library code. Yes, I know, i have did it. But it is too coarse for me. Just subclassing does not work for me. I really really need to filter by importance.Using RTSPClient.cpp as example I have no way to decide if that "message" is debug one like envir() << "Opening connection to " ... or just something even less important like envir() << "...local connection opened\n" or somethig informative (more than debug) like envir() << "Sending request: " << cmd << "\n" By the way the last one it the only way to know sent RTSP command from client code as cmd is destroyed before function return. > >Are you willing to incorporate patches? > > Yes - if they fit with the overall architecture of the code. All right, I will try again with something completely different (not logging). Best Regards David Stegbauer This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From finlayson at live555.com Fri Jul 2 23:11:52 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Jul 2010 23:11:52 -0700 Subject: [Live-devel] [PATCH] Enable logging levels, part1 In-Reply-To: <201007021237.06369.david.stegbauer@acision.com> References: <201007011244.09834.david.stegbauer@acision.com> <201007021113.50287.david.stegbauer@acision.com> <201007021237.06369.david.stegbauer@acision.com> Message-ID: > > >I think proper logging is vital part of any non-trivial code. I'm willing >> >to cooperate with you to introduce it in live555 library. >> >> No. Logging is necessarily application specific. > >Then why do you ever have it in the library? OK, this is just a difference in word interpretation. I consider the LIVE555 library code to be doing "output". I consider the word "logging" to mean one particular implementation of output - whereby the data is written serially to some non-volatile medium. And that, of course, is application specific. >I really really need to filter by importance.Using RTSPClient.cpp as example I >have no way to decide if that "message" is debug one like >envir() << "Opening connection to " ... >or just something even less important like >envir() << "...local connection opened\n" >or somethig informative (more than debug) like >envir() << "Sending request: " << cmd << "\n" Well, in my mind, these three messages are all equally 'important' (or, at the very least, the 2nd message - contrary to what you said - is very important, because - if the client and server are on separate nodes - there's no guarantee in general that the connection opening will succeed). In any case, I just don't see what you could be doing that could make you "really really need" to treat these three messages differently (and that you couldn't do instead using string pattern matching in your application code). But in any case, this is not a priority for me. Sorry. > > >Are you willing to incorporate patches? >> >> Yes - if they fit with the overall architecture of the code. > >All right, I will try again with something completely different (not logging). The patches that I'm most likely to accept are either bug fixes, or modifications that make it easier for people to develop their own custom application code without requiring them to make additional, application-specific modifications inside the supplied library code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Jul 3 00:44:03 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 3 Jul 2010 00:44:03 -0700 Subject: [Live-devel] patch to make MPEG1or2FileServerDemux seekable In-Reply-To: <4C2C7E85.8010809@dialog.su> References: <4C2C7E85.8010809@dialog.su> Message-ID: >For some reasons i want to have class MPEG1or2FileServerDemux seekable >to have the possibility to seek on the input file. I'm a bit puzzled as to why you want to do this. A "MPEG1or2FileServerDemux" is used only within a "MPEG1or2DemuxedServerMediaSubsession" (to implement a RTSP server that streams a MPEG Program Stream file), and "MPEG1or2DemuxedServerMediaSubsession" already implements the "seekStreamSource()" virtual function, which seeks within the input file source, but also does other important things (in particular, flushing buffers). In general, just seeking within the input file (which is what your new "SeekStream()" function does) is not sufficient. So I'm not sure why you would want to have a separate "SeekStream()" function on the "MPEG1or2FileServerDemux" object, and I'm concerned that adding it would confuse developers. So I won't be adding this to the library code. What you can do, however, is define your own subclass of "MPEG1or2FileServerDemux" that defines your "SeekStream()" member function, and pass an object of this subclass (rather than the base class) to "MPEG1or2DemuxedServerMediaSubsession::createNew()". (This is another example of a situation where you can (and should) customize the supplied library code by subclassing, rather than modifying it.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bryan at smirklive.com Mon Jul 5 01:35:55 2010 From: bryan at smirklive.com (Bryan Thrasher) Date: Mon, 5 Jul 2010 04:35:55 -0400 Subject: [Live-devel] Axis RTSP Relay Message-ID: <006901cb1c1d$1657e740$4307b5c0$@com> Hi All, I have an Axis M1011 (runs linux, the chipset is ARTPEC-3 or ARTPEC-B, I am getting dev documentation on it) cameras that have an rtsp server. They can stream h.264 when a client requests it. I also have a Wowza Server that can issue the request and restream to various clients as well as record. The problem is NAT traversal. The Wowza server needs a port open on the router for the network where the cameras reside so that it can issue it's connection request. Wowza can also listen for RTSP connections and then restream. The examples I have are using VLC as the server to send to Wowza. What I would like to do is both of the following: 1) Run a program on the M1011 that will "restream" to the Wowza Server acting as a client. a. It will either pull directly from the h.264 encoder or from the rtsp server built into the camera and send to Wowza. b. It would need to initiate the connection to Wowza on start up c. It would need to recover the connection if it dropped. 2) Run a program on a Linux PC on the same network as the cameras. a. It will pull from each camera and send to Wowza. b. It would also record the streams. c. It would need to have some sort of way to send recordings to the Wowza server on-demand. Maybe there would be a program that would poll the server every so often looking to see if a recording was needed. It seems like a combination of LIVE555 Media Server and openRTSP could work assuming they can be wired together, sort of in reverse. It may also make sense to use LIVE555 Media Server instead of Wowza. Can it stream to iPhone? Has anyone done this or would anyone be interested in taking this on? Thanks, Bryan Thrasher 404-849-4063 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 5 19:16:33 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Jul 2010 19:16:33 -0700 Subject: [Live-devel] Axis RTSP Relay In-Reply-To: <006901cb1c1d$1657e740$4307b5c0$@com> References: <006901cb1c1d$1657e740$4307b5c0$@com> Message-ID: >What I would like to do is both of the following: >1) Run a program on the M1011 that will "restream" to the Wowza >Server acting as a client. >a. It will either pull directly from the h.264 encoder or from >the rtsp server built into the camera and send to Wowza. >b. It would need to initiate the connection to Wowza on start up >c. It would need to recover the connection if it dropped. >2) Run a program on a Linux PC on the same network as the cameras. >a. It will pull from each camera and send to Wowza. >b. It would also record the streams. >c. It would need to have some sort of way to send recordings >to the Wowza server on-demand. Maybe there would be a program that >would poll the server every so often looking to see if a recording >was needed. > >It seems like a combination of LIVE555 Media Server and openRTSP >could work assuming they can be wired together, sort of in reverse. I don't know what protocol(s) the 'Wowza' server uses to receive incoming streams (that it then re-streams to clients, as a server), but if it uses the same protocol that Apple 'Darwin Streaming Server' uses, then you may be able to use our "DarwinInjector" class. (For two example applications that use this class, see the code for "testMPEG1or2AudioVideoToDarwin" and "testMPEG4VideoToDarwin") > It may also make sense to use LIVE555 Media Server instead of >Wowza. Can it stream to iPhone? Not at present, because the iPhone doesn't use RTSP/RTP. Instead, it uses Apple's "HTTP live streaming protocol". I have thought about possibly supporting this as an option in our server, but right now it's just a thought (there are so many other things on my plate). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bryan at smirklive.com Mon Jul 5 19:58:06 2010 From: bryan at smirklive.com (Bryan Thrasher) Date: Mon, 5 Jul 2010 22:58:06 -0400 Subject: [Live-devel] Axis RTSP Relay In-Reply-To: References: <006901cb1c1d$1657e740$4307b5c0$@com> Message-ID: <001701cb1cb7$0f179df0$2d46d9d0$@com> The way the Wowza server works in my usgage is you tell it to pull a stream from the camera via RTSP. The M1011 only allow MPEG4 and H.264 over RTSP (maybe that's an RTSP specification). The camera produces the h.264 Baseline level 3 which is packaged up in a playlist for the iPhone. But the underlying stream format must be iPhone compatible because Wowza does not do any transcoding. The Wowza server can also listen for rtsp connections from encoders like VLC. The crux of my issue is that the Axis camera cannot initiate the connection to the Wowza server. It can only listen as a server. So what I am trying to accomplish is loading some software on the camera that will initiate an rtsp connection to Wowza and send the output from the encoder that is built into the camera, or hand off to Wowza to let it start pulling it. I saw somewhere on the openRTSP pages that you can initiate a connection with openRTSP and then have another program handle the actual streaming data. I have extremely limited knowledge of RTSP. But, would it be possible for openRTSP or even a shell script running on the camera to initiate the RTSP connection and let Wowza take over the interaction? Theoretically, can you speculate on what that RTSP "exchange" would look like? I could take that and pose it to the Wowza developers to see if they can work with it. Thanks for your help! -----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, July 05, 2010 10:17 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Axis RTSP Relay >What I would like to do is both of the following: >1) Run a program on the M1011 that will "restream" to the Wowza >Server acting as a client. >a. It will either pull directly from the h.264 encoder or from >the rtsp server built into the camera and send to Wowza. >b. It would need to initiate the connection to Wowza on start up >c. It would need to recover the connection if it dropped. >2) Run a program on a Linux PC on the same network as the cameras. >a. It will pull from each camera and send to Wowza. >b. It would also record the streams. >c. It would need to have some sort of way to send recordings >to the Wowza server on-demand. Maybe there would be a program that >would poll the server every so often looking to see if a recording >was needed. > >It seems like a combination of LIVE555 Media Server and openRTSP >could work assuming they can be wired together, sort of in reverse. I don't know what protocol(s) the 'Wowza' server uses to receive incoming streams (that it then re-streams to clients, as a server), but if it uses the same protocol that Apple 'Darwin Streaming Server' uses, then you may be able to use our "DarwinInjector" class. (For two example applications that use this class, see the code for "testMPEG1or2AudioVideoToDarwin" and "testMPEG4VideoToDarwin") > It may also make sense to use LIVE555 Media Server instead of >Wowza. Can it stream to iPhone? Not at present, because the iPhone doesn't use RTSP/RTP. Instead, it uses Apple's "HTTP live streaming protocol". I have thought about possibly supporting this as an option in our server, but right now it's just a thought (there are so many other things on my plate). -- 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 tom at silocorp.com Mon Jul 5 21:12:45 2010 From: tom at silocorp.com (Tom Pepper) Date: Mon, 5 Jul 2010 21:12:45 -0700 Subject: [Live-devel] Axis RTSP Relay In-Reply-To: <001701cb1cb7$0f179df0$2d46d9d0$@com> References: <006901cb1c1d$1657e740$4307b5c0$@com> <001701cb1cb7$0f179df0$2d46d9d0$@com> Message-ID: Bryan: I believe Wowza can actively retrieve a stream via RTP/RTSP - check the wowza forums for documentation on StreamManager and MediaCaster. You basically define an xml config that references an .sdp and it re-streams on demand or at wowza startup. The rtplive application is where you want to start. -t On Jul 5, 2010, at 7:58 PM, Bryan Thrasher wrote: > The way the Wowza server works in my usgage is you tell it to pull a stream > from the camera via RTSP. The M1011 only allow MPEG4 and H.264 over RTSP > (maybe that's an RTSP specification). The camera produces the h.264 > Baseline level 3 which is packaged up in a playlist for the iPhone. But the > underlying stream format must be iPhone compatible because Wowza does not do > any transcoding. > > The Wowza server can also listen for rtsp connections from encoders like > VLC. > > The crux of my issue is that the Axis camera cannot initiate the connection > to the Wowza server. It can only listen as a server. So what I am trying > to accomplish is loading some software on the camera that will initiate an > rtsp connection to Wowza and send the output from the encoder that is built > into the camera, or hand off to Wowza to let it start pulling it. > > I saw somewhere on the openRTSP pages that you can initiate a connection > with openRTSP and then have another program handle the actual streaming > data. I have extremely limited knowledge of RTSP. But, would it be > possible for openRTSP or even a shell script running on the camera to > initiate the RTSP connection and let Wowza take over the interaction? > Theoretically, can you speculate on what that RTSP "exchange" would look > like? I could take that and pose it to the Wowza developers to see if they > can work with it. > > Thanks for your help! > > -----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, July 05, 2010 10:17 PM > To: LIVE555 Streaming Media - development & use > Subject: Re: [Live-devel] Axis RTSP Relay > >> What I would like to do is both of the following: >> 1) Run a program on the M1011 that will "restream" to the Wowza >> Server acting as a client. >> a. It will either pull directly from the h.264 encoder or from >> the rtsp server built into the camera and send to Wowza. >> b. It would need to initiate the connection to Wowza on start up >> c. It would need to recover the connection if it dropped. >> 2) Run a program on a Linux PC on the same network as the cameras. >> a. It will pull from each camera and send to Wowza. >> b. It would also record the streams. >> c. It would need to have some sort of way to send recordings >> to the Wowza server on-demand. Maybe there would be a program that >> would poll the server every so often looking to see if a recording >> was needed. >> >> It seems like a combination of LIVE555 Media Server and openRTSP >> could work assuming they can be wired together, sort of in reverse. > > I don't know what protocol(s) the 'Wowza' server uses to receive > incoming streams (that it then re-streams to clients, as a server), > but if it uses the same protocol that Apple 'Darwin Streaming Server' > uses, then you may be able to use our "DarwinInjector" class. > > (For two example applications that use this class, see the code for > "testMPEG1or2AudioVideoToDarwin" and "testMPEG4VideoToDarwin") > > >> It may also make sense to use LIVE555 Media Server instead of >> Wowza. Can it stream to iPhone? > > Not at present, because the iPhone doesn't use RTSP/RTP. Instead, it > uses Apple's "HTTP live streaming protocol". I have thought about > possibly supporting this as an option in our server, but right now > it's just a thought (there are so many other things on my plate). > -- > > 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 > > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From rachitbiyani at gmail.com Mon Jul 5 10:52:13 2010 From: rachitbiyani at gmail.com (Rachit Biyani) Date: Mon, 5 Jul 2010 11:52:13 -0600 Subject: [Live-devel] new rtspclient implementation question Message-ID: Hello, I just recently started developing some code to implement a simple RTSP client. I have been using the new RTSPClient implementation. (the one with the non blocking sockets) Below is an excerpt from my code: *rtspclient = RTSPClient::createNew(*env,link,verbosity_level,app_name,tunnel);* * * * *env << "created rtsp client\n";* * * * RTSPClient::responseHandler *fun = &printOptions; //printOptions prints the options response to stdout* * cseq = rtspclient->sendOptionsCommand(fun,NULL);* * *env << "Options Cseq = "<< cseq << "\n";* * * * fun = &printDescribe;//printDescribe prints the sdp description to stdout * * cseq = rtspclient->sendDescribeCommand(fun,NULL);* * *env << "Describe Cseq = " << cseq << "\n";* * * * env->taskScheduler().doEventLoop(); * Now, I know that the last statement effectively terminates the current thread of execution. However, without this statement, the printOptions and printDescribe functions dont output anything. This would have probably worked fine without the last statement if blocking sockets were used. Is there a way for the printOptions/Describe functions to be called without using the env->taskScheduler().doEventLoop() statement? I tried looking through the UsageEnvironment and TaskScheduler classes, but I'm not as comfortable with C++ as I am with C, so I would really appreciate any help/suggestions I could get. Thanks, Rachit -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 5 22:37:55 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Jul 2010 22:37:55 -0700 Subject: [Live-devel] new rtspclient implementation question In-Reply-To: References: Message-ID: >I just recently started developing some code to implement a simple >RTSP client. > >I have been using the new RTSPClient implementation. (the one with >the non blocking sockets) > >Below is an excerpt from my code: > > > rtspclient = >RTSPClient::createNew(*env,link,verbosity_level,app_name,tunnel); > > *env << "created rtsp client\n"; > > RTSPClient::responseHandler *fun = &printOptions; //printOptions >prints the options response to stdout > cseq = rtspclient->sendOptionsCommand(fun,NULL); > *env << "Options Cseq = "<< cseq << "\n"; > > fun = &printDescribe;//printDescribe prints the sdp description to stdout > cseq = rtspclient->sendDescribeCommand(fun,NULL); > *env << "Describe Cseq = " << cseq << "\n"; > > env->taskScheduler().doEventLoop(); > > >Now, I know that the last statement effectively terminates the >current thread of execution. No it doesn't - it just moves the "current thread of execution" into the event loop. And that's exactly what should be happening. The handling of incoming RTSP responses - and the subsequent calling of the response handler function for each response - takes place within the event loop. Note that LIVE555 applications are event-driven. If you set the "verbosity_level" parameter to 1, you should see more information about what's happening. I notice, though, that you're trying to send 'pipelined' requests: I.e., you're sending a "DESCRIBE" command before you receive a response to the previous "OPTIONS" command. This is something that RTSP allows, and which our RTSP client software supports (though it has not been extensively tested yet). However, it's possible that your server does not support it. So, at least at first, I suggest that you don't try to pipeline requests. In particular, I suggest that you move the call to "doEventLoop()" after the call to "sendOptionsCommand()" (and then move the call to "sendDescribeCommand()" to the end of the "printOptions" response handler). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at smirklive.com Mon Jul 5 23:47:53 2010 From: bryan at smirklive.com (Bryan Thrasher) Date: Tue, 6 Jul 2010 02:47:53 -0400 Subject: [Live-devel] Axis RTSP Relay In-Reply-To: References: <006901cb1c1d$1657e740$4307b5c0$@com> <001701cb1cb7$0f179df0$2d46d9d0$@com> Message-ID: Right, but that requires that the Wowza server have access to the camera. The camera is behind a firewall so the only way to connect is from the camera to the server. On Jul 6, 2010, at 12:12 AM, Tom Pepper wrote: > Bryan: > > I believe Wowza can actively retrieve a stream via RTP/RTSP - check > the wowza forums for documentation on StreamManager and > MediaCaster. You basically define an xml config that references > an .sdp and it re-streams on demand or at wowza startup. The > rtplive application is where you want to start. > > -t > > On Jul 5, 2010, at 7:58 PM, Bryan Thrasher wrote: > >> The way the Wowza server works in my usgage is you tell it to pull >> a stream >> from the camera via RTSP. The M1011 only allow MPEG4 and H.264 >> over RTSP >> (maybe that's an RTSP specification). The camera produces the h.264 >> Baseline level 3 which is packaged up in a playlist for the >> iPhone. But the >> underlying stream format must be iPhone compatible because Wowza >> does not do >> any transcoding. >> >> The Wowza server can also listen for rtsp connections from encoders >> like >> VLC. >> >> The crux of my issue is that the Axis camera cannot initiate the >> connection >> to the Wowza server. It can only listen as a server. So what I am >> trying >> to accomplish is loading some software on the camera that will >> initiate an >> rtsp connection to Wowza and send the output from the encoder that >> is built >> into the camera, or hand off to Wowza to let it start pulling it. >> >> I saw somewhere on the openRTSP pages that you can initiate a >> connection >> with openRTSP and then have another program handle the actual >> streaming >> data. I have extremely limited knowledge of RTSP. But, would it be >> possible for openRTSP or even a shell script running on the camera to >> initiate the RTSP connection and let Wowza take over the interaction? >> Theoretically, can you speculate on what that RTSP "exchange" would >> look >> like? I could take that and pose it to the Wowza developers to see >> if they >> can work with it. >> >> Thanks for your help! >> >> -----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, July 05, 2010 10:17 PM >> To: LIVE555 Streaming Media - development & use >> Subject: Re: [Live-devel] Axis RTSP Relay >> >>> What I would like to do is both of the following: >>> 1) Run a program on the M1011 that will "restream" to the Wowza >>> Server acting as a client. >>> a. It will either pull directly from the h.264 encoder or from >>> the rtsp server built into the camera and send to Wowza. >>> b. It would need to initiate the connection to Wowza on start >>> up >>> c. It would need to recover the connection if it dropped. >>> 2) Run a program on a Linux PC on the same network as the >>> cameras. >>> a. It will pull from each camera and send to Wowza. >>> b. It would also record the streams. >>> c. It would need to have some sort of way to send recordings >>> to the Wowza server on-demand. Maybe there would be a program that >>> would poll the server every so often looking to see if a recording >>> was needed. >>> >>> It seems like a combination of LIVE555 Media Server and openRTSP >>> could work assuming they can be wired together, sort of in reverse. >> >> I don't know what protocol(s) the 'Wowza' server uses to receive >> incoming streams (that it then re-streams to clients, as a server), >> but if it uses the same protocol that Apple 'Darwin Streaming Server' >> uses, then you may be able to use our "DarwinInjector" class. >> >> (For two example applications that use this class, see the code for >> "testMPEG1or2AudioVideoToDarwin" and "testMPEG4VideoToDarwin") >> >> >>> It may also make sense to use LIVE555 Media Server instead of >>> Wowza. Can it stream to iPhone? >> >> Not at present, because the iPhone doesn't use RTSP/RTP. Instead, it >> uses Apple's "HTTP live streaming protocol". I have thought about >> possibly supporting this as an option in our server, but right now >> it's just a thought (there are so many other things on my plate). >> -- >> >> 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 >> >> >> >> >> _______________________________________________ >> live-devel mailing list >> live-devel at lists.live555.com >> http://lists.live555.com/mailman/listinfo/live-devel > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From sivrumit at yahoo.com Tue Jul 6 00:44:53 2010 From: sivrumit at yahoo.com (umit sivri) Date: Tue, 6 Jul 2010 00:44:53 -0700 (PDT) Subject: [Live-devel] Question about rtsp session behaviours Message-ID: <670997.77998.qm@web32204.mail.mud.yahoo.com> Hi all, I am developing an rtsp client for cameras and encountered a strange situation while changing stream settings on cameras. After changing a stream setting, axis3301 continues sending old stream frames for a period of time and sends changed-setting-frames only when we open a new rtsp session. Bosch, however, sends new session frames from existing session, changing incoming frames; thus, continuing to receive frames from existing session is enough to get changed-setting-frames. I was wondering if this is standard behaviour. I've looked into RTSP responses from cameras but could not progress so far. Can I distinguish behaviours above from any of the RTSP responses? Any hint would be greatly appreciated. Thanks in advance, Umit -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at j2kvideo.com Tue Jul 6 05:06:50 2010 From: andy at j2kvideo.com (Andy Bell) Date: Tue, 6 Jul 2010 14:06:50 +0200 Subject: [Live-devel] Reconnect after lost connection Message-ID: Hi, How can I check when the connection to the RTSP server has been broken due to network failure? I have a RTSP client streaming video and saving this to disk using a MediaSink. Is there a way to specify a timeout on the RTP socket and then have a callback on this timeout? Thanks in advance, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 6 18:50:15 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 6 Jul 2010 18:50:15 -0700 Subject: [Live-devel] New LIVE555 release - fixes a problem with receiving some RTP-over-TCP streams Message-ID: I have released a new version (2010.07.07) of the "LIVE555 Streaming Media" code that fixes a problem with receiving some RTP-over-TCP streams. (Thanks to Kamil Dobkowski for providing a stream that illustrated the problem.) If you run a RTSP client application that can request/receive RTP-over-TCP, then you should definitely upgrade to this new version. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jul 6 22:38:33 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 6 Jul 2010 22:38:33 -0700 Subject: [Live-devel] Reconnect after lost connection In-Reply-To: References: Message-ID: >How can I check when the connection to the RTSP server has been >broken due to network failure? I have a RTSP client streaming video >and saving this to disk using a MediaSink. Is there a way to >specify a timeout on the RTP socket and then have a callback on this >timeout? I suggest using "TaskScheduler::scheduleDelayedTask()" to set up a 'watchdog timer' immediately after you've gotten a response from the RTSP "PLAY" command, and reset this timer each time new data arrives in your 'sink' object. (You can do this by subclassing your sink class, and redefining the "continuePlaying()" virtual function to reset the watchdog timer (and then call the parent class's "continuePlaying()".) This will check not only for 'network failure', but also for the server dying. You can reset the watchdog timer using "TaskScheduler::rescheduleDelayedTask()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From silence.vincent at msa.hinet.net Thu Jul 8 00:07:59 2010 From: silence.vincent at msa.hinet.net (Vincent Chen) Date: Thu, 8 Jul 2010 15:07:59 +0800 Subject: [Live-devel] how to know if RTP packets dropped Message-ID: I am using RTSP to receive RTP packets and found some video is not smooth enough. So I am wondering if any RTP packets get dropped or not, it there any function or callback I can know?? thanks :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From heyongzhenlf at 163.com Thu Jul 8 00:50:45 2010 From: heyongzhenlf at 163.com (hello yongzhen) Date: Thu, 8 Jul 2010 15:50:45 +0800 (CST) Subject: [Live-devel] Problem while streaming 720P and g711 with livemedia Message-ID: <21e8402e.155c6.129b10906d6.Coremail.heyongzhenlf@163.com> Hi,Ross Before stream 720P at 15fps (video estimatebitrat 600~2000kbps,audio estimatebitrate 64kbps),I have stream D1 at 30fps and g711 with livemedia, and it works well.With the same implement,livemedia works well at the first 6 minutes,but the video seems like sent more and more slowly. At last video @1fps,audio works well. By the way, if i just transport video or audio only ,it works well. I set fdurationInmicroseconds = 1000000/15; gettimeofday(&fpresentationtime,NULL); Any advice for me? regards, Hello yongzhen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnkakande at gmail.com Thu Jul 8 04:14:54 2010 From: jnkakande at gmail.com (Josephine Kakande) Date: Thu, 8 Jul 2010 13:14:54 +0200 Subject: [Live-devel] kbps RTP Reception statistics Message-ID: Hello all, Are the kbits_per_second RTP reception statistics in playCommon.cpp inclusive of both the RTP payload and RTP header, or are they for the RTP payload only? Thanks, Josephine -------------- next part -------------- An HTML attachment was scrubbed... URL: From sagi at netvision.net.il Thu Jul 8 13:53:06 2010 From: sagi at netvision.net.il (Sagi Ben Moshe) Date: Thu, 8 Jul 2010 23:53:06 +0300 Subject: [Live-devel] Live555 Streaming from a live source Message-ID: <000001cb1edf$910e39c0$b32aad40$@net.il> Hi, We are trying to stream from a live source with Live555. We implement our own DeviceSource class. In this class we implement doGetNextFrame in the following (logic) way. We remove all the unnecessary implementation details so you can see the idea If no frame is available do the following nextTask() = envir().taskScheduler().scheduleDelayedTask(30000,(TaskFunc*)nextTime, this); If a frame is available do the following If (fFrameSize < fMaxSize) { memcpy(fTo, Buffer_getUserPtr(hEncBuf) ,fFrameSize); // copy the frame to Live555 nextTask() = envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::after Getting, this); } else { What should we do? (We do not understand what should we do in this option) } As you can see we would like to feed the Live555 frame by frame from the live source. However, after some calls of the function doGetNextFrame the fMaxSize is smaller than fFrameSize and the application is in deadlock state. We do not understand what should we do in order to eliminate this state. We can give part of a frame to Live555 but then it means that we are not going to feed the Live555 library in frame by frame scenario. (We can build a byte buffer between the live source and live555 but we do not sure it is the right way) Please let us know what is the preferred way of handing this issue Thanks, Sagi -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 8 21:59:53 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Jul 2010 21:59:53 -0700 Subject: [Live-devel] how to know if RTP packets dropped In-Reply-To: References: Message-ID: >I am using RTSP to receive RTP packets and found some video is not >smooth enough. > >So I am wondering if any RTP packets get dropped or not, it there >any function or callback I can know?? Look at how "openRTSP" implements the "-Q" option to get 'quality of service' (including packet loss) statistics. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jul 8 22:20:26 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Jul 2010 22:20:26 -0700 Subject: [Live-devel] kbps RTP Reception statistics In-Reply-To: References: Message-ID: >Are the kbits_per_second RTP reception statistics in playCommon.cpp >inclusive of both the RTP payload and RTP header, or are they for >the RTP payload only? They count the RTP payload only. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jul 8 22:44:40 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Jul 2010 22:44:40 -0700 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: <000001cb1edf$910e39c0$b32aad40$@net.il> References: <000001cb1edf$910e39c0$b32aad40$@net.il> Message-ID: >We are trying to stream from a live source with Live555. >We implement our own DeviceSource class. In this class we implement >doGetNextFrame in the following (logic) way. We remove all the >unnecessary implementation details so you can see the idea > >If no frame is available do the following > > nextTask() = >envir().taskScheduler().scheduleDelayedTask(30000,(TaskFunc*)nextTime, >this); >If a frame is available do the following > >If (fFrameSize < fMaxSize) This should be "<=", not "<". Also, I hope you are setting "fFrameSize" properly before you get to this "if" statement. >{ >memcpy(fTo, Buffer_getUserPtr(hEncBuf) ,fFrameSize); // copy the >frame to Live555 >nextTask() = >envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, >this); You can probably replace this last statement with: FramedSource::afterGetting(this); which is more efficient (and will avoid infinite recursion, because you're reading from a live source). >} >else >{ >What should we do? (We do not understand what should we do in this option) Something like this: fNumTruncatedBytes = fFrameSize - fMaxSize; fFrameSize = fMaxSize; FramedSource::afterGetting(this); Note, however, that if data gets truncated, then it is *dropped*. This means that you should make sure that your downstream object always has enough buffer space to avoid trunction - i.e., so that fMaxSize is always >= fFrameSize -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sagi at netvision.net.il Thu Jul 8 23:24:03 2010 From: sagi at netvision.net.il (Sagi Ben Moshe) Date: Fri, 9 Jul 2010 09:24:03 +0300 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: References: <000001cb1edf$910e39c0$b32aad40$@net.il> Message-ID: <001f01cb1f2f$5369aeb0$fa3d0c10$@net.il> Hi Ross, We are setting fFrameSize to the size of the frame before the posted code. I am familiar with fNumTruncatedBytes but as you say the data will be dropped. We do not want this to happen. I did not sure I understand your last statement "make sure that your downstream object always has enough buffer space to avoid trunction - i.e., so that fMaxSize is always >= fFrameSize". How can I assure it, the Live555 library request 150,000 bytes exactly. We give it frame by frame and on the last frame it is not the exact number so we are in the situation of fMaxSize < fFrameSize. If I understand you correctly we have two options 1. Feeding Live555 frame by frame and on the last frame truncate the frame and loss the data 2. Handle internal buffer inside our DeviceSource in order to give Live555 parts of a frame on the last frame. It means that Live555 will handle the recognition of Frames and on this scenario I do not understand what should be the fPresentationTime because we are sending only part of a frame to the Live555 library and on the next call we will send the following part of the frame. What is the preferred way of action? Thanks, Sagi -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, July 09, 2010 8:45 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Live555 Streaming from a live source >We are trying to stream from a live source with Live555. >We implement our own DeviceSource class. In this class we implement >doGetNextFrame in the following (logic) way. We remove all the >unnecessary implementation details so you can see the idea > >If no frame is available do the following > > nextTask() = >envir().taskScheduler().scheduleDelayedTask(30000,(TaskFunc*)nextTime, >this); >If a frame is available do the following > >If (fFrameSize < fMaxSize) This should be "<=", not "<". Also, I hope you are setting "fFrameSize" properly before you get to this "if" statement. >{ >memcpy(fTo, Buffer_getUserPtr(hEncBuf) ,fFrameSize); // copy the >frame to Live555 >nextTask() = >envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afte rGetting, >this); You can probably replace this last statement with: FramedSource::afterGetting(this); which is more efficient (and will avoid infinite recursion, because you're reading from a live source). >} >else >{ >What should we do? (We do not understand what should we do in this option) Something like this: fNumTruncatedBytes = fFrameSize - fMaxSize; fFrameSize = fMaxSize; FramedSource::afterGetting(this); Note, however, that if data gets truncated, then it is *dropped*. This means that you should make sure that your downstream object always has enough buffer space to avoid trunction - i.e., so that fMaxSize is always >= fFrameSize -- 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 44072429 at qq.com Fri Jul 9 00:21:26 2010 From: 44072429 at qq.com (=?ISO-8859-1?B?NDQwNzI0Mjk=?=) Date: Fri, 9 Jul 2010 15:21:26 +0800 Subject: [Live-devel] live555 rtsp server Message-ID: my friend. i am using mediaServer to develop one rtsp server with realtime video stream show. but when i finished coding.and begun to test. i found it hardly run well when lots of clients connect in. i check your code and found . there is only one thread to poll the event. so how to use mutithread type run your event loop? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 9 02:04:50 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 9 Jul 2010 02:04:50 -0700 Subject: [Live-devel] live555 rtsp server In-Reply-To: References: Message-ID: >i am using mediaServer to develop one rtsp server with realtime >video stream show. > >but when i finished coding.and begun to test. > >i found it hardly run well when lots of clients connect in. > >i check your code and found . there is only one thread to poll the event. If you had read the FAQ - as you were asked to before you subscribed to this mailing list - then you would already have known this without having to look at the code :-) > so how to use mutithread type run your event loop? You don't. (Read the FAQ!) LIVE555 applications use a single-threaded event loop - rather than threads - for concurrency. However, this is irrelevant, because I very much doubt that the performance problems with your server are due to it being CPU-bound. Instead, it's more likely that your problem is either (i) your available network bandwidth, or (ii) OS-imposed limits on the number of open sockets (if so, you can probably increase these limits by reconfiguring your OS). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jul 9 02:12:51 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 9 Jul 2010 02:12:51 -0700 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: <001f01cb1f2f$5369aeb0$fa3d0c10$@net.il> References: <000001cb1edf$910e39c0$b32aad40$@net.il> <001f01cb1f2f$5369aeb0$fa3d0c10$@net.il> Message-ID: >I did not sure I understand your last statement "make sure that your >downstream object always has enough buffer space to avoid trunction - i.e., >so that fMaxSize is always >= fFrameSize". How can I assure it, the Live555 >library request 150,000 bytes exactly. This is true only for the "StreamParser" class, which you should *not* be using, because you are delivering discrete frames - rather than a byte stream - to your downstream object. In particular, you should be using a "*DiscreteFramer" object downstream, and not a "*Framer". What objects (classes) do you have 'downstream' from your input device, and what type of data (i.e., what codec) is your "DeviceSource" object trying to deliver? (This may help identify the problem.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From 44072429 at qq.com Fri Jul 9 02:29:13 2010 From: 44072429 at qq.com (=?ISO-8859-1?B?NDQwNzI0Mjk=?=) Date: Fri, 9 Jul 2010 17:29:13 +0800 Subject: [Live-devel] live555 rtsp server Message-ID: my friend. the code in your project void sendRTPOverTCP(unsigned char* packet, unsigned packetSize, int socketNum, unsigned char streamChannelId) if the ::send return error. you mean it is the os configuration's problem? ------------------ Original ------------------ From: "Ross Finlayson"; Date: Fri, Jul 9, 2010 05:04 PM To: "LIVE555 Streaming Media - development & use"; Subject: Re: [Live-devel] live555 rtsp server >i am using mediaServer to develop one rtsp server with realtime >video stream show. > >but when i finished coding.and begun to test. > >i found it hardly run well when lots of clients connect in. > >i check your code and found . there is only one thread to poll the event. If you had read the FAQ - as you were asked to before you subscribed to this mailing list - then you would already have known this without having to look at the code :-) > so how to use mutithread type run your event loop? You don't. (Read the FAQ!) LIVE555 applications use a single-threaded event loop - rather than threads - for concurrency. However, this is irrelevant, because I very much doubt that the performance problems with your server are due to it being CPU-bound. Instead, it's more likely that your problem is either (i) your available network bandwidth, or (ii) OS-imposed limits on the number of open sockets (if so, you can probably increase these limits by reconfiguring your OS). -- 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 finlayson at live555.com Fri Jul 9 05:01:33 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 9 Jul 2010 05:01:33 -0700 Subject: [Live-devel] live555 rtsp server In-Reply-To: References: Message-ID: >the code in your project > >void sendRTPOverTCP(unsigned char* packet, unsigned packetSize, > int socketNum, unsigned char streamChannelId) > >if the ::send return error. you mean it is the os configuration's problem? Perhaps. What error(s) are the "send()" calls returning (i.e., what "errno" values)? It's possible that your problem could be fixed (or at least reduced) by increasing the OS's internal buffer for sending data on the streams' sockets. You can do this by calling "increaseSendBufferTo()". Note that - by default - a 50 kByte buffer is used (see "RTSPServer.cpp"), but you could increase this. However, even this might not be enough if the failures are occurring because of excessive network congestion - if the combined bitrates of your output streams exceed the capacity of your network. If that's the case, then there's nothing you can do. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From marc.lambert at smardtv.com Fri Jul 9 06:34:41 2010 From: marc.lambert at smardtv.com (Lambert Marc) Date: Fri, 9 Jul 2010 15:34:41 +0200 Subject: [Live-devel] RTP packet lost when Live555MediaServer streams forward Dektec DTE3114 In-Reply-To: References: Message-ID: <6A8A31FCBF334D46904F2C962070EF3F019F9DE5@capella.hq.k.grp> Hello, First of all, I'm certainly not the first to say that but thank you for this very nice software. I use live555MediaServer in the context of my job and I compilled it with the option "RTSP_ALLOW_CLIENT_DESTINATION_SETTING" to make me able to control the server from a device connected on the network and to stream forward an IPtoTS modulator (DTE-3114 from Dektec) providing a DVB-C signal to a TV. My client is working well and everything is working perfectly with VLC but... When I replace VLC by the DTE-3114, the outgoing signal is not good with many RTP packet loss. Then, I tryed to change many parameters on each sides but nothing is fixing that. I also used the DTE-3114 with the QVidium file streamer (it doesn't have the rtsp server, just the rtp streamer) and, in that case, I succeed to stream perfectly until 25Mbps... I captured with Wireshark and there is a difference between the 2 streaming methodes, the Qvidium seems to allow more time before to send the next frame and the frame is composed of many UDP packet when Live555 try to gather perfectly the packets during the time and I guess it is stressing too much the DTE-3114 to treat this bandwidth on the fly. Then, I would like to know if it is possible to change the way to send packet on the network to try to make my test bench working. Thank's in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamildobk at poczta.onet.pl Fri Jul 9 06:58:27 2010 From: kamildobk at poczta.onet.pl (Kamil Dobkowski) Date: Fri, 9 Jul 2010 15:58:27 +0200 Subject: [Live-devel] New LIVE555 release - fixes a problem with receiving In-Reply-To: Message-ID: <5C5C64140A7B41139EF45AF34198A98E@KamilPC> Hi, I've tested the latest version ( 2010.07.07 ) of LiveMedia library. Unfortunately the problem with RTPoverTCP still remains. OpenRTSP client connects to the server and starts receiving data, but nothing is written to the output file, the same is with http tunneling, the same is with my application ( no frame handler called ). Unicast works fine in turn. I'm running all examples on Windows platform, so maybe it is a reason ( but I doubt it ). Kamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.lambert at smardtv.com Fri Jul 9 09:44:18 2010 From: marc.lambert at smardtv.com (Lambert Marc) Date: Fri, 9 Jul 2010 18:44:18 +0200 Subject: [Live-devel] RTP packet lost when Live555MediaServer streams forward Dektec DTE3114 In-Reply-To: References: Message-ID: <6A8A31FCBF334D46904F2C962070EF3F019F9E26@capella.hq.k.grp> Just to complet my explaination, please find the 2 IO Graphs Qvidium vs Live555 rtp streaming. Regards ________________________________ De : Lambert Marc Envoy? : vendredi 9 juillet 2010 15:35 ? : 'live-devel at lists.live555.com' Objet : RTP packet lost when Live555MediaServer streams forward Dektec DTE3114 Hello, First of all, I'm certainly not the first to say that but thank you for this very nice software. I use live555MediaServer in the context of my job and I compilled it with the option "RTSP_ALLOW_CLIENT_DESTINATION_SETTING" to make me able to control the server from a device connected on the network and to stream forward an IPtoTS modulator (DTE-3114 from Dektec) providing a DVB-C signal to a TV. My client is working well and everything is working perfectly with VLC but... When I replace VLC by the DTE-3114, the outgoing signal is not good with many RTP packet loss. Then, I tryed to change many parameters on each sides but nothing is fixing that. I also used the DTE-3114 with the QVidium file streamer (it doesn't have the rtsp server, just the rtp streamer) and, in that case, I succeed to stream perfectly until 25Mbps... I captured with Wireshark and there is a difference between the 2 streaming methodes, the Qvidium seems to allow more time before to send the next frame and the frame is composed of many UDP packet when Live555 try to gather perfectly the packets during the time and I guess it is stressing too much the DTE-3114 to treat this bandwidth on the fly. Then, I would like to know if it is possible to change the way to send packet on the network to try to make my test bench working. Thank's in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: streaming live555.png Type: image/png Size: 58821 bytes Desc: streaming live555.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: streaming qvidium.png Type: image/png Size: 67994 bytes Desc: streaming qvidium.png URL: From finlayson at live555.com Fri Jul 9 17:11:36 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 9 Jul 2010 17:11:36 -0700 Subject: [Live-devel] New LIVE555 release - fixes a problem with receiving In-Reply-To: <5C5C64140A7B41139EF45AF34198A98E@KamilPC> References: <5C5C64140A7B41139EF45AF34198A98E@KamilPC> Message-ID: >I've tested the latest version ( 2010.07.07 ) of LiveMedia library. >Unfortunately the problem with RTPoverTCP still remains. That's odd. I tested "openRTSP -t" with the URL that you gave me, and it worked fine (and still does; I checked it again just now). Are you using the same URL? Are you *sure* that your "openRTSP" was built using the latest version of the code (you can see the version number in the "openRTSP" diagnostic output)? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pepamoixiiovino at terra.es Sat Jul 10 01:16:58 2010 From: pepamoixiiovino at terra.es (pepamoixiiovino at terra.es) Date: Sat, 10 Jul 2010 01:16:58 -0700 (PDT) Subject: [Live-devel] Downloading streaming only not seekable streams with no loss Message-ID: <201007100816.o6A8GwWk098767@ns.live555.com> I want to download streaming only not seekable streams like the HD version of: http://www.apple.com/quicktime/qtv/wwdc10/index.html with absolutely no loss. I think doing a multipass download saving each packet until all of them are saved could download entirely all the stream. Is there a way to fully download streaming only non seekable streams? Are there any plans or other tool able to do that? From 44072429 at qq.com Sat Jul 10 07:42:45 2010 From: 44072429 at qq.com (=?ISO-8859-1?B?NDQwNzI0Mjk=?=) Date: Sat, 10 Jul 2010 22:42:45 +0800 Subject: [Live-devel] live555 rtsp server Message-ID: i tried to increase the send buffer.but i can't help me. one connection has 8mbps.and there must 64 connections at least. so you said, i can't finish my job? ------------------ Original ------------------ From: "Ross Finlayson"; Date: Fri, Jul 9, 2010 08:01 PM To: "LIVE555 Streaming Media - development & use"; Subject: Re: [Live-devel] live555 rtsp server >the code in your project > >void sendRTPOverTCP(unsigned char* packet, unsigned packetSize, > int socketNum, unsigned char streamChannelId) > >if the ::send return error. you mean it is the os configuration's problem? Perhaps. What error(s) are the "send()" calls returning (i.e., what "errno" values)? It's possible that your problem could be fixed (or at least reduced) by increasing the OS's internal buffer for sending data on the streams' sockets. You can do this by calling "increaseSendBufferTo()". Note that - by default - a 50 kByte buffer is used (see "RTSPServer.cpp"), but you could increase this. However, even this might not be enough if the failures are occurring because of excessive network congestion - if the combined bitrates of your output streams exceed the capacity of your network. If that's the case, then there's nothing you can do. -- 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 finlayson at live555.com Sat Jul 10 07:55:34 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 10 Jul 2010 07:55:34 -0700 Subject: [Live-devel] live555 rtsp server In-Reply-To: References: Message-ID: >i tried to increase the send buffer.but i can't help me. >one connection has 8mbps.and there must 64 connections at least. >so you said, i can't finish my job? Well, you didn't say why the "send()" calls are failing - but it seems that you're running into the bandwidth limits of your network. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From 44072429 at qq.com Sat Jul 10 08:17:31 2010 From: 44072429 at qq.com (=?ISO-8859-1?B?NDQwNzI0Mjk=?=) Date: Sat, 10 Jul 2010 23:17:31 +0800 Subject: [Live-devel] live555 rtsp server Message-ID: WSAEWOULDBLOCK windows error. i know it should retransmit the data.but that will block the thread. i do not think it was bandwidth's problem.we had other video show system.and i am sure the bandwidth will work ok. ------------------ Original ------------------ From: "Ross Finlayson"; Date: Sat, Jul 10, 2010 10:55 PM To: "LIVE555 Streaming Media - development & use"; Subject: Re: [Live-devel] live555 rtsp server >i tried to increase the send buffer.but i can't help me. >one connection has 8mbps.and there must 64 connections at least. >so you said, i can't finish my job? Well, you didn't say why the "send()" calls are failing - but it seems that you're running into the bandwidth limits of your network. -- 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 finlayson at live555.com Sat Jul 10 15:08:36 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 10 Jul 2010 15:08:36 -0700 Subject: [Live-devel] RTP packet lost when Live555MediaServer streams forward Dektec DTE3114 In-Reply-To: <6A8A31FCBF334D46904F2C962070EF3F019F9DE5@capella.hq.k.grp> References: <6A8A31FCBF334D46904F2C962070EF3F019F9DE5@capella.hq.k.grp> Message-ID: >I captured with Wireshark and there is a difference between the 2 >streaming methodes, the Qvidium seems to allow more time before to >send the next frame and the frame is composed of many UDP packet >when Live555 try to gather perfectly the packets during the time and >I guess it is stressing too much the DTE-3114 to treat this >bandwidth on the fly. >Then, I would like to know if it is possible to change the way to >send packet on the network to try to make my test bench working. Yes, perhaps - although I'm a bit surprised that our server is behaving in the way that you describe, so I suggest that you first try to investigate some more why this is happening. The code that determines the time gap between successive groups of 188-byte Transport Stream 'packets' that make up a network packet is in "liveMedia/MPEG2TransportStreamFramer.cpp", line 147: The calcuation of "fDurationInMicroseconds". This calculation is a running estimate, based on the PCR timestamps seen in the Transport Stream data. The value of "fDurationInMicroseconds" is then used by the RTP streaming code ("MultiFramedRTPSink") to figure out how long to wait before sending each outgoing network packet. So, if you wanted to change the time gaps between successive network packets, you would do so by (somehow) changing the calculation of "fDurationInMicroseconds" in the "MPEG2TransportStreamFramer" class. But, as I noted above, I suggest that - before diving in to chage this code - you first try to figure out why the current code is producing the behavior that you're seeing. Perhaps there's something strange about your data's PCR timestamps that is causing this?? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sagi at netvision.net.il Sat Jul 10 15:12:05 2010 From: sagi at netvision.net.il (Sagi Ben Moshe) Date: Sun, 11 Jul 2010 01:12:05 +0300 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: References: <000001cb1edf$910e39c0$b32aad40$@net.il> <001f01cb1f2f$5369aeb0$fa3d0c10$@net.il> Message-ID: <004b01cb207c$ee6bb220$cb431660$@net.il> Hi Ross, Ok, we used the StreamParser class and probably this cause the problem we have. This is our Device class class CapDeviceSource: public FramedSource { We are trying to stream MPEG4 (Later on we will move to H.264) What is the best class to derive from instead of FramedSource in order to use DiscreteFramer downstream object? If I understood you correctly it is MPEG4VideoStreamDiscreteFramer and we should implement the function doGetNextFunction but looking on the code we thought it is best to implement the function afterGettingFrame1, yet it is not virtual so probably we are missing something. Thanks, Sagi -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, July 09, 2010 12:13 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Live555 Streaming from a live source >I did not sure I understand your last statement "make sure that your >downstream object always has enough buffer space to avoid trunction - i.e., >so that fMaxSize is always >= fFrameSize". How can I assure it, the Live555 >library request 150,000 bytes exactly. This is true only for the "StreamParser" class, which you should *not* be using, because you are delivering discrete frames - rather than a byte stream - to your downstream object. In particular, you should be using a "*DiscreteFramer" object downstream, and not a "*Framer". What objects (classes) do you have 'downstream' from your input device, and what type of data (i.e., what codec) is your "DeviceSource" object trying to deliver? (This may help identify the problem.) -- 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 gbonneau at miranda.com Sat Jul 10 20:50:58 2010 From: gbonneau at miranda.com (BONNEAU Guy) Date: Sat, 10 Jul 2010 23:50:58 -0400 Subject: [Live-devel] RTP packet lost when Live555MediaServer streamsforward Dektec DTE3114 In-Reply-To: <6A8A31FCBF334D46904F2C962070EF3F019F9E26@capella.hq.k.grp> References: <6A8A31FCBF334D46904F2C962070EF3F019F9E26@capella.hq.k.grp> Message-ID: <6353CA579307224BAFDE9495906E691604D67C49@ca-ops-mail> This problem seems to be very similar to one I have had about 1 year ago while trying to stream a Mpeg2 TS with the live555 library with a very high datarate. Unfortunately I do not remember all the details but I eventually pinpointed the problem to the scheduler of Windows. (My testing application was Windows based). If a remember the library would compute a delay to callback a routine to schedule a new RTP packet to be sent over the network. I believe that was done through a select or sleep() function. The computing of the delay was well done by the library. But the timer resolution of Windows is 15 or 10 ms by default and the requested delay in my case was much lower given the requested bitrate from the Mpeg2 TS stream. The jitter of the packets over the network was terrible and the library much of the time was trying to catch-up from the misbehavior of the Windows Timer default resolution of 15 ms by bursting the RTP packets over the network. I solved that problem by using the TimeBeginPeriod(1) to change the Windows period of the timer to 1 ms. The callback function would then wakeup much faster and the jitter of the packets went down to an acceptable level. Guy Bonneau Just to complet my explaination, please find the 2 IO Graphs Qvidium vs Live555 rtp streaming. Regards ________________________________ De : Lambert Marc Envoy? : vendredi 9 juillet 2010 15:35 ? : 'live-devel at lists.live555.com' Objet : RTP packet lost when Live555MediaServer streams forward Dektec DTE3114 Hello, First of all, I'm certainly not the first to say that but thank you for this very nice software. I use live555MediaServer in the context of my job and I compilled it with the option "RTSP_ALLOW_CLIENT_DESTINATION_SETTING" to make me able to control the server from a device connected on the network and to stream forward an IPtoTS modulator (DTE-3114 from Dektec) providing a DVB-C signal to a TV. My client is working well and everything is working perfectly with VLC but... When I replace VLC by the DTE-3114, the outgoing signal is not good with many RTP packet loss. Then, I tryed to change many parameters on each sides but nothing is fixing that. I also used the DTE-3114 with the QVidium file streamer (it doesn't have the rtsp server, just the rtp streamer) and, in that case, I succeed to stream perfectly until 25Mbps... I captured with Wireshark and there is a difference between the 2 streaming methodes, the Qvidium seems to allow more time before to send the next frame and the frame is composed of many UDP packet when Live555 try to gather perfectly the packets during the time and I guess it is stressing too much the DTE-3114 to treat this bandwidth on the fly. Then, I would like to know if it is possible to change the way to send packet on the network to try to make my test bench working. Thank's in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jul 11 02:46:22 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 11 Jul 2010 02:46:22 -0700 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: <004b01cb207c$ee6bb220$cb431660$@net.il> References: <000001cb1edf$910e39c0$b32aad40$@net.il> <001f01cb1f2f$5369aeb0$fa3d0c10$@net.il> <004b01cb207c$ee6bb220$cb431660$@net.il> Message-ID: >We are trying to stream MPEG4 (Later on we will move to H.264) > >What is the best class to derive from instead of FramedSource in order to >use DiscreteFramer downstream object? Provided that your source object delivers one frame at a time, you should be able to feed it directly into a "MPEG4VideoStreamDiscreteFramer", with no modifications. > If I understood you correctly it is MPEG4VideoStreamDiscreteFramer and we >should implement the function doGetNextFunction but looking on the code we >thought it is best to implement the function afterGettingFrame1, yet it is >not virtual so probably we are missing something. No, there's nothing more for you to implement; just use "MPEG4VideoStreamDiscreteFramer" as is. (For H.264, however, it'll be a bit more complicated; you will need to implement your own subclass of "H264VideoStreamFramer" for that.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sagi at netvision.net.il Sun Jul 11 03:18:40 2010 From: sagi at netvision.net.il (Sagi Ben Moshe) Date: Sun, 11 Jul 2010 13:18:40 +0300 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: <004b01cb207c$ee6bb220$cb431660$@net.il> References: <000001cb1edf$910e39c0$b32aad40$@net.il> <001f01cb1f2f$5369aeb0$fa3d0c10$@net.il> <004b01cb207c$ee6bb220$cb431660$@net.il> Message-ID: <006401cb20e2$7ddec400$799c4c00$@net.il> Hi Ross, Thanks for the hint, we understood our problem. We used MPEG4VideoStreamFramer instead of MPEG4VideoStreamDiscreteFramer. We changed this and now it looks much better. Again, thank you very much for your great support and library. For the next stage we would like to use H264 codec, so I think we should write our own H264VideoStreamDiscreteFramer, is it correct? Thanks, Sagi -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Sagi Ben Moshe Sent: Sunday, July 11, 2010 1:12 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Live555 Streaming from a live source Hi Ross, Ok, we used the StreamParser class and probably this cause the problem we have. This is our Device class class CapDeviceSource: public FramedSource { We are trying to stream MPEG4 (Later on we will move to H.264) What is the best class to derive from instead of FramedSource in order to use DiscreteFramer downstream object? If I understood you correctly it is MPEG4VideoStreamDiscreteFramer and we should implement the function doGetNextFunction but looking on the code we thought it is best to implement the function afterGettingFrame1, yet it is not virtual so probably we are missing something. Thanks, Sagi -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, July 09, 2010 12:13 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Live555 Streaming from a live source >I did not sure I understand your last statement "make sure that your >downstream object always has enough buffer space to avoid trunction - i.e., >so that fMaxSize is always >= fFrameSize". How can I assure it, the Live555 >library request 150,000 bytes exactly. This is true only for the "StreamParser" class, which you should *not* be using, because you are delivering discrete frames - rather than a byte stream - to your downstream object. In particular, you should be using a "*DiscreteFramer" object downstream, and not a "*Framer". What objects (classes) do you have 'downstream' from your input device, and what type of data (i.e., what codec) is your "DeviceSource" object trying to deliver? (This may help identify the problem.) -- 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 _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Sun Jul 11 06:20:46 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 11 Jul 2010 06:20:46 -0700 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: <006401cb20e2$7ddec400$799c4c00$@net.il> References: <000001cb1edf$910e39c0$b32aad40$@net.il> <001f01cb1f2f$5369aeb0$fa3d0c10$@net.il> <004b01cb207c$ee6bb220$cb431660$@net.il> <006401cb20e2$7ddec400$799c4c00$@net.il> Message-ID: >For the next stage we would like to use H264 codec, so I think we should >write our own H264VideoStreamDiscreteFramer, is it correct? Yes, you need to write your own subclass of "H264VideoStreamFramer"; see http://www.live555.com/liveMedia/faq.html#h264-streaming -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From marc.lambert at smardtv.com Mon Jul 12 03:30:30 2010 From: marc.lambert at smardtv.com (Lambert Marc) Date: Mon, 12 Jul 2010 12:30:30 +0200 Subject: [Live-devel] RTP packet lost when Live555MediaServerstreamsforward Dektec DTE3114 In-Reply-To: <6353CA579307224BAFDE9495906E691604D67C49@ca-ops-mail> References: <6A8A31FCBF334D46904F2C962070EF3F019F9E26@capella.hq.k.grp> <6353CA579307224BAFDE9495906E691604D67C49@ca-ops-mail> Message-ID: <6A8A31FCBF334D46904F2C962070EF3F019F9EC8@capella.hq.k.grp> I just tried to modify the fDurationInMicroseconds but it doesn't work. Actually, It seems the task sends packet through "sendPacketIfNecessary" as soon as the packet is prepared when I would like to wait for 3 or 4 packets ready before to send them on the network. I tried to find a way to skip to send data but when I do that, it seems also than the packet is lost... It looks like the output buffer gathers frames and when there are enough frames to do a packet the RTP packet is done and sent, could I let prepare many packets and wait for few to effectively send them ? ________________________________ De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de BONNEAU Guy Envoy? : dimanche 11 juillet 2010 05:51 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTP packet lost when Live555MediaServerstreamsforward Dektec DTE3114 This problem seems to be very similar to one I have had about 1 year ago while trying to stream a Mpeg2 TS with the live555 library with a very high datarate. Unfortunately I do not remember all the details but I eventually pinpointed the problem to the scheduler of Windows. (My testing application was Windows based). If a remember the library would compute a delay to callback a routine to schedule a new RTP packet to be sent over the network. I believe that was done through a select or sleep() function. The computing of the delay was well done by the library. But the timer resolution of Windows is 15 or 10 ms by default and the requested delay in my case was much lower given the requested bitrate from the Mpeg2 TS stream. The jitter of the packets over the network was terrible and the library much of the time was trying to catch-up from the misbehavior of the Windows Timer default resolution of 15 ms by bursting the RTP packets over the network. I solved that problem by using the TimeBeginPeriod(1) to change the Windows period of the timer to 1 ms. The callback function would then wakeup much faster and the jitter of the packets went down to an acceptable level. Guy Bonneau Just to complet my explaination, please find the 2 IO Graphs Qvidium vs Live555 rtp streaming. Regards ________________________________ De : Lambert Marc Envoy? : vendredi 9 juillet 2010 15:35 ? : 'live-devel at lists.live555.com' Objet : RTP packet lost when Live555MediaServer streams forward Dektec DTE3114 Hello, First of all, I'm certainly not the first to say that but thank you for this very nice software. I use live555MediaServer in the context of my job and I compilled it with the option "RTSP_ALLOW_CLIENT_DESTINATION_SETTING" to make me able to control the server from a device connected on the network and to stream forward an IPtoTS modulator (DTE-3114 from Dektec) providing a DVB-C signal to a TV. My client is working well and everything is working perfectly with VLC but... When I replace VLC by the DTE-3114, the outgoing signal is not good with many RTP packet loss. Then, I tryed to change many parameters on each sides but nothing is fixing that. I also used the DTE-3114 with the QVidium file streamer (it doesn't have the rtsp server, just the rtp streamer) and, in that case, I succeed to stream perfectly until 25Mbps... I captured with Wireshark and there is a difference between the 2 streaming methodes, the Qvidium seems to allow more time before to send the next frame and the frame is composed of many UDP packet when Live555 try to gather perfectly the packets during the time and I guess it is stressing too much the DTE-3114 to treat this bandwidth on the fly. Then, I would like to know if it is possible to change the way to send packet on the network to try to make my test bench working. Thank's in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbonneau at miranda.com Mon Jul 12 08:21:49 2010 From: gbonneau at miranda.com (BONNEAU Guy) Date: Mon, 12 Jul 2010 11:21:49 -0400 Subject: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 In-Reply-To: <6A8A31FCBF334D46904F2C962070EF3F019F9EC8@capella.hq.k.grp> References: <6A8A31FCBF334D46904F2C962070EF3F019F9E26@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67C49@ca-ops-mail> <6A8A31FCBF334D46904F2C962070EF3F019F9EC8@capella.hq.k.grp> Message-ID: <6353CA579307224BAFDE9495906E691604D67DDC@ca-ops-mail> You shouldn't try to modify the code of the library unless you find a bug. The library send the packets at the appropriate time following the RTP specification unless the OS timer resolution create an issue. The library does indeed call the sendPacketIfNecessary routine to send the packets. From what I remember the library does a good job at computing the time when the Mpeg2 TS RTP packets are to be sent. I suggest you try to use the function gettimeofday() to log the time and the delay requested when nextTask() = envir().taskScheduler().scheduleDelayedTask(...) is called in function sendPacketIfNecessary() in file MultiFramedTPSink. Then log the time again with gettimeofday() in function MultiFramedRTPSink::sendNext. Then check check that you were called at the time requested by the library scheduler. If you are not then you know the problem is likely to be a timer resolution issue with the OS. This is how I was able to find my issue and find why the library was bursting the RTP packets. GB From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Lambert Marc Sent: Monday, July 12, 2010 6:31 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 I just tried to modify the fDurationInMicroseconds but it doesn't work. Actually, It seems the task sends packet through "sendPacketIfNecessary" as soon as the packet is prepared when I would like to wait for 3 or 4 packets ready before to send them on the network. I tried to find a way to skip to send data but when I do that, it seems also than the packet is lost... It looks like the output buffer gathers frames and when there are enough frames to do a packet the RTP packet is done and sent, could I let prepare many packets and wait for few to effectively send them ? ________________________________ De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de BONNEAU Guy Envoy? : dimanche 11 juillet 2010 05:51 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTP packet lost when Live555MediaServerstreamsforward Dektec DTE3114 This problem seems to be very similar to one I have had about 1 year ago while trying to stream a Mpeg2 TS with the live555 library with a very high datarate. Unfortunately I do not remember all the details but I eventually pinpointed the problem to the scheduler of Windows. (My testing application was Windows based). If a remember the library would compute a delay to callback a routine to schedule a new RTP packet to be sent over the network. I believe that was done through a select or sleep() function. The computing of the delay was well done by the library. But the timer resolution of Windows is 15 or 10 ms by default and the requested delay in my case was much lower given the requested bitrate from the Mpeg2 TS stream. The jitter of the packets over the network was terrible and the library much of the time was trying to catch-up from the misbehavior of the Windows Timer default resolution of 15 ms by bursting the RTP packets over the network. I solved that problem by using the TimeBeginPeriod(1) to change the Windows period of the timer to 1 ms. The callback function would then wakeup much faster and the jitter of the packets went down to an acceptable level. Guy Bonneau Just to complet my explaination, please find the 2 IO Graphs Qvidium vs Live555 rtp streaming. Regards ________________________________ De : Lambert Marc Envoy? : vendredi 9 juillet 2010 15:35 ? : 'live-devel at lists.live555.com' Objet : RTP packet lost when Live555MediaServer streams forward Dektec DTE3114 Hello, First of all, I'm certainly not the first to say that but thank you for this very nice software. I use live555MediaServer in the context of my job and I compilled it with the option "RTSP_ALLOW_CLIENT_DESTINATION_SETTING" to make me able to control the server from a device connected on the network and to stream forward an IPtoTS modulator (DTE-3114 from Dektec) providing a DVB-C signal to a TV. My client is working well and everything is working perfectly with VLC but... When I replace VLC by the DTE-3114, the outgoing signal is not good with many RTP packet loss. Then, I tryed to change many parameters on each sides but nothing is fixing that. I also used the DTE-3114 with the QVidium file streamer (it doesn't have the rtsp server, just the rtp streamer) and, in that case, I succeed to stream perfectly until 25Mbps... I captured with Wireshark and there is a difference between the 2 streaming methodes, the Qvidium seems to allow more time before to send the next frame and the frame is composed of many UDP packet when Live555 try to gather perfectly the packets during the time and I guess it is stressing too much the DTE-3114 to treat this bandwidth on the fly. Then, I would like to know if it is possible to change the way to send packet on the network to try to make my test bench working. Thank's in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamildobk at poczta.onet.pl Mon Jul 12 00:02:40 2010 From: kamildobk at poczta.onet.pl (Kamil Dobkowski) Date: Mon, 12 Jul 2010 09:02:40 +0200 Subject: [Live-devel] New LIVE555 release - fixes a problem with In-Reply-To: Message-ID: Hi, I downloaded LiveMedia once again and rebuilded whole project from fresh sources, but the effect is still the same. This is an example output from RTP over TCP session. Command line is : openRTSP.exe -u admin admin -F rtp-tcp-data -t rtsp://192.168.3.75/VideoInput/1/jpeg/1 > _rtp_over_tcp.txt 2>&1 openRTSP output is ( rtp-tcp-data file is empty - it has 0 bytes and there are some strange errors : sendRTPOverTCP: failed! int the output logs ) : Opening connection to 192.168.3.75, port 554... ...remote connection opened Sending request: OPTIONS rtsp://192.168.3.75/VideoInput/1/jpeg/1 RTSP/1.0 CSeq: 2 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2010.07.07) Received 96 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Server: SANYO RTSP Server Public: DESCRIBE, SETUP, TEARDOWN, PLAY Sending request: DESCRIBE rtsp://192.168.3.75/VideoInput/1/jpeg/1 RTSP/1.0 CSeq: 3 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2010.07.07) Accept: application/sdp Received 100 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 401 Unauthorized CSeq: 3 Server: SANYO RTSP Server WWW-Authenticate: Basic realm="/" Resending... Sending request: DESCRIBE rtsp://192.168.3.75/VideoInput/1/jpeg/1 RTSP/1.0 CSeq: 4 Authorization: Basic YWRtaW46YWRtaW4= User-Agent: openRTSP.exe (LIVE555 Streaming Media v2010.07.07) Accept: application/sdp Received 187 new bytes of response data. Have received 187 total bytes of a DESCRIBE RTSP response; awaiting 238 bytes more. Received 238 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 4 Server: SANYO RTSP Server Content-Base: rtsp://192.168.3.75/VideoInput/1/jpeg/1 Content-Type: application/sdp Content-Length: 238 Cache-Control: no-cache v=0 o=- -3466302438249376441 -3466302438248272635 IN IP4 192.168.3.75 s=Media Presentation c=IN IP4 0.0.0.0 b=AS:944 t=0 0 m=video 0 RTP/AVP 26 b=AS:880 a=framerate:5.0 a=quality:0 a=control:trackID=0 a=rtpmap:26 JPEG/90000 Opened URL "rtsp://192.168.3.75/VideoInput/1/jpeg/1", returning a SDP description: v=0 o=- -3466302438249376441 -3466302438248272635 IN IP4 192.168.3.75 s=Media Presentation c=IN IP4 0.0.0.0 b=AS:944 t=0 0 m=video 0 RTP/AVP 26 b=AS:880 a=framerate:5.0 a=quality:0 a=control:trackID=0 a=rtpmap:26 JPEG/90000 RTCPInstance[0025DF58]::RTCPInstance() schedule(1.026081->1278917070.353562) Created receiver for "video/JPEG" subsession (client ports 49898-49899) Sending request: SETUP rtsp://192.168.3.75/VideoInput/1/jpeg/1/trackID=0 RTSP/1.0 CSeq: 5 Authorization: Basic YWRtaW46YWRtaW4= User-Agent: openRTSP.exe (LIVE555 Streaming Media v2010.07.07) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Received 145 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 5 Server: SANYO RTSP Server Session: 00370932;timeout=60 Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode="PLAY" Setup "video/JPEG" subsession (client ports 49898-49899) Created output file: "_sanyo-tcp-2video-JPEG-1" Sending request: PLAY rtsp://192.168.3.75/VideoInput/1/jpeg/1 RTSP/1.0 CSeq: 6 Authorization: Basic YWRtaW46YWRtaW4= User-Agent: openRTSP.exe (LIVE555 Streaming Media v2010.07.07) Session: 00370932 Range: npt=0.000- Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Server: SANYO RTSP Server Session: 00370932 Range: npt=now- RTP-Info: url=VideoInput/1/jpeg/1/trackID=1;seq=1;rtptime=0 Started playing session Receiving streamed data... sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(1.025838->1278917071.379863) schedule(1.025086->1278917072.405915) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.052049->1278917074.459067) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.052058->1278917076.512183) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.051872->1278917078.565193) schedule(0.000056->1278917078.565310) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.051972->1278917080.618363) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.052033->1278917082.671521) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.052049->1278917084.724676) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.051986->1278917086.777710) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.052025->1278917088.830846) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.051975->1278917090.883915) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.051999->1278917092.936068) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.051975->1278917094.989158) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.052034->1278917097.042345) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.051990->1278917099.095418) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.052062->1278917101.148599) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.051958->1278917103.201604) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.051999->1278917105.253802) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.051953->1278917107.306847) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.051943->1278917109.358985) schedule(-0.000001->1278917109.359013) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: completed schedule(2.052011->1278917111.411215) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.052039->1278917113.464248) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.051988->1278917115.517313) schedule(0.000052->1278917115.517427) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.052017->1278917117.570468) schedule(0.000052->1278917117.570549) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.052014->1278917119.623567) schedule(0.000005->1278917119.623612) schedule(-0.000000->1278917119.623666) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.052100->1278917121.675883) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.052107->1278917123.728901) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.052102->1278917125.782022) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.051997->1278917127.835040) schedule(0.000004->1278917127.835078) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.052035->1278917129.887217) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.052071->1278917131.940335) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.052103->1278917133.993477) sending REPORT sending RTCP packet 80c90001 800043da 81ca0004 800043da 01084b61 6d696c2d 50430000 sendRTPOverTCP: 28 bytes over channel 1 (socket 76) sendRTPOverTCP: failed! schedule(2.052021->1278917136.046527) ^C -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamildobk at poczta.onet.pl Mon Jul 12 00:48:32 2010 From: kamildobk at poczta.onet.pl (Kamil Dobkowski) Date: Mon, 12 Jul 2010 09:48:32 +0200 Subject: [Live-devel] New LIVE555 release - fixes a problem with In-Reply-To: Message-ID: <73578E536DB74298AC87A5A3F7AA4C21@KamilPC> I attached Wireshark logs of my RTP session. OpenRTSP shows 'sendRTPOverTCP: failed!' because tcp connection is closed by my RTSP server after a few seconds. Regards, Kamil -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rtp_tcp.pcap Type: application/octet-stream Size: 89922 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rtp_tcp.txt URL: From kamildobk at poczta.onet.pl Mon Jul 12 05:49:27 2010 From: kamildobk at poczta.onet.pl (Kamil Dobkowski) Date: Mon, 12 Jul 2010 14:49:27 +0200 Subject: [Live-devel] New LIVE555 release - fixes a problem with In-Reply-To: Message-ID: Hi, I've played a bit with LiveMedia sources. I was able to improve TCP stream handling by checking network calls results against EWOULDBLOCK in two places : GroupsockHelper.cpp, readSocket(), line 243: #if defined(__WIN32__) || defined(_WIN32) || err == 0 || err == EWOULDBLOCK #else RTPInterface.cpp, void SocketDescriptor::tcpReadHandler1(int mask), line 369: if (result != 1) { // error reading TCP socket, or no more data available if (result < 0) { // error if ( fEnv.getErrno() != EWOULDBLOCK ) { fEnv.taskScheduler().turnOffBackgroundReadHandling(fOurSocketNum); // stops further calls to us } } return; } I don't know if it makes sense ( maybe these changes have some weird side effects ) but at least tcp is working better now. I'll let you know if I find something else. Regards, Kamil From kamildobk at poczta.onet.pl Mon Jul 12 06:49:24 2010 From: kamildobk at poczta.onet.pl (Kamil Dobkowski) Date: Mon, 12 Jul 2010 15:49:24 +0200 Subject: [Live-devel] New LIVE555 release - fixes a problem with In-Reply-To: Message-ID: Hi, I've just noticed that if you apply the first patch the second one will be unnesessary, because it does exactly the same the second time, so only the first patch makes sense. Kamil From marc.lambert at smardtv.com Mon Jul 12 09:36:16 2010 From: marc.lambert at smardtv.com (Lambert Marc) Date: Mon, 12 Jul 2010 18:36:16 +0200 Subject: [Live-devel] RTP packet lostwhenLive555MediaServerstreamsforward Dektec DTE3114 In-Reply-To: <6353CA579307224BAFDE9495906E691604D67DDC@ca-ops-mail> References: <6A8A31FCBF334D46904F2C962070EF3F019F9E26@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67C49@ca-ops-mail><6A8A31FCBF334D46904F2C962070EF3F019F9EC8@capella.hq.k.grp> <6353CA579307224BAFDE9495906E691604D67DDC@ca-ops-mail> Message-ID: <6A8A31FCBF334D46904F2C962070EF3F019F9F84@capella.hq.k.grp> Thank you, I'm going to do that and Dektec is also preparing a small log of what happening on the DTE-3114 side... Perhaps it is the way to treat the rtp packets on its side that causes the issue. ________________________________ De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de BONNEAU Guy Envoy? : lundi 12 juillet 2010 17:22 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTP packet lostwhenLive555MediaServerstreamsforward Dektec DTE3114 You shouldn't try to modify the code of the library unless you find a bug. The library send the packets at the appropriate time following the RTP specification unless the OS timer resolution create an issue. The library does indeed call the sendPacketIfNecessary routine to send the packets. >From what I remember the library does a good job at computing the time when the Mpeg2 TS RTP packets are to be sent. I suggest you try to use the function gettimeofday() to log the time and the delay requested when nextTask() = envir().taskScheduler().scheduleDelayedTask(...) is called in function sendPacketIfNecessary() in file MultiFramedTPSink. Then log the time again with gettimeofday() in function MultiFramedRTPSink::sendNext. Then check check that you were called at the time requested by the library scheduler. If you are not then you know the problem is likely to be a timer resolution issue with the OS. This is how I was able to find my issue and find why the library was bursting the RTP packets. GB From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Lambert Marc Sent: Monday, July 12, 2010 6:31 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 I just tried to modify the fDurationInMicroseconds but it doesn't work. Actually, It seems the task sends packet through "sendPacketIfNecessary" as soon as the packet is prepared when I would like to wait for 3 or 4 packets ready before to send them on the network. I tried to find a way to skip to send data but when I do that, it seems also than the packet is lost... It looks like the output buffer gathers frames and when there are enough frames to do a packet the RTP packet is done and sent, could I let prepare many packets and wait for few to effectively send them ? ________________________________ De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de BONNEAU Guy Envoy? : dimanche 11 juillet 2010 05:51 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTP packet lost when Live555MediaServerstreamsforward Dektec DTE3114 This problem seems to be very similar to one I have had about 1 year ago while trying to stream a Mpeg2 TS with the live555 library with a very high datarate. Unfortunately I do not remember all the details but I eventually pinpointed the problem to the scheduler of Windows. (My testing application was Windows based). If a remember the library would compute a delay to callback a routine to schedule a new RTP packet to be sent over the network. I believe that was done through a select or sleep() function. The computing of the delay was well done by the library. But the timer resolution of Windows is 15 or 10 ms by default and the requested delay in my case was much lower given the requested bitrate from the Mpeg2 TS stream. The jitter of the packets over the network was terrible and the library much of the time was trying to catch-up from the misbehavior of the Windows Timer default resolution of 15 ms by bursting the RTP packets over the network. I solved that problem by using the TimeBeginPeriod(1) to change the Windows period of the timer to 1 ms. The callback function would then wakeup much faster and the jitter of the packets went down to an acceptable level. Guy Bonneau Just to complet my explaination, please find the 2 IO Graphs Qvidium vs Live555 rtp streaming. Regards ________________________________ De : Lambert Marc Envoy? : vendredi 9 juillet 2010 15:35 ? : 'live-devel at lists.live555.com' Objet : RTP packet lost when Live555MediaServer streams forward Dektec DTE3114 Hello, First of all, I'm certainly not the first to say that but thank you for this very nice software. I use live555MediaServer in the context of my job and I compilled it with the option "RTSP_ALLOW_CLIENT_DESTINATION_SETTING" to make me able to control the server from a device connected on the network and to stream forward an IPtoTS modulator (DTE-3114 from Dektec) providing a DVB-C signal to a TV. My client is working well and everything is working perfectly with VLC but... When I replace VLC by the DTE-3114, the outgoing signal is not good with many RTP packet loss. Then, I tryed to change many parameters on each sides but nothing is fixing that. I also used the DTE-3114 with the QVidium file streamer (it doesn't have the rtsp server, just the rtp streamer) and, in that case, I succeed to stream perfectly until 25Mbps... I captured with Wireshark and there is a difference between the 2 streaming methodes, the Qvidium seems to allow more time before to send the next frame and the frame is composed of many UDP packet when Live555 try to gather perfectly the packets during the time and I guess it is stressing too much the DTE-3114 to treat this bandwidth on the fly. Then, I would like to know if it is possible to change the way to send packet on the network to try to make my test bench working. Thank's in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 12 11:57:47 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 12 Jul 2010 15:57:47 -0300 Subject: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 In-Reply-To: <6353CA579307224BAFDE9495906E691604D67DDC@ca-ops-mail> References: <6A8A31FCBF334D46904F2C962070E F3F019F9E26@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67C49@ca- ops-mail> <6A8A31FCBF334D46904F2C962070EF3F019F9EC8@capella.hq.k.grp> <6353CA579307224BAFDE9495906E691604D67DDC@ca-ops-mail> Message-ID: >You shouldn't try to modify the code of the library unless you find a bug. Yes, thank you Guy! > The library send the packets at the appropriate time following the >RTP specification unless the OS timer resolution create an issue. Marc, what OS are you using? If you are using Windows, then it's likely that your timer's resolution is too coarse; I've seen other people (not just Guy) who have had this problem with Windows. (Personally, I don't understand why anyone uses Windows to run an embedded system. Unix (including Linux) systems are much much better for this purpose.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jul 12 16:51:51 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 12 Jul 2010 20:51:51 -0300 Subject: [Live-devel] New LIVE555 release - fixes a problem with In-Reply-To: References: Message-ID: >I've just noticed that if you apply the first patch the second one >will be unnesessary, because it does exactly the same the second >time, so only the first patch makes sense. OK, if the first patch overcomes the problems that you were having with RTP-over-TCP in Windows (there doesn't seem to be a problem with other OSs), then I'll add it to the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From marc.lambert at smardtv.com Tue Jul 13 00:17:37 2010 From: marc.lambert at smardtv.com (Lambert Marc) Date: Tue, 13 Jul 2010 09:17:37 +0200 Subject: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 In-Reply-To: References: <6A8A31FCBF334D46904F2C962070EF3F019F9E26@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67C49@ca-ops-mail> <6A8A31FCBF334D46904F2C962070EF3F019F9EC8@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67DDC@ca-ops-mail> Message-ID: <6A8A31FCBF334D46904F2C962070EF3F019F9FE6@capella.hq.k.grp> I'm using windows because we also use several application all done on windows !!! I fully agree with you about the weakness of this OS but it's like that and I don't really have choice. On the other hand, I have the chance to be able to compare 2 kind of streaming and I tried to reproduce the behavior of the Qvidium with Live555 and it is true than nothing fix the problem. I also confirm I share with you than the code of the library is correct and then I have better time to keep it in this state. By the way and since I did not clearly identified the bug, I'm going to wait for ther Dektec log to understand wich kind of packets are lost on the DTE-3114 side and to get their explaination, perhaps it will be easy to fix and I will forward my conclusion. Thank you again for your help, it helped me to better understand the library architecture. -----Message d'origine----- De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : lundi 12 juillet 2010 20:58 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 >You shouldn't try to modify the code of the library unless you find a bug. Yes, thank you Guy! > The library send the packets at the appropriate time following the >RTP specification unless the OS timer resolution create an issue. Marc, what OS are you using? If you are using Windows, then it's likely that your timer's resolution is too coarse; I've seen other people (not just Guy) who have had this problem with Windows. (Personally, I don't understand why anyone uses Windows to run an embedded system. Unix (including Linux) systems are much much better for this purpose.) -- 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 sagi at netvision.net.il Tue Jul 13 05:39:10 2010 From: sagi at netvision.net.il (Sagi Ben Moshe) Date: Tue, 13 Jul 2010 15:39:10 +0300 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: References: <000001cb1edf$910e39c0$b32aad40$@net.il> <001f01cb1f2f$5369aeb0$fa3d0c10$@net.il> <004b01cb207c$ee6bb220$cb431660$@net.il> <006401cb20e2$7ddec400$799c4c00$@net.il> Message-ID: <00a801cb2288$64cdd9e0$2e698da0$@net.il> Hi Ross, We are checking for audio stream support with Live555 and we would like to know if we can stream the following codec AAC-LC and/or AAC-HE through the library. Thanks, Sagi -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Sunday, July 11, 2010 4:21 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Live555 Streaming from a live source >For the next stage we would like to use H264 codec, so I think we should >write our own H264VideoStreamDiscreteFramer, is it correct? Yes, you need to write your own subclass of "H264VideoStreamFramer"; see http://www.live555.com/liveMedia/faq.html#h264-streaming -- 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 marc.lambert at smardtv.com Tue Jul 13 08:58:07 2010 From: marc.lambert at smardtv.com (Lambert Marc) Date: Tue, 13 Jul 2010 17:58:07 +0200 Subject: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 In-Reply-To: References: <6A8A31FCBF334D46904F2C962070EF3F019F9E26@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67C49@ca-ops-mail> <6A8A31FCBF334D46904F2C962070EF3F019F9EC8@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67DDC@ca-ops-mail> Message-ID: <6A8A31FCBF334D46904F2C962070EF3F019FA0F8@capella.hq.k.grp> At last, I have an answer from dektec supprt. Actually, it's clear than the .ts file is correct and the PCR is perfect, the outgoing RTP packet are also perfect but there is a very small mismatching between the bandwidth and the PCR during approximativelly 75 seconds afterwhat the bandwidth and the PCR match. We have tryed with many files and it seems to be all the time the case. I also pinpoint than the DTE-3114 doesn't treat the RTP header, actually, it works like it would receive UDP packets, then it only referrence is the TS PCR and the broadcasting is only done with it. It explains why there is a buffer overflow sometimes until the PCR and the RTP bandwidth match. Then, I would like to know how to do to speed up the bandwidth computation from the PCR because it is approximativelly computed at the beginning and it take many seconds to decrease forward the correct bandwidth by about 100KHz steps. I'm going to try on my side to touch the algorism using NEW_DURATION_WEIGHT and TIME_ADJUSTMENT_FACTOR but I'm not sure to well understand how it works. -----Message d'origine----- De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : lundi 12 juillet 2010 20:58 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 >You shouldn't try to modify the code of the library unless you find a bug. Yes, thank you Guy! > The library send the packets at the appropriate time following the >RTP specification unless the OS timer resolution create an issue. Marc, what OS are you using? If you are using Windows, then it's likely that your timer's resolution is too coarse; I've seen other people (not just Guy) who have had this problem with Windows. (Personally, I don't understand why anyone uses Windows to run an embedded system. Unix (including Linux) systems are much much better for this purpose.) -- 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 marc.lambert at smardtv.com Tue Jul 13 09:37:02 2010 From: marc.lambert at smardtv.com (Lambert Marc) Date: Tue, 13 Jul 2010 18:37:02 +0200 Subject: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 In-Reply-To: References: <6A8A31FCBF334D46904F2C962070EF3F019F9E26@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67C49@ca-ops-mail> <6A8A31FCBF334D46904F2C962070EF3F019F9EC8@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67DDC@ca-ops-mail> Message-ID: <6A8A31FCBF334D46904F2C962070EF3F019FA10D@capella.hq.k.grp> After some new tests, if I modify NEW_DURATION_WEIGHT, TIME_ADJUSTMENT_FACTOR or PCR_PERIOD_VARIATION_RATIO, nothing becomes right but I defined DEBUG_PCR and when macroblocks happen, I can see a variation on the estimation of the PCR. Most of the time, it is at 162 and regularly it decreases at 108, then increases at 268 and comes back at 162. "this duration" stays at 162 all the time... Do you know what it means ? -----Message d'origine----- De : Lambert Marc Envoy? : mardi 13 juillet 2010 17:58 ? : LIVE555 Streaming Media - development & use Objet : RE: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 At last, I have an answer from dektec supprt. Actually, it's clear than the .ts file is correct and the PCR is perfect, the outgoing RTP packet are also perfect but there is a very small mismatching between the bandwidth and the PCR during approximativelly 75 seconds afterwhat the bandwidth and the PCR match. We have tryed with many files and it seems to be all the time the case. I also pinpoint than the DTE-3114 doesn't treat the RTP header, actually, it works like it would receive UDP packets, then it only referrence is the TS PCR and the broadcasting is only done with it. It explains why there is a buffer overflow sometimes until the PCR and the RTP bandwidth match. Then, I would like to know how to do to speed up the bandwidth computation from the PCR because it is approximativelly computed at the beginning and it take many seconds to decrease forward the correct bandwidth by about 100KHz steps. I'm going to try on my side to touch the algorism using NEW_DURATION_WEIGHT and TIME_ADJUSTMENT_FACTOR but I'm not sure to well understand how it works. -----Message d'origine----- De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : lundi 12 juillet 2010 20:58 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 >You shouldn't try to modify the code of the library unless you find a bug. Yes, thank you Guy! > The library send the packets at the appropriate time following the >RTP specification unless the OS timer resolution create an issue. Marc, what OS are you using? If you are using Windows, then it's likely that your timer's resolution is too coarse; I've seen other people (not just Guy) who have had this problem with Windows. (Personally, I don't understand why anyone uses Windows to run an embedded system. Unix (including Linux) systems are much much better for this purpose.) -- 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 marc.lambert at smardtv.com Tue Jul 13 10:43:39 2010 From: marc.lambert at smardtv.com (Lambert Marc) Date: Tue, 13 Jul 2010 19:43:39 +0200 Subject: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 In-Reply-To: <6A8A31FCBF334D46904F2C962070EF3F019FA10D@capella.hq.k.grp> References: <6A8A31FCBF334D46904F2C962070EF3F019F9E26@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67C49@ca-ops-mail> <6A8A31FCBF334D46904F2C962070EF3F019F9EC8@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67DDC@ca-ops-mail> <6A8A31FCBF334D46904F2C962070EF3F019FA10D@capella.hq.k.grp> Message-ID: <6A8A31FCBF334D46904F2C962070EF3F019FA117@capella.hq.k.grp> YES !!! At last, I found how to do, I reduced MAX_PLAYOUT_BUFFER_DURATION from 0.1 to 0.001 second and it works fine. Actually, the value at 0.1 allows to have a gap about 100ms between the estimated rate and the output rate, it is too high for the DTE-3114. With this value at 0.001, the computation turns all the time around 0 (from -0.005 to 0.005) and it is perfect. -----Message d'origine----- De : Lambert Marc Envoy? : mardi 13 juillet 2010 18:37 ? : Lambert Marc; 'LIVE555 Streaming Media - development & use' Objet : RE: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 After some new tests, if I modify NEW_DURATION_WEIGHT, TIME_ADJUSTMENT_FACTOR or PCR_PERIOD_VARIATION_RATIO, nothing becomes right but I defined DEBUG_PCR and when macroblocks happen, I can see a variation on the estimation of the PCR. Most of the time, it is at 162 and regularly it decreases at 108, then increases at 268 and comes back at 162. "this duration" stays at 162 all the time... Do you know what it means ? -----Message d'origine----- De : Lambert Marc Envoy? : mardi 13 juillet 2010 17:58 ? : LIVE555 Streaming Media - development & use Objet : RE: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 At last, I have an answer from dektec supprt. Actually, it's clear than the .ts file is correct and the PCR is perfect, the outgoing RTP packet are also perfect but there is a very small mismatching between the bandwidth and the PCR during approximativelly 75 seconds afterwhat the bandwidth and the PCR match. We have tryed with many files and it seems to be all the time the case. I also pinpoint than the DTE-3114 doesn't treat the RTP header, actually, it works like it would receive UDP packets, then it only referrence is the TS PCR and the broadcasting is only done with it. It explains why there is a buffer overflow sometimes until the PCR and the RTP bandwidth match. Then, I would like to know how to do to speed up the bandwidth computation from the PCR because it is approximativelly computed at the beginning and it take many seconds to decrease forward the correct bandwidth by about 100KHz steps. I'm going to try on my side to touch the algorism using NEW_DURATION_WEIGHT and TIME_ADJUSTMENT_FACTOR but I'm not sure to well understand how it works. -----Message d'origine----- De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : lundi 12 juillet 2010 20:58 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 >You shouldn't try to modify the code of the library unless you find a bug. Yes, thank you Guy! > The library send the packets at the appropriate time following the >RTP specification unless the OS timer resolution create an issue. Marc, what OS are you using? If you are using Windows, then it's likely that your timer's resolution is too coarse; I've seen other people (not just Guy) who have had this problem with Windows. (Personally, I don't understand why anyone uses Windows to run an embedded system. Unix (including Linux) systems are much much better for this purpose.) -- 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 Wed Jul 14 07:06:28 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Jul 2010 11:06:28 -0300 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: <00a801cb2288$64cdd9e0$2e698da0$@net.il> References: <000001cb1edf$910e39c0$b32aad40$@net.il> <001f01cb1f2f$5369aeb0$fa3d0c10$@net.il> <004b01cb207c$ee6bb220$cb431660$@net.il> <006401cb20e2$7ddec400$799c4c00$@net.il> <00a801cb2288$64cdd9e0$2e698da0$@net.il> Message-ID: >We are checking for audio stream support with Live555 and we would like to >know if we can stream the following codec >AAC-LC and/or AAC-HE through the library. Yes, you can do so using a "MPEG4GenericRTPSink", created with appropriate parameters to specify AAC audio. (Note, for example, how "ADTSAudioFileServerMediaSubsession" streams AAC audio that comes from an ADTS-format file.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From cataldi.alessandro at gmail.com Wed Jul 14 03:43:35 2010 From: cataldi.alessandro at gmail.com (Alessandro Cataldi) Date: Wed, 14 Jul 2010 12:43:35 +0200 Subject: [Live-devel] Starting point to build a relaying infrastructure of RTP streams Message-ID: Hi everybody, I'm facing the following challange: suppose we have two hosts, R (a host with satellite equipment) and H (no satellite equipment). R receive multiple streams (we can consider them "tv channels") and must be able to forward these streams (or some of them) to host H. H can then play locally the received streams and, in the meanwhile, forward them to another host H2 (and so on). Considering that R, H and H2 are, generally, behind a NAT box that hides their public addresses (problems with parity checks of RTP ports?)... what do you suggest as a starting point strategy, using the LIVE555? Thanks in advance, Alessandro Cataldi -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 14 09:50:16 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Jul 2010 13:50:16 -0300 Subject: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 In-Reply-To: <6A8A31FCBF334D46904F2C962070EF3F019FA117@capella.hq.k.grp> References: <6A8A31FCBF334D46904F2C962070E F3F019F9E26@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67C49@ca- ops-mail> <6A8A31FCBF334D46904F2C962070EF3F019F9EC8@capella.hq.k.grp><6353CA57930722 4BAFDE9495906E691604D67DDC@ca-ops-mail> <6A8A31FCBF334D46904F2C962070EF3F019FA10D@capella.hq.k.grp> <6A8A31FCBF334D46904F2C962070EF3F019FA117@capella.hq.k.grp> Message-ID: >YES !!! > >At last, I found how to do, I reduced MAX_PLAYOUT_BUFFER_DURATION >from 0.1 to 0.001 second and it works fine. >Actually, the value at 0.1 allows to have a gap about 100ms between >the estimated rate and the output rate, it is too high for the >DTE-3114. I find it amazing that in this day and age (when RAM memory is extremely cheap) a product would be built with so little internal buffer memory... >With this value at 0.001, the computation turns all the time around >0 (from -0.005 to 0.005) and it is perfect. The current value (0.1 seconds, i.e., 100 ms) has been in place since November 2005, and (as far as I know) has worked fine for everyone since then. However, if noone sees any problem with changing MAX_PLAYOUT_BUFFER_DURATION to 0.001 (i.e., 1 ms) in the released software, then I'll go ahead and do this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From marc.lambert at smardtv.com Thu Jul 15 00:24:33 2010 From: marc.lambert at smardtv.com (Lambert Marc) Date: Thu, 15 Jul 2010 09:24:33 +0200 Subject: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 In-Reply-To: References: <6A8A31FCBF334D46904F2C962070EF3F019F9E26@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67C49@ca-ops-mail><6A8A31FCBF334D46904F2C962070EF3F019F9EC8@capella.hq.k.grp><6353CA579307224BAFDE9495906E691604D67DDC@ca-ops-mail><6A8A31FCBF334D46904F2C962070EF3F019FA10D@capella.hq.k.grp><6A8A31FCBF334D46904F2C962070EF3F019FA117@capella.hq.k.grp> Message-ID: <6A8A31FCBF334D46904F2C962070EF3F019FA2A5@capella.hq.k.grp> Actually, in my use case, I have the RTSP controller on another IP adress than the RTP receiver, furthermore, the RTP receiver doesn't handle the RTCP feed back then I guess the server is not aware about the lost packets and the difference of speed between the RTP flow and the TS flow... It is not a real RTSP case and there is not a feedback loop and it is on the same model than UDP TS transmission. It explain than even if the DTE-3114 has 120ms of input buffer, it is not able to compensate the difference generated by the PCR computation. I think the current algorism stays correct for all other application than this specific one, I mean UDP transmission and Simple RTP transmission. Since my first test with the new value of MAX_PLAYOUT_BUFFER_DURATION, I tested many kind of streams and bitrate and everything work perfectly, then it is the conclusion for this topic. Thank's again for your help -----Message d'origine----- De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : mercredi 14 juillet 2010 18:50 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 >YES !!! > >At last, I found how to do, I reduced MAX_PLAYOUT_BUFFER_DURATION >from 0.1 to 0.001 second and it works fine. >Actually, the value at 0.1 allows to have a gap about 100ms between >the estimated rate and the output rate, it is too high for the >DTE-3114. I find it amazing that in this day and age (when RAM memory is extremely cheap) a product would be built with so little internal buffer memory... >With this value at 0.001, the computation turns all the time around >0 (from -0.005 to 0.005) and it is perfect. The current value (0.1 seconds, i.e., 100 ms) has been in place since November 2005, and (as far as I know) has worked fine for everyone since then. However, if noone sees any problem with changing MAX_PLAYOUT_BUFFER_DURATION to 0.001 (i.e., 1 ms) in the released software, then I'll go ahead and do 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 tjtngh at naver.com Thu Jul 15 01:33:30 2010 From: tjtngh at naver.com (=?EUC-KR?B?vK289sij?=) Date: Thu, 15 Jul 2010 17:33:30 +0900 Subject: [Live-devel] =?euc-kr?q?Hello=2C_I_have_found_some_problem_after_?= =?euc-kr?q?i_ran_the_openRTSP_program_like_=22openRTSP_=3Crtsp_lin?= =?euc-kr?q?k=3E=22_in_lin?= Message-ID: Hello, Live Networks Manager. My name is SEO SUHO. I am developing the some program with openRTSP source. I have found some problem after i ran the openRTSP program like "openRTSP " in linux environment. First, I confirmed that there are the "audio-MP4A-LATM", "video-MP4V-ES" files in my folder after i ran the openRTSP program in my linux environment. video-MP4V-ES file don't have problem when i execute the file in vlc media player. But the main problem is that i can't hear the sound when i execute the audio-MP4A-LATM file in vlc media player. I think that openRTSP source can support the codec about MP4A-LATM, MP4V-ES. therefore, I don't know why this problem is caused. I would like to thank you if you give me some help. have a nice day. Sincerely, SH, SEO -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 15 01:57:39 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Jul 2010 05:57:39 -0300 Subject: [Live-devel] Hello, I have found some problem after i ran the openRTSP program like "openRTSP " in lin In-Reply-To: References: Message-ID: >I have found some problem after i ran the openRTSP program like >"openRTSP " in linux environment. > >First, I confirmed that there are the "audio-MP4A-LATM", >"video-MP4V-ES" files in my folder after i >ran the openRTSP program in my linux environment. > >video-MP4V-ES file don't have problem when i execute the file in >vlc media player. > >But the main problem is that i can't hear the sound when i execute >the audio-MP4A-LATM file in vlc media player. This is a 'problem' with VLC, not with our software. "openRTSP" recorded the incoming MPEG-5 audio data just fine; however, VLC happens not to be able to play the recorded file. VLC is not our software. Questions about VLC should be sent to a VLC mailing list. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Paul.Corke at datatote.co.uk Thu Jul 15 02:14:59 2010 From: Paul.Corke at datatote.co.uk (Paul Corke) Date: Thu, 15 Jul 2010 10:14:59 +0100 Subject: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 Message-ID: <72D9E13A8FC8994794D448E91198AE0701A7153A@mail.sys.internal> On 14 July 2010 17:50, Ross Finlayson wrote: > > At last, I found how to do, I reduced MAX_PLAYOUT_BUFFER_DURATION > > from 0.1 to 0.001 second and it works fine. > > The current value (0.1 seconds, i.e., 100 ms) has been in place since > November 2005, and (as far as I know) has worked fine for everyone > since then. It doesn't work for me, I'm using: #define NEW_DURATION_WEIGHT 0.05 #define MAX_PLAYOUT_BUFFER_DURATION 0.25 // (seconds) Because we were seeing (sometimes) some packets being sent out too late. I think this was because not every packet has a PCR value on it, so the fTSPacketDurationEstimate was going wrong quickly. Part of the solution was to increase the MAX_PLAY_BUF_DUR so that the STB had a larger buffer to work around the resulting jitter. As we patch the library anyway (yes I'm aware of the "don't do it" rule) it wouldn't really affect us, but I thought I'd mention that 0.1 doesn't work for everyone. Paul. From finlayson at live555.com Thu Jul 15 19:29:12 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Jul 2010 23:29:12 -0300 Subject: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 In-Reply-To: <72D9E13A8FC8994794D448E91198AE0701A7153A@mail.sys.internal> References: <72D9E13A8FC8994794D448E91198AE0701A7153A@mail.sys.internal> Message-ID: > > The current value (0.1 seconds, i.e., 100 ms) has been in place since >> November 2005, and (as far as I know) has worked fine for everyone >> since then. > >It doesn't work for me, I'm using: > > #define NEW_DURATION_WEIGHT 0.05 > > #define MAX_PLAYOUT_BUFFER_DURATION 0.25 // (seconds) > >Because we were seeing (sometimes) some packets being sent out too >late. I think this was because not every packet has a PCR value >on it, so the fTSPacketDurationEstimate was going wrong quickly. >Part of the solution was to increase the MAX_PLAY_BUF_DUR so that >the STB had a larger buffer to work around the resulting jitter. > >As we patch the library anyway (yes I'm aware of the "don't do >it" rule) it wouldn't really affect us, but I thought I'd mention >that 0.1 doesn't work for everyone. OK, here's what I'll do: I'll put #ifndef #endif around each of the four constant definitions. That way, if anyone wants to change them, they can do so with their own definitions before including any of the liveMedia header files. Then they won't need to patch the supplied source code at all. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Norbert.Donath at keynote-sigos.com Fri Jul 16 07:27:01 2010 From: Norbert.Donath at keynote-sigos.com (Norbert Donath) Date: Fri, 16 Jul 2010 16:27:01 +0200 Subject: [Live-devel] Stream cutoff because openRTSP ignores timeout in Session header Message-ID: <20100716142701.GA3879@sigoslx210.sigos.de> Hello Ross, We currently discovered a problem when we used openRTSP to download a stream. The server includes a timeout parameter in the Session header but openRTSP ignores it. The timeout is set to 50 s and after 60 s play time the server stops sending RTP packets and sends TCP-RST on the RTSP port. Of course, the RTCP RRs are sent from openRTSP and we know that they are recieved on the server. However, it's not enough as keep-alive indication. Here is the output of wireshark of such a case (I know, you only provide support for unmodified sources but we had to patch the User-Agent to get it running): OPTIONS rtsp://10.135.20.82:554/live/free/83876346194768/TRT1_h264.3gp RTSP/1.0 CSeq: 1 User-Agent: BlackBerry9000/4.6.0.266 Profile/MIDP-2.0 Configuration/CLDC-1.1 VendorID/238 RTSP/1.0 200 OK CSeq: 1 Date: Wed, 14 Jul 2010 05:06:29 GMT Server: XenonStreamer/5.0.1.3573 ("Linux 2.6.18-128.el5PAE (i686)") Public: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN Supported: play.basic, con.persistent DESCRIBE rtsp://10.135.20.82:554/live/free/83876346194768/TRT1_h264.3gp RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: BlackBerry9000/4.6.0.266 Profile/MIDP-2.0 Configuration/CLDC-1.1 VendorID/238 RTSP/1.0 200 OK CSeq: 2 Date: Wed, 14 Jul 2010 05:06:30 GMT Expires: Fri, 13 Aug 2010 05:06:30 GMT Content-Type: application/sdp Content-Base: rtsp://10.135.20.82:554/live/free/83876346194768/TRT1_h264.3gp/ Content-Language: en-US Supported: play.basic, con.persistent Content-Length: 786 Server: XenonStreamer/5.0.1.3573 ("Linux 2.6.18-128.el5PAE (i686)") v=0 o=- 985824842 1279083989 IN IP4 10.135.20.82 s=TRT1_h264 c=IN IP4 0.0.0.0 t=0 0 a=control:rtsp://10.135.20.82:554/live/free/83876346194768/TRT1_h264.3gp a=range:npt=0.000000- a=X-Disallowrandomaccess a=random_access_denied m=video 0 RTP/AVP 105 b=AS:34 b=TIAS:34000 b=RS:480 b=RR:640 a=maxprate:15.00 a=range:npt=0.000000- a=rtpmap:105 H264/90000 a=control:trackID=11 a=fmtp:105 profile-level-id=42E00C;sprop-parameter-sets=Z0LgDJZUCg/I,aM4BrFCA;packetization-mode=1 a=framesize:105 320-240 a=cliprect:0,0,240,320 m=audio 0 RTP/AVP 110 b=AS:20 b=TIAS:20000 b=RS:480 b=RR:500 a=maxprate:36.00 a=range:npt=0.000000- a=rtpmap:110 MP4A-LATM/24000/1 a=control:trackID=12 a=fmtp:110 profile-level-id=15;object=2;cpresent=0;config=400026103FC0;SBR-enabled=1 SETUP rtsp://10.135.20.82:554/live/free/83876346194768/TRT1_h264.3gp/trackID=11 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=48742-48743;mode="PLAY" User-Agent: BlackBerry9000/4.6.0.266 Profile/MIDP-2.0 Configuration/CLDC-1.1 VendorID/238 RTSP/1.0 200 OK CSeq: 3 Cache-Control: must-revalidate Date: Wed, 14 Jul 2010 05:06:30 GMT Session: 985824842;timeout=50 Transport: RTP/AVP;unicast;client_port=48742-48743;server_port=34828-34829;source=10.135.20.82;destination=10.163.22.162;ssrc=dadfd607 Server: XenonStreamer/5.0.1.3573 ("Linux 2.6.18-128.el5PAE (i686)") SETUP rtsp://10.135.20.82:554/live/free/83876346194768/TRT1_h264.3gp/trackID=12 RTSP/1.0 CSeq: 4 Transport: RTP/AVP;unicast;client_port=41546-41547;mode="PLAY" Session: 985824842 User-Agent: BlackBerry9000/4.6.0.266 Profile/MIDP-2.0 Configuration/CLDC-1.1 VendorID/238 RTSP/1.0 200 OK CSeq: 4 Cache-Control: must-revalidate Date: Wed, 14 Jul 2010 05:06:30 GMT Session: 985824842;timeout=50 Transport: RTP/AVP;unicast;client_port=41546-41547;server_port=34830-34831;source=10.135.20.82;destination=10.163.22.162;ssrc=dd78f640 Server: XenonStreamer/5.0.1.3573 ("Linux 2.6.18-128.el5PAE (i686)") PLAY rtsp://10.135.20.82:554/live/free/83876346194768/TRT1_h264.3gp RTSP/1.0 CSeq: 5 Session: 985824842 Range: npt=0.000- User-Agent: BlackBerry9000/4.6.0.266 Profile/MIDP-2.0 Configuration/CLDC-1.1 VendorID/238 RTSP/1.0 200 OK CSeq: 5 Date: Wed, 14 Jul 2010 05:06:30 GMT Session: 985824842;timeout=50 Server: XenonStreamer/5.0.1.3573 ("Linux 2.6.18-128.el5PAE (i686)") Range: npt=0.0000- RTP-Info: url=rtsp://10.135.20.82:554/live/free/83876346194768/TRT1_h264.3gp/trackID=11;seq=0;rtptime=0 ,url=rtsp://10.135.20.82:554/live/free/83876346194768/TRT1_h264.3gp/trackID=12;seq=0;rtptime=0 RTCP-Interval: 1000 I saw in the changelog that in 2006 you added parsing the timeout parameter of the Session header and the sessionTimeoutParameter() function. However, openRTSP doesn't use it. Is this a bug or intended behaviour? I think that in chapter 12.37 of RfC 2326 sending RTSP requests as keep-alive with the value of the timeout parameter is not optional. Is this correct? Best Regards, Norbert Donath PS: Are you interested in a patch that allows to set the User-Agent header in openRTSP on the command line? In our experience in mobile networks it's only possible to get a reasonable stream quality if the User-Agent matches one of some known mobile types. -- 20 years - Keynote SIGOS GmbH - 1989 - 2009 Keynote SIGOS GmbH - TESTING IS OUR COMPETENCE - Klingenhofstrasse 50d D-90411 Nuernberg Fon +49 911 95168-0 www.keynote-sigos.com HRB 9323 Nuernberg Gerichtsstand: Nuernberg Geschaeftsfuehrer: Adil Kaya, Martin Loehlein, Umang Gupta, Andrew Hamer From finlayson at live555.com Fri Jul 16 08:05:04 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 16 Jul 2010 12:05:04 -0300 Subject: [Live-devel] Stream cutoff because openRTSP ignores timeout in Session header In-Reply-To: <20100716142701.GA3879@sigoslx210.sigos.de> References: <20100716142701.GA3879@sigoslx210.sigos.de> Message-ID: >We currently discovered a problem when we used openRTSP to download a >stream. The server includes a timeout parameter in the Session header >but openRTSP ignores it. The timeout is set to 50 s and after 60 s >play time the server stops sending RTP packets and sends TCP-RST on >the RTSP port. Of course, the RTCP RRs are sent from openRTSP and we >know that they are recieved on the server. However, it's not enough as >keep-alive indication. Then that's a problem with the server; it should be using these incoming RTCP "RR"s as a 'keep-alive'. >I saw in the changelog that in 2006 you added parsing the timeout >parameter of the Session header and the sessionTimeoutParameter() >function. However, openRTSP doesn't use it. Is this a bug or intended >behaviour? Intended behavior. The standard mechanism by which servers detect the continued liveness of clients is via RTCP "RR"s. Note that the intention of the "timeout" parameter in the RTSP "SETUP" response is to indicate how long the server can wait after the last detection of client liveness before closing the session. It is *not* intended to indicate the desired frequency of some alternative 'keep-alive' mechanism (such as sending periodic "GET_PARAMETER" requests, for example). I think that VLC, however, might be using the "timeout" parameter this way (as the frequency for sending "GET_PARAMETER" requests). However, this is non-standard, and there are no plans to do this for "openRTSP". (It might conceivable be added as an option (i.e., not default behavior) sometime in the future, but this would be low-priority, as is support for non-standards-complant servers in general.) >PS: Are you interested in a patch that allows to set the User-Agent >header in openRTSP on the command line? In our experience in mobile >networks it's only possible to get a reasonable stream quality if the >User-Agent matches one of some known mobile types. Mumble... I detest the idea that some servers may be modifying their behavior based on the client's "User-Agent" field. Can you give some examples of this? However, I might consider a patch for setting the "User-Agent" field in "openRTSP", because it should be quite simple (because there's already a function "RTSPClient::setUserAgentString()" for doing this). I suggest using the "-U" (upper-case) option for this. If you make a patch, be sure to do so against the latest version of the code - 2010.07.13 - because "openRTSP" has undergone extensive changes in that version (to use the new asynchronous RTSPClient interface exclusively). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From tjtngh at naver.com Fri Jul 16 21:39:48 2010 From: tjtngh at naver.com (=?EUC-KR?B?vK289sij?=) Date: Sat, 17 Jul 2010 13:39:48 +0900 Subject: [Live-devel] =?euc-kr?q?I_have_tested_the_audio-MP4A-LATM_in_many?= =?euc-kr?q?_player=2C_but_we_can=27t_execute_the_MP4A-LATM_in_any_?= =?euc-kr?q?player=2E?= Message-ID: <43fca0d29f82f2d6a64513d89d29c5af@tweb25-2.nm> Thank you for your rapid reply. You have sayed that "This is a 'problem' with VLC, not with our software. "openRTSP" recorded the incoming MPEG-5 audio data just fine; however, VLC happens not to be able to play the recorded file." So, I tested the audio-MP4A-LATM in many player, but I can't execute the MP4A-LATM in any player. For example, window media player, goam player, alsong player, 3GP player and so on. Therefore, I would like to take a test about audio-MP4A-LATM in available player. I would like to thank you if you tell me available player download site or player name. have a nice day. Sincerely, SH SEO Message: 4 Date: Thu, 15 Jul 2010 05:57:39 -0300 From: Ross Finlayson <finlayson at live555.com> Subject: Re: [Live-devel] Hello, I have found some problem after i ran the openRTSP program like "openRTSP " in lin To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com> Message-ID: <f06240802c8647d5dde70@[66.80.62.44]> Content-Type: text/plain; charset="us-ascii" ; format="flowed" >I have found some problem after i ran the openRTSP program like >"openRTSP " in linux environment. > >First, I confirmed that there are the "audio-MP4A-LATM", >"video-MP4V-ES" files in my folder after i >ran the openRTSP program in my linux environment. > >video-MP4V-ES file don't have problem when i execute the file in >vlc media player. > >But the main problem is that i can't hear the sound when i execute >the audio-MP4A-LATM file in vlc media player. This is a 'problem' with VLC, not with our software. "openRTSP" recorded the incoming MPEG-5 audio data just fine; however, VLC happens not to be able to play the recorded file. VLC is not our software. Questions about VLC should be sent to a VLC mailing list. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjtngh at naver.com Fri Jul 16 21:39:48 2010 From: tjtngh at naver.com (=?EUC-KR?B?vK289sij?=) Date: Sat, 17 Jul 2010 13:39:48 +0900 Subject: [Live-devel] =?euc-kr?q?I_have_tested_the_audio-MP4A-LATM_in_many?= =?euc-kr?q?_player=2C_but_we_can=27t_execute_the_MP4A-LATM_in_any_?= =?euc-kr?q?player=2E?= Message-ID: <43fca0d29f82f2d6a64513d89d29c5af@tweb25-2.nm> Thank you for your rapid reply. You have sayed that "This is a 'problem' with VLC, not with our software. "openRTSP" recorded the incoming MPEG-5 audio data just fine; however, VLC happens not to be able to play the recorded file." So, I tested the audio-MP4A-LATM in many player, but I can't execute the MP4A-LATM in any player. For example, window media player, goam player, alsong player, 3GP player and so on. Therefore, I would like to take a test about audio-MP4A-LATM in available player. I would like to thank you if you tell me available player download site or player name. have a nice day. Sincerely, SH SEO Message: 4 Date: Thu, 15 Jul 2010 05:57:39 -0300 From: Ross Finlayson <finlayson at live555.com> Subject: Re: [Live-devel] Hello, I have found some problem after i ran the openRTSP program like "openRTSP " in lin To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com> Message-ID: <f06240802c8647d5dde70@[66.80.62.44]> Content-Type: text/plain; charset="us-ascii" ; format="flowed" >I have found some problem after i ran the openRTSP program like >"openRTSP " in linux environment. > >First, I confirmed that there are the "audio-MP4A-LATM", >"video-MP4V-ES" files in my folder after i >ran the openRTSP program in my linux environment. > >video-MP4V-ES file don't have problem when i execute the file in >vlc media player. > >But the main problem is that i can't hear the sound when i execute >the audio-MP4A-LATM file in vlc media player. This is a 'problem' with VLC, not with our software. "openRTSP" recorded the incoming MPEG-5 audio data just fine; however, VLC happens not to be able to play the recorded file. VLC is not our software. Questions about VLC should be sent to a VLC mailing list. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 16 23:45:47 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 17 Jul 2010 03:45:47 -0300 Subject: [Live-devel] I have tested the audio-MP4A-LATM in many player, but we can't execute the MP4A-LATM in any player. In-Reply-To: <43fca0d29f82f2d6a64513d89d29c5af@tweb25-2.nm> References: <43fca0d29f82f2d6a64513d89d29c5af@tweb25-2.nm> Message-ID: First, do not send the same message to the mailing list more than once! >You have sayed that "This is a 'problem' with VLC, not with our >software. "openRTSP" >recorded the incoming MPEG-[4] audio data just fine; however, VLC >happens not to be able to play the recorded file." > > > >So, I tested the audio-MP4A-LATM in many player, but I can't execute >the MP4A-LATM in any player. > >For example, window media player, goam player, alsong player, 3GP >player and so on. "openRTSP" records the 'raw' incoming data (in this case, MPEG-4 audio) into a file, but does not necessarily leave the resulting file in a form which can be played 'as is' by a media playetr. For this data to be played by a media player, you must somehow tell it that it is LATM MPEG-4 audio. One way to do so is to simply have the media player play the "rtsp://" URL directly, i.e., without using "openRTSP". VLC supports this; just try having VLC play the "rtsp://" URL directly - i.e., run VLC rtsp://whatever Another way is to (somehow) turn the raw audio data file into a form which the media player will play. This may require adding some sort of file header, and/or changing the filename suffix, and is generally outside the scope of our software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at green-light.ca Sat Jul 17 09:59:27 2010 From: keith at green-light.ca (Keith Page) Date: Sat, 17 Jul 2010 09:59:27 -0700 Subject: [Live-devel] Seg Fault on VLC 1.1.0 Ubuntu 10.04 LTS Message-ID: <4C41E16F.3010608@green-light.ca> I just recompiled the latest stable vlc, x264 from the repo and the ffmpeg snapshot. When I shut down the recording of vlc I'm gettting segfaults that are tracing back to the live555 lib installed. http://pastebin.com/YE0b6ftg -- Green-Light Communications; Move Forward Green-Light Communications; Move Forward Keith Page, Chief Information Officer Phone: (403) 668-9184 Support Email: helpdesk at green-light.ca 911 Support: 911.support at green-light.ca Hours of Operation: 8am - 6pm -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 3NwHdNmwXu5yZ3U85CFgIMxHvrGExXyEHgMDwnfGLA8uIOQlVPnKWXapohfN6EY7+tGQjrSkJ32NIAAAOw== Type: image/gif Size: 2257 bytes Desc: not available URL: From polydeft+live555 at gmail.com Sat Jul 17 19:24:05 2010 From: polydeft+live555 at gmail.com (Jonathan Cole) Date: Sat, 17 Jul 2010 19:24:05 -0700 Subject: [Live-devel] openRTSP and triggered video clip from buffer Message-ID: Hello Live555 Devs, I've been looking into using openRTSP to store clips of video streamed from a video source. It works great using the command line, so I'm sure the software is capable with just minor changes to function exactly as I need it, I've just haven't had much luck narrowing down exactly where to look to make these changes. What I'd like to be able to do is have openRTSP buffer the video received from the source for, lets say 15 seconds, discarding older frames when full, and upon being signaled to do so outputs a video clip of its currently stored buffer. A few months back when I had tried fiddling around with openRTSP's code I managed to have it spit out the frames I needed in a playable file with improper headers resulting in a large gap at the beginning. It was kludgy and I dropped playing with it in favor of getting other stuff done. I'm looking to hack at it again and was wondering if anyone had any hints on where to start. Thanks for your time, -Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jul 18 06:25:49 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 18 Jul 2010 10:25:49 -0300 Subject: [Live-devel] Seg Fault on VLC 1.1.0 Ubuntu 10.04 LTS In-Reply-To: <4C41E16F.3010608@green-light.ca> References: <4C41E16F.3010608@green-light.ca> Message-ID: >I just recompiled the latest stable vlc, x264 from the repo and the >ffmpeg snapshot. When I shut down the recording of vlc I'm gettting >segfaults that are tracing back to the live555 lib installed. > >http://pastebin.com/YE0b6ftg Thanks for the report. Unfortunately it wasn't clear from the report exactly where the segmentation fault was happening in the "MediaSubsession::getNormalPlayTime()" function, and an inspection of the code suggests that this probably should not be happening *unless* it is being called on a "MediaSubsession" object pointer that has already been deleted (or is NULL). The fact that this error is occurring when you shut down VLC adds support to this. Therefore, my current suspicion is that the problem is not in our library, but instead in the VLC code ("modules_demux_live555.cpp") that is calling our library. I suggest that you contact the VLC developers (on a VLC mailing list), telling them about your segfault, and asking them it it's possible that "tk->sub->getNormalPlayTime(pts)" (in "modules_demux_live555.cpp") could be getting called on after "tk->sub" has already been deleted. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jul 18 06:28:53 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 18 Jul 2010 10:28:53 -0300 Subject: [Live-devel] openRTSP and triggered video clip from buffer In-Reply-To: References: Message-ID: I suggest replacing the use of "FileSink" in the VLC code with the use of some other "MediaSink" subclass - that you would write. Alternatively, if your stream is video-only, then you could redirect the output to 'stdout' - using the "-v" option - and then pipe "openRTSP" to a new application (that you would write) that reads from 'stdin'. That way, you won't need to modify the "openRTSP" code at all. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ilya.kogan at gmail.com Mon Jul 19 02:07:58 2010 From: ilya.kogan at gmail.com (Ilya Kogan) Date: Mon, 19 Jul 2010 11:07:58 +0200 Subject: [Live-devel] Slow-forward or frame-by-frame streaming of MPEG2 video from live555 to VLC Message-ID: Hi, I'm trying to stream MPEG-2 in slow motion and it doesn't work exactly as expected. My goal is to stream a 29.97-fps video stream 30 times slower, so that the VLC client will show one frame per second. What I see instead is 1 frame per 3 seconds, two thirds of the frames are skipped. My guess is that I only see the P-frames, and I don't see the B-frames, although they are transmitted. In order to achieve the slow motion effect, I changed the frame rate of MPEG1or2VideoStreamFramer from 29.97 to 1. The presentation time is computed accordingly, and so the sink requests one frame per second - which is exactly what I need. When I look at the stream in Wireshark, I see that indeed all frames are transmitted - one per second. But it seems that VLC just ignores the B-frames and only shows one frame every 3 seconds. Should I modify anything in one of the MPEG-2 headers in order to enable this feature? I'll be very grateful if you could give me some pointers. Ilya -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Stegbauer at acision.com Tue Jul 20 09:54:52 2010 From: David.Stegbauer at acision.com (Stegbauer, David) Date: Tue, 20 Jul 2010 18:54:52 +0200 Subject: [Live-devel] Which kind of code you would accept? Message-ID: <4171BB396C058D41A6D4D0FBD158044B05FAC27A04@ng-ex-mbx01> Hello Ross, I'm working on rtsp performance test tool and I will produce some code which I'd like to contribute. I know your strict opinion on patches, so I'd like to know in advance if you would accept: - common Linked List class (linked lists are already used on several places) - custom templates (for example function max() ) - C++ standard library string or custom string class (which one if any) - custom command line options parser class In addition I found current RTSPClient design difficult for my specific needs. So I plan to write other implementation. Should I keep you informed? Best Regards David Stegbauer This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From james.whetstone at kodak.com Tue Jul 20 17:37:59 2010 From: james.whetstone at kodak.com (james.whetstone at kodak.com) Date: Tue, 20 Jul 2010 17:37:59 -0700 Subject: [Live-devel] Problems using Windows Media Player Message-ID: Hi, I'm testing/evaluating the Live media server with the VLC Media Player and Windows Media Player, but I can't seem to get anything to play on WMP even though the same stream plays correctly using VLC. I'm streaming from the local host by using a URL : "rtsp://localhost/". Have I missed something about using WMP and Live? Thanks! Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoring at logitech.com Tue Jul 20 18:39:14 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Tue, 20 Jul 2010 18:39:14 -0700 Subject: [Live-devel] Problems using Windows Media Player In-Reply-To: References: Message-ID: On Tue, Jul 20, 2010 at 5:37 PM, wrote: > > Hi, > > I'm testing/evaluating the Live media server with the VLC Media Player and > Windows Media Player, but I can't seem to get anything to play on WMP even > though the same stream plays correctly using VLC. I'm streaming from the > local host by using a URL : "rtsp://localhost/". Have I missed > something about using WMP and Live? > WMP uses a non-standard form of RTSP, so it's generally incompatible with standards based RTSP servers. About the only thing it works well with is Windows Media Services, which generally uses a proprietary protocol called mms, or raw HTTP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhangjm at uusee.com Tue Jul 20 18:45:12 2010 From: zhangjm at uusee.com (Jimmy Zhang) Date: Wed, 21 Jul 2010 09:45:12 +0800 Subject: [Live-devel] Problems using Windows Media Player References: Message-ID: currently, wmp can only support file format of "wmv" which live hasn't support. ----- Original Message ----- From: james.whetstone at kodak.com To: live-devel at ns.live555.com Sent: Wednesday, July 21, 2010 8:37 AM Subject: [Live-devel] Problems using Windows Media Player Hi, I'm testing/evaluating the Live media server with the VLC Media Player and Windows Media Player, but I can't seem to get anything to play on WMP even though the same stream plays correctly using VLC. I'm streaming from the local host by using a URL : "rtsp://localhost/". Have I missed something about using WMP and Live? Thanks! Jim ------------------------------------------------------------------------------ _______________________________________________ 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 jnoring at logitech.com Tue Jul 20 19:26:33 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Tue, 20 Jul 2010 19:26:33 -0700 Subject: [Live-devel] Problems using Windows Media Player In-Reply-To: References: Message-ID: On Tue, Jul 20, 2010 at 6:45 PM, Jimmy Zhang wrote: > currently, wmp can only support file format of "wmv" which live hasn't > support. > It's off-topic for the mailing list, but this is completely incorrect. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sagi at netvision.net.il Wed Jul 21 06:06:30 2010 From: sagi at netvision.net.il (Sagi Ben Moshe) Date: Wed, 21 Jul 2010 16:06:30 +0300 Subject: [Live-devel] Live555 Streaming from a live source Message-ID: <005001cb28d5$891ff870$9b5fe950$@net.il> Hi Ross, We have implemented a stream for AAC audio and it works great, we also implement a stream for H.264 and it also works great. We would like to combine these two streams under one name. Currently, we have one stream called h264Video and another stream called aacAudio (Different streams, DESCRIBE). We would like to have one stream called audioVideo which configure two setups 1 for the video and 1 for the audio. Can you please let us know what is the best way to implement it? Thanks, Sagi -----Original Message----- From: Sagi Ben Moshe [mailto:sagi at adsonscreen.com] Sent: Wednesday, July 14, 2010 5:43 PM To: 'Enrique Polak' Subject: FW: [Live-devel] Live555 Streaming from a live source You can stream AAC audio using a "MPEG4GenericRTPSink", created with appropriate parameters to specify AAC audio. (Note, for example, how "ADTSAudioFileServerMediaSubsession" streams AAC audio that comes from an ADTS-format file.) From vigla at ece.fr Wed Jul 21 06:17:46 2010 From: vigla at ece.fr (Erwan Patrick Vigla) Date: Wed, 21 Jul 2010 15:17:46 +0200 Subject: [Live-devel] Implement RECORD RTSP functionality (server) Message-ID: Hello Ross, Before everything, great job for your work. As an academic project, i want to implement the record functionality in your library. I mean, to implement the RTSP request: RECORD, permitting to the server to copy the content of the media during streaming. I imagine to add a HandleCmd_Record function to the RTSPServer, streamState, subsession classes but i don't know how to link them with the sink and framer. Indeed, i imagine a framer which duplicates its content when the "record" functionality is activated, that supposed that the subsession access to the framer... Have i missed something? Does my reasoning seem correct? Thank you in advance for any help! EPV. From vinod_pratap at yahoo.com Wed Jul 21 06:47:48 2010 From: vinod_pratap at yahoo.com (Vinod Pratap) Date: Wed, 21 Jul 2010 06:47:48 -0700 (PDT) Subject: [Live-devel] trouble with aac audio Message-ID: <760510.48259.qm@web57506.mail.re1.yahoo.com> Hi, We have implmented a receiver and it seems to be working fine for most of the oulic content, however there are audio issues with seen with this specific stream: rtsp://mtvnmobile.qtod.llnwd.net/a4449/d1/n/124/17934/v001/mobilestor.download.akamai.com/17934/gametrailers.com/_tr_/83/8e/a4/t_reddeadr_shortfilm_teaser_mob_838ea408033615b2920362555618762b.3gp I tried to alayze this further using openRTSP, but there is a teardown seen. Same goes with Mplayer (windows GUI) which exits with error. I suspect that this is an interleaved stream which is not supported by live, but when I checked few of the packets AU- index delta appears to be zero. Can someone help me figure out what is different wrt audio in this stream. Thanks for help in advance, -VP From stephane.pigeon at visualdefence.com Wed Jul 21 14:05:10 2010 From: stephane.pigeon at visualdefence.com (Stephane Pigeon) Date: Wed, 21 Jul 2010 17:05:10 -0400 Subject: [Live-devel] ONVIF/PSIA compliance Message-ID: Sorry if this has been answered before, but a google search yielded no results. Is Live555 compliant with ONVIF and PSIA? I'm asking because ONVIF and PSIA specifications have some very specific requirements regarding streaming (ex. RTCP mandatory, RTP fallback on TCP if too much packet loss on UDP, etc). Thanks! Stephane Pigeon Software Developer Visual Defence Inc. http://www.visualdefence.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ottavio at videotec.com Thu Jul 22 01:18:34 2010 From: ottavio at videotec.com (Ottavio Campana) Date: Thu, 22 Jul 2010 10:18:34 +0200 Subject: [Live-devel] ONVIF/PSIA compliance In-Reply-To: References: Message-ID: <4C47FEDA.6020201@videotec.com> Il 21/07/10 23.05, Stephane Pigeon ha scritto: > Sorry if this has been answered before, but a google search yielded no > results. > > > > Is Live555 compliant with ONVIF and PSIA? > > > > I'm asking because ONVIF and PSIA specifications have some very specific > requirements regarding streaming (ex. RTCP mandatory, RTP fallback on > TCP if too much packet loss on UDP, etc). I developed a device for PSIA using live555 and by using the tester it says it is fine, though it just uses VLC to test it. I'm starting studying ONVIF, the situation seems to be a little bit more complicated, because of some extension in the RTP header, but I'm still not expert on this protocol. Ottavio PS: I tried looking at your website, you have a VMS. If you're interested in some interoperability test, please let me know. From sagi at netvision.net.il Thu Jul 22 09:57:43 2010 From: sagi at netvision.net.il (Sagi Ben Moshe) Date: Thu, 22 Jul 2010 19:57:43 +0300 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: <005001cb28d5$891ff870$9b5fe950$@net.il> References: <005001cb28d5$891ff870$9b5fe950$@net.il> Message-ID: <008a01cb29bf$00a24d00$01e6e700$@net.il> Hi Ross, We successfully combined the two streams into one stream and it works great. The Audio and Video are on the same url address. As it seems to us the Audio and Video are synchronized but we are not sure if we need to handle it (in some way other then setting presentation time) or it all handle in your library. The only thing we are currently doing is to update presentation time for the audio and for the video. We appreciate your input on this matter Thanks, Sagi -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Sagi Ben Moshe Sent: Wednesday, July 21, 2010 4:07 PM To: live-devel at ns.live555.com Subject: Re: [Live-devel] Live555 Streaming from a live source Hi Ross, We have implemented a stream for AAC audio and it works great, we also implement a stream for H.264 and it also works great. We would like to combine these two streams under one name. Currently, we have one stream called h264Video and another stream called aacAudio (Different streams, DESCRIBE). We would like to have one stream called audioVideo which configure two setups 1 for the video and 1 for the audio. Can you please let us know what is the best way to implement it? Thanks, Sagi -----Original Message----- From: Sagi Ben Moshe [mailto:sagi at adsonscreen.com] Sent: Wednesday, July 14, 2010 5:43 PM To: 'Enrique Polak' Subject: FW: [Live-devel] Live555 Streaming from a live source You can stream AAC audio using a "MPEG4GenericRTPSink", created with appropriate parameters to specify AAC audio. (Note, for example, how "ADTSAudioFileServerMediaSubsession" streams AAC audio that comes from an ADTS-format file.) _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From samparknisha at rediffmail.com Wed Jul 21 23:42:59 2010 From: samparknisha at rediffmail.com (Nisha Singh) Date: 22 Jul 2010 06:42:59 -0000 Subject: [Live-devel] =?utf-8?q?Synchronisation_of_audio_and_video?= Message-ID: <1279780879.S.3302.61075.webmail.rediff.com.drafts.1279780979.589@webmail.rediffmail.com> Hi, I have a mpeg-4 encoded video data and a wave file corresponding a video call (containing both audio and video). I am able to stream the mpeg-4 video file and the wave file separately by using live555 library. I want to play both the files together i.e. when the test_vid.m4e (mpeg-4 file) is being played, the test_aud.wav also gets played. For this I made the following changes in DynamicRTSPServer.cpp when the subsession for video and audio is created: if (stricmp(extension, ".m4e") == 0) { // Assumed to be a MPEG-4 Video Elementary Stream file: NEW_SMS("MPEG-4 Video"); sms->addSubsession(MPEG4VideoFileServerMediaSubsession::createNew(env, fileName, reuseSource)); //---------- added these lines so that the wave gets streamed----- Boolean convertToULaw = False; sms->addSubsession(WAVAudioFileServerMediaSubsession::createNew (env, "D:test_aud.wav", reuseSource, convertToULaw)); } After these small changes the video file and the audio file are getting streamed and the vlc is able to play them together. However the two files are not getting played synchronously by vlc. The video is lagging behind the audio. I don't know if I have done the above thing correctly or not. Could you please suggest me the correct way of streaming video and audio files together so that they can be played synchoronously by vlc. Regards, Nisha -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jul 24 00:39:45 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 24 Jul 2010 04:39:45 -0300 Subject: [Live-devel] Implement RECORD RTSP functionality (server) In-Reply-To: References: Message-ID: >As an academic project, i want to implement the record functionality >in your library. >I mean, to implement the RTSP request: RECORD, permitting to the >server to copy the content of the media during streaming. >I imagine to add a HandleCmd_Record function to the RTSPServer, >streamState, subsession classes but i don't know how to link them >with the sink and framer. >Indeed, i imagine a framer which duplicates its content when the >"record" functionality is activated, that supposed that the >subsession access to the framer... Yes, I think that is probably how I would implement "RECORD"- i.e., define a new "Framer" class (similar to the existing one for your media type) that also recorded (e.g., by writing to a file) the data that passed through it. Then you could define a new "ServerMediaSubsession" subclass - similar to the existing one - that used your new "Framer" class instead. Unfortunately you would still need to modify the existing code - both to handle the new "RECORD" command, and to define a new virtual function in "ServerMediaSubsession" for 'recording'. As you can probably imagine, "RECORD" is a rarely implemented feature of RTSP/1.0, and has been removed from the RTSP/2.0 specification. That's why implementing it in our server has never been a priority. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jul 25 02:11:18 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 25 Jul 2010 06:11:18 -0300 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: <008a01cb29bf$00a24d00$01e6e700$@net.il> References: <005001cb28d5$891ff870$9b5fe950$@net.il> <008a01cb29bf$00a24d00$01e6e700$@net.il> Message-ID: >We successfully combined the two streams into one stream and it works great. Good. As you figured out, you can do this just by creating a single "ServerMediaSession" object, and adding two separate "ServerMediaSubsessions" to it. >The Audio and Video are on the same url address. As it seems to us the Audio >and Video are synchronized but we are not sure if we need to handle it (in >some way other then setting presentation time) or it all handle in your >library. The only thing we are currently doing is to update presentation >time for the audio and for the video. We appreciate your input on this >matter Yes, if the presentation times of the two streams are in sync, and aligned with 'wall clock' time (i.e., the time that you'd get by calling "gettimeofday()"), and you are using RTCP (which is implemented by default in "OnDemandServerMediaSubsession"), then you will see A/V synchronization in standards-compliant clients. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From samparknisha at rediffmail.com Mon Jul 26 05:44:36 2010 From: samparknisha at rediffmail.com (Nisha Singh) Date: 26 Jul 2010 12:44:36 -0000 Subject: [Live-devel] =?utf-8?q?Live555_Streaming_from_a_live_source?= In-Reply-To: Message-ID: <1280051070.S.5915.59151.F.H.TlJvc3MgRmlubGF5c29uAFJlOiBbTGl2ZS1kZXZlbF0gTGl2ZTU1NSBTdHJlYW1pbmcgZnJvbSBhIGxpdmU_.f6-144-219.old.1280148271.30991@webmail.rediffmail.com> how is the presentationtime of two streams synchronised? I have to synchronise the mpeg-4 es and a wave file. I am able to send the two streams together by creating single servermediasession and adding two separate servermediasubsession, but they are not synchronised. In case of mpeg-4 es video, the gettimeofday() is getting called when the constructor of MPEGVideoStreamFramer is called and in case of wave, in WAVAudioFileSource::doGetNextFrame(). I think due to this the video and audio is not getting synchronised. So in this case how should i synchronise the audio and video? Regards, Nisha On Sun, 25 Jul 2010 15:14:30 +0530 wrote >>We successfully combined the two streams into one stream and it works great. Good. As you figured out, you can do this just by creating a single "ServerMediaSession" object, and adding two separate "ServerMediaSubsessions" to it. >The Audio and Video are on the same url address. As it seems to us the Audio >and Video are synchronized but we are not sure if we need to handle it (in >some way other then setting presentation time) or it all handle in your >library. The only thing we are currently doing is to update presentation >time for the audio and for the video. We appreciate your input on this >matter Yes, if the presentation times of the two streams are in sync, and aligned with 'wall clock' time (i.e., the time that you'd get by calling "gettimeofday()"), and you are using RTCP (which is implemented by default in "OnDemandServerMediaSubsession"), then you will see A/V synchronization in standards-compliant clients. -- 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 yinhua.li at siemens.com Mon Jul 26 20:26:50 2010 From: yinhua.li at siemens.com (Li, Yin Hua SLC CT NKG S) Date: Tue, 27 Jul 2010 11:26:50 +0800 Subject: [Live-devel] RTSP client_port(how to specify it) Message-ID: <68D227E48F4B0F4EB6161523402601BE65992C@PEKW987A.cn001.siemens.net> Dear all, At 'SETUP' section in RTSP, client side send the request includes client_port that it will used to receive rtp, these client_port were determined by client side player, now due to the firewall blocks most of ports, so I want to specify these client_port, what should I do? Best regards. -------------------------------------------------------------- ??? Li Yinhua SIEMENS Siemens Ltd., China Nanjing Branch Corporate Technology Development Center (CT DC), Nanjing 5F Dong Heng International Building Tel.: +86 (25) 52129888 - 6760 Fax: +86 (25) 52129308 Mobile: +86 15895967085 mailto:yinhua.li at siemens.com www.siemens.com P Save a tree. Don't print this e-mail unless it's really necessary. IMPORTANT NOTE: This e-mail and any attachment are confidential and may contain trade secrets and may also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are herewith informed about its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. You are prohibited from making use of or copying this e-mail or any attachment or disclosing the contents to any other person. In case you become aware of any unethical business behavior or violation of laws, particularly those against the Anti-corruption laws and Anti-trust laws, Siemens Compliance HelpDesk "Tell us" can be reached at www.siemens.com.cn/compliancehelpdesk ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????Tell us???????www.siemens.com.cn/compliancehelpdesk -------------- next part -------------- An HTML attachment was scrubbed... URL: From vishalsoni_2005 at yahoo.co.in Mon Jul 26 13:02:37 2010 From: vishalsoni_2005 at yahoo.co.in (vishal soni) Date: Tue, 27 Jul 2010 01:32:37 +0530 (IST) Subject: [Live-devel] Hi Message-ID: <123354.33957.qm@web8408.mail.in.yahoo.com> Hi, I am graduate student doing my master in Electrical Engineering at SDSU. I am doing my thesis on efficient video streaming over multihop wireless network using in band bandwidth estimation scheme ... In addition, I am planing to use H.264 video codec and RTP as the transport protocol ... So I tried to open the following link to check out the tutorial but the page does not open up http://www.white.ca/patrick/tutorial.tar.gz So can you please let me know how can access that tutorial or anyone can please send me that zip tutorial file. Thanking you all.... Thanks & Regards Vishal Soni MS Electrical Engineering San Diego State University. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 26 18:12:56 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 26 Jul 2010 21:12:56 -0400 Subject: [Live-devel] Live555 Streaming from a live source In-Reply-To: <1280051070.S.5915.59151.F.H.TlJvc3MgRmlubGF5c29uAFJlOiBbTGl2ZS1kZXZlbF0gT Gl2ZTU1NSBTdHJlYW1pbmcgZnJvbSBhIGxpdmU_.f6-144-219.old.1280148271.30991@we bmail.rediffmail.com> References: <1280051070.S.5915.59151.F.H.TlJvc3MgRmlubGF5c29uAFJlOiBbTGl2ZS1kZXZlbF0gT Gl2ZTU1NSBTdHJlYW1pbmcgZnJvbSBhIGxpdmU_.f6-144-219.old.1280148271.30991@we bmail.rediffmail.com> Message-ID: >how is the presentationtime of two streams synchronised? Please read the FAQ! >I have to synchronise the mpeg-4 es and a wave file. I am able to >send the two streams together by creating single servermediasession >and adding two separate servermediasubsession, but they are not >synchronised. >In case of mpeg-4 es video, the gettimeofday() is getting called >when the constructor of MPEGVideoStreamFramer is called and in case >of wave, in WAVAudioFileSource::doGetNextFrame(). I think due to >this the video and audio is not getting synchronised. So in this >case how should i synchronise the audio and video? You *must* set accurate "fPresentationTime" values for each frame of each of your sources. These values - and only these values - are what are used for synchronization. If the "fPresentationTime" values are not accurate - and synchronized - at the server, then they cannot possibly become synchronized at a client. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kamildobk at poczta.onet.pl Tue Jul 27 05:33:58 2010 From: kamildobk at poczta.onet.pl (Kamil Dobkowski) Date: Tue, 27 Jul 2010 14:33:58 +0200 Subject: [Live-devel] Stream cutoff because openRTSP ignores timeout in In-Reply-To: Message-ID: <619E09E2E2564DBDAD53044307FBC52C@KamilPC> >Intended behavior. The standard mechanism by which servers detect >the continued liveness of clients is via RTCP "RR"s. Note that the >intention of the "timeout" parameter in the RTSP "SETUP" response is >to indicate how long the server can wait after the last detection of >client liveness before closing the session. Actually RFC doesn't mention RTCP RR packets anywhere. Timeout is only for RTSP commands: www.ietf.org/rfc/rfc2326.txt 12.37 Session " The timeout parameter is only allowed in a response header. The server uses it to indicate to the client how long the server is prepared to wait between RTSP commands before closing the session due to lack of activity (see Section A)." -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidcailliere at voila.fr Tue Jul 27 13:28:47 2010 From: davidcailliere at voila.fr (david cailliere) Date: Tue, 27 Jul 2010 22:28:47 +0200 (CEST) Subject: [Live-devel] Strange output of openRTSP -Q Message-ID: <27062724.7375981280262527676.JavaMail.www@wwinf4631> Hi all, Using the current release of OpenRTSP (2010.07.13), I noticed a similar error in the num_packets_lost statistics line as Norbert Donath did in a old version (look at http://lists.live555.com/pipermail/live-devel/2004-December/001764.html). The format of the packet lost number is currently unsigned integer instead of signed integer as it should be in the source file Playcommon.cpp. Il also noticed a potential issue in the calculation of number of RTP packets expected According to RFC 1889 A.3. It must computed as follow extended_max = s->cycles + s->max_seq; expected = extended_max - s->base_seq + 1; In the current release of OpenRTSP, s->base_seq is assumed to be the sequence number of the first packet received, but it should probably not, since the first packet sent ont the server side can be received out of order on the client side. Some minor change could be done in the source file RTPSource.cpp/RTPSource.hh to fix that. I can provide you with a patch if necessary. Regards David ____________________________________________________ Suivez toute l'actualit? de Secret Story, retrouvez les d?p?ches, les photos et les vid?os sur http://people.voila.fr/evenementiel/PagesGenerees/secret-story2010/ From finlayson at live555.com Tue Jul 27 04:53:16 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Jul 2010 04:53:16 -0700 Subject: [Live-devel] RTSP client_port(how to specify it) In-Reply-To: <68D227E48F4B0F4EB6161523402601BE65992C@PEKW987A.cn001.siemens.net> References: <68D227E48F4B0F4EB6161523402601BE65992C@PEKW987A.cn001.siemens.net> Message-ID: > At 'SETUP' section in RTSP, client side send the request >includes client_port that it will used to receive rtp, these >client_port were determined by client side player, now due to the >firewall blocks most of ports, so I want to specify these >client_port, what should I do? Note how the "openRTSP" application implements the '-p " option. Specifically, call "MediaSubsession::setClientPortNum()" before calling "MediaSubsession::initiate()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinhua.li at siemens.com Tue Jul 27 19:05:34 2010 From: yinhua.li at siemens.com (Li, Yin Hua SLC CT NKG S) Date: Wed, 28 Jul 2010 10:05:34 +0800 Subject: [Live-devel] RTSP client_port(how to specify it) In-Reply-To: References: <68D227E48F4B0F4EB6161523402601BE65992C@PEKW987A.cn001.siemens.net> Message-ID: <68D227E48F4B0F4EB6161523402601BE659CD3@PEKW987A.cn001.siemens.net> Many thanks to Ross Finlayson, "openRTSP" application is client side at VOD structure. I really want to ask is can I modify client_port at server side? Thanks in advance~ ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, July 27, 2010 7:53 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTSP client_port(how to specify it) At 'SETUP' section in RTSP, client side send the request includes client_port that it will used to receive rtp, these client_port were determined by client side player, now due to the firewall blocks most of ports, so I want to specify these client_port, what should I do? Note how the "openRTSP" application implements the '-p " option. Specifically, call "MediaSubsession::setClientPortNum()" before calling "MediaSubsession::initiate()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ IMPORTANT NOTE: This e-mail and any attachment are confidential and may contain trade secrets and may also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are herewith informed about its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your system. You are prohibited from making use of or copying this e-mail or any attachment or disclosing the contents to any other person. In case you become aware of any unethical business behavior or violation of laws, particularly those against the Anti-corruption laws and Anti-trust laws, Siemens Compliance HelpDesk "Tell us" can be reached at www.siemens.com.cn/compliancehelpdesk ????:???????????,???????????????????????????,????????????,?????????????????????????????????????,?????????????????????????????? ?????????????????,?????????????????,????????????"Tell us"??,???www.siemens.com.cn/compliancehelpdesk -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 27 18:57:18 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Jul 2010 18:57:18 -0700 Subject: [Live-devel] ONVIF/PSIA compliance In-Reply-To: References: Message-ID: >Is Live555 compliant with ONVIF and PSIA? To be honest, I hadn't heard of either of these things until you mentioned them. The standards body that defines Internet Standard protocols for video streaming is the IETF, and it is those standards that we (at least attempt to) follow. I don't know how these other "Industry Forums" relate to the IETF standard protocols, but (IMHO) these organizations usually exist in order to try to gain a competitive advantage over a dominant or threatening rival. Finlayson's Law of Industry Forums: To discover the real purpose of an 'Industry Forum', look at its membership list, and note which major player in the industry is *not* present. Often these organizations 'pick and choose' from IETF standards that suit them, but sometimes they add custom extensions, in which case we probably don't support them. But again, I don't know anything about these organizations (and I don't really have the time to research them right now), so I really can't say for sure. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jul 27 22:16:13 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Jul 2010 22:16:13 -0700 Subject: [Live-devel] RTSP client_port(how to specify it) In-Reply-To: <68D227E48F4B0F4EB6161523402601BE659CD3@PEKW987A.cn001.siemens.net> References: <68D227E48F4B0F4EB6161523402601BE65992C@PEKW987A.cn001.siemens.net> <68D227E48F4B0F4EB6161523402601BE659CD3@PEKW987A.cn001.siemens.net> Message-ID: >"openRTSP" application is client side at VOD structure. I really >want to ask is can I modify client_port at server side? No. For unicast streams, the client's port is always choen by the client. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 27 22:21:10 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Jul 2010 22:21:10 -0700 Subject: [Live-devel] Strange output of openRTSP -Q In-Reply-To: <27062724.7375981280262527676.JavaMail.www@wwinf4631> References: <27062724.7375981280262527676.JavaMail.www@wwinf4631> Message-ID: >I can provide you with a patch if necessary. Yes, please do, and I'll take a look at it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jul 27 22:33:05 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Jul 2010 22:33:05 -0700 Subject: [Live-devel] trouble with aac audio In-Reply-To: <760510.48259.qm@web57506.mail.re1.yahoo.com> References: <760510.48259.qm@web57506.mail.re1.yahoo.com> Message-ID: >We have implmented a receiver and it seems to be working fine for >most of the oulic content, however there are audio issues with seen >with this specific stream: >rtsp://mtvnmobile.qtod.llnwd.net/a4449/d1/n/124/17934/v001/mobilestor.download.akamai.com/17934/gametrailers.com/_tr_/83/8e/a4/t_reddeadr_shortfilm_teaser_mob_838ea408033615b2920362555618762b.3gp > >I tried to alayze this further using openRTSP, but there is a teardown seen. I didn't see any problem when I ran "openRTSP" with that URL. The 'teardown' was merely the client closing down the stream after the end of its 70.70333 second duration (the duration that was specified in the stream's SDP description). Unfortunately I can't help you with your 'audio issues', because our software doesn't do any audio (or video) decoding. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jul 27 23:04:10 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Jul 2010 23:04:10 -0700 Subject: [Live-devel] Which kind of code you would accept? In-Reply-To: <4171BB396C058D41A6D4D0FBD158044B05FAC27A04@ng-ex-mbx01> References: <4171BB396C058D41A6D4D0FBD158044B05FAC27A04@ng-ex-mbx01> Message-ID: >I'm working on rtsp performance test tool and I >will produce some code which I'd like to contribute. I know your strict >opinion on patches, so I'd like to know in advance if you would accept: I don't have any definitive rules about what sort of patches I accept. However, the patches that I'm most likely to accept are: 1/ Bugfixes, and 2/ Changes that make it easier for developers to extend the supplied code via subclassing, rather than forcing them to modify the supplied code. The kind of patches that I'm least likely to accept are those that make changes throughout the code (in several files), especially if they are mostly cosmetic in nature. A problem we've had recently is that some people have apparently made little effort to try to leave the supplied code unchanged. Instead (perhaps because of laziness, or perhaps because of a lack of understanding of how C++ subclassing works; I'm not sure), they have charged ahead and merged the supplied code with their own application code, making widespread changes to the supplied code. They then want me to adopt these changes without question (e.g., so that they can more easily upgrade to new versions of the code), and then throw a hissy fit if I refuse to do so. I'm sorry, but that's not the way the code is supposed to be used. If people have misused the code this way, then I'm not going to 'reward' them by adopting their modifications without question. Specifically, looking at your suggestions: > - common Linked List class (linked lists are already used on several places) > - custom templates (for example function max() ) > - C++ standard library string or custom string class (which one if any) > - custom command line options parser class No, I won't be adopting any of these (at least, not anytime soon), because they don't fix bugs, nor do they improve (or even really change) the code's API - only its implementation, which developers shouldn't really be caring about very much (as long as it works). (I'm also a bit wary about using some of the newer C++ features (such as templates), because some people's compilers might not support them. Ditto for 'standard' C++ libraries, which might also make applications too large for some embedded systems. I like to be a bit conservative about which features of C++ I use for the "LIVE555 Streaming Media" libraries.) The things that you mention might be nice for *your* application code, but they don't have to be also applied to our library code - if you are using it correctly. >In addition I found current RTSPClient design difficult for my >specific needs. So >I plan to write other implementation. Go ahead. Of course, you should give your new class a new name - not "RTSPClient". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ottavio at videotec.com Wed Jul 28 00:46:01 2010 From: ottavio at videotec.com (Ottavio Campana) Date: Wed, 28 Jul 2010 09:46:01 +0200 Subject: [Live-devel] ONVIF/PSIA compliance In-Reply-To: References: Message-ID: <4C4FE039.7020101@videotec.com> Ross Finlayson wrote: >> Is Live555 compliant with ONVIF and PSIA? > > To be honest, I hadn't heard of either of these things until you > mentioned them. well, last year there was a post in this list http://lists.live555.com/pipermail/live-devel/2009-October/011278.html The specification http://www.onvif.org/imwp/download.asp?ContentID=18006 requires conformance to [RFC 3550], [RFC 3551], [RFC 3984], [RFC 3016] and at first sight everything is ok. My only doubt is about JPG over RTP enhanced headers, but I still have to check whether they are mandatory or not. Ottavio From david.stegbauer at acision.com Wed Jul 28 01:53:53 2010 From: david.stegbauer at acision.com (David Stegbauer) Date: Wed, 28 Jul 2010 10:53:53 +0200 Subject: [Live-devel] Live555 documentation generated by doxygen Message-ID: <201007281053.54064.david.stegbauer@acision.com> Hi all, the online documentation is available at http://geraldine.fjfi.cvut.cz/~dstegbauer/live555/html/index.html Source Doxyfile is available at http://geraldine.fjfi.cvut.cz/~dstegbauer/live555/Doxyfile Please do not mirror the live555 documentation from the web, it has 307MiB. If you would like to have it locally, grab the above mentioned Doxyfile, put it to live555 source directory, cd there and run doxygen. You have to have doxygen and graphviz installed. Ross, would you consider addition of Doxyfile to distribution? Would you accept changes in source which will convert the in-source documentation to doxygen compatible format? For example Boolean changeResponseHandler(unsigned cseq, responseHandler* newResponseHandler); // Changes the response handler for the previously-performed command (whose operation returned "cseq"). // (To turn off any response handling for the command, use a "newResponseHandler" value of NULL. This might be done as part // of an implementation of a 'timeout handler' on the command, for example.) // This function returns True iff "cseq" was for a valid previously-performed command (whose response is still unhandled). will change to something like //! Change the response handler for the previously-performed command. //! \param cseq CSeq of the previously-performed command //! \param newResponseHandler new response handler function. //! Set to null to turn off any response handling for the command. //! (This might be done as part of an implementation of a 'timeout handler' on the command, for example.) //! \return True iff "cseq" was for a valid previously-performed command (whose response is still unhandled). Boolean changeResponseHandler(unsigned cseq, responseHandler* newResponseHandler); Best Regards David Stegbauer This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From david.stegbauer at acision.com Wed Jul 28 02:33:44 2010 From: david.stegbauer at acision.com (David Stegbauer) Date: Wed, 28 Jul 2010 11:33:44 +0200 Subject: [Live-devel] Which kind of code you would accept? In-Reply-To: References: <4171BB396C058D41A6D4D0FBD158044B05FAC27A04@ng-ex-mbx01> Message-ID: <201007281133.44870.david.stegbauer@acision.com> On Wednesday 28 July 2010 08:04:10 Ross Finlayson wrote: > Specifically, looking at your suggestions: > > - C++ standard library string or custom string class (which one if any) > > - custom command line options parser class > > No, ... > because they don't fix bugs, nor do they improve (or even really > change) the code's API In fact use of std::string instead of char* is both change and improvement of API. User of library would not need to worry about delete []. On my platform (Linux gcc 4.3) sizeof(std::string) == sizeof(char*), so it has the same efficiency when passed as argument or returned by value. The worst I have seen was 16 bytes on 32 bit HP-UX in pre-standard mode. > > (I'm also a bit wary about using some of the newer C++ features (such > as templates), because some people's compilers might not support > them. AFAIK templates and STL are supported Linux, Windows, MacOSX and Unix both using native C++ libraries and uclibc (uclibc++). I'm not sure about iphoneOS, qnx and alpha. Does anybody on list know? > Ditto for 'standard' C++ libraries, which might also make > applications too large for some embedded systems. Standard C++ libraries could sometimes become huge, but there are techniques to keep final binaries small. I've compared my custom string class against std::string. The resulting binaries differed by approx 100 bytes. The most valuable thing on standard library is that it is extensively tested. Best Regards David Stegbauer This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From jordi at multinformatica.com Wed Jul 28 02:57:12 2010 From: jordi at multinformatica.com (Jordi Ortola Lorente) Date: Wed, 28 Jul 2010 11:57:12 +0200 Subject: [Live-devel] Frame to frame processing after decoding Message-ID: Hello, I'm developing a real time video processing aplication. I discovered your incredible rtsp library so I compiled and tested the samples. I need to receive h264 encoded video trough rtsp protocol and I've seen you already support this. I need to process each decoded frame, but I don't know in witch place do this. I've read a tutorial about h264 over livemedia, and also inspected the class hierarchy and I supose that this could be done deriving from H264VideoRTPSink class and overriding doSpecialFrameHandling, but I still don't know how retrieve frame propieties (width, height, pixelformat...) and the frame. It would appreciate it if you correct me and explain me the way to do this. Thanks, Jordi -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 28 06:24:21 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Jul 2010 06:24:21 -0700 Subject: [Live-devel] Live555 documentation generated by doxygen In-Reply-To: <201007281053.54064.david.stegbauer@acision.com> References: <201007281053.54064.david.stegbauer@acision.com> Message-ID: >the online documentation is available at >http://geraldine.fjfi.cvut.cz/~dstegbauer/live555/html/index.html No it's not. That is *David's* online documentation, generated from his copy of the code. The actual online Doxygen documentation is here http://www.live555.com/liveMedia/doxygen/html/ Please stop misleading the mailing list! >would you consider addition of Doxyfile to distribution? I already have one, which I use to generate the online Doxygen documentation that I mentioned above. I don't think that yours is much different (or better). > Would you accept changes in source which will convert the in-source >documentation to doxygen >compatible format? No, at least not right now. The existing online Doxygen documentation, e.g. http://www.live555.com/liveMedia/doxygen/html/classRTSPClient.html#1442234f611c9e0249c4deca5b6e4fa1 along with the documented header files, e.g. http://www.live555.com/liveMedia/doxygen/html/RTSPClient_8hh-source.html should be sufficient. The types of changes to the source code that you're proposing just make the code uglier and harder to read for people who (for whatever reason) want to read it directly, rather than only looking at the Doxygen online documentation. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Jul 28 06:49:08 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Jul 2010 06:49:08 -0700 Subject: [Live-devel] Which kind of code you would accept? In-Reply-To: <201007281133.44870.david.stegbauer@acision.com> References: <4171BB396C058D41A6D4D0FBD158044B05FAC27A04@ng-ex-mbx01> <201007281133.44870.david.stegbauer@acision.com> Message-ID: >On Wednesday 28 July 2010 08:04:10 Ross Finlayson wrote: > > Specifically, looking at your suggestions: >> > - C++ standard library string or custom string class (which one if any) >> > - custom command line options parser class >> >> No, ... >> because they don't fix bugs, nor do they improve (or even really >> change) the code's API > >In fact use of std::string instead of char* is both change and improvement of >API. User of library would not need to worry about delete []. In the future I'll definitely consider switching to using "std::string" if/when I become sure that it is available - and efficient - for *all* potential users of our code. Right now, though, I'm not sure of this. > > Ditto for 'standard' C++ libraries, which might also make >> applications too large for some embedded systems. > >Standard C++ libraries could sometimes become huge, but there are >techniques to keep final binaries small. That's too vague. I really want to make sure that this code remains useful, and usable, for people who are developing small embedded systems. But my basic point remains: If people are using the code properly, then the kinds of changes that you are proposing are just not important, because they add little new functionality. So please stop harping on about this. The more of my time that is wasted dealing with unimportant questions like this is time that I don't get to spend on adding important new functionality that will really help people, like, for example: 1/ A new simple RTSP client demo application ("testRTSPClient") that will give developers a much clearer picture of how to use "RTSPClient" (as opposed to the code for the "openRTSP" application, which is complex and has lots of 'bells and whistles' that are unneeded by most developers). 2/ New test programs (and 'framer' classes) for H.264 video (because many people seem to be having lots of trouble sending (especially) and receiving H.264 video. Both of these things (and a lot more - e.g., stuff that will eventually lead to support for IPv6) is all on the drawing board, but keeps getting delayed by distractions... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Jul 28 07:01:05 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Jul 2010 07:01:05 -0700 Subject: [Live-devel] ONVIF/PSIA compliance In-Reply-To: <4C4FE039.7020101@videotec.com> References: <4C4FE039.7020101@videotec.com> Message-ID: >Ross Finlayson wrote: >>> Is Live555 compliant with ONVIF and PSIA? >> >> To be honest, I hadn't heard of either of these things until you >> mentioned them. > >well, last year there was a post in this list >http://lists.live555.com/pipermail/live-devel/2009-October/011278.html Oh yes, I'd forgotten all about that thread. Thanks for the reminder. >The specification > >http://www.onvif.org/imwp/download.asp?ContentID=18006 > >requires conformance to [RFC 3550], [RFC 3551], [RFC 3984], [RFC 3016] >and at first sight everything is ok. My only doubt is about JPG over RTP > enhanced headers, but I still have to check whether they are mandatory >or not. As I noted in my response to the previous (October 2009) thread, JPEG video is stupid, and I really wish it would die. If these 'enhanced headers' get adopted by the IETF, though, then I'll consider supporting them. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Jul 28 07:07:18 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Jul 2010 07:07:18 -0700 Subject: [Live-devel] Frame to frame processing after decoding In-Reply-To: References: Message-ID: >I'm developing a real time video processing aplication. I discovered >your incredible rtsp library so I compiled and tested the samples. I >need to receive h264 encoded video trough rtsp protocol and I've >seen you already support this. I need to process each decoded frame, >but I don't know in witch place do this. You would do this by writing your own "MediaSink" subclass that would do the decoding. (Our library does not include any decoding software of its own.) An object of this new subclass would then read from a "H264VideoRTPSource" object (i.e., to read incoming H.264 NAL units). > I've read a tutorial about h264 over livemedia, and also inspected >the class hierarchy and I supose that this could be done deriving >from H264VideoRTPSink class No! "H264VideoRTPSink" is used by servers, to *transmit* H.264 data. You are interested in *receiving* H.264 data. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From davidcailliere at voila.fr Wed Jul 28 08:05:23 2010 From: davidcailliere at voila.fr (david cailliere) Date: Wed, 28 Jul 2010 17:05:23 +0200 (CEST) Subject: [Live-devel] Strange output of openRTSP -Q Message-ID: <1021499.4151311280329523705.JavaMail.www@wwinf4604> Dear Ross, Please find in the attached zip file the 3 source files including the change mentioned in my previous mail. The change has been made starting from the source code of the release 20100713. Regards, David > Message du 28/07/10 ? 07h48 > De : "Ross Finlayson" > A : "LIVE555 Streaming Media - development & use" > Copie ? : > Objet : Re: [Live-devel] Strange output of openRTSP -Q > > > >I can provide you with a patch if necessary. > > Yes, please do, and I'll take a look at it. > -- > > 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 > > ____________________________________________________ Suivez toute l'actualit? de Secret Story, retrouvez les d?p?ches, les photos et les vid?os sur http://people.voila.fr/evenementiel/PagesGenerees/secret-story2010/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenRTSPSourcePatch.zip Type: application/zip Size: 17513 bytes Desc: not available URL: From back2primitive at autistici.org Wed Jul 28 08:47:27 2010 From: back2primitive at autistici.org (jacopo) Date: Wed, 28 Jul 2010 17:47:27 +0200 Subject: [Live-devel] dump h264 video problem Message-ID: <4C50510F.5060300@autistici.org> Hi all, I'm trying to implement a video recording service, and i need to dump h264 or MPEG4 videos (service must be eterogenous) in response to some external events. I planned to do this reimplementing openRTSP exemple, in order to coordinate it not from command line but with external applications. Before starting writing code I've tried dumping some streams from various rtsp sources. I usually start openRTSP with canonical options ( -t -d ) and with mpeg4 video all works fine (with -4 or -q option), while h264 videos are quite unusable. All videos are out of sync with overlapped frames, and if I try to open them with mplayer the following error is reported an indefinite number of times: [h264 @ 0xb523e0]concealing 330 DC, 330 AC, 330 MV errors Error is not related to mplayer since also vlc or xine fail to play videos. I've specified various resolutions and fps (not needed for mpeg4, they just works), but none worked. I've read on faq about NAL unit, but I've verified that a H264FileSink implementation was introduced in 2007. I need to reimplent my own one? NAL units in h264 codec are related to the network transport layer, so every implementation is related to a single specific context or the H264FileSink implementation is generally usable? Ah, I'm using last version from public repo 2010.07.03 built from sources (of course) on a 64bit Fedora13 box, if it could in some way matter... Sorry in advance if some of my question seems innacurate, but I'm very confused and found few infos online (need I learn to google better?) thanks in advance j From amitye at gmail.com Wed Jul 28 09:36:08 2010 From: amitye at gmail.com (Amit Yedidia) Date: Wed, 28 Jul 2010 19:36:08 +0300 Subject: [Live-devel] H264 SVC Message-ID: Hi All, I am considering the development of adding the SVC RTP to the LIVE555 library.(both SST and MST) does anyone interested to join me in this effort? Amit Yedidia. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilton at ivision.ind.br Wed Jul 28 15:18:05 2010 From: wilton at ivision.ind.br (wilton at ivision.ind.br) Date: Wed, 28 Jul 2010 19:18:05 -0300 Subject: [Live-devel] SIGSEGV in testOnDemandRTSPServer Message-ID: <6b15be78c13cbd96d0f5bb84c4eb5a66@ivision.ind.br> Hi Ross, I got a Segmentation Fault in testOnDemandRTSPServer using the last version. (compiled in the Linux x86 environment) I connected to server using VLC (rtsp://192.168.0.2:8554/mpeg4ESVideoTest ) and it works fine. The segmentation fault happens when I close the connection from the VLC. If you give me a start point I can try to find the problem. Regards, Wilton Program received signal SIGSEGV, Segmentation fault. SocketDescriptor::tcpReadHandler1 (this=0x6edf50, mask=0) at RTPInterface.cpp:363 363 if (fTCPReadingState != AWAITING_PACKET_DATA) { (gdb) bt #0 SocketDescriptor::tcpReadHandler1 (this=0x6edf50, mask=0) at RTPInterface.cpp:363 #1 0x0000000000420edb in SocketDescriptor::tcpReadHandler (socketDescriptor=0x7ffff762fe40, mask=0) at RTPInterface.cpp:348 #2 0x000000000042c282 in BasicTaskScheduler::SingleStep (this=0x651010, maxDelayTime=) at BasicTaskScheduler.cpp:123 #3 0x000000000042d7a5 in BasicTaskScheduler0::doEventLoop (this=0x651010, watchVariable=0x0) at BasicTaskScheduler0.cpp:76 #4 0x0000000000402c0a in main (argc=, argv=) at testOnDemandRTSPServer.cpp:240 From finlayson at live555.com Wed Jul 28 16:59:14 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Jul 2010 16:59:14 -0700 Subject: [Live-devel] SIGSEGV in testOnDemandRTSPServer In-Reply-To: <6b15be78c13cbd96d0f5bb84c4eb5a66@ivision.ind.br> References: <6b15be78c13cbd96d0f5bb84c4eb5a66@ivision.ind.br> Message-ID: (Bom dia. Eu amo o Brasil. Eu visitei l? no in?cio deste m?s!) >I got a Segmentation Fault in testOnDemandRTSPServer using the last >version. >(compiled in the Linux x86 environment) > >I connected to server using VLC >(rtsp://192.168.0.2:8554/mpeg4ESVideoTest ) and it works fine. >The segmentation fault happens when I close the connection from the VLC. Unfortunately I haven't been able to reproduce this crash. (I presume you're streaming RTP-over-TCP, because of where the error is occurring.) How exactly are you "closing the connection from VLC"? Are you just quitting the VLC application from the console (using control-c), or are you pressing the "stop" button in the GUI? Or are you letting the stream run until it ends, and then quitting VLC (from the GUI, or using control-c)? Also, are you using one of the ".m4e" files from http://www.live555.com/liveMedia/public/m4e/ , or are you using some other file? (The file shouldn't matter, but I just want to check.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From wilton at ivision.ind.br Wed Jul 28 18:48:40 2010 From: wilton at ivision.ind.br (wilton at ivision.ind.br) Date: Wed, 28 Jul 2010 22:48:40 -0300 Subject: [Live-devel] SIGSEGV in testOnDemandRTSPServer In-Reply-To: References: <6b15be78c13cbd96d0f5bb84c4eb5a66@ivision.ind.br> Message-ID: > (Bom dia. Eu amo o Brasil. Eu visitei l? no in?cio deste m?s!) Que bom. Qual foi o lugar que voc? visitou? > Unfortunately I haven't been able to reproduce > this crash. (I presume you're streaming > RTP-over-TCP, because of where the error is > occurring.) Yes, I'm using RTP-over-TCP. When I disable this option in the VLC the Segmentation Fault does not ocur. > Also, are you using one of the ".m4e" files from > http://www.live555.com/liveMedia/public/m4e/ , or > are you using some other file? (The file > shouldn't matter, but I just want to check.) I was using different files. But after you asked I tested with para.m4e and petrov.m4e and got the same error. > How exactly are you "closing the connection from > VLC"? Are you just quitting the VLC application > from the console (using control-c), or are you > pressing the "stop" button in the GUI? Or are > you letting the stream run until it ends, and > then quitting VLC (from the GUI, or using > control-c)? I used the "stop" button in the GUI. I tested also using control-c and got the same error. I tested with petrov.m4e and waited for the file end. NO ERROR! I used the play button from the VLC gui and it works fine again. I executed some times to get the back trace. The error changes the place, but it always related to socket read called by tcpReadHandler. It seems to me that the handler is using a object after it was removed. I think that this task need to be removed from the Schedule, but I don't have a good idea of the correct place. Regards, Wilton From finlayson at live555.com Thu Jul 29 00:10:34 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 29 Jul 2010 00:10:34 -0700 Subject: [Live-devel] Strange output of openRTSP -Q In-Reply-To: <27062724.7375981280262527676.JavaMail.www@wwinf4631> References: <27062724.7375981280262527676.JavaMail.www@wwinf4631> Message-ID: >According to RFC 1889 A.3. It must computed as follow Note, BTW, that RFC1889 has been obsoleted by RFC3550. (However, the appendix that you referenced did not change, so your point is still valid.) >Please find in the attached zip file the 3 source files including >the change mentioned in my previous mail. Thanks. This will be included in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jul 29 05:51:15 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 29 Jul 2010 05:51:15 -0700 Subject: [Live-devel] SIGSEGV in testOnDemandRTSPServer In-Reply-To: References: <6b15be78c13cbd96d0f5bb84c4eb5a66@ivision.ind.br> Message-ID: > > (Bom dia. Eu amo o Brasil. Eu visitei l? no in?cio deste m?s!) >Que bom. Qual foi o lugar que voc? visitou? Visitei o Rio (para um tounament jiu-jitsu brasileiro), e Salvador. > > How exactly are you "closing the connection from >> VLC"? Are you just quitting the VLC application >> from the console (using control-c), or are you >> pressing the "stop" button in the GUI? Or are >> you letting the stream run until it ends, and >> then quitting VLC (from the GUI, or using >> control-c)? > >I used the "stop" button in the GUI. I tested also using control-c >and got the same error. OK, I was finally able to reproduce the problem, but only with "testOnDemandRTSPServer" running on Linux. Strangely, I was not able to reproduce the problem with "testOnDemandRTSPServer" running on FreeBSD or Mac OS X. But this gives me enough to help track down the problem. I'll let you know when a fix is available. Thanks again for reporting this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From back2primitive at autistici.org Thu Jul 29 06:22:19 2010 From: back2primitive at autistici.org (jacopo) Date: Thu, 29 Jul 2010 15:22:19 +0200 Subject: [Live-devel] dump h264 video problem In-Reply-To: <4C50510F.5060300@autistici.org> References: <4C50510F.5060300@autistici.org> Message-ID: <4C51808B.6050902@autistici.org> Update: I've found an h264 video stream that I'm able to dump and play correctly rtsp://media.lscube.org/tests/tc.mov This one suffers the problems I was talking about: rtsp://streaming1.osu.edu/media2/ufsap/ufsap.mov Both have been dumped with ./openRTSP -t -d 20 -q command line (no fps and w/h has to be specified for firts one, for second none worked) Both streams are taken from a wikipedia page, so I'm quite sure they are public... Second stream is delivered by Helix, first one by feng. I'm not sure about one thing. H264VideoFileSink class that inserts 4 bytes long delimiter between NAL units, is used only when streaming not when receiving a strem, right? If so, the problem must be container related (QuickTime or mp4 does't matter for me) not codec related, since libraries are just dumping an encoded stream that is not touched or modified when saved to a file (or printed to stdout) inside the choosen container... Am I totaly missing the point? Thanks again j On 07/28/2010 05:47 PM, jacopo wrote: > Hi all, > I'm trying to implement a video recording service, and i need to > dump h264 or MPEG4 videos (service must be eterogenous) in response to > some external events. > > I planned to do this reimplementing openRTSP exemple, in order to > coordinate it not from command line but with external applications. > Before starting writing code I've tried dumping some streams from > various rtsp sources. > I usually start openRTSP with canonical options ( -t -d ) and with mpeg4 > video all works fine (with -4 or -q option), while h264 videos are quite > unusable. > > All videos are out of sync with overlapped frames, and if I try to open > them with mplayer the following error is reported an indefinite number > of times: > [h264 @ 0xb523e0]concealing 330 DC, 330 AC, 330 MV errors > Error is not related to mplayer since also vlc or xine fail to play videos. > > I've specified various resolutions and fps (not needed for mpeg4, they > just works), but none worked. > I've read on faq about NAL unit, but I've verified that a H264FileSink > implementation was introduced in 2007. > I need to reimplent my own one? NAL units in h264 codec are related to > the network transport layer, so every implementation is related to a > single specific context or the H264FileSink implementation is generally > usable? > > Ah, I'm using last version from public repo 2010.07.03 built from > sources (of course) on a 64bit Fedora13 box, if it could in some way > matter... > > Sorry in advance if some of my question seems innacurate, but I'm very > confused and found few infos online (need I learn to google better?) > > > thanks in advance > j > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > From finlayson at live555.com Thu Jul 29 10:29:04 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 29 Jul 2010 10:29:04 -0700 Subject: [Live-devel] SIGSEGV in testOnDemandRTSPServer In-Reply-To: References: <6b15be78c13cbd96d0f5bb84c4eb5a66@ivision.ind.br> Message-ID: OK, I have now installed a new version of the code (2010.07.29) that fixes this problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jul 29 13:14:48 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 29 Jul 2010 13:14:48 -0700 Subject: [Live-devel] dump h264 video problem In-Reply-To: <4C51808B.6050902@autistici.org> References: <4C50510F.5060300@autistici.org> <4C51808B.6050902@autistici.org> Message-ID: >]I've found an h264 video stream that I'm able to dump and play correctly >rtsp://media.lscube.org/tests/tc.mov > >This one suffers the problems I was talking about: > rtsp://streaming1.osu.edu/media2/ufsap/ufsap.mov > >Both have been dumped with >./openRTSP -t -d 20 -q >command line (no fps and w/h has to be specified for firts one, for >second none worked) The second stream's video has width 320 pixels, and height 240 pixels, so you should specify those if you're trying to record it using "openRTSP -q". (I'm not sure about the frame rate.) >I'm not sure about one thing. H264VideoFileSink class that inserts 4 >bytes long delimiter between NAL units, is used only when streaming not >when receiving a strem, right? Wrong. Because it's a 'FileSink', it's used only when *receiving* a stream. If "openRTSP" is used to receive a H.264/RTP stream normally - without using the "-q" or "-4" options - then the "H264VideoFileSink" class is used for the output. If, however, "openRTSP" is used with the "-q" or "-4" options, then a different 'FileSink' class - "QuickTimeFileSink" - is used. Because you're using the "-q" option, this is what you are using. >If so, the problem must be container related (QuickTime or mp4 does't >matter for me) not codec related, since libraries are just dumping an >encoded stream that is not touched or modified when saved to a file (or >printed to stdout) inside the choosen container... >Am I totaly missing the point? I'm not sure. But the basic problem here is that the ".mov" (or ".mp4") file format was very badly designed, and is especially ill-suited for what we are trying to do: Record incoming media streams into a file. The "QuickTimeFileSink" class tries to do this as well as it can, but the basic flaws of the file format makes it difficult. Nonethess, it's possible that the "QuickTimeFileSink" implementation can be improved, so feel free to take a look at it, and let us know if you have any suggestions for improvements/bug fixes. Remember, You Have Complete Source Code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From back2primitive at autistici.org Fri Jul 30 00:22:40 2010 From: back2primitive at autistici.org (jacopo) Date: Fri, 30 Jul 2010 09:22:40 +0200 Subject: [Live-devel] dump h264 video problem In-Reply-To: References: <4C50510F.5060300@autistici.org> <4C51808B.6050902@autistici.org> Message-ID: <4C527DC0.6070703@autistici.org> On 07/29/2010 10:14 PM, Ross Finlayson wrote: >> ]I've found an h264 video stream that I'm able to dump and play >> correctly >> rtsp://media.lscube.org/tests/tc.mov >> >> This one suffers the problems I was talking about: >> rtsp://streaming1.osu.edu/media2/ufsap/ufsap.mov >> >> Both have been dumped with >> ./openRTSP -t -d 20 -q >> command line (no fps and w/h has to be specified for firts one, for >> second none worked) > > The second stream's video has width 320 pixels, and height 240 pixels, > so you should specify those if you're trying to record it using > "openRTSP -q". (I'm not sure about the frame rate.) > > >> I'm not sure about one thing. H264VideoFileSink class that inserts 4 >> bytes long delimiter between NAL units, is used only when streaming not >> when receiving a strem, right? > > Wrong. Because it's a 'FileSink', it's used only when *receiving* a > stream. If "openRTSP" is used to receive a H.264/RTP stream normally > - without using the "-q" or "-4" options - then the > "H264VideoFileSink" class is used for the output. If, however, > "openRTSP" is used with the "-q" or "-4" options, then a different > 'FileSink' class - "QuickTimeFileSink" - is used. Because you're > using the "-q" option, this is what you are using. Yes, I saw that into sources.. > > >> If so, the problem must be container related (QuickTime or mp4 does't >> matter for me) not codec related, since libraries are just dumping an >> encoded stream that is not touched or modified when saved to a file (or >> printed to stdout) inside the choosen container... >> Am I totaly missing the point? > > I'm not sure. But the basic problem here is that the ".mov" (or > ".mp4") file format was very badly designed, and is especially > ill-suited for what we are trying to do: Record incoming media streams > into a file. The "QuickTimeFileSink" class tries to do this as well > as it can, but the basic flaws of the file format makes it difficult. > Nonethess, it's possible that the "QuickTimeFileSink" implementation > can be improved, so feel free to take a look at it, and let us know if > you have any suggestions for improvements/bug fixes. Remember, You > Have Complete Source Code. Thanks a lot Ross. I'm digging deep into code from a couple of days... If I'll be able to do something usefull I'll write there ASAP. thanks again j From back2primitive at autistici.org Fri Jul 30 04:15:35 2010 From: back2primitive at autistici.org (jacopo) Date: Fri, 30 Jul 2010 13:15:35 +0200 Subject: [Live-devel] dump h264 video problem In-Reply-To: References: <4C50510F.5060300@autistici.org> <4C51808B.6050902@autistici.org> Message-ID: <4C52B457.40105@autistici.org> On 07/29/2010 10:14 PM, Ross Finlayson wrote: >> ]I've found an h264 video stream that I'm able to dump and play >> correctly >> rtsp://media.lscube.org/tests/tc.mov >> >> This one suffers the problems I was talking about: >> rtsp://streaming1.osu.edu/media2/ufsap/ufsap.mov >> >> Both have been dumped with >> ./openRTSP -t -d 20 -q >> command line (no fps and w/h has to be specified for firts one, for >> second none worked) > > The second stream's video has width 320 pixels, and height 240 pixels, > so you should specify those if you're trying to record it using > "openRTSP -q". (I'm not sure about the frame rate.) > > >> I'm not sure about one thing. H264VideoFileSink class that inserts 4 >> bytes long delimiter between NAL units, is used only when streaming not >> when receiving a strem, right? > > Wrong. Because it's a 'FileSink', it's used only when *receiving* a > stream. If "openRTSP" is used to receive a H.264/RTP stream normally > - without using the "-q" or "-4" options - then the > "H264VideoFileSink" class is used for the output. If, however, > "openRTSP" is used with the "-q" or "-4" options, then a different > 'FileSink' class - "QuickTimeFileSink" - is used. Because you're > using the "-q" option, this is what you are using. > > >> If so, the problem must be container related (QuickTime or mp4 does't >> matter for me) not codec related, since libraries are just dumping an >> encoded stream that is not touched or modified when saved to a file (or >> printed to stdout) inside the choosen container... >> Am I totaly missing the point? > > I'm not sure. But the basic problem here is that the ".mov" (or > ".mp4") file format was very badly designed, and is especially > ill-suited for what we are trying to do: Record incoming media streams > into a file. The "QuickTimeFileSink" class tries to do this as well > as it can, but the basic flaws of the file format makes it difficult. > Nonethess, it's possible that the "QuickTimeFileSink" implementation > can be improved, so feel free to take a look at it, and let us know if > you have any suggestions for improvements/bug fixes. Remember, You > Have Complete Source Code. Basically I've found that all streams that are not working are in some way out of sync. All of them fail at line: if (!ioState->syncOK(presentationTime)) at line 414 of QuickTimeFileSink.cpp (I hate posting code insed a mail...) And if the -y switch is passed to openRTSP the resulting dumped video is empty, sice all frames are discarded.. I've not really looked at the synkOK function, yet, but just wanted to ask if I'm the only one suffering from that beahviour or something is going wrong when determinating presentationTime or sync... Mplayer is using live555 as rtsp library, but it does not act like this (AFAIK) with h264, but often dumping mpeg4 videos result in an empty file... could that be related ? Thanks again to everyone... j From arang1978 at gmail.com Fri Jul 30 00:51:41 2010 From: arang1978 at gmail.com (Aranganathan Sankaradoss) Date: Fri, 30 Jul 2010 16:51:41 +0900 Subject: [Live-devel] for some RTSP URL the stream is not getting recorded Message-ID: hello friends, For some RTSP URL the video is not getting recorded. *Working RTSP URL* In my PC, I started the RTSP server using the following command ./live555MediaServer rtsp://192.10.2.9:8554/home/arang/Downloads/hbo.ts For this stream, I could record it record it using the following command. ./openRTSP rtsp://192.10.2.9:8554/home/arang/Downloads/hbo.ts *Not working RTSP URL* >From some other PC, the stream is sent in the following URL rtsp://114.205.1.110/liverepeater/camera.stream I could not record it using the following command ./openRTSP rtsp://114.205.1.110/liverepeater/camera.stream If you know the reason for the problem which I pace then please let me know. Your ideas will be useful for me. My ID is arang1978 at gmail.com Thanks and Regards, Arang. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 30 08:48:17 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 30 Jul 2010 08:48:17 -0700 Subject: [Live-devel] dump h264 video problem In-Reply-To: <4C52B457.40105@autistici.org> References: <4C50510F.5060300@autistici.org> <4C51808B.6050902@autistici.org> <4C52B457.40105@autistici.org> Message-ID: First, please trim your responses before posting them! (From now on, your posts will be moderated (just like the n00bs that use @gmail.com addresses).) >Basically I've found that all streams that are not working are in some >way out of sync. All of them fail at line: > >if (!ioState->syncOK(presentationTime)) >at line 414 of QuickTimeFileSink.cpp You have anough information (Complete Source Code!) to figure out why the "syncOK()" calls are always failing for the non-working streams. But it may be because these streams do not include RTCP "SR" packets (or if they do, there's a firewall somewhere that's blocking them). If that's the case, then these streams are non-compliant, and you will never be able to synchronize them. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jnoring at logitech.com Fri Jul 30 09:15:54 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Fri, 30 Jul 2010 09:15:54 -0700 Subject: [Live-devel] dump h264 video problem In-Reply-To: References: <4C50510F.5060300@autistici.org> <4C51808B.6050902@autistici.org> Message-ID: On Thu, Jul 29, 2010 at 1:14 PM, Ross Finlayson wrote: > I'm not sure. But the basic problem here is that the ".mov" (or ".mp4") > file format was very badly designed, and is especially ill-suited for what > we are trying to do: Record incoming media streams into a file. The > "QuickTimeFileSink" class tries to do this as well as it can, but the basic > flaws of the file format makes it difficult. Nonethess, it's possible that > the "QuickTimeFileSink" implementation can be improved, so feel free to take > a look at it, and let us know if you have any suggestions for > improvements/bug fixes. > Doubtful. I've worked with the mp4 file format for a few years now and it's just fine. The more likely problem is QuickTimeFileSink is a limited and basic mov/mp4 implementation, and Live555 is a streaming library, not a container library. If the OP wants nice files, they should use a library intended for writing mp4 files, like mp4v2. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 30 08:57:14 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 30 Jul 2010 08:57:14 -0700 Subject: [Live-devel] for some RTSP URL the stream is not getting recorded In-Reply-To: References: Message-ID: > For some RTSP URL the video is not getting recorded. >If you know the reason for the problem which I pace then please let me know. There's an answer to this question in the FAQ, which you were asked to read before you joined the mailing list! -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jul 30 10:10:10 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 30 Jul 2010 10:10:10 -0700 Subject: [Live-devel] dump h264 video problem In-Reply-To: References: <4C50510F.5060300@autistici.org> <4C51808B.6050902@autistici.org> Message-ID: >On Thu, Jul 29, 2010 at 1:14 PM, Ross Finlayson ><finlayson at live555.com> wrote: > >I'm not sure. But the basic problem here is that the ".mov" (or >".mp4") file format was very badly designed, and is especially >ill-suited for what we are trying to do: Record incoming media >streams into a file. The "QuickTimeFileSink" class tries to do this >as well as it can, but the basic flaws of the file format makes it >difficult. Nonethess, it's possible that the "QuickTimeFileSink" >implementation can be improved, so feel free to take a look at it, >and let us know if you have any suggestions for improvements/bug >fixes. > > >Doubtful. I've worked with the mp4 file format for a few years now >and it's just fine. The more likely problem is QuickTimeFileSink is >a limited and basic mov/mp4 implementation, and Live555 is a >streaming library, not a container library. If the OP wants nice >files, they should use a library intended for writing mp4 files, >like mp4v2. While I don't doubt that the "QuickTimeFileSink" implementation can be improved (perhaps using the "mp4v2" code as a guideline), the fact remains that the ".mov" (or ".mp4") file format is ill-suited for what we are trying to do: Record a file that properly represents incoming audio and video frames that are time-stamped. (There are also other things that I dislike about the file format, including the fact that the files themselves can't be streamed (because of the 'moov' metadata that needs to be received before you can do anything with such a file), nor can partially-received files be played at all. To paraphrase Jeremy's observation: The ".mov"/".mp4" fle format is a format for a media container, not a media stream.) But this is really beside the point, because this file format exists and is widespread, and people want to record incoming streams into it. So I would welcome any efforts to improve the "QuickTimeFileSink" class. Alternatively, if anyone wants to write a new class (ideally with a similar API to "QuickTimeFileSink") that works the same way, but using the "mp4v2" library instead of our code, then I would be interested in that as well. (I generally dislike having dependencies on third-party libraries, but I'm willing to consider *optional* code that does that.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien-devel at celeos.eu Fri Jul 30 11:04:16 2010 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Fri, 30 Jul 2010 20:04:16 +0200 Subject: [Live-devel] dump h264 video problem In-Reply-To: References: <4C50510F.5060300@autistici.org> <4C51808B.6050902@autistici.org> Message-ID: <1280513056.1855.4.camel@mnmsd-desktop> On Fri, 2010-07-30 at 10:10 -0700, Ross Finlayson wrote: > remains that the ".mov" (or ".mp4") file format is ill-suited for what > we are trying to do: Record a file that properly represents incoming > audio and video frames that are time-stamped. (There are also other > things that I dislike about the file format, including the fact that > the files themselves can't be streamed (because of the 'moov' metadata > that needs to be received before you can do anything with such a > file), nor can partially-received files be played at all. To > paraphrase Jeremy's observation: The ".mov"/".mp4" fle format is a > format for a media container, not a media stream.) Well, partially received mp4 files can be played like any "raw" video file (without container). IMO, the strength of mp4 files is seeking : you can jump at any timestamp in the file in constant time.