[Live-devel] live-devel Digest, Vol 49, Issue 13

Race Vanderdecken brickyard at codetyrant.com
Tue Nov 27 14:47:50 PST 2007


On Sat, 2007-11-24 at 23:37 -0800, live-devel-request at ns.live555.com
wrote:
> Send live-devel mailing list submissions to
> 	live-devel at lists.live555.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.live555.com/mailman/listinfo/live-devel
> or, via email, send a message with subject or body 'help' to
> 	live-devel-request at lists.live555.com
> 
> You can reach the person managing the list at
> 	live-devel-owner at lists.live555.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of live-devel digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Lost consideration about SSM on Windows XP with VS6.
>       (Ross Finlayson)
>    2. Re: MultiFrameRTPSource::doGetNextFrame1(): The total
>       received frame size exceeds to buffer client ...... (Ross Finlayson)
>    3. Trouble with Amino STB (???????? ??????)
>    4. Restrictions (???????? ??????)
>    5. working with MJPEG streams with frame width > 2040	(and even
>       2048) pixels. (Andrey Filippov)
>    6. Re: Restrictions (Ross Finlayson)
>    7. Re: Trouble with Amino STB (Ross Finlayson)
>    8. live555MediaServer and RAW UDP streaming (bagger-devel at medi-a.ru)
>    9. Re: live555MediaServer and RAW UDP streaming (Ross Finlayson)
>   10. Player application (Oliver Roll)
>   11. Re: Player application (Ross Finlayson)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 22 Nov 2007 09:33:43 -0700
> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] Lost consideration about SSM on Windows XP
> 	with VS6.
> To: LIVE555 Streaming Media - development & use
> 	<live-devel at ns.live555.com>
> Message-ID: <f06240803c36b5f50c209@[66.80.62.44]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 
> >Do you mean according to RFC 2326 that an RTSP server should or must 
> >explicitly specify whether the session is unicast or multicast (by 
> >providing a multicast address) rather than give the client a chance 
> >to choose either?
> 
> Yes.  It is always the server - not the client - that decides whether 
> a stream is unicast or multicast.  The "forceMulticastOnUnspecified" 
> hack was developed only to accommodate some unconventional servers 
> that always streamed multicast, but did not put the address in the 
> SDP description.  However, as I noted earlier, that won't work for 
> SSM streams.
> -- 
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 22 Nov 2007 09:40:39 -0700
> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] MultiFrameRTPSource::doGetNextFrame1(): The
> 	total received frame size exceeds to buffer client ......
> To: LIVE555 Streaming Media - development & use
> 	<live-devel at ns.live555.com>
> Message-ID: <f06240804c36b60f72525@[66.80.62.44]>
> Content-Type: text/plain; charset="us-ascii"
> 
> >As you can see in previous mail, my problem is only at the beginning 
> >received Jpeg frame.
> >This is because the size of frame is more than 65535 and after that 
> >vlc auto adjust it.
> 
> Yes, VLC is working correctly here.  If you want to change the 
> initial limit of 65535, you will need to modify VLC.
> 
> >The question is how can i fragment correctly a packet size less than 65535 ?
> 
> Our code *already* correctly fragments JPEG framesn into multiple RTP 
> packets.  (Note that RTP packets are typically about 1500 bytes - 
> i.e., much smaller than your JPEG frames.)  The problem you're seeing 
> is that you are losing some of these RTP packets - which usually 
> means that the receiving client will discard the entire JPEG frame.
> 
> As I said before, JPEG is a poor codec to be using for streaming video.
> -- 
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.live555.com/pipermail/live-devel/attachments/20071122/915af7e4/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 22 Nov 2007 23:25:15 +0600
> From: ???????? ?????? <rtc_ru at mail.ru>
> Subject: [Live-devel] Trouble with Amino STB
> To: live-devel at ns.live555.com
> Message-ID: <1563204654.20071122232515 at mail.ru>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi, all!
> 
> I have a problem with AMINO STB.  In original version of
> LiveMediaServer files are in the same folder that a exe-file.
> 
> I have modified code of DynamicRTSPServer.cpp for read folder list
> form config.ini file and getting unique file from this folder list.
> 
> ============================cut here=================================
> static ServerMediaSession* createNewSMS(UsageEnvironment& env,
>                                         char const* fileName, FILE* fid); // forward
> char fullname[512];
> ServerMediaSession*
> DynamicRTSPServer::lookupServerMediaSession(char const *streamName) {
>   // First, check whether the specified "streamName" exists as a local file:
>   /*
>   GetPrivateProfileString("programs", "dir_files", "", dir_files, sizeof(dir_files), ".\\config.ini");
>   memset(dir_files, '\0', sizeof(dir_files));
>   memset(targetFile, '\0', sizeof(targetFile));
>   targetFile[0] = '.';
>   targetFile[1] == '\\';
>   
>   strcat(targetFile, dir_files);
>   strcat(targetFile, "\\");
>   strcat(targetFile, streamName);
>   */
> 
>   //////Here we read folder list from config file
>   //////for example: dir_files=C:\testdir1;C:\testdir2;C:\testdir1\test;
>         char strName[512];
>         memset(strName, '\0', 512);
>         strcat(strName, streamName);
>         char* tmp = strName;
>         char* file = strName;
>         
>         while(true)
>         {
>         tmp = strchr(file, '\\');
>                 if(tmp == 0)
>                         break;
>                 else
>                 {
>                         tmp+=1;
>                         file = tmp;
>                 }
>         }
>  // in *file* we have real file name without path (full path have been deleted in previous block
>         char name[8192];
>         GetPrivateProfileString("programs", "dir_files", "", name, sizeof(name), "config.ini");
> 
>         char **dirs;
>         int nameLen = strlen(name);
>         int semicolonCount = 0;
> 
>         for(int i = 0; i < nameLen; i++)
>         {
>                 if(name[i] == ';')
>                 {
>                         semicolonCount++;
>                 }
>         }
>         dirs = new char*[semicolonCount]; // folder's array
> 
>         for(int i = 0; i < semicolonCount; i++)
>         {
>                 dirs[i] = new char[512]; // max length of full name
>                 memset(dirs[i], '\0', 512);
>         }
> 
>         int i = 0;
> 
>         for(int j = 0; j < nameLen; j++)
>         {
>                 if(name[j] == ';')
>                 {
>                         i++;
>                 }
>                 else
>                 {
>                         dirs[i][strlen(dirs[i])] = name[j];
>                 }
>         }
> 
>           ///////////now in dirs we have folder list///////////////////////
>           ///////////and search requested file there/////////////////////////
>           FILE* fid; // our file
> 
>           for(int i = 0; i < semicolonCount; i++)
>           {
>                         memset(fullname, '\0', 512);
>                         strcpy(fullname, dirs[i]);
>                         strcat(fullname, "\\");
>                         strcat(fullname, file); // in *fullname* stored full file name (with path) which one may be presented in folders
>                         // if file exists - break the cycle
>                         fid = fopen(fullname, "rb");
>                         if(fid)
>                         {
>                                 break;
>                         }
>           }
>   //////////////////////////////////////////////////////////////////////////
>   Boolean fileExists = fid != NULL;
> ============================cut here=================================
> 
>   NOW!
> 
>   The VLC Player perfectly reads files - so server starts thread for it.
> 
>   BUT!!!!
> 
>   AMINO STB can't request any file - so server not to start any thread
>   for it
> 
>   I've view some logs and have seen that AMINO don't send DESCRIBE
>   command therefore VLC do it.
> 
>   Which mistake I have done and how to solve my problem?
> 
>   With best regards, Anatoliy
>   
> p.S. Sorry for my bad English
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Thu, 22 Nov 2007 23:34:53 +0600
> From: ???????? ?????? <rtc_ru at mail.ru>
> Subject: [Live-devel] Restrictions
> To: live-devel at ns.live555.com
> Message-ID: <1509883266.20071122233453 at mail.ru>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi, all!
> 
> May I asked once more? =)
> 
> 1. How to make session count restriction?
> 
> 2. How to deny access from listed IP-adresses?
> 
> With best regards, Anatoliy
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Thu, 22 Nov 2007 13:55:04 -0700
> From: "Andrey Filippov" <elphel at gmail.com>
> Subject: [Live-devel] working with MJPEG streams with frame width >
> 	2040	(and even 2048) pixels.
> To: live-devel at lists.live555.com
> Cc: Spectr <spectr at gmail.com>
> Message-ID:
> 	<30288c370711221255k4ea2e55mdfd503f33f55262e at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Ross,
> 
> Some time ago we needed a patch to be able to receive MJPEG stream from our
> cameras (3MPix -  2048x1536) at that time. That was implemented and RTP
> width of 0 was treated as 2048. But sensors get bigger and the that is not
> enough anymore.
> 
> Elphel cameras provide the frame size information in SDP file
> ("a=x-dimensions:width,height") and Spectr implemented a patch that does
> that - if the dimension is 0, it uses the data from SDP file (like with
> other video formats).
> 
> Patch is tested with MPlayer with 5MPix MJPEG video stream from Elphel model
> 353 camera, the only change in the MPlayer itself was to replace that
> notorious "maximal frame size of 50,000" (we used just width*height for the
> frame buffer size).
> 
> Patch is available  at Elphel project page at Sourceforge (
> http://sourceforge.net/project/showfiles.php?group_id=105686&package_id=120785&release_id=555832)
> - can you please take a look at it ?
> 
> Andrey
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.live555.com/pipermail/live-devel/attachments/20071122/89a3e278/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 6
> Date: Thu, 22 Nov 2007 16:48:10 -0700
> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] Restrictions
> To: LIVE555 Streaming Media - development & use
> 	<live-devel at ns.live555.com>
> Message-ID: <f06240800c36bc55ffa66@[66.80.62.44]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 
> >1. How to make session count restriction?
> 
> You would need to modify the "RTSPServer" code to do this.
> 
> >
> >2. How to deny access from listed IP-adresses?
> 
> This is easy.  Define your own subclass of "RTSPServer" that 
> redefines the virtual function "specialClientAccessCheck()".  That's 
> what that function is meant for,
> -- 
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Thu, 22 Nov 2007 16:53:37 -0700
> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] Trouble with Amino STB
> To: LIVE555 Streaming Media - development & use
> 	<live-devel at ns.live555.com>
> Message-ID: <f06240801c36bc6342c61@[66.80.62.44]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 
> >I have a problem with AMINO STB.
> 
> Note that the Amino STB is not our product.  This is not the best 
> mailing list to ask about problems with Amino products.
> 
> >I have modified code
> 
> In general, once you've modified the supplied code, you can't expect 
> much help on this mailing list.  Therefore, you should first do your 
> testing with the original, unmodified code.
> 
> 
> >   I've view some logs and have seen that AMINO don't send DESCRIBE
> >   command
> 
> Yes it does - if you type a "rtsp://" URL into the Amino STB.  (Make 
> sure that it is configured to use "nCube" mode.)
> -- 
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Fri, 23 Nov 2007 10:50:26 +0300
> From: bagger-devel at medi-a.ru
> Subject: [Live-devel] live555MediaServer and RAW UDP streaming
> To: live-devel at ns.live555.com
> Message-ID: <425434606.20071123105026 at medi-a.ru>
> Content-Type: text/plain; charset=us-ascii
> 
> Hello again, mailinglist!
> 
> One more question: has implementation of RTSPServer supports any
> nat traversal algorithms? I know that native RFC 2326 doesn't support
> such a feature, but some mmusic drafts describe methods to do
> this (like Symmetric RTP or STUN).
> 
> Thanks for answer!
> 
> 
> -- 
> Best regards, 
>  bagger-devel                          mailto:bagger-devel at medi-a.ru
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Fri, 23 Nov 2007 01:48:42 -0700
> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] live555MediaServer and RAW UDP streaming
> To: LIVE555 Streaming Media - development & use
> 	<live-devel at ns.live555.com>
> Message-ID: <f06240804c36c44169da4@[66.80.62.44]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 
> >One more question: has implementation of RTSPServer supports any
> >nat traversal algorithms? I know that native RFC 2326 doesn't support
> >such a feature, but some mmusic drafts describe methods to do
> >this (like Symmetric RTP or STUN).
> 
> Yes, but note, however, that these were designed primarily for SIP, 
> and will need to be adapted/modified somewhat (by the IETF) for use 
> by RTSP.  When that is done, however, we will be adding support for 
> this.
> -- 
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> 
> 
> ------------------------------
> 
> Message: 10
> Date: Sun, 25 Nov 2007 08:19:35 +0100
> From: Oliver Roll <mail at oliroll.de>
> Subject: [Live-devel] Player application
> To: live-devel at ns.live555.com
> Message-ID: <47492207.4090801 at oliroll.de>
> Content-Type: text/plain; charset=ISO-8859-15
> 
> Hello all,
> 
> all of the receiver programs in liveMedia/testProgs are dumping their
> output to stdout or into files.
> What is the easiest way to display a video actually received via
> testMPEG1or2VideoReceiver for instance?
> Is vlc (which is a bit too complex for me on the first sight) the only
> software which can be used to benefit from the streaming-power of liveMedia?
> 
> Thanks & regards,
> 
> Oliver
> 
> 
> ------------------------------
> 
> Message: 11
> Date: Sat, 24 Nov 2007 23:30:11 -0800
> From: Ross Finlayson <finlayson at live555.com>
> Subject: Re: [Live-devel] Player application
> To: LIVE555 Streaming Media - development & use
> 	<live-devel at ns.live555.com>
> Message-ID: <f06240804c36ed46f08ce@[66.80.62.44]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 
> >all of the receiver programs in liveMedia/testProgs are dumping their
> >output to stdout or into files.
> >What is the easiest way to display a video actually received via
> >testMPEG1or2VideoReceiver for instance?
> 
> Well, if you have a video player that can read from stdin, then you 
> could pipe the video (from "testMPEG1or2VideoReceiver") into it.
> 
> >Is vlc (which is a bit too complex for me on the first sight)
> 
> There are prebuilt binary versions of VLC available on their web site.
> 
> VLC is easy - just enter the appropriate "rtsp://" URL into its 'open' dialog.
> 
> >  the only
> >software which can be used to benefit from the streaming-power of liveMedia?
> 
> No, there's also MPlayer (although VLC is better), and probably other 
> media players as well.



More information about the live-devel mailing list