[Live-devel] framerate anomaly

[Dion Galbreath]

>>We put a directshow wrapper around the live555 library and its been 
>>going great however there seems to be on major anomaly.
>>
>>If the video we are streaming is less than 16 frames per second, all 
>>audio is dropped after ~
>>5 minutes of streaming.  This happens on all formats Mpeg4, h264, 
>>mpeg2, mpeg1, and h263
>>
>>Every format from above was tested and every format the audio dropped 
>>after five minutes of streaming. Tests included streaming to a 
>>computer, streaming to a helix, QuickTime, and Darwin server..
>>
>>If I set the framerate in the file and or capture to 16 or above 
>>everything runs fine. We can stream about 3 or so days without any
real 
>>issues, however once I lower that framerate to
>>15 or anything lower then 16, then the audio will stream with the
video 
>>for only ~5 minutes.
>>Then it no longer streams fine? video continues to be fine..
>>
>>Any ideas.

>Not really.  However, what do you mean exactly by "audio is dropped"?
Do you mean that - after 5 minutes - your server >stops transmitting
audio RTP packets completely?  If so, then you should check to make sure
that (1) your audio source >is not closing down (for some reason), and
(2) the "fDurationInMicroseconds" values (set by the object that feeds
into >your "RTPSink" subclass) remain correct.
>-- 

>Ross Finlayson
>Live Networks, Inc.
>http://www.live555.com/




Well the thing is for whatever reason the buffers buckets get held back,
causing the osprey driver filter to start throwing away buffer buckets
because the driver isn't getting any back to fill to send downstream...

I compiled with a much older version of the library from probably June
22, 2006ish  was an archived in a external HD we have....  and the
problem seems to take longer to happen. it will stream fine for ~2 hours
before doing the same exact issue..

It might be because changes to some part of the code didn't really take
into account a dshow environment buckets have to come back to the driver
filter or else our driver starts to throw samples away.. until it can
get those buckets back.


I was just wondering if offhand if there was anything to change buffer
size, or some variable to help get those buckets back to the driver..
what is odd is that 16 fps  doesn't starve the audio driver, but 15
does.... I'd think it would be the exact opposite. The more fps the more
work it has to do??

Thanks,

Dion