[Live-devel] multi file read in testOnDemandRTSPServer

[alpharoot]

On 1/19/10, Ross Finlayson <finlayson at live555.com> wrote:
> > I am developing a rtsp server which is based on
> > testOnDemandRTSPServer/mpeg4ESVideoTest. The video source
> is from a
> > camera instead of files so that I can implement a live video server.
> >
> > I found When streaming video
> MPEG4VideoFileServerMediaSubsession reads
> > files from the beginning for several times. It looks like the first
> > time it reads in the header, and next times it reads and really
> > streams the data. If reuseFirstSource is set to True then the file
> > will be opened and read twice.
> >
>
> Yes, this is unavoidable, unfortunately.  The server needs to read the
> MPEG-4 video data initially, so it can parse it to figure out the
> stream-specific 'config' information (the SDP "a=fmtp:..." line) that gets
> returned as part of the RTSP "DESCRIBE" response.  It then needs to read the
> data a second time when it later gets delivered to the client (in response
> to RTSP "PLAY").
>
> If the input data is a file (as it is with the unmodified
> "testOnDemandRTSPServer"), then the server actually rereads the same data
> (i.e., from the beginning of the file).  However, if the input data is a
> live source, then it's not necessary that the second read return the same
> data as the first read.  Instead, you can treat the input data as being an
> unseekable object.  You don't need to buffer the data from the first read.
It looks like the current MPEG4VideoStreamFramer implementation
doesn't support this mode, because it maintains a state machine for
parsing MPEG4 data. Each time it reads the video data, it seeks
VISUAL_OBJECT_SEQUENCE_START_CODE (0x000001B0) which only exists at
the beginning of the stream. If the START_CODE doesn't exist the state
machine will break and streaming will fail.
However for H264 I believe we don't need to buffer the data.
Maybe the restricted state machine (ie, seeking START_CODE) in
MPEG4VideoStreamFramer is not necessary (sorry for this question, I
don't have specific knowledge about MPEG4 standard)?

-- 
Bill