[Live-devel] Single stepping RTSP server

[Derk-Jan Hartman]

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
>