Hi All ! What interests me is which standard streams efficiently over Multicast Sockets I figure for the type of application I am developing its better to sometimes loose a few frames than clogg up everybodys net with duplicated streams And if it was so important to have a 100% like transmission then still the mayor part of the data (the one thats assuming perfect transmission) should go through one or more Multicast sockets (1/3/7of11 quality of service kind of distribution for different bandwidth capabilities) It appears like a standard that Realmedia (for example) uses extensive buffers to prevent stalls (measured 40 sec. total delay). That may be what one has to live with for now... That every client could have an extra socket with the server (or better off peer) to rerequest missed packets is always an option ... Also Jodie you missunderstood me (maybe) I am not totally opposed to coding - just that I think that computers do that better, for that reason when I Programm I try to create rather readable little Java Objects :) cheers Tobias ----- Original Message ----- From: "Jodie Reynolds" <jodier333@xxxxxxxx> To: <video4linux-list@xxxxxxxxxx> Sent: Tuesday, April 17, 2001 01:44 Subject: RE: Re: Video Size in ffserver > Your better bet would be to look into the RTSP standard - RFC 2326. Try: > ftp://ftp.isi.edu/in-notes/rfc2326.txt or your favorite RFC repository. > > You can also download RTSP reference implementation source from: > http://www.realnetworks.com/devzone/library/rtsp/reference.html?src=r-av,nos > rc > > or look into OpenDivX Streaming SR-RTP 0.1a and the (IMHO) interesting > 'Congestion Management and Interactions Between Layered Quality Adaptation' > (I believe they call it) at > http://nms.lcs.mit.edu/papers/videocm-pv2001.html > > Thier server listens for requests on an RTSP port, establishes session > parameters via SDP, and streams requested data to the client via RTP over > UDP (not great for most firewalls, if you don't have control over them, and > not wonderful for security overall... I'm partial to http for that reason > alone.) > > As for the time limitations suggested - I haven't seen them on my Windows > development machine, but I have a TON of memory in that box. My laptop, on > the otherhand, stops after 6mins. It has 256M and runs Win 2000 Pro. Could > be a buffer is getting run over. MPJPEG will stream until I run out of RAM > and drive space (Netscape believes it's downloading ONE HUGE temporary > file.) One of the interesting things I've noted is that now that I can > change the video size in ffserver, if I set it for 4CIF and Motion JPEG or > Shockwave Streaming Format (effectively MPJPEG), I get streaming garbage > (not to be confused with the 'Steaming Garbage' in the other room that I > haven't taken out because I've been trying to get the ASF streaming working) > rather than a complete MJPEG packet, suggesting a buffer isn't large > enough... Something to investigate... > > --- Jodie > > -----Original Message----- > From: video4linux-list-admin@xxxxxxxxxx > [mailto:video4linux-list-admin@xxxxxxxxxx]On Behalf Of Michael Stearne > Sent: Monday, April 16, 2001 10:45 PM > To: video4linux-list@xxxxxxxxxx > Subject: Re: Re: Video Size in ffserver > > > RTSP is not proprietary to RealServer, RTSP (Real Time Streaming > Protocol) is an open standard employed by most major streaming methods > like QuickTime Streaming for example. > > ffserver should be able to use RTSP, you could view the source to the > OpenSource QuickTime Streaming server at http://publicsource.apple.com/ > and see how they implemented it. > > Michael > > On Monday, April 16, 2001, at 10:32 PM, Chris Kloiber wrote: > > > Tobias Gogolin wrote: > >> > >> Hi everybody > >> > >> I am doing some tests streaming in RealMedia format between my > >> computers here and found an > interesting misbehaviour: Aparently > >> after 2Minutes 46.6 Seconds every time the Stream ends > or the player > >> just doesnt receive any more data (verfied with LinuxPPC and Win 98 > >> (G2)) > >> The slide bar seems even know ahead of time that thats how long its > >> supposed to play > >> So is that a feature programmed in to the server or where does it come > >> from > >> (there is no need to restart the server when it happens - just hitting > >> stop and play again > >> does it ...) > > > > I think it has to do with the fact that it's using http:// rather than > > the normal streaming protocol (whatzit called? rtsp:// I think) that is > > proprietary to RealServer. I think (guessing) that if you use http: > > RealPlayer is thinking the file must NOT be a stream. I have gotten it > > up to almost 9 minutes at low resolution/low framerate. > > > > Chris Kloiber > >
