From rajeshbikram at wlink.com.np Thu Feb 1 02:45:23 2007 From: rajeshbikram at wlink.com.np (rajeshbikram at wlink.com.np) Date: Thu, 01 Feb 2007 15:45:23 +0500 Subject: [Live-devel] mulit threaded support. Message-ID: hello all, I manage to make multi threaded support for live555 library by the help of offical faq of live.com. But i am facing some problem. The dumped packet in file are ok (except few packet losses) from the all threads . The problem is CPU utilization is too high. I am using VLC, DARWIN and AXIS as RTSP server which send the stream continously. I think the problem might be in doEventLoop(). How can i optimize the CPU utilization. Any tricks out there with regards rajeshbikram From zjuchenjun at hotmail.com Thu Feb 1 04:12:31 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Thu, 1 Feb 2007 20:12:31 +0800 Subject: [Live-devel] "no-blocking fashion" in doGetNextFrame() Message-ID: Hi, In doGetNextFrame() member fuction of DeviceSource, I want to call "deliverFrame" in a non-blocking fashion, I wrote my code (follow the example http://lists.live555.com/pipermail/live-devel/2005-September/003276.html.) It works,but another problem came out: it returns immediately when "watchVarible==0"(no data is currntly available), but it still wait a long time even "watchVarible" already became non-zero. My purpose is implementing the "deliverFrame" as soon as possible when "watchVarible!=0". Could anyone help me? Thanks very much! Here is my code: void DeviceSource::doGetNextFrame() { envforH264->taskScheduler().doEventLoop(HasItemForH264); //HasItemForH264 is set non-zero in another thread after it filled the buffer deliverFrame(); } void DeviceSource::deliverFrame(){ if (!isCurrentlyAwaitingData()) return; // we're not ready for the data yet pthread_mutex_lock(mutexforH264); if(*HasItemForH264==99) { fFrameSize=*LengthForH264; //LengthForH264 is defined in another thread if (fFrameSize > fMaxSize) { fNumTruncatedBytes = fFrameSize - fMaxSize; fFrameSize = fMaxSize; } memcpy(fTo, BufferForH264, fFrameSize); //BufferForH264 is defined in another thread * HasItemForH264=0; } pthread_mutex_unlock(mutexforH264); usleep(100); // After delivering the data, inform the reader that it is now available: FramedSource::afterGetting(this); printf ("deliverFrame() is end !\n");} _________________________________________________________________ ???? Windows Live Mail? http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070201/70a10a79/attachment.html From bidibulle at operamail.com Thu Feb 1 07:54:23 2007 From: bidibulle at operamail.com (David Betrand) Date: Thu, 01 Feb 2007 16:54:23 +0100 Subject: [Live-devel] Problem with ourSourceAddressForMulticast() Message-ID: <20070201155423.B54A324742@ws5-3.us4.outblaze.com> Hello Ross, I recently investigated some strange problems to get a valid source IP address with some recent version of the library, which I didn't have with older versions. As you know ths is done using ourSourceAddressForMulticast() in GroupsockHelper Actually, ourSourceAddressForMulticast() tells me "This computer has an invalid IP address : 0x0". The full explanation of the failing is quite complex to explain so I prefer to summarize the important results : - Setting ReceivingInterfaceAddr and SendingInterfaceAddr to a value different from INADDR_ANY makes the multicast loopback trick fail. I guess this is normal on a regular Linux configuration, without multicast environment. Do you agree ? This means that (after a 5 second timeout) the secondary approach to get its source IP will be used : using getting first valid IP address from gethostname() followed by gethostbyname() - Getting a valid IP address from gethostname() followed by gethostbyname() doesn't work on most unix and linux systems as it only returns the first entry in /etc/hosts file : 127.0.0.1. And this IP address is rejected by badAddress(). So this means that the secondary plan also fails in my case ! -> I get the message "This computer has an invalid IP address : 0x0" So, is it reasonnable to set a global static variable for the source address. Something like ourAddress variable in ourSourceAddressForMulticast(): static netAddressBits ourAddress = 0; By default, It would be initialized with zero but would allow to be set to another value (for example ReceivingInterfaceAddr or SendingInterfaceAddr) Thanks in dvance. David -- _______________________________________________ Search for products and services at: http://search.mail.com Powered by Outblaze From xcsmith at rockwellcollins.com Thu Feb 1 08:45:30 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Thu, 1 Feb 2007 10:45:30 -0600 Subject: [Live-devel] how to run rtp client and server in one process? Message-ID: hi,all, I can run rtp client and server respective. Now I want to make my media bidirectional. But it seems difficult to make my codec chip under control in different process. So, how to run rtp source and sink in one process? Is it any test program? The "doEventLoop" is a block process, can I run source and sink with one "doEventLoop"? Will they conflict each other? You can run an RTSP client and RTSP server in the same application as long as they are on separate threads and do not communicate with eachother except through globals set in the library and they can use socket connections (client makes a connection to server in same app). If you use only one thread and your client contacts your server you will have a lockup. There's a mention about this in the FAQ and also here http://lists.live555.com/pipermail/live-devel/2006-December/005537.html. I asked Ross about this awhile ago on the mail list, maybe you can find it in the archives. Xochitl From finlayson at live555.com Thu Feb 1 08:57:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Feb 2007 08:57:20 -0800 Subject: [Live-devel] "no-blocking fashion" in doGetNextFrame() In-Reply-To: References: Message-ID: >In doGetNextFrame() member fuction of DeviceSource, I want to call >"deliverFrame" in a non-blocking fashion, > >I wrote my code >(follow >the example >http://lists.live555.com/pipermail/live-devel/2005-September/003276.html.) > >It works,but another problem came out: it returns immediately when >"watchVarible==0"(no data is currntly available), > >but it still wait a long time even "watchVarible" already became non-zero. > >My purpose is implementing the "deliverFrame" as soon as possible >when "watchVarible!=0". > >Could anyone help me? Thanks very much! > >Here is my code: > >void DeviceSource::doGetNextFrame() > { > >envforH264->taskScheduler().doEventLoop(HasItemForH264); //HasItemForH264 >is set non-zero in another thread after it filled the buffer > > deliverFrame(); > } The problem with this is that - if no new data is currently available - you will be executing the event loop forever, but the "HasItemForH264" will never get set, because nothing will ever call "deliverFrame()". Instead, the solution is for your *other* thread - the one that handles your H.264 encoding - to be the one that sets the "HasItemForH264" variable. > usleep(100); Don't do this - it will delay the whole application for 100ms, and nothing else will get done during this time. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070201/5d7a4497/attachment.html From finlayson at live555.com Thu Feb 1 11:13:14 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Feb 2007 11:13:14 -0800 Subject: [Live-devel] Problem with ourSourceAddressForMulticast() In-Reply-To: <20070201155423.B54A324742@ws5-3.us4.outblaze.com> References: <20070201155423.B54A324742@ws5-3.us4.outblaze.com> Message-ID: >- Setting ReceivingInterfaceAddr and SendingInterfaceAddr to a value >different from INADDR_ANY makes the multicast loopback trick fail. If that happens, then you have a more serious problem: you've stopped multicast from working! For multicast to work, your "ReceivingInterfaceAddr" - if not INADDR_ANY - must be set to the interface on which you have a route for 224.*. > I guess this is normal on a regular Linux configuration, without >multicast environment. A regular Linux configuration *does* have multicast - at least, a route for 224.*. >- Getting a valid IP address from gethostname() followed by >gethostbyname() doesn't work on most unix and linux systems as it >only returns the first entry in /etc/hosts file : 127.0.0.1. And >this IP address is rejected by badAddress(). That's not supposed to happen. The code is supposed to check through *all* of the addresses returned by "gethostbyname()", and use the first address that is not bad (and 127.0.0.1 is considered 'bad'). >So, is it reasonnable to set a global static variable for the source address. No. If the code cannot find the machine's source address - using either of the two methods (multicast loopback or gethostname()/gethostbyname()) - then you probably have more serious problems that would prevent other parts of the code from working properly. Allowing the programmer to 'paper over the problem' by specifying an address 'by hand' would likely cause more harm than good. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bidibulle at operamail.com Thu Feb 1 12:21:52 2007 From: bidibulle at operamail.com (David Betrand) Date: Thu, 01 Feb 2007 21:21:52 +0100 Subject: [Live-devel] Problem with ourSourceAddressForMulticast() Message-ID: <20070201202152.BEAA0CA0A4@ws5-11.us4.outblaze.com> Ross, I think you misunderstood me. My replies are inline. > If that happens, then you have a more serious problem: you've stopped > multicast from working! For multicast to work, your > "ReceivingInterfaceAddr" - if not INADDR_ANY - must be set to the > interface on which you have a route for 224.*. I'm not doing multicast at all, only unicast. But, each time a Groupsock is created a call of ourSourceAddressForMulticast is performed and thus some multicast sending/receiving also. And I really guess that 99% of computers of our beautiful planet will fail to read the multicast packet sent to guess our source address IF you set ReceivingInterfaceAddr and SendingInterfaceAddr to your ethernet IP address (example : 192.168.0.1). Can you try to slightly modify, for example, testOnDemandRTSPServer.cpp to add those two line in your main() : SendingInterfaceAddr = our_inet_addr("a.b.c.d"); ReceivingInterfaceAddr = our_inet_addr("a.b.c.d"); where "a.b.c.d" is a unicast IP address defined on your server and add also #include "GroupsockHelper.hh" You will see (I hope ;-)) that your app wait for 5 seconds after an answer and then swith to the secondary method to get its source IP. > A regular Linux configuration *does* have multicast - at least, a > route for 224.*. I would say : there is a route to a default gateway which probably as one. > > - Getting a valid IP address from gethostname() followed by > > gethostbyname() doesn't work on most unix and linux systems as it > > only returns the first entry in /etc/hosts file : 127.0.0.1. And > > this IP address is rejected by badAddress(). > > That's not supposed to happen. The code is supposed to check through > *all* of the addresses returned by "gethostbyname()", and use the > first address that is not bad (and 127.0.0.1 is considered 'bad'). The code is correct. The problem is that a Linux machine seems to answer with only the FIRST address it finds for the hostname, most of the time 127.0.0.1. I observed this on my Linux RedHat Enterprise 4 server, and crosscheked on some forums on internet. > > So, is it reasonnable to set a global static variable for the source address. > > No. If the code cannot find the machine's source address - using > either of the two methods (multicast loopback or > gethostname()/gethostbyname()) - then you probably have more serious > problems that would prevent other parts of the code from working > properly. Allowing the programmer to 'paper over the problem' by > specifying an address 'by hand' would likely cause more harm than > good. I partly agree with you. However, in my case, what I have to do to make my app working is to call ourAddressForMulticast() at the very beginning of my main() (before setting ReceivingInterfaceAddr and SendingInterfaceAddr). Not really "clean" either ... I'm just trying to show that, in some cases, the library's user that I am has to strugle for days and prefer to share his experience with all of you. But as I told you, I can now avoid my problem, so forget it if you prefer. Cheers, David -- _______________________________________________ Search for products and services at: http://search.mail.com Powered by Outblaze From finlayson at live555.com Thu Feb 1 13:09:44 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Feb 2007 13:09:44 -0800 Subject: [Live-devel] Problem with ourSourceAddressForMulticast() In-Reply-To: <20070201202152.BEAA0CA0A4@ws5-11.us4.outblaze.com> References: <20070201202152.BEAA0CA0A4@ws5-11.us4.outblaze.com> Message-ID: > > If that happens, then you have a more serious problem: you've stopped >> multicast from working! For multicast to work, your >> "ReceivingInterfaceAddr" - if not INADDR_ANY - must be set to the >> interface on which you have a route for 224.*. >I'm not doing multicast at all, only unicast. But, each time a >Groupsock is created a call of ourSourceAddressForMulticast is >performed and thus some multicast sending/receiving also. Once (the admittedly badly named) "ourSourceAddressForMulticast()" function succeeds in getting a proper IP address, it will just return that same address from then on (with no more multicast). > And I really guess that 99% of computers of our beautiful planet >will fail to read the multicast packet sent to guess our source >address IF you set ReceivingInterfaceAddr and SendingInterfaceAddr >to your ethernet IP address (example : 192.168.0.1). Well, "99% of computers of our beautiful planet" will have no need to set these addresses at all, because they have only one network interface. The real question here (which I don't know the answer to) is: If you set these addresses to a (valid) local IP address, then why does multicast loopback fail, and can this be fixed? > > > - Getting a valid IP address from gethostname() followed by >> > gethostbyname() doesn't work on most unix and linux systems as it >> > only returns the first entry in /etc/hosts file : 127.0.0.1. And >> > this IP address is rejected by badAddress(). >> >> That's not supposed to happen. The code is supposed to check through >> *all* of the addresses returned by "gethostbyname()", and use the >> first address that is not bad (and 127.0.0.1 is considered 'bad'). >The code is correct. The problem is that a Linux machine seems to >answer with only the FIRST address it finds for the hostname, most >of the time 127.0.0.1. I observed this on my Linux RedHat Enterprise >4 server, and crosscheked on some forums on internet. Do you know of any way to work around this, or else know of some alternative way to look up a valid IP address (rather than by explicitly parsing the /etc/hosts file, which would be gross) that will work on Linux systems (and not break on other systems)? If so, I could add it - as a third mechanism to try - to the "ourSourceAddressForMulticast()" code. I want to come up with code that works. Just throwing up my hands and saying "if this code doesn't work, here's how to hard-wire the address yourself" is not an acceptable solution (it's the ultimate in non-portable code :-). Of course, this is source code, so if people really want to do this, they can. I just don't want to encourage it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From victor_l2000 at hotmail.com Thu Feb 1 13:57:22 2007 From: victor_l2000 at hotmail.com (Victor Lee) Date: Thu, 01 Feb 2007 13:57:22 -0800 Subject: [Live-devel] synchronization problem with testOnDemandRTSPServer and data source Message-ID: Hi All, When the testOnDemandRTSPServer reads a stream from a file, it knows the time to read and the amount of data it needs. Now I want to connect the server to encoder. The encoder creates the source steam data in a fixed speed, and this data is finally passed to the RTSP server. When i am trying to implement this, i found there is a synchronization problem. I have the following questions and hope you can help me: 1. Is testOnDemandRTSPServer the right one i should use for my application? If not, what should i use? 2. how can we control the speed in testOnDemandRTSPServer so that it is of the same speed as the encoder's speed. I found that the speed of the encoder (TransportStream, with a speed of about 770k bytes/s) is faster than the process speed in testOnDemandRTSPServer, whose speed is about 712k bytes/s . But when i use VLC to receive the encoder's data, there is no synchronization problem with the speed of the encoder and VLC. Any suggestions are welcome! Thank you very much for your help in advance! Victor _________________________________________________________________ FREE online classifieds from Windows Live Expo – buy and sell with people you know http://clk.atdmt.com/MSN/go/msnnkwex0010000001msn/direct/01/?href=http://expo.live.com?s_cid=Hotmail_tagline_12/06 From xcsmith at rockwellcollins.com Thu Feb 1 14:07:35 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Thu, 1 Feb 2007 16:07:35 -0600 Subject: [Live-devel] Problem with ourSourceAddressForMulticast() Message-ID: Do you know of any way to work around this, or else know of some alternative way to look up a valid IP address (rather than by explicitly parsing the /etc/hosts file, which would be gross) that will work on Linux systems (and not break on other systems)? If so, I could add it - as a third mechanism to try - to the "ourSourceAddressForMulticast()" code. Re: I don't know if this will work, but I have computers which I want to use eth1 instead of eth0 and I don't want to put a hardcoded IP for every machine I run on. I hacked up a small routine based on "ourSourceAddressForMulticast" to run at the start of my application which uses ifaddrs.h "getifaddrs()" to get the interfaces, which I think might use kernell calls to get the list of interfaces, and not the /etc/hosts file. I am using Linux, and a very brief google search tells me that ifaddrs.h is not part of glibc and is required for libpcap, so maybe it is on windows too? When my network drive is back online I can post the function for your evaluation if you think the idea has potential. Xochitl From bidibulle at operamail.com Thu Feb 1 14:28:28 2007 From: bidibulle at operamail.com (David Betrand) Date: Thu, 01 Feb 2007 23:28:28 +0100 Subject: [Live-devel] Problem with ourSourceAddressForMulticast() Message-ID: <20070201222828.917D9CA0A4@ws5-11.us4.outblaze.com> > Once (the admittedly badly named) "ourSourceAddressForMulticast()" > function succeeds in getting a proper IP address, it will just return > that same address from then on (with no more multicast). Right. I supppose you understood that I didn't remind this because it never succeeds in my case. > Well, "99% of computers of our beautiful planet" will have no need to > set these addresses at all, because they have only one network > interface. One point for you here ! Unfortunately, I'm in "rest of the world" team > The real question here (which I don't know the answer to) is: If you > set these addresses to a (valid) local IP address, then why does > multicast loopback fail, and can this be fixed? Agreed. And really dont know why it doesn't succeed. All I can say is that all servers on wich I deployed my app have apparently the same issue (all on the same hardware and OS baseline, though). Just out of curiosity, I'm very curious to know if my little test in testOnDemandRTSPServer works with you. Once you have 5 minutes to test this of course. If we both really don't know what happens, let's forget this. Maybe one day someone will get the same problem and find out the reason. > Do you know of any way to work around this, or else know of some > alternative way to look up a valid IP address (rather than by > explicitly parsing the /etc/hosts file, which would be gross) that > will work on Linux systems (and not break on other systems)? If so, > I could add it - as a third mechanism to try - to the > "ourSourceAddressForMulticast()" code. Unfortunately, no. > I want to come up with code that works. Just throwing up my hands > and saying "if this code doesn't work, here's how to hard-wire the > address yourself" is not an acceptable solution (it's the ultimate in > non-portable code :-). Of course, this is source code, so if people > really want to do this, they can. I just don't want to encourage it. Were are on the same wave length on this. David -- _______________________________________________ Search for products and services at: http://search.mail.com Powered by Outblaze From mbernal at dif.um.es Thu Feb 1 16:53:45 2007 From: mbernal at dif.um.es (Manuel Bernal Llinares) Date: Fri, 2 Feb 2007 01:53:45 +0100 Subject: [Live-devel] Interface selection on the server Message-ID: <200702020153.45520.mbernal@dif.um.es> This is related to last e-mails about ourSourceAddressForMulticast() but most about the ability of picking a specific interface. I have a linux (I prefer Debian but it's a Suse) machine with two IPs from different networks on the same interface and the liveMedia modified (with SRTP, MIKEY, and so on) running on it. I'm trying to run to servers on the same machine, one of them on eth0 and the other on eth0:0. I wrote some lines in ourSourceAddressForMulticast for the server to have the ability of selecting an interface in this way: the first time this method is called it checks if a source IP has been set for the server and, instead of using the multicast trick, it takes this IP and it sets this address as the source address for later calls to this method; otherwise it would use the original ways of guessing the source address. Also, I wrote code to change ReceivingInterfaceAddr and SendingInterfaceAddr to be the same IP address I set for source address. Then I run the server with the source address I want it to use as a command line parameter and it announces the streams using this address with no issue... but... when a client comes, after the first SETUP command I see a great "segmentation fault" from the server :S I think it's a problem of getStreamParameters() call in handleCmd_SETUP, because the datagram socket seems not to be created correctly, but I don't know why yet. Any idea? Maybe I lost something after hours and hours staring at the screen of my laptop :D Thanks :) Manuel. --------- Seems a computer engineer, a systems analyst, and a programmer were driving down a mountain when the brakes gave out. They screamed down the mountain, gaining speed, but finally managed to grind to a halt, more by luck than anything else, just inches from a thousand foot drop to jagged rocks. They all got out of the car: The computer engineer said, "I think I can fix it." The systems analyst said, "No, no, I think we should take it into town and have a specialist look at it." The programmer said, "OK, but first I think we should get back in and see if it does it again." From rishikerala at gmail.com Thu Feb 1 18:51:25 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Fri, 2 Feb 2007 11:51:25 +0900 Subject: [Live-devel] Trick mode---please give me Message-ID: <4ba29cc0702011851w2345fcbehcd9034188d3f003e@mail.gmail.com> Hi all, In trick mode option.. there i am getting packet of size 1128 instead of 1316. please give some suggetion y it is so.. I need to pass this to the player where I allocate a buffer for 1316. I am using live media version #define LIVEMEDIA_LIBRARY_VERSION_STRING "2007.01.17" #define LIVEMEDIA_LIBRARY_VERSION_INT 1168992000 Please give me some suggestions.. Rgds Rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070201/be428dda/attachment.html From zjuchenjun at hotmail.com Thu Feb 1 19:45:46 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Fri, 2 Feb 2007 11:45:46 +0800 Subject: [Live-devel] "no-blocking fashion" in doGetNextFrame() Message-ID: Hi Ross, Maybe you have misunderstood, In fact my "HasItemForH264" variable is set in another thread - the one that handles your H.264 encoding(I mentioned it in my code). My problem is "HasItemForH264" variable is set to be non-zero in another thread, but event loop seems not respond immediately, it delay some time ,then implemented "deliverFrame". My purpose is implementing the "deliverFrame" as soon as possible when "HasItemForH264!=0". Thanks for your help :) Date: Thu, 1 Feb 2007 08:57:20 -0800To: live-devel at ns.live555.comFrom: finlayson at live555.comSubject: Re: [Live-devel] "no-blocking fashion" in doGetNextFrame() In doGetNextFrame() member fuction of DeviceSource, I want to call "deliverFrame" in a non-blocking fashion, I wrote my code (follow the example http://lists.live555.com/pipermail/live-devel/2005-September/003276.html.) It works,but another problem came out: it returns immediately when "watchVarible==0"(no data is currntly available), but it still wait a long time even "watchVarible" already became non-zero. My purpose is implementing the "deliverFrame" as soon as possible when "watchVarible!=0". Could anyone help me? Thanks very much! Here is my code: void DeviceSource::doGetNextFrame() { envforH264->taskScheduler().doEventLoop(HasItemForH264); //HasItemForH264 is set non-zero in another thread after it filled the buffer deliverFrame(); } The problem with this is that - if no new data is currently available - you will be executing the event loop forever, but the "HasItemForH264" will never get set, because nothing will ever call "deliverFrame()". Instead, the solution is for your *other* thread - the one that handles your H.264 encoding - to be the one that sets the "HasItemForH264" variable. usleep(100); Don't do this - it will delay the whole application for 100ms, and nothing else will get done during this time.-- Ross FinlaysonLive Networks, Inc.http://www.live555.com/ _________________________________________________________________ ???? Windows Live Mail? http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070201/a7034c65/attachment.html From zhouh31415 at 163.com Thu Feb 1 20:00:27 2007 From: zhouh31415 at 163.com (=?gbk?B?1ty66w==?=) Date: Fri, 2 Feb 2007 12:00:27 +0800 (CST) Subject: [Live-devel] thanks, xcsmith, I can run source and sink in same application now! Message-ID: <30876644.1857541170388827911.JavaMail.root@bj163app44.163.com> I can run the rtp client and server at the same time right now. I don't use RTSP protocol, but just run sink and source module with one doEventLoop. I traced the program that I found you just need be careful of using getNextFrame() function. And you must assure you read and write media data with no conflict. I'm sorry for my poor english. zhouhong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070201/4d70060c/attachment.html From TAYK0004 at ntu.edu.sg Thu Feb 1 20:17:32 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Fri, 2 Feb 2007 12:17:32 +0800 Subject: [Live-devel] Multicasting Message-ID: <438567054C073949AEBE5A28B83E7DE133FCCA@MAIL21.student.main.ntu.edu.sg> Hi guys, I have done my streamer and currently testing it. I have some technical questions on multicasting. I am using a wireless router (access point) connected to my pc. My streamer will run in the PC and send to the multicasting address. Then my pda or laptop which is also connected to the router wirelessly will receive the data from the multicast address. My questions are: 1) My wireless router is also conenct to the Internet, can I access the multicast data from a remote location if i am connected to the Internet as well. Or is the multicasting restricted to within my access point network. 2) If I wish to multicast to remote network, isit possible? Many thanks in advanced. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070201/227e1be0/attachment.html From Ow.Mun.Heng at wdc.com Thu Feb 1 21:26:25 2007 From: Ow.Mun.Heng at wdc.com (Ow Mun Heng) Date: Fri, 02 Feb 2007 13:26:25 +0800 Subject: [Live-devel] Multicasting In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FCCA@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FCCA@MAIL21.student.main.ntu.edu.sg> Message-ID: <1170393985.29377.79.camel@neuromancer.home.net> On Fri, 2007-02-02 at 12:17 +0800, #TAY KOON HWEE# wrote: > Hi guys, > > I have done my streamer and currently testing it. I have some > technical questions on multicasting. > > I am using a wireless router (access point) connected to my pc. My > streamer will run in the PC and send to the multicasting address. Then > my pda or laptop which is also connected to the router wirelessly will > receive the data from the multicast address. > > My questions are: > > 1) My wireless router is also conenct to the Internet, can I access > the multicast data from a remote location if i am connected to the > Internet as well. Or is the multicasting restricted to within my > access point network. > > 2) If I wish to multicast to remote network, isit possible? > You will need to get a multicast address and I think it's called the M-BONE? From zhouh31415 at 163.com Thu Feb 1 22:43:50 2007 From: zhouh31415 at 163.com (=?gbk?B?1ty66w==?=) Date: Fri, 2 Feb 2007 14:43:50 +0800 (CST) Subject: [Live-devel] Multicasting In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FCCA@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FCCA@MAIL21.student.main.ntu.edu.sg> Message-ID: <1716848067.2998221170398630680.JavaMail.root@bj163app125.163.com> ?2007-02-02?#TAY KOON HWEE# ??? Hi guys, I have done my streamer and currently testing it. I have some technical questions on multicasting. I am using a wireless router (access point) connected to my pc. My streamer will run in the PC and send to the multicasting address. Then my pda or laptop which is also connected to the router wirelessly will receive the data from the multicast address. My questions are: 1) My wireless router is also conenct to the Internet, can I access the multicast data from a remote location if i am connected to the Internet as well. Or is the multicasting restricted to within my access point network. 2) If I wish to multicast to remote network, isit possible? Many thanks in advanced. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070201/85a91ffd/attachment-0001.html From sademperor at gmail.com Thu Feb 1 22:46:23 2007 From: sademperor at gmail.com (LL Wang) Date: Fri, 2 Feb 2007 14:46:23 +0800 Subject: [Live-devel] Problem on live video source Message-ID: Hi, I would like to modified the testMPEG4VIdeoStreamer.* to streaming live video. I have already read the FAQ , but I still do not understand how to begin. It's so kind of you if you would tell me some more advice. Thanks. Frank Peking, China -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070201/923904f9/attachment.html From zhouh31415 at 163.com Thu Feb 1 23:00:37 2007 From: zhouh31415 at 163.com (=?gbk?B?1ty66w==?=) Date: Fri, 2 Feb 2007 15:00:37 +0800 (CST) Subject: [Live-devel] Multicasting In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FCCA@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FCCA@MAIL21.student.main.ntu.edu.sg> Message-ID: <16333408.9197211170399637435.JavaMail.root@bj163app73.163.com> Yes, you can. But, First, your wireless router must support multicast, you should set it allow multicast. Second, becouse your PC is in the lan, you must bind your port on the router. Third, your multicast IP must set from 224.0.1.0 to 238.255.255.255. ?2007-02-02?#TAY KOON HWEE# ??? Hi guys, I have done my streamer and currently testing it. I have some technical questions on multicasting. I am using a wireless router (access point) connected to my pc. My streamer will run in the PC and send to the multicasting address. Then my pda or laptop which is also connected to the router wirelessly will receive the data from the multicast address. My questions are: 1) My wireless router is also conenct to the Internet, can I access the multicast data from a remote location if i am connected to the Internet as well. Or is the multicasting restricted to within my access point network. 2) If I wish to multicast to remote network, isit possible? Many thanks in advanced. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070201/269c3e34/attachment.html From yunjnz at yahoo.com Thu Feb 1 23:25:37 2007 From: yunjnz at yahoo.com (Sean) Date: Thu, 1 Feb 2007 23:25:37 -0800 (PST) Subject: [Live-devel] About long time wait when server isn't available In-Reply-To: Message-ID: <340495.60898.qm@web35815.mail.mud.yahoo.com> --- Ross Finlayson wrote: > >is it OK for the RTSPClient work under non-blocking > mode? > > This would be nice to do, but would be a non-trivial > change to the > code. It might get done someday, but probably not > soon. Could you please give me some clue for adding this feature? I noticed that the program is always blocked when calling connect in the openConnectionFromURL function if the server isn't available, is it OK for just make this function non-blocking? Thanks a lot. Sean. > -- > > 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 > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From finlayson at live555.com Thu Feb 1 23:27:47 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Feb 2007 23:27:47 -0800 Subject: [Live-devel] "no-blocking fashion" in doGetNextFrame() In-Reply-To: References: Message-ID: >My problem is "HasItemForH264" variable is set to be non-zero in >another thread, but event loop seems not respond immediately, >it delay some time ,then I suspect that you're running into the issue described here: http://lists.live555.com/pipermail/live-devel/2006-March/004192.html The solution outlined there may work in your case also. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070201/66c687a3/attachment.html From finlayson at live555.com Fri Feb 2 00:09:03 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Feb 2007 00:09:03 -0800 Subject: [Live-devel] Trick mode---please give me In-Reply-To: <4ba29cc0702011851w2345fcbehcd9034188d3f003e@mail.gmail.com> References: <4ba29cc0702011851w2345fcbehcd9034188d3f003e@mail.gmail.com> Message-ID: >In trick mode option.. there i am getting packet of size 1128 instead of 1316. This is not a problem. Usually, 1316 bytes (i.e., 7 188-byte Transport 'packets') are packed within each outgoing network packet. However, if the total number of Transport 'packets' is not an even multiple of 7, then the last network packet will contain fewer than 7 Transport 'packets'. This is also true when you do trick mode (fast forward or reverse play). In trick mode, you're sending a new sequence of Transport 'packets' that, once again, may not be an even multiple of 7. In your case, you're seeing a network packet that contains 6*188 == 1128 bytes. There is absolutely nothing wrong here. Receivers should be prepared to receive any number (>0) of Transport 'packets' within each network packet. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From victor_l2000 at hotmail.com Fri Feb 2 16:12:35 2007 From: victor_l2000 at hotmail.com (Victor Lee) Date: Fri, 02 Feb 2007 16:12:35 -0800 Subject: [Live-devel] Urgent help needed! Message-ID: Hi Ross, We are trying to implement our system using livemedia for the RTSP server part. I did not work long with livemedia, but have done something with this great library. We hope that we can continue use livemedia lib. The data flow for me is as follows: MPEG file -> VLC, streaming out with RTP to a multicast address, output in MPEG TS format -> RTP client receive the RTP packet, send data to testOnDemandRTSPServer. In testOnDemandRTSPServer, we tried to modify ByteStreamFileSource, and let it accept the data sending from RTP client, instead of reading from a file. Problem: the speed of reading in ByteStreamFileSource is slower than the speed that RTP client sending out data, thus some data will be lost before it can be processed in ByteStreamFileSource. When the testOnDemandRTSPServer reads a stream from a file, it knows the time to read and the amount of data it needs. The RTP Client who is sending the source steam data out should be in a fixed speed. Could you please answer my following questions and give me some suggestions? 1. Is testOnDemandRTSPServer/ByteStreamFileSource the right one I should use to implement my application? If not, what should I use? Should I use the way described in your FAQ about testOnDemandRTSPServer taking input from a live source instead of from a file? 2. Can we control the speed in testOnDemandRTSPServer so that it is of the same speed as the encoder's speed? Any suggestions are welcome! Thanks for your help and have a great weekend! Victor _________________________________________________________________ FREE online classifieds from Windows Live Expo – buy and sell with people you know http://clk.atdmt.com/MSN/go/msnnkwex0010000001msn/direct/01/?href=http://expo.live.com?s_cid=Hotmail_tagline_12/06 From morgan.torvolt at gmail.com Fri Feb 2 22:07:21 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Sat, 3 Feb 2007 10:07:21 +0400 Subject: [Live-devel] Urgent help needed! In-Reply-To: References: Message-ID: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> Hi As your application does not need timing data to work properly (VLC makes sure the data leaves the source at the right time), you could just remove the MPEG2TransprtStreamFramer from the chain in your RTSPserver. That will make the data retransmitted as soon as it arrives. You find this in MPEG2TransportFileServerMediaSubsession.cpp // Create a framer for the Transport Stream: return MPEG2TransportStreamFramer::createNew(envir(), fileSource); instead, do this: // Create a framer for the Transport Stream: return fileSource; If it is the proper way of doing it, I can't say, but it works. What happes is that the fDurationInMicroseconds is not set, causing the server to transmit as soon as it can. -Morgan- On 03/02/07, Victor Lee wrote: > Hi Ross, > > We are trying to implement our system using livemedia for the RTSP server > part. I did not work long with livemedia, but have done something with this > great library. We hope that we can continue use livemedia lib. > > The data flow for me is as follows: > > MPEG file -> VLC, streaming out with RTP to a multicast address, output in > MPEG TS format -> RTP client receive the RTP packet, send data to > testOnDemandRTSPServer. > In testOnDemandRTSPServer, we tried to modify ByteStreamFileSource, and let > it accept the data sending from RTP client, instead of reading from a file. > > Problem: the speed of reading in ByteStreamFileSource is slower than the > speed that RTP client sending out data, thus some data will be lost before > it can be processed in ByteStreamFileSource. > > When the testOnDemandRTSPServer reads a stream from a file, it knows the > time to read and the amount of data it needs. The RTP Client who is sending > the source steam data out should be in a fixed speed. > > Could you please answer my following questions and give me some suggestions? > > 1. Is testOnDemandRTSPServer/ByteStreamFileSource the right one I should use > to implement my application? If not, what should I use? > Should I use the way described in your FAQ about testOnDemandRTSPServer > taking input from a live source instead of from a file? > > 2. Can we control the speed in testOnDemandRTSPServer so that it is of the > same speed as the encoder's speed? > > Any suggestions are welcome! Thanks for your help and have a great weekend! > > Victor > > _________________________________________________________________ > FREE online classifieds from Windows Live Expo ? buy and sell with people > you know > http://clk.atdmt.com/MSN/go/msnnkwex0010000001msn/direct/01/?href=http://expo.live.com?s_cid=Hotmail_tagline_12/06 > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > From finlayson at live555.com Fri Feb 2 22:34:13 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Feb 2007 22:34:13 -0800 Subject: [Live-devel] Urgent help needed! In-Reply-To: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> References: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> Message-ID: >As your application does not need timing data to work properly (VLC >makes sure the data leaves the source at the right time), you could >just remove the MPEG2TransprtStreamFramer from the chain in your >RTSPserver. That will make the data retransmitted as soon as it >arrives. > >You find this in MPEG2TransportFileServerMediaSubsession.cpp > > // Create a framer for the Transport Stream: > return MPEG2TransportStreamFramer::createNew(envir(), fileSource); > >instead, do this: > > // Create a framer for the Transport Stream: > return fileSource; > >If it is the proper way of doing it, I can't say, but it works. What >happes is that the fDurationInMicroseconds is not set, causing the >server to transmit as soon as it can. Unfortunately this will also prevent "fPresentationTime" from being set, which will in turn lead to incorrect RTP timestamps. For MPEG Transport Streams, however, that may not be a huge problem, because the Transport Stream data itself contains the timing (PCR) information that receivers use to properly play the stream. However, it will cause RTCP statistics (jitter, etc.) to not get reported correctly. The real puzzle here, though, is: Why is "MPEG2TransportStreamFramer" apparently generating incorrect average durations for Victor Lee's Transport Streams? "MPEG2TransportStreamFramer" uses the PCR timestamps in the source Transport Stream data to generate duration estimates, thereby pacing the streaming of the outgoing data. If the stream is getting sent too slowly (on average), then this suggests that the PCR timestamps are incorrect. But if that's the case, then how is a media player able to play the audio/video at the correct pace when it plays from the file stored locally? It would be helpful if Victor Lee would put one of his Transport Stream files on a web site, and post the URL, so we can download the file and check it for ourselves. (BTW, I think that Victor Lee's configuration MPEG TS file -> VLC -> RTP multicast -> RTP multicast receiver -> testOnDemandRTSPServer (modified) is ridiculous. It would be far simpler for him to just use the "LIVE555 Media Server" to stream his MPEG TS files. That's all he'd need.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From binli1115 at 163.com Sat Feb 3 17:04:38 2007 From: binli1115 at 163.com (binli1115) Date: Sun, 4 Feb 2007 09:04:38 +0800 (CST) Subject: [Live-devel] I have a question Message-ID: <22080711.30661170551078746.JavaMail.root@bj163app64.163.com> hi every: I want to know the format of the Annex B of the file of h.264.Is there someone knows? Good luck.Thanks. yours bin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070203/5404c1f9/attachment-0001.html From victor_l2000 at hotmail.com Sat Feb 3 23:09:00 2007 From: victor_l2000 at hotmail.com (Victor Lee) Date: Sat, 03 Feb 2007 23:09:00 -0800 Subject: [Live-devel] Urgent help needed! Message-ID: Hi Morgan and Ross, Thank you very much for taking your WEEKEND time to answer my questions! I appreciate your helpful information! Ross: The configuration i gave to you in my email is only a simulation for my application. It looks ridiculous: now that i want to use Livemedia RTSP server, why still take so much trouble multicast it, receive it and then use RTSP server to cast it again. Well, this is the only way we can think of now to simulate our application, and if this simulation works, our task also works. Actually, i need to support MPEG2 ES Video and TS, MPEG4 ES Video, maybe at the same time with one RTSP server. This is why i want to prove to my boss and persuade him that livemedia is the right library we should use. In my simulation, i used VLC to multicast a source stream with RTP. When using VLC to streaming out, only MPEG TS can be chosen. The input file to VLC is testv.mpg, which is a MPEG2 ES Video file. What i want to implement is to use RTSP server to receive the live streams sending form IP encoders. I read the FAQ in livemedia about changing testOnDemandRTSPServer taking input from a live source instead of from a file. I thought using testOnDemandRTSPServer and just change ByteStreamFileSource would be a quick and easy way to my solution. But i met the synchronization problem here. I think the problem is that when reading from file, it knows when to read and how much to read, and controled by its own pace/clock; while reading from live source, it just process the data it reived. Ross: Could you provide more detail information on how to use testOnDemandRTSPServer and make it taking input from a live source (IP Camera, or receiving from a socket) directly instead of from a file? I am sure that would be very useful to my application. Thanks! For Morgan's suggestion, i will think in detail and test if it works for my case. Thanks again to you all and have a nice weekend! Victor >From: Ross Finlayson >Reply-To: LIVE555 Streaming Media - development & >use >To: LIVE555 Streaming Media - development & use > >Subject: Re: [Live-devel] Urgent help needed! >Date: Fri, 2 Feb 2007 22:34:13 -0800 > > >As your application does not need timing data to work properly (VLC > >makes sure the data leaves the source at the right time), you could > >just remove the MPEG2TransprtStreamFramer from the chain in your > >RTSPserver. That will make the data retransmitted as soon as it > >arrives. > > > >You find this in MPEG2TransportFileServerMediaSubsession.cpp > > > > // Create a framer for the Transport Stream: > > return MPEG2TransportStreamFramer::createNew(envir(), fileSource); > > > >instead, do this: > > > > // Create a framer for the Transport Stream: > > return fileSource; > > > >If it is the proper way of doing it, I can't say, but it works. What > >happes is that the fDurationInMicroseconds is not set, causing the > >server to transmit as soon as it can. > >Unfortunately this will also prevent "fPresentationTime" from being >set, which will in turn lead to incorrect RTP timestamps. For MPEG >Transport Streams, however, that may not be a huge problem, because >the Transport Stream data itself contains the timing (PCR) >information that receivers use to properly play the stream. However, >it will cause RTCP statistics (jitter, etc.) to not get reported >correctly. > >The real puzzle here, though, is: Why is "MPEG2TransportStreamFramer" >apparently generating incorrect average durations for Victor Lee's >Transport Streams? "MPEG2TransportStreamFramer" uses the PCR >timestamps in the source Transport Stream data to generate duration >estimates, thereby pacing the streaming of the outgoing data. If the >stream is getting sent too slowly (on average), then this suggests >that the PCR timestamps are incorrect. But if that's the case, then >how is a media player able to play the audio/video at the correct >pace when it plays from the file stored locally? > >It would be helpful if Victor Lee would put one of his Transport >Stream files on a web site, and post the URL, so we can download the >file and check it for ourselves. > >(BTW, I think that Victor Lee's configuration > MPEG TS file -> VLC -> RTP multicast -> RTP multicast >receiver -> testOnDemandRTSPServer (modified) >is ridiculous. It would be far simpler for him to just use the >"LIVE555 Media Server" to >stream his MPEG TS files. That's all he'd need.) > >-- > >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 _________________________________________________________________ Invite your Hotmail contacts to join your friends list with Windows Live Spaces http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us From rajeshbikram at wlink.com.np Sat Feb 3 23:16:58 2007 From: rajeshbikram at wlink.com.np (Rajesh Bikram R.C.) Date: Sun, 04 Feb 2007 13:01:58 +0545 Subject: [Live-devel] urgent need Help. Message-ID: <45C5886A.4020808@wlink.com.np> Dear Ross, Why the CPU utilization of openRTSP program is high. I tested in mips processor(400MHZ) it takes about 5-7% of CPU utilization. I need to optimize the CPU utilization. I found out that even though there is no data transmitted from the rtsp sever. The select() function in do event loop doesn't go to sleep.Is the IO mulitiplexing is blocking or non blocking mode?. How i can at least optimize the cpu performance coz i am running many RTSP Client based on live555 library. hope you will help me. with regards Rajes From zjuchenjun at hotmail.com Sun Feb 4 00:07:19 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Sun, 4 Feb 2007 16:07:19 +0800 Subject: [Live-devel] call doGetNextFrame() problem! Message-ID: Hi Ross, I am sorry to trouble you again! I hope this will be the last question. I think I have solved the doEventLoop "delay" problem with your helps,thanks. But another problem came out: The program runs fine at the beginning. However, a few minutes later, the doGetNextFrame() function is called abnormal: After delivering the data, it delays a few seconds, and then call doGetNextFrame(). In a normal way, I think it should be called immediately after delivering the data.This lead to my client's playing speed slow down. I have tried both mplayer and openrtsp in the client, and got the same result. Can you give me some hints? Thanks My code: void H264VideoStreamDiscreteFramer::doGetNextFrame() { dummyTask(Null); envforH264->taskScheduler().doEventLoop(HasItemForH264); deliverFrame(); } void H264VideoStreamDiscreteFramer::deliverFrame(){ if (!isCurrentlyAwaitingData()) return; // we're not ready for the data yet pthread_mutex_lock(mutexforH264); if(*HasItemForH264==99){ fFrameSize=*LengthForH264; //LengthForH264 is defined in another thread if (fFrameSize > fMaxSize) { fNumTruncatedBytes = fFrameSize - fMaxSize; fFrameSize = fMaxSize; } memcpy(fTo, BufferForH264, fFrameSize); //BufferForH264 is defined in another thread * HasItemForH264=0; } pthread_mutex_unlock(mutexforH264); // After delivering the data, inform the reader that it is now available: FramedSource::afterGetting(this); } _________________________________________________________________ ?? Windows Live Messenger ?????? http://get.live.com/messenger/overview -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070204/f42acf0e/attachment.html From finlayson at live555.com Sun Feb 4 00:42:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 4 Feb 2007 00:42:15 -0800 Subject: [Live-devel] urgent need Help. In-Reply-To: <45C5886A.4020808@wlink.com.np> References: <45C5886A.4020808@wlink.com.np> Message-ID: >Why the CPU utilization of openRTSP program is high. I tested in mips >processor(400MHZ) it takes about 5-7% of CPU utilization. I need to >optimize the CPU utilization. I found out that even though there is no >data transmitted from the rtsp sever. The select() function in do event >loop doesn't go to sleep.Is the IO mulitiplexing is blocking or non >blocking mode?. How i can at least optimize the cpu performance coz i am >running many RTSP Client based on live555 library. Only you can figure this out, because only you know the details of your system. Also, Remember, You Have Complete Source Code. One point, however: On Windows (especially versions of Windows prior to XP), the "select()" routine sometimes performs badly. if you're running Windows, and are encountering scaling/performance problems, then you may get better results by running Unix (including Linux) instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From weiyutao36 at 163.com Sun Feb 4 04:21:36 2007 From: weiyutao36 at 163.com (weiyutao36) Date: Sun, 4 Feb 2007 20:21:36 +0800 (CST) Subject: [Live-devel] H.264 streaming Message-ID: <26790516.1173891170591696258.JavaMail.root@bj163app60.163.com> Hi Engin, When I studied your codes, I had some questions and I did not understood some part of the codes. InH264RTPStreamFramer::doGetNextFrame(), I am not clear how this function works: I think it first callsthe FramedSource::getNextFrame() function and at the end of this function, it callsByteStreamFileSource::doGetNextFrame() to read data from the file that we want to stream and excutesthe corresponding "afterGetting" function. After getting the RTP packet header, it continues to get thefollowing NALU data. But I am not clear how the codes continue to do the loop---getting rtp header,getting nalu........ Particularly, I am not clear what FramedSource::afterGetting(this) inH264RTPStreamFramer::afterGettingNALU1() does. I did not know its funtion.Also, I am not clear how H264RTPStreamFramer interacts with H264VideoRTPSink. Could you pleasegive me some explanations? Thank you. ps: I sent a mail to you on Jan 31st, 2006 to your mailbox at gmail.com, have you received the mail? Igive it to you as an attachment with this mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070204/4344bbd2/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: weiyutao_20060131.txt Url: http://lists.live555.com/pipermail/live-devel/attachments/20070204/4344bbd2/attachment.txt From rishikerala at gmail.com Sun Feb 4 20:59:29 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Mon, 5 Feb 2007 13:59:29 +0900 Subject: [Live-devel] hi all help to to do trick mode Message-ID: <4ba29cc0702042059w6dcc1096r28491c01e5d41505@mail.gmail.com> Hi all, I am using a simple rtsp client player as referrence from mplayer to get stream of ts packets. I need to do the trick mode so.. I am just sending a rtsp command as like this char * cmdFmt = "PLAY %s RTSP/1.0\r\n" "CSeq: %d\r\n" "Session: 1\r\n" "Scale: 2.0\r\n" "\r\n"; and In this the scale is given in even number like 2,4,6,8 but the problem is when I need a FF of 4x and then normal play and then RR .. I want to know the Scale parameter is enough to get packets. Please help me to solve this... rgds Rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070204/c70b3fba/attachment-0001.html From finlayson at live555.com Sun Feb 4 21:09:45 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 4 Feb 2007 21:09:45 -0800 Subject: [Live-devel] hi all help to to do trick mode In-Reply-To: <4ba29cc0702042059w6dcc1096r28491c01e5d41505@mail.gmail.com> References: <4ba29cc0702042059w6dcc1096r28491c01e5d41505@mail.gmail.com> Message-ID: >I am using a simple rtsp client player as referrence from mplayer >to get stream of ts packets. >I need to do the trick mode so.. >I am just sending a rtsp command as like this > >char * cmdFmt = > "PLAY %s RTSP/1.0\r\n" > "CSeq: %d\r\n" > "Session: 1\r\n" > "Scale: 2.0\r\n" > "\r\n"; > >and In this the scale is given in even number like 2,4,6,8 >but the problem is when I need a FF of 4x and then normal play and >then RR .. I want to know the Scale parameter is enough to get >packets. For 4x FF play, use a scale of 4.0. For normal play, use a scale of 1.0. For reverse play (at normal speed) use a scale of -1.0. Note, however, that not all servers support scales other than 1.0. (Ours does though, if you have an index file for each TS file.) The actual scale that the server implements is returned in the "Scale:" header that appears in the response to the RTSP "PLAY" command. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rishikerala at gmail.com Sun Feb 4 21:39:13 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Mon, 5 Feb 2007 14:39:13 +0900 Subject: [Live-devel] hi all help to to do trick mode In-Reply-To: References: <4ba29cc0702042059w6dcc1096r28491c01e5d41505@mail.gmail.com> Message-ID: <4ba29cc0702042139q72ac854eq15ecf6ee161b09b8@mail.gmail.com> Dear Ross, thanks for imediate reply.. while playing continously .. I mean I play first with scale 1.0 and then again i will send a play command to try 4.0 I am getting the buffer. I just want to whether we need to specify the range also. or scale only is enough.. even in even ie 2,4,8 also I am getting the 1112 packetsize.. Bocz In my player I am stuck here. bcoz if I try the play command at starting itself with 4x its working good. but when I try a normal and jump to 4x then client got hanged.. suddenly packet size is changed to 1316 to 1116 So is there any problem sending only scale.. Rgds Rishi On 2/5/07, Ross Finlayson wrote: > > >I am using a simple rtsp client player as referrence from mplayer > >to get stream of ts packets. > >I need to do the trick mode so.. > >I am just sending a rtsp command as like this > > > >char * cmdFmt = > > "PLAY %s RTSP/1.0\r\n" > > "CSeq: %d\r\n" > > "Session: 1\r\n" > > "Scale: 2.0\r\n" > > "\r\n"; > > > >and In this the scale is given in even number like 2,4,6,8 > >but the problem is when I need a FF of 4x and then normal play and > >then RR .. I want to know the Scale parameter is enough to get > >packets. > > For 4x FF play, use a scale of 4.0. For normal play, use a scale of > 1.0. For reverse play (at normal speed) use a scale of -1.0. > > Note, however, that not all servers support scales other than 1.0. > (Ours does though, if you have an index file for each TS file.) The > actual scale that the server implements is returned in the "Scale:" > header that appears in the response to the RTSP "PLAY" command. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070204/1a786c6e/attachment.html From rajeshbikram at wlink.com.np Sun Feb 4 21:57:49 2007 From: rajeshbikram at wlink.com.np (Rajesh Bikram R.C.) Date: Mon, 05 Feb 2007 11:42:49 +0545 Subject: [Live-devel] urgent need help In-Reply-To: References: Message-ID: <45C6C75D.5010406@wlink.com.np> > >> Why the CPU utilization of openRTSP program is high. I tested in mips >> processor(400MHZ) it takes about 5-7% of CPU utilization. I need to >> optimize the CPU utilization. I found out that even though there is no >> data transmitted from the rtsp sever. The select() function in do event >> loop doesn't go to sleep.Is the IO mulitiplexing is blocking or non >> blocking mode?. How i can at least optimize the cpu performance coz i am >> running many RTSP Client based on live555 library. >> > > Only you can figure this out, because only you know the details of > your system. Also, Remember, You Have Complete Source Code. > > One point, however: On Windows (especially versions of Windows prior > to XP), the "select()" routine sometimes performs badly. if you're > running Windows, and are encountering scaling/performance problems, > then you may get better results by running Unix (including Linux) > instead. > Dear ROSS, Thanks for the reply . I am testing live555 library on montavista linux 2.6 with mips processor(400MHZ). Performance is degrading once multiple RTSP client is running . I am transmitting MPEG-ES from RTSP server.I am reading the code but don't know where to optimize the code to get good performance. with regards Rajesh. From finlayson at live555.com Sun Feb 4 21:55:14 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 4 Feb 2007 21:55:14 -0800 Subject: [Live-devel] hi all help to to do trick mode In-Reply-To: <4ba29cc0702042139q72ac854eq15ecf6ee161b09b8@mail.gmail.com> References: <4ba29cc0702042059w6dcc1096r28491c01e5d41505@mail.gmail.com> <4ba29cc0702042139q72ac854eq15ecf6ee161b09b8@mail.gmail.com> Message-ID: >I just want to whether we need to specify the range also. >or scale only is enough.. No, you don't specify the range if you want the stream to continue from the same place as before; it is enough to just specify the scale. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From morgan.torvolt at gmail.com Mon Feb 5 02:09:51 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Mon, 5 Feb 2007 14:09:51 +0400 Subject: [Live-devel] Urgent help needed! In-Reply-To: References: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> Message-ID: <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> > Unfortunately this will also prevent "fPresentationTime" from being > set, which will in turn lead to incorrect RTP timestamps. For MPEG > Transport Streams, however, that may not be a huge problem, because > the Transport Stream data itself contains the timing (PCR) > information that receivers use to properly play the stream. However, > it will cause RTCP statistics (jitter, etc.) to not get reported > correctly. Ah, thanks Ross. I remember now. What we did was alter the live library so that it uses the timestamp and not durationInMicroseconds if durationInMicroseconds == 0. That made it possible for us to just set the current time, making the timestamps correct for live sources as well. > The real puzzle here, though, is: Why is "MPEG2TransportStreamFramer" > apparently generating incorrect average durations for Victor Lee's > Transport Streams? "MPEG2TransportStreamFramer" uses the PCR > timestamps in the source Transport Stream data to generate duration > estimates, thereby pacing the streaming of the outgoing data. If the > stream is getting sent too slowly (on average), then this suggests > that the PCR timestamps are incorrect. But if that's the case, then > how is a media player able to play the audio/video at the correct > pace when it plays from the file stored locally? The TransportStremFramer uses previous PCR times and packets between them to calculate an expected datarate for the following data. This caused alot of headache for us as our STBs did not have enough buffer to handle sudden bitrate changes in variable bitrate streams. A long durationPerPacket because of low bitrate, used on a suddenly high bitrate (usually because of scene change) caused buffer underruns, and a few extreme times buffer overruns when the other way around. I believe I have mentioned this to you before also, but that might have been ouside the mailing list. As to the "correct" way of doing packet duration calculations, it would be to buffer the incoming data until you have the next PCR, and calculate time per packet based on the PCRs actually related to the data between. If Victors live input is variable bitrate, and especially if there are big variations, he could experience too low bitrate at some points. The way TransportStreamFramer works will give you alot more "too low bitrate" than "too high bitrate", as the too high bitrate last for a short time (few packets between PCRs), while the too low bitrate is used on many more packets as the sudden high bitrate increases the number of packets between PCRs. This gives an overall too low bitrate. As a sidenote, I see you have added discontinuity_indicator support, but strictly speaking, you should keep a set discontinuity_indicator value to the next PCR comes along, since it is not nessesarily set in a the packet with PCR time discontinuity. The standard states "the next PCR in a Transport Stream packet with the same PID". > It would be helpful if Victor Lee would put one of his Transport > Stream files on a web site, and post the URL, so we can download the > file and check it for ourselves. Agreed Victor: > Thank you very much for taking your WEEKEND time to answer my > questions! I appreciate your helpful information! My day off is Friday. I live in a muslim country at the moment =) -Morgan- From morgan.torvolt at gmail.com Mon Feb 5 02:13:33 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Mon, 5 Feb 2007 14:13:33 +0400 Subject: [Live-devel] Urgent help needed! In-Reply-To: <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> References: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> Message-ID: <3cc3561f0702050213w1b94de68t7def0ad8e8dd28b9@mail.gmail.com> > As a sidenote, I see you have added discontinuity_indicator support, > but strictly speaking, you should keep a set discontinuity_indicator > value to the next PCR comes along, since it is not nessesarily set in > a the packet with PCR time discontinuity. The standard states "the > next PCR in a Transport Stream packet with the same PID". Oops. That was my mistake. I read the standard again, and it seems that the PCR packet should have this set as well. We had to fix this though, as we had problems with streams not doing this correctly. -Morgan- From finlayson at live555.com Mon Feb 5 02:43:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Feb 2007 02:43:43 -0800 Subject: [Live-devel] Urgent help needed! In-Reply-To: <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> References: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> Message-ID: >As to the "correct" way of doing packet duration calculations, it >would be to buffer the incoming data until you have the next PCR, and >calculate time per packet based on the PCRs actually related to the >data between. Perhaps, although this would add a little latency, and require buffering (and add a lot of complexity) at the server. Architecturally, with memory being so cheap these days, it seems much better to require that *clients* have sufficient buffer memory to handle not just variable-bitrate streams, but also network jitter (which buffering at the server could never eliminate). >If Victors live input is variable bitrate, and especially if there are >big variations, he could experience too low bitrate at some points. He seemed to be complaining, however, about the *average* output bitrate from "MPEG2TransportStreamFramer" being too low. If that's the case, then I don't understand how that could be occurring. If the PCR values in the Transport Stream are correct, then the average output bitrate from "MPEG2TransportStreamFramer" should also be correct. If, however, the average output bitrate from "MPEG2TransportStreamFramer" is correct (as it should be), but the output bitrate has too much variability for your client(s), then you may be able to overcome this by tweaking the constants "NEW_DURATION_WEIGHT", "TIME_ADJUSTMENT_FACTOR", and "MAX_PLAYOUT_BUFFER_DURATION". (If you do this, though, you're definitely on your own...) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From armandopoulos at yahoo.fr Mon Feb 5 03:07:09 2007 From: armandopoulos at yahoo.fr (Armando Ko) Date: Mon, 5 Feb 2007 11:07:09 +0000 (GMT) Subject: [Live-devel] please help Message-ID: <20070205110709.4434.qmail@web86905.mail.ukl.yahoo.com> Hello please can anybody help me , i try to run the test program "testMPEG2TransportStreamer.cpp" under MS VS2003 but just a the beginning on the DOS Box i have this two messages errors, i don?t really know what i am making wrong. 04:26:13 Groupsock(1924: 239.255.42.42, 1234, 7): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Unknown error 04:26:13 Groupsock(1900: 239.255.42.42, 1235, 7): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Unknown error Beginning streaming ....... i hope you can give me some hints to debug this error. thanks for your help Armando ___________________________________________________________________________ D?couvrez une nouvelle fa?on d'obtenir des r?ponses ? toutes vos questions ! Profitez des connaissances, des opinions et des exp?riences des internautes sur Yahoo! Questions/R?ponses http://fr.answers.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070205/f94d4a91/attachment-0001.html From morgan.torvolt at gmail.com Mon Feb 5 07:18:47 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Mon, 5 Feb 2007 19:18:47 +0400 Subject: [Live-devel] Urgent help needed! In-Reply-To: References: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> Message-ID: <3cc3561f0702050718g41a69d37lcfbc3a8b17d4e462@mail.gmail.com> > Perhaps, although this would add a little latency, and require > buffering (and add a lot of complexity) at the server. > Architecturally, with memory being so cheap these days, it seems much > better to require that *clients* have sufficient buffer memory to > handle not just variable-bitrate streams, but also network jitter > (which buffering at the server could never eliminate). That would also cause trick play functionality to be laggy which would annoy the hell out of me for one. "No, NO! Stop rewinding!" > He seemed to be complaining, however, about the *average* output > bitrate from "MPEG2TransportStreamFramer" being too low. If that's > the case, then I don't understand how that could be occurring. If > the PCR values in the Transport Stream are correct, then the average > output bitrate from "MPEG2TransportStreamFramer" should also be > correct. Yes, you are now using the server clock to adjust the time, so all in all, the datarate should be dead stable over time. But not always. Take this scenario: GOP size of 12, static picture source, variable bitrate encoding, PCR sent 4 times per second (not totally uncommon i believe). Usually PCRs come at a regular time interval, not regular packet interval. The still frame is very well compressed in B and P frames, but the I frame is still the full frame, and contains alot of data. Lets say you get this packet count between PCRs during a GOP: 1000, 10, 10, 10 ....... , 10 Lets disregard the startup phase to make this simpler, and assume that we are in the middle of a stream. Just before the start of a new GOP, the durationInMicroseconds will be around 250ms/10 = 25ms. The TIME_ADJUSTMENT_FACTOR will pull that down somewhat, since NEW_DURATION_WEIGHT is 0.5, it will not be much less. When you get to the GOP start, the one PCR interval will take something like 1000*20ms = 20 seconds. The following frame will have a much shorter interval, at around 0.5ms, but that is only for 10 packets. Then the interval will change after the first 5ms to around 12ms, and then close in on 25ms again, being pulled down by the 0.8 factor, but it will never catch up. Every second of the film you get a 20 second delay. Yes, this was extreme, but I assure you that some encoders does this, and with a still frame like from a surveillance camera or webcam, it will happen. Even some TV stations (still frame soft-porn commercial, telephone number thingys and such, as well as quite a few religious channels) have this distribution of bandwidth. There is nothing like testing your system on these services, cause everything that can be configured is wrong and every standard is disregarded. Of course noone believes me when I say it is for testing =) In most cases though, your implementation will work nicely, catching up after some time. I have seen buffer underruns in movies with variable bitrate. Especially one movie I remember problems every time where after a silent night picture there was a scene change to a big explosion. We got more than a second of delay, which is much more than the STB can handle (iirc even mplayer complained at this stage), then the catching up caused a buffer overrun later. On fixed bandwidth it works flawlessly. I guess you see the problem. Decreasing the NEW_DURATION_WEIGHT to something like 0.1 would make a more stable bitrate, allowing the catching up part to overpower the PCR calculations, but then you would never really get a stable bitrate. Making the TIME_ADJUSTMENT_FACTOR dynamic instead of fixed could help alot. PCR is also important for another thing, namely the internal clock in the STB. Satellite STBs does not handle PCR jitter very well, since the internal clock of the STB is adjusted according to when it arrives, and this is very strict. There are not many milliseconds to spare. This makes the encoder clock the reference clock, just as it should be. On IP network one cannot be that dependent upon PCR, but the internal clock is also there adjusted after how the PCR times arrives. If one solves it like in TransportStreamFramer, then some standard compliant STBs will eventually have a problem with the very large PCR jitter it produces. That is why you should abandon TransportStreamFramer for live sources, as the receive->transmit process will introduce some jitter, but not nearly as much as TransportStreamFramer. A quick fix for some of the worst problems of buffer underrun could be to add an average time between PCRs, and if the time between two is avgTime*2 you should just flush out alot of data as fast as possible up until the next PCR arrives. This could go seriously wrong on borked TS streams though, even worse than it would with the current framer I guess, but many times it could save the day also. The best way is of course to buffer data up to the next PCR. This would also give less random access on disk and maybe better troughput, as one reads linearly more often, but with many clients, the memory demand would escalate, and could cause packet delays when the buffer is being filled. One could make this more intelligent of course, and thread the file-read part, but then it gets complicated. > "MAX_PLAYOUT_BUFFER_DURATION". (If you do this, though, you're > definitely on your own...) But it is alot of fun, running around unplugging network cables as a quick and dirty disaster solution =) -Morgan- From finlayson at live555.com Mon Feb 5 07:21:39 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Feb 2007 07:21:39 -0800 Subject: [Live-devel] please help In-Reply-To: <20070205110709.4434.qmail@web86905.mail.ukl.yahoo.com> References: <20070205110709.4434.qmail@web86905.mail.ukl.yahoo.com> Message-ID: >Hello > >please can anybody help me , i try to run the >test program "testMPEG2TransportStreamer.cpp" >under MS VS2003 but just a the beginning on the >DOS Box i have this two messages errors, i don?t >really know what i am making wrong. > >04:26:13 Groupsock(1924: 239.255.42.42, 1234, >7): failed to join group: >setsockopt(IP_ADD_MEMBERSHIP) error: Unknown >error >04:26:13 Groupsock(1900: 239.255.42.42, 1235, >7): failed to join group: >setsockopt(IP_ADD_MEMBERSHIP) error: Unknown >error >Beginning streaming ....... > >i hope you can give me some hints to debug this error. It appears that IP multicast is not configured properly on your network interface(s). Is there anything unusual about your network configuration? What version of Windows are you running? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From scheifele2001 at yahoo.com Mon Feb 5 11:17:59 2007 From: scheifele2001 at yahoo.com (Randy Schefiele) Date: Mon, 5 Feb 2007 11:17:59 -0800 (PST) Subject: [Live-devel] Speex and RTP Message-ID: <20070205191759.30664.qmail@web38203.mail.mud.yahoo.com> Hi - I am currently working on a streaming server that is using RTSP, RTP, and SDP. I have been able to successfully stream u-law encoded audio to a couple of players (VLC Media Player and RealPlayer). However, I am currently testing my streaming server with Speex encoded files and I have been unable to find a player that can play back my Speex stream. I was wondering if you could tell me (if I build the MPlayer with the Live555 software to support RTSP/RTP streaming) if receiving Speex encoded audio via RTP would work. I had also noticed that VLC media player uses some Live555 software but I have been unsuccessful in getting VLC to play back my Speex stream. If Live555 doesn't have the support for receiving Speex RTP streams I would like to help build that functionality if possible. Also, if you know of any other way I can play back a Speex RTP stream I would greatly appreciate the advice! Thanks in advance for your time and response! Randy Scheifele --------------------------------- 8:00? 8:25? 8:40? Find a flick in no time with theYahoo! Search movie showtime shortcut. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070205/42a435f3/attachment.html From xcsmith at rockwellcollins.com Mon Feb 5 14:18:26 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Mon, 5 Feb 2007 16:18:26 -0600 Subject: [Live-devel] How to make LIVE patch? Message-ID: I want to prepare some small code changes for consideration. Do I have to send a patch file, or can I just put the changed source files in a .zip? If I need a patch file, how should I make it? Thanks! Xochitl From finlayson at live555.com Mon Feb 5 18:08:29 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Feb 2007 18:08:29 -0800 Subject: [Live-devel] How to make LIVE patch? In-Reply-To: References: Message-ID: >I want to prepare some small code changes for consideration. Do I have to >send a patch file, or can I just put the changed source files in a .zip? >If I need a patch file, how should I make it? Run "diff -c" -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rishikerala at gmail.com Mon Feb 5 21:02:42 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Tue, 6 Feb 2007 14:02:42 +0900 Subject: [Live-devel] hi all.. Urgent help in trick mode Message-ID: <4ba29cc0702052102o2974f9f2icb7b296dbe873f78@mail.gmail.com> hi all, I am trying to get the stream in trick mode using the play command to scale 4 but after the play command my cleint application is playing for a 2 sec with 4x speed and hangs. any one face this problem. please give me some idea regarding this.. I check the buffer part. I am recv the packets of stream from the rtp socket with a size of 1328 .. with recv command. and then parse the RTP header.. and pass the streams to the decoder. its working good but when i try in trick mode suddenly i the buffer suddenly changes to 1128 and again I do the same but no sucess.. Please hlep me regarding this.. rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070205/0d077c3a/attachment.html From armandopoulos at yahoo.fr Mon Feb 5 21:10:52 2007 From: armandopoulos at yahoo.fr (Armando Ko) Date: Tue, 6 Feb 2007 05:10:52 +0000 (GMT) Subject: [Live-devel] Re : please help Message-ID: <111220.19383.qm@web86909.mail.ukl.yahoo.com> Dear Ross, thanks for reply.. i have windows xp with sp2 and if i run the program at first time i become a windows message box form windows firewall that as me if i want to block or allow the program i press allow ? i try to disable my windows firewall and test the program again but i have send error thanks Armando ----- Message d'origine ---- De : Ross Finlayson ? : LIVE555 Streaming Media - development & use Envoy? le : Lundi, 5 F?vrier 2007, 16h21mn 39s Objet : Re: [Live-devel] please help >Hello > >please can anybody help me , i try to run the >test program "testMPEG2TransportStreamer.cpp" >under MS VS2003 but just a the beginning on the >DOS Box i have this two messages errors, i don?t >really know what i am making wrong. > >04:26:13 Groupsock(1924: 239.255.42.42, 1234, >7): failed to join group: >setsockopt(IP_ADD_MEMBERSHIP) error: Unknown >error >04:26:13 Groupsock(1900: 239.255.42.42, 1235, >7): failed to join group: >setsockopt(IP_ADD_MEMBERSHIP) error: Unknown >error >Beginning streaming ....... > >i hope you can give me some hints to debug this error. It appears that IP multicast is not configured properly on your network interface(s). Is there anything unusual about your network configuration? What version of Windows are you running? -- 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 ___________________________________________________________________________ D?couvrez une nouvelle fa?on d'obtenir des r?ponses ? toutes vos questions ! Profitez des connaissances, des opinions et des exp?riences des internautes sur Yahoo! Questions/R?ponses http://fr.answers.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070205/2ecda890/attachment.html From rishikerala at gmail.com Mon Feb 5 22:51:04 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Tue, 6 Feb 2007 15:51:04 +0900 Subject: [Live-devel] hi Ross, trickmode Message-ID: <4ba29cc0702052251u3b0d8917he9edd0b0104abd7e@mail.gmail.com> Hi Ross, i am facing some problem in STB regarding the trickmode playing.. Please give me some solution to to get the buffer size to be 1316 in trick mode also... Is there any way to do this.. waiting your reply.. rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070205/1c96c9aa/attachment-0001.html From rishikerala at gmail.com Tue Feb 6 04:13:12 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Tue, 6 Feb 2007 04:13:12 -0800 Subject: [Live-devel] hi all please help me Message-ID: <4ba29cc0702060413o33744b77gf961dbc6c3193f0e@mail.gmail.com> hi all, Please give me some solution .. i have to change something the live server.. to get buffer in trick mode 1316 .. now I am getting buffer in trick mode as 1128.. where I can change in server side to get a buffer count always 1316.. in trickmode and normal play.. please give me some solution rgds rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070206/60769027/attachment.html From gorkeralp at gmail.com Tue Feb 6 05:33:48 2007 From: gorkeralp at gmail.com (Gorker Malazgirt) Date: Tue, 6 Feb 2007 14:33:48 +0100 Subject: [Live-devel] MPEG4-ES -> MPEG4/3GP Message-ID: Hi! We are 2 thesis workers who are trying to use openRTSP but we are really confused about how we can change to VIDEO-GENERIC codec or RAW video instead of VIDEO-MPEG4-ES-1.. VIDEO-MPEG4-ES-1 is implemented as default we believe and is there any way we can change it to other formats? Is it possible to stream a raw mpeg4 format instead of elementary stream by using openRTSP? If this can be done or are already implemented how can we get it? Is there any possibilities to convert the captured mpeg4-es format to 3gp/mp4? Best regards David & Gorki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070206/9bdaa0e2/attachment.html From armando at highseascs.com Tue Feb 6 06:42:29 2007 From: armando at highseascs.com (Armando de Oliveira Fortuna) Date: Tue, 6 Feb 2007 08:42:29 -0600 Subject: [Live-devel] Quicktime and live555 Message-ID: <000401c749fd$06d0f6e0$6702a8c0@rudder> Hi Ross, I am thinking about writing a sink for live555 that will use the Quicktime API to save a movie to disk. I would like to follow as much as possible the way the current sink files have been written. For that I would need the following information: a) How can I retrieve the frame rate, etc, that may be sent down by the streaming server? b) The file sink will have to be after live555's packet reassembler has put packets together. Where is the sink given the packets? And how do I know what type they are (sound, video) and if it was a sync frame? c) If the reassembler throws a video packet away (say), what happens to the sound packets for that interval of time? Are they thrown away to? Once the file sink is complete I will make it available to you for possible inclusion in the source code of the lib. Thanks, Armando -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070206/119bd0f9/attachment.html From finlayson at live555.com Mon Feb 5 21:00:27 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 6 Feb 2007 18:00:27 +1300 Subject: [Live-devel] Speex and RTP In-Reply-To: <20070205191759.30664.qmail@web38203.mail.mud.yahoo.com> References: <20070205191759.30664.qmail@web38203.mail.mud.yahoo.com> Message-ID: >Hi - > >I am currently working on a streaming server that is using RTSP, RTP, and SDP. I hope you are using our software for this (note that the "LIVE555 Streaming Media" software includes a RTSP server implementation (as well as a RTSP client). > I have been able to successfully stream u-law encoded audio to a >couple of players (VLC Media Player and RealPlayer). However, I am >currently testing my streaming server with Speex encoded files and I >have been unable to find a player that can play back my Speex >stream. I was wondering if you could tell me (if I build the >MPlayer with the Live555 software to support RTSP/RTP streaming) if >receiving Speex encoded audio via RTP would work. > >I had also noticed that VLC media player uses some Live555 software >but I have been unsuccessful in getting VLC to play back my Speex >stream. If Live555 doesn't have the support for receiving Speex RTP >streams I would like to help build that functionality if possible. > >Also, if you know of any other way I can play back a Speex RTP >stream I would greatly appreciate the advice! I haven't looked at the Speex RTP payload format specification for a while, but I recall that it used to be very simple (with no extra special headers in the RTP packet). If that is still the case, then it turns out that the "LIVE555 Streaming Media" code can already receive Speex audio RTP streams, using the "SimpleRTPSource" class (see line 782 of "liveMedia/MediaSession.cpp"). So, all that remains is the ability to decode/play the incoming Speex audio stream. Our software does not include any codec (decoding) functionality - for that, you will have to consult with the VLC and MPlayer developers. It might be the case that they already include Speex decoding software. If so, then it will be very easy to feed this with the incoming Speex audio data. If not, then you will need to work with them to add the Speex decoding software to those player. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Feb 5 21:30:44 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 6 Feb 2007 18:30:44 +1300 Subject: [Live-devel] Urgent help needed! In-Reply-To: <3cc3561f0702050718g41a69d37lcfbc3a8b17d4e462@mail.gmail.com> References: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> <3cc3561f0702050718g41a69d37lcfbc3a8b17d4e462@mail.gmail.com> Message-ID: >A quick fix for some of the worst problems of buffer underrun could be >to add an average time between PCRs, and if the time between two is >avgTime*2 you should just flush out alot of data as fast as possible >up until the next PCR arrives. This could go seriously wrong on borked >TS streams though, even worse than it would with the current framer I >guess, but many times it could save the day also. Please let us know if you have any specific suggestions for improvements to the existing "MPEG2TransportStreamFramer" code... In any case, I would still like to see a specific example of a (real-live) Transport Stream file that illustrates this problem. >The best way is of >course to buffer data up to the next PCR. This would also give less >random access on disk and maybe better troughput, as one reads >linearly more often I don't buy this, because the streaming itself causes the data to be read linearly. I think that a better (but related) solution would be to use the index file. When we generate an index file, we are already 'reading ahead' in the stream, so it would be not be too difficult, I think, to augment the index file records to add an accurate 'duration' for each Transport Packet, and to use this 'duration' when streaming. Perhaps I'll add this at some point in the future... (Of course, this won't help at all with live streams (because they don't have index files), but I think that having live Transport Streams that are severly VBR is a really bad idea, if you're not counting on clients to have sufficient buffering to handle them.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From hubert at csail.mit.edu Tue Feb 6 10:24:16 2007 From: hubert at csail.mit.edu (Hubert Pham) Date: Tue, 06 Feb 2007 13:24:16 -0500 Subject: [Live-devel] Unicast, Socket Bind Issues on localhost? Message-ID: <45C8C7D0.5060001@csail.mit.edu> Hi, I'm trying to use testMP3Sender and testMP3Receiver to stream an MP3 file via unicast. I've modified the examples appropriately for unicast streaming: testMP3Sender sends to a target unicast address, while testMP3Receiver listens on 0.0.0.0. This works fine---except when a) the sender is sending to a receiver on the same host, and b) the receiver starts up before the sender. Under this scenario, the receiver never receives any packets; more precisely, the receiver's select() never indicates that the socket is readable. If instead the sender starts before the receiver, then the setup works fine (except the receiver obviously doesn't receive the first few initial packets). Additionally, if using multicast instead of unicast, then everything also works fine regardless of startup order. My guess is that GroupsockHelper.cpp::setupDatagramSocket (ultimately called when constructing a Groupsock) attempts to bind the socket to the user-specified port if the port is non-zero, disregarding whether or not the socket is intended as send-only to a unicast address: if (port.num() != 0 || ReceivingInterfaceAddr != INADDR_ANY) { ... MAKE_SOCKADDR_IN(name, ReceivingInterfaceAddr, port.num()); if (bind(newSocket, (struct sockaddr*)&name, sizeof name) != 0) { ... I imagine what is happening is that when testMP3Receiver and testMP3Sender run on the same host, they both try to bind to port 6666 and 6667 on the same interface. This might make sense when using multicast, but my guess is that under unicast---in which not all the multicast socket options are set---one process will lose on the bind and not receive packets. While streaming data between two processes on the same host might seem like a corner case, are there any suggestions for doing so? (e.g., a different available Groupsock interface or constructor parameter?) Thanks for your time, hubert PS I noticed that someone did bring up this issue on March 5, 2002, but I didn't see a resolution, nor did the post mention anything about the sender and receiver being on the same host. Apologies if I missed the resolution... From finlayson at live555.com Tue Feb 6 12:17:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 7 Feb 2007 09:17:23 +1300 Subject: [Live-devel] hi all.. Urgent help in trick mode In-Reply-To: <4ba29cc0702052102o2974f9f2icb7b296dbe873f78@mail.gmail.com> References: <4ba29cc0702052102o2974f9f2icb7b296dbe873f78@mail.gmail.com> Message-ID: This asshole (rishikerala at gmail.com) has now been permanently banned from ever posting to this mailing list again. (Don't bother whining to me to try to get me to change my mind on this - I won't.) Not only did this clown rudely post the same question to the list at least five times, he continued doing so after I'd already answered his question: It is perfectly OK for network packets - when carrying Transport Stream data - to contain any integral number of 188-byte Transport Stream packets - not just 7, and therefore receivers need to be prepared for this. I'm baffled by the bizarre sense of entitlement that some people seem to have about support for this software. For some reason, the worse offenders seem to be people with unprofessional 'hobbyist' email addresses (@gmail.com, @hotmail.com, @yahoo.com, etc.). If you have an email address like this, then it's actually *less* likely that I'm going to answer your questions, because your email address suggests that you are not a serious professional, and that your project is just for fun. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From morgan.torvolt at gmail.com Tue Feb 6 13:30:44 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Wed, 7 Feb 2007 01:30:44 +0400 Subject: [Live-devel] Urgent help needed! In-Reply-To: References: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> <3cc3561f0702050718g41a69d37lcfbc3a8b17d4e462@mail.gmail.com> Message-ID: <3cc3561f0702061330p46a10af2k8d1370d89eac154d@mail.gmail.com> > Please let us know if you have any specific suggestions for > improvements to the existing "MPEG2TransportStreamFramer" code... I did give you some specific suggestions. I did not give you any code, because I think (maybe even know) that the design is flawed and should not be used no matter how you tweak it, and I have therefor not bothered to do any work on it, just rewrote the whole thing. > In any case, I would still like to see a specific example of a > (real-live) Transport Stream file that illustrates this problem. If you have a satellite tuner card, and access to Hotbird 13E, you will find tons of channels like I described. Don't think I am allowed to distribute those streams though. If you cannot see Hotbird, you could probably find tons of free to air channels from www.lyngsat.com > I don't buy this, because the streaming itself causes the data to be > read linearly. Yes, if you have only one client, but having 30 clients, none of them at the same point in the stream, or maybe even on different streams, causes random access on the disk. Reading 188 byte here, and then 188 byte there, often at totally different places on the disk is not very efficient because of the long delay when moving the HDD heads around. Random access is not efficient. If you read in larger bolks, you will get a higher troughput from your HDD. Look at some of the tests at storagereview, it is clear that reading smaller blocks spread around the disk is very much slower than large blocks, and it is logical too, if you think about it. If you clean up you house one place at a time instead of just one small spot at a time, you spend less time running around from place to place, and more time getting the job done. > I think that a better (but related) solution would be to use the > index file. When we generate an index file, we are already 'reading > ahead' in the stream, so it would be not be too difficult, I think, > to augment the index file records to add an accurate 'duration' for > each Transport Packet, and to use this 'duration' when streaming. > Perhaps I'll add this at some point in the future... (Of course, > this won't help at all with live streams (because they don't have > index files), but I think that having live Transport Streams that are > severly VBR is a really bad idea, if you're not counting on clients > to have sufficient buffering to handle them.) This is what we are doing. As the solution is out in the open now, I can tell you that it solves all the buffer problems. Combined with a read-ahead routine we have, the efficiency of live555 is greatly increased. Our code demands some changes to live that you have not wanted to add earlier, as well as some custom changes that is not very usefull for everyone. I do not believe that the changes we have will make you very happy =/ You do have the solutions though, and it is actually not very hard to do. You will need to index _every_ PCR though. An average between I frames is not sufficient. I have tested that. By the way, the PCR is not supposed to be a guideline. The PCR timestamp is the exact time the packet should reach the client. You really have no slack there. It is an extremely accurate timestamp because it needs to be. The accuracy of the PCR is how much slack you should count on. If that is disregarded, then you are in for problems sooner or later. Claiming that it is the client that should do it differently does not help the guy that already have these (probably even standard compliant) STBs that are strict with the PCR timings. I do have real life experience from working in earth stations to back that up. 50ms jitter could actually be too much, and even less on VBR. If I have understood this correctly, the DVB standard was developed with one very strong read thread going trough it all. STBs should be cheap. As cheap as possible, putting all the cost on the distribution system, giving a better total system cost, and lower end user prices. That is still being done, and I think it is the right way of attacking the problem with consumers not willing to pay a wole lot for stuff like this. Being strict on PCR will lower the cost of parts and manufacturing. It also, as I stated, improves interactivity response times. As for severly VBR, it is standard compliant, it is efficient, and very many providers use this on entire muxes to give better average quality/bit/s in their services. These dynamic VBR muxes can have huge changes, very quickly, adapted on a per frame basis. I agree that CBR is more equipment friendly, but is not what the real world provides you with. Severly VBR is here to stay, and with good reason. Take any DVD as an example. The bitrate fluctuations are totaly disregarded, it is the quality that counts, and that is the way it should be. The problem with live sources, I already said how you could fix that. The live sources do of course not give data to fast or to slow, at it is a live process being done realtime, it sends the data at the exactly correct time (somtimes in big chunks that you have to even out over time, but still, the timing is right). There is no reason to re-time the packets in a framer, they are fine just the way they are. Just drop the framer, and add support for setting the RTP timestamp to server-time, and you're done. Whatever you have in store, it will never beat the PCR accuracy from DVB-S, DVB-T and DVB-C sources anyway. Just pass it on as soon as you receive it, introducing as little jitter as possible. I have provided you with a patch before to make this possible trough using timestamps instead of durationInMicroseconds if one wished, but it was never added to live555. I do as before suggest that it gets added. If you do not have the patch anymore, I think I could dig it up again. It has been some time since I last had a look at it. Don't get me wrong here. Live555 is an excellent product, the best there is imo, but it does have it's flaws. The transprtstremframer works, it is just not very good at what it does, as opposed to most other tings in live555. Having all my suggestions and experiences disregarded because you think that the clients or providers should fix the problems does not make me very eager to help out too much though. Now that you have trick play implemented though, you will have alot of new users, and transportstreamframer will need to be fixed for them to be able to use it properly. At least we could not. Best regards -Morgan- From scheifele2001 at yahoo.com Tue Feb 6 20:28:42 2007 From: scheifele2001 at yahoo.com (Randy Schefiele) Date: Tue, 6 Feb 2007 20:28:42 -0800 (PST) Subject: [Live-devel] Speex and RTP In-Reply-To: Message-ID: <380097.25759.qm@web38212.mail.mud.yahoo.com> Hi Ross, Thank you for the reply. I have tried to stream a Speex encoded file (in the ogg format) with the Live555 Streaming Server but it does not seem to work. I think that the streaming software is checking the file extension of the file to be streamed in order to determine if it can be streamed or not. When I try to stream the file it comes back with a file not found message from the server. I was able to successfully stream .wav files though. VLC does include software to decode and play Speex encoded audio but it doesn't seem to be picking up the SDP and selecting the correct codec in order to play the stream. I will have to work with the VLC source and/or developers to see if this can be fixed. Thanks for your help and Live555 software! I have already recommended it to some friends. Randy Ross Finlayson wrote: >Hi - > >I am currently working on a streaming server that is using RTSP, RTP, and SDP. I hope you are using our software for this (note that the "LIVE555 Streaming Media" software includes a RTSP server implementation (as well as a RTSP client). > I have been able to successfully stream u-law encoded audio to a >couple of players (VLC Media Player and RealPlayer). However, I am >currently testing my streaming server with Speex encoded files and I >have been unable to find a player that can play back my Speex >stream. I was wondering if you could tell me (if I build the >MPlayer with the Live555 software to support RTSP/RTP streaming) if >receiving Speex encoded audio via RTP would work. > >I had also noticed that VLC media player uses some Live555 software >but I have been unsuccessful in getting VLC to play back my Speex >stream. If Live555 doesn't have the support for receiving Speex RTP >streams I would like to help build that functionality if possible. > >Also, if you know of any other way I can play back a Speex RTP >stream I would greatly appreciate the advice! I haven't looked at the Speex RTP payload format specification for a while, but I recall that it used to be very simple (with no extra special headers in the RTP packet). If that is still the case, then it turns out that the "LIVE555 Streaming Media" code can already receive Speex audio RTP streams, using the "SimpleRTPSource" class (see line 782 of "liveMedia/MediaSession.cpp"). So, all that remains is the ability to decode/play the incoming Speex audio stream. Our software does not include any codec (decoding) functionality - for that, you will have to consult with the VLC and MPlayer developers. It might be the case that they already include Speex decoding software. If so, then it will be very easy to feed this with the incoming Speex audio data. If not, then you will need to work with them to add the Speex decoding software to those player. -- 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 --------------------------------- Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070206/c07a7c42/attachment.html From finlayson at live555.com Tue Feb 6 14:40:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 7 Feb 2007 11:40:40 +1300 Subject: [Live-devel] Unicast, Socket Bind Issues on localhost? In-Reply-To: <45C8C7D0.5060001@csail.mit.edu> References: <45C8C7D0.5060001@csail.mit.edu> Message-ID: >I'm trying to use testMP3Sender and testMP3Receiver to stream an MP3 file >via unicast. I don't recommend doing this. Instead, I recommend using applications that were developed specifically for unicast streaming: Use "testOnDemandRTSPServer" (or "live555MediaServer") as the server, and "openRTSP" for the client. This should work OK even if the client and server are running on the same host. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Feb 7 00:32:04 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 7 Feb 2007 21:32:04 +1300 Subject: [Live-devel] Urgent help needed! In-Reply-To: <3cc3561f0702061330p46a10af2k8d1370d89eac154d@mail.gmail.com> References: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> <3cc3561f0702050718g41a69d37lcfbc3a8b17d4e462@mail.gmail.com> <3cc3561f0702061330p46a10af2k8d1370d89eac154d@mail.gmail.com> Message-ID: > > I don't buy this, because the streaming itself causes the data to be >> read linearly. > >Yes, if you have only one client, but having 30 clients, none of them >at the same point in the stream, or maybe even on different streams, >causes random access on the disk. OK, I guess I was assuming that the OS's file system implementation is smart enough to detect sequential reads within a file (even if they're interleaved with sequential reads within other files), and optimize this by doing read-ahead - for each file - into its file system cache. However, I'm not sure in practice how smart OSs are about this, but if the OS kernel *could* do this automatically, that would certainly be better than having the application implementing its own read-ahead in user space. In any case, file systems typically read from the disk in large block sizes (certainly much larger than 188 bytes), so you get some 'read-ahead' for free there. (OTOH, we had a major VOD customer that had no choice but to use Windows, and they ended up deciding to do their own read-ahead/buffering of Transport Stream file data in user space (replacing "ByteStreamFileSource" and "MPEG2TransportStreamFramer"). But perhaps other OSs aren't as brain-damaged as Windows about this...) > > I think that a better (but related) solution would be to use the > index file. [...] >This is what we are doing. Are you using our index file format, or a different one that you created? >You will need to index _every_ PCR >though. An average between I frames is not sufficient. Yes, our index file format records every PCR - not just those that belong to I-frames. >By the way, the PCR is not supposed to be a guideline. The PCR >timestamp is the exact time the packet should reach the client. More precisely, the client's *decoder*. (See below.) > You really have no slack there. That's true, but in an Internet environment (as opposed to, say, a satellite network, where jitter can presumably be tightly controlled) you can't avoid nontrivial network jitter. The *only* way to overcome this is to add buffering at the client, between the network interface and the decoder. If a client is too 'cheap' to have enough buffering to overcome typical Internet network jitter, then it's not going to work (well) on the Internet, no matter how precisely the Transport Packets are transmitted from the source. >The problem with live sources, I already said how you could fix that. >The live sources do of course not give data to fast or to slow, at it >is a live process being done realtime, it sends the data at the >exactly correct time (somtimes in big chunks that you have to even out >over time, but still, the timing is right). There is no reason to >re-time the packets in a framer, they are fine just the way they are. >Just drop the framer, and add support for setting the RTP timestamp to >server-time, and you're done. Whatever you have in store, it will >never beat the PCR accuracy from DVB-S, DVB-T and DVB-C sources >anyway. Just pass it on as soon as you receive it, introducing as >little jitter as possible. I have provided you with a patch before to >make this possible trough using timestamps instead of >durationInMicroseconds if one wished, but it was never added to >live555. I do as before suggest that it gets added. If you do not have >the patch anymore, I think I could dig it up again. It has been some >time since I last had a look at it. Yes, that would be useful. I can imagine providing a "MPEG2TransportStreamDiscreteFramer" (similar to the existing "MPEG1or2VideoStreamDiscreteFramer" and "MPEG4VideoStreamDiscreteFramer" classes) that could be used when the input source is discrete Transport Stream packets, arriving at precise times. (It would set "fPresentationTime", but not "fDurationInMicroseconds", and thus be very simple.) >Don't get me wrong here. Live555 is an excellent product, the best >there is imo, but it does have it's flaws. The transprtstremframer >works, it is just not very good at what it does Ultimately, I can envision there being three Transport Stream 'framer' classes: 1/ "MPEG2TransportStreamDiscreteFramer", as described above, for live streams that deliver discrete Transport Stream packets at precise times. 2/ "MPEG2TransportStreamFramerFromIndexFile", for use with prerecorded Transport Stream files that have a corresponding index file. 3/ The current "MPEG2TransportStreamFramer", as a fallback for everything else. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mrnikhilagrawal at gmail.com Wed Feb 7 04:17:49 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Wed, 7 Feb 2007 17:47:49 +0530 Subject: [Live-devel] Regarding Client Player with Live555 Message-ID: <733cde3e0702070417m4e4ed66ft3880f1a12f94e819@mail.gmail.com> Hi Ross, I am using Live555 as Media Streaming Server and looking for a client player that is best suitable with Live555. Unfortunately , I am exploring client players since long period and didn't found any player completely compatible with Live555. I tried VLC but its having much problems with PAUSE/PLAY feature. I tried MPlayer, its also having seeking and multichannel (wav file ) problem I tried Real Player , it also have multichannel and PAUSE/PLAY problems I tried QuickTime , it works very correctly with PAUSE/PLAY, but didn't play multichanel. Although I thought to use QT accepted this problem but suddenly found no support of MP3 stream playing in it , so again disappointed. I want client player to be embedded in WebPage. Can you please tell me , the one player that is compatible with Live555 and can satisfy all the above requirements , or please suggest me , what step I can take in such situation. I will be thankful for your any suggestions. Thanks and Regards, Nikhil Agrawal PS. Any Live555 user , if have any kind of solution regarding the same , please let me know. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070207/42c8fa35/attachment.html From morgan.torvolt at gmail.com Wed Feb 7 04:23:29 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Wed, 7 Feb 2007 16:23:29 +0400 Subject: [Live-devel] Urgent help needed! In-Reply-To: References: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> <3cc3561f0702050718g41a69d37lcfbc3a8b17d4e462@mail.gmail.com> <3cc3561f0702061330p46a10af2k8d1370d89eac154d@mail.gmail.com> Message-ID: <3cc3561f0702070423s20125a9du6abf0126bf3d7de8@mail.gmail.com> > OK, I guess I was assuming that the OS's file system implementation > is smart enough to detect sequential reads within a file (even if > they're interleaved with sequential reads within other files), and > optimize this by doing read-ahead - for each file - into its file > system cache. However, I'm not sure in practice how smart OSs are > about this, but if the OS kernel *could* do this automatically, that > would certainly be better than having the application implementing > its own read-ahead in user space. In any case, file systems > typically read from the disk in large block sizes (certainly much > larger than 188 bytes), so you get some 'read-ahead' for free there. > (OTOH, we had a major VOD customer that had no choice but to use > Windows, and they ended up deciding to do their own > read-ahead/buffering of Transport Stream file data in user space > (replacing "ByteStreamFileSource" and "MPEG2TransportStreamFramer"). > But perhaps other OSs aren't as brain-damaged as Windows about > this...) We run Linux, and we have seen some significant improvements by reading larger chuncks, but if they get too large, we got PCR jitter problems due to the "slow read" of the harddrives. It seemed like when three or more clients needed read-time after one-another (happened randomly from time to time), the time it took to finish those three reads made the following packets delayed. This was with very large buffers though. With other clients (like VLC) one could probably increase the buffer size even more than we do. A disk with 60MB/s throughput can give you 600kB in (avg-seek-time + 600k/60M) = 8ms + 10ms = 18ms. 60kB would be achieved in 9ms. Half the time, one tenth of the data. The filesystem reads in larger chunks than a TS packet, that is true, but I believe never larger than one block, since the next block could very well be on a different place on the disk. If you have 4k block size, that would be about 21 TS packets. If it has some spare time it could do some read ahead, but that only helps until the amount of requests starts piling up, making read-ahead on one process/request a time-burden on the next process/request. > Are you using our index file format, or a different one that you created? We use our own that we made a about year/year and a half ago. Would like to use yours though, as we would not need to maintain our code anymore, but I have not had time to look at it yet. > That's true, but in an Internet environment (as opposed to, say, a > satellite network, where jitter can presumably be tightly controlled) > you can't avoid nontrivial network jitter. The *only* way to > overcome this is to add buffering at the client, between the network > interface and the decoder. If a client is too 'cheap' to have enough > buffering to overcome typical Internet network jitter, then it's not > going to work (well) on the Internet, no matter how precisely the > Transport Packets are transmitted from the source. Yes, you are quite right. Satellite networks are easier in that aspect. SDH and and even to some extent ATM networks are also able to do this. Ethernet is unfortunately broken by design on this aspect, and one do need buffers. One have to weigh the responsiveness against the network jitter demand. Usually a semi closed network, like most IPTV "cable TV" providers and hospitality use have quite good control of its network delay, so having more than a few hundred ms buffer would be end-user-experience degrading. Having that much jitter added by the server would probably not be the best thing that happened then. > Ultimately, I can envision there being three Transport Stream 'framer' classes: > 1/ "MPEG2TransportStreamDiscreteFramer", as described above, for live > streams that deliver discrete Transport Stream packets at precise > times. > 2/ "MPEG2TransportStreamFramerFromIndexFile", for use with > prerecorded Transport Stream files that have a corresponding index > file. > 3/ The current "MPEG2TransportStreamFramer", as a fallback for everything else. That could be quite nice actually. Since MPEG4 transmitted in terrestrial and satellite networks also use the same transportstream layer, it would work with those as well. That sounds like a good plan. If you indeed do implement this, remember to do time adjusting also in the index-file version, as the double precision is not good enough. Gave us problems every half hour or so. If I could interest you in another very nice feature, I have a suggestion for the trick play functionality. I see that you use I frames now. What we have done is to use GOPs. We play a full GOP, then jump over "scale" amounts of GOPs to play the next one. We found this to be a much sweeter way for fast forwarding as you don't just get random pictures but half a second of movie between each jump. This makes it much easier to see exactly where in the stream you are. For rewind i think the I-frame solution works best. You will need to edit the MPEG stream to enable this GOP streaming, though, setting the broken_GOP flag in the PES header while fast forwarding, as well as index on sequence header packets as well as the actual I frame (usually the same or very close I guess). Best regards -Morgan- From senthilprabu.vs at gmail.com Wed Feb 7 05:12:51 2007 From: senthilprabu.vs at gmail.com (Senthil Prabu) Date: Wed, 7 Feb 2007 18:42:51 +0530 Subject: [Live-devel] Not able to play RTP multicast mpeg2 video elementary stream using VLC player Message-ID: <8f1753dd0702070512h4d553134s10ea991c3c228cab@mail.gmail.com> Hi I am not able to play RTP multicast mpeg2 video elementary streams using VLC player using Open Network Stream option when I multicast the mpeg2 video stream by testMPEG1or2VideoStreamer. I got the following messages from VLC message q main debug: creating new input thread main debug: waiting for thread completion main debug: thread 3172 (input) created at priority 1 (src/input/input.c:228) main debug: `udp://@239.255.42.42:8888' gives access `udp' demux `' path `@239.255.42.42:8888' main debug: demux2_New: access='udp' demux='' path='@239.255.42.42:8888' main debug: looking for access_demux module main debug: probing 0 candidates main warning: no access_demux module matched "udp" main debug: access2_New: access='udp' path='@239.255.42.42:8888' main debug: looking for access2 module main debug: probing 5 candidates access_udp debug: opening server=:0 local=239.255.42.42:8888 main debug: net: connecting to ':0 at 239.255.42.42:8888' main debug: looking for network module main debug: probing 2 candidates ipv4 debug: IP_ADD_MEMBERSHIP multicast request main debug: using network module "ipv4" main debug: unlocking module "ipv4" main debug: using access2 module "access_udp" main debug: pre buffering access_udp debug: detected MPEG video over RTP main debug: received first data for our buffer main debug: prebuffering done 3576 bytes in 0s - 32 kbytes/s main debug: demux2_New: access='udp' demux='es' path='@239.255.42.42:8888' main debug: looking for demux2 module main debug: probing 0 candidates main error: no demux2 module matched "es" main error: no suitable demux module for `udp/es://@239.255.42.42:8888' main debug: unlocking module "access_udp" main debug: thread 3172 joined (src/input/input.c:290) But the same stream is playing if I directly open in VLC(without multicating). One more thing, testMPEG1or2VideoReceiver is receiving the streamed o/p. So VLC will support only mpeg2 ts format while it is reading from network stream? Can u suggest me some other player which will play this? or give me the solution. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070207/5d689809/attachment-0001.html From finlayson at live555.com Wed Feb 7 08:05:03 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Feb 2007 05:05:03 +1300 Subject: [Live-devel] Not able to play RTP multicast mpeg2 video elementary stream using VLC player In-Reply-To: <8f1753dd0702070512h4d553134s10ea991c3c228cab@mail.gmail.com> References: <8f1753dd0702070512h4d553134s10ea991c3c228cab@mail.gmail.com> Message-ID: >Hi >I am not able to play RTP multicast mpeg2 video elementary streams >using VLC player using Open Network Stream option when I multicast >the mpeg2 video stream by testMPEG1or2VideoStreamer. That's strange. I'm not sure why that isn't working (because the log shows that VLC is detecting MPEG video). I suggest modifying "testMPEG1or2VideoStreamer" to enable its built-in RTSP server (by uncommenting the line #define IMPLEMENT_RTSP_SERVER 1 in "testMPEG1or2VideoStreamer.cpp". The program will then display a "rtsp://" URL that you can enter into VLC. That should work. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Feb 7 08:09:21 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Feb 2007 05:09:21 +1300 Subject: [Live-devel] Regarding Client Player with Live555 In-Reply-To: <733cde3e0702070417m4e4ed66ft3880f1a12f94e819@mail.gmail.com> References: <733cde3e0702070417m4e4ed66ft3880f1a12f94e819@mail.gmail.com> Message-ID: >Hi Ross, > >I am using Live555 as Media Streaming Server and looking for a >client player that is best suitable with Live555. Unfortunately , I >am exploring client players since long period and didn't found any >player completely compatible with Live555. > >I tried VLC but its having much problems with PAUSE/PLAY feature. VLC is your best bet. However, you will need to wait until people have fixed its (known) problems with implementing 'trick play' operations. People are working on this issue, so PLEASE STOP CONSTANTLY POSTING EMAIL ABOUT THIS!! -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Feb 7 08:20:06 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Feb 2007 05:20:06 +1300 Subject: [Live-devel] Urgent help needed! In-Reply-To: <3cc3561f0702070423s20125a9du6abf0126bf3d7de8@mail.gmail.com> References: <3cc3561f0702022207r37b23363j8a97961f7ad019e0@mail.gmail.com> <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> <3cc3561f0702050718g41a69d37lcfbc3a8b17d4e462@mail.gmail.com> <3cc3561f0702061330p46a10af2k8d1370d89eac154d@mail.gmail.com> <3cc3561f0702070423s20125a9du6abf0126bf3d7de8@mail.gmail.com> Message-ID: >If you indeed do implement this, remember to do time adjusting also in >the index-file version, as the double precision is not good enough. >Gave us problems every half hour or so. Can you explain some more what you mean by this? >If I could interest you in another very nice feature, I have a >suggestion for the trick play functionality. I see that you use I >frames now. What we have done is to use GOPs. We play a full GOP, then >jump over "scale" amounts of GOPs to play the next one. We found this >to be a much sweeter way for fast forwarding as you don't just g