[Live-devel] Single stepping RTSP server

[Peter von Kaenel]

You're right: what I want to do does go completely against the whole
video streaming concept.  I think you might also be right about using
HTTP MJPEG MIME streams instead of RTSP.  I have already written a mini
web server (for embedded applications).  Do you know where I can find
the specifications for various video MIME types?  Is there sample source
code available that does it?

Thanks,
Peter




> -----Original Message-----
> From: live-devel-bounces at ns.live555.com [mailto:live-devel-
> bounces at ns.live555.com] On Behalf Of Derk-Jan Hartman
> Sent: Thursday, May 25, 2006 10:10 AM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] Single stepping RTSP server
> 
> Ehm.. Frame by frame control of a Stream sounds like a very bad idea.
> Why would you want to do that? it goes against almost any concept in
> video streaming
> 
> In video streaming, you usually work "lossy". ergo you don't care
> about dataloss as long as the perceived client experience is ok.
> If you want full quality you usually go to something file based.
> 
> Listening to what you want to do, I think a HTTP MJPEG multipart MIME
> stream sounds like a good solution. It's serverpush, and I think it
> will work for what you want to do.
> 
> DJ
> 
> 
> On 25-mei-2006, at 15:12, Peter von Kaenel wrote:
> >>> I'm interested in streaming video in a slightly non-standard way:
I
> >>> want to control the playback rate from the server, ignoring the
> >>> frame rate as defined in the media file.  Could you please give me
> >>> some pointers as to where in the code I should make
> >>> modifications?  My guess so far is to create new UsageEnvironment
> >>> and TaskScheduler classes and use them instead of the
> >>> BasicUsageEnvironment classes.
> >>
> >> I doubt you would need to do that, but without knowing more about
> >> exactly what you're trying to do, it's hard to say for sure.  Are
you
> >> talking about supporting 'trick play' - e.g., so that the stream
> >> appears, to the client, to be N times as fast (i.e., the RTSP
"scale"
> >> header)?  Or are you talking about actually changing the rate that
> >> bits get sent, without necessarily changing the stream's
appearance,
> >> as seen by clients (i.e., the RTSP "speed" header)?  Or something
> > else?
> >>
> >>
> >> 	Ross Finlayson
> >> 	Live Networks, Inc. (LIVE555.COM)
> >> 	<http://www.live555.com/>
> >
> > I have a bunch of AVI files and am starting to collect m2t files
> > containing video that I want to analyze in a simulation
> > environment.  I
> > would like to be able to tell the server when to send the next
> > frame so
> > that I have time to verify the analysis on a frame-by-frame basis
> > on the
> > client side.  Basically, I would like to have a trigger within
> > BasicTaskScheduler0::doEventLoop() that blocks the call to
> > SingleStep()
> > until I'm ready to send the next frame.  But looking inside of
> > SingleStep() it looks like it will try to handle overtiming (is this
> > correct?) along with client TCP based requests.  I guess I need to
> > separate the message handling from the frame transmission, and make
> > sure
> > that the frames can be sent at a variable rate.
> >
> > Thanks,
> > Peter
> >
> >
> >
> > _______________________________________________
> > live-devel mailing list
> > live-devel at lists.live555.com
> > http://lists.live555.com/mailman/listinfo/live-devel
> >
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel