[Live-devel] H.264 in MPEG-2 TS streams roughly at the start

[Warren Young]

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.