On 9/7/2012 10:13 PM, Ross Finlayson wrote:
We've been unable to create files that stream as
smoothly as our old MPEG-2 files.
Our code has trouble streaming MPEG Transport Stream files that are
extremely VBR (variable bit rate), which is what I suspect your file is.
Yes, that's right. It averages 8 Mbit/s, but it has peaks in the 20
Mbit/s range, and falls well below the average at times.
Do you have any ffmpeg recipes for reducing variability? I ask because
it seems to treat parameters like -maxrate the same way people treat
speed limits. :)
That is, are there known ways to tell it, "No really, I'm not kidding,
max means max."?
I'm not against using another encoder. We have several. It's just that
most of the TS-capable ones we have are inflexible. They assume you're
using some common hardware profile like ATSC, AVCHD, or BluRay. They
either won't let you tune overall bit rate, or when you try, they create
broken streams.
Down the road, a better solution might be to provide an alternative
implementation of the "MPEG2TransportStreamFramer" class that 'reads
ahead'...less efficient
That wouldn't bother us at all.
Our servers have gigs of RAM in them these days, and they are only being
asked to serve dozens of streams maximum. If each took a few tens of MB
so the server would have a big enough window to examine the stream
before sending it out, it wouldn't be a problem.
You can call it TAKE_LOTS_O_RAM_TO_PREBUFFER_THE_STREAM compile time
parameter.
Another possibility would be store packet durations in the 'index file'
(that gets used when performing 'trick play' operations on Transport
Stream files. The disadvantage of this, however, is that it would work
only for prerecorded files, not 'live' input streams (e.g., from an
encoder). It would also require an incompatible change to the index
file format.
I'm surprised you can't get what you need from the index file already.
Doesn't it tell you whee all the I frames are in the file? If you take
a guess at the GOP length, you can infer frame rate.
It would be better if the file header included the observed average GOP
length instead, of course.
Then again, if the indexer were to do that, it could simply record the
observed average bit rate, and its variability. That would help the
RTSP server decide on an optimal buffer size. Instead of guessing
something like "24 MB" it could say "(avg_bit_rate + max_variability) *
seconds_of_buffer / 8" to get the buffer size in bytes necessary to hold
that many seconds of video.
From what we're seeing with this stream, it seems you need to prebuffer
30 seconds or so, before the current implementation can get a handle on
overall bit rate. Using the 8 Mbit/s = 1 MB/second rule of thumb again,
that means 30 MB. In 1 GB of RAM, that lets you stream 34 streams,
plenty for us.
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
