[Live-devel] A few more questions

[Jeremy Bernstein]

Great! That seems to work. Thanks very much.

One more: a couple of months ago (when I was trying to get this working 
on a Mac), I mentioned that my H.263 frames were being streamed my 
liveMedia at the wrong size - there's a large margin on the right and 
bottom of the image frame. At that time, you suggested that the header 
of the data I was sending ought to contain this information, and that 
liveMedia would then be able to stream at the correct resolution. Which 
has me wondering - is liveMedia expecting a buffer of compressed image 
data (in this case of a FramedSource), or a buffer of pre-packetized 
data, including any necessary RTP header data? 

If the latter, I'm at a bit of a loss as to how to do that with 
QuickTime. Has anyone got a suggestion? Or a hint for places in the 
DirectX SDK to investigate? Either would be OK. Alternatively, if 
people are already simply using data compressed by DirectX, and 
everything seems to be working properly, that would be useful 
information as well.

Thanks again, and in advance for any new insight,
jb

Sun, 23 Jan 2005 08:01:32 -0800, finlayson at live.com (Ross Finlayson):
>> Everything seems to be functioning, but rather slowly. My
>> doGetNextFrame() gets called only about 10 times per second, and I'm
>> seeing frames in VLC Player (on the same computer), at maybe 1 frame
>> per second. Quicktime player shows a single frame and then gives up.

> It sounds like your "doNextFrame()" may be setting 
> "fDurationInMicroseconds" incorrectly before 
> "FramedSource::afterGetting()" gets called.
> 
> Because you are reading from a live source (I presume), rather than 
> from a file, it turns out that you don't need to set 
> "fDurationInMicroseconds".  Instead, just leave it at its default 
> value (0), which tells the "MultiFramedRTPSink" to not wait any time 
> before asking for the next input frame.  This works because - in your 
> case - any delay needed to process the next frame will be taken care 
> of by your "doNextFrame()".
> 
> You should also check that you are setting "fPresentationTime" 
> correctly.  As you're reading from a live input source, you can 
> probably just use "gettimeofday()" to set this (at the time that each 
> frame is read).  (This should work as long as your data doesn't 
> include MPEG (2 or 4) 'B' frames.)