From gbonneau at miranda.com Thu Apr 1 05:26:49 2010 From: gbonneau at miranda.com (BONNEAU Guy) Date: Thu, 1 Apr 2010 08:26:49 -0400 Subject: [Live-devel] kindly help In-Reply-To: <000e0cd70c0058b4b2048324ec36@google.com> References: <000e0cdf1c0460e88e048317b787@google.com> <000e0cd70c0058b4b2048324ec36@google.com> Message-ID: <6353CA579307224BAFDE9495906E691604399B18@ca-ops-mail> Use Visual Studio express 2008. It is available for free. You can find it at : http://www.microsoft.com/express/Downloads/#2008-Visual-CPP This is the best I can do for you! And if you want to absolutely use Visual 2005 then download and use Visual Studio Express 2008 and study the projects setup that I sent to the list. Then use what you learned to setup Visual 2005. GB From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of sindhumaheswari at gmail.com Sent: Thursday, April 1, 2010 0:02 To: live-devel at ns.live555.com Subject: Re: [Live-devel] kindly help hi, thanks for the link . i saw it. but i am using visual 2005 and vc 6.0 for compiling. in this platform i want to build the openrtsp for rtsp client. here i am not able to build the testprogs.mak file. the above said libraries have to be linked with this file before building right ? kindly tell me how to link the libraries with this fiel in vc 6.0 and after building this file ? kindly help. thanks in advance On Mar 31, 2010 5:46pm, sindhumaheswari at gmail.com wrote: > hi all, > > > > > > > > > i am trying to replace the http client in my application with rtsp client. i found ur application worth, > > > > > > but i am having trouble in building it and adding it to my application. i have successfully built the first 4 libraries namely : basicusageenvironment, usageenvironment ,groupsock and live media. now i am trying to build the testprogs.mak i am facing some problems. > > > > > > also i face some probelm while building the openrtsp.cpp.please help me. i am working in vc 6.0 . also i am a new bie to tat. so kindlyhelp me build my rtsp client. > > > > > > kindlyhelp me > > > > > > > > > build log for testprogs.mak: > > > > > > "C:\Program Files\Microsoft Visual Studio 8\VC\bin\cl" -c -I../UsageEnvironment/include -I../groupsock/include -I../liveMedia/include -I../BasicUsageEnvironment/include -Z7 -Od -c -W3 -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -D_X86_=1 -D_WINNT -D_WIN32_WINNT=0x0400 -D_WIN32_IE=0x0300 -DWINVER=0x0400 -DWIN32 -D_WIN32 -D_MT -D_DLL -MD -I. -I"C:\Program Files\Microsoft Visual Studio 8\VC\include" testMP3Streamer.cpp > > > testMP3Streamer.cpp > > > link -out:testMP3Streamer.exe -debug:full -debugtype:cv msvcrt.lib /NODEFAULTLIB /INCREMENTAL:NO /PDB:NONE /RELEASE /NOLOGO -subsystem:console,4.0 msvcrt.lib oldnames.lib kernel32.lib ws2_32.lib mswsock.lib advapi32.lib testMP3Streamer.obj ../liveMedia/libliveMedia.lib ../groupsock/libgroupsock.lib ../BasicUsageEnvironment/libBasicUsageEnvironment.lib ../UsageEnvironment/libUsageEnvironment.lib > > > testMP3Streamer.obj : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > msvcrt.lib(cinitexe.obj) : warning LNK4078: multiple ".CRT" sections found with different attributes (C0300040) > > > libliveMedia.lib(RTCP.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(MPEG1or2AudioRTPSink.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(MediaSink.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(MP3FileSource.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(Media.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(RTPInterface.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(RTPSink.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(RTPSource.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(rtcp_from_spec.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(AudioRTPSink.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(MultiFramedRTPSink.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(FramedSource.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(MP3StreamState.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(FramedFileSource.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(MediaSource.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(InputFile.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(MP3Internals.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libliveMedia.lib(MP3InternalsHuffman.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libgroupsock.lib(Groupsock.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libgroupsock.lib(Groupsock.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libgroupsock.lib(NetAddress.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libgroupsock.lib(inet.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libgroupsock.lib(GroupsockHelper.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libgroupsock.lib(NetInterface.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libgroupsock.lib(NetInterface.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libgroupsock.lib(GroupEId.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libBasicUsageEnvironment.lib(BasicUsageEnvironment.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libBasicUsageEnvironment.lib(BasicTaskScheduler.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libBasicUsageEnvironment.lib(DelayQueue.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libBasicUsageEnvironment.lib(BasicHashTable.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libBasicUsageEnvironment.lib(BasicUsageEnvironment0.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libBasicUsageEnvironment.lib(BasicTaskScheduler0.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libUsageEnvironment.lib(strDup.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libUsageEnvironment.lib(UsageEnvironment.obj) : warning LNK4044: unrecognized option "manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"; ignored > > > libgroupsock.lib(Groupsock.obj) : error LNK2001: unresolved external symbol ___security_cookie > > > libgroupsock.lib(inet.obj) : error LNK2001: unresolved external symbol ___security_cookie > > > libgroupsock.lib(GroupsockHelper.obj) : error LNK2001: unresolved external symbol ___security_cookie > > > libliveMedia.lib(MultiFramedRTPSink.obj) : error LNK2001: unresolved external symbol ___security_cookie > > > libliveMedia.lib(MP3StreamState.obj) : error LNK2001: unresolved external symbol ___security_cookie > > > libliveMedia.lib(MP3Internals.obj) : error LNK2001: unresolved external symbol ___security_cookie > > > libliveMedia.lib(MP3InternalsHuffman.obj) : error LNK2001: unresolved external symbol ___security_cookie > > > testMP3Streamer.obj : error LNK2001: unresolved external symbol ___security_cookie > > > libliveMedia.lib(RTCP.obj) : error LNK2001: unresolved external symbol ___security_cookie > > > libliveMedia.lib(MP3FileSource.obj) : error LNK2001: unresolved external symbol ___security_cookie > > > libliveMedia.lib(RTPInterface.obj) : error LNK2001: unresolved external symbol ___security_cookie > > > libgroupsock.lib(Groupsock.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 > > > libgroupsock.lib(inet.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 > > > libgroupsock.lib(GroupsockHelper.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 > > > libliveMedia.lib(MultiFramedRTPSink.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 > > > libliveMedia.lib(MP3StreamState.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 > > > libliveMedia.lib(MP3Internals.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 > > > libliveMedia.lib(MP3InternalsHuffman.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 > > > testMP3Streamer.obj : error LNK2001: unresolved external symbol @__security_check_cookie at 4 > > > libliveMedia.lib(RTCP.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 > > > libliveMedia.lib(MP3FileSource.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 > > > libliveMedia.lib(RTPInterface.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 > > > libBasicUsageEnvironment.lib(BasicUsageEnvironment0.obj) : error LNK2001: unresolved external symbol __imp____iob_func > > > libliveMedia.lib(InputFile.obj) : error LNK2001: unresolved external symbol __imp____iob_func > > > libliveMedia.lib(MP3Internals.obj) : error LNK2001: unresolved external symbol __imp____iob_func > > > libliveMedia.lib(MP3InternalsHuffman.obj) : error LNK2001: unresolved external symbol __imp____iob_func > > > libBasicUsageEnvironment.lib(BasicUsageEnvironment.obj) : error LNK2001: unresolved external symbol __imp____iob_func > > > libliveMedia.lib(RTCP.obj) : error LNK2001: unresolved external symbol __imp____iob_func > > > libliveMedia.lib(MediaSink.obj) : error LNK2001: unresolved external symbol __imp____iob_func > > > libliveMedia.lib(RTPInterface.obj) : error LNK2001: unresolved external symbol __imp____iob_func > > > libliveMedia.lib(MP3StreamState.obj) : error LNK2001: unresolved external symbol __imp____iob_func > > > libliveMedia.lib(RTCP.obj) : error LNK2001: unresolved external symbol __ftol2_sse > > > libliveMedia.lib(InputFile.obj) : error LNK2001: unresolved external symbol __imp___stat64i32 > > > libgroupsock.lib(GroupsockHelper.obj) : error LNK2001: unresolved external symbol __imp___ctime64 > > > libgroupsock.lib(GroupsockHelper.obj) : error LNK2001: unresolved external symbol __imp___ftime64 > > > testMP3Streamer.exe : fatal error LNK1120: 7 unresolved externals > > > NMAKE : fatal error U1077: 'link' : return code '0x460' > > > Stop. > > > Error executing NMAKE. > > > > > > > > > error log for openrtsp: > > > > > > Command Lines > > > Creating temporary file "C:\DOCUME~1\e480177\LOCALS~1\Temp\RSP166.tmp" with contents > > > [ > > > kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /incremental:yes /pdb:"Debug/openRTSP.pdb" /debug /machine:I386 /out:"Debug/openRTSP.exe" /pdbtype:sept > > > ".\Debug\openRTSP.obj" > > > ] > > > Creating command line "link.exe @C:\DOCUME~1\e480177\LOCALS~1\Temp\RSP166.tmp" > > > Output Window > > > Linking... > > > openRTSP.obj : error LNK2001: unresolved external symbol "public: static class RTSPClient * __cdecl RTSPClient::createNew(class UsageEnvironment &,int,char const *,unsigned short)" (?createNew at RTSPClient@@SAPAV1 at AAVUsageEnvironment@@HPBDG at Z) > > > openRTSP.obj : error LNK2001: unresolved external symbol "unsigned short tunnelOverHTTPPortNum" (?tunnelOverHTTPPortNum@@3GA) > > > openRTSP.obj : error LNK2001: unresolved external symbol "public: char * __thiscall RTSPClient::sendOptionsCmd(char const *,char *,char *,class Authenticator *,int)" (?sendOptionsCmd at RTSPClient@@QAEPADPBDPAD1PAVAuthenticator@@H at Z) > > > openRTSP.obj : error LNK2001: unresolved external symbol "unsigned int statusCode" (?statusCode@@3IA) > > > openRTSP.obj : error LNK2001: unresolved external symbol "public: char * __thiscall RTSPClient::describeURL(char const *,class Authenticator *,unsigned int,int)" (?describeURL at RTSPClient@@QAEPADPBDPAVAuthenticator@@IH at Z) > > > openRTSP.obj : error LNK2001: unresolved external symbol "public: char * __thiscall RTSPClient::describeWithPassword(char const *,char const *,char const *,unsigned int,int)" (?describeWithPassword at RTSPClient@@QAEPADPBD00IH at Z) > > > openRTSP.obj : error LNK2001: unresolved external symbol "public: unsigned int __thiscall RTSPClient::setupMediaSubsession(class MediaSubsession &,unsigned int,unsigned int,unsigned int)" (?setupMediaSubsession at RTSPClient@@QAEIAAVMediaSubsession@@III at Z) > > > openRTSP.obj : error LNK2001: unresolved external symbol "public: unsigned int __thiscall RTSPClient::playMediaSession(class MediaSession &,double,double,float)" (?playMediaSession at RTSPClient@@QAEIAAVMediaSession@@NNM at Z) > > > openRTSP.obj : error LNK2001: unresolved external symbol "double duration" (?duration@@3NA) > > > openRTSP.obj : error LNK2001: unresolved external symbol "double scale" (?scale@@3NA) > > > openRTSP.obj : error LNK2001: unresolved external symbol "double initialSeekTime" (?initialSeekTime@@3NA) > > > openRTSP.obj : error LNK2001: unresolved external symbol "public: unsigned int __thiscall RTSPClient::teardownMediaSession(class MediaSession &)" (?teardownMediaSession at RTSPClient@@QAEIAAVMediaSession@@@Z) > > > LIBCD.lib(crt0.obj) : error LNK2001: unresolved external symbol _main > > > Debug/openRTSP.exe : fatal error LNK1120: 13 unresolved externals > > > Error executing link.exe. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adammich2 at gmail.com Thu Apr 1 11:47:16 2010 From: adammich2 at gmail.com (Adam Mich) Date: Thu, 1 Apr 2010 20:47:16 +0200 Subject: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ... Message-ID: Hi, I've found out that when you run a few different instances of RTSP clients in separate threads CSeq number is not increased by one with each consecutive request. It's because CSeq number is a static variable in RTSPClient. It has an unexpected side effect - SANYO network cameras end RTSP session with an error "Bad Request" when the current request's CSeq number is greater then CSeq of the previous one plus one. When I removed 'static' and made CSeq a local variable of RTSP client everything worked ok. In fact, I don't know if it is a bug in LiveMedia or in Sanyo firmware ... Does LiveMedia library conform to RTSP standard in this matter or maybe it is a bug in Sanyo devices ? Thanks in advance, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 1 19:06:33 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Apr 2010 19:06:33 -0700 Subject: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ... In-Reply-To: References: Message-ID: >I've found out that when you run a few different instances of RTSP >clients in separate threads CSeq number is not increased by one with >each consecutive request. >It's because CSeq number is a static variable in RTSPClient. This is a perfect illustration of why you are not supposed to run LIVE555 library code in multiple threads. (Have you read the FAQ entry about threads? If not, then why not (because you were asked to read the FAQ before you subscribed/posted to the mailing list)?) Instead, you should be using a single event loop (in a single thread) - even to make multiple RTSP client requests. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From guerreroderrick at gmail.com Thu Apr 1 19:58:01 2010 From: guerreroderrick at gmail.com (Derrick N. Guerrero) Date: Thu, 1 Apr 2010 21:58:01 -0500 Subject: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ... In-Reply-To: References: Message-ID: > > I've found out that when you run a few different instances of RTSP clients >> in separate threads CSeq number is not increased by one with each >> consecutive request. >> It's because CSeq number is a static variable in RTSPClient. >> > > This is a perfect illustration of why you are not supposed to run LIVE555 > library code in multiple threads. (Have you read the FAQ entry about > threads? If not, then why not (because you were asked to read the FAQ > before you subscribed/posted to the mailing list)?) > > Instead, you should be using a single event loop (in a single thread) - > even to make multiple RTSP client requests. > -- > > From the faq, Another possible way to access the code from multiple threads is to have each thread use its own "UsageEnvironment" and "TaskScheduler" objects, and thus its own event loop. The objects created by each thread (i.e., using its own "UsageEnvironment") must not interact (except via global variables). This is what I'm doing and haven't had a problem yet with our test servers. What I'm more interested in is from the original post: Does LiveMedia library conform to RTSP standard in this matter or maybe it is a bug in Sanyo devices ? I would think that even in single-threaded usage, if multiple RTSP client requests are required, then the CSeq would still increase by more than one. Also from the original post: SANYO network cameras end RTSP session with an error "Bad Request" when the current request's CSeq number is greater then CSeq of the previous one plus one. If this is expected behavior from the standard, I imagine I should make some changes before this actually becomes a problem... If this is a bug in the server implementation, I can make my bosses aware of it and try to steer away from such servers. Any advice? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoring at logitech.com Thu Apr 1 21:18:11 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Thu, 1 Apr 2010 21:18:11 -0700 Subject: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ... In-Reply-To: References: Message-ID: On Thu, Apr 1, 2010 at 7:06 PM, Ross Finlayson wrote: > I've found out that when you run a few different instances of RTSP clients >> in separate threads CSeq number is not increased by one with each >> consecutive request. >> It's because CSeq number is a static variable in RTSPClient. >> > > This is a perfect illustration of why you are not supposed to run LIVE555 > library code in multiple threads. (Have you read the FAQ entry about > threads? If not, then why not (because you were asked to read the FAQ > before you subscribed/posted to the mailing list)?) > > Instead, you should be using a single event loop (in a single thread) - > even to make multiple RTSP client requests. > I interpret what the OP is doing as this section in the FAQ: "Another possible way to access the code from multiple threads is to have each thread use its own "UsageEnvironment" and "TaskScheduler" objects, and thus its own event loop. The objects created by each thread (i.e., using its own "UsageEnvironment") must not interact (except via global variables)." ...if there's a dedicated thread for each RTSPClient, with its own UsageEnvironment and TaskScheduler objects, is that a valid configuration of the library? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Thu Apr 1 22:00:32 2010 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Thu, 01 Apr 2010 22:00:32 -0700 Subject: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ... In-Reply-To: References: Message-ID: <4BB579F0.9080900@schuckmannacres.com> On 4/1/2010 7:06 PM, Ross Finlayson wrote: >> I've found out that when you run a few different instances of RTSP >> clients in separate threads CSeq number is not increased by one with >> each consecutive request. >> It's because CSeq number is a static variable in RTSPClient. > > This is a perfect illustration of why you are not supposed to run > LIVE555 library code in multiple threads. (Have you read the FAQ > entry about threads? If not, then why not (because you were asked to > read the FAQ before you subscribed/posted to the mailing list)?) > > Instead, you should be using a single event loop (in a single thread) > - even to make multiple RTSP client requests. Ross, Actually your FAQ says "Another possible way to access the code from multiple threads is to have each thread use its own "UsageEnvironment" and "TaskScheduler" objects, and thus its own event loop. The objects created by each thread (i.e., using its own "UsageEnvironment") must not interact (except via global variables). " I have done this and so far it has worked fine, I haven't noticed if this particular problem has cropped up, but maybe LiveMedia RTSPserver is more forgiving. I can't say if the original poster did the same. From the sounds of it even if they did they'd have this problem. Is there any reason why that variable is a static? I can think of many cases where one may not have control over running all instances of RTSPClient in the same thread. One example is in a plug-in type environment. In one of my cases I've embedded RTSPClient in an ActiveX control and users of my control could run multiple instances of the control in their application or web page and I have no control over it. I've followed your FAQ and created an independent thread for each RTSPClient and in each case created it's own UsageEnvironment and TaskScheduler. I have been very careful to use thread safe mechanisms (not global's which are not thread safe) for cross thread communication. Are you now telling me that I shouldn't follow your FAQ? If this is the case can we please fix it? I personally find your disdain for threads antiquated and naive, I find a well thought out multi-threaded application easier to code, understand, debug, extensible, and with today's OS's and processors much more per-formant. Of course that's just my opinion and it's not to say that there is anything wrong with the way LiveMedia is implemented. I very much appreciate LiveMedia and the work you've done. Matt S. BTW Have you ever encountered anyone that has ever successfully implemented a TaskScheduler that was multi-threaded? I glanced at it once or twice but it didn't seem very straight forward and so wasn't worth it at the time. From finlayson at live555.com Fri Apr 2 00:28:46 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Apr 2010 00:28:46 -0700 Subject: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ... In-Reply-To: References: Message-ID: >This is what I'm doing and haven't had a problem yet with our test >servers. What I'm more interested in is from the original post: > >Does LiveMedia library conform to RTSP standard in this matter or >maybe it is a bug in Sanyo devices ? > >I would think that even in single-threaded usage, if multiple RTSP >client requests are required, then the CSeq would still increase by >more than one. Yes, and this probably does, indeed, violate the RTSP specification. I originally made "fCSeq" a static variable because I was worried about a server possibly getting confused if the same CSeq value were used by two separate requests from the same client host using the same URL - something that could happen if fCSeq were made a (non-static) member variable. (Note my comment in "liveMedia/include/RTSPClient.hh") In practice, however, this is probably not going to be a problem for most servers (because each request would use a separate TCP connection). Therefore, because we have now seen a server that - instead - has problems with the current implementation, I'll change it in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 2 00:34:26 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Apr 2010 00:34:26 -0700 Subject: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ... In-Reply-To: References: Message-ID: >I interpret what the OP is doing as this section in the FAQ: > >"Another possible way to access the code from multiple threads is to >have each thread use its own "UsageEnvironment" and "TaskScheduler" >objects, and thus its own event loop. The objects created by each >thread (i.e., using its own "UsageEnvironment") must not interact >(except via global variables)." Possibly, but remember that the "OP" used a "@gmail.com" address, which tags him as a noob (absence strong evidence to the contrary :-). Unfortunately, I've found that such people frequently do not read the FAQ. >...if there's a dedicated thread for each RTSPClient, with its own >UsageEnvironment and TaskScheduler objects, is that a valid >configuration of the library? Yes, although this is still not recommended - because of possible hidden 'gotchas' like this one. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Apr 2 01:10:54 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Apr 2010 01:10:54 -0700 Subject: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ... In-Reply-To: <4BB579F0.9080900@schuckmannacres.com> References: <4BB579F0.9080900@schuckmannacres.com> Message-ID: >I personally find your disdain for threads antiquated and naive This shows a lack of understanding. It's like saying that the designers of a bullet train have a "disdain" for air transportation, or conversely that the designers of an aircraft have a "disdain" for rail transport. On the contrary. We are talking about two completely different computation models, each with their pros and cons. I have been programming with threads since the mid 1980s - but for the LIVE555 libraries, I chose a single-threaded event-driven model instead. This works well for the type of applications that these libraries are typically used for, especially given that lots of inexperienced programmers (far more than I had originally anticipated, actually) are using the software. If anyone is interested in this topic, I encourage them to view Professor John Ousterhout's slide presentation: http://www.softpanorama.org/People/Ousterhout/Threads/tsld001.htm (Personally, I wouldn't state the conclusion quite as strongly as he does, but - as a very experienced threads programmer myself - I agree with the general argument.) >BTW Have you ever encountered anyone that has ever successfully >implemented a TaskScheduler that was multi-threaded? In principle, it would be possible to replace the "event loop" with an "event pool" that contains events (tasks) that could be claimed and acted on concurrently by multiple threads (i.e., with each thread claiming and acting on a single event (task) at a time). This would not, however, eliminate potential problems with concurrent access to shared data structures - so programmers (especially inexperienced programmers) would still likely run into problems there. (Plus, problems might arise from having events being handled in an unexpected and non-deterministic order.) So, the "multi-threaded event pool" would be a different computation model again from the existing "single-threaded event loop" - and one that it's unlikely that I would support, absent a complete redesign of the whole software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jnoring at logitech.com Fri Apr 2 09:14:06 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Fri, 2 Apr 2010 09:14:06 -0700 Subject: [Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ... In-Reply-To: References: <4BB579F0.9080900@schuckmannacres.com> Message-ID: On Fri, Apr 2, 2010 at 1:10 AM, Ross Finlayson wrote: > I personally find your disdain for threads antiquated and naive >> > > This shows a lack of understanding. It's like saying that the designers of > a bullet train have a "disdain" for air transportation, or conversely that > the designers of an aircraft have a "disdain" for rail transport. On the > contrary. We are talking about two completely different computation models, > each with their pros and cons. > > I have been programming with threads since the mid 1980s - but for the > LIVE555 libraries, I chose a single-threaded event-driven model instead. > This works well for the type of applications that these libraries are > typically used for, especially given that lots of inexperienced programmers > (far more than I had originally anticipated, actually) are using the > software. > > If anyone is interested in this topic, I encourage them to view Professor > John Ousterhout's slide presentation: > http://www.softpanorama.org/People/Ousterhout/Threads/tsld001.htm(Personally, I wouldn't state the conclusion quite as strongly as he does, > but - as a very experienced threads programmer myself - I agree with the > general argument.) I'd buy this. But I think the library itself must run the way the FAQ mentions; otherwise, it is seriously problematic to use in any realistic manner. It just makes sense to run one RTSPServer or RTSPClient per-thread with its own event loop. The truth of the matter is: the rest of the world uses threads, and I can count the number of projects I participate in that use an eventing model on one hand (on one finger, actually), and almost every media API I use besides this one makes heavy use of threads. Love threads or hate them, it is often tricky to reconcile this disparity. That said, I actually prefer the Live555 model for threading because it makes sense always to have a dedicated thread servicing the network. (doing work on your network thread, besides servicing the network, is a bad idea) But if I had to put multiple clients on a single thread...I'd basically be screwed. That doesn't mesh well with any decent media framework I can think of. Possibly, but remember that the "OP" used a "@gmail.com" address, which tags > him as a noob (absence strong evidence to the contrary :-). Unfortunately, > I've found that such people frequently do not read the FAQ. > Yeah....we're probably not going to agree on that one. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adammich2 at gmail.com Fri Apr 2 10:30:48 2010 From: adammich2 at gmail.com (Adam Mich) Date: Fri, 2 Apr 2010 19:30:48 +0200 Subject: [Live-devel] Problems with RTSPClient Message-ID: > Instead, you should be using a single event loop (in a single thread) > - even to make multiple RTSP client requests. Yes I know, but I have a few reasons to do it in multiple threads: You have to take into account that there is a limit on the number of sockets in a single FD_SET on most systems. On some systems the limit is only 64 sockets. So when you have an separate socket for RTSP, RTCP, RTP-audio and RTP-video you can open 16 sessions at most. Safe limit would be rather about 8 sessions, I think. >From what I found out RTSP client uses blocking calls and when it's sending requests it is blocking other sockets, so you can loose video or audio frames in other connections. It is undesirable effect if you are often creating and destroying RTSP sessions. When you have a multi core processor it is a good programming practice to create a one thread per core and spread all sessions between all available threads. Of course I didn't implement a multithreaded scheduler or something. I know that LiveMedia don't support thread pool architecture ( and thanks God, it looks good and fancy in academic books but it's debugging hell and you probably loose more trying to synchronize access to session data or even queue than gain from using multiple threads ). I saw your comment in code regarding making CSeq static. If there is a problem with other usage scenarios you can always move CSeq to BasicEnvironment class. It would be one CSeq variable per thread in that case. Thanks for all answers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From zelalems at hotmail.com Mon Apr 5 05:37:15 2010 From: zelalems at hotmail.com (Zelalem Sintayehu) Date: Mon, 5 Apr 2010 15:37:15 +0300 Subject: [Live-devel] How to stream an h263 encoded video file In-Reply-To: References: <39b9a2b31003250029g7f706219r6c4df00af98d1f04@mail.gmail.com>, Message-ID: Hi all, I was trying to create an rtsp proxy to send rtsp requests on behalf of other clients. Anyway, I followed the discussion on the another post on this forum to change the RTSPServer.cpp file to allow the setting of destination field and made LIVE555 server do what I really wanted. The problem I am having now is the server sends the stream to my clients properly but the client only has h263 codec and doesn't . But as I have seen the logs of Live555 the file types that it support are 'mpg' and m4e. And I couldn't convert my videos to mpg (with h263). So I suspected that mpg file can't contain h263. So, is there anyway that I can play a file with h263 codec video content. I used ffmpeg to convert my files to mpg (but couldn't succeed to create a file with h263 encoded video). Thank you. - Zelalem S. _________________________________________________________________ Hotmail: Trusted email with Microsoft?s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anslinuxlist at gmail.com Mon Apr 5 07:50:54 2010 From: anslinuxlist at gmail.com (ans linux) Date: Mon, 5 Apr 2010 20:20:54 +0530 Subject: [Live-devel] streaming h264 video with live555MediaServer Message-ID: Hi list, I want to stream h264 encoded ( mp4 encapsulated) video. >From the FAQ http://live555.com/liveMedia/faq.html#h264-streaming it seems like I may need to implement some class to use live555MeadiaServer to stream h264 video. I am pretty new to this and having very little programming experience in c++ . It will be great if some body can point me to a working modification to use live555media server to stream h264 video . My requirement is very minimal that I have to stream out a 2Mbps CBR video and no need to support multiple file sources. Thanks for your help in advance Ans -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Thu Apr 8 07:28:38 2010 From: rglobisch at csir.co.za (Ralf Globisch) Date: Thu, 8 Apr 2010 16:28:38 +0200 Subject: [Live-devel] AMR RTCP Synchronization Message-ID: Hi Ross, We recently added AMR support to our streaming system. In the system I rely on the RTPSource::hasBeenSynchronizedUsingRTCP flag to set offsets to the beginning of the stream and I noticed that this flag never gets set for AMR media unlike when streaming PCM and mp3, due to the RawAMRRTPSource overriding hasBeenSynchronizedUsingRTCP, returning fIsSynchronized which in turn never seems to get set. I can't see a reason why the RawAMRRTPSource overrides hasBeenSynchronizedUsingRTCP: Overridden hasBeenSynchronizedUsingRTCP method: Boolean RawAMRRTPSource::hasBeenSynchronizedUsingRTCP() { return fIsSynchronized; } Boolean& RawAMRRTPSource::isSynchronized() { return fIsSynchronized; } - In AMRDeinterleaver::doGetNextFrame, AMRDeinterleavingBuffer::retrieveFrame is called passing a reference to fInputSource->isSynchronized(). if (fDeinterleavingBuffer->retrieveFrame(fTo, fMaxSize, fFrameSize, fNumTruncatedBytes, fLastFrameHeader, fPresentationTime, fInputSource->isSynchronized())) - In AMRDeinterleavingBuffer::retrieveFrame, this ref gets set to the outBin.fIsSynchronized. resultIsSynchronized = outBin.fIsSynchronized; - And in AMRDeinterleavingBuffer::deliverIncomingFrame inBin.fIsSynchronized = ((RTPSource*)source)->hasBeenSynchronizedUsingRTCP(); which in turn calls the overridden hasBeenSynchronizedUsingRTCP method. I removed the overridden method and obtained the desired flag which seems like a satisfactory solution in our system. Is this a bug or am I overlooking something? Regards, Ralf FYI, the SDP for the AMR file looks as follows: v=0 o=- 1270728056462831 1 IN IP4 192.168.56.1 s=AMR Audio, streamed by the LIVE555 Media Server i=SleepWalk.amr t=0 0 a=tool:LIVE555 Streaming Media v2010.03.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:AMR Audio, streamed by the LIVE555 Media Server a=x-qt-text-inf:SleepWalk.amr m=audio 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:10 a=rtpmap:96 AMR/8000 a=fmtp:96 octet-align=1 a=control:track1 From rglobisch at csir.co.za Thu Apr 8 07:40:28 2010 From: rglobisch at csir.co.za (Ralf Globisch) Date: Thu, 8 Apr 2010 16:40:28 +0200 Subject: [Live-devel] Windows Media Player? Message-ID: This shouldn't be OT since it is related to live555: To add to Jeremy's comment, another option you could look at is to write a DirectShow sourcefilter that uses the live555 RTSP stack internally and to register the filter with the OS for the RTSP protocol. This is the approach we used to get around the WMP mess and should also work if the player is embedded in a webpage, provided that the DS filter has been registered on the system. From harishn at netxcell.com Tue Apr 6 21:59:37 2010 From: harishn at netxcell.com (Harish N) Date: Wed, 7 Apr 2010 10:29:37 +0530 Subject: [Live-devel] bandwidth consideration Message-ID: <007E0DB7F798F74CB459378DC49816370A4948C685@nxlmail.netxcell.com> Hi Ross and others, I am streaming a video using live555 and client as vlc. If I specify explicitly that my bandwidth is this much (from vlc to live555) what action does the live555 media server will take? Is anything related to this is defined in the implementation, by considering avaialble bandwidth? Any sort of help is highly appreciated Thanks Regards, Harish -------------- next part -------------- An HTML attachment was scrubbed... URL: From albalber at yahoo.com Thu Apr 8 08:44:22 2010 From: albalber at yahoo.com (Alberto Alberici) Date: Thu, 8 Apr 2010 08:44:22 -0700 (PDT) Subject: [Live-devel] rtcp and NAT Message-ID: <775872.81075.qm@web114112.mail.gq1.yahoo.com> Hi, is there a way to _force_? a client to send rtcp packets to another port than the one received in the rtsp handshaking? This would solve a lot of problems when the RTSP server is behind a NAT Otherwise, what could I do? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Apr 9 10:24:02 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 9 Apr 2010 10:24:02 -0700 Subject: [Live-devel] AMR RTCP Synchronization In-Reply-To: References: Message-ID: >I can't see a reason why the RawAMRRTPSource overrides >hasBeenSynchronizedUsingRTCP The intention was to make it work properly if AMR frames are interleaved within RTP packets. Suppose, for example, that - the first received RTP packet contains AMR frames 1,4,7 - the second received RTP packet contains AMR frames 2,5,8 - the third received RTP packet contains AMR frames 3,6,9 And suppose that the first received RTP packet is not RTCP-synchronized, but that the second, third etc. received RTP packets are RTCP-synchronized. In this case, when we deinterleave - and then deliver - the received AMR frames, we want to report that RTCP synchronization has occurred only for AMR frames starting with frame number 8 (because once "hasBeenSynchronizedUsingRTCP()" returns True, it is assumed to always return True from then on). However, it's now clear from the code that I didn't properly complete this implementation - i.e., you've discovered a bug in the code. I will try to fix this soon. In the meantime, please disable the reimplementation of the "hasBeenSynchronizedUsingRTCP()" virtual function - as you have done. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Apr 9 12:29:06 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 9 Apr 2010 12:29:06 -0700 Subject: [Live-devel] AMR RTCP Synchronization Message-ID: OK, I have now released a new version of this code that I thinks fixes this problem. (I haven't had a chance to test it, though, so if there's a problem, let me know.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Apr 9 12:54:00 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 9 Apr 2010 12:54:00 -0700 Subject: [Live-devel] bandwidth consideration In-Reply-To: <007E0DB7F798F74CB459378DC49816370A4948C685@nxlmail.netxcell.com> References: <007E0DB7F798F74CB459378DC49816370A4948C685@nxlmail.netxcell.com> Message-ID: >I am streaming a video using live555 and client as vlc. >If I specify explicitly that my bandwidth is this much (from vlc to >live555) what action does the live555 media server will take? >Is anything related to this is defined in the implementation, by >considering avaialble bandwidth? No. However, what you could do is have your server make available two or more different streams - with different bitrates - using different stream names. A client could then - if it wishes - select whichever stream it wants, using the appropriate stream name in the "rtsp://" URL. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lvshengye at gmail.com Fri Apr 9 13:21:26 2010 From: lvshengye at gmail.com (Shengye Lu) Date: Fri, 9 Apr 2010 23:21:26 +0300 Subject: [Live-devel] rtcp and NAT In-Reply-To: <775872.81075.qm@web114112.mail.gq1.yahoo.com> References: <775872.81075.qm@web114112.mail.gq1.yahoo.com> Message-ID: Hi, Is RTSP server or client behind a NAT? For the case of RTSP client behind NAT, solutions are: 1. using RTSP application layer firewall proxy. 2. interleaving RTP/RTCP with RTSP, to transmit RTP/RTCP and RTSP via the same TCP connection. Shengye On Thu, Apr 8, 2010 at 6:44 PM, Alberto Alberici wrote: > Hi, > > is there a way to _force_ a client to send rtcp packets to another port > than the one received in the rtsp handshaking? > This would solve a lot of problems when the RTSP server is behind a NAT > > Otherwise, what could I do? > > thanks > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -- Shengye -------------- next part -------------- An HTML attachment was scrubbed... URL: From jabirm at gmail.com Sat Apr 10 21:45:10 2010 From: jabirm at gmail.com (jabir) Date: Sun, 11 Apr 2010 00:45:10 -0400 Subject: [Live-devel] multiple RTSP client using event loop Message-ID: Hi Ross, I have tried to implement Multiple RTSP client using event loop instead of threads and it is working fine now. I have used XML parser to read the inputs from an XML file.. I have attached the source files please point out the bugs in the code if any so that i can rectify the code. Thanks, Jabir -------------- next part -------------- A non-text attachment was scrubbed... Name: playCommon.hh Type: text/x-c++hdr Size: 2592 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: playCommon.hh Type: text/x-c++hdr Size: 2592 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testXML.xml Type: text/xml Size: 5057 bytes Desc: not available URL: From rglobisch at csir.co.za Mon Apr 12 05:06:16 2010 From: rglobisch at csir.co.za (Ralf Globisch) Date: Mon, 12 Apr 2010 14:06:16 +0200 Subject: [Live-devel] AMR RTCP Synchronization Message-ID: Ross, thanks for the quick fix, I tested it and everything looks good. Also, thanks for the explanation concerning the synchronisation of deinterleaved AMR frames. Regards, Ralf From yaron at emza-vs.com Mon Apr 12 08:54:28 2010 From: yaron at emza-vs.com (Yaron Levy) Date: Mon, 12 Apr 2010 17:54:28 +0200 Subject: [Live-devel] Streaming H264 difficulties Message-ID: <009701cada58$6f22a880$337ba8c0@YARON> Hi, I am working on a RTSP RTP-over-TCP H264 streaming application from a live HW-based encoder. I have implemented MyDeviceSource, MyH264VideoStreamFramer, H264DeviceMediaSubsession and MyH264App based on testOnDemandRTSPServer. In general the application works and I get the live stream. The intended viewer application is VLC on a remote machine in the same LAN, where bandwidth is a non-issue. I've encountered 2 obstacles that have been giving me a hard time: 1. "Glitches" in the video output. After every (quite small) amount of frames the video "glitches" and I get block artifacts, and frames that seem to jump back in time. From playing around with the presentation times, I thought it might be related to this. My approach to fPresentationTime is to set it to gettimeofday() every GOP (i.e. SPS/PPS frames), and increment by 1000000/FPS for every encoded frame. The encoder encodes frame by frame only. When I use openRTSP as the client, the video file is saved perfectly, which no glitches. 2. The streaming server (OS is Linux2.6) is also used for other cpu-intensive processes. This is a requirement. The machine is practically constantly at 100% cpu usage. However, it practically does not use any network resources. When this is the situation, the video glitches become overwhelming, and it seems the client has a very hard time handling the stream and sometimes even disconnects. So the question is how and where is Live555 subject to cpu load, and why does it have such a catastrophic effect on the video output given that network usage is low. Could this be related also to (1)? Thanks, Yaron Levy Emza Visual Sense Ltd. Research & Development Email: yaron at emza-vs.com Tel: (972)-52-2968679 -------------- next part -------------- An HTML attachment was scrubbed... URL: From siddeeqhssn at yahoo.com Sun Apr 11 12:30:43 2010 From: siddeeqhssn at yahoo.com (Siddeeq Hssn) Date: Sun, 11 Apr 2010 12:30:43 -0700 (PDT) Subject: [Live-devel] howto read live555 stream? using vlc Message-ID: <794025.429.qm@web51007.mail.re2.yahoo.com> hi all i want to stream video form linux to window using c++ and i use live555 and success and the output is stdout. and i install vlc0.9.9 and use activex and i can play video using vb.net. now how i can send video from linux using live555 and read that video using vlc (by using any language VC++ or VB.net using activex) need help please, thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sahucd at sbcglobal.net Mon Apr 12 10:38:50 2010 From: sahucd at sbcglobal.net (DAVID SAHUC) Date: Mon, 12 Apr 2010 10:38:50 -0700 (PDT) Subject: [Live-devel] Client issue with large IP packets during interrop tests Message-ID: <968020.53455.qm@web82602.mail.mud.yahoo.com> Hi, We've had some issues while testing Live555 client (e.g. openRTSP, even on April 9th release) with our RTSP server while serving larger IP packets (containing MPEG-2 TS but that might impact other modes). Above a certain IP packet size, openRTSP doesn't receive correctly (data loss). I've had a hard time to trace where this error was coming from and I found the following line in MultiFramedRTPSource.cpp : #define MAX_PACKET_SIZE 10000 The maximum IP datagram size is 65535 bytes; IP datagrams are fragmented by the IP layer (RFC 791). This can be easily fixed replacing this code with (at least on Linux, not tried on other OSes tho there shall be an equivalent): #include #define MAX_PACKET_SIZE IP_MAXPACKET It also seems Live555 server(s) "only" serves 1316 bytes packets in MPEG-2 TS 188 mode. It looks like you're trying to fit as many TS packets as you can in 1500 bytes but MTU of 1500 bytes only applies to Ethernet frames (plus it exists now "Jumbo frames" that can reach 9000 bytes). Fragmentation being managed at IP layer, you could serve bigger packets (up to max IP datagram size, i.e. 65KB). Note that sending "only" 7 TS packets in an IP packet is totally fine, but adds more overhead (IP headers, etc.) over time. Sending bigger packets is recommended, while it needs benchmarking to find the optimal packet size for performance (a bit bellow 16KB in our tests for our environment); this can be different depending on O.S. & HW. Maybe you will want to introduce, as we do, an "IP packet size" as a parameter for your server(s) (at least in MPEG-2 TS mode). Hope this helps. David. From finlayson at live555.com Mon Apr 12 11:29:33 2010 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 12 Apr 2010 11:29:33 -0700 Subject: [Live-devel] Client issue with large IP packets during interrop tests In-Reply-To: <968020.53455.qm@web82602.mail.mud.yahoo.com> References: <968020.53455.qm@web82602.mail.mud.yahoo.com> Message-ID: IP fragmentation is a very bad idea, and should be avoided. (The reason for this is that if any IP fragment is lost, the whole IP packet will be discarded, even if the remaining fragments happened to contain useful data.) Instead, RTP/UDP/IP packets should always be small enough to fit within a network's MTU (even if the theoretical maximum size of an IP packet is much larger). For almost all networks, the MTU will be at least 1500 bytes, which is why we set the maximum RTP packet size - by default - to 1448 bytes. Note the call to setPacketSizes(1000, 1448); in "MultiFramedRTPSink.cpp". If you want to increase this number (i.e., for a larger MTU), then you can do this by calling "setPacketSizes()" on your "MultiFramedRTPSink" (subclass) object. Note that you *do not* need to modify the existing supplied source code to do this. It is true, however, that we currently 'hardwire' a 7 Transport-Packets-per-RTP-packet limit when streaming Transport Stream data - i.e., the definition of "TRANSPORT_PACKETS_PER_NETWORK_PACKET" in "MPEG2TransportFileServerMediaSubsession.cpp". This is one case where you would need to modify the supplied code if you wanted to change this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sahucd at sbcglobal.net Mon Apr 12 12:13:16 2010 From: sahucd at sbcglobal.net (DAVID SAHUC) Date: Mon, 12 Apr 2010 12:13:16 -0700 (PDT) Subject: [Live-devel] Client issue with large IP packets during interrop tests In-Reply-To: References: <968020.53455.qm@web82602.mail.mud.yahoo.com> Message-ID: <470909.20208.qm@web82604.mail.mud.yahoo.com> Agreed, in a general case, MTU is 1500; but for network owners (with control of routers), or for point to point applications, control/use of this parameter is flexible (helped sometimes by "path MTU discovery"). Sorry if I was not clear enough, I was not talking of the Sink but MultiFramedRTPSource.cpp's BufferedPacket: if you do not modify MAX_PACKET_SIZE, there is loss of data on the client side for packets sizes above the defined 10000 bytes "out of the box" (since we're just using it as is for interop tests). I guess that would also apply if one increase TRANSPORT_PACKETS_PER_NETWORK_PACKET above 53 in Live555 server(s) and use openRTSP as a client. Since we're just in our case using Live555 for interop tests, one option live555 could also use to avoid having another server (than Live555's) sending too big IP packets is the RTSP "Blocksize" to restrict to its defined MAX_PACKET_SIZE: http://tools.ietf.org/html/rfc2326#page-47 David. ----- Original Message ---- From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Mon, April 12, 2010 8:29:33 PM Subject: Re: [Live-devel] Client issue with large IP packets during interrop tests IP fragmentation is a very bad idea, and should be avoided. (The reason for this is that if any IP fragment is lost, the whole IP packet will be discarded, even if the remaining fragments happened to contain useful data.) Instead, RTP/UDP/IP packets should always be small enough to fit within a network's MTU (even if the theoretical maximum size of an IP packet is much larger). For almost all networks, the MTU will be at least 1500 bytes, which is why we set the maximum RTP packet size - by default - to 1448 bytes. Note the call to setPacketSizes(1000, 1448); in "MultiFramedRTPSink.cpp". If you want to increase this number (i.e., for a larger MTU), then you can do this by calling "setPacketSizes()" on your "MultiFramedRTPSink" (subclass) object. Note that you *do not* need to modify the existing supplied source code to do this. It is true, however, that we currently 'hardwire' a 7 Transport-Packets-per-RTP-packet limit when streaming Transport Stream data - i.e., the definition of "TRANSPORT_PACKETS_PER_NETWORK_PACKET" in "MPEG2TransportFileServerMediaSubsession.cpp". This is one case where you would need to modify the supplied code if you wanted to change this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From flying5yue at sina.com Mon Apr 12 18:42:23 2010 From: flying5yue at sina.com (flying5yue at sina.com) Date: Tue, 13 Apr 2010 09:42:23 +0800 Subject: [Live-devel] about the rtp payload for mpa Message-ID: <20100413014223.7CF8584516@mail3-43.sinamail.sina.com.cn>  my dear developers of live555:     I have some questions about the rtp payload for mpa(type is 14) when i use testOnDemandRTSPServer to stream mp3 file.When i capture packet via Wireshark(an network capture tools), on the rtp layer, the payload of the rtp packet is composed of audio frames.It strongly trouble me thatthe composed way. Sometimes, 3 or 4 auido frames are involved and the total length is nearly the MTU(1350Bytes).But sometimes, only 2 audioframes are involved and the total length is far below the MTU, and i think next audio frame can be involved because there is enough space.     Could you tell me the composed way of the rtp payload for audio frames, please? Where can i find the composed code in Live555 code?                Sincerely!              Yours pei liu. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcos at a5security.com Thu Apr 15 01:25:00 2010 From: marcos at a5security.com (Miguel Angel Arcos) Date: Thu, 15 Apr 2010 10:25:00 +0200 Subject: [Live-devel] Client reconnect with the same server Message-ID: Hi Ross & the other developers, I'm having one problem when I try to reconnect the connection with the same server. On the first connecton all its ok, I call getNextFrame and receive the data on my AfterReadingFrame function. The problem comes when I disconnect from the server, I'm closing with teardown and destroying all the object, and try to reconnect. In the process of the second connect all is Ok and after the call of the getNextFrame I don't receive the data on the AfterReadingFrame function but if I see with wireshark for example I'm receiving the data. Then why the AfterReadingFrame not receive any data? Thanks in advance. PD: I think is a problem closing my first connection but I can't see where is the error. -- Miguel Angel Arcos -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk.raffel at de.transport.bombardier.com Thu Apr 15 03:13:54 2010 From: dirk.raffel at de.transport.bombardier.com (dirk.raffel at de.transport.bombardier.com) Date: Thu, 15 Apr 2010 12:13:54 +0200 Subject: [Live-devel] SegmentQueue::enqueueNewSegment() overflow Message-ID: Hello everyone, First, let me say that I'm totally new to Live555 and multimedia streaming in general. I'm planning to build an on-demand RTSP server for streaming WAV and/or MP3 files via RTP unicast to an RTSP client. I've built and tried the TestOnDemandRTSPServer in the testProgs directory. Streaming a WAV file works flawless, but when streaming a MP3 file I get the error SegmentQueue::enqueueNewSegment() overflow which is generated in MP3ADU.cpp. While increasing SegmentQueueSize obviously helps in avoiding this error, there are still a lot of "gaps" in the playback. Tested with latest release live.2010.04.09 on multiple platforms (Linux, Windows/MinGW) with different clients (VLC, openRTSP). If needed, I've uploaded my MP3 test file under http://docs.google.com/leaf?id=0B6vp23tQ3ixPYTkxMGYxMzktYmM4ZS00YzIzLWFmM2EtNzFhMDZiMTRiMmI2&hl=en Am I doing something wrong? What does this mean? Best regards, Dirk Raffel _______________________________________________________________________________________________________________ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Please note that in order to protect the security of our information systems an AntiSPAM solution is in use and will browse through incoming emails. Thank you. _________________________________________________________________________________________________________________ Ce message (ainsi que le(s) fichier(s)), transmis par courriel, peut contenir des renseignements confidentiels ou prot?g?s et est destin? ? l?usage exclusif du destinataire ci-dessus. Toute autre personne est, par les pr?sentes, avis?e qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez re?u par inadvertance, veuillez nous en aviser et d?truire ce message. Veuillez prendre note qu'une solution antipollupostage (AntiSPAM) est utilis?e afin d'assurer la s?curit? de nos syst?mes d'information et qu'elle fur?tera les courriels entrants. Merci. _________________________________________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.nemec at atlas.cz Thu Apr 15 05:25:40 2010 From: a.nemec at atlas.cz (=?utf-8?B?TsSbbWVjIEFsZXhhbmRy?=) Date: Thu, 15 Apr 2010 12:25:40 GMT Subject: [Live-devel] Threads and event loops Message-ID: <379ce6ee516b473282c706c19be55b24@4cf9bd62fe1843b9936dc122ed76e231> An HTML attachment was scrubbed... URL: -------------- next part -------------- Dear Ross (and anybody), I followed all the posts about threading and event loops some days ago. I also reviewed the FAQ once more and because I had done it several times in the past, it seems to me that the recommendation "Such a configuration is not recommended, however; instead, it is safer to structure such an application as multiple processes, not multiple threads." has been added recently and was not there just some weeks ago. Am I right? When this configuration (more event loops running in separate threads with dedicated usage environments and task schedulers) is not recommended any more, it is bad news for us because our application is structured exactly in this configuration. Nevertheless, we have not seen any problems in this configuration so far, in our tests we are running up to 20 threads in one process, each thread is responsible for exactly one RTSP server. Could you, please, be more specific why this configuration is not recommended? Are there any known problems with this configuration? (I think the problem can be some static variables but since we compiled the live555 code to a Windows COM library and create one instance of a COM object for each RTSP client, maybe the static variables are not touched by other instances, but I am not sure about this). Finally, according to my opinion, this approach is far better than having just one thread to be responsible for many RTSP servers because the code contains blocking operations and it can easily happen that longer response times or a low speed network connection of one RTSP server can have a negative impact on the video streams from other RTSP servers or am I completely wrong? Best regards and thanks very much for your answers Alex From finlayson at live555.com Thu Apr 15 14:02:24 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Apr 2010 14:02:24 -0700 Subject: [Live-devel] about the rtp payload for mpa In-Reply-To: <20100413014223.7CF8584516@mail3-43.sinamail.sina.com.cn> References: <20100413014223.7CF8584516@mail3-43.sinamail.sina.com.cn> Message-ID: > I have some questions about the rtp payload for mpa(type is 14) >when i use testOnDemandRTSPServer to stream mp3 file.When i capture >packet via Wireshark(an network capture tools), on the rtp layer, >the payload of the rtp packet is composed of audio frames.It >strongly trouble me thatthe composed way. Sometimes, 3 or 4 auido >frames are involved and the total length is nearly the >MTU(1350Bytes).But sometimes, only 2 audioframes are involved and >the total length is far below the MTU, and i think next audio frame >can be involved because there is enough space. The RTP packaging code "MultiFramedRTPSink" usually fits as many frames as possible within each outgoing packet. However - to use your example - if it has already packed 2 frames into a packet, it will send the packet immediately if it thinks that the 3rd frame (that it has not yet seen) will overflow the packet. It does this by looking at the size of the most recently packed packet (the 2nd, in this case), and guessing that the 3rd frame will likely be the same size. If another frame of the same size would overflow the packet, then the packet will be sent immediately, without waiting for the 3rd packet to arrive. This is for efficiency; if the 3rd frame would indeed overflow the packet, then it would be somewhat inefficient to have to buffer its data to use later. But if the 3rd frame in fact would *not* have overflowed the packet, then yes, we will send a packet that's somewhat smaller than it could have been. (But this doesn't really matter; this should not "strongly trouble" you.) Note that this is only an issue for VBR streams, because those are the only streams for which the frame sizes can vary. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jnoring at logitech.com Thu Apr 15 11:43:11 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Thu, 15 Apr 2010 11:43:11 -0700 Subject: [Live-devel] SegmentQueue::enqueueNewSegment() overflow In-Reply-To: References: Message-ID: On Thu, Apr 15, 2010 at 3:13 AM, wrote: > > Hello everyone, > > First, let me say that I'm totally new to Live555 and multimedia streaming > in general. I'm planning to build an on-demand RTSP server for streaming WAV > and/or MP3 files via RTP unicast to an RTSP client. > > I've built and tried the TestOnDemandRTSPServer in the testProgs directory. > Streaming a WAV file works flawless, but when streaming a MP3 file I get the > error > > SegmentQueue::enqueueNewSegment() overflow > > which is generated in MP3ADU.cpp. While increasing SegmentQueueSize > obviously helps in avoiding this error, there are still a lot of "gaps" in > the playback. > When I ran Live555 through static code analysis, a bunch of stuff in the MP3 portions of the library was flagged, including several potential buffer overflows. I didn't do anything about it because I don't use MP3 (sorry) but some of the stuff could definitely be related to your overflow: Warning 5 warning C6385: Invalid data: accessing 'fSegments->s', the readable size is '20320' bytes, but '1572768' bytes might be read: Lines: 173, 174, 175, 177, 181, 182, 185, 189, 197, 198, 199, 200, 203, 205, 213, 215, 220, 222, 225, 226, 227, 228, 229, 230, 231, 234, 240, 244, 245, 246 mp3adu.cpp 246 Warning 6 warning C6246: Local declaration of 'bytesToZero' hides declaration of the same name in outer scope. For additional information, see previous declaration at line '442' of 'mp3adu.cpp': Lines: 442 mp3adu.cpp 471 Warning 12 warning C4996: 'fdopen': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _fdopen. See online help for details. MP3HTTPSource.cpp 55 Warning 28 warning C6386: Buffer overrun: accessing 'si.ch', the writable size is '480' bytes, but '720' bytes might be written: Lines: 432, 438, 439, 441, 442, 445, 447, 448, 450, 451 mp3internals.cpp 451 Warning 25 warning C6386: Buffer overrun: accessing 'si.ch', the writable size is '480' bytes, but '720' bytes might be written: Lines: 349, 355, 356, 358, 359, 362, 364, 365 mp3internals.cpp 365 Warning 27 warning C6385: Invalid data: accessing 'si.ch', the readable size is '480' bytes, but '720' bytes might be read: Lines: 432, 438, 439, 441, 442, 445, 447, 448 mp3internals.cpp 448 Warning 26 warning C6385: Invalid data: accessing 'si.ch', the readable size is '480' bytes, but '720' bytes might be read: Lines: 349, 355, 356, 358, 359, 362, 364, 365, 366, 364, 365, 366, 364, 365, 366, 364, 369, 370, 371 mp3internals.cpp 371 Warning 24 warning C6385: Invalid data: accessing 'live_tabsel[isMPEG2]', the readable size is '192' bytes, but '384' bytes might be read: Lines: 157, 158, 159, 166, 167, 168, 170, 173, 176, 178, 179, 180, 181, 182, 183, 184, 186, 188, 194 mp3internals.cpp 194 Warning 23 warning C6244: Local declaration of 'slen' hides previous declaration at line '434' of 'mp3internalshuffman.cpp' mp3internalshuffman.cpp 505 Warning 22 warning C6054: String 'command' might not be zero-terminated: Lines: 341, 342, 343, 344, 345, 346, 350, 351, 353, 355 mp3internalshuffman.cpp 355 Warning 19 warning C6031: Return value ignored: 'sscanf' mp3internalshuffman.cpp 353 Warning 20 warning C6031: Return value ignored: 'sscanf' mp3internalshuffman.cpp 365 Warning 21 warning C6031: Return value ignored: 'sscanf' mp3internalshuffman.cpp 376 Warning 18 warning C6385: Invalid data: accessing 'hbuf', the readable size is '3' bytes, but '4' bytes might be read: Lines: 226, 227, 228, 230, 231, 233, 241, 242, 243, 252, 259, 268, 288, 289, 290, 293, 294 mp3streamstate.cpp 294 Warning 16 warning C6385: Invalid data: accessing 'argument 2', the readable size is '2500' bytes, but '1048556' bytes might be read: Lines: 153, 155, 166, 167, 168, 169, 170, 171, 173 mp3streamstate.cpp 173 Warning 17 warning C6053: Call to '_snprintf' might not zero-terminate string 'writeBuf': Lines: 201, 203, 204, 205, 206, 212, 215 mp3streamstate.cpp 215 Warning 13 warning C4996: 'fileno': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _fileno. See online help for details. MP3StreamState.cpp 417 Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemens.arth at gmx.at Fri Apr 16 01:04:24 2010 From: clemens.arth at gmx.at (Clemens Arth) Date: Fri, 16 Apr 2010 10:04:24 +0200 Subject: [Live-devel] XVid + Live555 Message-ID: <4BC81A08.9010105@gmx.at> Hi, I just found a single post from quite some time ago discussing this issue without real outcome. My goal is to compress live camera input from a windows mobile or android phone, probably with XVID, and stream it over Live555 and WLAN to a single client. From the sources I have seen that there are many different media formats supported, however, I haven't seen anything related to xvid. Now, I have two questions: 1) Does someone have a solution for streaming xvid content that he/she can share? I'm neither into xvid nor live555, so any help here is appreciated. 2) Assuming xvid streaming does not work out, can someone point me to other video encoder sources that are freely available? Unfortunately I haven't found any other compact libraries other than xvid so far. Thanks in advance! Regards From erpat_vig at hotmail.com Fri Apr 16 09:00:00 2010 From: erpat_vig at hotmail.com (Erpat Vig) Date: Fri, 16 Apr 2010 16:00:00 +0000 Subject: [Live-devel] H264FUAFragmenter fNumValidDataBytes problem Message-ID: Hello everybody, I am developing an h264 framer with a parser by following the same approach than Mike Gilormas. I parse normally a NAL_Start_Sequence and a Nal_Unit, I have never seen my parser recalled thereafter (it?s bugging before). The problem is localised in FUAFragmenter::doGetNextFrame, After a while, (around 100 packet RTP sent), there is a reading problem of the InputBuffer, at this level: memmove(fTo, &fInputBuffer[fCurDataOffset-2], numBytesToSend); because: fCurDataOffset= 70268 numBytesToSend= 3452746591 The problem comes from the fact that fNumValidDataBytes (if i well understand) is absurdly enormous and is never reinitialized (the first frameSize is worth 3452816845, after it is worth 11). As you can note below, fNumValidDataByte increase much more than fCurDataOffset. I don?t know how to solve this, I guess fNumValidDataBytes has to be correctly reinitialized, but i don?t know how. Indeed the first frameSize in H264FUAFragmenter is 3452816845 worth while the acquiredFrameSize from H264FUAFragmenter is 0! Otherwise, I implemented framedFilter for my H264VideoStreamFramer, may be is it problematic and the reason of that mess? Here is my fileLog: On the beginning (first packet) in H264VideoStreamFramer::continueReadProcessing() acquiredFrameSize = 0 need to do somemore reading here to get a frame!!!! H264VideoStreamParser::getParseState() lets check parse state: 0 H264VideoStreamParser::getParseState() FramedSource::afterGetting(source) in H264FUAFragmenter::afterGettingFrame(void* clientData, unsigned frameSize,unsigned numTruncatedBytes,struct timeval presentationTime,unsigned durationInMicroseconds) in H264FUAFragmenter::afterGettingFrame1(void* clientData, unsigned frameSize,unsigned numTruncatedBytes,struct timeval presentationTime,unsigned durationInMicroseconds) frameSize= 3452816845//weird if we consider that acquiredFrameSize=0 fNumValidDataBytes =1 fNumValidDataBytes += frameSize =3452816846 in H264FUAFragmenter::doGetNextFrame() fNumValidDataBytes= 3452816846 later i have this: in H264VideoStreamFramer::continueReadProcessing() acquiredFrameSize = 11 continueReadProcessing, acquiredFrameSize: 11 FramedSource::afterGetting(source) in H264FUAFragmenter::afterGettingFrame(void* clientData, unsigned frameSize,unsigned numTruncatedBytes,struct timeval presentationTime,unsigned durationInMicroseconds) in H264FUAFragmenter::afterGettingFrame1(void* clientData, unsigned frameSize,unsigned numTruncatedBytes,struct timeval presentationTime,unsigned durationInMicroseconds) frameSize= 11 fNumValidDataBytes =3452816846 fNumValidDataBytes += frameSize =3452816857 in H264FUAFragmenter::doGetNextFrame() Could you provide some piece of advice? Best Regards, and by the way thank you for the work done. Patrick Vigle. _________________________________________________________________ Consultez vos emails Orange, Gmail, Yahoo!, Free ... directement depuis HOTMAIL ! http://www.windowslive.fr/hotmail/agregation/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoring at logitech.com Mon Apr 19 11:32:24 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Mon, 19 Apr 2010 11:32:24 -0700 Subject: [Live-devel] XVid + Live555 In-Reply-To: <4BC81A08.9010105@gmx.at> References: <4BC81A08.9010105@gmx.at> Message-ID: On Fri, Apr 16, 2010 at 1:04 AM, Clemens Arth wrote: > 2) Assuming xvid streaming does not work out, can someone point me to > other video encoder sources that are freely available? Unfortunately I > haven't found any other compact libraries other than xvid so far. > IMO, I wouldn't bother with xvid, which is basically just MPEG-4. For any new work, I'd go with H264. x264 is the library I'd look into. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chouhan.nishesh at gmail.com Mon Apr 19 06:52:28 2010 From: chouhan.nishesh at gmail.com (nishesh chouhan) Date: Mon, 19 Apr 2010 19:22:28 +0530 Subject: [Live-devel] live55 with settop box Message-ID: Hi, I am using live555 with set top box(STB) but the STB is not playing audio, I am using libfaac for audio and Mpeg4 for video what I want to confirm is that can the client request for a codec format it understands to a server ?? I read RTSP rfc and found ANNOUNCE can be used from client to desire media initialization from server though I am not well versed with rtsp. I may be wrong in understanding, pls anyone guide me. Thanks in Advance, Nishesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.kreker at fkie.fraunhofer.de Tue Apr 20 07:01:33 2010 From: paul.kreker at fkie.fraunhofer.de (Kreker, Paul) Date: Tue, 20 Apr 2010 16:01:33 +0200 Subject: [Live-devel] First Application Message-ID: <1FF0CFC89178B64DBD5CF6696750AC4338885F@mailserv1.lorien.fkie.fgan.de> Hi to everybody, I would like to program a tool for saving the frames of a commercially IP-Cam into a memory buffer using the live555-library. This memory buffer data should afterwards be sent to a Qt-GUI for displaying the pictures. All I tried so far was using some source code from openRTSP, but I could actually not figure out where to grab the data. Maybe there is anyone around, who is experienced in motion picture processing? Could you give me a hint, which Class to use and how to be more successful? How to figure this out? Are there any additional steps, which should be taken into account for displaying the data using Qt? Thanx for any kind of support ------------------------------------------------------------------------------------------------------ Paul Kreker Auszubildender zum Fachinformatiker f?r Anwendungsentwicklung Fraunhofer-Institut f?r Kommunikation, Informationsverarbeitung und Ergonomie (FKIE) Abteilung Sensordaten und Informationsfusion (SDF) Neuenahrer Str. 20 53343 Wachtberg Germany Fon: +49 228 9435 456 Email: Paul.Kreker at fkie.fraunhofer.de Web: www.fgan.de ------------------------------------------------------------------------------------------------------ Diese E-Mail kann vertrauliche und/oder rechtlich gesch?tzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren, Verbreiten sowie die unbefugte Weitergabe dieser E-Mail, ihrer Anh?nge und/oder deren jeweiliger Inhalte ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of this e-mail, its attachments and/or the information contained therein is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3792 bytes Desc: image001.gif URL: From den.dgtex at gmail.com Tue Apr 20 07:42:59 2010 From: den.dgtex at gmail.com (Denis Z) Date: Tue, 20 Apr 2010 18:42:59 +0400 Subject: [Live-devel] Live555 on iPhone Message-ID: Hi! We would like to use live555 RTSP client on iPhone, but we faced the problem - we don't know how to build live555 for iPhone device (arm). There are several config files, but no one could be used to build live555 for iPhone. What can you suggest, what should we do? Thanks! Denis. From finlayson at live555.com Tue Apr 20 08:05:34 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Apr 2010 08:05:34 -0700 Subject: [Live-devel] First Application In-Reply-To: <1FF0CFC89178B64DBD5CF6696750AC4338885F@mailserv1.lorien.fkie.fgan.de> References: <1FF0CFC89178B64DBD5CF6696750AC4338885F@mailserv1.lorien.fkie.fgan.de> Message-ID: >All I tried so far was using some source code from openRTSP, but I >could actually not figure out where to grab the data. The "openRTSP" code (in "testProgs/playCommon.cpp") saves its incoming data into a file - using the "FileSink" class. Note that "FileSink" is a subclass of "MediaSink", and implements the virtual function "continuePlaying()". If you want to instead do something else with the incoming data, you would use a different subclass (that you would write) of "MediaSink". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Tue Apr 20 09:37:42 2010 From: matt at schuckmannacres.com (Matt Schuckmann) Date: Tue, 20 Apr 2010 09:37:42 -0700 Subject: [Live-devel] Live555 on iPhone In-Reply-To: References: Message-ID: <4BCDD856.7070203@schuckmannacres.com> Basically create a Xcode project for each of the Live555 libraries yourself. I did it a while back and it worked fine. Matt S. On 4/20/2010 7:42 AM, Denis Z wrote: > Hi! > > We would like to use live555 RTSP client on iPhone, but we faced the > problem - we don't know how to build live555 for iPhone device (arm). > There are several config files, but no one could be used to build > live555 for iPhone. What can you suggest, what should we do? > > Thanks! > Denis. > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From paul.kreker at fkie.fraunhofer.de Wed Apr 21 07:22:22 2010 From: paul.kreker at fkie.fraunhofer.de (Kreker, Paul) Date: Wed, 21 Apr 2010 16:22:22 +0200 Subject: [Live-devel] First Application In-Reply-To: References: <1FF0CFC89178B64DBD5CF6696750AC4338885F@mailserv1.lorien.fkie.fgan.de> Message-ID: <1FF0CFC89178B64DBD5CF6696750AC43388882@mailserv1.lorien.fkie.fgan.de> Okay, I understand. But do I've to use doEventLoop()? If yes, how can I say doEventLoop to run the continuePlaying()-methode of my subclass? And how can I run an Qt-app while doEventLoop runs? I mean do EventLoop() never returns or can I make two threads? With kind regards, Paul Kreker ------------------------------------------------------------------------------------------------------ Trainee to IT Specialist for Application Development Fraunhofer-Institution for Communikation, Informations Processing and Ergonomics (FKIE) Department Sensordata and Information Fusion (SDF) Neuenahrer Str. 20 53343 Wachtberg Germany Phone: +49 228 9435 456 Email: Paul.Kreker at fkie.fraunhofer.de Web: www.fgan.de ------------------------------------------------------------------------------------------------------ Diese E-Mail kann vertrauliche und/oder rechtlich gesch?tzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren, Verbreiten sowie die unbefugte Weitergabe dieser E-Mail, ihrer Anh?nge und/oder deren jeweiliger Inhalte ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of this e-mail, its attachments and/or the information contained therein is strictly forbidden. ________________________________ Von: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Im Auftrag von Ross Finlayson Gesendet: Dienstag, 20. April 2010 17:06 An: LIVE555 Streaming Media - development & use Betreff: Re: [Live-devel] First Application All I tried so far was using some source code from openRTSP, but I could actually not figure out where to grab the data. The "openRTSP" code (in "testProgs/playCommon.cpp") saves its incoming data into a file - using the "FileSink" class. Note that "FileSink" is a subclass of "MediaSink", and implements the virtual function "continuePlaying()". If you want to instead do something else with the incoming data, you would use a different subclass (that you would write) of "MediaSink". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 21 09:54:38 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 21 Apr 2010 09:54:38 -0700 Subject: [Live-devel] First Application In-Reply-To: <1FF0CFC89178B64DBD5CF6696750AC43388882@mailserv1.lorien.fkie.fgan.de> References: <1FF0CFC89178B64DBD5CF6696750AC4338885F@mailserv1.lorien.fkie.fgan.de> <1FF0CFC89178B64DBD5CF6696750AC43388882@mailserv1.lorien.fkie.fgan.de> Message-ID: >Okay, I understand. But do I've to use doEventLoop()? If yes, how >can I say doEventLoop to run the continuePlaying()-methode of my >subclass? You do what "openRTSP" (and the other receiving demo applications) do: - Call YourSinkObject->startPlaying(...) then - Call doEventLoop() The call to "startPlaying(...)" will cause your "continuePlaying()" function to be called the first time. After that, you call it again, after you receive (and process) incoming data. See the code for "FileSink" for an illustration of how this works. >And how can I run an Qt-app while doEventLoop runs? I mean do >EventLoop() never returns or can I make two threads? Yes, provided that the Qt thread does not iteract with the "LIVE555 event loop" thread - except perhaps using global variables. See the FAQ. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoring at logitech.com Wed Apr 21 13:30:55 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Wed, 21 Apr 2010 13:30:55 -0700 Subject: [Live-devel] Crash in RTSPServer.cpp Message-ID: We have a crash in our RTSP server (implemented with Live555) that reproduces when streaming the same session to multiple RTP-over-TCP clients. Here's the callstack: Program terminated with signal 11, Segmentation fault. #0 0x47ac7cb4 in RTSPServer::RTSPClientSession::handleAlternativeRequestByte1 () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/ExternalMediaDelivery.so (gdb) bt #0 0x47ac7cb4 in RTSPServer::RTSPClientSession::handleAlternativeRequestByte1 () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/ExternalMediaDelivery.so #1 0x47ac4b9c in SocketDescriptor::tcpReadHandler () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/ExternalMediaDelivery.so #2 0x47a9ee54 in BasicTaskScheduler::SingleStep () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/ExternalMediaDelivery.so #3 0x47a9e2d8 in BasicTaskScheduler0::doEventLoop () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/ExternalMediaDelivery.so #4 0x47a96670 in RTSPServer::run (this=0x3f5c0) at ../../../../src/RTSPServer.cpp:190 #5 0x403637f0 in QThreadPrivate::start () from /opt/montavista/pro/devkit/arm/v5t_le/target/opt/libQtCore.so.4 #6 0x405158c8 in start_thread (arg=) at pthread_create.c:300 #7 0x4078add8 in clone () from /opt/montavista/pro/devkit/arm/v5t_le/target/lib/libc.so.6 Backtrace stopped: frame did not save the PC (gdb) The callstack is a bit odd because of optimiztion, but it makes sense going through tcpReadHandler. are there any known issues from requesting multiple RTP-over-TCP streams from the same session? (also, our client is based on openRTSP--so Live555 on both sides). -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 21 16:44:38 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 21 Apr 2010 16:44:38 -0700 Subject: [Live-devel] Crash in RTSPServer.cpp In-Reply-To: References: Message-ID: >We have a crash in our RTSP server (implemented with Live555) that >reproduces when streaming the same session to multiple RTP-over-TCP >clients. You have "reuseFirstSource" set to "True" in your "OnDemandServerMediaSubsession" subclass, right? > Here's the callstack: It's hard to tell from this what's going wrong. Please add #define DEBUG 1 to the start of "RTSPServer.cpp", recompile, and send us the debugging output, up to the point of the crash. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From nilesh.kuber at gmail.com Wed Apr 21 07:12:57 2010 From: nilesh.kuber at gmail.com (Nilesh Kuber) Date: Wed, 21 Apr 2010 19:42:57 +0530 Subject: [Live-devel] Regarding getting H264 Message-ID: Hi, I am using the latest Live 555 SDK and I am developing client application in which I want to read H264 streams from IP camera. I have seen source - sink model of Live 555. I am getting success upto sending "PLAY" option to IP camera. Now I need to read H264 payload from this camera. So what classes I need to use in my client application to form source-sink model and I am able to extract H264 frame. Any help will be appreciated. -- Thanks! KIMI -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 21 17:16:28 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 21 Apr 2010 17:16:28 -0700 Subject: [Live-devel] Threads and event loops In-Reply-To: <379ce6ee516b473282c706c19be55b24@4cf9bd62fe1843b9936dc122ed76e231> References: <379ce6ee516b473282c706c19be55b24@4cf9bd62fe1843b9936dc122ed76e231> Message-ID: >I followed all the posts about threading and event loops some days >ago. I also reviewed the FAQ once more and because I had done it >several times in the past, it seems to me that the recommendation >"Such a configuration is not recommended, however; instead, it is >safer to structure such an application as multiple processes, not >multiple threads." has been added recently and was not there just >some weeks ago. Am I right? Yes. >When this configuration (more event loops running in separate >threads with dedicated usage environments and task schedulers) is >not recommended any more, it is bad news for us because our >application is structured exactly in this configuration. Don't worry - I just said "not recommended", not "you cannot do this" (which I couldn't enforce anyway, because this is Open Source :-) > Nevertheless, we have not seen any problems in this configuration >so far, in our tests we are running up to 20 threads in one process, >each thread is responsible for exactly one RTSP server. Could you, >please, be more specific why this configuration is not recommended? >Are there any known problems with this configuration? (I think the >problem can be some static variables but since we compiled the >live555 code to a Windows COM library and create one instance of a >COM object for each RTSP client, maybe the static variables are not >touched by other instances, but I am not sure about this). We recently saw a problem (with multiple threads in a single process) caused by a static variable. There might be others; I can't say for sure. >Finally, according to my opinion, this approach is far better than >having just one thread to be responsible for many RTSP servers >because the code contains blocking operations Yes, the current implementation of "RTSPClient" is inadequate (because it contains blocking operations). This is being fixed (please be patient :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoring at logitech.com Thu Apr 22 07:22:40 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Thu, 22 Apr 2010 07:22:40 -0700 Subject: [Live-devel] Regarding getting H264 In-Reply-To: References: Message-ID: On Wed, Apr 21, 2010 at 7:12 AM, Nilesh Kuber wrote: > Hi, > > I am using the latest Live 555 SDK and I am developing client application in > which I want to read H264 streams from IP camera. > > I have seen source - sink model of Live 555. > > I am getting success upto sending "PLAY" option to IP camera. Now I need to > read H264 payload from this camera. So what classes I need to use in my > client application to form source-sink model and I am able to extract H264 > frame. Any help will be appreciated. http://www.live555.com/liveMedia/faq.html#h264-streaming From toms at ncifcrf.gov Fri Apr 23 13:11:58 2010 From: toms at ncifcrf.gov (Tom Schneider) Date: Fri, 23 Apr 2010 16:11:58 -0400 (EDT) Subject: [Live-devel] can't compile open RTSP on Mac or Sun Message-ID: <201004232011.o3NKBwqx024186@strawberry.ncifcrf.gov> Hi, I am on a Mac OSX 10.5.8. I got the live555-latest.tar.gz 09-Apr-2010. I unbundled, cd into the diretory and ./genMakefiles macosx make ... make[1]: *** [testMP3Streamer] Error 1 make: *** [all] Error 2 What's wrong? On my Sun workstation I get this error: ... cc -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I. -O -DSOLARIS -DSOCKLEN_T=socklen_t rtcp_from_spec.c /usr/ucb/cc: language optional software package not installed make[1]: *** [rtcp_from_spec.o] Error 1 ... make: *** [all] Error 2 I don't really care about optional languges ... maybe there's a flag to say this? Thanks, Tom Thomas D. Schneider, Ph.D. National Institutes of Health schneidt at mail.nih.gov toms at alum.mit.edu (permanent) http://alum.mit.edu/www/toms (permanent) From finlayson at live555.com Fri Apr 23 13:39:41 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 23 Apr 2010 13:39:41 -0700 Subject: [Live-devel] can't compile open RTSP on Mac or Sun In-Reply-To: <201004232011.o3NKBwqx024186@strawberry.ncifcrf.gov> References: <201004232011.o3NKBwqx024186@strawberry.ncifcrf.gov> Message-ID: >I am on a Mac OSX 10.5.8. I got the live555-latest.tar.gz >09-Apr-2010. I unbundled, cd into the diretory and > >./genMakefiles macosx >make >... >make[1]: *** [testMP3Streamer] Error 1 >make: *** [all] Error 2 > >What's wrong? Unfortunately I can't tell, but I'd be surprised if those are the only errors that you see. (You do have Apple's software development tools (XCode) installed, right?) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rmcouat at smartt.com Fri Apr 23 14:26:58 2010 From: rmcouat at smartt.com (Ron McOuat) Date: Fri, 23 Apr 2010 14:26:58 -0700 Subject: [Live-devel] can't compile open RTSP on Mac or Sun In-Reply-To: References: <201004232011.o3NKBwqx024186@strawberry.ncifcrf.gov> Message-ID: <4BD210A2.40007@smartt.com> I have 10.6.3 and followed the same steps and got no errors. Historically I have compiled with 10.5.X but upgraded to 10.6.X sometime last year so I can't give you that frame of reference. I have XCode installed including the option to link the compiler and tools into the UNIX file tree under /usr - this part is important. On 10-04-23 1:39 PM, Ross Finlayson wrote: >> I am on a Mac OSX 10.5.8. I got the live555-latest.tar.gz >> 09-Apr-2010. I unbundled, cd into the diretory and >> >> ./genMakefiles macosx >> make >> ... >> make[1]: *** [testMP3Streamer] Error 1 >> make: *** [all] Error 2 >> >> What's wrong? > > Unfortunately I can't tell, but I'd be surprised if those are the only > errors that you see. > > (You do have Apple's software development tools (XCode) installed, > right?) From jmigdal at gmail.com Thu Apr 22 10:21:54 2010 From: jmigdal at gmail.com (Joshua Migdal) Date: Thu, 22 Apr 2010 13:21:54 -0400 Subject: [Live-devel] Chunking up video in openRTSP Message-ID: Hi all, I'm trying to modify the openRTSP test app in order to have it output quicktime files in one minute long chunks instead of in one big mov file. I've looked a lot at QuickTimeFileSink.cpp and PlayCommon.cpp but have run into some snags. Some things I have tried: Since the start-of-file and end-of-file markers written into the quicktime file are linked with sink construction and destruction, the first thing I did was to set up a delayed task that, when invoked, closes the quicktime sink medium and attempt to recreate it. However, this didn't work as intended, as there is likely a whole lot of stuff still "attached" to the filter chain that was set up originally. I don't think live555 liked it when I ripped out the sink and tried to recreate it on the fly. The code looked something like this: closeMediaSinks(); qtOut = QuickTimeFileSink::createNew(*env, *session, quickTimeFileName.c_str(), fileSinkBufferSize, movieWidth, movieHeight, movieFPS, packetLossCompensate, syncStreams, generateHintTracks, generateMP4Format); if (qtOut == NULL) { *env << "Failed to create QuickTime file sink for stdout: " << env->getResultMsg(); shutdown(); } qtOut->startPlaying(sessionAfterPlaying, NULL); Another approach I took was to simply run openRTSP back-to-back in one minute intervals. However, this left about a 10 second gap in which I didn't have video coverage. The next thing I'd like to try is to close the quicktime movie with and reopen another one directly within the quicktime sink class itself, thereby avoiding the filter chain issues I had when destroying the sink entirely. Just wanted to get your take on what the best approach to doing this is. Thanks, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilremm at gmail.com Mon Apr 26 03:27:27 2010 From: nilremm at gmail.com (nilremm) Date: Mon, 26 Apr 2010 12:27:27 +0200 Subject: [Live-devel] live555 - trick play issue Message-ID: <78711A4A-91E6-4259-A11C-F7B2939B349C@gmail.com> Hi, I have got 2 issues with trick play and happens regardless of the movie (I use DVD VOB that I convert to TS file) : 1) when I trick play (forward / backward), the video jitter for 5-10 secs before stabilizing. It is not critical, but very annoying. 2) (join issue with VLC?), if I let the movies play for a while (around 2-3min) then if I do a trick play, I am redirected to the beginning of the sequence (2-3 min ago). If I do trick play in sequence, it works fine. I am using VLC 1.0.5 (MacOSX et Win XP) and live555 version 2010.03.16 From stephlejeune at gmail.com Mon Apr 26 06:20:18 2010 From: stephlejeune at gmail.com (=?ISO-8859-1?Q?St=E9phane_Le_Jeune?=) Date: Mon, 26 Apr 2010 15:20:18 +0200 Subject: [Live-devel] "GET_PARAMETER" as a client 'liveness' indicator Message-ID: Hello, I read that openRTSP can send GET_PARAMETER as keepAlive (or client liveness indicator) but nothing in the source code show that (in RTSPClient.cpp). During our session, the timeout is sent by the video server in the RTSP SETUP response and catched by openRTSP, but nothing append then when the time expired. Why no behavior has been developped ? Is there any player that can be able to send GET_PARAMETER in place of RTCP "RR" packet ? Fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephlejeune at gmail.com Mon Apr 26 06:24:02 2010 From: stephlejeune at gmail.com (=?ISO-8859-1?Q?St=E9phane_Le_Jeune?=) Date: Mon, 26 Apr 2010 15:24:02 +0200 Subject: [Live-devel] OpenRTSP keepAlive with RTCP "RR" Message-ID: Hello, We use openRTSP to test our video server timeout, openRTSP is able to send RTCP "RR" to the server to maintain the session but it does not use the good port that it's indicated in SETUP response. RTCP is defined in RTSP response from the server with the following: a=rtcp:5000 IN IP4 "@IP" a=rtcp-fb:96 nack a=fmtp:97;apt=96;rtx-time=340 So RTCP port for feedback is 5000 but openRTSP uses the port 5001 for RTCP "RR", This port is the second port (p+1) indicated in Transport parameter (Transport: RTP/AVP;unicast;source=@IP; client_port=5000-5001;server_port=5000-5001; mode="PLAY") Is it the standart behavior ? Fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohitagandotra at gmail.com Mon Apr 26 20:33:34 2010 From: mohitagandotra at gmail.com (mohita gandotra) Date: Tue, 27 Apr 2010 09:03:34 +0530 Subject: [Live-devel] playing wav file Message-ID: Hi All I am using TestOnDemandRTPServer for streaming wav file. I am using VLC to recieve the stream. I am able to recieve & play the wav streams correctly. But i found a problem when I use VLC option to stream the output to a file. After recording the output to a file and renaming the file to use .wav extension, i am not able to play this file. This problem arises only with the wav file. For other codecs, it works fine. I will be greatful to you if you let me know the reason of this problem. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Apr 27 00:23:05 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Apr 2010 00:23:05 -0700 Subject: [Live-devel] "GET_PARAMETER" as a client 'liveness' indicator In-Reply-To: References: Message-ID: >I read that openRTSP can send GET_PARAMETER as keepAlive (or client >liveness indicator) but nothing in the source code show that (in >RTSPClient.cpp). Not true. The "RTSPClient" class supports sending the "GET_PARAMETER" command, using the "getMediaSessionParameter()" member function. (However, our "openRTSP" demo application does not use this.) > During our session, the timeout is sent by the video server in the >RTSP SETUP response and catched by openRTSP, but nothing append then >when the time expired. > >Why no behavior has been developped ? > >Is there any player that can be able to send GET_PARAMETER in place >of RTCP "RR" packet ? I believe that the "VLC" media player will send a periodic "GET_PARAMETER" RTSP command (*as well as* sending RTCP "RR" packets, which is the proper, standard way in which a client indicates liveness) if the server responds with a "timeout=" parameter. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Apr 27 01:35:14 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Apr 2010 01:35:14 -0700 Subject: [Live-devel] playing wav file In-Reply-To: References: Message-ID: >I am using TestOnDemandRTPServer for streaming wav file. I am using >VLC to recieve the stream. I am able to recieve & play the wav >streams correctly. But i found a problem when I use VLC option to >stream the output to a file. VLC is not our application (and the feature of VLC that you're asking about does not use our software). You will need to ask your question on a VLC mailing list instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Apr 27 01:50:34 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Apr 2010 01:50:34 -0700 Subject: [Live-devel] OpenRTSP keepAlive with RTCP "RR" In-Reply-To: References: Message-ID: >We use openRTSP to test our video server timeout, openRTSP is able >to send RTCP >"RR" to the server to maintain the session but it does not use the good port >that it's indicated in SETUP response. RTCP is defined in RTSP >response from the server with the following: >a=rtcp:5000 IN IP4 "@IP" Unfortunately we do not yet support the "a=rtcp:" attribute defined by RFC 3605. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From stephlejeune at gmail.com Tue Apr 27 05:22:18 2010 From: stephlejeune at gmail.com (=?ISO-8859-1?Q?St=E9phane_Le_Jeune?=) Date: Tue, 27 Apr 2010 14:22:18 +0200 Subject: [Live-devel] OpenRTSP keepAlive with RTCP "RR" In-Reply-To: References: Message-ID: So the RTCP liveness indicator is only based on the port found in Transport parameter of the SETUP response? Fan 2010/4/27 Ross Finlayson > We use openRTSP to test our video server timeout, openRTSP is able to send >> RTCP >> "RR" to the server to maintain the session but it does not use the good >> port >> that it's indicated in SETUP response. RTCP is defined in RTSP response >> from the server with the following: >> a=rtcp:5000 IN IP4 "@IP" >> > > Unfortunately we do not yet support the "a=rtcp:" attribute defined by RFC > 3605. > -- > > 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 Apr 27 12:16:24 2010 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Apr 2010 12:16:24 -0700 Subject: [Live-devel] OpenRTSP keepAlive with RTCP "RR" In-Reply-To: References: Message-ID: >So the RTCP liveness indicator is only based on the port found in >Transport parameter of the SETUP response? Yes, in our current implementation, that port number is used for RTCP. We do not yet recognize the "a=rtcp:" attribute. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mgros at linceo.es Wed Apr 28 00:17:15 2010 From: mgros at linceo.es (=?iso-8859-1?Q?Marta_Gros_Mar=EDn?=) Date: Wed, 28 Apr 2010 09:17:15 +0200 Subject: [Live-devel] Help with multicast Message-ID: <2096288e$954093$62732c8b$@com> Hi to everyone, I have some questions about multicast that hope someone can help me with. I need to transmit a mpeg4 video using multicast and for doing that I'm using the "-m" option in wis-streamer. Doing that and using Wireshark I can see the multicast packets but if I try to watch the video connecting to the multicast address using VLC I see nothing, but, if I use the RTSP option in VLC then I can see the video. With RTSP the SDP info is as following: v=0 o=- 952047184189632 1 IN IP4 192.168.1.95 s=RTSP/RTP stream i=mpeg4 t=0 0 a=tool:LIVE555 Streaming Media v2008.04.02 a=type:broadcast a=control:* a=source-filter: incl IN IP4 * 192.168.1.95 a=rtcp-unicast: reflection a=range:npt=0- a=x-qt-text-nam:RTSP/RTP stream from DaVinci EVM a=x-qt-text-inf:mpeg4 m=audio 6002 RTP/AVP 96 c=IN IP4 232.36.244.217/255 a=rtpmap:96 L16/8000 a=control:track1 m=video 6000 RTP/AVP 97 c=IN IP4 232.36.244.217/255 a=rtpmap:97 MP4V-ES/90000 a=fmtp:97 profile-level-id=1;config=000001B001000001B509000001010000012000844007A94022 D0A21F a=control:track2 And the SETUP says: Transport: RTP/AVP;multicast;destination=232.36.244.217;source=192.168.1.95;port=6002-6 003;ttl=255 Does it mean I am really transmiting in multicast? shouldn't I be able to connect directly to the multicast address? Another thing is that I read that doing: ping 224.0.0.2 the multicast router should answer, but I get no answer. Does it mean my router is not multicast? As you can see I'm pretty lost with multicast, so I would be grateful if something could help me. Thanks in advance. Best regards to everyone, Marta -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Apr 28 00:46:43 2010 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Apr 2010 00:46:43 -0700 Subject: [Live-devel] Help with multicast In-Reply-To: <2096288e$954093$62732c8b$@com> References: <2096288e$954093$62732c8b$@com> Message-ID: >I have some questions about multicast that hope someone can help me with. > >I need to transmit a mpeg4 video using multicast and for doing that >I'm using the "-m" option in wis-streamer. >Doing that and using Wireshark I can see the multicast packets but >if I try to watch the video connecting to the multicast address >using VLC I see nothing, but, if I use the RTSP option in VLC then I >can see the video. So then what's the problem? If RTSP works for you, then why not continue to use that? Note that RTSP tells the client not only the multicast address and port number to subscribe to, but also (in the SDP description) important details about the codec that is being streamed. (Note, in particular, the "config=" parameter, which contains important information for the client's MPEG-4 decoder.) Even though VLC (apparently) allows you to subscribe to a multicast stream merely by specifying its address and port number, this will work only for certain simple codecs that are 'hard wired' into VLC. (However, I remind people yet again that VLC is not our software, and questions about VLC should be posted to a VLC mailing list.) >With RTSP the SDP info is as following: > >v=0 >o=- 952047184189632 1 IN IP4 192.168.1.95 >s=RTSP/RTP stream >i=mpeg4 >t=0 0 >a=tool:LIVE555 Streaming Media v2008.04.02 >a=type:broadcast >a=control:* >a=source-filter: incl IN IP4 * 192.168.1.95 >a=rtcp-unicast: reflection >a=range:npt=0- >a=x-qt-text-nam:RTSP/RTP stream from DaVinci EVM >a=x-qt-text-inf:mpeg4 >m=audio 6002 RTP/AVP 96 >c=IN IP4 232.36.244.217/255 >a=rtpmap:96 L16/8000 >a=control:track1 >m=video 6000 RTP/AVP 97 >c=IN IP4 232.36.244.217/255 >a=rtpmap:97 MP4V-ES/90000 >a=fmtp:97 >profile-level-id=1;config=000001B001000001B509000001010000012000844007A94022D0A21F >a=control:track2 > >And the SETUP says: > >Transport: >RTP/AVP;multicast;destination=232.36.244.217;source=192.168.1.95;port=6002-6003;ttl=255 > >Does it mean I am really transmiting in multicast? Yes. > shouldn't I be able to connect directly to the multicast address? Yes, but the way to do this is to use RTSP (see above). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From d2 at d2consulting.co.uk Wed Apr 28 00:32:04 2010 From: d2 at d2consulting.co.uk (Dom Robinson) Date: Wed, 28 Apr 2010 07:32:04 +0000 Subject: [Live-devel] Help with multicast In-Reply-To: <2096288e$954093$62732c8b$@com> References: <2096288e$954093$62732c8b$@com> Message-ID: <2037766455-1272440292-cardhu_decombobulator_blackberry.rim.net-970457278-@bda2148.bisx.produk.on.blackberry> Can you describe the network topology a little: routers often need a little priming to support mcast... Dom -----Original Message----- From: "Marta Gros Mar?n" Date: Wed, 28 Apr 2010 09:17:15 To: Subject: [Live-devel] Help with multicast _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From mgros at linceo.es Wed Apr 28 04:58:47 2010 From: mgros at linceo.es (=?iso-8859-1?Q?Marta_Gros_Mar=EDn?=) Date: Wed, 28 Apr 2010 13:58:47 +0200 Subject: [Live-devel] Help with multicast Message-ID: <74d30d53$33ff793d$310d7b0c$@com> Thanks for your answers. Dom:I'm connected to Router SpeedTouch 585 through a Switch D-link DES-1008D. Ross: Sorry for the misunderstanding, I wasn't asking about VLC, I was just pointing that out in case it helped. The problem is that I don't know if I'm doing it correct, if I am really transmitting in multicast, and that I don't know if I was supposed to be able to connect to the multicast address directly. And another question is, right now as I said I can't connect directly to the multicast address, but, do you know if I would be able to do it if my router were multicast? Thanks in advance. Marta -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephlejeune at gmail.com Wed Apr 28 00:18:08 2010 From: stephlejeune at gmail.com (=?ISO-8859-1?Q?St=E9phane_Le_Jeune?=) Date: Wed, 28 Apr 2010 09:18:08 +0200 Subject: [Live-devel] OpenRTSP keepAlive with RTCP "RR" In-Reply-To: References: Message-ID: Have you a idea of when do you interpret the "a=rtcp:" attribute ? fan 2010/4/27 Ross Finlayson > So the RTCP liveness indicator is only based on the port found in Transport >> parameter of the SETUP response? >> > > Yes, in our current implementation, that port number is used for RTCP. We > do not yet recognize the "a=rtcp:" attribute. > > -- > > 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 oussama.soualah at gmail.com Wed Apr 28 14:05:37 2010 From: oussama.soualah at gmail.com (oussama soualah) Date: Wed, 28 Apr 2010 23:05:37 +0200 Subject: [Live-devel] Insert images in streamed video Message-ID: Dear All, I want to add periodically an image in a streamed video. So how shall I modify the code to support this. Note I use testOnDemandRTSPServer to stream the video. Thanks and best regards... -- Oussama -------------- next part -------------- An HTML attachment was scrubbed... URL: From vikasjkmcs2005 at yahoo.co.in Tue Apr 27 18:03:46 2010 From: vikasjkmcs2005 at yahoo.co.in (vikas srivastava) Date: Wed, 28 Apr 2010 06:33:46 +0530 (IST) Subject: [Live-devel] Error in testMPEG4VideoStreamer Message-ID: <512062.3156.qm@web95307.mail.in2.yahoo.com> Hi Ross, I was?testing your testMPEG4VideoStreamer, but it gives error 1272415941.241840 Groupsock(6028: 232.0.4.12, 18888, 255): failed to join group: ?setsockopt(IP_ADD_MEMBERSHIP) error: Unknown error 1272415941.243164 Groupsock(5940: 232.0.4.12, 18889, 255): failed to join group: ?setsockopt(IP_ADD_MEMBERSHIP) error: Unknown error I googled it and found that i need to set route to 224.0.0/4. I?am using windows XP sp 2 and by using route print command, i found that the route?has already been added to the table?for 224.0.0/4. My pc is on LAN. So how to solve this problem. Thanks Vikas -------------- next part -------------- An HTML attachment was scrubbed... URL: From suwei19870312 at gmail.com Tue Apr 27 22:11:55 2010 From: suwei19870312 at gmail.com (wei su) Date: Wed, 28 Apr 2010 13:11:55 +0800 Subject: [Live-devel] RTP PCMU-audio and H263-video problem? In-Reply-To: References: Message-ID: hi *Ross:* *I need some help! * *I recently use live555 to implement a RTP streaming relay, I have to relay PCMU-audio and H263-video from a media server to RTSP client,* *when I only relay PCMU-audio or H263-video it works ok, but when i want relay both of them it works weird,* *it can send aduio in 2 seconds, and then re-cache the rtp streaming, then the audio can't be send * *, but video works well. I am sorry my english is not good.* *this is frame work of my PCMU-audio relay:* *1. I use SimpleRTPSource::createNEW() to get the RTP streaming.* *2. I use SimpleRTPSink::createNEW() to create audioSink.* *3.I use audioSink to play audioSource. * *and it works well.* * * *this is frame work of my H263-video relay:* *1. I use SimpleRTPSource::createNew() to get the RTP streaming.* *2. I use H263plusVideoStreamFramer::createNew() to create video source.* *3. I use H263plusVideoRTPSink::createNew() to create video sink.* *4. I use videosink to play videosource.* *an it works well.* * * *but after relay both of them. it woks weird.* *1. ServerMediaSession* sms = ServerMediaSession::createNew(*env, 8554).* *2. RTSPServer* rtspServer = RTSPServer::createNew(*ene, 8554).* *3. sms->addSubsession(PassiveServerMediaSubsession::create(*audiosink, audioRTCP)).* *4. sms->addSubsession(PassiveServerMediaSubsession::create(*videosink, videoRTCP)).* *5. rtspServer->addServerMediaSession(sms);* *6. audioSink->startPlaying(*aduioSource, afterPlaying, audioSink);* *7. videoSink->startPlaying(*videoSource, afterPlaying, videoSink);* * * * * * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From suwei19870312 at gmail.com Tue Apr 27 22:24:46 2010 From: suwei19870312 at gmail.com (wei su) Date: Wed, 28 Apr 2010 13:24:46 +0800 Subject: [Live-devel] RTP PCMU-audio and H263-video problem-plus? Message-ID: hi Ross: I use openRTSP as RTSP client, it can generate two files, audio-PCMU-1, and video-H263-2? but when I use VLC as RTSP client, it can not work well. it can display H263 video, but can't display PCMU audio. I use wireshark to get the packet, I can get the PCMU RTP, and H263 RTP . thank you for your help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh_vijayan at yahoo.com Thu Apr 29 02:34:29 2010 From: ganesh_vijayan at yahoo.com (Ganesh V) Date: Thu, 29 Apr 2010 02:34:29 -0700 (PDT) Subject: [Live-devel] RTP PCMU-audio and H263-video problem? In-Reply-To: References: Message-ID: <248287.14145.qm@web39504.mail.mud.yahoo.com> Hi Wei Su, >From your query, it appears that you are trying to add multiple media sub-sessions to a media sub-session. There is a previous post on the same topic. Kindly refer to http://www.mail-archive.com/live-devel at lists.live555.com/msg03995.html for the same. Please let me know if this helps or you still face problems. Cheers, Ganesh P.S: I haven't looked at the latest code in Livemedia. Pardon me if there are some changes to the same as compared to my earlier post. Date: Wed, 28 Apr 2010 13:11:55 +0800 From: wei su Subject: [Live-devel] RTP PCMU-audio and H263-video problem? To: live-devel at ns.live555.com Message-ID: Content-Type: text/plain; charset="iso-8859-1" hi *Ross:* *I need some help! * *I recently use live555 to implement a RTP streaming relay, I have to relay PCMU-audio and H263-video from a media server to RTSP client,* *when I only relay PCMU-audio or H263-video it works ok, but when i want relay both of them it works weird,* *it can send aduio in 2 seconds, and then re-cache the rtp streaming, then the audio can't be send * *, but video works well. I am sorry my english is not good.* *this is frame work of my PCMU-audio relay:* *1. I use SimpleRTPSource::createNEW() to get the RTP streaming.* *2. I use SimpleRTPSink::createNEW() to create audioSink.* *3.I use audioSink to play audioSource. * *and it works well.* * * *this is frame work of my H263-video relay:* *1. I use SimpleRTPSource::createNew() to get the RTP streaming.* *2. I use H263plusVideoStreamFramer::createNew() to create video source.* *3. I use H263plusVideoRTPSink::createNew() to create video sink.* *4. I use videosink to play videosource.* *an it works well.* * * *but after relay both of them. it woks weird.* *1. ServerMediaSession* sms = ServerMediaSession::createNew(*env, 8554).* *2. RTSPServer* rtspServer = RTSPServer::createNew(*ene, 8554).* *3. sms->addSubsession(PassiveServerMediaSubsession::create(*audiosink, audioRTCP)).* *4. sms->addSubsession(PassiveServerMediaSubsession::create(*videosink, videoRTCP)).* *5. rtspServer->addServerMediaSession(sms);* *6. audioSink->startPlaying(*aduioSource, afterPlaying, audioSink);* *7. videoSink->startPlaying(*videoSource, afterPlaying, videoSink);* * * * * * * -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel End of live-devel Digest, Vol 78, Issue 7 ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiongjiaji at gmail.com Thu Apr 29 07:14:21 2010 From: xiongjiaji at gmail.com (=?GB2312?B?0Ny80rzM?=) Date: Thu, 29 Apr 2010 22:14:21 +0800 Subject: [Live-devel] need H264 RTP streaming tutorial Message-ID: Hello, May I inquire if anybody has the H264 RTP streaming tutorial as mentioned in the previous postinghttp://www.mail-archive.com/live-devel at lists.live555.com/msg00238.html I hope it can be shared with live555 newbie like me. I need to refer to it to create a customized streaming server for a research project. Thank you so much. It is greatly appreciated. My eMail address is: xiongjiaji at gmail.com Can anybody send a copy to me?Thank you very much!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmigdal at gmail.com Thu Apr 29 12:52:02 2010 From: jmigdal at gmail.com (Joshua Migdal) Date: Thu, 29 Apr 2010 15:52:02 -0400 Subject: [Live-devel] broken avi index in openrtsp? Message-ID: I'm using openRTSP to create an avi file, but the avi files it creates will not play in Windows Media Player. The directshow filter graphs will not render properly. The AVI will play in VLC with warnings, and it seems to play fine in MPC. When I open it in VirtualDub, I get the following notices: AVI: Index not found or damaged -- reconstructing via file scan AVI: Keyframe flag reconstruction was not specified in open options.... What can I do to get openRTSP to create AVIs that will play properly? Thanks, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From mallikarjunarao at gaiansolutions.com Thu Apr 29 22:33:24 2010 From: mallikarjunarao at gaiansolutions.com (Mallikarjuna Rao) Date: Fri, 30 Apr 2010 11:03:24 +0530 Subject: [Live-devel] rtsp client crashes Message-ID: <1272605604.5416.2.camel@arjun-desktop> hi, I am new to live555 and implementing RTSP client by referring playCommon.cpp from testProgs. In my application i am following the sequence to open/play/close the rtsp session from my program. create_thread(RTSP); .................................... //after some time----------------- shutdown(); cancel_thread(RTSP); the definition of create_thread is like this open all the medium, sessions and initiate doEventLoop(); Here my problem is even after cancel_thread(RTSP), I am getting segmentaion falut like this and my program got killed. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1706] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x00425dfc in FramedSource::afterGetting (source=) at FramedSource.cpp:91 #2 0x0042e878 in MPEG2TransportStreamFramer::afterGettingFrame1 (this=0x54f738, frameSize=, presentationTime= {tv_sec = 0, tv_usec = 0}) at MPEG2TransportStreamFramer.cpp:151 #3 0x00425dfc in FramedSource::afterGetting (source=) at FramedSource.cpp:91 #4 0x004261e0 in BasicUDPSource::incomingPacketHandler1 (this=0x54fac8) at BasicUDPSource.cpp:72 #5 0x0043a370 in BasicTaskScheduler::SingleStep(unsigned int) () #6 0x0043c2fc in BasicTaskScheduler0::doEventLoop(char*) () #7 0x0040b0ec in RTSP(void*) () Please help me to fix this issue. thanks in advance, Mallikarjun -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Apr 29 23:45:20 2010 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 29 Apr 2010 23:45:20 -0700 Subject: [Live-devel] rtsp client crashes In-Reply-To: <1272605604.5416.2.camel@arjun-desktop> References: <1272605604.5416.2.camel@arjun-desktop> Message-ID: Do you have any problem with the original, unmodified "openRTSP" application code (i.e., "openRTSP.cpp" and "playCommon.cpp")? If not, then you should use that as a starting point, and make only small changes at a time - making sure that your application keeps workig each time. (From your crash, it looks like you're not properly shutting down the RTSP/RTP streams - but the original code should be doing that OK.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mallikarjunarao at gaiansolutions.com Fri Apr 30 00:03:35 2010 From: mallikarjunarao at gaiansolutions.com (Mallikarjuna Rao) Date: Fri, 30 Apr 2010 12:33:35 +0530 Subject: [Live-devel] rtsp client crashes In-Reply-To: References: <1272605604.5416.2.camel@arjun-desktop> Message-ID: <4BDA80C7.4010301@gaiansolutions.com> Dear Ross, Thanks for the reply. I have no problem with OpenRTSP application. It runs for RTSP URL and closes the program. Where as my application runs continuously by opening and closing each URL at time. Even I have no problem for some iterations, after say 100 iterations I am getting the problem. do I need to close/destruct any instances other than specified in shutdown() function? Please help me regarding this. regards, Mallikarjun Ross Finlayson wrote: > Do you have any problem with the original, unmodified "openRTSP" > application code (i.e., "openRTSP.cpp" and "playCommon.cpp")? If not, > then you should use that as a starting point, and make only small > changes at a time - making sure that your application keeps workig > each time. > > (From your crash, it looks like you're not properly shutting down the > RTSP/RTP streams - but the original code should be doing that OK.) From charlie at sensoray.com Fri Apr 30 09:21:03 2010 From: charlie at sensoray.com (Charlie X. Liu) Date: Fri, 30 Apr 2010 09:21:03 -0700 Subject: [Live-devel] need H264 RTP streaming tutorial In-Reply-To: References: Message-ID: <007b01cae881$214892f0$63d9b8d0$@com> http://www.fileden.com/files/2008/12/4/2210768/live555_H.264_tutorial.tar.gz From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of ??? Sent: Thursday, April 29, 2010 7:14 AM To: live-devel at ns.live555.com Subject: [Live-devel] need H264 RTP streaming tutorial Hello, May I inquire if anybody has the H264 RTP streaming tutorial as mentioned in the previous posting http://www.mail-archive.com/live-devel at lists.live555.com/msg00238.html I hope it can be shared with live555 newbie like me. I need to refer to it to create a customized streaming server for a research project. Thank you so much. It is greatly appreciated. My eMail address is: xiongjiaji at gmail.com Can anybody send a copy to me?Thank you very much!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoring at logitech.com Fri Apr 30 10:38:48 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Fri, 30 Apr 2010 10:38:48 -0700 Subject: [Live-devel] need H264 RTP streaming tutorial In-Reply-To: <007b01cae881$214892f0$63d9b8d0$@com> References: <007b01cae881$214892f0$63d9b8d0$@com> Message-ID: On Fri, Apr 30, 2010 at 9:21 AM, Charlie X. Liu wrote: > > http://www.fileden.com/files/2008/12/4/2210768/live555_H.264_tutorial.tar.gz > > That tutorial is wrong in so many ways, and personally cost me a good month or two of banging my head against the wall. Worst of all: // Create an 'H264 Video RTP' sink from the RTP 'groupsock': mVideoSenderSink = H264VideoRTPSink::createNew(*mEnv, mRtpGroupsock, 96, 0, "h264"); ...that last parameter? It's supposed to be SPS/PPS, base-64 encoded and comma delimited. "h264" is _completely_ wrong. This is probably fine code if your target is VLC, but any standards-based player will probably puke trying to read this stream (as it should, it's totally bogus). Also, the code doesn't check to make sure the NALU start codes (i.e. 0x000001 or 0x00000001) are stripped off before being sent--also invalid. Lastly, SPS/PPS info should not be sent in-stream; it is better to explicitly strip it out--I check NALU header info and simply discard those entirely (it's already in the SDP exchange, no need to send it in-stream). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnoring at logitech.com Fri Apr 30 11:15:49 2010 From: jnoring at logitech.com (Jeremy Noring) Date: Fri, 30 Apr 2010 11:15:49 -0700 Subject: [Live-devel] Crash in RTSPServer.cpp In-Reply-To: References: Message-ID: On Wed, Apr 21, 2010 at 4:44 PM, Ross Finlayson wrote: >> We have a crash in our RTSP server (implemented with Live555) that >> reproduces when streaming the same session to multiple RTP-over-TCP clients. > > You have "reuseFirstSource" set to "True" in your > "OnDemandServerMediaSubsession" subclass, right? Yes. > It's hard to tell from this what's going wrong. ?Please add > ? ? ? ?#define DEBUG 1 > to the start of "RTSPServer.cpp", recompile, and send us the debugging > output, up to the point of the crash. Okay: accept()ed connection from 10.0.0.10110RTSPClientSession[0xb09b0]::handleRequestBytes() read 174 new bytes:DESCRIBE rtsp://10.0.0.102:554/HighResolutionVideo RTSP/1.0 CSeq: 102 Accept: application/sdp User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "HighResolutionVideo" sending response: RTSP/1.0 200 OK CSeq: 102 Date: Fri, Apr 30 2010 18:09:22 GMT Content-Base: rtsp://10.0.0.102/HighResolutionVideo/ Content-Type: application/sdp Content-Length: 731 v=0 o=- 1272650943859266 1 IN IP4 10.0.0.102 s=LIVE555 Streaming Media v i=LIVE555 Streaming Media v t=0 0 a=tool:LIVE555 Streaming Media v2010.03.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v a=x-qt-text-inf:LIVE555 Streaming Media v m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:1000 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=4D001F;sprop-parameter-sets=J00AH9oDwFuwFUgAAAMACAAAAwHjAgAD0JAAD0JF73wvCIRq,KO48gA== a=control:track1 m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:64 a=rtpmap:97 MPEG4-GENERIC/8000 a=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588 a=control:track2 accept()ed connection from 10.0.0.1810RTSPClientSession[0xdc0e0]::handleRequestBytes() read 173 new bytes:DESCRIBE rtsp://10.0.0.102:554/HighResolutionVideo RTSP/1.0 CSeq: 10 Accept: application/sdp User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "HighResolutionVideo" sending response: RTSP/1.0 200 OK CSeq: 10 Date: Fri, Apr 30 2010 18:09:22 GMT Content-Base: rtsp://10.0.0.102/HighResolutionVideo/ Content-Type: application/sdp Content-Length: 731 v=0 o=- 1272650943859266 1 IN IP4 10.0.0.102 s=LIVE555 Streaming Media v i=LIVE555 Streaming Media v t=0 0 a=tool:LIVE555 Streaming Media v2010.03.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v a=x-qt-text-inf:LIVE555 Streaming Media v m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:1000 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=4D001F;sprop-parameter-sets=J00AH9oDwFuwFUgAAAMACAAAAwHjAgAD0JAAD0JF73wvCIRq,KO48gA== a=control:track1 m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:64 a=rtpmap:97 MPEG4-GENERIC/8000 a=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588 a=control:track2 RTSPClientSession[0xb09b0]::handleRequestBytes() read 197 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track1 RTSP/1.0 CSeq: 103 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "SETUP", urlPreSuffix "HighResolutionVideo", urlSuffix "track1" sending response: RTSP/1.0 200 OK CSeq: 103 Date: Fri, Apr 30 2010 18:09:22 GMT Transport: RTP/AVP/TCP;unicast;destination=10.0.0.101;source=10.0.0.102;interleaved=0-1 Session: 089B25B5 RTSPClientSession[0xdc0e0]::handleRequestBytes() read 196 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track1 RTSP/1.0 CSeq: 11 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "SETUP", urlPreSuffix "HighResolutionVideo", urlSuffix "track1" sending response: RTSP/1.0 200 OK CSeq: 11 Date: Fri, Apr 30 2010 18:09:22 GMT Transport: RTP/AVP/TCP;unicast;destination=10.0.0.18;source=10.0.0.102;interleaved=0-1 Session: 2FC31F4B RTSPClientSession[0xb09b0]::handleRequestBytes() read 216 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track2 RTSP/1.0 CSeq: 104 Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 089B25B5 User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "SETUP", urlPreSuffix "HighResolutionVideo", urlSuffix "track2" sending response: RTSP/1.0 200 OK CSeq: 104 Date: Fri, Apr 30 2010 18:09:22 GMT Transport: RTP/AVP/TCP;unicast;destination=10.0.0.101;source=10.0.0.102;interleaved=2-3 Session: 089B25B5 RTSPClientSession[0xdc0e0]::handleRequestBytes() read 215 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track2 RTSP/1.0 CSeq: 12 Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 2FC31F4B User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "SETUP", urlPreSuffix "HighResolutionVideo", urlSuffix "track2" sending response: RTSP/1.0 200 OK CSeq: 12 Date: Fri, Apr 30 2010 18:09:22 GMT Transport: RTP/AVP/TCP;unicast;destination=10.0.0.18;source=10.0.0.102;interleaved=2-3 Session: 2FC31F4B RTSPClientSession[0xb09b0]::handleRequestBytes() read 205 new bytes:TEARDOWN rtsp://10.0.0.102/HighResolutionVideo/ RTSP/1.0 CSeq: 105 Session: 089B25B5 User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) $ parseRTSPRequestString() returned cmdName "TEARDOWN", urlPreSuffix "HighResolutionVideo", urlSuffix "" sending response: RTSP/1.0 200 OK CSeq: 105 Date: Fri, Apr 30 2010 18:09:22 GMT RTSPClientSession[0xdc0e0]::handleRequestBytes() read 204 new bytes:TEARDOWN rtsp://10.0.0.102/HighResolutionVideo/ RTSP/1.0 CSeq: 13 Session: 2FC31F4B User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) $ parseRTSPRequestString() returned cmdName "TEARDOWN", urlPreSuffix "HighResolutionVideo", urlSuffix "" sending response: RTSP/1.0 200 OK CSeq: 13 Date: Fri, Apr 30 2010 18:09:22 GMT accept()ed connection from 10.0.0.1810RTSPClientSession[0xdc0e0]::handleRequestBytes() read 173 new bytes:DESCRIBE rtsp://10.0.0.102:554/HighResolutionVideo RTSP/1.0 CSeq: 14 Accept: application/sdp User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "HighResolutionVideo" sending response: RTSP/1.0 200 OK CSeq: 14 Date: Fri, Apr 30 2010 18:09:22 GMT Content-Base: rtsp://10.0.0.102/HighResolutionVideo/ Content-Type: application/sdp Content-Length: 731 v=0 o=- 1272650943859266 1 IN IP4 10.0.0.102 s=LIVE555 Streaming Media v i=LIVE555 Streaming Media v t=0 0 a=tool:LIVE555 Streaming Media v2010.03.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v a=x-qt-text-inf:LIVE555 Streaming Media v m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:1000 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=4D001F;sprop-parameter-sets=J00AH9oDwFuwFUgAAAMACAAAAwHjAgAD0JAAD0JF73wvCIRq,KO48gA== a=control:track1 m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:64 a=rtpmap:97 MPEG4-GENERIC/8000 a=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588 a=control:track2 accept()ed connection from 10.0.0.10110RTSPClientSession[0xe3f60]::handleRequestBytes() read 174 new bytes:DESCRIBE rtsp://10.0.0.102:554/HighResolutionVideo RTSP/1.0 CSeq: 106 Accept: application/sdp User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "HighResolutionVideo" sending response: RTSP/1.0 200 OK CSeq: 106 Date: Fri, Apr 30 2010 18:09:22 GMT Content-Base: rtsp://10.0.0.102/HighResolutionVideo/ Content-Type: application/sdp Content-Length: 731 v=0 o=- 1272650943859266 1 IN IP4 10.0.0.102 s=LIVE555 Streaming Media v i=LIVE555 Streaming Media v t=0 0 a=tool:LIVE555 Streaming Media v2010.03.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v a=x-qt-text-inf:LIVE555 Streaming Media v m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:1000 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=4D001F;sprop-parameter-sets=J00AH9oDwFuwFUgAAAMACAAAAwHjAgAD0JAAD0JF73wvCIRq,KO48gA== a=control:track1 m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:64 a=rtpmap:97 MPEG4-GENERIC/8000 a=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588 a=control:track2 RTSPClientSession[0xdc0e0]::handleRequestBytes() read 196 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track1 RTSP/1.0 CSeq: 15 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "SETUP", urlPreSuffix "HighResolutionVideo", urlSuffix "track1" sending response: RTSP/1.0 200 OK CSeq: 15 Date: Fri, Apr 30 2010 18:09:22 GMT Transport: RTP/AVP/TCP;unicast;destination=10.0.0.18;source=10.0.0.102;interleaved=0-1 Session: 1699AEC7 RTSPClientSession[0xe3f60]::handleRequestBytes() read 197 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track1 RTSP/1.0 CSeq: 107 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "SETUP", urlPreSuffix "HighResolutionVideo", urlSuffix "track1" sending response: RTSP/1.0 200 OK CSeq: 107 Date: Fri, Apr 30 2010 18:09:23 GMT Transport: RTP/AVP/TCP;unicast;destination=10.0.0.101;source=10.0.0.102;interleaved=0-1 Session: 4B6DF54E RTSPClientSession[0xdc0e0]::handleRequestBytes() read 215 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track2 RTSP/1.0 CSeq: 16 Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 1699AEC7 User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "SETUP", urlPreSuffix "HighResolutionVideo", urlSuffix "track2" sending response: RTSP/1.0 200 OK CSeq: 16 Date: Fri, Apr 30 2010 18:09:23 GMT Transport: RTP/AVP/TCP;unicast;destination=10.0.0.18;source=10.0.0.102;interleaved=2-3 Session: 1699AEC7 RTSPClientSession[0xe3f60]::handleRequestBytes() read 216 new bytes:SETUP rtsp://10.0.0.102/HighResolutionVideo/track2 RTSP/1.0 CSeq: 108 Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 4B6DF54E User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "SETUP", urlPreSuffix "HighResolutionVideo", urlSuffix "track2" sending response: RTSP/1.0 200 OK CSeq: 108 Date: Fri, Apr 30 2010 18:09:23 GMT Transport: RTP/AVP/TCP;unicast;destination=10.0.0.101;source=10.0.0.102;interleaved=2-3 Session: 4B6DF54E RTSPClientSession[0xdc0e0]::handleRequestBytes() read 179 new bytes:PLAY rtsp://10.0.0.102/HighResolutionVideo/ RTSP/1.0 CSeq: 17 Session: 1699AEC7 Range: npt=0.000- User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "PLAY", urlPreSuffix "HighResolutionVideo", urlSuffix "" sending response: RTSP/1.0 200 OK CSeq: 17 Date: Fri, Apr 30 2010 18:09:23 GMT Range: npt=0.000- Session: 1699AEC7 RTP-Info: url=rtsp://10.0.0.102/HighResolutionVideo/track1;seq=50013;rtptime=75201702,url=rtsp://10.0.0.102/HighResolutionVideo/track2;seq=29644;rtptime=4193596696 RTSPClientSession[0xe3f60]::handleRequestBytes() read 180 new bytes:PLAY rtsp://10.0.0.102/HighResolutionVideo/ RTSP/1.0 CSeq: 109 Session: 4B6DF54E Range: npt=0.000- User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "PLAY", urlPreSuffix "HighResolutionVideo", urlSuffix "" sending response: RTSP/1.0 200 OK CSeq: 109 Date: Fri, Apr 30 2010 18:09:23 GMT Range: npt=0.000- Session: 4B6DF54E RTP-Info: url=rtsp://10.0.0.102/HighResolutionVideo/track1;seq=50013;rtptime=75201702,url=rtsp://10.0.0.102/HighResolutionVideo/track2;seq=29644;rtptime=4193596696 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:T RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:E RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:A RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:R RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:D RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:O RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:W RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:N RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:r RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:t RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:s RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:p RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:/ RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:/ RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:1 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:0 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:. RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:0 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:. RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:0 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:. RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:1 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:0 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:2 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:/ RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:H RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:i RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:g RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:h RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:R RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:s RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:o RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:l RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:u RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:t RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:i RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:o RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:n RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:V RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:i RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:d RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:o RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:/ RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:R RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:T RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:S RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:P RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:/ RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:1 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:. RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:0 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:C RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:S RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:q RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:1 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:1 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:0 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:S RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:s RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:s RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:i RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:o RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:n RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:4 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:B RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:6 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:D RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:F RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:5 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:4 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:E RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:U RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:s RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:r RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:- RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:A RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:g RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:n RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:t RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:E RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:x RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:t RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:r RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:n RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:a RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:l RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:M RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:d RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:i RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:a RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:R RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:c RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:i RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:v RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:r RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:( RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:L RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:I RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:V RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:E RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:5 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:5 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:5 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:S RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:t RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:r RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:a RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:m RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:i RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:n RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:g RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:M RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:e RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:d RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:i RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:a RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:v RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:2 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:0 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:1 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:0 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:. RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:0 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:3 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:. RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:1 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:6 RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes:) RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: RTSPClientSession[0xe3f60]::handleRequestBytes() read 1 new bytes: parseRTSPRequestString() returned cmdName "TEARDOWN", urlPreSuffix "HighResolutionVideo", urlSuffix "" sending response: RTSP/1.0 200 OK CSeq: 110 Date: Fri, Apr 30 2010 18:09:22 GMT accept()ed connection from 10.0.0.10110RTSPClientSession[0x5434f190]::handleRequestBytes() read 174 new bytes:DESCRIBE rtsp://10.0.0.102:554/HighResolutionVideo RTSP/1.0 CSeq: 111 Accept: application/sdp User-Agent: External Media Receiver (LIVE555 Streaming Media v2010.03.16) parseRTSPRequestString() returned cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "HighResolutionVideo" sending response: RTSP/1.0 200 OK CSeq: 111 Date: Fri, Apr 30 2010 18:09:22 GMT Content-Base: rtsp://10.0.0.102/HighResolutionVideo/ Content-Type: application/sdp Content-Length: 731 v=0 o=- 1272650943859266 1 IN IP4 10.0.0.102 s=LIVE555 Streaming Media v i=LIVE555 Streaming Media v t=0 0 a=tool:LIVE555 Streaming Media v2010.03.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v a=x-qt-text-inf:LIVE555 Streaming Media v m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:1000 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=4D001F;sprop-parameter-sets=J00AH9oDwFuwFUgAAAMACAAAAwHjAgAD0JAAD0JF73wvCIRq,KO48gA== a=control:track1 m=audio 0 RTP/AVP 97 c=IN IP4 0.0.0.0 b=AS:64 a=rtpmap:97 MPEG4-GENERIC/8000 a=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1588 a=control:track2 ...at this point, our application on the camera crashes. I'm not sure if this gives you any clues or not. I'm going to try the same thing with VLC and RTP-over-UDP to see if I get similar results. Thanks. From mleventhal at ramprm.com Fri Apr 30 11:23:59 2010 From: mleventhal at ramprm.com (Mleventhal) Date: Fri, 30 Apr 2010 18:23:59 +0000 (UTC) Subject: [Live-devel] Playlists Message-ID: We are running some tests with Live555 to generate rtsp live streams. We have encoded several videos in .ts format and would like to run a playlist so one video plays after the next, or loop a video so it runs continuously. Any idea on how to do that? From finlayson at live555.com Fri Apr 30 14:12:09 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 30 Apr 2010 14:12:09 -0700 Subject: [Live-devel] Playlists In-Reply-To: References: Message-ID: >We are running some tests with Live555 to generate rtsp live streams. We have >encoded several videos in .ts format and would like to run a playlist so one >video plays after the next, or loop a video so it runs continuously. >Any idea on >how to do that? Yes, you can use a "ByteStreamMultiFileSource" - rather than a "ByteStreamFileSource" - as your input. You will need to implement your own subclass of "ServerMediaSubsession" - similar to "MPEG2TransportFileServerMediaSubsession" - to do this. (You would not be able to implement 'trick play' operations (except perhaps for 'seek') without a *lot* of extra work, though.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Apr 30 16:19:51 2010 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 30 Apr 2010 16:19:51 -0700 Subject: [Live-devel] Crash in RTSPServer.cpp In-Reply-To: References: Message-ID: >...at this point, our application on the camera crashes. I'm not sure >if this gives you any clues or not. Not a lot, unfortunately. Can you run something like "valgrind" that will give you more detailed information about where/why the crash is occurring? > I'm going to try the same thing >with VLC and RTP-over-UDP to see if I get similar results. I suspect that the problem has to do with the modifications that we made in version 2010.03.14 to handle RTSP commands sent within a RTP-over-TCP session. If that's the case, I would not expect to see problem occur if you used only RTP-over-UDP sessions. It's probably worth testing this, though. It would be nice to find a simple, repeatable sequence of client operations that cause the crash. E.g., does crash ever happen if there are two complete "DESCRIBE, SETUP, SETUP, PLAY, TEARDOWN" sequences in order (i.e., not overlapping), or does it occur only when two such sequences overlap? Once you've found a repeatable situation that causes the crash, then you could also test with RTP-over-UDP, and with "reuseFirstSource" set to False. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From suwei19870312 at gmail.com Fri Apr 30 03:33:58 2010 From: suwei19870312 at gmail.com (wei su) Date: Fri, 30 Apr 2010 18:33:58 +0800 Subject: [Live-devel] how to use ffmpeg to decode PCM streaming and encode it to AAC stream? Message-ID: Hi Ross. I recently use live555 to relay PCMU rtp streaming from a media server to a rtsp client. and pcmu streaming works well on VLC streaming player. but now we need to relay the PCMU streaming to cellphone, and lots of cellphone streaming player don't support PCMU codec. so we have to transcode the PCMU streaming to AAC streaming. and send the AAC streaming to RTSP client. I search on the internet and find out that ffmpeg can transcode PCM to AAC. but I don't know how to use ffmpeg to do it. so if there are some demo about this can help me. the framework of my codes as below: 1. use SimpleRTPSource to get the PCM streaming. 2. if I need to use ffmpeg to create a new subclass of FramedFiliter to transcode the streaming, and how to use ffmpeg? 3. use AC3audioRTPSink to relay. -------------- next part -------------- An HTML attachment was scrubbed... URL: