[Live-devel] Live Streaming Device

[Pering, Trevor]

Ross -- thanks for your feedback... I figured some of stuff out...

* the problem I was having with doGetNextFrame was that I was not
scheduling the follow-up event -- I forgot to move it up from
deliverFrame (just tired, I guess) -- so it did one frame and then quit.
Looking at ByteStreamMultiFileSource was instructive, but the files are
only a stop-gap for the encoder, so not quite what I was looking for as
a final solution.

* The problem with the getAuxSDPLine was my misunderstanding about how
to wire the structures together.  I was trying to create a *replacement*
for MPEG4VideoStreamDiscreteFramer, when my encoder class really is just
a replacement to the file-source passed to MPEG4*. Doing this gives me
the configuration data I need.

Now -- on to the next part which is getting actual data from my encoder
to work...

	Trevor

-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, December 14, 2005 1:08 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Live Streaming Device


>* doGetNextFrame() just returns the frame immediately from the source
>file. deliverFrame() is never called/used.

You have to do everything that's described in the "deliverFrame()" 
code.  (If - as is the case for you - you are reading your data 
synchronously, you can get away with just calling "deliverFrame()" as 
a function from within "doGetNextFrame()".)

Because you're reading from a set of files, you may be able to use 
the existing "ByteStreamMultiFileSource" class, rather than writing 
your own source class.

>* I commented out most of the stuff in getAuxSDPLine(), so it just
>returns NULL. This is because I don't have/undestand the stuff that
this
>function supplies.

Unfortunately you will need this working in order for QT Player (or 
VLC, or any other compliant player) to be able to decode and play the
stream.

The issue here is that the SDP description (returned in response to 
the RTSP "DESCRIBE" command) needs to contain "config" information 
about the stream.  Unfortunately (in the case of MPEG-4 video), this 
information can only be obtained by reading the start of the 
stream.  So, the code ends up reading the input MPEG-4 video stream 
twice: Once to get the "config" information, and again to actually 
stream the data.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>

_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel