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 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). That sounds like it could be something worthwhile to add in the future. (The index file already records the locations of GOP headers, so it should be possible to do this without modifying the index file format.) It's not high-priority however... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From morgan.torvolt at gmail.com Wed Feb 7 09:45:24 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Wed, 7 Feb 2007 21:45:24 +0400 Subject: [Live-devel] Urgent help needed! In-Reply-To: References: <3cc3561f0702050209j5863f978ic123f4673bff6683@mail.gmail.com> <3cc3561f0702050718g41a69d37lcfbc3a8b17d4e462@mail.gmail.com> <3cc3561f0702061330p46a10af2k8d1370d89eac154d@mail.gmail.com> <3cc3561f0702070423s20125a9du6abf0126bf3d7de8@mail.gmail.com> Message-ID: <3cc3561f0702070945x6dd67cfah1b35f206ceba9f24@mail.gmail.com> On 07/02/07, Ross Finlayson wrote: > >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? Sorry, poorly explained. What TransportStreamFramer does now is to try to adjust the duration partly based on the system time of the server using the TIME_ADJSUTMENT_FACTOR. You will still need to do that when using index file even though the PCR should be accurate enough. We did not do this at first, thinking the PCR time was more than sufficient. The problem is that the double variable we used for the PCR value is not accurate enough ( I did not believe it at first eighter ). I guess that with the PCR timestamp accuracy on its 33bits, the least significant digits are not exact enough when divided by numberOfPackets, and .001us (or whatever the error is, I don't remember anymore, was a year ago) error per packet did obviously add up to a whole lot for some odd reason =) > That sounds like it could be something worthwhile to add in the > future. (The index file already records the locations of GOP > headers, so it should be possible to do this without modifying the > index file format.) It's not high-priority however... Of course. Maybe I will try adding it if I ever get the time. What we have now is neighter very nicely coded nor compliant with many standards I believe. continuity_counter and other things are completely disregarded because the STBs did not care. Regards Morgan Torvolt From zhouh31415 at 163.com Wed Feb 7 20:06:40 2007 From: zhouh31415 at 163.com (=?gbk?B?1ty66w==?=) Date: Thu, 8 Feb 2007 12:06:40 +0800 (CST) 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: <22389439.733521170907600162.JavaMail.root@bj163app33.163.com> Vlc can't play elementary stream directly, when you use testMPEG1or2VideoStreamer, you must be stream it by TS. Vlc support a lot of stream format, including TS and PS. But their payload type is difference. Please read the RFC document, but I can't remember it's number. There are lots of reasons that you can't play your stream, you must make sure multicast is all right in your Lan and I suggest you play your stream with UDPsink and UDPsource firstly. ?2007-02-07?Senthil Prabu ??? 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/0b5f7451/attachment.html From armando at highseascs.com Thu Feb 8 07:50:44 2007 From: armando at highseascs.com (Armando de Oliveira Fortuna) Date: Thu, 8 Feb 2007 09:50:44 -0600 Subject: [Live-devel] QuicktimeFileSink changes Message-ID: <000d01c74b98$e4a50280$6702a8c0@rudder> Hi Ross, I am modifying the QuickTimeFileSink file to include the code for using the Quicktime library to save the file. I will open the file (using Quicktime's API) in at the bottom of the QuickTimeFileSink constructor, and close it (after writing the movie atom through Quicktime's API) in completeOutputFile. I believe useFrame is the appropriate place to add the track to the file (if the track is not already there), and then add the media sample for each track. Now, I am not sure I understand what you mean by "frame". Is that a collection of RTP packets that (minus the RTP header) that make up what Quicktime calls a 'sample'? Also, I am not sure of the relationship between afterGettingFrame, useFrame and useFrame1. Can you please give me a quick description of their functionality? Thank you very much, Armando -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070208/7306737d/attachment.html From TAYK0004 at ntu.edu.sg Thu Feb 8 08:55:07 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Fri, 9 Feb 2007 00:55:07 +0800 Subject: [Live-devel] Groupsock, usage environment purpose Message-ID: <438567054C073949AEBE5A28B83E7DE133FCD3@MAIL21.student.main.ntu.edu.sg> Hi guys, i in the midst of completing my project on h264 streamer. Should be able to share the source code on the framer soon. I writing some documentation now and I need some help on the purposes of groupsock, usage environment etc... example: (1) // Begin by setting up our usage environment: TaskScheduler* scheduler = BasicTaskScheduler::createNew(); env = BasicUsageEnvironment::createNew(*scheduler); Why do we need to set up a taskscheduler? (2) //Create 'groupsocks' for RTP and RTCP: Groupsock rtpGroupsock(*env, destinationAddress, rtpPort, ttl); Groupsock rtcpGroupsock(*env, destinationAddress, rtcpPort, ttl); why do we need to create groupsock (3) Why do we need to implement the RTSP server? Can anyone guide me to the answes to the above questions? Many thanks and regards. zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070208/9bc0f582/attachment-0001.html From finlayson at live555.com Thu Feb 8 17:08:58 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 9 Feb 2007 11:08:58 +1000 Subject: [Live-devel] QuicktimeFileSink changes In-Reply-To: <000d01c74b98$e4a50280$6702a8c0@rudder> References: <000d01c74b98$e4a50280$6702a8c0@rudder> Message-ID: > I am modifying the QuickTimeFileSink file to include the >code for using the Quicktime library to save the file. Because you're changing the functionality of the class, please don't modify the existing "QuickTimeFileSink" code, otherwise you'll have problems whenever you download the latest version of the released code. Instead, write a new class. > Now, I am not sure I understand what you mean by >"frame". Is that a collection of RTP packets that (minus the RTP >header) that make up what Quicktime calls a 'sample'? No, not really. For video, it's a complete video frame. For audio, it's either a collection of audio samples (for things like PCM), or else a single encoded audio frame (for things like AAC). -- 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/20070208/0bac612f/attachment.html From bleary at harris.com Fri Feb 9 05:46:33 2007 From: bleary at harris.com (Leary, Brent) Date: Fri, 9 Feb 2007 08:46:33 -0500 Subject: [Live-devel] RFC 2250 Q Message-ID: <562FAD78E92B674A84927B71705A98DA034423AE@mlbe2k5.cs.myharris.net> Does the Live555 Media server follow RFC 2250 to transport video? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070209/90120560/attachment.html From Stefan.Delaere at DZINE.BE Fri Feb 9 07:53:38 2007 From: Stefan.Delaere at DZINE.BE (Stefan De Laere) Date: Fri, 9 Feb 2007 16:53:38 +0100 Subject: [Live-devel] MPEG2TransportStreamMultiplexor Message-ID: <006701c74c62$772f4100$7500000a@dzine.be> Hi Ross, Some context: I have the following setup: - An in house designed embedded x86 platform - An in house designed add-on module (PCIExpress interface) which features an nGene-Decypher (Micronas-WISChip) High definition (MPEG2/H264/MPEG4/VC1) decoder solution. This add-on module must be fed with a Constant Bitrate Transport Stream (possibly containing null packets) using DMA transfers over the PCIExpress bus. Actually I need a transport stream source with a fixed bitrate and a stable clock with a precision better than 100ppm With this setup, I have to achieve the following functionality: 1. Play prerecorded constant bitrate transport streams (already containing null packets) that are stored on harddisk. This is already implemented. 2. Play MPEG1/MPEG2 program streams stored on harddisk (because our product supports program streams and we have to be backwards compatible). 3. Play transport streams coming in from the network using RTP/RTCP. I'm already using the live555 libraries for this purpose. My question concerns the creation of a transport stream. For the moment I am using the MPEG1or2Demux, MPEG1or2DemuxedElementaryStream and MPEG2TransportStreamMultiplexor classes for creating the transport stream in case of MPEG2. Problem is that this transport stream is not a constant bitrate one and I need to insert null packets. The data output from the MPEG2TransportStreamMultiplexor is fed to a MediaSink derived object but it is missing fPresentationTime and durationInMicroseconds. Can this easily be added to the doGetNextFrame() function in MPEG2TransportStreamMultiplexor? Or do you have any other suggestions of how I can create such a constant bitrate transport stream. Likewise, for MPEG4, H264 and VC1, I will also have to create a constant bitrate transport stream... Best Regards, Stefan De Laere R&D Department Email: stefan.delaere at dzine.be 't Hoge 49 B-8500 KORTRIJK BELGIUM www.dzine.be From finlayson at live555.com Sat Feb 10 02:14:44 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 10 Feb 2007 20:14:44 +1000 Subject: [Live-devel] RFC 2250 Q In-Reply-To: <562FAD78E92B674A84927B71705A98DA034423AE@mlbe2k5.cs.myharris.net> References: <562FAD78E92B674A84927B71705A98DA034423AE@mlbe2k5.cs.myharris.net> Message-ID: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C74C50.B5ECF64E" > >Does the Live555 Media server follow RFC 2250 to transport video? Yes, but note that this RFC is only for MPEG-1 or 2 Video RTP streams. Transport of other kinds of stream - including MPEG-4, H.263+ and H.264 - is defined using other RFCs (but we support those also). To implement RFC 2250, we use the "MPEG1or2VideoRTPSource/Sink" classes (for Video Elementary Streams), the "MPEG1or2AudioRTPSource/Sink" classes (for Audio Elementary Streams), and the "SimpleRTPSource/Sink" classes (for Transport Streams). Note also the numerous demo applications that use these classes. -- 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/20070210/d661824a/attachment.html From ruru605 at 163.com Sun Feb 11 04:46:06 2007 From: ruru605 at 163.com (ruru605) Date: Sun, 11 Feb 2007 20:46:06 +0800 Subject: [Live-devel] question about ServerMediaSubsession Message-ID: <200702112046046353885@163.com> Hi, everybody, I am a student and have just read the RFC of RTP,RTCP and RTSP. I am a rookie of live library. I started to read the code of this library and have some questions belows: 1. In the test programmes, I wonder why they use PassiveServerMediaSubsession to create a new subsession and to begin streaming through "sessionState.sink->startPlaying(*sessionState.source, afterPlaying, NULL)"? And I found that inside of PassiveServerMediaSubssion we did nothing about streaming.(Maybe I missed) In my opinion, RTSP is to control RTP(my understanding), so the situation should be like this: method startPlaying should be inside of ServerMediaSubssion so the streaming can be automatical. It seems that OnDemandServerMediaSubssion is doing so but I still don't quite understand. 2. When I test testMP3Steamer, the unicast address is pretty good, however, when the address is multicast address such as 232.255.42.42, although I add USE_SSM inside of Makefile, client using VLC within windows does not work while within linux works. Why? I am puzzled. Thanks and Regards Kangaroo (nickname) ruru605 2007-02-11 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070211/970129ee/attachment.html From finlayson at live555.com Sun Feb 11 16:01:12 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 12 Feb 2007 10:01:12 +1000 Subject: [Live-devel] question about ServerMediaSubsession In-Reply-To: <200702112046046353885@163.com> References: <200702112046046353885@163.com> Message-ID: > 1. In the test programmes, I wonder why they use >PassiveServerMediaSubsession to create a new subsession and to begin >streaming through >"sessionState.sink->startPlaying(*sessionState.source, afterPlaying, >NULL)"? And I found that inside of PassiveServerMediaSubssion we did >nothing >about streaming.(Maybe I missed) > In my opinion, RTSP is to control RTP(my >understanding), so the situation should be like this: >method startPlaying should be inside of ServerMediaSubssion so the >streaming can be automatical. It seems that >OnDemandServerMediaSubssion is doing so but I still don't quite >understand. "PassiveServerMediaSubsession" is used to implement a RTSP server for a stream (usually multicast) that already exists before the client accesses it (using RTSP). Therefore, for such a stream, we call "startPlaying" once, before (and independent of) each RTSP request. "OnDemandServerMediaSubsession", however, is used to implement a RTSP server that creates and serves new streams, on demand. I.e., a new stream is created for each RTSP client request. Therefore, for such a stream we call "startPlaying" for each RTSP request. This is done in the "OnDemandServerMediaSubsession" code. > 2. When I test testMP3Steamer, the unicast address is pretty >good, however, when the address is multicast address such as >232.255.42.42, although I add USE_SSM inside of Makefile, client >using VLC within windows does not work while within linux works. > Why? I am puzzled. So am I. I suggest using the "testOnDemandRTSPServer" demo application (a unicast RTSP server) instead. -- 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/20070211/513c1412/attachment.html From sanjay417 at rediffmail.com Mon Feb 12 09:17:33 2007 From: sanjay417 at rediffmail.com (sanjay kumar gupta) Date: 12 Feb 2007 17:17:33 -0000 Subject: [Live-devel] Rgd playing mp3 stream in Linux FC6. Message-ID: <20070212171733.3366.qmail@webmail90.rediffmail.com> Hi, I have installed Helix server in the LAN which is streaming MP3 file. I can save the stream into a file using openRTSP test program provided with live media library. I would like to play the stream directly (e.g. want to hear the music) in the Linux fedora core 6 instead of saving it into the file. Can you please suggest what kind of modification needed to do in openRTSP code to do this? do I need to use some other test program to do this? Please help me as I am new to this. Thanks in advance. Regards, Sanjay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070212/74587c88/attachment.html From finlayson at live555.com Mon Feb 12 14:57:24 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 13 Feb 2007 08:57:24 +1000 Subject: [Live-devel] Rgd playing mp3 stream in Linux FC6. In-Reply-To: <20070212171733.3366.qmail@webmail90.rediffmail.com> References: <20070212171733.3366.qmail@webmail90.rediffmail.com> Message-ID: >Hi, > I have installed Helix server in the LAN which is streaming MP3 file. >I can save the stream into a file using openRTSP test program >provided with live media library. >I would like to play the stream directly (e.g. want to hear the >music) in the Linux fedora core 6 instead of saving it into the file. >Can you please suggest what kind of modification needed to do in >openRTSP code to do this? If your MP3 player application can read from 'stdin', then you don't need to modify the "openRTSP" code at all. Instead, just run openRTSP -a rtsp://your-url | your-mp3-player-application Alternatively (and better, IMHO), just run VLC, which will be able to play the stream (from the "rtsp://" URL) directly. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From xcsmith at rockwellcollins.com Mon Feb 12 15:50:14 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Mon, 12 Feb 2007 17:50:14 -0600 Subject: [Live-devel] Help: cause of RTP packet loss Message-ID: Hello! I hope you will please help me figure out the reason I am losing RTP packets when recording a live stream. The RTCP of my openRTSP reports packet loss (I'm using ethereal to look at this). My recorded video also shows large chunks of missing data and freezes. When I use VLC to play the recorded video, VLC messages say "buffer underrun" every time the video freezes. So I think that somehow I am losing RTP packets. When I play the video live using VLC as an RTSP client, the video is fine. It seems that about every 30 - 40 seconds, a large number of packets are dropped. I thought this was happening every time the packet reorder threshold is reached, but now I'm not quite so sure of this. I tried increasing the wait threshold to 40 seconds and the RTP socket buffer in MultiFramedRTPSource to 100 MB (which I see is successfully changed). I have varied the wait threshold to 1, 2, 20 and 40 seconds. I also used the default 100ms. I have tried the following things to figure out the cause of lost packets. 1. In ReorderingPacketBuffer::getNextCompletedPacket() print debug statement any time fHeadPacket->rtpSeqNo() != fNextExpectedSeqNo. I got quite a lot of printout from this statement. I printed both the head packet and the expected sequence number. I checked ethereal, and the missing seq no. packets had been sent to me. Later I removed this and just print a single statement any time the "packetLossPreceded" was set to true. 2. Add printf to MultiframedRTPSource::networkReadHandler() for each case in which an RTP packet could be discarded before being stored in fReorderingBuffer. None of my RTP packets seem to be invalidated before being stored. 3. Add printf to MultiframedRTPSource::networkReadHandler() to show if fReorderingBuffer->storePacket fails. No failures reported. 4. Comment out using MPEG2TransportStreamFramer in MediaSession.cpp. It doesn't seem to make much of a difference whether or not MPEG2TransportStreamFramer is used or if the RTPSource goes directly to FileSink. 5. In ReorderingPacketBuffer::storePacket() print debug statement any time we see a late packet. No late packets noted. I also notice that the RTP packets sent to me all have an RTPTime of 0. Ethereal I/O graph shows my data rate to be about 4 Mbps. My host computer is on a private network with 1 other computer and 2 embedded computers which are used as RTSP servers or clients. I can't see how it's possible for network packets to be 30 - 40 seconds late on this private network, but I see that LIVE acts as though this is happening. Can you point me to a part of the code to look at for these RTP packet losses? Any ideas for me? Thank you! Xochitl From zhouh31415 at 163.com Mon Feb 12 17:19:57 2007 From: zhouh31415 at 163.com (=?gbk?B?1ty66w==?=) Date: Tue, 13 Feb 2007 09:19:57 +0800 (CST) Subject: [Live-devel] Help: cause of RTP packet loss In-Reply-To: References: Message-ID: <26065131.90781171329597718.JavaMail.root@bj163app15.163.com> Hello, I can't answer your questions, but I have some suggestions. First, making sure your stream is good with UDP client and server.Maybe the problem does not come from RTP. Second, your test program must run in the simplest net environment. Third, you must know the problem come from which side- receiver or sender or both of them. ?2007-02-13?xcsmith at rockwellcollins.com ??? Hello! I hope you will please help me figure out the reason I am losing RTP packets when recording a live stream. The RTCP of my openRTSP reports packet loss (I'm using ethereal to look at this). My recorded video also shows large chunks of missing data and freezes. When I use VLC to play the recorded video, VLC messages say "buffer underrun" every time the video freezes. So I think that somehow I am losing RTP packets. When I play the video live using VLC as an RTSP client, the video is fine. It seems that about every 30 - 40 seconds, a large number of packets are dropped. I thought this was happening every time the packet reorder threshold is reached, but now I'm not quite so sure of this. I tried increasing the wait threshold to 40 seconds and the RTP socket buffer in MultiFramedRTPSource to 100 MB (which I see is successfully changed). I have varied the wait threshold to 1, 2, 20 and 40 seconds. I also used the default 100ms. I have tried the following things to figure out the cause of lost packets. 1. In ReorderingPacketBuffer::getNextCompletedPacket() print debug statement any time fHeadPacket->rtpSeqNo() != fNextExpectedSeqNo. I got quite a lot of printout from this statement. I printed both the head packet and the expected sequence number. I checked ethereal, and the missing seq no. packets had been sent to me. Later I removed this and just print a single statement any time the "packetLossPreceded" was set to true. 2. Add printf to MultiframedRTPSource::networkReadHandler() for each case in which an RTP packet could be discarded before being stored in fReorderingBuffer. None of my RTP packets seem to be invalidated before being stored. 3. Add printf to MultiframedRTPSource::networkReadHandler() to show if fReorderingBuffer->storePacket fails. No failures reported. 4. Comment out using MPEG2TransportStreamFramer in MediaSession.cpp. It doesn't seem to make much of a difference whether or not MPEG2TransportStreamFramer is used or if the RTPSource goes directly to FileSink. 5. In ReorderingPacketBuffer::storePacket() print debug statement any time we see a late packet. No late packets noted. I also notice that the RTP packets sent to me all have an RTPTime of 0. Ethereal I/O graph shows my data rate to be about 4 Mbps. My host computer is on a private network with 1 other computer and 2 embedded computers which are used as RTSP servers or clients. I can't see how it's possible for network packets to be 30 - 40 seconds late on this private network, but I see that LIVE acts as though this is happening. Can you point me to a part of the code to look at for these RTP packet losses? Any ideas for me? Thank you! Xochitl _______________________________________________ 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/20070212/ef88bc21/attachment.html From finlayson at live555.com Mon Feb 12 17:51:59 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 13 Feb 2007 11:51:59 +1000 Subject: [Live-devel] Help: cause of RTP packet loss In-Reply-To: References: Message-ID: First, note that, in your case, the 'reordering buffer threshold' is a complete 'red herring'. That becomes relevant only when you have out-of-order packets in the network. On a LAN, it's very unlikely that any packets are out-of-order, so you should leave this threshold at its default value (100ms). The key pieces of information in your message are: 1/ If you play the stream using VLC, you don't seem to lose any packets. 2/ If you record the stream using openRTSP, you seem to lose packets. Note also that the incoming packets are getting dropped before they even reach the LIVE555 RTP reception/handling code, so no amount of messing with that code is going to help things. Because the client RTSP code (the "LIVE555 Streaming Media" libraries) is the same in both cases, and because your socket receive buffer is at least as large as that (2000000) used by VLC, the difference has to be related to the fact that in case 2/, you're writing the incoming data to a file, rather than feeding it to decoding/rendering software. So I suspect that occasionally, on your OS, writes to a file are blocking for a sufficient amount of time to cause incoming RTP packets to overflow some internal buffer and get dropped within the OS. I don't know why this would be happening, but perhaps disk seeking is to blame, in which case you could check to see whether you can (somehow) increase your OS file system's write-ahead buffering. Anyway, you can test this hypothesis by running openRTSP -v rtsp://whatever > /dev/null i.e., by discarding the incoming data rather than writing it to a file, and checking (from RTCP reception reports) whether or not you still see packet loss. If that doesn't shed any light on your problem, then I don't know what else could be going wrong. Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ruru605 at 163.com Mon Feb 12 18:30:20 2007 From: ruru605 at 163.com (ruru605) Date: Tue, 13 Feb 2007 10:30:20 +0800 Subject: [Live-devel] Questions about RTP transportation Message-ID: <200702131030190005250@163.com> Hi, Ross, Thanks very much for answering my question. I have another question here: As I know, RTCP is used to control the transport of RTP. 1.But how can I know the speed of RTP transportation? I saw the method "buildandSendPacket()" is to packet a RTP packets and send them one by one but did not find anything related to the speed. 2.When RTCP packet is received, we can get some value such as fraction lost, jitter ..etc. But what are we going to do after receiving such dataes? Are we going to change some parameters in order to changed the speed of RTP transportation?(Just my point, maybe wrong) I did not find these parameters. Please help me. Best Regards to you! Thanks again. Kangaroo ruru605 2007-02-13 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070212/84c0559e/attachment.html From rmpg2001 at gmail.com Tue Feb 13 02:16:25 2007 From: rmpg2001 at gmail.com (Ramon Martin de Pozuelo) Date: Tue, 13 Feb 2007 11:16:25 +0100 Subject: [Live-devel] H264 Session Message-ID: <389189e20702130216y4d0aa32ak6404eb7135c0cb32@mail.gmail.com> Hi all!!, I create a test program that sends broadcast H.264 video. I create a class that derives from H264VideoStreamFramer and takes the video information from another application that extract the NAL Units from a file. My application uses PassiveServerMediaSubsession to send broadcast and it works very well, but it only works opening a SDP file in VLC. What kind of session could I use to send that video on broadcast (or maybe unicast) and supporting RTSP? Have I to create my own MediaSubsession? Thanks in Advance, Ramon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070213/6e3826ec/attachment.html From morgan.torvolt at gmail.com Tue Feb 13 04:51:03 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Tue, 13 Feb 2007 16:51:03 +0400 Subject: [Live-devel] Read ahead on Linux Message-ID: <3cc3561f0702130451k5e5b1199j1f47904126b26184@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. Just following up on this issue. Rumors say that the next kernel release will incorporate adaptive read-ahead. Here is some old reading material I dug, although I am not sure that it is exactly this that is being included in the upcoming kernel release: http://kerneltrap.org/node/6642 It seems like our fixes that does read-ahead in the application will now become obsolete. For releases like redhat and others, it will probably take some time before the update arrives. When this is up and running, it will make all our lives much easier =) -Morgan- From armando at highseascs.com Tue Feb 13 06:47:35 2007 From: armando at highseascs.com (Armando de Oliveira Fortuna) Date: Tue, 13 Feb 2007 08:47:35 -0600 Subject: [Live-devel] QuicktimeFileSink changes Message-ID: <000a01c74f7d$e61ec130$6702a8c0@rudder> Hi Ross, That is exactly what I am doing - creating a new class based on methods available in the QuicktimeFileSink class. a) How can I retrieve the frame rate, and audio sampling rate that may be sent down by the streaming server? b) I am not sure of the relationship between afterGettingFrame, useFrame and useFrame1. Can you please give me a quick description of their functionality? Do I need the Chunk list? Thank you, Armando -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070213/65c84f93/attachment-0001.html From armandopoulos at yahoo.fr Tue Feb 13 07:51:36 2007 From: armandopoulos at yahoo.fr (Armando Ko) Date: Tue, 13 Feb 2007 15:51:36 +0000 (GMT) Subject: [Live-devel] help -- Streaming RTP/JPEG Multicast Message-ID: <910142.35722.qm@web86909.mail.ukl.yahoo.com> hi Ross, i try to stream jpeg Files as RTP Multicast with the live555. But i can stream the jpegfiles but the vlc cannot see them and with wireshark i can see the jpeg frames they are sending, also here is my test program for do it. i would be very happy, if you can give me some tips or what is wrong in my code. The ImageSource is a subclass of JPEGVideoSource where i define this methodes createNew(UsageEnvironment& env, char const* fileName, unsigned viewTime); // redefined virtual functions: virtual void doGetNextFrame(); virtual u_int8_t type(); virtual u_int8_t qFactor(); virtual u_int8_t width(); virtual u_int8_t height(); virtual u_int8_t const* quantizationTables(u_int8_t& precision, u_int16_t& length); here is my testprogramm (see attachment) thanks 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/20070213/cf6ccc43/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: testJPEGStreamer.cpp Type: text/x-c++src Size: 2580 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070213/cf6ccc43/attachment.bin From sanjay417 at rediffmail.com Tue Feb 13 09:59:36 2007 From: sanjay417 at rediffmail.com (sanjay kumar gupta) Date: 13 Feb 2007 17:59:36 -0000 Subject: [Live-devel] Rgd playing mp3 stream in Linux FC6. Message-ID: <20070213175936.9544.qmail@webmail91.rediffmail.com> ?Hi Ross, Thanks for your reply. My simple mp3 player application is based on gstreamer (using elements like filesrc, decodebin,alsasink etc) which takes mp3 file name as input. so I think it can not read from stdin & play the mp3 stream. Though VLC media player is good option but we are not allowed to use these player as mentioned in the assignment. So we want to read the RTP media data using library, decode it and play the mp3 decoded data. I read that SDL_sound library can be used to decode the buffer and can be played the decode raw data. Currently openRTSP is using sink classes to write the data into given file name (file or stdout). can we get the rtp data buffer directly (may be in some callback)using live media library rather than writing it to file or stdout so that I can manage this buffer in some data structure (e.g. list) and will try to play using SDL sound library parallely. dont know if this idea will work. Please give some idea if you have any. Thanks in advance. Regards, Sanjay On Tue, 13 Feb 2007 Ross Finlayson wrote : > >Hi, > > I have installed Helix server in the LAN which is streaming MP3 file. > >I can save the stream into a file using openRTSP test program > >provided with live media library. > >I would like to play the stream directly (e.g. want to hear the > >music) in the Linux fedora core 6 instead of saving it into the file. > >Can you please suggest what kind of modification needed to do in > >openRTSP code to do this? > >If your MP3 player application can read from 'stdin', then you don't >need to modify the "openRTSP" code at all. Instead, just run > openRTSP -a rtsp://your-url | your-mp3-player-application > >Alternatively (and better, IMHO), just run VLC, which will be able to >play the stream (from the "rtsp://" URL) directly. >-- > >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/20070213/9010a6b2/attachment.html From rajat.dudeja at tcs.com Tue Feb 13 10:22:53 2007 From: rajat.dudeja at tcs.com (rajat.dudeja at tcs.com) Date: Tue, 13 Feb 2007 23:52:53 +0530 Subject: [Live-devel] Not able to send 50 RTP packets / sec to the mobile Message-ID: An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070213/71ebcb79/attachment.html From finlayson at live555.com Tue Feb 13 17:18:41 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Feb 2007 14:18:41 +1300 Subject: [Live-devel] H264 Session In-Reply-To: <389189e20702130216y4d0aa32ak6404eb7135c0cb32@mail.gmail.com> References: <389189e20702130216y4d0aa32ak6404eb7135c0cb32@mail.gmail.com> Message-ID: >I create a test program that sends broadcast H.264 video. I create a >class that derives from H264VideoStreamFramer and takes the video >information from another application that extract the NAL Units from >a file. My application uses PassiveServerMediaSubsession to send >broadcast and it works very well, but it only works opening a SDP >file in VLC. What kind of session could I use to send that video on >broadcast (or maybe unicast) and supporting RTSP? Have I to create >my own MediaSubsession? Yes, you should create your own subclass of "OnDemandServerMediaSubsession". See the numerous examples of this in the code. ("PassiveServerMediaSubsession" is used only for accessing pre-existing multicast streams.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ymreddy at ssdi.sharp.co.in Tue Feb 13 22:33:57 2007 From: ymreddy at ssdi.sharp.co.in (Mallikharjuna Reddy (NAVT)) Date: Wed, 14 Feb 2007 12:03:57 +0530 Subject: [Live-devel] FW: [vlc-devel] Re: RTCP reports Message-ID: <7FB4685EA93D014C8E30AA087B66E7520337D1F8@ssdimailsrvnt01.ssdi.sharp.co.in> Hi Ross, Can you help us in this issue. We are trying to log the RTCP reports in VLC. We observed that this functionality is not being called in RTCP.cpp file. Any pointers to solve this issue. Thanks and Regards Y. Mallikharjuna Reddy -----Original Message----- From: vlc-devel-bounce at videolan.org [mailto:vlc-devel-bounce at videolan.org]On Behalf Of Jean-Paul Saman Sent: Tuesday, February 13, 2007 2:17 PM To: vlc-devel at videolan.org Subject: [vlc-devel] Re: RTCP reports Mallikharjuna Reddy (NAVT) wrote: > Hi Jean-Paul Saman, > > Thanks for the information. > > We downloaded the latest source code from LIVE555 site and modified the > function incomingReportHandler1() in RTCP.cpp file. We added the logging > functionality in this file. We compiled the LIVE555 source and kept the new > libliveMedia.a file in \cygwin\usr\win32\live.com\liveMedia\ directory. We > re-compiled VLC, but still observed that logging is not happening/is not > being called in this RTCP.cpp file. > > Any inputs on this. Sorry cannot help you on this. You must ask questions about live555 library on the live devel mailinglist. Gtz, Jean-Paul Saman. -- This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/ To unsubscribe, please read http://developers.videolan.org/lists.html From finlayson at live555.com Tue Feb 13 21:23:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Feb 2007 18:23:55 +1300 Subject: [Live-devel] Not able to send 50 RTP packets / sec to the mobile In-Reply-To: References: Message-ID: >Hi All, > >I new to the live555 and and have some queries related to speed of >RTP-AMR payloads. > >My system is a WindowsXP and I'm working on .Net Environment. > >I'm using the testAMRAudioStreamer test program to send the RTP >packets to a mobile phone( a samsung mobile phone). My requirement >is to send / receive 50 packets to / from Mobile in 20ms .For this >I'm using the FT=7 which in the code gives me a frame size of 31 >frames. (per packet) > >But I'm not getting the required results. Instead, just 2 or 3 >packets are send per sec The code used by "testAMRAudioStreamer" should be sending packets at the correct rate (indicated by the headers of the audio frames contain in the AMR audio file). Please send us a copy of your "test.amr" audio file, so I can take a look at it, and investigate what might be going wrong. -- 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/20070213/0b26d008/attachment-0001.html From finlayson at live555.com Wed Feb 14 00:39:24 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Feb 2007 21:39:24 +1300 Subject: [Live-devel] FW: [vlc-devel] Re: RTCP reports In-Reply-To: <7FB4685EA93D014C8E30AA087B66E7520337D1F8@ssdimailsrvnt01.ssdi.sharp.co.in > References: <7FB4685EA93D014C8E30AA087B66E7520337D1F8@ssdimailsrvnt01.ssdi.sharp.co.in > Message-ID: >We are trying to log the RTCP reports in VLC. We observed that this >functionality is not being called in RTCP.cpp file. > >Any pointers to solve this issue. Look at how "openRTSP" implements its "-Q" option. (Hint: Search for "RTPReceptionStats" in "testProgs/playCommon.cpp") -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rajat.dudeja at tcs.com Wed Feb 14 01:23:55 2007 From: rajat.dudeja at tcs.com (Rajat Dudeja) Date: Wed, 14 Feb 2007 14:53:55 +0530 Subject: [Live-devel] Not able to send 50 RTP packets / sec to the mobile Message-ID: Hi All, I new to the live555 and and have some queries related to speed of RTP-AMR payloads. My system is a WindowsXP and I'm working on .Net Environment. I'm using the testAMRAudioStreamer test program to send the RTP packets to a mobile phone( a Samsung mobile phone). My requirement is to send / receive 50 packets to / from Mobile in 20ms .For this I'm using the FT=7 which in the code gives me a frame size of 31 frames. (per packet) But I'm not getting the required results. Instead, just 2 or 3 packets are send per sec I havn't made much changes in the existing base libraries(i.e. > livemedia, groupsock, basicUsageEnvironment or UsageEnvironment). and Neither I'm required to ( I suppose as of now ) I see that the problem could be in the DelayQueueEntry, DelayQueue and AlarmHandler. Am I right? In these libraries: 1.First, I could not understand much of the functionality of the DelayQueueEntry, DelayQueue and AlarmHandler. Particularly, on what basis the entries are added / removed from the DelayQueueEntry,(though on some time basis, but not very sure)? 2. What is the role of the synchronize in the DelayQueue? 3. Please some one brief me on the description of these libraries. 4. So, is the problem (and its solution) to controlling the rate of RTP tranmission really with these 3 libraries? Or is there any other thing more to be looked into? Please advice. Thanks and regards, Rajat =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070214/56b2912c/attachment.html From susovan at tataelxsi.co.in Wed Feb 14 04:13:52 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Wed, 14 Feb 2007 17:43:52 +0530 Subject: [Live-devel] how to run live555 server on windows Message-ID: <003501c75031$976d70e0$0a2a320a@telxsi.com> respected sir, first i simple put a mpg file in the current directory and run the exc file live555MediaServer.exe from command prompt .Then i tried to run this file through VLC player. But it could not connect to server.so kindly inform me the basic steps. Thank you Susovan Ghosh From armandopoulos at yahoo.fr Wed Feb 14 06:05:00 2007 From: armandopoulos at yahoo.fr (Armando Ko) Date: Wed, 14 Feb 2007 14:05:00 +0000 (GMT) Subject: [Live-devel] Re : help -- Streaming RTP/JPEG Multicast Message-ID: <20070214140501.7690.qmail@web86912.mail.ukl.yahoo.com> hi, i try to stream jpeg image files as multicast to 239.255.42.42 but vlc can show the pictures in the report i can read this errors ps warning: found sync code ps warning: garbage at input, trying to resync... i don?t know what are missing in the streaming. i think i don?t need "ByteStreamFileSource" to open the file as a byte stream but open the file also stream like this m_ImageSource = ImageSource::createNew(*m_Env, pFileName, timeToDisplay); if (m_ImageSource == NULL) { *m_Env << "Unable to open file \"" << pFileName << "\" as a byte-stream file source\n"; return FALSE; } // Finally, start playing --------------------------------- *m_Env << "Beginning streaming image...\n"; m_ImageSink->startPlaying(*m_ImageSource, OnEndShowImage, this); thanks for a tips or ideas. Armando ----- Message d'origine ---- De : Armando Ko ? : live-devel at ns.live555.com Envoy? le : Mardi, 13 F?vrier 2007, 16h51mn 36s Objet : [Live-devel] help -- Streaming RTP/JPEG Multicast hi Ross, i try to stream jpeg Files as RTP Multicast with the live555. But i can stream the jpegfiles but the vlc cannot see them and with wireshark i can see the jpeg frames they are sending, also here is my test program for do it. i would be very happy, if you can give me some tips or what is wrong in my code. The ImageSource is a subclass of JPEGVideoSource where i define this methodes createNew(UsageEnvironment& env, char const* fileName, unsigned viewTime); // redefined virtual functions: virtual void doGetNextFrame(); virtual u_int8_t type(); virtual u_int8_t qFactor(); virtual u_int8_t width(); virtual u_int8_t height(); virtual u_int8_t const* quantizationTables(u_int8_t& precision, u_int16_t& length); here is my testprogramm (see attachment) thanks 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. UsageEnvironment* env; char const* inputFileName = "test.jpeg"; ImageSource* ImageSource; JPEGVideoRTPSink* ImageSink; void play(); // forward int main(int argc, char** argv) { // Begin by setting up our usage environment: TaskScheduler* scheduler = BasicTaskScheduler::createNew(); m_Env = BasicUsageEnvironment::createNew(*scheduler); // Create 'groupsocks' for RTP and RTCP: char* destinationAddressStr = "239.255.42.42"; const unsigned short rtpPortNum = 1234; const unsigned short rtcpPortNum = rtpPortNum+1; const unsigned char ttl = 7; // low, in case routers don't admin scope struct in_addr destinationAddress; destinationAddress.s_addr = our_inet_addr(destinationAddressStr); const Port rtpPort(rtpPortNum); const Port rtcpPort(rtcpPortNum); Groupsock rtpGroupsock(*env, destinationAddress, rtpPort, ttl); Groupsock rtcpGroupsock(*env, destinationAddress, rtcpPort, ttl); ImageSink = JPEGVideoRTPSink::createNew(*m_Env, rtpGroupsock); // Create (and start) a 'RTCP instance' for this RTP sink: const unsigned estimatedSessionBandwidth = 5000; // in kbps; for RTCP b/w share const unsigned maxCNAMElen = 100; unsigned char CNAME[maxCNAMElen+1]; gethostname((char*)CNAME, maxCNAMElen); CNAME[maxCNAMElen] = '\0'; // just in case RTCPInstance::createNew(*m_Env,m_rtcpGroupsock, estimatedSessionBandwidth, CNAME, ImageSink, NULL /* we're a server */,/*isSSM*/false); // Finally, start the streaming: *env << "Beginning streaming...\n"; play(); env->taskScheduler().doEventLoop(); // does not return return 0; // only to prevent compiler warning } void afterPlaying(void* /*clientData*/) { *env << "...done reading from file\n"; Medium::close(ImageSource); // Note that this also closes the input file that this source read from. play(); } void play() { //----------- Create a framer for the image elementary Stream--------- m_ImageSource = ImageSource::createNew(*m_Env, inputFileName, timeToDisplay); //timeToDisplay if (m_ImageSource == NULL) { *m_Env << "Unable to open file \"" << inputFileName << "\" as a byte-stream file source\n"; return FALSE; } // Finally, start playing --------------------------------- *m_Env << "Beginning streaming image...\n"; m_ImageSink->startPlaying(*m_ImageSource, afterPlaying, ImageSink); } _______________________________________________ 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/20070214/dcc76b90/attachment.html From xcsmith at rockwellcollins.com Wed Feb 14 12:37:43 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Wed, 14 Feb 2007 14:37:43 -0600 Subject: [Live-devel] Error reporting guidelines Message-ID: What are the coding guidelines for using the error and message reporting in LIVE? I see different functions being used such as "env <<" "env.setResultMsg()" "perror()" "fprintf(stderr ... " Thanks! ?????????????????????????????????????????? Xochitl Smith GS Software Engineer; Computer-E (Embedded image moved to file: ph: 319.263.0191 pic06270.jpg) xcsmith at rockwellcollins.com ?????????????????????????????????????????? -------------- next part -------------- A non-text attachment was scrubbed... Name: pic06270.jpg Type: image/jpeg Size: 2784 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070214/d9b066b3/attachment-0001.jpg From finlayson at live555.com Wed Feb 14 14:28:48 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Feb 2007 11:28:48 +1300 Subject: [Live-devel] Error reporting guidelines In-Reply-To: References: Message-ID: >What are the coding guidelines for using the error and message reporting in >LIVE? I see different functions being used such as "env <<" >"env.setResultMsg()" "perror()" "fprintf(stderr ... " Best is to use "env <<", because that will work even if you later change your "UsageEnvironment" to use something other than console 'stderr'. ("fprintf(stderr, ...)" is still used in a few places in the code for casual debugging, but shouldn't really be; "env <<" is the preferred way to output error messages. (In contrast, "env.setResultMsg()" is used to assign a (usually error) message that you may or may not necessarily want to print out later.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Feb 14 14:41:41 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Feb 2007 11:41:41 +1300 Subject: [Live-devel] how to run live555 server on windows In-Reply-To: <003501c75031$976d70e0$0a2a320a@telxsi.com> References: <003501c75031$976d70e0$0a2a320a@telxsi.com> Message-ID: > respected sir, > first i simple put a mpg file in the current directory >and run the exc file live555MediaServer.exe from command prompt .Then i >tried to run this file through > VLC player. But it could not connect to server.so >kindly inform me the basic steps. See -- 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/20070214/ae33156b/attachment.html From finlayson at live555.com Wed Feb 14 14:43:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Feb 2007 11:43:07 +1300 Subject: [Live-devel] Not able to send 50 RTP packets / sec to the mobile In-Reply-To: References: Message-ID: Once again: Please send us a copy of your "test.amr" audio file, so I can take a look at it, and investigate what might be going wrong. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ruru605 at 163.com Wed Feb 14 17:10:07 2007 From: ruru605 at 163.com (ruru605) Date: Thu, 15 Feb 2007 09:10:07 +0800 Subject: [Live-devel] help about RTCP Message-ID: <200702150910061258754@163.com> Hi, Ross The day before yesterday I emailed you but I did not receive reply because I lost one email from live-level. I rewrite it here and wait for your reply. I have another question here: As I know, RTCP is used to control the transport of RTP. 1.But how can I know the speed of RTP transportation? I saw the method "buildandSendPacket()" is to packet a RTP packets and send them one by one but did not find anything related to the speed. 2.When RTCP packet is received, we can get some value such as fraction lost, jitter ..etc. But what are we going to do after receiving such dataes? Are we going to change some parameters in order to changed the speed of RTP transportation?(Just my point, maybe wrong) I did not find these parameters. Please help me. Best Regards to you! Thanks again. Kangaroo ruru605 2007-02-15 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070214/2d05b397/attachment.html From susovan at tataelxsi.co.in Wed Feb 14 20:28:05 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Thu, 15 Feb 2007 09:58:05 +0530 Subject: [Live-devel] how to run live555 server on windows Message-ID: <002301c750b9$aff06e50$0a2a320a@telxsi.com> respected sir, first i simple put a mpg file in the current directory and run the exc file live555MediaServer.exe from command prompt .Then i tried to run this file through VLC player. But it could not connect to server.so kindly inform me the basic steps. See -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ Hi Ross you told me to see the above URL.But in that question the error message is different.So i send you the error messages that i got from VLC player for am MP3 file. live555 error: Failed to connect with rtsp://10.50.42.10/NEEL.MP3 main error: no suitable access module for `rtsp://10.50.42.10/NEEL.MP3' main debug: creating new input thread main debug: waiting for thread completion main debug: thread 3904 (input) created at priority 1 (input/input.c:265) main debug: `rtsp://10.50.42.10/NEEL.MP3' gives access `rtsp' demux `' path `10.50.42.10/NEEL.MP3' main debug: creating demux: access='rtsp' demux='' path='10.50.42.10/NEEL.MP3' main debug: looking for access_demux module: 1 candidate live555 debug: DESCRIBE failed with 0: cannot handle DESCRIBE response: RTSP/1.0 404 Not Found live555 debug: we will now try HTTP tunneling mode live555 debug: DESCRIBE failed with 0: connect() failed: Unknown error live555 error: Failed to connect with rtsp://10.50.42.10/NEEL.MP3 main warning: no access_demux module matching "rtsp" could be loaded main debug: creating access 'rtsp' path='10.50.42.10/NEEL.MP3' main debug: looking for access2 module: 5 candidates main debug: net: connecting to 10.50.42.10 port 554 main debug: connection in progress access_realrtsp debug: rtsp connected access_realrtsp warning: only real/helix rtsp servers supported for now vcd debug: trying .cue file: 10.50.42.10/NEEL.cue vcd debug: could not find .cue file access_file warning: 10.50.42.10/NEEL.MP3: No such file or directory cdda debug: trying .cue file: 10.50.42.10/NEEL.cue cdda debug: could not find .cue file cdda warning: could not open 10.50.42.10/NEEL.MP3 main warning: no access2 module matching "rtsp" could be loaded main error: no suitable access module for `rtsp://10.50.42.10/NEEL.MP3' main debug: thread times: real 0m2.203026s, kernel 0m0.015625s, user 0m0.000000s main debug: thread 3904 joined (input/input.c:412) main: nothing to pla So now i need your help what to do next to over come thisproblem. I have another proble.I can not unzip the source code. So please help me out. Thank you. Susovan Ghosh From susovan at tataelxsi.co.in Wed Feb 14 22:17:38 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Thu, 15 Feb 2007 11:47:38 +0530 Subject: [Live-devel] client support Message-ID: <004401c750c8$fe2be7c0$0a2a320a@telxsi.com> respected sir, i am working with live555media server.i want to know the no of client that the server can support simultaniously. thank you Susovan Ghosh From rajat.dudeja at tcs.com Thu Feb 15 00:57:03 2007 From: rajat.dudeja at tcs.com (Rajat Dudeja) Date: Thu, 15 Feb 2007 14:27:03 +0530 Subject: [Live-devel] Attached Test.amr file to investigate the less number of RTP packets being sent. In-Reply-To: Message-ID: > Date: Wed, 14 Feb 2007 18:23:55 +1300 > From: Ross Finlayson > Subject: Re: [Live-devel] Not able to send 50 RTP packets / sec to the > mobile > To: LIVE555 Streaming Media - development & use > > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > >Hi All, > > > >I new to the live555 and and have some queries related to speed of > >RTP-AMR payloads. > > > >My system is a WindowsXP and I'm working on .Net Environment. > > > >I'm using the testAMRAudioStreamer test program to send the RTP > >packets to a mobile phone( a samsung mobile phone). My requirement > >is to send / receive 50 packets to / from Mobile in 20ms .For this > >I'm using the FT=7 which in the code gives me a frame size of 31 > >frames. (per packet) > > > >But I'm not getting the required results. Instead, just 2 or 3 > >packets are send per sec > > The code used by "testAMRAudioStreamer" should be sending packets at > the correct rate (indicated by the headers of the audio frames > contain in the AMR audio file). > > Please send us a copy of your "test.amr" audio file, so I can take a > look at it, and investigate what might be going wrong. > -- Ross, Please find the zipped test.amr file attached. Regards, Rajat =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070215/4d7d0aec/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: test.zip Type: application/zip Size: 63408 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070215/4d7d0aec/attachment-0001.zip From finlayson at live555.com Thu Feb 15 01:46:03 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Feb 2007 22:46:03 +1300 Subject: [Live-devel] client support In-Reply-To: <004401c750c8$fe2be7c0$0a2a320a@telxsi.com> References: <004401c750c8$fe2be7c0$0a2a320a@telxsi.com> Message-ID: > i am working with live555media server.i want to know >the no of client that the server can support simultaniously. There's no inherent limit. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Feb 15 01:50:47 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Feb 2007 22:50:47 +1300 Subject: [Live-devel] Attached Test.amr file to investigate the less number of RTP packets being sent. In-Reply-To: References: Message-ID: Your file "test.amr" gets streamed correctly by both "testAMRAudioStreamer" and "live555MediaServer". In each case, QuickTime Player is able to play the stream (from the "rtsp://" URL OK). Note, however, that VLC currently cannot play the stream - perhaps because it does not have an AMR audio decoder. (If you wish to complain about this, you should do so on a VLC mailing list.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Feb 15 01:56:28 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Feb 2007 22:56:28 +1300 Subject: [Live-devel] how to run live555 server on windows In-Reply-To: <002301c750b9$aff06e50$0a2a320a@telxsi.com> References: <002301c750b9$aff06e50$0a2a320a@telxsi.com> Message-ID: >main debug: `rtsp://10.50.42.10/NEEL.MP3' gives access `rtsp' demux `' path >`10.50.42.10/NEEL.MP3' >main debug: creating demux: access='rtsp' demux='' >path='10.50.42.10/NEEL.MP3' >main debug: looking for access_demux module: 1 candidate >live555 debug: DESCRIBE failed with 0: cannot handle DESCRIBE response: >RTSP/1.0 404 Not Found The problem is that your file had file name extension ".MP3". For the LIVE555 Media Server to recognize it, it must instead have file name extension ".mp3" - i.e., lower case. Therefore, you should rename your file to "NEEL.mp3", and you will be able to stream it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From e.beckers at gmail.com Thu Feb 15 02:30:39 2007 From: e.beckers at gmail.com (Erwin Beckers) Date: Thu, 15 Feb 2007 11:30:39 +0100 Subject: [Live-devel] fix for stuttering video and audio when streaming an mpeg-2 transport stream Message-ID: Hi, 80% of all my mpeg-2 transport files can be streamed very nice with the live555 sdk However i noticed that the other 20% produce stuttering audio and video in VLC. The VLC messages window shows a lot of 'PTS out of range' errors/warnings I debugged the library and found out that if i change the following line in MPEG2TransportStreamFramer.cpp change this line: #define TIME_ADJUSTMENT_FACTOR 0.8 to this line: #define TIME_ADJUSTMENT_FACTOR 0.5 Then all my mpeg-2 transport files stream nicely. Can anybody explain what exactly this factor does and if my 'fix' is good? Regards Erwin Beckers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070215/a45f7486/attachment.html From rmpg2001 at gmail.com Thu Feb 15 03:07:47 2007 From: rmpg2001 at gmail.com (Ramon Martin de Pozuelo) Date: Thu, 15 Feb 2007 12:07:47 +0100 Subject: [Live-devel] RTSP & VLC player Message-ID: <389189e20702150307r10cd233l1ebd0e6d089e23df@mail.gmail.com> Hi all, I create my own H264MediaSubsession derived from OnDemandMediaServerSubsession and it works fine (thanks Ross for your reply). I only have a problem now. When my video source finishes, the VLC breaks down and collapses my computer for a few time. Do you know what's the problem? Have I to send a RTSP message to the client when I don't have more source to send? Thanks in advance, Ramon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070215/cce66bb2/attachment.html From kurutepe at nue.tu-berlin.de Thu Feb 15 03:53:09 2007 From: kurutepe at nue.tu-berlin.de (Engin Kurutepe) Date: Thu, 15 Feb 2007 12:53:09 +0100 Subject: [Live-devel] possible RFC3984 related VLC bug? Message-ID: <45D449A5.4040409@nue.tu-berlin.de> Dear all, I have extended the on demand test server in the live555 distribution to handle H.264 streaming. I have first tested my server with VLC and then my own simple client written using live555 library and ffmpeg API. VLC complains a lot, often fails to decode macroblocks and resorts to error concealment regularly. However the video is decoded and displayed, albeit with some artifacts. First I thought this might be due to an undiscovered bug in my server code. However, my own client which passes the received NAL units from the H264VideoRTPSource to the ffmpeg avcodec_decode_video() displays the H.264 stream perfectly with no ffmpeg error messages and without any error concealment. I find this strange since VLC also uses live555 and ffmpeg to receive an H.264 stream. I am not familiar with VLC source and I tend to think this might be due to a small bug in the way VLC passes the received NAL unit to the ffmpeg decoder. I would like to ask to those in this mail group who are familiar with both live555 and VLC code if they are aware of such problems with VLC? Sorry for having to post this tangential question in this group. Regards, Engin. From kurutepe at nue.tu-berlin.de Thu Feb 15 04:14:55 2007 From: kurutepe at nue.tu-berlin.de (Engin Kurutepe) Date: Thu, 15 Feb 2007 13:14:55 +0100 Subject: [Live-devel] RTSP & VLC player In-Reply-To: <389189e20702150307r10cd233l1ebd0e6d089e23df@mail.gmail.com> References: <389189e20702150307r10cd233l1ebd0e6d089e23df@mail.gmail.com> Message-ID: <45D44EBF.2010009@nue.tu-berlin.de> RTSP BYE message should be sent when there are no more video packets. But live555 should be doing this automatically for you. How do you handle source file closure in your server code? Engin. Ramon Martin de Pozuelo wrote: > Hi all, > I create my own H264MediaSubsession derived from > OnDemandMediaServerSubsession and it works fine (thanks Ross for your > reply). I only have a problem now. When my video source finishes, the > VLC breaks down and collapses my computer for a few time. Do you know > what's the problem? Have I to send a RTSP message to the client when I > don't have more source to send? > > Thanks in advance, > > Ramon > > > ------------------------------------------------------------------------ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From vinodjoshi at tataelxsi.co.in Thu Feb 15 06:05:21 2007 From: vinodjoshi at tataelxsi.co.in (Vinod Madhav Joshi) Date: Thu, 15 Feb 2007 19:35:21 +0530 Subject: [Live-devel] (no subject) Message-ID: <000201c7510a$556650c0$4829320a@telxsi.com> Hi, I was trying to stream .mpg file with live555 media server. But received the following error on command prompt. MPEGProgramStreamParser::parsePESPacket() error: PES_packet_length (15556) excee ds max frame size asked for (10000) Also what command should be used to stop the server? Thank You. From morgan.torvolt at gmail.com Thu Feb 15 08:53:53 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Thu, 15 Feb 2007 20:53:53 +0400 Subject: [Live-devel] fix for stuttering video and audio when streaming an mpeg-2 transport stream In-Reply-To: References: Message-ID: <3cc3561f0702150853u2a4f4e1crfb38798450b30341@mail.gmail.com> Hi This is because your stream is variable bitrate. This has been discussed and a conclusion has been reached. You can read more in the mailing list archive. Here is one link: http://lists.live555.com/pipermail/live-devel/2007-February/006110.html Look for threads with "Urgent help needed!" as subject. -Morgan- On 15/02/07, Erwin Beckers wrote: > Hi, > > 80% of all my mpeg-2 transport files can be streamed very nice with the > live555 sdk > However i noticed that the other 20% produce stuttering audio and video in > VLC. > The VLC messages window shows a lot of 'PTS out of range' errors/warnings > > I debugged the library and found out that if i change the following line in > MPEG2TransportStreamFramer.cpp > > change this line: > #define TIME_ADJUSTMENT_FACTOR 0.8 > > to this line: > #define TIME_ADJUSTMENT_FACTOR 0.5 > > Then all my mpeg-2 transport files stream nicely. > Can anybody explain what exactly this factor does and if my 'fix' is good? > > Regards > > Erwin Beckers > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > From info at dnastudios.it Thu Feb 15 09:07:47 2007 From: info at dnastudios.it (DNA Studios s.r.l.) Date: Thu, 15 Feb 2007 18:07:47 +0100 Subject: [Live-devel] development request Message-ID: <45D49363.7030006@dnastudios.it> Hi, can someone solve a vlc media player bug for me (seeking from RTSP source does not work well)? I have started an auction for this: http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=623542 Sorry, but i use this mailing list because imo here there are peoples that know how to solve this problem. ------------------------------------------------------------- Nicola Mettimano DNA STUDIOS s.r.l. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070215/5d52bc59/attachment.html From e.beckers at gmail.com Thu Feb 15 11:43:36 2007 From: e.beckers at gmail.com (Erwin Beckers) Date: Thu, 15 Feb 2007 20:43:36 +0100 Subject: [Live-devel] fix for stuttering video and audio when streaming an mpeg-2 transport stream In-Reply-To: <3cc3561f0702150853u2a4f4e1crfb38798450b30341@mail.gmail.com> References: <3cc3561f0702150853u2a4f4e1crfb38798450b30341@mail.gmail.com> Message-ID: >This is because your stream is variable bitrate. This has been >discussed and a conclusion has been reached. You can read more in the mailing list archive. >Here is one link: >http://lists.live555.com/pipermail/live-devel/2007-February/006110.html >Look for threads with "Urgent help needed!" as subject. Thanks i see and understand the problem now. However the solutions (build 3 different framers) which is being suggested will not work for me. I need a fourth framer;-) and let me explain why. Although I do receive live tv, i dont want to feed it directly in the Live library. Instead i'm writing the live data to HDD and use the file on the HDD as a timeshifting buffer. This buffer on the HDD is circular and has a fixed length (lets say 2 GByte) I receive the live tv, write it to the file and when i reach the 2 GB, i start at file position 0 again. With a size of 2 GB, I now have a timeshifting buffer of +/- 1 hour of tv (depending on the bitrate offcourse) and the client can do timeshifting features like pausing and seeking backwards / forwards. To make this work I needed to write my own filereader which is derived from FramedFileSource All this works nicely except for the tv channels which have sudden changes in bitrate like you described One of those channels is HitRadio OE3 (yes its a tv channel, not a radio channel) on Astra 19.2 see http://en.kingofsat.net/tp.php?tp=117 Because of my setup where - i use the live tv data (so no indexing possible) - the data is not feeded directly into live555 (so not possible to skip the pcr detection as you proposed) I'm now forced to use the default framer which is not good enough. I guess we really need a (small) buffer on the server side to determine both current and next PCR and based on those two perform the calcuations Erwin > -Morgan- > > On 15/02/07, Erwin Beckers wrote: > > Hi, > > > > 80% of all my mpeg-2 transport files can be streamed very nice with the > > live555 sdk > > However i noticed that the other 20% produce stuttering audio and video > in > > VLC. > > The VLC messages window shows a lot of 'PTS out of range' > errors/warnings > > > > I debugged the library and found out that if i change the following line > in > > MPEG2TransportStreamFramer.cpp > > > > change this line: > > #define TIME_ADJUSTMENT_FACTOR 0.8 > > > > to this line: > > #define TIME_ADJUSTMENT_FACTOR 0.5 > > > > Then all my mpeg-2 transport files stream nicely. > > Can anybody explain what exactly this factor does and if my 'fix' is > good? > > > > Regards > > > > Erwin Beckers > > > > _______________________________________________ > > live-devel mailing list > > live-devel at lists.live555.com > > http://lists.live555.com/mailman/listinfo/live-devel > > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070215/a8d6f0cc/attachment-0001.html From finlayson at live555.com Thu Feb 15 16:45:19 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 16 Feb 2007 13:45:19 +1300 Subject: [Live-devel] (no subject) In-Reply-To: <000201c7510a$556650c0$4829320a@telxsi.com> References: <000201c7510a$556650c0$4829320a@telxsi.com> Message-ID: >Hi, > > I was trying to stream .mpg file with live555 media server. > > But received the following error on command prompt. > > > >MPEGProgramStreamParser::parsePESPacket() error: PES_packet_length (15556) >excee >ds max frame size asked for (10000) Please put your ".mpg" file on a web server, and send us the URL, so we can download it and test this for ourselves. > > > > > Also what command should be used to stop the server? -C :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Feb 15 16:55:48 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 16 Feb 2007 13:55:48 +1300 Subject: [Live-devel] development request In-Reply-To: <45D49363.7030006@dnastudios.it> References: <45D49363.7030006@dnastudios.it> Message-ID: >Hi, >can someone solve a vlc media player bug for me (seeking from RTSP >source does not work well)? >I have started an auction for this: >http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=623542 > >Sorry, but i use this mailing list because imo here there are >peoples that know how to solve this problem. Once again: I believe that people are currently working on improving VLC's handling of (RTSP client) seeking (and fast forward, and reverse play). (Right, DJ?) Please be patient... -- 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/20070215/1b48b928/attachment.html From susovan at tataelxsi.co.in Thu Feb 15 19:50:37 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Fri, 16 Feb 2007 09:20:37 +0530 Subject: [Live-devel] problem with MPEG-4 Message-ID: <001301c7517d$9ec1c790$0a2a320a@telxsi.com> Hi all, Thank you very much ross now it can stream the mp3 files,but not all. for .mpg files some time it streamed some time not. for MPEG it can not streamed. please consider the points.I have another problem ,I found the .exc file for live555medis server but for on demand test server only code is present.So in this case what are the step to ready and use that server for streaming. Thank you Susovan Ghosh From vinodjoshi at tataelxsi.co.in Thu Feb 15 21:42:29 2007 From: vinodjoshi at tataelxsi.co.in (Vinod Madhav Joshi) Date: Fri, 16 Feb 2007 11:12:29 +0530 Subject: [Live-devel] To Build Source Code on Windows XP Message-ID: <002601c7518d$3f72df80$4829320a@telxsi.com> Hi, Which compiler should be used to build the source code of LIve 555 Media Servre on Windows XP? Is it possible to do with VC++ environment? From susovan at tataelxsi.co.in Thu Feb 15 21:47:30 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Fri, 16 Feb 2007 11:17:30 +0530 Subject: [Live-devel] h.264 video codec Message-ID: <002f01c7518d$f2ea2be0$0a2a320a@telxsi.com> Hi all , i am working with live555media server and try to stream different files.It can stream only those .mpg files which have the mpgv vedio codec but not able to sream the .mpg files which have h.264 vedio codec.So give some more information on this matter. Thank you Susovan Ghosh From patil_subhash at yahoo.com Fri Feb 16 00:44:14 2007 From: patil_subhash at yahoo.com (Subhash Patil) Date: Fri, 16 Feb 2007 00:44:14 -0800 (PST) Subject: [Live-devel] Unsubscribe- Pls unsubscibe me.- High priority Message-ID: <20070216084414.66281.qmail@web54108.mail.yahoo.com> Dear Sir, Pls kindly unsubscribe me from the live-devel news group. My mailbox gets flooded with the messages from this news group. This is quite upsetting and strange. I request you to not to forward any mails from the live-devel newsgroup. With best regards, Subhash --- live-devel-bounces at ns.live555.com wrote: > > respected sir, > i am working with live555media server.i want to know > the no of client that the server can support simultaniously. > > > thank you > > > Susovan Ghosh > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html From vinodjoshi at tataelxsi.co.in Fri Feb 16 02:20:33 2007 From: vinodjoshi at tataelxsi.co.in (Vinod Madhav Joshi) Date: Fri, 16 Feb 2007 15:50:33 +0530 (IST) Subject: [Live-devel] Live 555 source code building on windows Message-ID: <20070216155033.CGD26841@mail.tataelxsi.co.in> Hi all, I am trying to build the source code on windows xp. But i am confused with "Tools" directory. I dont have any directory c:\Program Files\DevStudio\ But in Visual Studio I have got 3 Tools folders. C:\Program Files\Microsoft Visual Studio\Common\Tools C:\Program Files\Microsoft Visual Studio\Vfp98\Tools C:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT\Tools In win32conf I changed the path to all above directories but for cmd> genWindowsMakefiles I treceived the the following errors. D:\Live 555\live1>genWindowsMakefiles The system cannot find the path specified. Could Not Find D:\Live 555\live1\Makefile The system cannot find the file specified. Error occurred while processing: ..\win32config. The system cannot find the file specified. Error occurred while processing: Makefile.tail. The system cannot find the path specified. Could Not Find D:\Live 555\live1\Makefile The system cannot find the file specified. Error occurred while processing: ..\win32config. The system cannot find the file specified. Error occurred while processing: Makefile.tail. The system cannot find the path specified. Could Not Find D:\Live 555\live1\Makefile The system cannot find the file specified. Error occurred while processing: ..\win32config. The system cannot find the file specified. Error occurred while processing: Makefile.tail. The system cannot find the path specified. Could Not Find D:\Live 555\live1\Makefile The system cannot find the file specified. Error occurred while processing: ..\win32config. The system cannot find the file specified. Error occurred while processing: Makefile.tail. The system cannot find the path specified. Could Not Find D:\Live 555\live1\Makefile The system cannot find the file specified. Error occurred while processing: ..\win32config. The system cannot find the file specified. Error occurred while processing: Makefile.tail. The system cannot find the path specified. Could Not Find D:\Live 555\live1\Makefile The system cannot find the file specified. Error occurred while processing: ..\win32config. The system cannot find the file specified. Error occurred while processing: Makefile.tail. What has happened please tell. Thank You. From kurutepe at nue.tu-berlin.de Fri Feb 16 02:39:45 2007 From: kurutepe at nue.tu-berlin.de (Engin Kurutepe) Date: Fri, 16 Feb 2007 11:39:45 +0100 Subject: [Live-devel] presentation time jumps Message-ID: <45D589F1.1040101@nue.tu-berlin.de> Dear all, I am streaming H.264 video from my server to my own client-player. On the server side, My H264VideoStreamFramer sets the presentation time to gettimeofday() for the first frame and then increments by fDurationInMicroseconds for the other frames. However, the presentation time received by the client is not monotonically increasing. For my test video of 194 frames, it first starts with some value about 7500secs and jumps to about 2500 around 80-90th frames. I think this might be caused by RTCP synchronizations. Is that normal? If it is, what would be the proper way to handle this behavior in my client? Thanks, Engin. From morgan.torvolt at gmail.com Fri Feb 16 03:12:37 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Fri, 16 Feb 2007 15:12:37 +0400 Subject: [Live-devel] fix for stuttering video and audio when streaming an mpeg-2 transport stream In-Reply-To: References: <3cc3561f0702150853u2a4f4e1crfb38798450b30341@mail.gmail.com> Message-ID: <3cc3561f0702160312l164828e6l98b1be29c63db687@mail.gmail.com> > Thanks i see and understand the problem now. > However the solutions (build 3 different framers) which is being suggested > will not work for me. > I need a fourth framer;-) and let me explain why. > Although I do receive live tv, i dont want to feed it directly in the Live > library. > Instead i'm writing the live data to HDD and use the file on the HDD as a > timeshifting buffer. > This buffer on the HDD is circular and has a fixed length (lets say 2 GByte) > I receive the live tv, write it to the file and when i reach the 2 GB, i > start at file position 0 again. That makes it harder, yes. > Because of my setup where > - i use the live tv data (so no indexing possible) > - the data is not feeded directly into live555 (so not possible to skip the > pcr detection as you proposed) Indexing could still be possible, doing that in a parallell ring-buffer of some sort. It would even make it very easy to see if you are at the boundry of the buffer as there will be a large gap in the PCR without the discontinuity flag being set in the TS header, so disallowing rewinding or fast forwarding too far. Problem with that ring-buffer is that it cannot be fixed size like the other buffer, as you really do not know how many pcr packets and I-frames will be in the ts-buffer. There are of course ways around that. Maybe you could make the receiving application and the liveMedia streaming application talk trough a socket, and let the receiving application keep track of all the PCRs available? You will need to index the file in one way or another to get decent trick play functionality without demanding too much resources from your server. > I'm now forced to use the default framer which is not good enough. > I guess we really need a (small) buffer on the server side to determine both > current and next PCR > and based on those two perform the calcuations That is a possibility, but doing fast forward or rewinding would make you read trough the whole file looking for PCRs and I-frames. That is not what you want if you expect to have more than very small number of clients. Best regards -Morgan- From kumar.bhrigu at tcs.com Fri Feb 16 04:41:35 2007 From: kumar.bhrigu at tcs.com (Kumar Bhrigu) Date: Fri, 16 Feb 2007 18:11:35 +0530 Subject: [Live-devel] understanding session setup.. Message-ID: hi Ross, can u plz tell me how out of band signalling is done in testAMRStreamer ..whenever we capture the data on ethereal we get the payload type unknown(96).we tried to look into the rtsp and PassiveServerMediaSubsession.and got SDPlines couldnt track the flow. Can u please tell us more about that. regards Kumar Bhrigu Tata Consultancy Services Mailto: kumar.bhrigu at tcs.com Website: http://www.tcs.com =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you From scheifele2001 at yahoo.com Fri Feb 16 06:28:53 2007 From: scheifele2001 at yahoo.com (Randy Schefiele) Date: Fri, 16 Feb 2007 06:28:53 -0800 (PST) Subject: [Live-devel] Unsubscribe- Pls unsubscibe me.- High priority In-Reply-To: <20070216084414.66281.qmail@web54108.mail.yahoo.com> Message-ID: <537991.80146.qm@web38204.mail.mud.yahoo.com> Hi Subhash, You can unsubscribe yourself from this mailing list at any time the same way you signed up for it. Visit the following URL to unsubscribe: http://lists.live555.com/mailman/listinfo/live-devel/ Randy Subhash Patil wrote: Dear Sir, Pls kindly unsubscribe me from the live-devel news group. My mailbox gets flooded with the messages from this news group. This is quite upsetting and strange. I request you to not to forward any mails from the live-devel newsgroup. With best regards, Subhash --- live-devel-bounces at ns.live555.com wrote: > > respected sir, > i am working with live555media server.i want to know > the no of client that the server can support simultaniously. > > > thank you > > > Susovan Ghosh > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel --------------------------------- TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070216/40f487bc/attachment-0001.html From finlayson at live555.com Fri Feb 16 15:23:24 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 17 Feb 2007 12:23:24 +1300 Subject: [Live-devel] h.264 video codec In-Reply-To: <002f01c7518d$f2ea2be0$0a2a320a@telxsi.com> References: <002f01c7518d$f2ea2be0$0a2a320a@telxsi.com> Message-ID: > Hi all , > i am working with live555media server and try to stream different >files.It can stream only those .mpg files which have the mpgv vedio codec >but not able to sream the .mpg files which have h.264 vedio codec.So give >some more information on this matter. First, I have never heard of ".mpg files that have the H.264 video codec". ".mpg" files are usually always MPEG-1 or 2 Program Stream or Elementary Stream files. But in any case, streaming H.264 video from files is currently not supported in the "LIVE555 Streaming Media" code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Feb 16 15:26:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 17 Feb 2007 12:26:43 +1300 Subject: [Live-devel] presentation time jumps In-Reply-To: <45D589F1.1040101@nue.tu-berlin.de> References: <45D589F1.1040101@nue.tu-berlin.de> Message-ID: >Dear all, > >I am streaming H.264 video from my server to my own client-player. > >On the server side, My H264VideoStreamFramer sets the presentation time >to gettimeofday() for the first frame and then increments by >fDurationInMicroseconds for the other frames. > >However, the presentation time received by the client is not >monotonically increasing. For my test video of 194 frames, it first >starts with some value about 7500secs and jumps to about 2500 around >80-90th frames. I think this might be caused by RTCP synchronizations. >Is that normal? Yes. > If it is, what would be the proper way to handle this >behavior in my client? Use "RTPSource:: hasBeenSynchronizedUsingRTCP()" to test whether an incoming frame's presentation time has been computed using RTCP synchronization. (Those are the only presentation times that can be considered accurate.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Feb 16 15:28:17 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 17 Feb 2007 12:28:17 +1300 Subject: [Live-devel] problem with MPEG-4 In-Reply-To: <001301c7517d$9ec1c790$0a2a320a@telxsi.com> References: <001301c7517d$9ec1c790$0a2a320a@telxsi.com> Message-ID: > please consider the points.I have another problem ,I found the >.exc file for live555medis server but for on demand test server only code is >present.So in this case > what are the step to ready and use that server for streaming. Read the documentation! http://www.live555.com/liveMedia/ -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mrnikhilagrawal at gmail.com Sat Feb 17 09:15:59 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Sat, 17 Feb 2007 22:45:59 +0530 Subject: [Live-devel] Regarding MP3 Streaming In-Reply-To: <733cde3e0702152136t5542ae59l72ebde161e3103a4@mail.gmail.com> References: <733cde3e0702152136t5542ae59l72ebde161e3103a4@mail.gmail.com> Message-ID: <733cde3e0702170915i53cf1a56i8c76e4ff279ee92e@mail.gmail.com> Hi All, I was working on MP3 streaming code and what I understood is first an MP3 frame is converted to ADU and then again this ADU is converted to MP3 frame. Although I am still trying to understand the complete flow but can you tell me why we are doing this conversion from A -> B -> A . Is that just because to support trick mode or something else. Thanks and Regards, Nikhil Agrawal PS. If you have some links that can help me understand more this flow please provide it to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070217/949a9824/attachment.html From finlayson at live555.com Sat Feb 17 16:12:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 18 Feb 2007 13:12:23 +1300 Subject: [Live-devel] Regarding MP3 Streaming In-Reply-To: <733cde3e0702170915i53cf1a56i8c76e4ff279ee92e@mail.gmail.com> References: <733cde3e0702152136t5542ae59l72ebde161e3103a4@mail.gmail.com> <733cde3e0702170915i53cf1a56i8c76e4ff279ee92e@mail.gmail.com> Message-ID: >I was working on MP3 streaming code and what I understood is first >an MP3 frame is converted to ADU and then again this ADU is >converted to MP3 frame. Although I am still trying to understand the >complete flow but can you tell me why we are doing this conversion >from A -> B -> A . Is that just because to support trick mode or >something else. (I presume you're referring to the "MP3AudioFileServerMediaSubsession" code.) Yes, the conversion MP3->ADU->MP3 is done in order to support 'trick mode' - specifically, fast forward. Because MP3 frames are not self contained, it is not possible to implement Nx speedup on a MP3 stream simply by extracting every Nth MP3 frame. Instead, we need to first convert to ADUs, apply the scaling on the ADUs, and then convert them back to MP3 frames. (For more information on MP3 ADUs, see and -- 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/20070217/303a6dc1/attachment.html From Shawn.Van.Every at nyu.edu Sun Feb 18 09:20:17 2007 From: Shawn.Van.Every at nyu.edu (Shawn Van Every) Date: Sun, 18 Feb 2007 12:20:17 -0500 Subject: [Live-devel] Live555 liveMedia Java Bindings Message-ID: Greetings All, Just a quick question regarding the fantastic liveMedia libraries: Does anyone know of any projects or people that have built Java bindings (JNI) for the libraries? Thanks, shawn From mrnikhilagrawal at gmail.com Sun Feb 18 01:06:03 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Sun, 18 Feb 2007 14:36:03 +0530 Subject: [Live-devel] Regarding MP3 Streaming In-Reply-To: References: <733cde3e0702152136t5542ae59l72ebde161e3103a4@mail.gmail.com> <733cde3e0702170915i53cf1a56i8c76e4ff279ee92e@mail.gmail.com> Message-ID: <733cde3e0702180106h648832b5qe9d3217ab02e4c56@mail.gmail.com> Hi Ross, Thanks Ross, I have still 2 Queries :- Q1. If I dont need Fast Forward, just seek n pause is sufficient then also do i need to convert MP3-> ADU -> MP3 Q2. This conversion is compulsory even if I just want to support Play. Or its just for trick mode and no need if only playing need to be supported. Thanks and Regards, Nikhil Agrawal On 2/18/07, Ross Finlayson wrote: > > I was working on MP3 streaming code and what I understood is first an MP3 > frame is converted to ADU and then again this ADU is converted to MP3 frame. > Although I am still trying to understand the complete flow but can you tell > me why we are doing this conversion from A -> B -> A . Is that just because > to support trick mode or something else. > > > > (I presume you're referring to the "MP3AudioFileServerMediaSubsession" > code.) > > > Yes, the conversion MP3->ADU->MP3 is done in order to support 'trick mode' > - specifically, fast forward. Because MP3 frames are not self contained, it > is not possible to implement Nx speedup on a MP3 stream simply by extracting > every Nth MP3 frame. Instead, we need to first convert to ADUs, apply the > scaling on the ADUs, and then convert them back to MP3 frames. > > > (For more information on MP3 ADUs, see > and > > -- > > > 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/20070218/3b90dfec/attachment.html From finlayson at live555.com Sun Feb 18 19:35:08 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 18 Feb 2007 19:35:08 -0800 Subject: [Live-devel] Regarding MP3 Streaming In-Reply-To: <733cde3e0702180106h648832b5qe9d3217ab02e4c56@mail.gmail.com> References: <733cde3e0702152136t5542ae59l72ebde161e3103a4@mail.gmail.com> <733cde3e0702170915i53cf1a56i8c76e4ff279ee92e@mail.gmail.com> <733cde3e0702180106h648832b5qe9d3217ab02e4c56@mail.gmail.com> Message-ID: >Thanks Ross, I have still 2 Queries :- >Q1. If I dont need Fast Forward, just seek n pause is >sufficient then also do i need to convert MP3-> ADU -> MP3 > >Q2. This conversion is compulsory even if I just want to support >Play. Or its just for trick mode and no need if only playing need to >be supported. Yes, this conversion is needed only for implementing 'fast forward'. However, you should have no need to modify the existing code. (If you do, you can expect absolutely no support, especially with a "@gmail.com" email address.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From susovan at tataelxsi.co.in Sun Feb 18 20:43:00 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Mon, 19 Feb 2007 10:13:00 +0530 Subject: [Live-devel] MPEG-2 transport stream Message-ID: <001f01c753e0$6f8d4f20$0a2a320a@telxsi.com> Hi all, i feel very good to work with Live555 server.i have a problem withMPEG2TransportStreamIndexer.exe.the exe file is used to create .tsx file for MPEG -2 transport stream. But i was using that withMPEG2TransportStreamIndexer.exe, it ctrated the .tsx file but it is of 0KB,and we could not use the trick play functionility for MPEG-2 tranaport stream.So I want to know what to do next. Thank you Susovan From finlayson at live555.com Sun Feb 18 20:55:02 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 18 Feb 2007 20:55:02 -0800 Subject: [Live-devel] MPEG-2 transport stream In-Reply-To: <001f01c753e0$6f8d4f20$0a2a320a@telxsi.com> References: <001f01c753e0$6f8d4f20$0a2a320a@telxsi.com> Message-ID: > i feel very good to work with Live555 server.i have a problem >withMPEG2TransportStreamIndexer.exe.the exe file is used to create .tsx file >for MPEG -2 transport stream. But i was using that >withMPEG2TransportStreamIndexer.exe, it ctrated the .tsx file but it is of >0KB,and we could not use the trick play functionility for MPEG-2 >tranaport stream.So I want to know what to do next. Are you sure that your Transport Stream file contains MPEG-2 (or MPEG-1) video, and not some other codec (like H.264)? Note that the Transport Stream file indexing mechanism currently works only on Transport Stream files that contain MPEG-1 or MPEG-2 video. If you are sure that your Transport Stream file contains MPEG-1 or MPEG-2 video, then please put it on a web server, and post the URL, so I can download it and investigate what might be going wrong. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mridu.kaura at tcs.com Sun Feb 18 22:36:30 2007 From: mridu.kaura at tcs.com (Mridu Kaura) Date: Mon, 19 Feb 2007 12:06:30 +0530 Subject: [Live-devel] Not able to send 50 RTP packets / sec to the mobile In-Reply-To: <001f01c753e0$6f8d4f20$0a2a320a@telxsi.com> Message-ID: >Ross Finlayson finlayson at live555.com >Your file "test.amr" gets streamed correctly by both >"testAMRAudioStreamer" and "live555MediaServer". In each case, >QuickTime Player is able to play the stream (from the "rtsp://" URL >OK). Hi All, In continuation to Rajat's queries related to streaming AMR Payloads, we( Me and Rajat) have observed the following and still unable to solve it: For your information, we are using testAmrAudioStreamer to stream test.amr payloads. The complete RTP Code is working in a separate thread. We are using the ethereal to capture the frames exchanged between the Phone and the RTP Server. We have observed that, In case the phone does not send any RTP packet, the rate of frames that we send from the RTP Server is as high as 2000 frames per seond. In case when the phone also starts sending the RTP Packets, we have debugged the code and observed that the first frame sent (after the phone also starts sending RTP Packets) takes almost 50 mili seconds to be sent out.. Due to this all the next queued up frames are also getting delayed. We have also observed in the ethereal logs that the frames are sent sequentially as they are built (i.e their Sequence numbers are correct and the consecutive frames show a difference of 160 in their time stamps. ). But the issue is that frames are sent at a very low rate of 2 or 3 frames per second. However, the phone is sending the frames at the correct rate of 50 frames / sec and we are required to send at the same rate in return. We have managed to control the rate of sending frames by incrementing the fPresenattionTime (in doGetNextframe in AMRAudioFileSource.cpp) with 2 secs duration. With this change we were able to modify the rate of sending the frames at 1 frame every two seconds Ross has already tested "Test.amr" and there was no issue found with its streaming.. In fact we are using the same testAMRAudioStreamer,cpp that Ross had used (i.e. without any modifications). Ross had suggested that this rate is achievable if Test.amr and testAMRAudioStreamer.cpp are correct. With the correct files we are unable to achieve this rate. Kindly guide us in case we are overlooking something and also please suggest as to how we can acheive the rate of sending 50 frames per second while streaming AMR audio. Regards Mridu Kaura =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070218/52d13956/attachment.html From mridu.kaura at tcs.com Sun Feb 18 22:41:50 2007 From: mridu.kaura at tcs.com (Mridu Kaura) Date: Mon, 19 Feb 2007 12:11:50 +0530 Subject: [Live-devel] Not able to send 50 RTP packets / sec to the mobile Message-ID: >Ross Finlayson finlayson at live555.com >Your file "test.amr" gets streamed correctly by both >"testAMRAudioStreamer" and "live555MediaServer". In each case, >QuickTime Player is able to play the stream (from the "rtsp://" URL >OK). Hi All, In continuation to Rajat's queries related to streaming AMR Payloads, we( Me and Rajat) have observed the following and still unable to solve it: For your information, we are using testAmrAudioStreamer to stream test.amr payloads. The complete RTP Code is working in a separate thread. We are using the ethereal to capture the frames exchanged between the Phone and the RTP Server. We have observed that, In case the phone does not send any RTP packet, the rate of frames that we send from the RTP Server is as high as 2000 frames per seond. In case when the phone also starts sending the RTP Packets, we have debugged the code and observed that the first frame sent (after the phone also starts sending RTP Packets) takes almost 50 mili seconds to be sent out.. Due to this all the next queued up frames are also getting delayed. We have also observed in the ethereal logs that the frames are sent sequentially as they are built (i.e their Sequence numbers are correct and the consecutive frames show a difference of 160 in their time stamps. ). But the issue is that frames are sent at a very low rate of 2 or 3 frames per second. However, the phone is sending the frames at the correct rate of 50 frames / sec and we are required to send at the same rate in return. We have managed to control the rate of sending frames by incrementing the fPresenattionTime (in doGetNextframe in AMRAudioFileSource.cpp) with 2 secs duration. With this change we were able to modify the rate of sending the frames at 1 frame every two seconds Ross has already tested "Test.amr" and there was no issue found with its streaming.. In fact we are using the same testAMRAudioStreamer,cpp that Ross had used (i.e. without any modifications). Ross had suggested that this rate is achievable if Test.amr and testAMRAudioStreamer.cpp are correct. With the correct files we are unable to achieve this rate. Kindly guide us in case we are overlooking something and also please suggest as to how we can acheive the rate of sending 50 frames per second while streaming AMR audio. Regards Mridu Kaura ForwardSourceID:NT00006DDE =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070218/3d5154e1/attachment.html From stabrawa at stanford.edu Sun Feb 18 23:25:07 2007 From: stabrawa at stanford.edu (Tim Stabrawa) Date: Mon, 19 Feb 2007 01:25:07 -0600 Subject: [Live-devel] building under visual studio 2005 Message-ID: <45D950D3.2050908@stanford.edu> I'm trying to build the Live555 libraries / test programs under Visual Studio 2005, but am having trouble loading the generated .mak files. I think my problem is exactly the same as described in this thread: http://lists.live555.com/pipermail/live-devel/2006-November/005444.html Unfortunately, I haven't been able to find a public response with a solution. Could someone please point me in the right direction? Thanks, - Tim From asmundg at snap.tv Sun Feb 18 23:46:11 2007 From: asmundg at snap.tv (=?utf-8?q?=C3=85smund_Grammeltvedt?=) Date: Mon, 19 Feb 2007 08:46:11 +0100 Subject: [Live-devel] Unresolved Groupsock::lookupByname In-Reply-To: <200702151752.33594.asmundg@snap.tv> References: <200702151752.33594.asmundg@snap.tv> Message-ID: <200702190846.17909.asmundg@snap.tv> Seems like the previous mail got eaten by the Internet, so here's a new attempt. On Thursday 15 February 2007 17:52, ?smund Grammeltvedt wrote: > Hi. > > It seems like groupsock/include/Groupsock.hh contains a declaration for the > above mentioned function, with no corresponing implementation (see attached > patch). May I suggest removing the declaration if it serves no purpose? > It's messing up my non-lazy symbol resolving. -- ?smund Grammeltvedt Snap TV -------------- next part -------------- A non-text attachment was scrubbed... Name: live_groupsock_sym.patch Type: text/x-diff Size: 569 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070218/453e171c/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070218/453e171c/attachment-0001.bin From stabrawa at stanford.edu Sun Feb 18 23:49:20 2007 From: stabrawa at stanford.edu (Tim Stabrawa) Date: Mon, 19 Feb 2007 01:49:20 -0600 Subject: [Live-devel] Live 555 source code building on windows Message-ID: <45D95680.7050706@stanford.edu> Vinod, I saw similar file-not-found messages when I ran genWindowsMakefiles for the first time. I think what was happening in my case was the script was essentially trying to run a make clean of the windows makefiles before generating. If that's the case, you should see them go away if you run genWindowsMakefiles a second time. If all else fails, I'd suggest getting rid of the spaces in your path to the live source code. My experiences with most scripts is they tend not to like spaces, etc in directory/file names. As for which tools directory to use, I had luck generating with "TOOLS32=D:\Visual Studio 8\Common7\Tools" ... but I suspect, upon reviewing the .mak files that I generated, that I probably should have given it "TOOLS32=D:\Visual Studio 8\VC" instead. I hope some of this ends up being useful ... - Tim From mrnikhilagrawal at gmail.com Sun Feb 18 22:10:38 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Mon, 19 Feb 2007 11:40:38 +0530 Subject: [Live-devel] Regarding MP3 RTP stream in Quicktime Message-ID: <733cde3e0702182210u5f25d6b3g9d05ff81d7c16611@mail.gmail.com> Hi, I refered to http://www.live555.com/rtp-mp3/ link and clicked on 24 kbps version link. QuickTime player starts playing the stream. I read that QucikTime Player is not able to play MP3 RTP stream. Can anyone please tell me where I am wrong. Thanks and Regards, Nikhil Agrawal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070218/b694882e/attachment.html From finlayson at live555.com Mon Feb 19 00:09:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Feb 2007 00:09:15 -0800 Subject: [Live-devel] Not able to send 50 RTP packets / sec to the mobile In-Reply-To: References: Message-ID: >Ross has already tested "Test.amr" and there was no issue found >with its streaming.. In fact we are using the same >testAMRAudioStreamer,cpp that Ross had used (i.e. without any >modifications). > >Ross had suggested that this rate is achievable if Test.amr and >testAMRAudioStreamer.cpp are correct. With the correct files we are >unable to achieve this rate. I don't understand this. For me, all three of our applications - "testAMRAudioStreamer", "testOnDemandRTSPServer" and "live555MediaServer" - stream your "test.amr" file correctly (such that they are correctly played by QuickTime Player). If this is not true for you, then I have no idea why this could be - sorry. -- 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/20070219/be9370c3/attachment-0001.html From finlayson at live555.com Mon Feb 19 00:10:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Feb 2007 00:10:57 -0800 Subject: [Live-devel] Regarding MP3 RTP stream in Quicktime In-Reply-To: <733cde3e0702182210u5f25d6b3g9d05ff81d7c16611@mail.gmail.com> References: <733cde3e0702182210u5f25d6b3g9d05ff81d7c16611@mail.gmail.com> Message-ID: >I refered to >http://www.live555.com/rtp-mp3/ link >and clicked on 24 kbps >version link. QuickTime player starts playing the stream. I read >that QucikTime Player is not able to play MP3 RTP stream. Can anyone >please tell me where I am wrong. In this case, you're playing a HTTP stream, not a RTSP/RTP stream. -- 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/20070219/c16e64af/attachment.html From finlayson at live555.com Mon Feb 19 00:18:58 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Feb 2007 00:18:58 -0800 Subject: [Live-devel] Unresolved Groupsock::lookupByname In-Reply-To: <200702190846.17909.asmundg@snap.tv> References: <200702151752.33594.asmundg@snap.tv> <200702190846.17909.asmundg@snap.tv> Message-ID: > > It seems like groupsock/include/Groupsock.hh contains a declaration for the >> above mentioned function, with no corresponing implementation (see attached >> patch). May I suggest removing the declaration if it serves no purpose? Yes, this declaration is archaic - it will get removed in the next release of the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From stas at mer.co.il Mon Feb 19 00:35:48 2007 From: stas at mer.co.il (Stas Desyatnlkov) Date: Mon, 19 Feb 2007 10:35:48 +0200 Subject: [Live-devel] building under visual studio 2005 Message-ID: <8F5A28107CB68247BB8E3D3EE626F54F020D6ECF@fs1.mertree.mer.co.il> Hi Tim, I tried that too. I finally gave up and compiled live using my own workspace. Create a static lib and add whatever files you need from live distro. Ross, I think its time you start including VS2k5 workspaces with the distro. People have trouble building livecast libraries with the make files provided. Regards, Stas -----Original Message----- From: Tim Stabrawa [mailto:stabrawa at stanford.edu] Sent: Monday, February 19, 2007 9:25 AM To: live-devel at ns.live555.com Subject: [Live-devel] building under visual studio 2005 I'm trying to build the Live555 libraries / test programs under Visual Studio 2005, but am having trouble loading the generated .mak files. I think my problem is exactly the same as described in this thread: http://lists.live555.com/pipermail/live-devel/2006-November/005444.html Unfortunately, I haven't been able to find a public response with a solution. Could someone please point me in the right direction? Thanks, - Tim _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From igor at mir2.org Mon Feb 19 03:45:47 2007 From: igor at mir2.org (Igor Bukanov) Date: Mon, 19 Feb 2007 12:45:47 +0100 Subject: [Live-devel] RTSPClient::describeURL authentication problems Message-ID: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> Hi! I think the current implementation of char* RTSPClient::describeURL(char const* url, Authenticator* authenticator, Boolean allowKasennaProtocol) has the following problems: 1. If authenticator is null and the url contains username:password@ prefix before the host, then code calls describeWithPassword and ignores allowKasennaProtocol parameter. 2. If authenticator is not null, then the code does not repeat sending the command. This is very inconvenient and forces various workarounds in the client to repeat the command after the checking one more time that the last failure was due to the access denied problem. The attaches patch fixes both this problems as with it I can play through unpatched vlc 0.8.6 rtsp source requiring authorization. Regards, Igor -------------- next part -------------- A non-text attachment was scrubbed... Name: compile Type: application/octet-stream Size: 373 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070219/b2e1a532/attachment.obj From igor at mir2.org Mon Feb 19 03:54:15 2007 From: igor at mir2.org (Igor Bukanov) Date: Mon, 19 Feb 2007 12:54:15 +0100 Subject: [Live-devel] RTSPClient::describeURL authentication problems In-Reply-To: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> References: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> Message-ID: <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> On 19/02/07, Igor Bukanov wrote: > Hi! > > I think the current implementation of > > char* RTSPClient::describeURL(char const* url, Authenticator* authenticator, > Boolean allowKasennaProtocol) > > has the following problems: > > 1. If authenticator is null and the url contains username:password@ > prefix before the host, then code calls describeWithPassword and > ignores allowKasennaProtocol parameter. > > 2. If authenticator is not null, then the code does not repeat > sending the command. This is very inconvenient and forces various > workarounds in the client to repeat the command after the checking one > more time that the last failure was due to the access denied problem. > > The attaches patch fixes both this problems as with it I can play > through unpatched vlc 0.8.6 rtsp source requiring authorization. > > Regards, Igor The previous mail got a wrong patch, here is one inline: Index: live/liveMedia/RTSPClient.cpp =================================================================== --- live.orig/liveMedia/RTSPClient.cpp 2007-02-13 13:39:08.000000000 +0100 +++ live/liveMedia/RTSPClient.cpp 2007-02-19 11:50:51.000000000 +0100 @@ -201,18 +201,19 @@ char* RTSPClient::describeURL(char const* url, Authenticator* authenticator, Boolean allowKasennaProtocol) { - char* cmd = NULL; + Authenticator authenticator2; fDescribeStatusCode = 0; - do { - // First, check whether "url" contains a username:password to be used: - char* username; char* password; - if (authenticator == NULL - && parseRTSPURLUsernamePassword(url, username, password)) { - char* result = describeWithPassword(url, username, password); - delete[] username; delete[] password; // they were dynamically allocated - return result; - } + // First, check whether "url" contains a username:password to be used: + char* username; char* password; + if (authenticator == NULL + && parseRTSPURLUsernamePassword(url, username, password)) { + authenticator2.setUsernameAndPassword(username, password); + authenticator = &authenticator2; + } + + Boolean repeatWhenDenied = True; + for (;;) { if (!openConnectionFromURL(url, authenticator)) break; // Send the DESCRIBE command: @@ -243,7 +244,7 @@ + strlen(acceptStr) + strlen(authenticatorStr) + fUserAgentHeaderStrSize; - cmd = new char[cmdSize]; + char* cmd = new char[cmdSize]; sprintf(cmd, cmdFmt, url, ++fCSeq, @@ -252,7 +253,10 @@ fUserAgentHeaderStr); delete[] authenticatorStr; - if (!sendRequest(cmd, "DESCRIBE")) break; + Boolean sent = sendRequest(cmd, "DESCRIBE"); + delete cmd; + if (!sent) + break; // Get the response from the server: unsigned bytesRead; unsigned responseCode; @@ -271,11 +275,23 @@ wantRedirection = True; redirectionURL = new char[fResponseBufferSize]; // ensures enough space } else if (responseCode != 200) { - checkForAuthenticationFailure(responseCode, nextLineStart, authenticator); + if (repeatWhenDenied) { + checkForAuthenticationFailure(responseCode, nextLineStart, + authenticator); + if (authenticator->realm() != NULL) { + repeatWhenDenied = False; + continue; + } + } envir().setResultMsg("cannot handle DESCRIBE response: ", firstLine); break; } + if (authenticator->realm() != NULL) { + // The authenticator worked, so use it in future requests: + fCurrentAuthenticator = *authenticator; + } + // Skip over subsequent header lines, until we see a blank line. // The remaining data is assumed to be the SDP descriptor that we want. // While skipping over the header lines, we also check for certain headers @@ -455,7 +471,6 @@ char* describeSDP = describeURL(url, authenticator, True); delete[] currentWord; - delete[] cmd; return describeSDP; } @@ -489,16 +504,13 @@ char* result = strDup(sdpBuf); delete[] sdpBuf; delete[] currentWord; - delete[] cmd; return result; } ////////// END Kasenna BS ////////// - delete[] cmd; return strDup(bodyStart); - } while (0); + } - delete[] cmd; if (fDescribeStatusCode == 0) fDescribeStatusCode = 2; return NULL; } @@ -508,26 +520,7 @@ char const* username, char const* password) { Authenticator authenticator; authenticator.setUsernameAndPassword(username, password); - char* describeResult = describeURL(url, &authenticator); - if (describeResult != NULL) { - // We are already authorized - return describeResult; - } - - // The "realm" field should have been filled in: - if (authenticator.realm() == NULL) { - // We haven't been given enough information to try again, so fail: - return NULL; - } - - // Try again: - describeResult = describeURL(url, &authenticator); - if (describeResult != NULL) { - // The authenticator worked, so use it in future requests: - fCurrentAuthenticator = authenticator; - } - - return describeResult; + return describeURL(url, &authenticator); } char* RTSPClient::sendOptionsCmd(char const* url, From rmpg2001 at gmail.com Mon Feb 19 04:05:48 2007 From: rmpg2001 at gmail.com (Ramon Martin de Pozuelo) Date: Mon, 19 Feb 2007 13:05:48 +0100 Subject: [Live-devel] SDP & RTSP with VLC Message-ID: <389189e20702190405v19aeb96fpebcaa64fa36807bd@mail.gmail.com> Hi all, create two applications that send H264. First I create one that send broadcast and then I create my own subclass H264Session and I do a video on demand application. Well, all of this works fine but I have some problems. I usually used a .sdp in VLC Player to open the stream that I send broadcast, but now I'm using directly RTSP to connect both (video on demand and broadcast) and it works, but VLC player shows many messages like: ffmpeg warning: Unknown NAL code: 26 (h264 at 00B914C0) I sed exactly the same using RTSP & SDP in VLC, but this messages only appear when I use RTSP to connect to my application. Do you know what's the problem? Is it a VLC problem? Thanks in advance, Ramon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070219/93a82cf2/attachment.html From nagyz at nefty.hu Mon Feb 19 05:16:12 2007 From: nagyz at nefty.hu (Zoltan NAGY) Date: Mon, 19 Feb 2007 14:16:12 +0100 Subject: [Live-devel] fps? Message-ID: <45D9A31C.1030508@nefty.hu> Hi, Is there a way to determine the fps of a given rtsp stream? According to the RFC, it could be calculated from the rtp timestamps, but I havent really found an exact way to do so.. does the library contain code to calculate it? or how can I do that? Thanks in advance, Zoltan NAGY From ashutosh.naik at gmail.com Mon Feb 19 07:04:28 2007 From: ashutosh.naik at gmail.com (Ashutosh Naik) Date: Mon, 19 Feb 2007 20:34:28 +0530 Subject: [Live-devel] VLC problems in streaming RTSP media Message-ID: <81083a450702190704o7a8bbf6u5b66e5b44834dafb@mail.gmail.com> Hi everyone, I am running the latest version of VLC, 0.6.8a for Windows. However, when I compare VLC and Quicktime performance, on RTSP over HTTP streams, I observe a lot of differences between Quicktime and VLC while moving the slidebar. The transition isnt smooth in almost all the cases. I wonder if this is a problem observed by the guys on this list. This can be consistently reproduced with both RTSP and RTSP over htp tunneling scenarios on my setup here. Thanks in advance for your comments Best, Ash From finlayson at live555.com Mon Feb 19 07:28:31 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Feb 2007 07:28:31 -0800 Subject: [Live-devel] VLC problems in streaming RTSP media In-Reply-To: <81083a450702190704o7a8bbf6u5b66e5b44834dafb@mail.gmail.com> References: <81083a450702190704o7a8bbf6u5b66e5b44834dafb@mail.gmail.com> Message-ID: >Hi everyone, > >I am running the latest version of VLC, 0.6.8a for Windows. However, >when I compare VLC and Quicktime performance, on RTSP over HTTP >streams, I observe a lot of differences between Quicktime and VLC >while moving the slidebar. The transition isnt smooth in almost all >the cases. > I wonder if this is a problem observed by the guys on this list. Yes, this is a known problem. 'Seeking' (moving the slidebar) in VLC does not always work properly on RTSP/RTP streams (regardless of whether or not it's over HTTP). The VLC developers are working on this (I hope). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Feb 19 07:41:22 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Feb 2007 07:41:22 -0800 Subject: [Live-devel] RTSPClient::describeURL authentication problems In-Reply-To: <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> References: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> Message-ID: > > 1. If authenticator is null and the url contains username:password@ >> prefix before the host, then code calls describeWithPassword and >> ignores allowKasennaProtocol parameter. Yes. This is a 'problem' (in that "describeWithPassword()" currently does not take a "allowKasennaProtocol" parameter, but probably should). Note, however, that the 'Kasenna' support is a non-standard hack that will be removed from the code at some time in the future. However, for now I will probably go ahead and add a "allowKasennaProtocol" parameter to "describeWithPassword()". > > 2. If authenticator is not null, then the code does not repeat > > sending the command. The original idea here was that if "authenticator" is not NULL, then it would contain a (username,password) pair that should supercede any "username:password@" string in the URL. However, the VLC code now passes a (non-NULL) "authenticator", even if the user does not enter a (username,password) in a dialog box. So that's why the code is no longer working for you. Therefore, to solve your problem, would it be sufficient simply to remove the authenticator == NULL && from the "if" statement: if (authenticator == NULL && parseRTSPURLUsernamePassword(url, username, password)) { so that it instead just says: if (parseRTSPURLUsernamePassword(url, username, password)) { ??? I.e., if the RTSP URL contains a "username:password@", then it would now supercede any (username,password) in the "authenticator". Let me know if this would work for you? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Feb 19 07:48:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Feb 2007 07:48:57 -0800 Subject: [Live-devel] fps? In-Reply-To: <45D9A31C.1030508@nefty.hu> References: <45D9A31C.1030508@nefty.hu> Message-ID: >Is there a way to determine the fps of a given rtsp stream? >According to the RFC, it could be calculated from the rtp timestamps, >but I havent really found an exact way to do so.. does the library >contain code >to calculate it? or how can I do that? I suggest looking at the MPlayer source code. It contains some code (in "libmpdemux/demux_rtp_codec.cpp") that does this (search for "guess"). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From armandopoulos at yahoo.fr Mon Feb 19 07:58:45 2007 From: armandopoulos at yahoo.fr (Armando Ko) Date: Mon, 19 Feb 2007 15:58:45 +0000 (GMT) Subject: [Live-devel] using Mplayer or vlc as multicast client Message-ID: <20070219155846.69656.qmail@web86906.mail.ukl.yahoo.com> Hello, i have develop an application for streaming jpeg over RTP Multicast with the live555 and it is running very well but the vlc or Mplayer or Quicktime or Winamp cannot show the jpeg pictures i don?t not why....... i try the JMF (java media framwork) of sun they can decode the stream very well. Any ideas. thanks 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/20070219/2cf7765a/attachment.html From igor at mir2.org Mon Feb 19 08:20:41 2007 From: igor at mir2.org (Igor Bukanov) Date: Mon, 19 Feb 2007 17:20:41 +0100 Subject: [Live-devel] RTSPClient::describeURL authentication problems In-Reply-To: References: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> Message-ID: <7dee4710702190820l6e12dc73x44cc266a081a5e5d@mail.gmail.com> > Therefore, to solve your problem, would it be sufficient simply to remove the > authenticator == NULL && > from the "if" statement: > if (authenticator == NULL > && parseRTSPURLUsernamePassword(url, username, password)) { > so that it instead just says: > if (parseRTSPURLUsernamePassword(url, username, password)) { > ??? > > I.e., if the RTSP URL contains a "username:password@", then it would > now supercede any (username,password) in the "authenticator". > > Let me know if this would work for you? This alone would not work as then username and password from URL would override one from the authenticator. Another problem (addressed in the sent patch) is wrong error message about failure to handle response when in fact the code perfectly handles non-authorized situation via resubmitting the request later. Plus there is the third issue: the library does not srip username:password@ prefix from the URL and sends them in clear text even with the digest authentication. Regards, Igor From igor at mir2.org Mon Feb 19 09:13:16 2007 From: igor at mir2.org (Igor Bukanov) Date: Mon, 19 Feb 2007 18:13:16 +0100 Subject: [Live-devel] RTSPClient::describeURL authentication problems In-Reply-To: References: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> Message-ID: <7dee4710702190913r3512bbebqe155d350c76c8826@mail.gmail.com> On 19/02/07, Ross Finlayson wrote: > > > 2. If authenticator is not null, then the code does not repeat > > > sending the command. > > The original idea here was that if "authenticator" is not NULL, then > it would contain a (username,password) pair that should supercede any > "username:password@" string in the URL. However, the VLC code now > passes a (non-NULL) "authenticator", even if the user does not enter > a (username,password) in a dialog box. So that's why the code is no > longer working for you. Here is more clarifications: the problem is that describeWithPassword resends the command on authentication failure while describeUrl does not. Since VLC does not have own repetition code it fails. Since writing such restart code is very inconvenient on the client as there is no simple way to check for that, the patch changes the code to repeat DESCRIBE command in describeUrl while avoiding incorrect error reporting. Regards, Igor From ashutosh.naik at gmail.com Mon Feb 19 09:34:34 2007 From: ashutosh.naik at gmail.com (Ashutosh Naik) Date: Mon, 19 Feb 2007 23:04:34 +0530 Subject: [Live-devel] VLC problems in streaming RTSP media In-Reply-To: References: <81083a450702190704o7a8bbf6u5b66e5b44834dafb@mail.gmail.com> Message-ID: <81083a450702190934n32482e59jf91bf8df6de2a50b@mail.gmail.com> Hi Ross, On 2/19/07, Ross Finlayson wrote: > >I am running the latest version of VLC, 0.6.8a for Windows. However, > >when I compare VLC and Quicktime performance, on RTSP over HTTP > >streams, I observe a lot of differences between Quicktime and VLC > >while moving the slidebar. The transition isnt smooth in almost all > >the cases. > Yes, this is a known problem. 'Seeking' (moving the slidebar) in VLC > does not always work properly on RTSP/RTP streams (regardless of > whether or not it's over HTTP). The VLC developers are working on > this (I hope). I would love to work on this, and resolve this in VLC. Have you got a chance to go through the VLC code? Where could I look for problems. Any leads are greatly appreciated. Thanks again Ash From finlayson at live555.com Mon Feb 19 11:23:53 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Feb 2007 11:23:53 -0800 Subject: [Live-devel] RTSPClient::describeURL authentication problems In-Reply-To: <7dee4710702190820l6e12dc73x44cc266a081a5e5d@mail.gmail.com> References: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> <7dee4710702190820l6e12dc73x44cc266a081a5e5d@mail.gmail.com> Message-ID: > > Therefore, to solve your problem, would it be sufficient simply >to remove the >> authenticator == NULL && >> from the "if" statement: >> if (authenticator == NULL >> && parseRTSPURLUsernamePassword(url, username, password)) { >> so that it instead just says: >> if (parseRTSPURLUsernamePassword(url, username, password)) { >> ??? >> >> I.e., if the RTSP URL contains a "username:password@", then it would >> now supercede any (username,password) in the "authenticator". >> >> Let me know if this would work for you? > >This alone would not work as then username and password from URL would >override one from the authenticator. Why would you not want this? > Another problem (addressed in the >sent patch) is wrong error message about failure to handle response >when in fact the code perfectly handles non-authorized situation via >resubmitting the request later. I don't understand what you mean by this. > >Plus there is the third issue: the library does not srip >username:password@ prefix from the URL and sends them in clear text >even with the digest authentication. This is not our problem - nothing in the RTSP specification mentions modifying the supplied RTSP URL in any way, so we don't do it. People should not really be putting a "username:password@" in URLs anyway. In any case, because VLC already has command-line option(s) for specifying the username and password, I wonder if perhaps the best solution would be to simply remove all support for handling "username:password@" in the "rtsp://" URL? Not all servers support this anyway, and - as you noted, it's a security hole because the username and password are passed over the net in the clear. Are there any servers out there than handle "username:password@", but which don't handle Digest Authentication instead? Do we have any good reason for continuing to support "username:password@" at all?? >Here is more clarifications: the problem is that describeWithPassword >resends the command on authentication failure while describeUrl does >not. That's not a 'problem' - that's just the way that the code works. The code can resubmit the command (after an authentication failure) only if the user gave it a (username,password) to try. This suggests that the real solution would be to change the VLC code to call "describeWithPassword()" rather than "describeURL()". Or, even better, call "describeWithPassword()" iff the user supplied a (username,password), otherwise call "describeURL()". Do you agree with this - i.e., that the best solution would be to change the way that VLC calls the LIVE555 libraries in this case?? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From igor at mir2.org Mon Feb 19 12:36:34 2007 From: igor at mir2.org (Igor Bukanov) Date: Mon, 19 Feb 2007 21:36:34 +0100 Subject: [Live-devel] RTSPClient::describeURL authentication problems In-Reply-To: References: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> <7dee4710702190820l6e12dc73x44cc266a081a5e5d@mail.gmail.com> Message-ID: <7dee4710702191236h450e759ayf4672809d4df6198@mail.gmail.com> On 19/02/07, Ross Finlayson wrote: > >Plus there is the third issue: the library does not srip > >username:password@ prefix from the URL and sends them in clear text > >even with the digest authentication. > > This is not our problem - nothing in the RTSP specification mentions > modifying the supplied RTSP URL in any way, so we don't do it. > People should not really be putting a "username:password@" in URLs > anyway. RTSP is very clear about the format of URL: http://tools.ietf.org/html/rfc2326#page-14 That does not allow any user:password@ prefix. Yet live555 supports it while not striping during DESCRIBE/OPTIONS. This violates RFC while making potential security hole. Thus live555 should be fixed to either strip the prefix or explicitly reject it. I am fine with either. > That's not a 'problem' - that's just the way that the code works. > The code can resubmit the command (after an authentication failure) > only if the user gave it a (username,password) to try. The problem (a minor one I must admit) is that this still would print useless error message about failed DESCRIBE when in fact there is no failure, just a requirement to resent DESCRIBE with an updated authentication information. > > This suggests that the real solution would be to change the VLC code > to call "describeWithPassword()" rather than "describeURL()". Or, > even better, call "describeWithPassword()" iff the user supplied a > (username,password), otherwise call "describeURL()". This requires changing both live555 and vlc since vls depends on the ability to pass kassena flag to describeUrl and there is no such option in describeWithPassword. > > Do you agree with this - i.e., that the best solution would be to > change the way that VLC calls the LIVE555 libraries in this case?? I agree that from a practical point of view changing only live555 or vlc ie better then chnaging both. If you think that changing vlc is simpler, then I will prepare a patch for vlc to continue to use describeUrl but repeat the failed call if the passed authenticator gained the the digest info. I also make sure that it strips the username and password from URL. Regards, Igor From finlayson at live555.com Mon Feb 19 14:48:32 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Feb 2007 14:48:32 -0800 Subject: [Live-devel] RTSPClient::describeURL authentication problems In-Reply-To: <7dee4710702191236h450e759ayf4672809d4df6198@mail.gmail.com> References: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> <7dee4710702190820l6e12dc73x44cc266a081a5e5d@mail.gmail.com> <7dee4710702191236h450e759ayf4672809d4df6198@mail.gmail.com> Message-ID: > > This suggests that the real solution would be to change the VLC code >> to call "describeWithPassword()" rather than "describeURL()". Or, >> even better, call "describeWithPassword()" iff the user supplied a >> (username,password), otherwise call "describeURL()". > >This requires changing both live555 and vlc since vls depends on the >ability to pass kassena flag to describeUrl and there is no such >option in describeWithPassword. Yes - I will shortly be updating the LIVE555 code to add a 'kasenna' flag to "describeWithPassword()", and then submit a patch to VLC to use "describeWithPassword()" instead of "describeURL()" (if there are already username,password strings), and to not pass its own 'authenticator' object. In the meantime, you can get authentication to work for your streams by *not* including the "username:password@" hack in the URL, but instead waiting for VLC's authentication dialog box to pop up, and then enter the username,password there. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From igor at mir2.org Mon Feb 19 19:17:45 2007 From: igor at mir2.org (Igor Bukanov) Date: Tue, 20 Feb 2007 04:17:45 +0100 Subject: [Live-devel] RTSPClient::describeURL authentication problems In-Reply-To: References: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> <7dee4710702190820l6e12dc73x44cc266a081a5e5d@mail.gmail.com> <7dee4710702191236h450e759ayf4672809d4df6198@mail.gmail.com> Message-ID: <7dee4710702191917l4b21b550pf1f751a40e27f870@mail.gmail.com> On 19/02/07, Ross Finlayson wrote: > In the meantime, you can get authentication to work for your streams > by *not* including the "username:password@" hack in the URL, but > instead waiting for VLC's authentication dialog box to pop up, and > then enter the username,password there. It does not work when one use vlc as a streaming proxy with no GUI. Regards, Igor From igor at mir2.org Tue Feb 20 02:03:27 2007 From: igor at mir2.org (Igor Bukanov) Date: Tue, 20 Feb 2007 11:03:27 +0100 Subject: [Live-devel] RTSPClient::describeURL authentication problems In-Reply-To: References: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> <7dee4710702190820l6e12dc73x44cc266a081a5e5d@mail.gmail.com> <7dee4710702191236h450e759ayf4672809d4df6198@mail.gmail.com> Message-ID: <7dee4710702200203l2f191c82pe912d179a9d0b980@mail.gmail.com> On 19/02/07, Ross Finlayson wrote: > Yes - I will shortly be updating the LIVE555 code to add a 'kasenna' > flag to "describeWithPassword()", and then submit a patch to VLC to > use "describeWithPassword()" instead of "describeURL()" (if there are > already username,password strings), and to not pass its own > 'authenticator' object. Today I figured out that describeWithPassword() would not work when VLC provides own authentication dialog box. In that case one wants to show the dialog only when the server replied to DECRIBE and supplied realm. Then one needs to repeat the describe generating proper authentication header based on realm and just entered username/password. But describeWithPassword() does not allow that. So vlc needs to use describeURL(). Regards, Igor From finlayson at live555.com Tue Feb 20 02:22:34 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Feb 2007 02:22:34 -0800 Subject: [Live-devel] RTSPClient::describeURL authentication problems In-Reply-To: <7dee4710702200203l2f191c82pe912d179a9d0b980@mail.gmail.com> References: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> <7dee4710702190820l6e12dc73x44cc266a081a5e5d@mail.gmail.com> <7dee4710702191236h450e759ayf4672809d4df6198@mail.gmail.com> <7dee4710702200203l2f191c82pe912d179a9d0b980@mail.gmail.com> Message-ID: >On 19/02/07, Ross Finlayson wrote: >> Yes - I will shortly be updating the LIVE555 code to add a 'kasenna' >> flag to "describeWithPassword()", and then submit a patch to VLC to >> use "describeWithPassword()" instead of "describeURL()" (if there are >> already username,password strings), and to not pass its own >> 'authenticator' object. > >Today I figured out that describeWithPassword() would not work when >VLC provides own authentication dialog box. In that case one wants to >show the dialog only when the server replied to DECRIBE and supplied >realm. Then one needs to repeat the describe generating proper >authentication header based on realm and just entered >username/password. But describeWithPassword() does not allow that. Actually it does, by first sending a "DESCRIBE", that will probably fail (but with a realm included in the response), and then by sending another "DESCRIBE" with the updated authenticator (that includes the realm). I.e., when used with VLC, it the user doesn't supply a (username,password) in advance, then *three* RTSP "DESCRIBE"s will be sent: one initially (which will fail triggering VLC to pop up its dialog box to ask for the (username,password)), and then two more afterwards (to implement "describeWithPassword()"). This is slightly inefficient, but it should work. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From igor at mir2.org Tue Feb 20 02:34:37 2007 From: igor at mir2.org (Igor Bukanov) Date: Tue, 20 Feb 2007 11:34:37 +0100 Subject: [Live-devel] RTSPClient::describeURL authentication problems In-Reply-To: References: <7dee4710702190345m2143b91bt7ccedd9838658b0@mail.gmail.com> <7dee4710702190354u7e789dcg6135c953648900cc@mail.gmail.com> <7dee4710702190820l6e12dc73x44cc266a081a5e5d@mail.gmail.com> <7dee4710702191236h450e759ayf4672809d4df6198@mail.gmail.com> <7dee4710702200203l2f191c82pe912d179a9d0b980@mail.gmail.com> Message-ID: <7dee4710702200234j44ee8654m5f6790f648f1c145@mail.gmail.com> On 20/02/07, Ross Finlayson wrote: > Actually it does, by first sending a "DESCRIBE", that will probably > fail (but with a realm included in the response), and then by sending > another "DESCRIBE" with the updated authenticator (that includes the > realm). I sent a vlc-only patch to VLC maillist that implements the proper authentication (including striping username:password@) with the current live555 and only 2 DESCRIBE, http://www.via.ecp.fr/via/ml/vlc/2007-02/msg00089.html Regards, Igor From jean-paul.saman at planet.nl Tue Feb 20 03:14:39 2007 From: jean-paul.saman at planet.nl (Jean-Paul Saman) Date: Tue, 20 Feb 2007 12:14:39 +0100 Subject: [Live-devel] Regarding Client Player with Live555 In-Reply-To: References: <733cde3e0702070417m4e4ed66ft3880f1a12f94e819@mail.gmail.com> Message-ID: <45DAD81F.6090204@planet.nl> Ross Finlayson wrote: >> 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!! The VLC team is working on this particular problem. ETA not known. Gtz, Jean-Paul Saman. From luk666 at wp.pl Tue Feb 20 03:49:41 2007 From: luk666 at wp.pl (Paul) Date: Tue, 20 Feb 2007 12:49:41 +0100 Subject: [Live-devel] RTP, change of the incoming PORT Message-ID: <45dae05594a8f@wp.pl> Hi, I impelmented a module, in which RTPClient and RTPServer communicate usimg pipe. The RTPClient receive RTP stream write it to pipe and the RTPServer (other process) read pipe and stream it to VLC Player. I am using FreeBsd and C++ as prorgamming language. I would like to implement the following functionality: I stream two RTP streams (using testMPEG2TransportStream server) to the same IP address but to two different ports. My module will listen to one of them and then (lets say after 15 seconds) will switch to the other port and forward the second stream to VLC player. I think the best way to implement this is to change on the fly the incoming PORT of the RTP Client. I implemeted successfully the dynamic change of the outgoing port of RTPServer. It works fine using the following code: //CHANGING OF OUTGOING PORT sinkStream->startPlaying(*sourceStream, RTPServer::stop, this); watch='c'; while(1){ uEnv->taskScheduler().doEventLoop(&watch); if (watch=='c') { fprintf(stderr,"watch variable changed \n"); changeRTPPort(9500); watch=0; } } . and the fucntion which change Port. .void RTPServer::changeRTPPort(int newPort) { //set rtp port number rtpPortNumber=newPort; rtcpPortNumber=newPort+1; if (rtpPort) { delete(rtpPort); } rtpPort=new Port(rtpPortNumber); if (rtcpPort) { delete(rtcpPort); } struct in_addr temp_address; temp_address.s_addr = our_inet_addr("192.168.16.233"); //temp_address=address int temp_timeToLive=1 ; rtcpPort =new Port(rtcpPortNumber); rtpGroupsock->changeDestinationParameters(temp_address, *rtpPort, temp_timeToLive); rtcpGroupsock->changeDestinationParameters(temp_address, *rtcpPort, temp_timeToLive); } When I tried to implemented changing of incoming port of the RTPClinet in the similar way it does not work. Does anybody has any idea why it is not working? Thanks for any help or suggestions. Regards, Paul ---------------------------------------------------- P?yta Franka Sinatry "Songs From The Heart" to kolekcja najromantyczniejszych przeboj?w gwiazdy Hollywood! Pos?uchaj "My Funny Valentine" i "All The Way" i zakochaj si? http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fsinatra.html&sid=1027 From ruru605 at 163.com Tue Feb 20 08:04:41 2007 From: ruru605 at 163.com (ruru605) Date: Wed, 21 Feb 2007 00:04:41 +0800 Subject: [Live-devel] question of testOnDemand Message-ID: <200702210004401569526@163.com> Hi, everyone I have a question about testOnDemandStreamer. In the part of "A MPEG-1 or 2 audio+video program stream", I tried a file named test.mpg, however, when I use vlc as a client, it only show about 2 seconds and then TEARDOWN. Can you help me about this Thanks a lot ruru605 2007-02-20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070220/a2a22c63/attachment.html From finlayson at live555.com Tue Feb 20 08:36:54 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Feb 2007 08:36:54 -0800 Subject: [Live-devel] question of testOnDemand In-Reply-To: <200702210004401569526@163.com> References: <200702210004401569526@163.com> Message-ID: >Hi, everyone > I have a question about testOnDemandStreamer. > In the part of "A MPEG-1 or 2 audio+video program stream", I >tried a file named test.mpg, however, when I use vlc as a client, it >only show about 2 seconds and then TEARDOWN. > Can you help me about this Please read the FAQ!!! http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work -- 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/20070220/f149cbec/attachment.html From finlayson at live555.com Tue Feb 20 18:42:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Feb 2007 18:42:43 -0800 Subject: [Live-devel] RTP, change of the incoming PORT In-Reply-To: <45dae05594a8f@wp.pl> References: <45dae05594a8f@wp.pl> Message-ID: >When I tried to implemented changing of incoming port of the >RTPClinet in the similar way it does not work. Does anybody has any >idea why it is not working? It's because the "Groupsock::changeDestinationParameters()" function can only change the port (and/or address) that packets get sent *to*. There is currently no function available in the LIVE555 library that will let you change the port on which a 'groupsock' object *receives* data. To do this, you would need to first get the socket number, by calling gs->socketNum() and then calling "bind()" to bind to the new port. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vinodjoshi at tataelxsi.co.in Tue Feb 20 22:06:04 2007 From: vinodjoshi at tataelxsi.co.in (Vinod Madhav Joshi) Date: Wed, 21 Feb 2007 11:36:04 +0530 Subject: [Live-devel] Streaming .ts as .mpg Message-ID: <005901c7557e$5ecbe710$4829320a@telxsi.com> Hi , I want to know that whether we can change extension of ts files from .ts to .mpg I tried for that but some packet size exceeding error i have received. By making the changes in source is it possible to that? Also we are streaming the data to set top box, whether any changes need to be done for this? Thanks. From finlayson at live555.com Tue Feb 20 22:12:38 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Feb 2007 22:12:38 -0800 Subject: [Live-devel] Streaming .ts as .mpg In-Reply-To: <005901c7557e$5ecbe710$4829320a@telxsi.com> References: <005901c7557e$5ecbe710$4829320a@telxsi.com> Message-ID: > I want to know that whether we can change extension of ts files from .ts >to .mpg I don't recommend doing this. It will likely confuse humans as well as our software. The ".mpg" suffix is almost always used for MPEG *Program Stream* (or sometimes Elementary Stream) files, not Transport Stream files. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From susovan at tataelxsi.co.in Wed Feb 21 00:49:01 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Wed, 21 Feb 2007 14:19:01 +0530 Subject: [Live-devel] stream to STB Message-ID: <003101c75595$229c5fb0$0a2a320a@telxsi.com> Hi all, i can stream .mpg file through live555 to VLC player,but it can not stream to set top box.can any one help me what is problem with set top box. Thank You From sanjay417 at rediffmail.com Wed Feb 21 05:13:45 2007 From: sanjay417 at rediffmail.com (sanjay kumar gupta) Date: 21 Feb 2007 13:13:45 -0000 Subject: [Live-devel] how to get RTP packet data directly? Message-ID: <20070221131345.25242.qmail@webmail90.rediffmail.com> Hi, is it possible to receive the RTP data packet buffer directly using live555 media library? Actually I want RTP data packets directly so that I can decode this buffer and play it. Thanks in advance for help. Regards, Sanjay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070221/c2452cc3/attachment-0001.html From xcsmith at rockwellcollins.com Wed Feb 21 15:51:58 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Wed, 21 Feb 2007 17:51:58 -0600 Subject: [Live-devel] sanity check: Program Streams Message-ID: Is it correct to say that MPEG 2 Program Stream format has no RTP payload type, and that RTP-encapsulated MPEG 2 data is sent as either TS or ES data? It is my understanding that the Program Stream format is not designed for VOD network transmission and that audio/video industry practices do not use the PS format in that way. I can't find an RTP payload type for Program Stream (unless it is sent as 32 MP2V), which I think is because you're not supposed to send PS in RTP. I am trying to build an argument that our system should not do either of the following: A) RTP Source -> TS Framer -> TS demux -> PS Mux -> File Sink B) File Source -> PS demux -> TS from ES source -> TS framer -> RTP Sink Mainly, I think it is very illogical to build a network streaming device which reads and writes only PS files, when PS files are not as versatile and not designed for use in network environments. Certainly, implementing trick mode in this system will be very confusing for me, and I think I will not be able to use much of the LIVE555 trick mode if I have this strange system. My opinion is that a system which reads and writes only Transport Streams makes a lot more sense. I'd like to request a sanity check on my logic. Please advise if my opinions / facts are incorrect and how reasonable or unreasonable you think the system would be. I'd be greatful for whatever comments you can provide. Thanks xochitl From finlayson at live555.com Wed Feb 21 21:35:14 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 21 Feb 2007 21:35:14 -0800 Subject: [Live-devel] sanity check: Program Streams In-Reply-To: References: Message-ID: >Is it correct to say that MPEG 2 Program Stream format has no RTP payload >type, and that RTP-encapsulated MPEG 2 data is sent as either TS or ES >data? This is not strictly true, but in practice it's true enough. RFC 2250 *does* briefly mention the packetization/streaming of MPEG Program Stream data, but almost noone implements it. > It is my understanding that the Program Stream format is not >designed for VOD network transmission and that audio/video industry >practices do not use the PS format in that way. That's correct. > I can't find an RTP >payload type for Program Stream Actually, it is defined (using the MIME type "video/MP2P") in RFC 3555, but, as noted above, it's rarely used. >Mainly, I think it is very illogical to build a network streaming device >which reads and writes only PS files, when PS files are not as versatile >and not designed for use in network environments. Certainly, implementing >trick mode in this system will be very confusing for me, and I think I will >not be able to use much of the LIVE555 trick mode if I have this strange >system. My opinion is that a system which reads and writes only Transport >Streams makes a lot more sense. Yes, especially if you want to support fast forward and reverse play. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ruru605 at 163.com Thu Feb 22 00:33:14 2007 From: ruru605 at 163.com (ruru605) Date: Thu, 22 Feb 2007 16:33:14 +0800 Subject: [Live-devel] Questions of bitrate Message-ID: <200702221633137349333@163.com> Hi, everyone I have questions about RTP bitrate. 1.In OpenRTSP, we can calculate the QOS out which includes the bitrate. But I wonder can I reduce or increase the bitrate by controlling the server? 2.In every ServerMediaSubSession there is a estBitrate. What does it work for? I do not quite understand. I have an idea about increasing RTP QOS (on demand) like this and please tell me whether it is feasible. The clients' situations vary a lot not only in software but also in the condition of bandwidth. So I wonder if we can tell the server the situation of each client including cpu utilization,bandwidth... then server can change the RTP bitrate to adapt each client. I am a student and this is only an idea and maybe it is ridiculous but please tell me the answers. Thanks a lot. ruru605 2007-02-22 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070222/06e20b45/attachment.html From morgan.torvolt at gmail.com Thu Feb 22 01:35:50 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Thu, 22 Feb 2007 13:35:50 +0400 Subject: [Live-devel] stream to STB In-Reply-To: <003101c75595$229c5fb0$0a2a320a@telxsi.com> References: <003101c75595$229c5fb0$0a2a320a@telxsi.com> Message-ID: <3cc3561f0702220135v7bc53d36wa8ce0c6e218d37e6@mail.gmail.com> Probably your STB only accepts transport stream files. -Morgan- On 21/02/07, Susovan Ghosh wrote: > > Hi all, > i can stream .mpg file through live555 to VLC player,but it can not > stream to set top box.can any one help me what is problem with set top box. > > Thank You > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From susovan at tataelxsi.co.in Thu Feb 22 02:15:22 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Thu, 22 Feb 2007 15:45:22 +0530 Subject: [Live-devel] stream to STB In-Reply-To: <3cc3561f0702220135v7bc53d36wa8ce0c6e218d37e6@mail.gmail.com> Message-ID: <003301c7566a$5d029180$0a2a320a@telxsi.com> Hi Morgan, actualy we try with both transport stream and program stream.It can not received both.But we tried it through SMS server but it can.so I can not understand what is the problem. Thank you SUSOVAN GHOSH PH No-9986667320 Engineer (D&D) PRDE TATAELXSI LIMITED -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com]On Behalf Of Morgan Torvolt Sent: Thursday, February 22, 2007 3:06 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] stream to STB Probably your STB only accepts transport stream files. -Morgan- On 21/02/07, Susovan Ghosh wrote: > > Hi all, > i can stream .mpg file through live555 to VLC player,but it can not > stream to set top box.can any one help me what is problem with set top box. > > Thank You > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Thu Feb 22 02:45:27 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Feb 2007 02:45:27 -0800 Subject: [Live-devel] Questions of bitrate In-Reply-To: <200702221633137349333@163.com> References: <200702221633137349333@163.com> Message-ID: >Hi, everyone > I have questions about RTP bitrate. > 1.In OpenRTSP, we can calculate the QOS out which includes the >bitrate. But I wonder can I reduce or increase the bitrate by >controlling the server? No, not at present. RFC 4585 does define a new RTP profile - "RTP/AVPF" - that modifies the original "RTP/AVP" profile to add support for special RTCP 'feedback' packets (from the client back to the server) that the server might use to adapt its behavior. However, we do not currently implement this profile (for either clients or servers). > 2.In every ServerMediaSubSession there is a estBitrate. What >does it work for? It's used by the RTCP implementation to estimate how often to send RTCP packets. (According to the RTP/RTCP specification, RTCP packets are not supposed to take up more than 5% of the total bitrate.) -- 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/20070222/e64ad0ea/attachment.html From xcsmith at rockwellcollins.com Thu Feb 22 09:12:37 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Thu, 22 Feb 2007 11:12:37 -0600 Subject: [Live-devel] Questions of bitrate Message-ID: >> But I wonder can I reduce or increase the bitrate by controlling the server? I thought that the bitrate for a presentation was fixed by the recording? I have an encoder which can create a TS stream (MPEG2 data) at 5 Mbps or 4 Mbps for me to record, but the quality is different between the two streams. If am streaming a recorded presentation later and i tell the server to change the bitrate, but the recording was a 5 Mbps stream, wouldn't that have wierd results? xochitl From morgan.torvolt at gmail.com Thu Feb 22 10:25:56 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Thu, 22 Feb 2007 22:25:56 +0400 Subject: [Live-devel] Questions of bitrate In-Reply-To: References: Message-ID: <3cc3561f0702221025i7e4a20a4pd9a1352c53acbef4@mail.gmail.com> On 22/02/07, xcsmith at rockwellcollins.com wrote: > > >> But I wonder can I reduce or increase the bitrate by controlling the > server? > > I thought that the bitrate for a presentation was fixed by the recording? > I have an encoder which can create a TS stream (MPEG2 data) at 5 Mbps or 4 > Mbps for me to record, but the quality is different between the two > streams. If am streaming a recorded presentation later and i tell the > server to change the bitrate, but the recording was a 5 Mbps stream, > wouldn't that have wierd results? There are some situations where this is not the case. I do not know the exact technology behind it, but I think that material can be encoded for two (or more?) different resolutions, and at two (or more?) different bitrates. The reason I suspect this because I have heard about some small handheld devices that uses DVB-T, but does not decode the whole transport-stream to save power. This demands special encoding from the provider though, but is still standard compliant I belive, as i guess the ordinary receivers still would work. A small screen like that does not need all the information to show a decent picture anyway. I guess they use the same technology as progressive JPEG, where a picture gets better and better the more data you download. If there is a way to tag the TS packets with what quality they are ment for, one could actually just grab the data that one need, making it possible to lower quality and bandwidth and possibly resolution and framerate on demand. I have noe firm information to base this on unfortunately, but i did find this information with a very quick google search: http://forum.doom9.org/archive/index.php/t-98849.html -Morgan- From finlayson at live555.com Thu Feb 22 12:43:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Feb 2007 12:43:15 -0800 Subject: [Live-devel] Questions of bitrate In-Reply-To: <3cc3561f0702221025i7e4a20a4pd9a1352c53acbef4@mail.gmail.com> References: <3cc3561f0702221025i7e4a20a4pd9a1352c53acbef4@mail.gmail.com> Message-ID: >There are some situations where this is not the case. I do not know >the exact technology behind it, but I think that material can be >encoded for two (or more?) different resolutions, and at two (or >more?) different bitrates. The reason I suspect this because I have >heard about some small handheld devices that uses DVB-T, but does not >decode the whole transport-stream to save power. This demands special >encoding from the provider though, but is still standard compliant I >belive, as i guess the ordinary receivers still would work. Remember also that not all streaming uses MPEG Transport Streams, and not all streaming is from pre-encoded data :-) When streaming from a live source (e.g., a camera), it may make sense for a receiving client to send feedback to the server (camera+encoder+streamer), to request that it reencode/restream at a lower bitrate - especially when using codecs that are scalable. As I noted in my previous message, the RTP/AVPF profile (as defined in RFC 4585) supports such feedback (using RTCP). I don't know how widely used this is yet, but it would be nice to support (for both clients and servers) in the "LIVE555 Streaming Media" code at some point. (This of this as being another addition to the (already very long) wishlist...) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From skye at f4.ca Thu Feb 22 17:14:15 2007 From: skye at f4.ca (Skye Poier Nott) Date: Thu, 22 Feb 2007 17:14:15 -0800 Subject: [Live-devel] RTSP ANNOUNCE support? Message-ID: Hi, great library thank you!! I'm wondering if there is any support for the RTSP ANNOUNCE method in the liveMedia library? I would like to build a lightweight relay server for QuickTime Broadcaster, something much simpler than Darwin Streaming Server (or possible inclusion in VLC). If not, please let me know if this is a feature that would be appropriate for the library or falls out of the scope of the project, and where I might start subclassing etc. Actually this seems to answer that question: http://www.live555.com/liveMedia/faq.html#liveInput I have permission to submit code back to whatever open source projects that I use in my current work. I'm likely going to work on upgrading VLC's use of your libraries to support interleaved RTSP/RTP over TCP in their Video on Demand (VOD) feature, and I'd also like to implement RTSP/RTP tunneled over HTTP for NAT traversal for QuickTime Player. Below is output of the first request by QTBroadcaster. Thanks, Skye ANNOUNCE rtsp://localhost:8554/mystream.sdp RTSP/1.0 CSeq: 1 Content-Type: application/sdp User-Agent: QuickTime/7.1.3 (qtver=7.1.3;cpu=PPC;os=Mac 10.4.8) Content-Length: 404 v=0 o=- 12 2369617134 IN IP4 127.0.0.0 s=QuickTime c=IN IP4 127.0.0.1 t=0 0 a=x-qt-text-nam:TITLE a=x-qt-text-cpy:COPYRIGHT a=x-qt-text-aut:AUTHOR a=x-qt-text-inf:INFO a=range:npt=now- m=audio 6970 RTP/AVP 96 b=AS:8 a=rtpmap:96 mpeg4-generic/8000/1 a=fmtp:96 profile-level-id=15;mode=AAC- hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588 a=mpeg4-esid:101 a=control:trackid=1 From finlayson at live555.com Thu Feb 22 17:56:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Feb 2007 17:56:55 -0800 Subject: [Live-devel] RTSP ANNOUNCE support? In-Reply-To: References: Message-ID: >I'm wondering if there is any support for the RTSP ANNOUNCE method in >the liveMedia library? No, nor are there any plans to support it in the future. Almost nobody implements the RTSP "ANNOUNCE" command (in either clients or servers), and in fact it is no longer mentioned in the updated "RTSP 2.0" specification that is currently being standardized by the IETF. >I'm likely going to work on >upgrading VLC's use of your libraries to support interleaved RTSP/RTP >over TCP in their Video on Demand (VOD) feature, and I'd also like to >implement RTSP/RTP tunneled over HTTP for NAT traversal for QuickTime >Player. Do you realize that: 1/ Our RTSP client support already implements RTP-over-TCP, including HTTP tunneling. 2/ Our RTSP server support already supports RTP-over-TCP (but not yet including HTTP tunneling, although support for this will be added shortly) 3/ VLC currently uses the "LIVE555 Streaming Media" libraries only to implement its RTSP *client* support, not to implement its RTSP *server* support. -- 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/20070222/055d662f/attachment.html From finlayson at live555.com Thu Feb 22 18:13:05 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Feb 2007 18:13:05 -0800 Subject: [Live-devel] RTSP ANNOUNCE support? Message-ID: Oops, I spoke too soon. I just remembered that we *do* implement the RTSP "ANNOUNCE" command in our RTSP *client* implementation (but not our RTSP server implementation), and that (as you noted) QuickTime Broadcaster uses it. Note, though, that QuickTime Broadcaster's use of the RTSP "ANNOUNCE" command doesn't really follow the intent of the original RTSP specification. (Apple should have used "RECORD" instead, although that command is also being deprecated.) In any case, we don't implement "ANNOUNCE" (or "RECORD") in our RTSP *server* implementation. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From stabrawa at stanford.edu Fri Feb 23 00:15:36 2007 From: stabrawa at stanford.edu (Tim Stabrawa) Date: Fri, 23 Feb 2007 02:15:36 -0600 Subject: [Live-devel] Layered video with Live555 Message-ID: <45DEA2A8.7060805@stanford.edu> For an academic demonstration, I'm planning on extending Live555 to support RTP transport of scalable H.264 video and was hoping someone with a reasonable amount of experience with Live555 could help steer me in the direction of least pain ... Basically, I'll be using the reference codec for H.264 SVC (currently in development) to generate a file containing H.264 NAL units. The important difference between the output of this codec and a standard H.264 stream is the addition of two NAL unit types (20 & 21), which carry information about which layer of video is described in the preceding/current NAL unit. For now, assume I know how to parse this file and determine which NAL units belong to which layers. My intention is to send each layer out either multiplexed in the same RTP stream (the easy way) or in separate RTP streams (the hard / interesting way), according to this draft RFC: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-00.txt So, from everything I've read so far, there doesn't seem to be any Real Code I have to write in the H.264 RTP classes - aside from setting up the correct SDP parameters, etc. What I'm not sure about though is how to hook up a single file parser class (that I'd have to write) to one or more RTP Sink classes. Is it as simple as just instantiating multiple instances of the H264VideoRTPSink class and including them as separate sub-sessions in my ServerMediaSession? How would I indicate to the Live555 framework which sub-session a given NAL unit belongs to? Does it sound like I'm on the right path here, or am I missing something huge? I'd appreciate any direction I could get on this. Thanks, - Tim From finlayson at live555.com Fri Feb 23 05:04:51 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 23 Feb 2007 05:04:51 -0800 Subject: [Live-devel] Layered video with Live555 In-Reply-To: <45DEA2A8.7060805@stanford.edu> References: <45DEA2A8.7060805@stanford.edu> Message-ID: >For an academic demonstration, I'm planning on extending Live555 to >support RTP transport of scalable H.264 video and was hoping someone >with a reasonable amount of experience with Live555 could help steer me >in the direction of least pain ... > >Basically, I'll be using the reference codec for H.264 SVC (currently in >development) to generate a file containing H.264 NAL units. The >important difference between the output of this codec and a standard >H.264 stream is the addition of two NAL unit types (20 & 21), which >carry information about which layer of video is described in the >preceding/current NAL unit. For now, assume I know how to parse this >file and determine which NAL units belong to which layers. My intention >is to send each layer out either multiplexed in the same RTP stream (the >easy way) or in separate RTP streams (the hard / interesting way), >according to this draft RFC: >http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-00.txt This is interesting. I suggest proceeding in three steps (with each step requiring additional work building on the previous steps): 1/ Stream regular (non-SVC) H.264 video from a file. You will be able to test this using VLC. 2/ Add additional SVC layers, multiplexed in the same RTP stream as the base layer. 2/ Use separate RTP streams for separate SVC layers. >So, from everything I've read so far, there doesn't seem to be any Real >Code I have to write in the H.264 RTP classes - aside from setting up >the correct SDP parameters, etc. That's basically true, I think. However, the implementation of these classes may need to be updated to handle interleaved mode (as defined in RFC 3984) - something that we don't yet implement, but which (upon a cursory look at the SVC Internet-Draft) appears to be necessary for carrying SVC. > What I'm not sure about though is how >to hook up a single file parser class (that I'd have to write) to one or >more RTP Sink classes. If you're streaming on a single RTP stream (steps 1/ or 2/), then it's fairly straightforward: You'll need to write your own subclass of "H264VideoStreamFramer"; that subclass will parse the input stream (from a "ByteStreamFileSource"). You'll then 'play' this to a "H264VideoRTPSink" object. For step 3/, however: > Is it as simple as just instantiating multiple >instances of the H264VideoRTPSink class and including them as separate >sub-sessions in my ServerMediaSession? Yes. > How would I indicate to the >Live555 framework which sub-session a given NAL unit belongs to? You would need to write a 'demultiplexor' class that splits the incoming NAL stream (coming out of your 'Framer') into several different sub-streams of NAL units - one for each outgoing "H264VideoRTPSink". (But note that you'll need this only for step 3/.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ruru605 at 163.com Fri Feb 23 05:40:58 2007 From: ruru605 at 163.com (ruru605) Date: Fri, 23 Feb 2007 21:40:58 +0800 Subject: [Live-devel] help of bitrate Message-ID: <200702232140565314846@163.com> Hi, everyone After reading one reply now I am confused with two concepts of bitrate : One is bitrate of a source fixed by recording. Such as a mp3 file whose bitrate is 128kbps. The other one is the RTP transmission bitrate which I am interested in. This bitrate can be obtained from the client by calculating QOS parameters. My question is what is the relation of these two bitrates? Are they the same? Please help me know the answer and thanks very much. Best Regards ruru605 2007-02-23 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070223/563ec35b/attachment.html From skye at F4.ca Fri Feb 23 11:09:21 2007 From: skye at F4.ca (Skye Poier Nott) Date: Fri, 23 Feb 2007 11:09:21 -0800 Subject: [Live-devel] RTSP ANNOUNCE support? In-Reply-To: References: Message-ID: Thanks for the fast response, I didn't realize VLC wasn't using your library for RTSP server. > 2/ Our RTSP server support already supports RTP-over-TCP (but not > yet including HTTP tunneling, although support for this will be > added shortly) Great, can I contribute to the HTTP tunneling server support effort in any way? Skye From gau.mehta at gmail.com Fri Feb 23 15:45:26 2007 From: gau.mehta at gmail.com (Gaurav Mehta) Date: Fri, 23 Feb 2007 18:45:26 -0500 Subject: [Live-devel] Load testing live555 Message-ID: <85311cdb0702231545y15bf11dbv7260848b3ba5570d@mail.gmail.com> Hi All, I was interested to know how I can simulate load testing with Live 555? Any suggestions regarding how this can be done or tools I can use for this purpose? Is there any way I can remotely manage live555 from a web page? Any help or some kind of direction would be highly appreciated. Thanks and regards, Gaurav -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070223/54def1b4/attachment.html From yunjnz at yahoo.com Sat Feb 24 21:20:58 2007 From: yunjnz at yahoo.com (Sean) Date: Sat, 24 Feb 2007 21:20:58 -0800 (PST) Subject: [Live-devel] About RTSP Server over broad band router Message-ID: <406894.7434.qm@web35804.mail.mud.yahoo.com> Greetings, I'm working on a RTSP Server over broad band router, The network environment is that there are two broad band routers connected to the Internet, and a Dynamic DNS Server on the Internet, The Live555 based RTSP Server resides on the behind of one broad band router, The Live555 based RTSP Client resides on the behind of another broad band router, the client will access the server via domain name translated by the dynamic-DNS Server, The problem is, the client will stop after about 1 minute's streaming because of about 10 times' TaskInterrupt but the total streaming duration of the streaming is about 3 minutes. Can anyone give me some clue for this problem? Appreciate for your help. Sean. ____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html From luis.figueiredo at tagus.ist.utl.pt Sun Feb 25 12:05:52 2007 From: luis.figueiredo at tagus.ist.utl.pt (Figueiredo) Date: Sun, 25 Feb 2007 20:05:52 +0000 Subject: [Live-devel] Problem with FF and RW in MPEG2 Message-ID: <200702252006.l1PK61Fm024118@ns.live555.com> I have a problem with FF and RW functionalities in my STB. Somebody can help me? I am to use serving software live555 and a Amino STB 125. Thanks From finlayson at live555.com Sun Feb 25 16:25:01 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 25 Feb 2007 16:25:01 -0800 Subject: [Live-devel] Problem with FF and RW in MPEG2 In-Reply-To: <200702252006.l1PK61Fm024118@ns.live555.com> References: <200702252006.l1PK61Fm024118@ns.live555.com> Message-ID: >I have a problem with FF and RW functionalities in my STB. Somebody >can help me? I am to use serving software live555 and a Amino STB >125. What specifically is your problem? 1/ Does your STB successfully play streams (from the "LIVE555 Media Server") in regular (i.e., 1x forward play - not FF or RW) mode? 2/ Have you created an index file for each of your Transport Stream files, as described in ? Are the index files all larger than 0 bytes in size? 3/ How are you requesting FF and RW from your Amino STB? Are you using the >> and << buttons on its remote control - or are you using some other method? -- 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/20070225/8065fe75/attachment.html From yunjnz at yahoo.com Sun Feb 25 17:47:29 2007 From: yunjnz at yahoo.com (Sean) Date: Sun, 25 Feb 2007 17:47:29 -0800 (PST) Subject: [Live-devel] About RTSP Server over broad band router In-Reply-To: <406894.7434.qm@web35804.mail.mud.yahoo.com> Message-ID: <166002.68182.qm@web35808.mail.mud.yahoo.com> --- Sean wrote: > Greetings, > > I'm working on a RTSP Server over broad band router, > The network environment is that there are two broad > band routers connected to the Internet, and a > Dynamic > DNS Server on the Internet, > The Live555 based RTSP Server resides on the behind > of > one broad band router, > The Live555 based RTSP Client resides on the behind > of > another broad band router, > the client will access the server via domain name > translated by the dynamic-DNS Server, > The problem is, > the client will stop after about 1 minute's > streaming > because of about 10 times' TaskInterrupt but the > total > streaming duration of the streaming is about 3 > minutes. Additionally, if the client and server in the same LAN without transfer over broad band router, this problem won't happen. > Can anyone give me some clue for this problem? > Appreciate for your help. > > Sean. > > > > ____________________________________________________________________________________ > Expecting? Get great news right away with email > Auto-Check. > Try the Yahoo! Mail Beta. > http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > ____________________________________________________________________________________ Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com From c.drost at student.utwente.nl Mon Feb 26 00:13:33 2007 From: c.drost at student.utwente.nl (c.drost at student.utwente.nl) Date: Mon, 26 Feb 2007 09:13:33 +0100 Subject: [Live-devel] Streaming LATM withouh live555 taskmanager as central point References: <85311cdb0702231545y15bf11dbv7260848b3ba5570d@mail.gmail.com> Message-ID: Hi all, I am trying to build a LATM streaming application towards a Darwin server. The connection with Darwin is set up easily with the given code and the sdp file is generated correctly. The problem is that my application has the audio encoder as a central point, which delivers frames to my own written 'deviceSource.cpp'. To fool the task handlers I handle the loop with a number so I does return control to my program instead of waiting for a new task. In this way I try to let the encoder control when a new frame is available and signal this to my own deviceSource. When I am monitoring my traffic using live555 in this fashion, no RTP packets with latm frames are sent. I have no idea why this is... I used some debugging rules to check if doGetNextFrame() is being called when a frame is available and it does, does anyone have a clue what is the problem here and why my frames are not sent to the sink-point for sending to the Darwin server? Regards, Chiel Drost From sripadnavali at yahoo.co.in Mon Feb 26 00:21:00 2007 From: sripadnavali at yahoo.co.in (sripad _n) Date: Mon, 26 Feb 2007 08:21:00 +0000 (GMT) Subject: [Live-devel] How to build a part live555 implementaton Message-ID: <20070226082101.33986.qmail@web7908.mail.in.yahoo.com> I wanted to build only RTSP Client - Server from the libraries and functions given. How can extract only server and client code and make it executable independantly from other fuctions. They are required to provide only that functionality that i needed. --------------------------------- Here?s a new way to find what you're looking for - Yahoo! Answers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070226/e37e1a56/attachment.html From clem.taylor at gmail.com Mon Feb 26 11:52:01 2007 From: clem.taylor at gmail.com (Clem Taylor) Date: Mon, 26 Feb 2007 14:52:01 -0500 Subject: [Live-devel] RTSP ANNOUNCE support? In-Reply-To: References: Message-ID: On 2/22/07, Ross Finlayson wrote: > 1/ Our RTSP client support already implements RTP-over-TCP, including HTTP > tunneling. > 2/ Our RTSP server support already supports RTP-over-TCP (but not yet > including HTTP tunneling, although support for this will be added shortly) Ross, I was wondering what the time frame for supporting HTTP tunneling on the server side? Is this something you are currently working on or something you may add in the future? Thanks, Clem Taylor From xcsmith at rockwellcollins.com Mon Feb 26 13:00:50 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Mon, 26 Feb 2007 15:00:50 -0600 Subject: [Live-devel] Help: cause of RTP packet loss Message-ID: So I suspect that occasionally, on your OS, writes to a file are blocking for a sufficient amount of time Re: Thanks! this points out something i knew but had forgotten about. I was trying to write to a NFS location. Once I changed to writing to the localfs this packet loss went away on my fedora 5 host computer. Anyway, you can test this hypothesis by running openRTSP -v rtsp://whatever > /dev/null Re: On my target powerpc I still see lost packets from RTCP when writing to /dev/null. I have just learned that my powerpc does not have DMA, but I am told the write speed "should be fast enough". I have tested that my target disk can be written fast enough by using it in the fedora 5 computer. I'll have to figure out what is wrong with the powerpc here, but I wanted to reply to this on the mail list just incase someone else makes the same mistake as I did so they won't spend time figuring out that they are writing to NFS. :) How can I find out / figure out recommended system requirements for the streaming I am trying to do? I want to send a 5 Mbps TS stream to my powerpc, how can I learn what I need as minimum for processor, ram, etc. on this and other embedded targets? I would like to be able to predict how many simultaneous streams my powerpc box could handle. (Hopefully, DMA can be enabled and that could boost this number?) Thanks again for all your help! Xochitl From mrnikhilagrawal at gmail.com Mon Feb 26 21:20:32 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Tue, 27 Feb 2007 10:50:32 +0530 Subject: [Live-devel] Regarding streaming BMP Message-ID: <733cde3e0702262120g2d5ccd89web5df8c9bf0f5a90@mail.gmail.com> Hi, I have some sequence of BMP images and want to stream it like a video using Live555. For this I found a C# code to convert BMP to MPG. For each request (getNextFrame()) I take a BMP file , convert it to MPG and provide it in fTo Buffer.I cannot make a MPG file from all BMPs before streaming and stream that MPG directly , I have constraint to do conversion on fly only. Since this BMP to MPG is a C# dll and also not optimized , this conversion takes some time (2-3 Sec for each frame) because of which Live555 is able to stream it properly , VLC shows 3-4 images properly , after that it sticks on 4th image and doesnot show further frames even those are already placed in buffer and sent to VLC. #1 Can anyone tell me how can i proceed to make live555 and vlc work even with this delay. #2 Is there another way to stream BMP images , as if like it is a contigeous video sequence. Thanks and Regards, Nikhil Agrawal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070226/c4be768c/attachment.html From zhouh31415 at 163.com Tue Feb 27 00:59:32 2007 From: zhouh31415 at 163.com (=?gbk?B?1ty66w==?=) Date: Tue, 27 Feb 2007 16:59:32 +0800 (CST) Subject: [Live-devel] how to add IGMP? Message-ID: <19851224.1503231172566772315.JavaMail.root@bj163app33.163.com> Hi, I can run multicast now, but I want to add IGMP, Does live lib support the protocol? Or do you have any suggestion? Thank you. zhouhong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070227/5dadbaec/attachment.html From finlayson at live555.com Tue Feb 27 01:11:34 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Feb 2007 01:11:34 -0800 Subject: [Live-devel] how to add IGMP? In-Reply-To: <19851224.1503231172566772315.JavaMail.root@bj163app33.163.com> References: <19851224.1503231172566772315.JavaMail.root@bj163app33.163.com> Message-ID: >Hi, > I can run multicast now, but I want to add IGMP, Does live lib >support the protocol? Or do you have any suggestion? IGMP is implemented by the operating system, not by user-level code (like the "LIVE555 Streaming Media" code). IGMP happens automatically when the code joins or leaves multicast groups. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ydq at nbicc.com Tue Feb 27 03:51:44 2007 From: ydq at nbicc.com (ydq) Date: Tue, 27 Feb 2007 19:51:44 +0800 Subject: [Live-devel] How to realize " SET_PARAMETER" command of RTSP client by using Livemedia? Message-ID: <20070227115941.D59DF24B30A@slave.mail113.cn4e.com> Hi , According to a document, the Darwin sever will send a sign in SET_PARAMETER command when the end of a stream is arriving . Then the client should response it and teardown. How I to realize this function by using Livemedia ? #ifdef SUPPORT_REAL_RTSP #include "../RealRTSP/include/RealRTSP.hh" #endif The code above is from Livemedia in MediaSession.cpp. However it is strange that I cannot find RealRTSP.hh file in Live folders. How and where to get this file ? Best regards ! Ydq -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070227/5e929758/attachment-0001.html From adutta at research.telcordia.com Tue Feb 27 03:58:16 2007 From: adutta at research.telcordia.com (Ashutosh Dutta) Date: Tue, 27 Feb 2007 06:58:16 -0500 Subject: [Live-devel] Transport header VLC client In-Reply-To: References: <19851224.1503231172566772315.JavaMail.root@bj163app33.163.com> Message-ID: <45E41CD8.3060608@research.telcordia.com> I was curious if anybody has experience using transport header in VLC client code to designate the address where the server should play it stream. This is the example from RTSP RFC 2326bis. > C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 > CSeq: 302 > Transport: RTP/AVP;multicast;mode="PLAY", > RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ > "192.0.2.5:3457";mode="PLAY" > > S->C: RTSP/2.0 200 OK > CSeq: 302 > Date: 23 Jan 1997 15:35:06 GMT > Session: 47112344 > Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ > "192.0.2.5:3457";src_addr="192.0.2.224:6256" > /"192.0.2.224:6257";mode="PLAY" Thanks Ashutosh From finlayson at live555.com Tue Feb 27 04:12:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Feb 2007 04:12:15 -0800 Subject: [Live-devel] How to realize " SET_PARAMETER" command of RTSP client by using Livemedia? In-Reply-To: <20070227115941.D59DF24B30A@slave.mail113.cn4e.com> References: <20070227115941.D59DF24B30A@slave.mail113.cn4e.com> Message-ID: >According to a document, the Darwin sever will send a sign in >SET_PARAMETER command when the end of a stream is arriving . >Then the client should response it and teardown. Are you sure about this? Please send us the URL of the document. (Servers usually use the RTCP "BYE" command - which we support - to inform the client of the end of the stream. I have not heard of "SET_PARAMETER" being used for this.) But anyway, if you *really* want to handle the "SET_PARAMETER" (or any other) RTSP command coming from the server, then you could modify the function "RTSPClient::incomingRequestHandler1()". (However, once you've modified the code, you can, in general, expect no support.) >#ifdef SUPPORT_REAL_RTSP >#include "../RealRTSP/include/RealRTSP.hh" >#endif > >The code above is from Livemedia in MediaSession.cpp. However it is >strange that I cannot find RealRTSP.hh file in Live folders. >How and where to get this file ? You can't; it is not included in the "LIVE555 Streaming Media" code (and is irrelevant to your question anyway). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From susovan at tataelxsi.co.in Tue Feb 27 04:29:50 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Tue, 27 Feb 2007 17:59:50 +0530 Subject: [Live-devel] Transport Stream Message-ID: <001b01c75a6a$fa6d9fb0$0a2a320a@telxsi.com> hi all, I was trying to convert .ts file to .txs using MPEG2TransportStreamIndexer.exe for implementing trick play operation for .ts file. But it creat .txs file of 0 kb.So what is the problem.can any one send me any .ts file and corrosponding .txs file. Thank you SUSOVAN GHOSH PH No-9986667320 Engineer (D&D) PRDE TATAELXSI LIMITED From finlayson at live555.com Tue Feb 27 04:30:44 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Feb 2007 04:30:44 -0800 Subject: [Live-devel] Transport header VLC client In-Reply-To: <45E41CD8.3060608@research.telcordia.com> References: <19851224.1503231172566772315.JavaMail.root@bj163app33.163.com> <45E41CD8.3060608@research.telcordia.com> Message-ID: >I was curious if anybody has experience using transport header in VLC >client code to designate the address where the server should play it >stream. This is the example from RTSP RFC 2326bis. > >> C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 >> CSeq: 302 >> Transport: RTP/AVP;multicast;mode="PLAY", >> RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ >> "192.0.2.5:3457";mode="PLAY" >> >> S->C: RTSP/2.0 200 OK >> CSeq: 302 >> Date: 23 Jan 1997 15:35:06 GMT >> Session: 47112344 >> Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ >> "192.0.2.5:3457";src_addr="192.0.2.224:6256" >> /"192.0.2.224:6257";mode="PLAY" Note that the "LIVE555 Streaming Media" code does not yet support (for either clients or servers) the RTSP 2.0 proposal (as defined by the "2326bis" Internet Draft). We currently support only the RTSP 1.0 standard (RFC 2326). In RTSP 1.0, the parameter that you're referring to is called "destination", not "dest_addr". In any case, our RTSP client implementation (and thus, VLC) does not support this. Neither does our RTSP server implementation (except in some normally #ifdef'd out code in "RTSPServer.cpp"). Note that allowing the client to specify the IP address that the server should send has major security implications - it would effectively make possible denial-of-service attacks on innocent third parties - and so probably no RTSP server anywhere supports this feature by default. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From shishir at birmiwal.net Tue Feb 27 04:46:58 2007 From: shishir at birmiwal.net (Shishir Birmiwal) Date: Tue, 27 Feb 2007 18:16:58 +0530 Subject: [Live-devel] Help: cause of RTP packet loss In-Reply-To: References: Message-ID: Xochitl, > Re: On my target powerpc I still see lost packets from RTCP when writing > to /dev/null. I have just learned that my powerpc does not have DMA, but I > am told the write speed "should be fast enough". I have tested that my > target disk can be written fast enough by using it in the fedora 5 > computer. > How can I find out / figure out recommended system requirements for the > streaming I am trying to do? I want to send a 5 Mbps TS stream to my > powerpc, how can I learn what I need as minimum for processor, ram, etc. on > this and other embedded targets? I would like to be able to predict how > many simultaneous streams my powerpc box could handle. (Hopefully, DMA can > be enabled and that could boost this number?) What file-system do you have on your PowerPC system? You could test your read (or write, if you have a spare disk to write random data to and corrupt the file-system) speeds using hdparm (for disk-drives). Alternately, you can do some elementary tests to read/write chunks of data (128/256/more MB) from/to your filesystem and measure the time taken for this action. Be careful while doing a read as you may see disk-caches speeding up your transfers. A simple test to measure the write speed: sync; time dd if=/dev/zero bs=1M count=256 of=/tmp/temp; time sync; rm /tmp/temp Add up the two time values to get an estimate of time to write 256 MB. Regards Shishir From jlfurlong at hotmail.com Tue Feb 27 10:42:56 2007 From: jlfurlong at hotmail.com (Jeff Furlong) Date: Tue, 27 Feb 2007 14:42:56 -0400 Subject: [Live-devel] Index file for H264 over mpeg2ts Message-ID: I've seen some recent posts regarding H.264 - specifically one regarding the creation of index files. I have placed an HD H.264 sample clip from a live encoder and was wondering if someone (Ross ?) could take a look to see what would be required to be able to support indexing? You can access the file here: http://www.geeknet.ca/~temp/tenten16-2.ts Regards, Jeff Furlong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070227/68ecd1e5/attachment.html From jlfurlong at hotmail.com Tue Feb 27 10:49:39 2007 From: jlfurlong at hotmail.com (Jeff Furlong) Date: Tue, 27 Feb 2007 14:49:39 -0400 Subject: [Live-devel] Java Support Message-ID: Has anyone ported the libraries and/or applications to Java? Is there any plans for upcoming release(s) to support Java? Thanks, Jeff Furlong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070227/335a1815/attachment.html From finlayson at live555.com Tue Feb 27 13:07:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Feb 2007 13:07:57 -0800 Subject: [Live-devel] Transport Stream In-Reply-To: <001b01c75a6a$fa6d9fb0$0a2a320a@telxsi.com> References: <001b01c75a6a$fa6d9fb0$0a2a320a@telxsi.com> Message-ID: > I was trying to convert .ts file to .txs using >MPEG2TransportStreamIndexer.exe for implementing trick play operation for >.ts file. But it creat .txs file of 0 kb.So what is the problem. I don't know - but please put your ".ts" file on a web server, and send us the URL, so we can download it and test it for ourselves. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Feb 27 13:18:00 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Feb 2007 13:18:00 -0800 Subject: [Live-devel] Index file for H264 over mpeg2ts In-Reply-To: References: Message-ID: >I've seen some recent posts regarding H.264 - specifically one >regarding the creation of index files. I have placed an HD H.264 >sample clip from a live encoder and was wondering if someone (Ross >?) could take a look to see what would be required to be able to >support indexing? > >You can access the file here: >http://www.geeknet.ca/~temp/tenten16-2.ts Thanks. (I'm downloading this now.) -- 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/20070227/9062d0ea/attachment.html From skye at F4.ca Tue Feb 27 15:53:17 2007 From: skye at F4.ca (Skye Poier Nott) Date: Tue, 27 Feb 2007 15:53:17 -0800 Subject: [Live-devel] Website borked Message-ID: <1BA2AA83-5793-40B1-B091-99761680E42F@F4.ca> Getting a 404 here: http://www.live555.com/liveMedia/ Just FYI Thanks, Skye From finlayson at live555.com Tue Feb 27 16:15:41 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Feb 2007 16:15:41 -0800 Subject: [Live-devel] Website borked In-Reply-To: <1BA2AA83-5793-40B1-B091-99761680E42F@F4.ca> References: <1BA2AA83-5793-40B1-B091-99761680E42F@F4.ca> Message-ID: >Getting a 404 here: http://www.live555.com/liveMedia/ It seems to be working fine. Try again. (Perhaps you're behind a misbehaving web cache/proxy??) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From skye at F4.ca Tue Feb 27 16:48:31 2007 From: skye at F4.ca (Skye Poier Nott) Date: Tue, 27 Feb 2007 16:48:31 -0800 Subject: [Live-devel] Website borked In-Reply-To: References: <1BA2AA83-5793-40B1-B091-99761680E42F@F4.ca> Message-ID: <8EA2400F-F321-4DE5-A663-51EAD29A8749@F4.ca> Huh weird. Did a shift-reload in Firefox and now it's fine. Nevermind!! On Feb 27, 2007, at 16:15, Ross Finlayson wrote: >> Getting a 404 here: http://www.live555.com/liveMedia/ > > It seems to be working fine. Try again. (Perhaps you're behind a > misbehaving web cache/proxy??) > > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From adutta at research.telcordia.com Tue Feb 27 21:42:16 2007 From: adutta at research.telcordia.com (Ashutosh Dutta) Date: Wed, 28 Feb 2007 00:42:16 -0500 Subject: [Live-devel] Transport header VLC client In-Reply-To: References: <19851224.1503231172566772315.JavaMail.root@bj163app33.163.com> <45E41CD8.3060608@research.telcordia.com> Message-ID: <45E51638.9030801@research.telcordia.com> Ross, thanks for your reply. I agreed with DOS attack part. However, in some cases (e.g., multihoming case), the client may like to receive the stream in a specific desired address. Thus having the ability to receive at a particular address (interface) is sometimes desirable. It is good to know that the RTSP server has some optional settings. I guess, one needs to update the RTSP client to get this feature. Thanks Ashutosh Ross Finlayson wrote: >> I was curious if anybody has experience using transport header in VLC >> client code to designate the address where the server should play it >> stream. This is the example from RTSP RFC 2326bis. >> >>> C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 >>> CSeq: 302 >>> Transport: RTP/AVP;multicast;mode="PLAY", >>> RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ >>> "192.0.2.5:3457";mode="PLAY" >>> >>> S->C: RTSP/2.0 200 OK >>> CSeq: 302 >>> Date: 23 Jan 1997 15:35:06 GMT >>> Session: 47112344 >>> Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ >>> "192.0.2.5:3457";src_addr="192.0.2.224:6256" >>> /"192.0.2.224:6257";mode="PLAY" > > Note that the "LIVE555 Streaming Media" code does not yet support > (for either clients or servers) the RTSP 2.0 proposal (as defined by > the "2326bis" Internet Draft). We currently support only the RTSP > 1.0 standard (RFC 2326). In RTSP 1.0, the parameter that you're > referring to is called "destination", not "dest_addr". > > In any case, our RTSP client implementation (and thus, VLC) does not > support this. Neither does our RTSP server implementation (except in > some normally #ifdef'd out code in "RTSPServer.cpp"). Note that > allowing the client to specify the IP address that the server should > send has major security implications - it would effectively make > possible denial-of-service attacks on innocent third parties - and so > probably no RTSP server anywhere supports this feature by default. From finlayson at live555.com Tue Feb 27 22:08:31 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Feb 2007 22:08:31 -0800 Subject: [Live-devel] Transport header VLC client In-Reply-To: <45E51638.9030801@research.telcordia.com> References: <19851224.1503231172566772315.JavaMail.root@bj163app33.163.com> <45E41CD8.3060608@research.telcordia.com> <45E51638.9030801@research.telcordia.com> Message-ID: >Ross, thanks for your reply. I agreed with DOS attack part. > >However, in some cases (e.g., multihoming case), the client may like to >receive the stream in a specific desired address. Thus having the >ability to receive at a particular address (interface) is sometimes >desirable. It is good to know that the RTSP server has some optional >settings. I guess, one needs to update the RTSP client to get this feature. Yes, but that's something that you would need to do with with your own copy of the code, because I won't be adding such functionality to the distributed source code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From susovan at tataelxsi.co.in Wed Feb 28 01:48:48 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Wed, 28 Feb 2007 15:18:48 +0530 Subject: [Live-devel] Transport stream Message-ID: <002801c75b1d$a541ca80$0a2a320a@telxsi.com> Hi Ross, you said me to send the FTN_Part1.ts file.I can not put it in a wed server so i put in a online storage .Here is the steps--- 1)Go to the link given http://www.mediamax.com/susovan/FileManager# 2)Usr Name->susovan 3)Password->mailtosusovan 4)Go to my account 5)Select the file FTN_Part1.ts from file manager >From there you can download and perform all tests.If you have any .ts and .txs file ,please upload it in that site. Tha nk you SUSOVAN GHOSH PH No-9986667320 Engineer (D&D) PRDE TATAELXSI LIMITED From finlayson at live555.com Wed Feb 28 02:01:56 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Feb 2007 02:01:56 -0800 Subject: [Live-devel] Transport stream In-Reply-To: <002801c75b1d$a541ca80$0a2a320a@telxsi.com> References: <002801c75b1d$a541ca80$0a2a320a@telxsi.com> Message-ID: The site wouldn't let me download your file, because it's greater than 10 MBytes in size. Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From susovan at tataelxsi.co.in Wed Feb 28 02:51:14 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Wed, 28 Feb 2007 16:21:14 +0530 Subject: [Live-devel] Transport stream In-Reply-To: Message-ID: <000001c75b26$5dfe4be0$0a2a320a@telxsi.com> Hi Ross, IF you have any .ts file link which can converted to .txs file ,please send me the link .I will try it in my system and replay you back. Thank you. SUSOVAN GHOSH PH No-9986667320 Engineer (D&D) PRDE TATAELXSI LIMITED -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com]On Behalf Of Ross Finlayson Sent: Wednesday, February 28, 2007 3:32 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Transport stream The site wouldn't let me download your file, because it's greater than 10 MBytes in size. Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Wed Feb 28 04:48:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Feb 2007 04:48:40 -0800 Subject: [Live-devel] Transport stream In-Reply-To: <000001c75b26$5dfe4be0$0a2a320a@telxsi.com> References: <000001c75b26$5dfe4be0$0a2a320a@telxsi.com> Message-ID: >Hi Ross, > IF you have any .ts file link which can converted to .txs file ,please >send me the link .I will try it in my system and replay you back. No, I want to know why *your* Transport Stream file doesn't work. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From krenzer at wayport.net Wed Feb 28 07:05:45 2007 From: krenzer at wayport.net (Matthew Krenzer) Date: Wed, 28 Feb 2007 09:05:45 -0600 Subject: [Live-devel] Transport header VLC client In-Reply-To: <45E51638.9030801@research.telcordia.com> References: <19851224.1503231172566772315.JavaMail.root@bj163app33.163.com> <45E41CD8.3060608@research.telcordia.com> <45E51638.9030801@research.telcordia.com> Message-ID: <52AD365BD79BA048B359E3F4411D4515105DA57E@exchange01.wayad.corp.wayport.net> We have had similar issues in the past multihoming boxes with other protocols (icmp, radius, and a few others). In the end the solution has always been to modify the client to bind outbound requests to a specific address. If you know the desired target address at the time of the RTSP request and the address exists on the box the request comes from (as in multihoming), you should just ensure the request actually originates from the desired target address. I think as a general rule (not sure here - and assuming bsd sockets), if you don't bind a socket before calling connect the OS assigns (somewhat of) a random source udp/tcp port number and chooses as the source address the ipaddress of the interface through which it thinks the packing will go - which is not always the desired source address. To do otherwise would be, as Ross points out, a potentially large vulnerability. Matthew > -----Original Message----- > From: live-devel-bounces at ns.live555.com [mailto:live-devel- > bounces at ns.live555.com] On Behalf Of Ashutosh Dutta > Sent: Tuesday, February 27, 2007 11:42 PM > To: LIVE555 Streaming Media - development & use > Subject: Re: [Live-devel] Transport header VLC client > > Ross, thanks for your reply. I agreed with DOS attack part. > > However, in some cases (e.g., multihoming case), the client may like to > receive the stream in a specific desired address. Thus having the > ability to receive at a particular address (interface) is sometimes > desirable. It is good to know that the RTSP server has some optional > settings. I guess, one needs to update the RTSP client to get this > feature. > > Thanks > Ashutosh > > > > > Ross Finlayson wrote: > >> I was curious if anybody has experience using transport header in VLC > >> client code to designate the address where the server should play it > >> stream. This is the example from RTSP RFC 2326bis. > >> > >>> C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 > >>> CSeq: 302 > >>> Transport: RTP/AVP;multicast;mode="PLAY", > >>> RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ > >>> "192.0.2.5:3457";mode="PLAY" > >>> > >>> S->C: RTSP/2.0 200 OK > >>> CSeq: 302 > >>> Date: 23 Jan 1997 15:35:06 GMT > >>> Session: 47112344 > >>> Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ > >>> "192.0.2.5:3457";src_addr="192.0.2.224:6256" > >>> /"192.0.2.224:6257";mode="PLAY" > > > > Note that the "LIVE555 Streaming Media" code does not yet support > > (for either clients or servers) the RTSP 2.0 proposal (as defined by > > the "2326bis" Internet Draft). We currently support only the RTSP > > 1.0 standard (RFC 2326). In RTSP 1.0, the parameter that you're > > referring to is called "destination", not "dest_addr". > > > > In any case, our RTSP client implementation (and thus, VLC) does not > > support this. Neither does our RTSP server implementation (except in > > some normally #ifdef'd out code in "RTSPServer.cpp"). Note that > > allowing the client to specify the IP address that the server should > > send has major security implications - it would effectively make > > possible denial-of-service attacks on innocent third parties - and so > > probably no RTSP server anywhere supports this feature by default. > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From xcsmith at rockwellcollins.com Wed Feb 28 09:26:32 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Wed, 28 Feb 2007 11:26:32 -0600 Subject: [Live-devel] Transport header VLC client Message-ID: > I won't be adding such functionality to the distributed source code. I have implemented this functionality to build into the RTSPClient when RTSP_ALLOW_CLIENT_DESTINATION_SETTING is set. In this way I can instruct my MPEG encoder's RTSP server where to send its multicast stream, which is a user requirement so that multiple encoders can exist on the same network. Does your comment mean that this capability, despite being disabled, could not be added to the distribution? Isn't it the server which is a security risk if it allows the RTSPClient to do this? RTSPClients - or telnet clients as i recall - can send whatever messages they want to RTSPServers, but it is the RTSPServer which gets do decide whether or not to follow the instruction. In the case of my system, the encoder's policy to allow clients to set the destination is the real security risk. The LIVE server does not support client destination setting by default, but it does support it. In the case of my LIVE code, my client now supports it too, but not by default. It doesn't seem illogical to me for the included client to support the capability if the server does, although it could be a bad idea for all general VLC users to have the capability enabled and go to town looking for RTSP servers that are vulnerable. Are there plans to remove the capability from the server source code? Anyway this feature would likely be included as part of the first patch I would run the red tape gauntlet with so that I have company authority to return it to the community. (Of course we are obligated to release this source code, but there's still a bunch of red tape for me to get it done because I intend to post patches to the community instead of hide them away and wait for people to come asking and have to wait 3 months to get them.) xochitl From finlayson at live555.com Wed Feb 28 13:13:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Feb 2007 13:13:15 -0800 Subject: [Live-devel] Transport header VLC client In-Reply-To: References: Message-ID: > > I won't be adding such functionality to >the distributed source code. > >I have implemented this functionality to build into the RTSPClient when >RTSP_ALLOW_CLIENT_DESTINATION_SETTING is set. In this way I can instruct >my MPEG encoder's RTSP server where to send its multicast stream, which is >a user requirement so that multiple encoders can exist on the same network. >Does your comment mean that this capability, despite being disabled, could >not be added to the distribution? Well, if someone submits a patch that adds such functionality to the RTSP client code, then I *might* conceivably include it in the distribution, but I'm certainly not going to go out of my way to write it myself. In any case, to use your example, it's bad design for the RTSP *clients* to be deciding which multicast address each server should be using, not merely because it relies upon the server having this ability enabled. It makes far more sense for each *server* to choose (or be assigned) its multicast address, in advance (when it starts up), in order to avoid conflicting with the multicast address(es) used by other server(s) on the same network. In general, it's the servers that will know this, not the clients (which might be on a completely separate network, and administered separately). Also, what if you want to have more than one client play the same stream (which I imagine that you do, given that you are using multicast)? How does the first client know that it should choose a destination multicast address itself, and how do the second (and subsequent) clients know that they should, instead, use the multicast address that the first client has already given to the server? In this case, having the clients tell the servers what multicast addresses to use is silly, and I see no reason to support it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From antoniotirri at libero.it Wed Feb 28 15:12:57 2007 From: antoniotirri at libero.it (Antonio Tirri) Date: Thu, 01 Mar 2007 00:12:57 +0100 Subject: [Live-devel] Simulation and packet loss Message-ID: <45E60C79.3090606@libero.it> Hi, i'm an italian student. For my thesis, i have to study the effect of packet loss on a MPEG video recived during a streaming session. I thinked to execute locally both Live555MediaServer and VLC client. Is it possibile to edit the live555MediaServer, in order to implement a packet loss model during streaming of a MPEG video? What file i have to edit? Thank You and sorry for my poor english :) Antonio Tirri From susovan at tataelxsi.co.in Wed Feb 28 19:49:48 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Thu, 1 Mar 2007 09:19:48 +0530 Subject: [Live-devel] Transport Stream Message-ID: <000001c75bb4$a8d1a160$0a2a320a@telxsi.com> Hi Ross, Thanx Ross for your coperation . I give the detail that i did to make .txs file from .ts file.from the cmd promt i run the program MPEG2TransportStreamIndexer with file name FTN_Part1.ts.Both the progran and the .ts file was placed in same location.Below is the detail. C:\Fresh Live555\live\testProgs>MPEG2TransportStreamIndexer FTN_Part1.ts Writing index file "FTN_Part1.tsx"......done After that it creat FTN_Part1.txs file of size 0KB.I can not understand what was happing.Please Ross help me. Thank You SUSOVAN GHOSH PH No-9986667320 Engineer (D&D) PRDE TATAELXSI LIMITED From adutta at research.telcordia.com Wed Feb 28 19:48:50 2007 From: adutta at research.telcordia.com (Ashutosh Dutta) Date: Wed, 28 Feb 2007 22:48:50 -0500 Subject: [Live-devel] Transport header VLC client In-Reply-To: References: Message-ID: <45E64D22.6090804@research.telcordia.com> Ross, I think we can still have a mechanism, where the client can make unicast RTSP request and provide the desired multicast transport address as part of SETUP request if the client knows ahead of time about the set of multicast addresses the RTSP server is provisioned with and the associated stream for each of the multicast address. I can think of using something like SAP or some other out-of-bound mechanism where the client becomes aware of that multicast address it needs to put in as destination addr in its SETUP request. Thus, RTSP server can act like Video-on-Demand server, and with some advanced knowledge of the multicast address, client can make use of this transport header option to get a specific desired stream. I agree that, this specific feature would be useful only for the cases where a group of people would like to watch the same video,(i.e, all the members in a family or all the members of a department)but, only one member of the family (head of the family) or the department (department head) has the control for starting the video or stopping it. Thanks Ashutosh Ross Finlayson wrote: >> > I won't be adding such functionality to >> the distributed source code. >> >> I have implemented this functionality to build into the RTSPClient when >> RTSP_ALLOW_CLIENT_DESTINATION_SETTING is set. In this way I can instruct >> my MPEG encoder's RTSP server where to send its multicast stream, which is >> a user requirement so that multiple encoders can exist on the same network. >> Does your comment mean that this capability, despite being disabled, could >> not be added to the distribution? > > Well, if someone submits a patch that adds such functionality to the > RTSP client code, then I *might* conceivably include it in the > distribution, but I'm certainly not going to go out of my way to > write it myself. > > In any case, to use your example, it's bad design for the RTSP > *clients* to be deciding which multicast address each server should > be using, not merely because it relies upon the server having this > ability enabled. It makes far more sense for each *server* to choose > (or be assigned) its multicast address, in advance (when it starts > up), in order to avoid conflicting with the multicast address(es) > used by other server(s) on the same network. In general, it's the > servers that will know this, not the clients (which might be on a > completely separate network, and administered separately). Also, > what if you want to have more than one client play the same stream > (which I imagine that you do, given that you are using multicast)? > How does the first client know that it should choose a destination > multicast address itself, and how do the second (and subsequent) > clients know that they should, instead, use the multicast address > that the first client has already given to the server? > > In this case, having the clients tell the servers what multicast > addresses to use is silly, and I see no reason to support it. From mr.nguyenhonghai at gmail.com Wed Feb 28 20:02:01 2007 From: mr.nguyenhonghai at gmail.com (Hong Hai Nguyen) Date: Thu, 1 Mar 2007 11:02:01 +0700 Subject: [Live-devel] Problem with H264+DSS Message-ID: <731203720702282002hc3db25eqfff02c79a6f2c6f0@mail.gmail.com> Hi, everyone! I have got a problem with H264 elementary stream captured from Darwin Streaming Server. I cannot play the output file video-H264-1 with some video player (MPlayer or FFPlay), they said "Could not find codec parameters (Audio: mp3, 8 kb/s)". I have read the source-code (playCommon.cpp) and found that the MPEG4-ES have a header in the SDP 'config' data and the output file video-MPEG4-ES was played successfully, but when I tried to add the same thing into the H264 output file, the file cannot be played - it catched the same error :(. Any recommendations are appriciated! Some source code is so much the better! Thank you! -- Hong Hai, Nguyen RDLAB - Multimedia Research & Development Laboratory Faculty of Electronic and Telecommunication Hanoi University of Technology Hanoi, Vietnam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070228/d1860ec6/attachment.html From susovan at tataelxsi.co.in Wed Feb 28 21:59:04 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Thu, 1 Mar 2007 11:29:04 +0530 Subject: [Live-devel] Link of tf lile(transport stream) Message-ID: <003501c75bc6$b8816b10$0a2a320a@telxsi.com> Hi Ross, here is the link of the file FTN_Part1.ts.please check this one . http://www2.sendthisfile.com/d.jsp?t=jO7zviGOSZxeSlAFl7MmvjTC i am waiting for your replay. Thank you SUSOVAN GHOSH PH No-9986667320 Engineer (D&D) PRDE TATAELXSI LIMITED