> I’m not necessarily asking for you to change the API back to how it was; as
> you said, there was probably a good reason for changing it in the first
> place. I was hoping, however, that you or someone else on the list would
> have a clean an elegant solution.
Yes, I’d be interested to hear
I forget the specific motivation behind this API change (which occurred back in
2011), but I suspect it had to do with wanting to make sure that open files are
never left lying around once the “ByteStreamFileSource” object is closed.
I can understand that, but that could have been achieved with
> I have an RTSP server application that uses a woefully out-of-date version of
> live555. I’m in the process of updating to the latest version of live555 and
> have come across an API change that puzzles me.
>
> Basically, I have a thread that generates H.264 video and feeds it through a
> pi
As an application programmer, when would I want to specify
playTimePerFrame to ByteStreamFileSource?
When you are streaming directly from a file, by reading/streaming one
fixed-size chunk of data at a time. This happens for many simple
audio codecs (although not for more complex audio codecs
> Q: What is ByteStreamFileSource::fPlayTimePerFrame for?
>
> It's used to implement the (optional) "playTimePerFrame" parameter
> in "ByteStreamFileSource::createNew()".
> --
Yes, I did look at the code for this, but I don't understand what
"playTimePerFrame" actually does. Does it request t
Q: What is ByteStreamFileSource::fPlayTimePerFrame for?
It's used to implement the (optional) "playTimePerFrame" parameter in
"ByteStreamFileSource::createNew()".
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/___
live-devel mailing li
