From yaopingtiankong at 163.com Mon Nov 1 00:44:39 2010 From: yaopingtiankong at 163.com (=?gbk?B?0qLGvQ==?=) Date: Mon, 1 Nov 2010 15:44:39 +0800 (CST) Subject: [Live-devel] Problem about Application of live555 in embeded system Message-ID: <11c97d1.600b.12c06652129.Coremail.yaopingtiankong@163.com> Good afternoon,every experts! Sorry to disturb you. I am a master of Central South University(changsha,hu nan province,china).Recently I am work on research of live555 in embeded system. I come across a big and strange problem when running the test example "testMPEG4VideoStreamer.cpp" in Embeded system. But it works well in linux system which runs on PC. the following shows the details: Environment: server MediaServer:live555 platform?davinci dm6446,with super terminal together to debug. Embeded system?montavista linux client VLC ?using vlc to receive video stream ,windows xp? test project The test example in file " testProgs": testMPEG4VideoStreamer.cpp Problem description server: running testMPEG4VideoStream in super terminal. client: running vlc in cmd like this, vlc -vv --extraintf=logger rtsp://192.168.1.120/testStream test result: vlc in cmd shows that the buffer fills very slow, it takes nearly 5 minutes to grow up from 0% to 100%. And then show a picture, then fills from 0% again...this really bother me a lot. But it works very well when I run this test example in linux system(not embeded linux). VLC cann't play it. some debugger already done ,this may help you to analyse convinently? 1?if I run the test testMPEG4VideoStream in linux? not embeded linux?,it works well.VLC's buffer fills very fast,and plays smoothly. 2?several days ago,I meet this problem which has been solved ?? Groupsock failed? setsockopt?? no such device? some one told me that maybe my kernal didn't support multicast. so I got a way to do like following: solution: Firstly,recompile the kernal of montavista linux,add the supportIP:MULTICAST?then download. when I run ifconfigin super terminal, the coming-out messages contain this:UP BROADCAST RUNNING MULTICAST MTU:1500 METRIC 1 this means the system have supported multicast. right? Secondly add route like this? route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 route add default gw "192.168.40.1 " dev eth0 ?up here ,the error? Groupsock failed? setsockopt?? no such device?disappeared? That's all. Waiting for your answer. Thanks? Ping Yao -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Nov 1 01:50:31 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 1 Nov 2010 01:50:31 -0700 Subject: [Live-devel] Problem about Application of live555 in embeded system In-Reply-To: <11c97d1.600b.12c06652129.Coremail.yaopingtiankong@163.com> References: <11c97d1.600b.12c06652129.Coremail.yaopingtiankong@163.com> Message-ID: I suggest that you first try running "testOnDemandRTSPServer" (or "live555MediaServer") to stream from your ".m4e" file via unicast instead of multicast. Also, you should try using "openRTSP" as a client, rather than just VLC. (VLC is not our software, so we can't give you much help with VLC problems.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yaopingtiankong at 163.com Mon Nov 1 06:04:51 2010 From: yaopingtiankong at 163.com (=?gbk?B?0qLGvQ==?=) Date: Mon, 1 Nov 2010 21:04:51 +0800 (CST) Subject: [Live-devel] Problem about Application of live555 in embeded system In-Reply-To: References: <11c97d1.600b.12c06652129.Coremail.yaopingtiankong@163.com> Message-ID: <1c661e0.710d.12c078a47f5.Coremail.yaopingtiankong@163.com> Can you tell me how to change testOnDemandRTSPServer from multicast to unicast? thanks. At 2010-11-01 16:50:31?"Ross Finlayson" wrote: >I suggest that you first try running "testOnDemandRTSPServer" (or >"live555MediaServer") to stream from your ".m4e" file via unicast >instead of multicast. > >Also, you should try using "openRTSP" as a client, rather than just >VLC. (VLC is not our software, so we can't give you much help with >VLC problems.) >-- > >Ross Finlayson >Live Networks, Inc. >http://www.live555.com/ >_______________________________________________ >live-devel mailing list >live-devel at lists.live555.com >http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Nov 1 06:21:49 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 1 Nov 2010 06:21:49 -0700 Subject: [Live-devel] Problem about Application of live555 in embeded system In-Reply-To: <1c661e0.710d.12c078a47f5.Coremail.yaopingtiankong@163.com> References: <11c97d1.600b.12c06652129.Coremail.yaopingtiankong@163.com> <1c661e0.710d.12c078a47f5.Coremail.yaopingtiankong@163.com> Message-ID: >Can you tell me how to change testOnDemandRTSPServer from multicast >to unicast? The "testOnDemandRTSPServer" application *already* streams via unicast; nothing needs to be changed. (The "test*Streamer" applications stream via multicast; the "testOnDemandRTSPServer" and "live555MediaServer" applications stream via unicast.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jkburges at gmail.com Mon Nov 1 08:20:08 2010 From: jkburges at gmail.com (Jon Burgess) Date: Mon, 1 Nov 2010 23:20:08 +0800 Subject: [Live-devel] receiving and decoding AAC-hbr Message-ID: Hi, I have subclassed MediaSink in an attempt to provide an adapter class between live555 and the audio APIs on iOS (iPhone). The RTSP session is set up using the openRTSP test program (except my custom subclass of MediaSink is used in place of FileSink). The stream being received is an AAC-hbr stream. I am getting *some* audio to decode/render, but it seems as though the data is being consumed faster than it is being supplied, resulting in audio rendering to stop (it's quite likely a problem down stream from live555, but just trying to rule things out). I just want to double check that each frame received from the MPEG4GenericRTPSource is actually a depacketized, "raw" AAC frame - i.e. stripped of all RTP and AU headers etc, and ready to be sent on for decoding. Also, the server (in this case Darwin 5.5.5) is sending out multiframed RTP packets (about 6 or 7 frames per RTP packets) - my sink is being notified of new data but with the same presentation timestamp for 6 or 7 frames in a row (it then increases). I'm guessing that the MPEG4GenericeRTPSource is setting the pts based on the RTP timestsamp, and not calculating for each frame within the packet, and that's why I'm seeing this behaviour. Is this correct? The pts is ignored by my code anyway - again, just trying to understand things. Regards, Jon Burgess -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaopingtiankong at 163.com Mon Nov 1 20:12:41 2010 From: yaopingtiankong at 163.com (=?gbk?B?0qLGvQ==?=) Date: Tue, 2 Nov 2010 11:12:41 +0800 (CST) Subject: [Live-devel] Problem about Application of live555 in embeded system In-Reply-To: References: <11c97d1.600b.12c06652129.Coremail.yaopingtiankong@163.com> <1c661e0.710d.12c078a47f5.Coremail.yaopingtiankong@163.com> Message-ID: <7b55f7e0.3828.12c0a927e27.Coremail.yaopingtiankong@163.com> According to your suggestion, I have done some tests like the following: 1. Firstly,I open testOnDemandRTSPServer in super terminal, then I run openRTSP in cmd like : openRTSP rtsp://192.168.1.120/mpeg4ESVideoTest, the window print out some message,but stop ataccept:application/sdp. after a while,I try to open another cmd ,and input the same command, it was surprise the two window print out all the message and begin to receive data. but another problem comes out 2?The client receive data very slow just like what happened when using VLC (what I said in my first email) but it also works well when I run testOnDemandRTSPServer in linux system(not embeded). So can you tell me why? Thanks. At 2010-11-01 21:21:49?"Ross Finlayson" wrote: >>Can you tell me how to change testOnDemandRTSPServer from multicast >>to unicast? > >The "testOnDemandRTSPServer" application *already* streams via >unicast; nothing needs to be changed. > >(The "test*Streamer" applications stream via multicast; the >"testOnDemandRTSPServer" and "live555MediaServer" applications stream >via unicast.) >-- > >Ross Finlayson >Live Networks, Inc. >http://www.live555.com/ >_______________________________________________ >live-devel mailing list >live-devel at lists.live555.com >http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From 44072429 at qq.com Tue Nov 2 01:49:40 2010 From: 44072429 at qq.com (=?ISO-8859-1?B?NDQwNzI0Mjk=?=) Date: Tue, 2 Nov 2010 16:49:40 +0800 Subject: [Live-devel] memory leak Message-ID: hi,dear friend. i don't know how to delete your variant. and i saw many strDup string.wouldn't delete at all. why are you doing this. or am i wrong usage? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 2 02:10:27 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Nov 2010 02:10:27 -0700 Subject: [Live-devel] memory leak In-Reply-To: References: Message-ID: >i don't know how to delete your variant. >and i saw many strDup string.wouldn't delete at all. >why are you doing this. >or am i wrong usage? I'm sorry, but I don't really understand your question. Can you give a specific example of something that you think is a memory leak? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From francisco at j2kvideo.com Tue Nov 2 02:40:39 2010 From: francisco at j2kvideo.com (Francisco Feijoo) Date: Tue, 2 Nov 2010 10:40:39 +0100 Subject: [Live-devel] JPEGVideoRTPSink and Restart markers In-Reply-To: References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com> <4CC7DA07.7080202@imavis.com> Message-ID: <852F8B82-F6F7-409B-8984-58EDC5305D64@j2kvideo.com> El 28/10/2010, a las 16:09, Ross Finlayson escribi?: > OK, I have now installed a new version (2010.10.28) of the code that adds support for "Restart Marker Headers" in outgoing JPEG/RTP packets. (We already supported such headers in *incoming* JPEG/RTP packets.) > > To use this, your "JPEGVideoSource" subclass must redefine the virtual function "restartInterval()" to return a non-zero value if "type()" returns a value in the range [64,127]. > > You should *not* need to subclass or modify the implementation of "JPEGVideoRTPSink". > -- > > 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 Hi, finally I have this working. Cristiano, I have used your code to get information from the image. I have also changed doSpecialFrameHandling because you don't have to send the DRI header for images that don't have this markers. u_int8_t RestartMarkerHeader[4]; // the special header u_int16_t restartInterval = source->restartInterval(); if (restartInterval > 0 ) { RestartMarkerHeader[0] = restartInterval >> 8; RestartMarkerHeader[1] = restartInterval; RestartMarkerHeader[2] = 0xFF; RestartMarkerHeader[3] = 0xFF; setSpecialHeaderBytes(RestartMarkerHeader, sizeof RestartMarkerHeader, sizeof mainJPEGHeader /* start position */); } Ross, thanks for the new release. I have tried it and is not working here. Maybe I'm doing something wrong, could you send one JPEG image working? If you want I can send two test images with and without restart markers for you to test. Cheers. -- Francisco Feijoo Software Engineer J2K Video Limited W: www.j2kvideo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From 44072429 at qq.com Tue Nov 2 02:25:11 2010 From: 44072429 at qq.com (=?ISO-8859-1?B?NDQwNzI0Mjk=?=) Date: Tue, 2 Nov 2010 17:25:11 +0800 Subject: [Live-devel] memory leak Message-ID: m_pUsageEnvironment = BasicUsageEnvironment::createNew(*m_pTaskScheduler); if(m_pUsageEnvironment == NULL) { service_error.init(service_error_type_failed,"BasicUsageEnvironment::createNew failed"); return service_error; } and . how to delete this m_pUsageEnvironment; ------------------ Original ------------------ From: "Ross Finlayson"; Date: Tue, Nov 2, 2010 05:10 PM To: "LIVE555 Streaming Media - development & use"; Subject: Re: [Live-devel] memory leak >i don't know how to delete your variant. >and i saw many strDup string.wouldn't delete at all. >why are you doing this. >or am i wrong usage? I'm sorry, but I don't really understand your question. Can you give a specific example of something that you think is a memory leak? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe at lemoine-fr.com Tue Nov 2 02:35:46 2010 From: christophe at lemoine-fr.com (Christophe Lemoine) Date: Tue, 02 Nov 2010 11:35:46 +0200 Subject: [Live-devel] H264 streaming with trick play Message-ID: <4CCFDB72.5050709@lemoine-fr.com> Hi, I'm looking for a H264 streaming implementation that supports trick play (at least play/pause/skip). Any video container format would be ok to start with. I can see in the list archive that a few developers where doing such an implementation, but could not find any running code.... I would also be ready to participate in any ongoing development. Thanks for your help. Christophe From finlayson at live555.com Tue Nov 2 06:06:53 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Nov 2010 06:06:53 -0700 Subject: [Live-devel] memory leak In-Reply-To: References: Message-ID: >m_pUsageEnvironment = BasicUsageEnvironment::createNew(*m_pTaskScheduler); >if(m_pUsageEnvironment == NULL) >{ >service_error.init(service_error_type_failed,"BasicUsageEnvironment::createNew failed"); >return service_error; >} > >and . how to delete this m_pUsageEnvironment; Objects of class "UsageEnvironment" (or subclasses) are deleted using "UsageEnvironment::reclaim()", rather than "delete". So, just call: m_pUsageEnvironment->reclaim(); and then delete m_pTaskScheduler; Of course, you should do this only after you have deleted any "Media" subclassed objects - using "Medium::close()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Nov 2 06:07:27 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Nov 2010 06:07:27 -0700 Subject: [Live-devel] JPEGVideoRTPSink and Restart markers In-Reply-To: <852F8B82-F6F7-409B-8984-58EDC5305D64@j2kvideo.com> References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com> <4CC7DA07.7080202@imavis.com> <852F8B82-F6F7-409B-8984-58EDC5305D64@j2kvideo.com> Message-ID: >Ross, thanks for the new release. I have tried it and is not working here. Please let me know if you find any bugs in the latest release, because it is the only version for which support will be given. (Remember, You Have Complete Source Code.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From francisco at j2kvideo.com Tue Nov 2 06:38:46 2010 From: francisco at j2kvideo.com (Francisco Feijoo) Date: Tue, 2 Nov 2010 14:38:46 +0100 Subject: [Live-devel] JPEGVideoRTPSink and Restart markers In-Reply-To: References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com> <4CC7DA07.7080202@imavis.com> <852F8B82-F6F7-409B-8984-58EDC5305D64@j2kvideo.com> Message-ID: <44337E12-1B6D-47CC-B36F-E107BD7C3E2E@j2kvideo.com> El 02/11/2010, a las 14:07, Ross Finlayson escribi?: >> Ross, thanks for the new release. I have tried it and is not working here. > > Please let me know if you find any bugs in the latest release, because it is the only version for which support will be given. (Remember, You Have Complete Source Code.) > -- > > 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 Ok, If I can find the problem I will report it. -- Francisco Feijoo Software Engineer J2K Video Limited W: www.j2kvideo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mojtaba.nouri at gmail.com Tue Nov 2 06:21:02 2010 From: mojtaba.nouri at gmail.com (Mojtaba Nouri) Date: Tue, 2 Nov 2010 16:51:02 +0330 Subject: [Live-devel] Index onlive stream Message-ID: Hi I am trying to capture a live stream (which is MPEG2TS) via openRTSP and instead of recording it in 'video-MP2T-1', index the received video on-live. FramedSource* video1 = sources[0]; //I caught it from MediaSubsession MediaSink* outputIndexerSink = FileSink::createNew(*env, "out.tsx"); FramedSource* indexer = MPEG2IFrameIndexFromTransportS tream::createNew(*env, video1); outputIndexerSink->startPlaying(*indexer, subsessionAfterPlaying, NULL); when I run it, I get these errors: MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (188). 940 bytes of trailing data will be dropped! what seems to be the problem? Regards Mojtaba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sr at coexsi.fr Tue Nov 2 06:45:04 2010 From: sr at coexsi.fr (=?iso-8859-1?Q?S=E9bastien_RAILLARD_=28COEXSI=29?=) Date: Tue, 2 Nov 2010 14:45:04 +0100 Subject: [Live-devel] H264 streaming with trick play In-Reply-To: <4CCFDB72.5050709@lemoine-fr.com> References: <4CCFDB72.5050709@lemoine-fr.com> Message-ID: <008501cb7a94$282960e0$787c22a0$@coexsi.fr> > -----Original Message----- > From: live-devel-bounces at ns.live555.com [mailto:live-devel- > bounces at ns.live555.com] On Behalf Of Christophe Lemoine > Sent: mardi 2 novembre 2010 10:36 > To: live-devel at ns.live555.com > Subject: [Live-devel] H264 streaming with trick play > > Hi, > > I'm looking for a H264 streaming implementation that supports trick play > (at least play/pause/skip). Any video container format would be ok to > start with. > I can see in the list archive that a few developers where doing such an > implementation, but could not find any running code.... I would also be > ready to participate in any ongoing development. I've published recently a work for doing trick play with any TS files (containing H264 or not). There are some limitations, the source code and binaries are provided for Windows and Linux. Here is the link: http://www.coexsi.fr/publications/live555-universal-indexer/ > > Thanks for your help. > > Christophe > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1153 / Virus Database: 424/3232 - Release Date: 11/01/10 From finlayson at live555.com Tue Nov 2 07:45:10 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Nov 2010 07:45:10 -0700 Subject: [Live-devel] Index onlive stream In-Reply-To: References: Message-ID: >I am trying to capture a live stream (which is MPEG2TS) via openRTSP and >instead of recording it in 'video-MP2T-1', index the received video >on-live. > >FramedSource* video1 = sources[0]; //I caught it from MediaSubsession >MediaSink* outputIndexerSink = FileSink::createNew(*env, "out.tsx"); >FramedSource* indexer = MPEG2IFrameIndexFromTransportS >tream::createNew(*env, video1); > >outputIndexerSink->startPlaying(*indexer, subsessionAfterPlaying, NULL); > >when I run it, I get these errors: >MultiFramedRTPSource::doGetNextFrame1(): The total received frame >size exceeds the client's buffer size (188). 940 bytes of trailing >data will be dropped! > >what seems to be the problem? In principle, what you are doing is exactly right. In practice, though, the problem is that the "MPEG2IFrameIndexFromTransportStream" object reads just one 188-byte MPEG Transport 'packet' at a time, into a 188-byte buffer. However, the upstream object "SimpleRTPSource" (a subclass of "MultiFramedRTPSource") delivers a whole network packet's worth of data, which is usually much larger. To overcome this, you will need to write a new filter object and insert it between "video1" and "indexer" in your code. This filter object will be of a subclass of "FramedFilter" that you'll need to write yourself. It will read network packet data into a large buffer, and deliver - from this buffer - 188-byte MPEG Transport 'packets', one-at-a-time, to its downstream reader ("indexer"). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From waazimreza at gmail.com Tue Nov 2 07:50:18 2010 From: waazimreza at gmail.com (Waazim Reza) Date: Tue, 2 Nov 2010 10:50:18 -0400 Subject: [Live-devel] I need H.264 streaming code Message-ID: Hi, I'm looking for a H264 streaming implementation. I looked at the tutorial, but had many mistakes in it and not its not running. If anybody has already implemented the code, please sent the code to me. Thanks for your help. Waazim Reza wreza at fau.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From 44072429 at qq.com Tue Nov 2 18:03:40 2010 From: 44072429 at qq.com (=?ISO-8859-1?B?NDQwNzI0Mjk=?=) Date: Wed, 3 Nov 2010 09:03:40 +0800 Subject: [Live-devel] memory leak Message-ID: thank you. and another question. what about MediaSubSession::sessionId. it was created was strDup. and where to delete it. the same to other strDup return variant. ------------------ Original ------------------ From: "Ross Finlayson"; Date: Tue, Nov 2, 2010 09:06 PM To: "LIVE555 Streaming Media - development & use"; Subject: Re: [Live-devel] memory leak >m_pUsageEnvironment = BasicUsageEnvironment::createNew(*m_pTaskScheduler); >if(m_pUsageEnvironment == NULL) >{ >service_error.init(service_error_type_failed,"BasicUsageEnvironment::createNew failed"); >return service_error; >} > >and . how to delete this m_pUsageEnvironment; Objects of class "UsageEnvironment" (or subclasses) are deleted using "UsageEnvironment::reclaim()", rather than "delete". So, just call: m_pUsageEnvironment->reclaim(); and then delete m_pTaskScheduler; Of course, you should do this only after you have deleted any "Media" subclassed objects - using "Medium::close()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 2 18:25:46 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Nov 2010 18:25:46 -0700 Subject: [Live-devel] memory leak In-Reply-To: References: Message-ID: >and another question. >what about MediaSubSession::sessionId. >it was created was strDup. >and where to delete it. This field is not managed by "MediSubsession" itself. Instead, it is assigned by "RTSPClient" while performing the RTSP "SETUP" command, and is deleted automatically later (again, by "RTSPClient") while performing the RTSP "TEARDOWN" command. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mojtaba.nouri at gmail.com Wed Nov 3 04:09:40 2010 From: mojtaba.nouri at gmail.com (Mojtaba Nouri) Date: Wed, 3 Nov 2010 14:39:40 +0330 Subject: [Live-devel] Index onlive stream In-Reply-To: References: Message-ID: Thank you. One problem thought. I read 7*188 bytes from input and output 188 byte each time. but when the indexer read 7th frame (last 188 bytes of 188*7 bytes) I get this error: Bad TS sync byte: 0x0 But when I drop the last frame each time, indexing works and it seems that it generates a correct one. Am i doing it right. Thanks again. On Tue, Nov 2, 2010 at 6:15 PM, Ross Finlayson wrote: > I am trying to capture a live stream (which is MPEG2TS) via openRTSP and >> instead of recording it in 'video-MP2T-1', index the received video >> on-live. >> >> FramedSource* video1 = sources[0]; //I caught it from MediaSubsession >> MediaSink* outputIndexerSink = FileSink::createNew(*env, "out.tsx"); >> FramedSource* indexer = MPEG2IFrameIndexFromTransportS >> tream::createNew(*env, video1); >> >> outputIndexerSink->startPlaying(*indexer, subsessionAfterPlaying, NULL); >> >> when I run it, I get these errors: >> MultiFramedRTPSource::doGetNextFrame1(): The total received frame size >> exceeds the client's buffer size (188). 940 bytes of trailing data will be >> dropped! >> >> what seems to be the problem? >> > > In principle, what you are doing is exactly right. In practice, though, > the problem is that the "MPEG2IFrameIndexFromTransportStream" object reads > just one 188-byte MPEG Transport 'packet' at a time, into a 188-byte buffer. > However, the upstream object "SimpleRTPSource" (a subclass of > "MultiFramedRTPSource") delivers a whole network packet's worth of data, > which is usually much larger. > > To overcome this, you will need to write a new filter object and insert it > between "video1" and "indexer" in your code. This filter object will be of > a subclass of "FramedFilter" that you'll need to write yourself. It will > read network packet data into a large buffer, and deliver - from this buffer > - 188-byte MPEG Transport 'packets', one-at-a-time, to its downstream reader > ("indexer"). > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Nov 3 06:13:18 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Nov 2010 06:13:18 -0700 Subject: [Live-devel] Index onlive stream In-Reply-To: References: Message-ID: >One problem thought. I read 7*188 bytes from input and output 188 >byte each time. but when the indexer read 7th frame (last 188 bytes >of 188*7 bytes) I get this error: >Bad TS sync byte: 0x0 Then clearly you're not outputting the 7th 188-byte 'frame' correctly, because each of the 7 188-byte 'frames' (MPEG Transport Stream 'packets') definitely starts with a 'sync byte' (0x47). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jortola86 at gmail.com Wed Nov 3 10:11:01 2010 From: jortola86 at gmail.com (Jordi) Date: Wed, 03 Nov 2010 18:11:01 +0100 Subject: [Live-devel] rtsp serving camera stream Message-ID: <1288804261.3961.87.camel@PZeus> Hi, I'm developing a rtsp server for an embedded (i-mx53) over linux. I suppose this great library will compile and run but the main problem is that I don't know where to start due to the leak of documentation (maybe I didn't find it). I need to transmit in a session: video and binary data from memory. I'll receive uncompressed L16 (luminance 16bits) video from a camera in my embedded device, I'll have to encode that video in h264 and keep it synk with the binary data and send to all my subscripted clients. Could anyone explain me how to get this? From kamildobk at poczta.onet.pl Thu Nov 4 07:20:04 2010 From: kamildobk at poczta.onet.pl (Kamil Dobkowski) Date: Thu, 4 Nov 2010 15:20:04 +0100 Subject: [Live-devel] RTSP-over-HTTP problems Message-ID: <0F517E25D11343F9AE6501AAACEAF095@KamilPC> Hi, I have problems with RTSP over HTTP. OpenRTSP still fails to connect to the server ( network camera ) when authorization is required. This happens only when I use latest library versions, older ones like 'live.2010.01.22` are working perfectly in each case. The only difference I found is that the older library keeps sending GET request until authorization is finished, and the new library starts to send POST request after the first GET, no matter if authorization succeeded or not. I can send you a link to my RTSP server if you would like to take a look. Regards, Kamil From finlayson at live555.com Thu Nov 4 07:47:00 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Nov 2010 07:47:00 -0700 Subject: [Live-devel] RTSP-over-HTTP problems In-Reply-To: <0F517E25D11343F9AE6501AAACEAF095@KamilPC> References: <0F517E25D11343F9AE6501AAACEAF095@KamilPC> Message-ID: >I have problems with RTSP over HTTP. OpenRTSP still fails to connect >to the server ( network camera ) when authorization is required. >This happens only when I use latest library versions, older ones >like 'live.2010.01.22` are working perfectly in each case. No. That version of the library worked the same way that the current version does. It was only some more recent versions (2010.05.29 through 2010.10.20) that worked differently. > The only difference I found is that the older library keeps sending >GET request until authorization is finished, and the new library >starts to send POST request after the first GET, no matter if >authorization succeeded or not. Arggh! I deliberately changed the behavior of the client to do this (in the 2010.10.22 version), because you had told me (back then) that this is what your server wanted. Now you're telling me the complete opposite!!! > I can send you a link to my RTSP server if you would like to take a look. Yes, please send us a publically-accessible "rtsp://" URL (with username & password) for this stream. (And once again, if you want to be taken more seriously on this mailing list, you should use a professional email address - not "@poczta.onet.pl".) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Nov 4 16:18:10 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Nov 2010 16:18:10 -0700 Subject: [Live-devel] RTSP-over-HTTP problems Message-ID: Kamil, Thanks for providing access to a server that illustrates the problem. I have now installed a new version (2010.11.04) of the "LIVE555 Streaming Media" code that fixes this problem (in "RTSPClient"). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sandmanup at vip.163.com Thu Nov 4 17:11:59 2010 From: sandmanup at vip.163.com (=?gb2312?B?1Ky1wsqk?=) Date: Fri, 5 Nov 2010 08:11:59 +0800 Subject: [Live-devel] Ask to contribute to the team Message-ID: <201011050811579869270@vip.163.com> HI, I made a new version of the RTSP clients sources to fix the "groupsock" implementation so that it could use IPv6/IPv4 in both GNU Linux and Windows(XP -> 7). However, most codes were modified in a unfriendly way, since I was just for a test. And now, I want to generate a full version supporting both IPv6 and IPv4 using compatible socket API, and after that , i want to contribute that to the live team for further development. Would you please tell me that how to join the live555 development team? Thanks a lot. Best regards. Guangdong ZDXT technologies, ltd. Sandman.Yuan E-mail?sandmanup at vip.163.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Nov 4 18:19:44 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Nov 2010 18:19:44 -0700 Subject: [Live-devel] Ask to contribute to the team In-Reply-To: <201011050811579869270@vip.163.com> References: <201011050811579869270@vip.163.com> Message-ID: Changes to the "LIVE555 Streaming Media" source code release are made only by Live Networks, Inc. However, we will always consider incorporating bugfixes, patches, and other suggested improvements that are posted on this mailing list. (Several such changes are made to the code each month, on average.) However, suggestions of major, widespread changes to the code are less likely to be adopted, because of the increased potential for disruption (due to the unexpected introduction of new bugs). We do plan to support IPv6 someday, but this will be done by completely replacing the "Groupsock" interface (not just rewriting it) with a new 'network packet' abstraction (treating incoming network interfaces as 'framed sources' and outgoing network interfaces as 'framed sinks'- the same way we already treat RTP media frames). Then our code will be able to handle any network interface, whether IPv4, IPv6, or synthetic (e.g., a simulated network interface). Unfortunately this will be a lot of work, and there's currently no ETA for it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Nov 4 18:49:38 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Nov 2010 18:49:38 -0700 Subject: [Live-devel] Basic 'netiquette': Please do not post the same question to the list multiple times Message-ID: I have just been forced to remove someone from the mailing list for violating (what I would have thought was) a simple, well-known rule of mailing list 'netiquette': They attempted to post the same question to the mailing list multiple times (after their first post had already been accepted and sent to the list). A reminder: Not every question that's posted to this mailing list happens to get answered. If noone answers your question, then it may just be because noone knows the answer. Or maybe it was because your question was specific to your particular environment and/or application (which the rest of us may know little about). Or maybe your question can be answered by reading the FAQ. Or maybe people just don't find your question interesting enough to respond to. If your question shows up on the mailing list, then rest assured that lots of people (currently, more than 900 people) will get to see it. But sometimes, a question does not get answered. If that happens, then sorry - but *do not* resend the question to the list again. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From 44072429 at qq.com Fri Nov 5 02:10:32 2010 From: 44072429 at qq.com (=?ISO-8859-1?B?NDQwNzI0Mjk=?=) Date: Fri, 5 Nov 2010 17:10:32 +0800 Subject: [Live-devel] Live555MediaServer Message-ID: i use vlc to play sample.mp3 from Live555MediaServer. and i found that vlc buffer twice when i click play button. and i debug the code found that,the FrameSource object will be created twice. and the first time is to get sdp information. and the second time is to play stream. but it called doGetNextFrame automately in the first time when FrameSource was created. ofcourse it was sent immediately. is there a reason you called doGetNextFrame when get sdp? thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Nov 5 04:18:07 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Nov 2010 04:18:07 -0700 Subject: [Live-devel] Live555MediaServer In-Reply-To: References: Message-ID: >i use vlc to play sample.mp3 from Live555MediaServer. >and i found that vlc buffer twice when i click play button. I'm not sure what this means, but it is completely irrelevant to the rest of your question. (Whatever the VLC client does, it requests the stream (using the RTSP protocol) only once. You could also have used the "openRTSP" client to play the stream.) >and i debug the code found that,the FrameSource object will be created twice. >and the first time is to get sdp information. That is correct. The first time a particular file is requested, the "live555MediaServer" creates a new "ServerMediaSubsession" object for it. As part of getting the stream's SDP description, the server then calls "OnDemandServerMediaSubsession::sdpLines()", which in turn creates - and then deletes - 'dummy' source and sink objects. (However, for MP3 files, these 'dummy' objects do not actually get used.) Note again that this happens only when a particular file is being requested *for the first time*. >and the second time is to play stream. Yes. When actually playing the stream (i.e., handling the RTSP "PLAY" command), 'real' source and sink (i.e., RTPSink) objects are created and used. >but it called doGetNextFrame automately in the first time when >FrameSource was created. >ofcourse it was sent immediately. > >is there a reason you called doGetNextFrame when get sdp? We don't. When streaming a MP3 file, "FramedSource::getNextFrame()" (and therefore the "doGetNextFrame()" virtual function) gets called only when the file is actually being streamed (i.e., in response to the RTSP "PLAY" command). When streaming certain other kinds of media file - in particular, MPEG-4 Elementary Stream Video (.m4e) files - the server may need to start reading the file to get all the information that it needs to create the SDP description. That is not true for MP3 files, however. In any case, you should not need to concern yourself with any of this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From matteo.pampolini at elsagdatamat.com Mon Nov 8 08:06:06 2010 From: matteo.pampolini at elsagdatamat.com (Pampolini Matteo) Date: Mon, 08 Nov 2010 17:06:06 +0100 Subject: [Live-devel] Send/receive MPEG2 TS streams without RTP encapsulation Message-ID: <4CD81FEE.6030802@elsagdatamat.com> Hello there, my name is Matteo and I'm writing from Italy. Maybe my question already occurred in this list, but searching in the archives I was not able to find what I need, that's why I decided to post. I'm developing a Live555-based client application that has to connect to a server that sends MPEG2 TS streams without RTP encapsulation (directly over UDP): is there a way to pass some configuration flag or similar to Live555 classes to avoid getting data through RTP? Many thanks in advance for your kind help, Matteo From finlayson at live555.com Mon Nov 8 15:01:34 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Nov 2010 15:01:34 -0800 Subject: [Live-devel] Send/receive MPEG2 TS streams without RTP encapsulation In-Reply-To: <4CD81FEE.6030802@elsagdatamat.com> References: <4CD81FEE.6030802@elsagdatamat.com> Message-ID: >I'm developing a Live555-based client application that has to connect to a >server that sends MPEG2 TS streams without RTP encapsulation (directly over >UDP): is there a way to pass some configuration flag or similar to Live555 >classes to avoid getting data through RTP? It's the server that decides what kind of stream it wants to send. I.e., the server's SDP description for the stream - that it returns in response to the client's RTSP "DESCRIBE" command - will describe whether or not the stream is sent via raw UDP, or via RTP. Unfortunately, however, there's no standard for how a raw UDP stream is described in SDP (in part because such streams are a bad idea; e.g., with such a stream, you can't recover from misordered packets). Nonetheless, our client code understands some common ways that a server might describe such a stream, and handles it accordingly. So, please let us know how your server describes such a stream. E.g., please send us the output from running "openRTSP" to try to play/record the stream. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From maratshch at gmail.com Mon Nov 8 23:54:53 2010 From: maratshch at gmail.com (Marat Shchuchinsky) Date: Tue, 9 Nov 2010 09:54:53 +0200 Subject: [Live-devel] RTP timestamp changes when second client connected to same stream. In-Reply-To: References: Message-ID: Der Sir! I'm works with live555 to stream H264 encoded video, via RTP. I have found not clear functionality in your code and I will be grateful if you explain to me. When secondary client connected to same stream I saw "jump" into RTP timestamp in first stream. I have seen a code and to me functionality isn't clear in: RTPSink::convertToRTPTimestamp and RTPSink::presetNextTimestamp(). Why need to change "fTimestampBase" when secondary stream connected ??? Why connection of secondary client influence on fTimestampBase and timestamp of first client??? timeStamp base overwrite by function "presetNextTimestamp" into RTPSink.cpp What is reason for base timestamp use randomaly value and not real time stamp, created by gettimeofday()??? Thank you very much and best regrads. Marat Shchuchinsky. // DSP software engineer. // maratshch at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 9 00:28:03 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Nov 2010 00:28:03 -0800 Subject: [Live-devel] RTP timestamp changes when second client connected to same stream. In-Reply-To: References: Message-ID: The conversion from presentation time to RTP timestamp (in the server code), and from RTP timestamp to presentation time (in the client code) happens automatically, and is not something that you should concern yourself with. As a (server or client) developer, you need concern yourself only with presentation times. >When secondary client connected to same stream I saw "jump" into RTP >timestamp in first stream. No, that doesn't happen. What can happen, however, is that presentation times - as seen by clients - may change abruptly shortly after a stream starts to be received. This is explained in the FAQ (which you were asked to read before posting to the mailing list :-) >What is reason for base timestamp use randomaly value and not real >time stamp, created by gettimeofday()??? Because the RTP timestamp field is only 32 bits, which does not - by itself - have enough resolution. Instead, servers and clients use 64-bit "presentation times" (seconds+microseconds), which are aligned with the 'wall clock' time generated by "gettimeofday()". This is explained in the RTP/RTCP specification (RFC 3550). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From maratshch at gmail.com Tue Nov 9 02:15:54 2010 From: maratshch at gmail.com (Marat Shchuchinsky) Date: Tue, 9 Nov 2010 12:15:54 +0200 Subject: [Live-devel] RTP timestamp changes when second client connected to same stream. In-Reply-To: References: Message-ID: Dear Mr. Ross Finlayson! I'm very glad for your detail explanation, but RTP timestamp is really changed. I print timestamp value into MultiFramedRTPSink::setTimestamp() after call of convertToRTPTimestamp(). Saw that printed value "jumped" once after the second instance of VLC player connected to same RTP stream. Watch of stream into WireShark get me same result. I use live555 version from 2007 year, distributed by Appro Technology(c) with wis-streamer. Thank you very much again. On Tue, Nov 9, 2010 at 10:28 AM, Ross Finlayson wrote: > The conversion from presentation time to RTP timestamp (in the server > code), and from RTP timestamp to presentation time (in the client code) > happens automatically, and is not something that you should concern yourself > with. As a (server or client) developer, you need concern yourself only > with presentation times. > > > > When secondary client connected to same stream I saw "jump" into RTP >> timestamp in first stream. >> > > No, that doesn't happen. What can happen, however, is that presentation > times - as seen by clients - may change abruptly shortly after a stream > starts to be received. This is explained in the FAQ (which you were asked > to read before posting to the mailing list :-) > > > > What is reason for base timestamp use randomaly value and not real time >> stamp, created by gettimeofday()??? >> > > Because the RTP timestamp field is only 32 bits, which does not - by itself > - have enough resolution. Instead, servers and clients use 64-bit > "presentation times" (seconds+microseconds), which are aligned with the > 'wall clock' time generated by "gettimeofday()". > > This is explained in the RTP/RTCP specification (RFC 3550). > > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 9 02:25:44 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Nov 2010 02:25:44 -0800 Subject: [Live-devel] RTP timestamp changes when second client connected to same stream. In-Reply-To: References: Message-ID: >I use live555 version from 2007 year, distributed by >Appro Technology(c) with wis-streamer. Sorry, but absolutely no support is given for old versions of the software. (And for the second (and last) time: You should be looking only at "presentation times", not "RTP timestamps". Our software converts presentation times to/from RTP timestamps automatically.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From matteo.pampolini at elsagdatamat.com Tue Nov 9 04:52:43 2010 From: matteo.pampolini at elsagdatamat.com (Pampolini Matteo) Date: Tue, 09 Nov 2010 13:52:43 +0100 Subject: [Live-devel] Send/receive MPEG2 TS streams without RTP encapsulation In-Reply-To: References: <4CD81FEE.6030802@elsagdatamat.com> Message-ID: <4CD9441B.5010007@elsagdatamat.com> Hi Ross, many thanks for your quick feedback. Currently I'm using Kasenna MediaBase RTSP server, but sigh, my evaluation license has expired few days ago and I'm waiting for instructions on how to renew it! So at the moment I cannot tell you what the server answers, but if you have experience on MediaBase I guess you know it well. Regards, Matteo On 11/09/2010 12:01 AM, Ross Finlayson wrote: >> I'm developing a Live555-based client application that has to connect >> to a >> server that sends MPEG2 TS streams without RTP encapsulation (directly >> over >> UDP): is there a way to pass some configuration flag or similar to >> Live555 >> classes to avoid getting data through RTP? > > It's the server that decides what kind of stream it wants to send. I.e., > the server's SDP description for the stream - that it returns in > response to the client's RTSP "DESCRIBE" command - will describe whether > or not the stream is sent via raw UDP, or via RTP. > > Unfortunately, however, there's no standard for how a raw UDP stream is > described in SDP (in part because such streams are a bad idea; e.g., > with such a stream, you can't recover from misordered packets). > Nonetheless, our client code understands some common ways that a server > might describe such a stream, and handles it accordingly. > > So, please let us know how your server describes such a stream. E.g., > please send us the output from running "openRTSP" to try to play/record > the stream. From davidcailliere at voila.fr Tue Nov 9 10:20:35 2010 From: davidcailliere at voila.fr (david cailliere) Date: Tue, 9 Nov 2010 19:20:35 +0100 (CET) Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP Message-ID: <11228407.1048371289326835676.JavaMail.www@wwinf4620> Dear All, When launching the following command OpenRTSP.exe -Q -d 15 , the OpenRTSP application get crash every time I get the following protocol sequence at the end of the streaming session client -> serveur RSTP TEARDOWN serveur -> client RTP serveur -> client RTP serveur -> client RTCP GOODBYE serveur -> client RTCP GOODBYE crash serveur -> client RTSP TEARDOWN REPLY OK These test are performed with the last release of OpenRTSP (2010.11.04) without any modification in the source code. It looks like the application does not stand for handling RTCP GOOBYE packet after calling the shutdown function (from the sessionAfterPlaying function). In the spec RFC 3550, I didn't found anything relevant about the ability for the sever to send RTCP GOODBYE after receiving the RSTP TEARDOWN packet. Anyway is there a way to avoid OpenRTSP crashing in such a case. Thanks in advance for your help Regards David ____________________________________________________ D?couvez nos 10 astuces sant? pour ne pas tomber malade cet hiver sur http://actu.voila.fr/evenementiel/sante-bien-etre-2010-2011/ From finlayson at live555.com Tue Nov 9 11:14:36 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Nov 2010 11:14:36 -0800 Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP In-Reply-To: <11228407.1048371289326835676.JavaMail.www@wwinf4620> References: <11228407.1048371289326835676.JavaMail.www@wwinf4620> Message-ID: Thanks for the report. Does the crash still happen if you omit the "-Q" option? Can you post a (publically-accessible) "rtsp://" URL of a stream that illustrates the problem? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From davidcailliere at voila.fr Tue Nov 9 14:40:53 2010 From: davidcailliere at voila.fr (david cailliere) Date: Tue, 9 Nov 2010 23:40:53 +0100 (CET) Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP Message-ID: <20760035.2277511289342453094.JavaMail.www@wwinf4605> Dear Ross, > Does the crash still happen if you omit the "-Q" option? I need to check that. I'll give you some feedback soon. > Can you post a (publically-accessible) "rtsp://" URL of a stream that illustrates the problem? Unfortunately, the streaming server is not publically-accessible. I can give you a capture file and the log file with debug data for investigation Regards, David > Message du 09/11/10 ? 20h36 > De : "Ross Finlayson" > A : "LIVE555 Streaming Media - development & use" > Copie ? : > Objet : Re: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP > > > Thanks for the report. > > Does the crash still happen if you omit the "-Q" option? > > Can you post a (publically-accessible) "rtsp://" URL of a stream that > illustrates the problem? > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > ____________________________________________________ D?couvez nos 10 astuces sant? pour ne pas tomber malade cet hiver sur http://actu.voila.fr/evenementiel/sante-bien-etre-2010-2011/ From finlayson at live555.com Tue Nov 9 18:23:12 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Nov 2010 18:23:12 -0800 Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP In-Reply-To: <20760035.2277511289342453094.JavaMail.www@wwinf4605> References: <20760035.2277511289342453094.JavaMail.www@wwinf4605> Message-ID: OK, I think I figured out the problem, and have installed a new version (2010.11.10) of the "LIVE555 Streaming Media" code that should, I think, fix it. (Note that this was a problem only with the "openRTSP" application, not with our RTSP client code in general.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mojtaba.nouri at gmail.com Wed Nov 10 00:17:55 2010 From: mojtaba.nouri at gmail.com (Mojtaba Nouri) Date: Wed, 10 Nov 2010 11:47:55 +0330 Subject: [Live-devel] stream multiple ts files Message-ID: Hi. I need to stream multiple ts files, each having its own index file, as a single stream. I know there is ByteStreamMultigFile class, but I am not sure how to couple index and ts files. I hope you can help me. Mojtaba -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe at lemoine-fr.com Wed Nov 10 01:29:45 2010 From: christophe at lemoine-fr.com (Christophe Lemoine) Date: Wed, 10 Nov 2010 11:29:45 +0200 Subject: [Live-devel] Streaming H264: quality issue Message-ID: <4CDA6609.20002@lemoine-fr.com> Hi, I'm trying to stream H264 video but I have some quality issues and I cannot find a way to solve it. Maybe some experienced developers can help me on that.... I generate a TS file containing H264 video and ac3 audi using ffmpeg: ffmpeg -i video.mkv -vbsf h264_mp4toannexb -ab 384k -vcodec copy -acodec ac3 video.ts Result: Input #0, mpegts, from 'video.ts': Duration: 00:01:59.99, start: 1.400000, bitrate: 9680 kb/s Program 1 Service01 Metadata: name : Service01 provider_name : FFmpeg Stream #0.0[0x100]: Video: h264, yuv420p, 1920x800, 23.98 fps, 30k tbr, 90k tbn, 47.95 tbc Stream #0.1[0x101](fin): Audio: ac3, 48000 Hz, 5.1, s16, 384 kb/s I then stream video.ts using live555, and play it using vlc. Although I do get something on VLC, the quality is very bad (I get good quality with MPEG2 videos). CPU on the server remains normal (almost idle), CPU usage on the client is quite high, but, if I play the video.ts file directly in VLC (no streaming), I get good quality, so I guess that my client can decode the video without any issue. Maybe using a TS container is not very optimal for streaming H264 ? I noticed that live555 also support m4e files, but could not find a way to generate such a file. Here are the quality results from openRTSP: begin_QOS_statistics subsession video/MP2T num_packets_received 109834 num_packets_lost 194 elapsed_measurement_time 120.000112 kBytes_received_total 144541.544000 measurement_sampling_interval_ms 1000 kbits_per_second_min 315.835894 kbits_per_second_ave 9636.093940 kbits_per_second_max 29382.884045 packet_loss_percentage_min 0.000000 packet_loss_percentage_ave 0.176319 packet_loss_percentage_max 6.666667 inter_packet_gap_ms_min 0.013000 inter_packet_gap_ms_ave 1.091214 inter_packet_gap_ms_max 118.313000 end_QOS_statistics Thanks for your help Christophe From belloni at imavis.com Wed Nov 10 03:22:29 2010 From: belloni at imavis.com (Cristiano Belloni) Date: Wed, 10 Nov 2010 12:22:29 +0100 Subject: [Live-devel] JPEGVideoRTPSink and Restart markers In-Reply-To: References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com> <4CC7DA07.7080202@imavis.com> <852F8B82-F6F7-409B-8984-58EDC5305D64@j2kvideo.com> Message-ID: <4CDA8075.20907@imavis.com> Il 02/11/2010 14:07, Ross Finlayson ha scritto: >> Ross, thanks for the new release. I have tried it and is not working >> here. > > Please let me know if you find any bugs in the latest release, because > it is the only version for which support will be given. (Remember, You > Have Complete Source Code.) Dear Ross, I seem to experience the very same double-free corruption problem I already reported with the latest version of your code (live.2010.11.04), streaming mjpeg on rtp. For convenience, I report the problem again here: The double-alloc issue seems to be triggered when I add a 4-byte special header for the RestartMarkerHeader in JPEGRSTVideoRTPSink class. This calls setSpecialHeaderBytes(), that calls OutPacketBuffer::insert(). In JPEGRSTVideoRTPSink::specialHeaderSize, I also set headerSize += 4 at the end, assuming that restart markers are present. So far so good, but, investigating, I found that, somehow, this breaks MultiFramedRTPSink. In particular, this seems to invalidate the assumptions made in this piece of code: if (fOutBuf->haveOverflowData() && fOutBuf->totalBytesAvailable() > fOutBuf->totalBufferSize()/2) { // Efficiency hack: Reset the packet start pointer to just in front of // the overflow data (allowing for the RTP header and special headers), // so that we probably don't have to "memmove()" the overflow data // into place when building the next packet: unsigned newPacketStart = fOutBuf->curPacketSize() - (rtpHeaderSize + fSpecialHeaderSize + frameSpecificHeaderSize()); fOutBuf->adjustPacketStart(newPacketStart); } The first time it's invoked, the efficiency hack sets newPacketStart to 4294939175 (!), and fOutBuf is adjusted to this value. This corrupts the fOutBuf OutPacketBuffer. When the buffer is deleted, it tries to dealloc 4 gigabytes, and glibc gets very angry. Solution: commenting out the efficiency hack seems to make the whole thing work (but the CPU toll without the efficiency hack is too high). Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Nov 10 07:32:31 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Nov 2010 07:32:31 -0800 Subject: [Live-devel] JPEGVideoRTPSink and Restart markers In-Reply-To: <4CDA8075.20907@imavis.com> References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com> <4CC7DA07.7080202@imavis.com> <852F8B82-F6F7-409B-8984-58EDC5305D64@j2kvideo.com> <4CDA8075.20907@imavis.com> Message-ID: >I seem to experience the very same double-free corruption problem I >already reported with the latest version of your code >(live.2010.11.04), streaming mjpeg on rtp. > >For convenience, I report the problem again here: > >The double-alloc issue seems to be triggered when I add a 4-byte >special header for the RestartMarkerHeader in JPEGRSTVideoRTPSink >class. Why are you still doing this yourself?? *We* are now adding the 4-byte special header ourselves, in "JPEGVideoRTPSink". There is no longer any need for you to subclass this code. That was the whole point of the changes that we made in 2010.10.28. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Nov 10 07:34:40 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Nov 2010 07:34:40 -0800 Subject: [Live-devel] stream multiple ts files In-Reply-To: References: Message-ID: >I need to stream multiple ts files, each having its own index file, >as a single stream. >I know there is ByteStreamMultigFile class, but I am not sure how to >couple index and ts files. You can't do this. Both the index file and the file that it's indexing needs to be a single file. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Nov 10 07:39:35 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Nov 2010 07:39:35 -0800 Subject: [Live-devel] Streaming H264: quality issue In-Reply-To: <4CDA6609.20002@lemoine-fr.com> References: <4CDA6609.20002@lemoine-fr.com> Message-ID: >I then stream video.ts using live555, and play it using vlc. >Although I do get something on VLC, the quality is very bad (I get >good quality with MPEG2 videos). What happens if you just *play* your "video.ts" file using VLC - i.e., just play it as a local file, rather than streaming it? If you get the same video quaility problems when you (try to) play the file locally, then the problem is with VLC, not our code, and you'll need to ask about it on a VLC mailing list. If, however, your problem occurs *only* when you stream your file to VLC, then the problem is either (i) your network does not have enough bandwidth, or (more likely) (ii) there is a problem with the PCR timestamps in your TS file. >Maybe using a TS container is not very optimal for streaming H264 ? >I noticed that live555 also support m4e files, but could not find a >way to generate such a file. Irrelevant. ".m4e" files are for (regular) MPEG-4 Elementary Stream Video, not H.264 video. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From belloni at imavis.com Wed Nov 10 08:03:40 2010 From: belloni at imavis.com (Cristiano Belloni) Date: Wed, 10 Nov 2010 17:03:40 +0100 Subject: [Live-devel] JPEGVideoRTPSink and Restart markers In-Reply-To: References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com> <4CC7DA07.7080202@imavis.com> <852F8B82-F6F7-409B-8984-58EDC5305D64@j2kvideo.com> <4CDA8075.20907@imavis.com> Message-ID: <4CDAC25C.9000005@imavis.com> Il 10/11/2010 16:32, Ross Finlayson ha scritto: >> I seem to experience the very same double-free corruption problem I >> already reported with the latest version of your code >> (live.2010.11.04), streaming mjpeg on rtp. >> >> For convenience, I report the problem again here: >> >> The double-alloc issue seems to be triggered when I add a 4-byte >> special header for the RestartMarkerHeader in JPEGRSTVideoRTPSink class. > > Why are you still doing this yourself?? *We* are now adding the > 4-byte special header ourselves, in "JPEGVideoRTPSink". There is no > longer any need for you to subclass this code. That was the whole > point of the changes that we made in 2010.10.28. Dear Ross, My bad, the problem is present, but the report I copied was obsolete. The problem now is that, even if I *don't* subclass JPEGVideoRTPSink anymore (I even wiped the files of the subclasses from the HD), and use instead liveMedia's JPEGVideoRTPSink class, the double-free corruption problem is still here, as it was before commenting out the efficiency hack. This means that, at least for me, even your post-2010.10.28 code has problems with the efficiency hack (or so it seems). Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe at lemoine-fr.com Wed Nov 10 08:01:27 2010 From: christophe at lemoine-fr.com (Christophe Lemoine) Date: Wed, 10 Nov 2010 18:01:27 +0200 Subject: [Live-devel] Streaming H264: quality issue In-Reply-To: References: <4CDA6609.20002@lemoine-fr.com> Message-ID: <4CDAC1D7.8060103@lemoine-fr.com> Hi, As I mentioned, if I play the file directly in VLC the quality is perfect, so VLC is probably not the issue. Network should not be an issue as I either stream on the same PC where I play the video, or from a server connected on a local 100M switch. Is there a way I can check the PCR timestamps ? Maybe I need to give some additional parameters to ffmpeg when I generate the TS file ? Thanks for your help Christophe On 11/10/2010 05:39 PM, Ross Finlayson wrote: >> I then stream video.ts using live555, and play it using vlc. Although >> I do get something on VLC, the quality is very bad (I get good >> quality with MPEG2 videos). > > What happens if you just *play* your "video.ts" file using VLC - i.e., > just play it as a local file, rather than streaming it? If you get > the same video quaility problems when you (try to) play the file > locally, then the problem is with VLC, not our code, and you'll need > to ask about it on a VLC mailing list. > > If, however, your problem occurs *only* when you stream your file to > VLC, then the problem is either (i) your network does not have enough > bandwidth, or (more likely) (ii) there is a problem with the PCR > timestamps in your TS file. > >> Maybe using a TS container is not very optimal for streaming H264 ? I >> noticed that live555 also support m4e files, but could not find a way >> to generate such a file. > > Irrelevant. ".m4e" files are for (regular) MPEG-4 Elementary Stream > Video, not H.264 video. From finlayson at live555.com Wed Nov 10 08:50:48 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Nov 2010 08:50:48 -0800 Subject: [Live-devel] JPEGVideoRTPSink and Restart markers In-Reply-To: <4CDAC25C.9000005@imavis.com> References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com> <4CC7DA07.7080202@imavis.com> <852F8B82-F6F7-409B-8984-58EDC5305D64@j2kvideo.com> <4CDA8075.20907@imavis.com> <4CDAC25C.9000005@imavis.com> Message-ID: >The problem now is that, even if I *don't* subclass JPEGVideoRTPSink >anymore (I even wiped the files of the subclasses from the HD), and >use instead liveMedia's JPEGVideoRTPSink class, the double-free >corruption problem is still here, as it was before commenting out >the efficiency hack. OK. Unfortunately I'm having a hard time seeing how/why this problem is occurring, so could you please add the following debugging statement: fprintf(stderr, "DEBUG: %d = %d - (%d + %d + %d), tbs %d, tba %d, ods %d\n", newPacketStart, fOutBuf->curPacketSize(), rtpHeaderSize, fSpecialHeaderSize, frameSpecificHeaderSize(), fOutBuf->totalBufferSize(), fOutBuf->totalBytesAvailable(), fOutBuf->overflowDataSize()); just after the statement unsigned newPacketStart = fOutBuf->curPacketSize() - (rtpHeaderSize + fSpecialHeaderSize + frameSpecificHeaderSize()); and let us know the output (when the problem occurs). Thanks. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From belloni at imavis.com Wed Nov 10 09:43:21 2010 From: belloni at imavis.com (Cristiano Belloni) Date: Wed, 10 Nov 2010 18:43:21 +0100 Subject: [Live-devel] JPEGVideoRTPSink and Restart markers In-Reply-To: References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com> <4CC7DA07.7080202@imavis.com> <852F8B82-F6F7-409B-8984-58EDC5305D64@j2kvideo.com> <4CDA8075.20907@imavis.com> <4CDAC25C.9000005@imavis.com> Message-ID: <4CDAD9B9.6000401@imavis.com> Il 10/11/2010 17:50, Ross Finlayson ha scritto: > fprintf(stderr, "DEBUG: %d = %d - (%d + %d + %d), tbs %d, tba %d, ods > %d\n", newPacketStart, fOutBuf->curPacketSize(), rtpHeaderSize, > fSpecialHeaderSize, frameSpecificHeaderSize(), > fOutBuf->totalBufferSize(), fOutBuf->totalBytesAvailable(), > fOutBuf->overflowDataSize()); Dear Ross, What I get after crashing is: DEBUG: 1424 = 1448 - (12 + 12 + 0), tbs 1000568, tba 962228, ods 35806 (I know it seems ok, but I also tried to comment out the Efficiency Hack from the latest library, and everything works fine. When I put it back, library crashes). As additional info, here's the traceback of the crash: *** glibc detected *** ./rtspServer: munmap_chunk(): invalid pointer: 0x406e5008 *** ======= Backtrace: ========= /lib/libc.so.6[0x40231f3c] ./rtspServer(_ZN15OutPacketBufferD1Ev+0x18)[0x5db3c] ./rtspServer(_ZN18MultiFramedRTPSinkD2Ev+0x3c)[0x6a10c] ./rtspServer(_ZN12VideoRTPSinkD2Ev+0x14)[0x6a410] ./rtspServer(_ZN16JPEGVideoRTPSinkD2Ev+0x14)[0x61c0c] ./rtspServer(_ZN20LiveJPEGVideoRTPSinkD0Ev+0x2c)[0x45e80] ./rtspServer(_ZN16MediaLookupTable6removeEPKc+0x60)[0x47584] ./rtspServer(_ZN11StreamState7reclaimEv+0x24)[0x7cfa8] ./rtspServer(_ZN11StreamStateD0Ev+0x14)[0x7d2cc] ./rtspServer(_ZN29OnDemandServerMediaSubsession12deleteStreamEjRPv+0x78)[0x7d8a0] ./rtspServer(_ZN10RTSPServer17RTSPClientSession19reclaimStreamStatesEv+0x60)[0x6d458] ./rtspServer(_ZN10RTSPServer17RTSPClientSessionD2Ev+0xbc)[0x70b8c] ./rtspServer(_ZN15LimitRTSPServer22LimitRTSPClientSessionD0Ev+0x44)[0x46de8] ./rtspServer(_ZN10RTSPServer17RTSPClientSession18handleRequestBytesEi+0x13c)[0x6e380] ./rtspServer(_ZN10RTSPServer17RTSPClientSession23incomingRequestHandler1Ev+0x48)[0x6e7f4] ./rtspServer(_ZN18BasicTaskScheduler10SingleStepEj+0x1ec)[0x8fcac] ./rtspServer(_ZN19BasicTaskScheduler011doEventLoopEPc+0x20)[0x8f02c] ./rtspServer(_Z8mainLoopP16UsageEnvironmentjjPc+0x614)[0x44930] ./rtspServer(main+0x3c)[0x41030] /lib/libc.so.6(__libc_start_main+0x120)[0x401ddfd4] It can happen on the munmap_chunk() or wit a double dealloc, but the crash always come in the OutPacketBuffer destructor, presumably after a free() is made. Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Nov 10 11:57:16 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Nov 2010 11:57:16 -0800 Subject: [Live-devel] JPEGVideoRTPSink and Restart markers In-Reply-To: <4CDAD9B9.6000401@imavis.com> References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com> <4CC7DA07.7080202@imavis.com> <852F8B82-F6F7-409B-8984-58EDC5305D64@j2kvideo.com> <4CDA8075.20907@imavis.com> <4CDAC25C.9000005@imavis.com> <4CDAD9B9.6000401@imavis.com> Message-ID: >Il 10/11/2010 17:50, Ross Finlayson ha scritto: > >>fprintf(stderr, "DEBUG: %d = %d - (%d + %d + %d), tbs %d, tba %d, >>ods %d\n", newPacketStart, fOutBuf->curPacketSize(), rtpHeaderSize, >>fSpecialHeaderSize, frameSpecificHeaderSize(), >>fOutBuf->totalBufferSize(), fOutBuf->totalBytesAvailable(), >>fOutBuf->overflowDataSize()); >> >Dear Ross, >What I get after crashing is: > > DEBUG: 1424 = 1448 - (12 + 12 + 0), tbs 1000568, tba 962228, ods 35806 > >(I know it seems ok Yes, it is, which means that your previous description of the problem was wrong. I suspect that the 'efficiency hack' is not the cause of the problem, and that disabling it doesn't fix the problem, but just masks it somehow. (I.e., it still exists, but just doesn't become obvious.) >As additional info, here's the traceback of the crash: > >*** glibc detected *** ./rtspServer: munmap_chunk(): invalid >pointer: 0x406e5008 *** >======= Backtrace: ========= >/lib/libc.so.6[0x40231f3c] >./rtspServer(_ZN15OutPacketBufferD1Ev+0x18)[0x5db3c] >./rtspServer(_ZN18MultiFramedRTPSinkD2Ev+0x3c)[0x6a10c] >./rtspServer(_ZN12VideoRTPSinkD2Ev+0x14)[0x6a410] >./rtspServer(_ZN16JPEGVideoRTPSinkD2Ev+0x14)[0x61c0c] >./rtspServer(_ZN20LiveJPEGVideoRTPSinkD0Ev+0x2c)[0x45e80] What is "LiveJPEGVideoRTPSink"? I told you that you no longer needed to subclass "JPEGVideoRTPSink". I meant it. Because the problem seems to occur only when you add your own custom code, I'm not going to be able to help you fix it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From davidcailliere at voila.fr Wed Nov 10 14:31:02 2010 From: davidcailliere at voila.fr (david cailliere) Date: Wed, 10 Nov 2010 23:31:02 +0100 (CET) Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP Message-ID: <26321761.2380541289428262190.JavaMail.www@wwinf4607> Dear Ross, Thanks for your reactivity. Unfortunately the new version (2010.11.10) does not solve for the issue and not using the -Q option does not make any change. After calling shutdown and then subsessionByeHandler functions, OpenRTSP gets in trouble when trying to use the clientData pointer in FileSink::afterGettingFrame. It looks like to be no longer valid and the call for sink->afterGettingFrame1 causes a read exception error. Regards, David > Message du 10/11/10 ? 03h42 > De : "Ross Finlayson" > A : "LIVE555 Streaming Media - development & use" > Copie ? : > Objet : Re: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP > > > OK, I think I figured out the problem, and have installed a new > version (2010.11.10) of the "LIVE555 Streaming Media" code that > should, I think, fix it. (Note that this was a problem only with the > "openRTSP" application, not with our RTSP client code in general.) > -- > > 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?couvez nos 10 astuces sant? pour ne pas tomber malade cet hiver sur http://actu.voila.fr/evenementiel/sante-bien-etre-2010-2011/ From finlayson at live555.com Thu Nov 11 01:03:20 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Nov 2010 01:03:20 -0800 Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP In-Reply-To: <26321761.2380541289428262190.JavaMail.www@wwinf4607> References: <26321761.2380541289428262190.JavaMail.www@wwinf4607> Message-ID: >Thanks for your reactivity. Unfortunately the new version >(2010.11.10) does not solve for the issue That's strange. Right now I can't see how the problem could still be happening, so without a publically-accessible stream that illustrates the problem, I'm not going to be able to fix it right now. Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From belloni at imavis.com Fri Nov 12 00:48:15 2010 From: belloni at imavis.com (Cristiano Belloni) Date: Fri, 12 Nov 2010 09:48:15 +0100 Subject: [Live-devel] JPEGVideoRTPSink and Restart markers In-Reply-To: References: <148BCFDE-68FA-4B12-822F-9D87FEC2BBE7@j2kvideo.com> <4CC7DA07.7080202@imavis.com> <852F8B82-F6F7-409B-8984-58EDC5305D64@j2kvideo.com> <4CDA8075.20907@imavis.com> <4CDAC25C.9000005@imavis.com> <4CDAD9B9.6000401@imavis.com> Message-ID: <4CDCFF4F.3060809@imavis.com> Il 10/11/2010 20:57, Ross Finlayson ha scritto: >> Il 10/11/2010 17:50, Ross Finlayson ha scritto: >> >>> fprintf(stderr, "DEBUG: %d = %d - (%d + %d + %d), tbs %d, tba %d, >>> ods %d\n", newPacketStart, fOutBuf->curPacketSize(), rtpHeaderSize, >>> fSpecialHeaderSize, frameSpecificHeaderSize(), >>> fOutBuf->totalBufferSize(), fOutBuf->totalBytesAvailable(), >>> fOutBuf->overflowDataSize()); >>> >> Dear Ross, >> What I get after crashing is: >> >> DEBUG: 1424 = 1448 - (12 + 12 + 0), tbs 1000568, tba 962228, ods 35806 >> >> (I know it seems ok > > Yes, it is, which means that your previous description of the problem > was wrong. > > I suspect that the 'efficiency hack' is not the cause of the problem, > and that disabling it doesn't fix the problem, but just masks it > somehow. (I.e., it still exists, but just doesn't become obvious.) > > >> As additional info, here's the traceback of the crash: >> >> *** glibc detected *** ./rtspServer: munmap_chunk(): invalid pointer: >> 0x406e5008 *** >> ======= Backtrace: ========= >> /lib/libc.so.6[0x40231f3c] >> ./rtspServer(_ZN15OutPacketBufferD1Ev+0x18)[0x5db3c] >> ./rtspServer(_ZN18MultiFramedRTPSinkD2Ev+0x3c)[0x6a10c] >> ./rtspServer(_ZN12VideoRTPSinkD2Ev+0x14)[0x6a410] >> ./rtspServer(_ZN16JPEGVideoRTPSinkD2Ev+0x14)[0x61c0c] >> ./rtspServer(_ZN20LiveJPEGVideoRTPSinkD0Ev+0x2c)[0x45e80] > > What is "LiveJPEGVideoRTPSink"? I told you that you no longer needed > to subclass "JPEGVideoRTPSink". I meant it. > > Because the problem seems to occur only when you add your own custom > code, I'm not going to be able to help you fix it. Dear Ross, LiveJPEGVideoRTPSink adds only a parameters struct to the class members; it does nothing else. Anyway, I'm gonna remove it and investigate further. Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Nov 14 22:15:17 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 14 Nov 2010 22:15:17 -0800 Subject: [Live-devel] Live555 Media Server .Handle PAUSE. In-Reply-To: References: Message-ID: >is there any way to handle PAUSE request in the mediaserver. Our RTSP server implementation already handles the RTSP "PAUSE" command. >my custemer is a hardware decoder developer. >and sometimes he wants to hold on the decode process. >and he doesn't have enough memory to cache so many frames. >so he wants to send a PAUSE request to the Server. >but the default Meidaserver handler will send GoodBye to the client. That's not true at all. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Nov 15 14:11:59 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Nov 2010 14:11:59 -0800 Subject: [Live-devel] Question about a resizing filter In-Reply-To: References: Message-ID: >I don't know of anything like that in Live555. I think you could >probably kludge something like that into Live555's model It wouldn't be a 'kludge' at all; it would be a natural part of the LIVE555 application model (using a subclass of "FramedFilter".) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Nov 15 16:20:41 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Nov 2010 16:20:41 -0800 Subject: [Live-devel] Question about a resizing filter In-Reply-To: References: Message-ID: >I view adding a morphological filter to my network streaming library >as a rather substantial kludge, so I'll chalk this up to "difference >of opinion." Well maybe. However, because I was the person who designed the library and its architecture, some opinions are more valuable than others :-) "Media processing" (which includes transcoding) is exactly the sort of thing I had in mind when I designed this library. Although the code that we ship focuses on network I/O - and doesn't include any codec software - there's no reason why you couldn't use a 3rd-party library (e.g., FFMPEG or Intel IPP) to help implement a decoding and/or encoding filter. (The internal implementation of a particular filter could even be multi-threaded (to exploit multiple cores) if you wished, even though the filter chain as a whole remains single-threaded.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Nov 15 18:38:33 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Nov 2010 18:38:33 -0800 Subject: [Live-devel] inherit from RTSPClientSession In-Reply-To: References: Message-ID: >this is your RTSPClientSession definition > >class RTSPServer: public Medium { >protected: > class RTSPClientSession { >}; >}; > >and how can i inherit a subclass from RTSPClientSession in vc6. > >class MyRTSPServer : public RTSPServer >{ >public: >class MyRTSPClientSession : public RTSPClientSession >{ >}; >}; Because both "RTSPServer" and "RTSPClientSession" have (non-default) constructors, you also have to define constructors for their subclasses. The following is legal C++: class MyRTSPServer : public RTSPServer {public: MyRTSPServer(); class MyRTSPClientSession : public RTSPClientSession { public: MyRTSPClientSession(); // redefined virtual function: virtual RTSPClientSession* createNewClientSession(unsigned sessionId, int clientSocket, struct sockaddr_in clientAddr); }; }; Of course, you will presumably want to add parameters to the "MyRTSPServer" and "MyRTSPClientSession" constructors. Note that you'll need to redefine the virtual function "createNewClientSession()" in your "MyRTSPClientSession" subclass (as noted in the code above), and have your (re)implementation of this virtual function return an object of type "MyRTSPClientSession". Also, because "MyRTSPServer" objects (just like "RTSPServer" objects) should always be allocated on the heap (rather than on the stack), you might also want to make the "MyRTSPServer" constructor "protected:", and define a static "createNew()" function for creating these objects. (This is optional, however; instead, your application code could just do "new myRTSPServer";) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Nov 15 20:25:02 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Nov 2010 20:25:02 -0800 Subject: [Live-devel] inherit from RTSPClientSession In-Reply-To: References: Message-ID: >i write the code like follow in vc6: >class MyRTSPServer : public RTSPServer {public: > MyRTSPServer(); > class MyRTSPClientSession : public RTSPClientSession { > public: > MyRTSPClientSession(); > > // redefined virtual function: > virtual RTSPClientSession* createNewClientSession(unsigned >sessionId, int clientSocket, struct sockaddr_in clientAddr); > }; >}; >but the compile error comes out.and say >D:\develop\develop\InterfaceRTSPServer\src\DynamicRTSPServer.h(69) : >error C2504: 'RTSPClientSession' : base class undefined Then try writing class MyRTSPClientSession : public RTSPServer::RTSPClientSession { instead of class MyRTSPClientSession : public RTSPClientSession { Some compilers might be picky about this... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Nov 15 21:09:40 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Nov 2010 21:09:40 -0800 Subject: [Live-devel] inherit from RTSPClientSession In-Reply-To: References: Message-ID: >this can't help.it said i can't access protected member. You have to be more specific. *Which* protected member?? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From davidcailliere at voila.fr Tue Nov 16 15:49:17 2010 From: davidcailliere at voila.fr (david cailliere) Date: Wed, 17 Nov 2010 00:49:17 +0100 (CET) Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP Message-ID: <9675930.2747511289951357880.JavaMail.www@wwinf4630> Dear Ross, Actually you have solved for the recursive call to "shutdown()" issued when calling "subsessionByeHandler()" function but it seems it is not enough. The "subsessionByeHandler()" close some media subsession's stream with the following line "Medium::close(subsession->sink)", which causes some medium object to be deleted. But this medium object is still needed and used later in the process (when calling fDelayQueue.handleAlarm(); into BasicTaskScheduler::SingleStep()). Roughly speaking, it look likes there are still some remaining RTP audio packets to be processed after receiving the RTCP bye packet for the audio stream. Therefore some object are deleted too early. Hoping this will help you understanding my trouble. Regards, David > Message du 11/11/10 ? 10h23 > De : "Ross Finlayson" > A : "LIVE555 Streaming Media - development & use" > Copie ? : > Objet : Re: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP > > > >Thanks for your reactivity. Unfortunately the new version > >(2010.11.10) does not solve for the issue > > That's strange. Right now I can't see how the problem could still be > happening, so without a publically-accessible stream that illustrates > the problem, I'm not going to be able to fix it right now. 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 > > ____________________________________________________ D?couvez nos 10 astuces sant? pour ne pas tomber malade cet hiver sur http://actu.voila.fr/evenementiel/sante-bien-etre-2010-2011/ From finlayson at live555.com Tue Nov 16 18:07:39 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Nov 2010 18:07:39 -0800 Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP In-Reply-To: <9675930.2747511289951357880.JavaMail.www@wwinf4630> References: <9675930.2747511289951357880.JavaMail.www@wwinf4630> Message-ID: >Actually you have solved for the recursive call to "shutdown()" >issued when calling "subsessionByeHandler()" function but it seems >it is not enough. >The "subsessionByeHandler()" close some media subsession's stream >with the following line "Medium::close(subsession->sink)", which >causes some medium object to be deleted. But this medium object is >still needed and used later in the process (when calling >fDelayQueue.handleAlarm(); "handleAlarm()" is not supposed to get called again, because "shutdown()" unschedules all alarm handlers. >Roughly speaking, it look likes there are still some remaining RTP >audio packets to be processed after receiving the RTCP bye packet >for the audio stream. That also shouldn't matter, because the shutdown code should also be disabling the reception of new network packets. Once again, unless you've modified the source code (in which case I can't help you), I don't yet see how this problem can be happening. I'm going to need a publically-accessible stream that illustrates the problem -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Nov 17 00:07:24 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Nov 2010 00:07:24 -0800 Subject: [Live-devel] Slight authentication change In-Reply-To: References: Message-ID: >We updated the "UserAuthenticationDatabase" used in the RTSP server >to have a "requireAuthentication" method that can be overridden in a >derived class. We use it so that if default credentials are in use, >we don't require authentication. > >Basically, this allows implementations to turn authentication on and >off at will while the server is running. Unless implementations >override requireAuthentication, the behavior is identical to the >previous code. > >It's a pretty simple change so hopefully it's good enough for inclusion. Yes. In fact, I can think of another way to do this that's even simpler, yet more general: Add a new member function UserAuthenticationDatabase* RTSPServer::setAuthenticationDatabase(UserAuthenticationDatabase* newDB); This would change the server's authentication database, and return the existing one (perhaps NULL). Then, you could turn off authentication simply by doing: UserAuthenticationDatabase* oldDB = myServer->setAuthenticationDatabase(NULL); and turn it back on by doing: myServer->setAuthenticationDatabase(oldDB); This also has the benefit of not requiring an additional check in the server; the existing check against NULL is sufficient. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Nov 17 12:37:57 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Nov 2010 12:37:57 -0800 Subject: [Live-devel] Slight authentication change In-Reply-To: References: Message-ID: >That would work. But it might also lead to crashing issues if >people call setAuthenticationDatabase on something other than the >primary Live555 thread. (I can envision a scenario where something >calls setAuthenticationDatabase(NULL) at precisely the moment >between the NULL check and the actual authentication with the >UserAuthenticationDatabase*, which would result in dereferencing a >null pointer). And that is *precisely* why you should not be doing this. I've made it very clear (in the FAQ and elsewhere) that LIVE555 applications have a single thread of execution (using an event loop, rather than threads, for concurrency). Other threads should not access the library (except perhaps to set global variables - e.g., 'watch variables' that the event loop may use to detect 'events'). If you do otherwise, then you can't expect any support. >I know Live555 is "single threaded," so maybe you consider this >entire line of reasoning invalid, but I think there's considerable >room for error with setting the entire object to NULL. Not if you use the library properly. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Nov 17 15:59:16 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Nov 2010 15:59:16 -0800 Subject: [Live-devel] Slight authentication change In-Reply-To: References: Message-ID: I have now installed a new version (2010.11.17) of the "LIVE555 Streaming Media" code that adds a new member function RTSPServer::setAuthenticationDatabase() as described earlier. Feel free to call this if desired (from within the event loop thread, of course :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Nov 17 18:21:28 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Nov 2010 18:21:28 -0800 Subject: [Live-devel] max length of rtsp url . In-Reply-To: References: Message-ID: >what's the max length of the rtsp url in live555 media server. 200 bytes -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Nov 17 22:03:33 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Nov 2010 22:03:33 -0800 Subject: [Live-devel] max length of rtsp url . In-Reply-To: References: Message-ID: >can i change this length by overwrite RTSPClientSession? No, the way to change this length is by changing the definition of "RTSP_PARAM_STRING_MAX" in "liveMedia/include/RTSPCommon.hh". If you find a new value that works for you, then let us know, and I may change the definition in future releases of the code. >and Would you mind change RTSPClientSession from protected to public? No, not yet - because I'm not yet convinced that this is needed. >or i can't inhert from RTSPClientSession in Visual C++ 6.0. So far noone else has reported this problem. Can anyone else (preferably someone with a professional email address) confirm (or deny) that this is a problem? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Nov 21 22:53:55 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 21 Nov 2010 22:53:55 -0800 Subject: [Live-devel] rtsp server scale. In-Reply-To: References: Message-ID: >if rtsp client request scale = 0.5. > >my rtsp server must slow down the send speed by using >fDurationInMicroseconds /= m_scale; > >what other should i do.should i change the pts?and the duration? Yes. "fDurationInMicroseconds" merely tells the downstream object ("RTPSink") how often to request new data. It's the "fPresentationTime" value that tells the receiving client when to play each frame. Therefore, if you change the scale, you'll need to set the "fPresentationTime" values as appropriate. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sarroutbi at sepsa.es Wed Nov 24 02:49:45 2010 From: sarroutbi at sepsa.es (Sergio Arroutbi) Date: Wed, 24 Nov 2010 11:49:45 +0100 Subject: [Live-devel] Non loop behaviour on live555 Message-ID: <4CECEDC9.2020107@sepsa.es> Hello. I am trying to develop a program that gets the stream from an Axis cam and shows it on the screen. For some reasons, I am interested in painting via SDL with ffmpeg decoding, so as far as the program is concerned, it needs the information of each H.264 frame arriving in the stream. I have developed a parallel sink class that, instead of writing to file, keeps the frame in memory. I would like to know if there is a way to call to the event attending procedures without looping, I mean: while(1) { env->taskScheduler.eventInteration(); // Rest of my things I need could be performed here } instead of env->taskScheduler.doEventLoop() // No way of doing "intermediate actions" Thanks a lot for your help Sergio Arroutbi. From finlayson at live555.com Wed Nov 24 06:44:14 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Nov 2010 06:44:14 -0800 Subject: [Live-devel] Non loop behaviour on live555 In-Reply-To: <4CECEDC9.2020107@sepsa.es> References: <4CECEDC9.2020107@sepsa.es> Message-ID: >I am trying to develop a program that gets the stream from an Axis >cam and shows it on the screen. Have you tried VLC? (VLC uses the "LIVE555 Streaming Media" code for its RTSP/RTP client implementation.) >I would like to know if there is a way to call to the event >attending procedures without looping, I mean: > >while(1) >{ > env->taskScheduler.eventInteration(); > // Rest of my things I need could be performed here >} > >instead of > >env->taskScheduler.doEventLoop() // No way of doing "intermediate actions" No, not really. LIVE555 applications run within the event loop, so your "intermediate actions" (assuming that they use/interact with the LIVE555 code) need to be called from event handlers. If you want your "intermediate actions" to be done each time data arrives on an object, then you can simnply call them from within your data handler. Alternatively, if you want your "intermediate actions" to be done periodically, then you do this by setting up a task to be called periodically - using "TaskScheduler::scheduleDelayedTask() - and then call your "intermediate actions" from within this task. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jingke2000 at gmail.com Wed Nov 24 12:27:45 2010 From: jingke2000 at gmail.com (Ke Yu) Date: Wed, 24 Nov 2010 15:27:45 -0500 Subject: [Live-devel] RTSP unicast from circular buffer Message-ID: I'm new to the Live555 which I want to use in my project. My requirement is to stream video (H.264/AAC in TS) over the RTSP unicast. The video continuously comes in (like live) and is captured into circular buffer (either in memory or on hard disk). I check out the "testOnDemandRTSPServer" sample. But it takes in a single file. How can I do it with multiple files in a circular fashion or with circular buffer in memory? From yangzx at acejet.com.cn Wed Nov 24 20:15:01 2010 From: yangzx at acejet.com.cn (=?gb2312?B?0e7Wvs/p?=) Date: Thu, 25 Nov 2010 12:15:01 +0800 Subject: [Live-devel] use livemedia transport mpeg4streame problem References: Message-ID: <41FC1A94FE13684D8249B089C38119700F673A@mailserver-nj1.njacejet.com> HI: I use livemeida transport xvid mpeg4 video,i implement own mpeg4serverseesion class and owen devicesource class.I find I set xvid codec only use I frame,then use vlc play is good.but, if i set xvid codec use I frame and p frame(not use B frame) encodec,then use vlc player is abnormal.vlc only display I frame video is good,p frame is abnormal. why? (note:i frame and p frame i use same gettimeday() code). From finlayson at live555.com Thu Nov 25 02:11:23 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 25 Nov 2010 02:11:23 -0800 Subject: [Live-devel] RTSP unicast from circular buffer In-Reply-To: References: Message-ID: >I'm new to the Live555 which I want to use in my project. My >requirement is to stream video (H.264/AAC in TS) over the RTSP >unicast. The video continuously comes in (like live) and is captured >into circular buffer (either in memory or on hard disk). I check out >the "testOnDemandRTSPServer" sample. But it takes in a single file. >How can I do it with multiple files in a circular fashion or with >circular buffer in memory? You would need to write a new input source class (a subclass of "FramedSource"), and a new "ServerMediaSubsession" class. This would be similar to the existing "MPEG2TransportFileServerMediaSubsession" class, but would use your new input source class rather than "ByteStreamFileSource". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Nov 25 07:23:59 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 25 Nov 2010 07:23:59 -0800 Subject: [Live-devel] use livemedia transport mpeg4streame problem In-Reply-To: <41FC1A94FE13684D8249B089C38119700F673A@mailserver-nj1.njacejet.com> References: <41FC1A94FE13684D8249B089C38119700F673A@mailserver-nj1.njacejet.com> Message-ID: > I use livemeida transport xvid mpeg4 video,i implement own >mpeg4serverseesion class and owen devicesource class.I find I set >xvid codec only use I frame,then use vlc play is good.but, if i set >xvid codec use I frame and p frame(not use B frame) encodec,then use >vlc player is abnormal.vlc only display I frame video is good,p >frame is abnormal. why? (note:i frame and p frame i use same >gettimeday() code). Unfortunately I can't help you with your custom code. However, I suggest that you first try using the supplied demo applications "testMPEG4VideoStreamer" and/or "testOnDemandRTSPServer" to stream a MPEG-4 Elementary Stream Video (i.e., ".m4e") file, made from your encoder. If these applications cannot properly stream your file, then please send us a link to the file, so we can download it and test it for ourself. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Nov 25 12:51:04 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 25 Nov 2010 12:51:04 -0800 Subject: [Live-devel] ERROR: parse buffer full; increase MAX_FRAME_SIZE In-Reply-To: <098BBFB65A194D009B086562560663D1@its.na.it> References: <098BBFB65A194D009B086562560663D1@its.na.it> Message-ID: Unfortunately our 'indexing' code currently works only on Transport Stream files that contain MPEG-2 video. It does not currently support MPEG-4 or H.264 video Transport Stream files. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yangzx at acejet.com.cn Thu Nov 25 23:22:34 2010 From: yangzx at acejet.com.cn (=?gb2312?B?0e7Wvs/p?=) Date: Fri, 26 Nov 2010 15:22:34 +0800 Subject: [Live-devel] use livemedia transport mpeg4streame problem References: <41FC1A94FE13684D8249B089C38119700F673A@mailserver-nj1.njacejet.com> <41FC1A94FE13684D8249B089C38119700F673B@mailserver-nj1.njacejet.com> Message-ID: <41FC1A94FE13684D8249B089C38119700F673C@mailserver-nj1.njacejet.com> thanks.if use the encode to file,the file use "testondemandrtpserver" tansport,VLC player is GOOD.(use i frame and p frame). i have two question: 1?i look devicesource exsample,it say if use livesource,then "fDurationInMicroseconds" is no set.yes? if no,how to set it? 2?whatever livemeida receive is I frame and P frame,my owndevicesource deliverFrame use same gettimeofday(&fPresentationTime,NULL),i dont know it's right and error? ________________________________ From: live-devel-bounces at ns.live555.com ?? Ross Finlayson Sent: 2010-11-25 (???) 23:23 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] use livemedia transport mpeg4streame problem > I use livemeida transport xvid mpeg4 video,i implement own >mpeg4serverseesion class and owen devicesource class.I find I set >xvid codec only use I frame,then use vlc play is good.but, if i set >xvid codec use I frame and p frame(not use B frame) encodec,then use >vlc player is abnormal.vlc only display I frame video is good,p >frame is abnormal. why? (note:i frame and p frame i use same >gettimeday() code). Unfortunately I can't help you with your custom code. However, I suggest that you first try using the supplied demo applications "testMPEG4VideoStreamer" and/or "testOnDemandRTSPServer" to stream a MPEG-4 Elementary Stream Video (i.e., ".m4e") file, made from your encoder. If these applications cannot properly stream your file, then please send us a link to the file, so we can download it and test it for ourself. -- 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 yangzx at acejet.com.cn Fri Nov 26 02:14:52 2010 From: yangzx at acejet.com.cn (=?gb2312?B?0e7Wvs/p?=) Date: Fri, 26 Nov 2010 18:14:52 +0800 Subject: [Live-devel] =?gb2312?b?tPC4tDogIHVzZSBsaXZlbWVkaWEgdHJhbnNwb3J0?= =?gb2312?b?IG1wZWc0c3RyZWFtZSBwcm9ibGVt?= References: <41FC1A94FE13684D8249B089C38119700F673A@mailserver-nj1.njacejet.com><41FC1A94FE13684D8249B089C38119700F673B@mailserver-nj1.njacejet.com><41FC1A94FE13684D8249B089C38119700F673C@mailserver-nj1.njacejet.com> Message-ID: <41FC1A94FE13684D8249B089C38119700F673D@mailserver-nj1.njacejet.com> thanks you answer. 1?i alreday use ""MPEG4VideoStreamDiscreteFramer" by ownserverseesion. 2?I test my devicesource class.when i set "fDurationInMicroseconds=0" or not set it.then use vlcplayer is very bad. if set fDurationInMicroseconds=1000000/25,then vlc player result better than "fDurationInMicroseconds=0". why? 3?I dont know 'where "frame_rate" is the stream's frame rate in frames-per-second'. it not 25 or 30?? if no,i how to get frame_rate value? ________________________________ From: live-devel-bounces at ns.live555.com ?? Ross Finlayson Sent: 2010-11-26 (???) 17:00 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] use livemedia transport mpeg4streame problem thanks.if use the encode to file,the file use "testondemandrtpserver" tansport,VLC player is GOOD.(use i frame and p frame). That's good news, because it shows that the data from your encoder is OK. The only problem is the way that you are sending it. Because your data comes from an encoder - one frame at a time - you should be feeding it into a "MPEG4VideoStreamDiscreteFramer" (*not* a "MPEG4VideoStreamFramer"), and from there into a "MPEG4ESVideoRTPSink". i have two question: 1?Ai look devicesource exsample,it say if use livesource,then "fDurationInMicroseconds" is no set.yes? if no,how to set it? Because your encoded video data comes from a live source, you probably do not need to set "fDurationInMicroseconds" in your data source class. (However, if you do choose to set it, you would set it to 1000000.0/frame_rate for each frame, where "frame_rate" is the stream's frame rate in frames-per-second. 2?Awhatever livemeida receive is I frame and P frame,my owndevicesource deliverFrame use same gettimeofday(&fPresentationTime,NULL) That should be OK. Just be sure to feed this data into a "MPEG4VideoStreamDiscreteFramer", and the presentation time values will be adjusted properly, even for P frames. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From davidcailliere at voila.fr Fri Nov 26 16:00:20 2010 From: davidcailliere at voila.fr (david cailliere) Date: Sat, 27 Nov 2010 01:00:20 +0100 (CET) Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP Message-ID: <16553615.3862221290816020473.JavaMail.www@wwinf4630> Dear Ross, Unfortunately, I can not provide you for the stream that illustrates the problem but I did my investigation, and I think I'm close to find the reason why openRTSP is crashing. Actually I'm playing two different stream simultaneously using the lastest release of openRTSP. One MPEG4 video stream and one AMR audio stream. I get the following sequence when the problem is happenning: ..... server -> client AUDIO RTCP GOODBYE crash server -> client VIDEO RTCP GOODBYE client -> server RTSP TEARDOWN ..... The first call to "subsessionByeHandler()" close the audio media subsession's stream, which causes some medium object to be deleted. But "shutdown()" is not yet called since the video subession is still active. Therefore the alarm handlers are not unscheduled and the previously deleted audio medium object is used later in the process when calling fDelayQueue.handleAlarm() in order to process some pending audio buffer. So the crash only happens when there is some delay between the reception of the RTCP bye packet for the two different stream, and in the mean time the handlertimeout is not called. So my question is: Would it be possible to force the call to shutdown at the first call of subsessionByeHandler ? Regards, David ____________________________________________________ Prenez de l'avance pour vos cadeaux de No?l, d?couvrez notre s?lection sur Voila : http://actu.voila.fr/evenementiel/noel-2010/boutique/ From finlayson at live555.com Fri Nov 26 18:12:44 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 26 Nov 2010 18:12:44 -0800 Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP In-Reply-To: <16553615.3862221290816020473.JavaMail.www@wwinf4630> References: <16553615.3862221290816020473.JavaMail.www@wwinf4630> Message-ID: >So my question is: >Would it be possible to force the call to shutdown at the first call >of subsessionByeHandler ? Yes, it would certainly be 'possible'. However, I'm not going to do that, because it's not the right thing to do. It's perfectly reasonable (though uncommon) for the server to end one substream early, while continuing to stream the other(s). In this case, we want to continue to receive the other, ongoing stream(s), until they also end. >I get the following sequence when the problem is happenning: > >..... >server -> client AUDIO RTCP GOODBYE >crash >server -> client VIDEO RTCP GOODBYE >client -> server RTSP TEARDOWN >..... > > >The first call to "subsessionByeHandler()" close the audio media >subsession's stream, which causes some medium object to be deleted. >But "shutdown()" is not yet called since the video subession is >still active. Therefore the alarm handlers are not unscheduled and >the previously deleted audio medium object is used later in the >process when calling fDelayQueue.handleAlarm() in order to process >some pending audio buffer. This is helpful, but still not quite enough information, unfortunately. The closing of the audio subsession's stream *should* be stopping any additional processing related to the audio stream, so it that's not happening, then that will be the bug. It would be nice to know exactly what alarm handler function is getting called (after the audio subsession is closed) that's leading to the crash. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jd1008 at gmail.com Sat Nov 27 21:54:57 2010 From: jd1008 at gmail.com (JD) Date: Sat, 27 Nov 2010 21:54:57 -0800 Subject: [Live-devel] Questions about live555 media server Message-ID: <4CF1EEB1.1000307@gmail.com> When I run the media server, it says it is unable to determine my ip address: ------------------------------------------ $ live555MediaServer LIVE555 Media Server version 0.42 (LIVE555 Streaming Media library version 2010.04.09). Play streams from this server using the URL rtsp://0.0.0.0:8554/ where is a file present in the current directory. Each file's type is inferred from its name suffix: ".aac" => an AAC Audio (ADTS format) file ".amr" => an AMR Audio file ".m4e" => a MPEG-4 Video Elementary Stream file ".dv" => a DV Video file ".mp3" => a MPEG-1 or 2 Audio file ".mpg" => a MPEG-1 or 2 Program Stream (audio+video) file ".ts" => a MPEG Transport Stream file (a ".tsx" index file - if present - provides server 'trick play' support) ".wav" => a WAV Audio file See http://www.live555.com/mediaServer/ for additional documentation. Unable to determine our source address: This computer has an invalid IP address: 0x0 Unable to determine our source address: This computer has an invalid IP address: 0x0 Unable to determine our source address: This computer has an invalid IP address: 0x0 ---------------------------- That is indeed strange. Can it not use at least 127.0.0.1 ? Also, when I try to play a file: $ ffplay 'rtsp://127.0.0.1:8554/f/tmp1/01-Invocation_(Sri_Rudram_Lagunyasam).wav' the playback is so horribly slow, with long silence between each 2 seconds of sound, that it makes me wonder if this stream server can even function across the real internet at reasonable speeds - when it does not even provide sufficient speed when it's client is on the same machine. Am I doing something wrong here?? Also, how do I subscribe to the mailing list? Best regards, JD From finlayson at live555.com Sat Nov 27 22:32:38 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 27 Nov 2010 22:32:38 -0800 Subject: [Live-devel] Questions about live555 media server In-Reply-To: <4CF1EEB1.1000307@gmail.com> References: <4CF1EEB1.1000307@gmail.com> Message-ID: >When I run the media server, it says it is unable to >determine my ip address: > >------------------------------------------ >$ live555MediaServer >LIVE555 Media Server > version 0.42 (LIVE555 Streaming Media library version 2010.04.09). >Play streams from this server using the URL >rtsp://0.0.0.0:8554/ >where is a file present in the current directory. >Each file's type is inferred from its name suffix: > ".aac" => an AAC Audio (ADTS format) file > ".amr" => an AMR Audio file > ".m4e" => a MPEG-4 Video Elementary Stream file > ".dv" => a DV Video file > ".mp3" => a MPEG-1 or 2 Audio file > ".mpg" => a MPEG-1 or 2 Program Stream (audio+video) file > ".ts" => a MPEG Transport Stream file > (a ".tsx" index file - if present - provides server 'trick >play' support) > ".wav" => a WAV Audio file >See http://www.live555.com/mediaServer/ for additional documentation. >Unable to determine our source address: This computer has an invalid >IP address: 0x0 >Unable to determine our source address: This computer has an invalid >IP address: 0x0 >Unable to determine our source address: This computer has an invalid >IP address: 0x0 >---------------------------- > >That is indeed strange. Not really. The code uses multicast to (try to) figure out the host's IP address. This error is usually caused by not having IP multicast configured properly on your system. Make sure that you have a route for 224.0.0/4 >Can it not use at least 127.0.0.1 ? Yes, you could - but if you're a server, you really want an IP address that other computers can reach. >Also, when I try to play a file: >$ ffplay >'rtsp://127.0.0.1:8554/f/tmp1/01-Invocation_(Sri_Rudram_Lagunyasam).wav' > >the playback is so horribly slow, with long silence between each 2 >seconds of sound, The problem may be with "ffplay", not with our server. However, "ffplay" is not our software, so if you have any questions about "ffplay", you'll need to ask them on another mailing list. I suggest that you try using VLC as a client instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Nov 28 00:15:12 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Nov 2010 00:15:12 -0800 Subject: [Live-devel] Questions about live555 media server In-Reply-To: <000901cb8ed1$f0958170$d1c08450$@coexsi.fr> References: <4CF1EEB1.1000307@gmail.com> <000901cb8ed1$f0958170$d1c08450$@coexsi.fr> Message-ID: >What I suggest: >- Open the UDP port 15947 (the one live555 will use, >hardcoded) in the firewall of the computer if enabled >- Add the following route "route add -host 228.67.43.91 dev >eth0" on the correct interface (228.67.43.91 is the multicast IP >address used by live555, hardcoded) This will work, but it's better to add a route for 224.0.0/4 - i.e., all IP multicast addresses, so that multicast applications (both ours and others) will work properly. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Nov 28 01:14:07 2010 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Nov 2010 01:14:07 -0800 Subject: [Live-devel] FW: LiveMedia in a Directshow Filter Message-ID: I discovered (and, I hope, fixed) a bug in our mailing list software that was apparently causing the list's digesting and archiving mechanism to choke on some Unicode characters that were in Eyal's message (and quoted in my response). Therefore, I'm sending my response again, in the hope that it will get through to everyone this time. (This may be the third time that some of you have seen this message; if so, my apologies.) ------------------ >Question #1: How should Notify MPEG4LiveSource::doGetNextFrame ? >while(true) >{ >fWatchVariable = 0; >dummyTask(NULL); // 100 ms to awake a sleeping server. >env->taskScheduler().doEventLoop(&fWatchVariable); >if (fWatchVariable =1) >{ > // How to Invoke MPEG4LiveSource::doGetNextFrame? >printf("\nEventThrown=%d,",fWatchVariable); >} >} Assuming that "fWatchVariable" gets set when new data arrives for your "MPEG4LiveSource" object, then you would handle this event by calling whatever function - in your "MPEG4LIVESource" class - you have defined to handle the arrival of new data. (E.g, if you were to use our "DeviceSource" code as a model ("liveMedia/DeviceSource.cpp"), this would be the "deliverFrame()" member function.) >Question #2: Is It ok to use MPEG4VideoStreamFramer or should I use >MPEG4VideoStreamDiscreteFramer in order to parse test.m4e file.? ".m4e" files should always be streamed using the "MPEG4VideoStreamFramer" class (because files deliver a byte stream - not a stream of discrete frames). >void MPEG4LiveSource::doGetNextFrame() { > > if (!isCurrentlyAwaitingData()) > return; // we're not ready for the data yet > > // WaitForSingleObject( hEvent, INFINITE ); // >Question #3: Try to sync both thread Ignoring >TaskScheduler::doEventLoop() >, is that recommendable? No! Your "doGetNextFrame()" function should never block. If no data is immediately available for delivery, then "doGetNextFrame()" should just return. (Again, see the "DeviceSource" code for an illustration.) >nextTask() = >envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, >this); // Question #4: Is that good to call suitable here? Yes. This tells the downstream object that data has been delivered to it. >Question #5: Run over the Mailing list I could not found any >example of streaming from DirectShopw filter, Is there a problem >with that approach? No. Several other people have done this. (However, I personally do not use 'DirectShow'.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jd1008 at gmail.com Sun Nov 28 08:31:18 2010 From: jd1008 at gmail.com (JD) Date: Sun, 28 Nov 2010 08:31:18 -0800 Subject: [Live-devel] Questions about live555 media server In-Reply-To: References: <4CF1EEB1.1000307@gmail.com> Message-ID: <4CF283D6.9030906@gmail.com> On 11/27/2010 10:32 PM, Ross Finlayson wrote: >> When I run the media server, it says it is unable to >> determine my ip address: >> >> ------------------------------------------ >> $ live555MediaServer >> LIVE555 Media Server >> version 0.42 (LIVE555 Streaming Media library version 2010.04.09). >> Play streams from this server using the URL >> rtsp://0.0.0.0:8554/ >> where is a file present in the current directory. >> Each file's type is inferred from its name suffix: >> ".aac" => an AAC Audio (ADTS format) file >> ".amr" => an AMR Audio file >> ".m4e" => a MPEG-4 Video Elementary Stream file >> ".dv" => a DV Video file >> ".mp3" => a MPEG-1 or 2 Audio file >> ".mpg" => a MPEG-1 or 2 Program Stream (audio+video) file >> ".ts" => a MPEG Transport Stream file >> (a ".tsx" index file - if present - provides server 'trick >> play' support) >> ".wav" => a WAV Audio file >> See http://www.live555.com/mediaServer/ for additional documentation. >> Unable to determine our source address: This computer has an invalid >> IP address: 0x0 >> Unable to determine our source address: This computer has an invalid >> IP address: 0x0 >> Unable to determine our source address: This computer has an invalid >> IP address: 0x0 >> ---------------------------- >> >> That is indeed strange. > > Not really. The code uses multicast to (try to) figure out the host's > IP address. This error is usually caused by not having IP multicast > configured properly on your system. > > Make sure that you have a route for 224.0.0/4 I found the source of the problem. The firewall! I had to allow route to 224.0.0.0/4 It all works now. Thanks!! Cheers, JD From yaopingtiankong at 163.com Sun Nov 28 17:33:36 2010 From: yaopingtiankong at 163.com (=?GBK?B?0qLGvQ==?=) Date: Mon, 29 Nov 2010 09:33:36 +0800 (CST) Subject: [Live-devel] Why the test examples don't work well in embedded system Message-ID: <5af24c.137f.12c95437cb3.Coremail.yaopingtiankong@163.com> I have tried testMPEG4VideoStreamer ,testOnDemandRTSPServer and others in embedded system, they all show the same problem: the video data send too slowly, why? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eyals at aeronautics-sys.com Mon Nov 29 07:00:45 2010 From: eyals at aeronautics-sys.com (Eyal Shveky) Date: Mon, 29 Nov 2010 17:00:45 +0200 Subject: [Live-devel] LiveMedia in a Directshow Filter Message-ID: <10C6D4821E0BAA44A73B987733947B16C91334@OREV.ads.local> Hi, Thank you for the reply. I Don't quite understand how the doGetNextFrame() method is working. If I'm using the while loop, after creating MPEG4VideoLiveServerMediaSubsession the MPEG4LiveSource that is a member of that object is not created yet, Until I'm running the VLC received stream. Then I'm checking if it's already been assign only then calling to deliverFrame(); ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); MPEG4VideoLiveServerMediaSubsession* mP4LiveSms = MPEG4VideoLiveServerMediaSubsession::createNew(*env, streamName, reuseFirstSource); sms->addSubsession(mP4LiveSms); rtspServer->addServerMediaSession(sms); announceStreamLive(rtspServer, sms, streamName); while(true) { fWatchVariable = 0; dummyTask(NULL); // 100ms env->taskScheduler().doEventLoop(&fWatchVariable); if (fWatchVariable = 1) { printf("\nIn While fWatchVariable=%d,",fWatchVariable); if (!mP4LiveSms->mpeg4LiveSource != NULL) mP4LiveSms->mpeg4LiveSource->deliverFrame(); } } Questions: 1) Looking at the ouptput (attached file) learning that a lot of "ms:###., size=###" prints that received in My DS filter. When receiving the stream on VLC Player on demand with "rtsp://192.168.169.128" I'm getting : fWatchVariable=0,accept()ed connection from 192.168.169.12810RTSPClientSession[0 0E79B20]::handleRequestBytes() read 138 new bytes:OPTIONS rtsp://192.168.169.128 :8554/mpeg4ESVideoTest RTSP/1.0 CSeq: 2 User-Agent: LibVLC/1.1.4 (LIVE555 Streaming Media v2010.08.22) parseRTSPRequestString() returned cmdName "OPTIONS", urlPreSuffix "", urlSuffix "mpeg4ESVideoTest" sending response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Nov 29 2010 11:41:10 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA METER RTSPClientSession[00E79B20]::handleRequestBytes() read 164 new bytes:DESCRIBE rt sp://192.168.169.128:8554/mpeg4ESVideoTest RTSP/1.0 CSeq: 3 User-Agent: LibVLC/1.1.4 (LIVE555 Streaming Media v2010.08.22) Accept: application/sdp parseRTSPRequestString() returned cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "mpeg4ESVideoTest" parsing VisualObjectSequence MPEG4VideoStreamParser::parse() EXCEPTION (This is normal behavior - *not* an er ror) .Done! RTSPClientSession[00E79B20]::handleRequestBytes() read 0 new bytes (of 9836); te rminating connection! ********************************************************************************************** LEGAL NOTICE - Unless expressly stated otherwise, this message, its annexes, attachments, appendixes, any subsequent correspondence, and any document, data, sketches, plans and/or other material that is hereby attached, are proprietary. confidential and may be legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of Aeronautics or make it subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. This transmission is intended for the named addressee only. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else, any disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is unauthorised and may be unlawful. If you are not an addressee, please inform the sender immediately. IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error, please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies thereof. *** eSafe scanned this email for viruses, vandals, and malicious content. *** ********************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Output.zip Type: application/x-zip-compressed Size: 2114 bytes Desc: Output.zip URL: From finlayson at live555.com Mon Nov 29 07:33:38 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Nov 2010 07:33:38 -0800 Subject: [Live-devel] LiveMedia in a Directshow Filter In-Reply-To: <10C6D4821E0BAA44A73B987733947B16C91334@OREV.ads.local> References: <10C6D4821E0BAA44A73B987733947B16C91334@OREV.ads.local> Message-ID: >while(true) >{ > fWatchVariable = 0; > dummyTask(NULL); // 100ms > env->taskScheduler().doEventLoop(&fWatchVariable); > if (fWatchVariable = 1) > { > printf("\nIn While fWatchVariable=%d,",fWatchVariable); > if (!mP4LiveSms->mpeg4LiveSource != NULL) > mP4LiveSms->mpeg4LiveSource->deliverFrame(); > } >} Note that you don't need to test for "if (fWatchVariable == 1)", because we return from "doEventLoop()" only if "fWatchVariable" is not 0. (I presume that you have some other thread - not running LIVE555 code - that is setting "fWatchVariable" to 1 when new data becomes available.) >RTSPClientSession[00E79B20]::handleRequestBytes() read 0 new bytes >(of 9836); te >rminating connection! This is strange. Your client's TCP connection (for RTSP) has unexpectedly ended. This might not have anything to do with your server's new code. I suggest that you first try to run the *unmodified* "testOnDemandRTSPServer" demo application on your system - streaming from a MPEG-4 Elementary Stream Video - i.e., ".m4e" - file. Only when you get this running correctly, then you can try modifying it to stream from another kind of input source object. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincenzo.terracciano at its.na.it Mon Nov 29 07:31:47 2010 From: vincenzo.terracciano at its.na.it (Vincenzo Terracciano) Date: Mon, 29 Nov 2010 16:31:47 +0100 Subject: [Live-devel] TRICK PLAY H264 Message-ID: Hello, i need to support trick play of a H264 ts files in my Audio/Video distribution system. Somebody can help me? Best regards. ------------------------------------------------------------------ ITS S.p.A. Vincenzo Terracciano, Via Terragneta 90, 80058 Torre Annunziata(NA) +39 081 5353392 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Nov 29 07:41:54 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Nov 2010 07:41:54 -0800 Subject: [Live-devel] LiveMedia in a Directshow Filter Message-ID: >while(true) >{ > fWatchVariable = 0; > dummyTask(NULL); // 100ms > env->taskScheduler().doEventLoop(&fWatchVariable); > if (fWatchVariable = 1) > { > printf("\nIn While fWatchVariable=%d,",fWatchVariable); > if (!mP4LiveSms->mpeg4LiveSource != NULL) > mP4LiveSms->mpeg4LiveSource->deliverFrame(); > } >} Also, don't forget to reset "fWatchVariable" back to 0 immediately after you return from "doEventLoop()" (i.e., before you call "doEventLoop()" again), so that you don't unexpectedly return from "doEventLoop()" the next time. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sr at coexsi.fr Mon Nov 29 09:45:39 2010 From: sr at coexsi.fr (=?iso-8859-1?Q?S=E9bastien_RAILLARD_=28COEXSI=29?=) Date: Mon, 29 Nov 2010 18:45:39 +0100 Subject: [Live-devel] TRICK PLAY H264 In-Reply-To: References: Message-ID: <00c101cb8fed$3d51c020$b7f54060$@coexsi.fr> It?s too complex for now to implement a real H264 indexer for TS files. I?ve publish a simple indexer for this kind of files here: http://www.coexsi.fr/publications/live555-universal-indexer/ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Vincenzo Terracciano Sent: lundi 29 novembre 2010 16:32 To: live-devel at ns.live555.com Subject: [Live-devel] TRICK PLAY H264 Hello, i need to support trick play of a H264 ts files in my Audio/Video distribution system. Somebody can help me? Best regards. ------------------------------------------------------------------ ITS S.p.A. Vincenzo Terracciano, Via Terragneta 90, 80058 Torre Annunziata(NA) +39 081 5353392 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sr at coexsi.fr Mon Nov 29 15:31:38 2010 From: sr at coexsi.fr (=?iso-8859-1?Q?S=E9bastien_RAILLARD_=28COEXSI=29?=) Date: Tue, 30 Nov 2010 00:31:38 +0100 Subject: [Live-devel] h.264 indexer In-Reply-To: References: <002201cb89bc$a5ede780$f1c9b680$@coexsi.fr> Message-ID: <00f801cb901d$9274ca90$b75e5fb0$@coexsi.fr> Dear Nouri, I didn?t know that avidemux was creating an index file. It seems to be used for subtitling synchronization. It may be possible to convert this index file to as .tsx file for live555 but I can?t find in the avidemux source code where the index is created, how it is created and the file format of the idx file. Sebastien. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Mojtaba Nouri Sent: lundi 22 novembre 2010 06:54 To: live-devel Subject: Re: [Live-devel] h.264 indexer Dear Sebastian I have seen your indexer, but couldn't you use a library (like ffmpeg) to detect all h264 frames and make a complete index file? Btw, Has anyone seen the avidemux software? It builds an index of the opened file (which can be in various formats and codecs) that represents a report if its frames. I attached an index file that it made. does it seem to be a good start point? On Mon, Nov 22, 2010 at 12:12 AM, S?bastien RAILLARD (COEXSI) wrote: I don?t think it?s the only thing to change. Also, for indexing H264, the equivalent of the I-Frames must be located in the stream, and that is really harder than with MPEG2 video. By the way the indexer code isn?t really easy to understand. That why I did a small and external TS indexer based on the starting of PES payload. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Mojtaba Nouri Sent: dimanche 21 novembre 2010 10:54 To: live-devel Subject: [Live-devel] h.264 indexer Hi Ross I am trying to improve the indexer to index a h.264/ts file. Could you tell me which parts of the indexer are write regardless of the codec? In particular I see the following comment in the code // Note: The following works only for MPEG-2 data ##### Is this the only part that depends on MPEG-2? I could use any information. Thanks. _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders_chen at huntelec.com.tw Mon Nov 29 20:12:47 2010 From: anders_chen at huntelec.com.tw (HUNT_Anders Chen) Date: Tue, 30 Nov 2010 12:12:47 +0800 Subject: [Live-devel] incorrect uSecondsToGo value Message-ID: <898CBB7916D04EE6AB96E3B484B17176@huntelec.com.tw> Dear all, At line 391 of MultiFramedRTPSink.cpp : int64_t uSecondsToGo = (fNextSendTime.tv_sec - timeNow.tv_sec)*1000000 + (fNextSendTime.tv_usec - timeNow.tv_usec); In some situations, (fNextSendTime.tv_sec - timeNow.tv_sec)*1000000 will become a huge, but positive value. ex. timeNow.tv_sec = 1291086790; fNextSendTime.tv_sec = 1291084611; (fNextSendTime.tv_sec - timeNow.tv_sec) = -2179; (fNextSendTime.tv_sec - timeNow.tv_sec)*1000000 = 2115967296; And I think the same problem will be happened at line 86 of BasicUDPSink.cpp. Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Nov 29 21:09:09 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Nov 2010 21:09:09 -0800 Subject: [Live-devel] incorrect uSecondsToGo value In-Reply-To: <898CBB7916D04EE6AB96E3B484B17176@huntelec.com.tw> References: <898CBB7916D04EE6AB96E3B484B17176@huntelec.com.tw> Message-ID: > At line 391 of MultiFramedRTPSink.cpp : > > int64_t uSecondsToGo = (fNextSendTime.tv_sec - >timeNow.tv_sec)*1000000 + (fNextSendTime.tv_usec - timeNow.tv_usec); > > In some situations, (fNextSendTime.tv_sec - >timeNow.tv_sec)*1000000 will become a huge, but positive value. > ex. > timeNow.tv_sec = 1291086790; > fNextSendTime.tv_sec = 1291084611; > > (fNextSendTime.tv_sec - timeNow.tv_sec) = -2179; > (fNextSendTime.tv_sec - timeNow.tv_sec)*1000000 = 2115967296; Thanks for the report. As far as I can tell, there are only two possible ways that this problem ("fNextSendTime" being less than "timeNow") could occur: 1/ The source object that feeds into this is generating invalid "durationInMicroseconds" values, 2/ The system clock got set forward in time. I don't care about 1/ (if the inputting source object is buggy, then that's its problem, not ours), but 2/ is a legitimate concern. (Sebastien Escudier has also noted similar problems.) To overcome this situation, I suggest adding the following code to replace the assignment of "uSecondsToGo" (i.e., replacing line 391): int secsDiff = fNextSendTime.tv_sec - timeNow.tv_sec; int64_t uSecondsToGo = secsDiff*1000000 + (fNextSendTime.tv_usec - timeNow.tv_usec); if (secsDiff < 0 || uSecondsToGo < 0) { // sanity check (perhaps the system clock jumped ahead?) uSecondsToGo = 0; fNextSendTime = timeNow; } This change will be added to the next release of the code. > And I think the same problem will be happened at >line 86 of BasicUDPSink.cpp. Yes. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 44072429 at qq.com Mon Nov 29 18:07:29 2010 From: 44072429 at qq.com (=?ISO-8859-1?B?NDQwNzI0Mjk=?=) Date: Tue, 30 Nov 2010 10:07:29 +0800 Subject: [Live-devel] RTPInterface Message-ID: dear friends. can i change RTPInterface's implementation? i saw RTPInterface was using like this. class RTPSink: public MediaSink { RTPInterface fRTPInterface; }; any way to change it? or i can't change it for some reason? regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidcailliere at voila.fr Mon Nov 29 10:03:39 2010 From: davidcailliere at voila.fr (david cailliere) Date: Mon, 29 Nov 2010 19:03:39 +0100 (CET) Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP Message-ID: <8207701.4124021291053819341.JavaMail.www@wwinf4630> Dear Ross > This is helpful, but still not quite enough information, unfortunately. The closing of the audio subsession's stream *should* > be stopping any additional processing related to the audio stream, so it that's not happening, then that will be the bug. > It would be nice to know exactly what alarm handler function is getting called (after the audio subsession is closed) that's leading to the crash. I get a fisrt chance exception at 0x004125be in openRTSP.exe?: (0xC0000005: acces Violation) when running sink->afterGettingFrame1(frameSize, presentationTime); Please find below a screen shot of the call stack when the crash happens: openRTSP.exe!FileSink::afterGettingFrame(void * clientData=0x00af3768, unsigned int frameSize=17, unsigned int __formal=0, timeval presentationTime={...}, unsigned int __formal=0) Ligne 88 + 0x14 octets C++ openRTSP.exe!FramedSource::afterGetting(FramedSource * source=0x0039d2f8) Ligne 91 + 0x2f octets C++ openRTSP.exe!AMRDeinterleaver::doGetNextFrame() Ligne 468 + 0x9 octets C++ openRTSP.exe!AMRDeinterleaver::afterGettingFrame1(unsigned int frameSize=17, timeval presentationTime={...}) Ligne 504 C++ openRTSP.exe!AMRDeinterleaver::afterGettingFrame(void * clientData=0x0039d2f8, unsigned int frameSize=17, unsigned int __formal=0, timeval presentationTime={...}, unsigned int __formal=0) Ligne 493 C++ openRTSP.exe!FramedSource::afterGetting(FramedSource * source=0x0039d0b0) Ligne 91 + 0x2f octets C++ openRTSP.exe!AlarmHandler::handleTimeout() Ligne 34 + 0xf octets C++ openRTSP.exe!DelayQueue::handleAlarm() Ligne 182 C++ openRTSP.exe!BasicTaskScheduler::SingleStep(unsigned int maxDelayTime=0) Ligne 151 C++ openRTSP.exe!BasicTaskScheduler0::doEventLoop(char * watchVariable=0x00000000) Ligne 77 C++ openRTSP.exe!main(int argc=2, char * * argv=0x00393d1c) Ligne 512 C++ openRTSP.exe!__tmainCRTStartup() Ligne 266 + 0x19 octets C openRTSP.exe!mainCRTStartup() Ligne 182 C kernel32.dll!7c817077() Regards, David ____________________________________________________ Prenez de l'avance pour vos cadeaux de No?l, d?couvrez notre s?lection sur Voila : http://actu.voila.fr/evenementiel/noel-2010/boutique/ From finlayson at live555.com Tue Nov 30 00:41:58 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Nov 2010 00:41:58 -0800 Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP In-Reply-To: <8207701.4124021291053819341.JavaMail.www@wwinf4630> References: <8207701.4124021291053819341.JavaMail.www@wwinf4630> Message-ID: The call stack helps a little, but unfortunately still doesn't nail down the problem for me. A couple more questions: 1/ What command-line arguments are you giving to "openRTSP" (apart from the "rtsp://" URL)? 2/ Does the crash happen for streams that contain other kinds of audio, or just those that contain AMR audio (in addition to video)? From finlayson at live555.com Tue Nov 30 01:12:30 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Nov 2010 01:12:30 -0800 Subject: [Live-devel] RTPInterface In-Reply-To: References: Message-ID: >can i change RTPInterface's implementation? Of course you can. The code is Open Source, licensed under the LGPL. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From dane at cam.ly Tue Nov 30 01:29:44 2010 From: dane at cam.ly (Dane Jensen) Date: Tue, 30 Nov 2010 04:29:44 -0500 Subject: [Live-devel] (no subject) Message-ID: Hey Live555 Developers, I run a very small IP Security Camera company cam.ly. We use openRTSP to record our archive video. Thanks for building it. We sell our cameras as open devices and encourage hacking ( http://cam.ly/blog/2010/08/different-ways-to-modify-your-cam-ly/). It would be awesome if you guys would link to us in your products page. Thanks, Dane Jensen Cam.ly Security Cameras -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 30 02:43:45 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Nov 2010 02:43:45 -0800 Subject: [Live-devel] Cam.ly In-Reply-To: References: Message-ID: >I run a very small IP Security Camera >company cam.ly. We use openRTSP to record our >archive video. Thanks for building it. We sell our cameras as open >devices and encourage hacking >(http://cam.ly/blog/2010/08/different-ways-to-modify-your-cam-ly/). > It would be awesome if you guys would link to us in your products >page. Done. Thanks for the note. This sounds like an interesting product. Just curious: Do you allow clients to view a camera's video directly using RTSP (i.e., from a RTSP server inside the camera itself), or can video be viewed only using Flash (or HTML 5) browsers? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yangzx at acejet.com.cn Tue Nov 30 05:24:44 2010 From: yangzx at acejet.com.cn (=?gb2312?B?0e7Wvs/p?=) Date: Tue, 30 Nov 2010 21:24:44 +0800 Subject: [Live-devel] =?gb2312?b?tPC4tDogIKisP6GuYCA6ICB1c2UgbGl2ZW1lZGlh?= =?gb2312?b?IHRyYW5zcG9ydCAgbXBlZzRzdHJlYW1lIHByb2JsZW0=?= References: <41FC1A94FE13684D8249B089C38119700F673A@mailserver-nj1.njacejet.com><41FC1A94FE13684D8249B089C38119700F673B@mailserver-nj1.njacejet.com><41FC1A94FE13684D8249B089C38119700F673C@mailserver-nj1.njacejet.com> <41FC1A94FE13684D8249B089C38119700F673D@mailserver-nj1.njacejet.com> Message-ID: <41FC1A94FE13684D8249B089C38119700F673F@mailserver-nj1.njacejet.com> thank you help. I find my encode frame rate no fix.frame rate often change.so,my devicesource class "fDurationInMicroseconds" no right set. when i set "fDurationInMicroseconds" is 1000000/25,because encode frame rate often change,so,my deliverFrame() possisble no can deliver new or right frame.to make of vlc player is no good. please tell me how fix the problem? i think my encode is wrong,yes? ________________________________ From: live-devel-bounces at ns.live555.com ?? Ross Finlayson Sent: 2010-11-26 (???) 18:12 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] ???` : use livemedia transport mpeg4streame problem thanks you answer. 1?Ai alreday use ""MPEG4VideoStreamDiscreteFramer" by ownserverseesion. 2?AI test my devicesource class.when i set "fDurationInMicroseconds=0" or not set it.then use vlcplayer is very bad. if set fDurationInMicroseconds=1000000/25,then vlc player result better than "fDurationInMicroseconds=0". why? I don't know (because this relates to your own, custom code) - but it appears that your input source class is not working properly. It should be delivering a frame of data only when a new frame becomes available (from your encoder). The fact that your code is not working properly when "fDurationInMicroseconds" is 0 suggests that it is not doing this. Instead, it might be delivering the same frame data more than once - which is wrong. However, because this is your own code, I'm not going to be able to help you any more with this. 3?AI dont know 'where "frame_rate" is the stream's frame rate in frames-per-second'. it not 25 or 30?? if no,i how to get frame_rate value? I don't know - again, because this relates to your own custom environment. But presumably you have some way of knowing the rate at which your encoder generates video frames... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From davidcailliere at voila.fr Tue Nov 30 04:53:06 2010 From: davidcailliere at voila.fr (david cailliere) Date: Tue, 30 Nov 2010 13:53:06 +0100 (CET) Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP Message-ID: <1204265.1176471291121586990.JavaMail.www@wwinf4625> Dear Ross, > 1/ What command-line arguments are you giving to "openRTSP" (apart from the "rtsp://" URL)? I'm using options "-Q -d x" for the test where x is a duration which is smaller than the full length of the stream. A change on the duration parameter has no impact on the issue. > 2/ Does the crash happen for streams that contain other kinds of > audio, or just those that contain AMR audio (in addition to video)?ilable Unfortunately, I think there is only one kind of audio-video stream from the server I'm testing. But I've noticed that the crash never happens when the MPEG4 video RTCP bye packet is received before the AMR audio RTCP bye packet. Regards, David ____________________________________________________ Prenez de l'avance pour vos cadeaux de No?l, d?couvrez notre s?lection sur Voila : http://actu.voila.fr/evenementiel/noel-2010/boutique/ From finlayson at live555.com Tue Nov 30 05:36:02 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Nov 2010 05:36:02 -0800 Subject: [Live-devel] Handling RTCP Goodbye packet with OpenRTSP In-Reply-To: <1204265.1176471291121586990.JavaMail.www@wwinf4625> References: <1204265.1176471291121586990.JavaMail.www@wwinf4625> Message-ID: > > 1/ What command-line arguments are you giving to "openRTSP" >(apart from the "rtsp://" URL)? >I'm using options "-Q -d x" for the test >where x is a duration which is smaller than the full length of the >stream. A change on the duration parameter has no impact on the >issue. Are you sure that the crash can still occur, even if you omit the "-Q" option? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From edi87 at fibertel.com.ar Tue Nov 30 11:38:36 2010 From: edi87 at fibertel.com.ar (edi87 at fibertel.com.ar) Date: Tue, 30 Nov 2010 16:38:36 -0300 Subject: [Live-devel] Question about trick play, server side Message-ID: <1ee543a07e28.4cf5288c@fibertel.com.ar> Hello, I'm new at live555, i read doxygen references and make some tests to start understanding how it works. Now i plan something to do, i think simple, I want to stream a video file (.mpg) on demand, but with one feature... I want to specify the duration to stream in seconds, or make it an infinite loop. So, suppose I have a video of 10 mins, I want to stream on demand only 1 min... or make it an infinite loop, so when 10 mins are streamed to a client, it must restart from 0 again. I tried to do it without any good consecuence, I'm a bit lost about .ts and .tsx files, also if its supported in server side of live555 or not. Could anybody explain me more about this? Thanks in advance, webbi From jingke2000 at gmail.com Tue Nov 30 11:45:31 2010 From: jingke2000 at gmail.com (Ke Yu) Date: Tue, 30 Nov 2010 14:45:31 -0500 Subject: [Live-devel] RTSP unicast from circular buffer In-Reply-To: References: Message-ID: I've built a solution per your suggestion. It works well. Thanks. On Thu, Nov 25, 2010 at 5:11 AM, Ross Finlayson wrote: >> I'm new to the Live555 which I want to use in my project. My >> requirement is to stream video (H.264/AAC in TS) over the RTSP >> unicast. The video continuously comes in (like live) and is captured >> into circular buffer (either in memory or on hard disk). I check out >> the "testOnDemandRTSPServer" sample. But it takes in a single file. >> How can I do it with multiple files in a circular fashion or with >> circular buffer in memory? > > You would need to write a new input source class (a subclass of > "FramedSource"), and a new "ServerMediaSubsession" class. ?This would be > similar to the existing "MPEG2TransportFileServerMediaSubsession" class, but > would use your new input source class rather than "ByteStreamFileSource". > -- > > 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 kanavgandhi at gmail.com Tue Nov 30 12:59:10 2010 From: kanavgandhi at gmail.com (kanav gandhi) Date: Tue, 30 Nov 2010 12:59:10 -0800 Subject: [Live-devel] SDP problem in openRTSP Message-ID: Hi all, I am writing my RTSP server and am using openRTSP as the client. The problem I am facing is that when I send the response for the DESCRIBE request, I get an error saying: "Have received 283 total bytes of a DESCRIBE RTSP response; awaiting 131 bytes more Failed to get a SDP description from URL "rtsp:// 127.0.1.1:554/output_Vid.mkv": liveMedia0" Can someone please give me some pointers as to what might be going wrong here. This is the message sequence for the request-reply pair: Sending request: DESCRIBE rtsp://127.0.1.1:554/output_Vid.mkv RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2010.11.17) Accept: application/sdp Received 283 new bytes of response data. headerDataCopy: RTSP/1.0 200 OK CSeq: 3 Date: 22 Nov 2010 15:35:06 GMT Content-Type: application/sdp Content-Length: 131 Content-base: rtsp://127.0.1.1/test.mkv/ v=0 o=kanav 123456 0 IN IP4 127.0.1.1 s=vp8 RTP t=0 0 m= video 5004 RTP/AVP 96 a=rtpmap:96 VP8/90000 a=control:streamid=1 Have received 283 total bytes of a DESCRIBE RTSP response; awaiting 131 bytes more. Failed to get a SDP description from URL "rtsp:// 127.0.1.1:554/output_Vid.mkv": liveMedia0 I am stuck on this issue and any help will be much appreciated. Thanks and Regards, Kanav Gandhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From eyals at aeronautics-sys.com Tue Nov 30 08:12:53 2010 From: eyals at aeronautics-sys.com (Eyal Shveky) Date: Tue, 30 Nov 2010 18:12:53 +0200 Subject: [Live-devel] LiveMedia in a Directshow Filter Message-ID: <10C6D4821E0BAA44A73B987733947B16C91431@OREV.ads.local> >while(true) >{ > fWatchVariable = 0; > dummyTask(NULL); // 100ms > env->taskScheduler().doEventLoop(&fWatchVariable); > if (fWatchVariable = 1) > { > printf("\nIn While fWatchVariable=%d,",fWatchVariable); > if (!mP4LiveSms->mpeg4LiveSource != NULL) > mP4LiveSms->mpeg4LiveSource->deliverFrame(); > } >} Note that you don't need to test for "if (fWatchVariable == 1)", because we return from "doEventLoop()" only if "fWatchVariable" is not 0. (I presume that you have some other thread - not running LIVE555 code - that is setting "fWatchVariable" to 1 when new data becomes available.) 1) How should I call deliverFrame() from the Main thread(DS Graph in a Filter) in order to signal my FramedSource that a new frame is arrived. >RTSPClientSession[00E79B20]::handleRequestBytes() read 0 new bytes >(of 9836); te >rminating connection! This is strange. Your client's TCP connection (for RTSP) has unexpectedly ended. This might not have anything to do with your server's new code. I suggest that you first try to run the *unmodified* "testOnDemandRTSPServer" demo application on your system - streaming from a MPEG-4 Elementary Stream Video - i.e., ".m4e" - file. Only when you get this running correctly, then you can try modifying it to stream from another kind of input source object. -- 2) I did, testOnDemandRTSPServer works fine I'm streaming the test.m4e into VLC player on more than one Pc on a local net. The problem is to stream from a live DirectShow filter, I think it's something with synchronized both threads and signaling to live lib when I'm getting a new frame , for the FramedSource::deliverFrame to take the global frame buffer, frame size,etc. 3) Question about the parameters : fPresentationTime, fDurationInMicroseconds what exactly they mean. fPresentationTime Is the different between sample(frame) start and Stop - in my received filter -> pSample->GetTime(&tStart, &tStop);? fDurationInMicroseconds - How do I set this parameter? Is it depand if the stream is VBR or CBR, Or should I set it to 25 fps when I'm using PAL source? Thanks, Ross Finlayson Live Networks, Inc. http://www.live555.com/ ********************************************************************************************** LEGAL NOTICE - Unless expressly stated otherwise, this message, its annexes, attachments, appendixes, any subsequent correspondence, and any document, data, sketches, plans and/or other material that is hereby attached, are proprietary. confidential and may be legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of Aeronautics or make it subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. This transmission is intended for the named addressee only. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else, any disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is unauthorised and may be unlawful. If you are not an addressee, please inform the sender immediately. IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error, please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies thereof. *** eSafe scanned this email for viruses, vandals, and malicious content. *** ********************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From dane at cam.ly Tue Nov 30 18:55:18 2010 From: dane at cam.ly (Dane Jensen) Date: Tue, 30 Nov 2010 21:55:18 -0500 Subject: [Live-devel] Cam.ly In-Reply-To: References: Message-ID: Hey Ross, Clients can view the RTSP stream directly. Best, Dane Jensen On Tue, Nov 30, 2010 at 5:43 AM, Ross Finlayson wrote: > I run a very small IP Security Camera company cam.ly. We use openRTSP to > record our archive video. Thanks for building it. We sell our cameras as > open devices and encourage hacking ( > http://cam.ly/blog/2010/08/different-ways-to-modify-your-cam-ly/). It > would be awesome if you guys would link to us in your products page. > > > Done. Thanks for the note. This sounds like an interesting product. > > Just curious: Do you allow clients to view a camera's video directly using > RTSP (i.e., from a RTSP server inside the camera itself), or can video be > viewed only using Flash (or HTML 5) browsers? > > -- > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Nov 30 20:18:02 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Nov 2010 20:18:02 -0800 Subject: [Live-devel] LiveMedia in a Directshow Filter In-Reply-To: <10C6D4821E0BAA44A73B987733947B16C91431@OREV.ads.local> References: <10C6D4821E0BAA44A73B987733947B16C91431@OREV.ads.local> Message-ID: > >while(true) > >{ > > fWatchVariable = 0; > > dummyTask(NULL); // 100ms > > env->taskScheduler().doEventLoop(&fWatchVariable); > > if (fWatchVariable = 1) > > { > > printf("\nIn While fWatchVariable=%d,",fWatchVariable); > > if (!mP4LiveSms->mpeg4LiveSource != NULL) > > mP4LiveSms->mpeg4LiveSource->deliverFrame(); > > } > >} [...] > 1) How should I call deliverFrame() from the Main thread(DS Graph >in a Filter) in order to signal my FramedSource that a new frame is >arrived. You don't! "deliverFrame()" - being a LIVE555 library operation - should be called only from the LIVE555 event loop thread - not from some other thread. However, what you *can* do in the non-LIVE555 thread (i.e., your 'DirectShow' thread) is set "fWatchVariable" to 1. If you do this, then the LIVE555 event loop (your code above) will notice this, and do the right thing, calling "deliverFrame()". >3) Question about the parameters : fPresentationTime, >fDurationInMicroseconds what exactly they mean. > fPresentationTime Is the different between sample(frame) start and >Stop - in my received filter -> pSample->GetTime(&tStart, &tStop);? In most situations, you can just set "fPresentationTime" by calling "gettimeofday()". You should do this inside your "deliverFrame()" function (which is called from the LIVE555 event loop thread, of course). > fDurationInMicroseconds - How do I set this parameter? In principle, it should be set to the duration between successive frames (that you deliver using "deliverFrame()"). However, because you are streaming from a live source, rather than from a file, it's probably OK to leave this variable unset (in which case, it'll get a default value of 0). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Nov 30 20:32:16 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Nov 2010 20:32:16 -0800 Subject: [Live-devel] Question about trick play, server side In-Reply-To: <1ee543a07e28.4cf5288c@fibertel.com.ar> References: <1ee543a07e28.4cf5288c@fibertel.com.ar> Message-ID: >I'm new at live555, i read doxygen references and make some tests to >start understanding how it works. >Now i plan something to do, i think simple, I want to stream a video >file (.mpg) on demand, but with one feature... I want to specify the >duration to stream in seconds, or make it an infinite loop. This is something that the *client* requests (using the RTSP protocol). It does not require any special support from the server. I.e., our existing, unmodified server code can do this. >So, suppose I have a video of 10 mins, I want to stream on demand >only 1 min... This is easy to do from your RTSP client (and, as I noted above, without requiring any modification to server code). Note, for example, how the "openRTSP" demo application (a RTSP client) implements the "-s " and "-d " options. > or make it an infinite loop, so when 10 mins are streamed to a >client, it must restart from 0 again. Again, this is easy to do - from the client. Note, for example, how "openRTSP" implements the "-c" option. See , and the "openRTSP" source code (in "testProgs/playCommon.cpp"). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Nov 30 20:54:37 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Nov 2010 20:54:37 -0800 Subject: [Live-devel] SDP problem in openRTSP In-Reply-To: References: Message-ID: >I am writing my RTSP server Are you using our RTSP server implementation? (If not, why not? :-) > and am using openRTSP as the client. The problem I am facing is >that when I send the response for the DESCRIBE request, I get an >error saying: > >"Have received 283 total bytes of a DESCRIBE RTSP response; awaiting >131 bytes more >Failed to get a SDP description from URL >"rtsp://127.0.1.1:554/output_Vid.mkv": >liveMedia0" > >Can someone please give me some pointers as to what might be going wrong here. Sorry, but unless you can provide the (publically accessible) "rtsp://" URL of a stream that illustrates this problem, I'm not going to be able to help you. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanavgandhi at gmail.com Tue Nov 30 23:46:52 2010 From: kanavgandhi at gmail.com (kanav gandhi) Date: Tue, 30 Nov 2010 23:46:52 -0800 Subject: [Live-devel] SDP problem in openRTSP In-Reply-To: References: Message-ID: Thanks for your reply. Well actually this is part of my school project, thats why I am writing it myself :) I was able to figure out the problem I had. If I send the actual SDP message in another rtsp response, it worked. Though now I have another problem. The client tells me that it is 'Unable to create receiver for "video/VP8" subsession: RTP payload format unknown or not supported'. So I am guessing that the live555 libraries don't support VP8. Is this correct? Thanks and Regards, Kanav On Tue, Nov 30, 2010 at 8:54 PM, Ross Finlayson wrote: > I am writing my RTSP server > > > Are you using our RTSP server implementation? (If not, why not? :-) > > > and am using openRTSP as the client. The problem I am facing is that when > I send the response for the DESCRIBE request, I get an error saying: > > "Have received 283 total bytes of a DESCRIBE RTSP response; awaiting 131 > bytes more > Failed to get a SDP description from URL "rtsp:// > 127.0.1.1:554/output_Vid.mkv": liveMedia0" > > Can someone please give me some pointers as to what might be going wrong > here. > > > Sorry, but unless you can provide the (publically accessible) "rtsp://" URL > of a stream that illustrates this problem, I'm not going to be able to help > you. > > -- > > > 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: