[Live-devel] Basic question

[Ross Finlayson]

> From my encoder, I can choose to bring in full MPEG frames or, blocks of 
> say, 1400 bytes. Which would be more efficient. In the latter case I have 
> to use MPEG4VideoStreamFramer, so is it true that that would be less efficient?

Actually, you'll need to use a "MPEG4VideoStreamFramer" in either case, 
because the 'sink' object ("MPEG4ESVideoRTPSink") requires that its input 
source be a "MPEG4VideoStreamFramer" (because it looks for special MPEG-4 
specific parameters that only "MPEG4VideoStreamFramer" supplies).

However, you still have a choice between having your 
"MPEG4VideoStreamFramer" read full MPEG frames, or fixed size (e.g., 1400 
byte) blocks.  Both will work, but I suggest reading full MPEG frames, as 
this will be slightly more efficient (by making the framer's job easier).

>BTW: Why is ByteStreamFileSource derived from the Framed*Source classes? 
>Would it make more sense to have a ByteStream*Source from an "unframed 
>source" class?

The distinction between 'framed' and 'unframed' sources was one that I made 
when I first designed the class hierarchy, but the distinction now turns 
out to be meaningless - because every source class ends up being derived 
from "FramedSource".  In practice, a "FramedSource" means only that it 
supports the "getNextFrame()" operation, to read a discrete chunk of data.

>Ok. All I wanted to confirm is that Live is compatible with Quicktime in 
>general.

IMHO, if this is all you want to do, then the easiest way for you to check 
this is to first read some raw MPEG-4 data from your encoder device into a 
file (named "test.m4v), and then run the existing "testMPEG4VideoStreamer" 
application (and then try reading the stream using QuickTime Player).

This will enable you to figure out quickly whether QuickTime Player will 
play a stream from your encoder.  If it does, you can then put in the extra 
effort to make your encoder use the LIVE.COM libraries.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>