[Live-devel] Question about trick play, server side

[edi87 at fibertel.com.ar]

Ross,

I just found a "bit" change... I just realized that the live555 version I can use here is 2009.02.13.

I checked FramedFilter and I'm a bit lost about how should I do it... I saw that ByteStreamFileSource could be the way to make the stream to go back to the start when its ending, but I'm not sure...

I though in doing something like subclass FramedSource, let's say "FramedLoopFilter", then subclas OnDemandServerMediaSubsession to use FramedLoopFilter instead of FramedSource*

The code that im using to make tests (run the server) is:

[....]
ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString);
MPEG1or2FileServerDemux* demux = MPEG1or2FileServerDemux::createNew(*env, inputFileName, reuseFirstSource);
    
ServerMediaSubsession *video_ssession = demux->newVideoServerMediaSubsession(iFramesOnly);
ServerMediaSubsession *audio_ssession = demux->newAudioServerMediaSubsession();
    
sms->addSubsession(video_ssession);
sms->addSubsession(audio_ssession);
rtspServer->addServerMediaSession(sms);
[....]

So I would need to subclass MPEG1or2FileServerDemux to use my OnDemandServerMediaSubsession subclass.

Please, could you guide me if I'm correct? since I know that there are a lot of changes between my live555 version and current.

PS: I'm not able to update the live version, so I need to do this with this old version.

Thanks in advance,

Jonathan


----- Mensaje original -----
De: Jonathan Granade <edi87 at fibertel.com.ar>
Fecha: Miércoles, Diciembre 8, 2010 8:19 pm
Asunto: Re: [Live-devel] Question about trick play, server side

> Ross,
> 
> Sorry by being late in reply but I was pretty busy.
> 
> Thanks for your reply, it sounds very very good and I'm starting to 
> test it.
> 
> About stream N minutes of a file, I dont want to "cut" the original 
> video, I think that I can modify the headers or something to make 
> the 
> client think that the video duration is N and not the total.
> 
> Sorry about the "trick play" confusion, I miss understood the concept.
> 
> PS: I need to stream a MPEG file, not a transport stream file, I 
> just 
> say a TS file because the example, it's the same to stream a TS 
> file or 
> a MPG? I mean, I should say what you said for any of those formats?
> 
> Thanks in advance,
> 
> Jonathan
> 
> On 12/01/2010 11:23 AM, Ross Finlayson wrote:
> >> I checked the code mentioned, and it works as expected.
> >> But now I have a question... is possible to do the same (stream 
> only N
> >> mins of file, or make an infinite loop) from the server side?
> >
> > Well, if you want to only stream N minutes of a file - without the
> > client asking you to do this - then the best/right way to do this 
> would> simply be to create a new file in advance, by editing the 
> original file,
> > and then asking your clients to stream from the new file instead.
> >
> > As for streaming a single file over and over again, in an 
> infinite loop
> > (again, without the client asking you to do this): You could do 
> this,> but you'd need to write a new "FramedFilter" subclass that 
> sits in front
> > of your "ByteStreamFileSource" class (and presents the illusion of
> > delivering a single, unbroken stream to the downstream object (a
> > "MPEG2TransportStreamFramer")). You'd also need to write a new
> > "OnDemandServerMediaSubsession" class (replacing the existing
> > "MPEG2TransportFileServerMediaSubsession" class) that uses your new
> > "FramedFilter" subclass.
> >
> > Also, because you're streaming a Transport Stream file, you'd 
> need to
> > make sure that the 'discontinuity flag' is set at the start of 
> the file,
> > so that PCR values (and thus presentation times) don't get messed up
> > when the server loops back to the start of the file.
> >
> > None of this really has anything to do with 'trick play' (in 
> particular,> you won't be creating index files at all), because - 
> from the client's
> > point of view - you're not doing anything other than playing a 
> simple> stream.
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>