[Ffmpeg-devel] Re: mpeg transport streams

[Måns Rullgård]

"Eric L. Hernes" <eric at hernes.ws> writes:

>>>You are apparently talking about realtime encoding to a network?
>>>Won't that require some kind of async processing (either a thread or a
>>>callback) to send the PCRs and nulls if no ES packets are available.
>>
>>There's no fundamental difference.  The only thing that differs is
>>whether you sync the PCR against the actual time.
>>
> The fundamental difference being in how the program is designed.  If
> it needs to stream realtime output, the muxer needs to be in control
> and pulling data from somwehere. This is not how ffmpeg works, the
> muxer is pushed data.

The muxer can always block whoever is pushing.

>>OK, here's how you do it:
>>
>>1. decide on a mux rate, and rates for the elementary streams
>>2. create a few counters, one for the PCR and a time counter for each
>>   elementary stream
>>3. if the smallest ES time is <= PCR, write one TS packet from that ES,
>>      and increase the ES time accordingly (bits / rate)
>>4. else, write a null packet
>>5. increase PCR by 188*8 / muxrate
>>6. send PSI, if required, and increase PCR
>>7. repeat from 3
>>
>>PCR values can be attached to one of the elementary stream PIDs
>>(usually video), or use a separate PID.
>>
>>If you are streaming in realtime, just add a delay somewhere in the
>>loop to keep the PCR in sync with the clock.
>>
>>The problem is if you don't know the elementary stream rates, or they
>>are not VBV constrained.  In that case, it is necessary to continously
>>measure the rates based on PTS/DTS.
>>
> That sounds fine if the muxer is running as a data-puller.  Ffmpeg's
> muxer is being pushed data.  I know that to turn a push model into a
> pull, just you just buffer the data.  However, if a solution can be
> found that doesn't require re-buffering, it will be more efficient.
>
> On the other hand, re-buffering the audio should be a step towards
> properly interleaving the data.

You will always need to buffer one packet (as delivered to the muxer)
from each ES.

> Is it ok to just calculate packet intervals up front and ignore
> rounding? For example, say we have a muxrate of 6Mb and PCR interval
> of 40ms.  This would indicate we should have a PCR every 159.57
> packets, can we just round this and send a PCR every 160th packet?

That's fine for PCR packets, as long as you stay below the required
interval of 100 ms.  For calculations relating to data muxing, you
must (obviously) use methods that do not accumulate errors.

> I was also assuming that the ES streams were VBR, and that the mux
> rate was high enough for all ES streams, plus overhead.
>
> Does a VBV constrained stream guarantee a stream will be exactly the
> bitrate, or does the VBV just put a cap on the rate?

VBV compliance means that the stream can be read at a constant rate
without ever overflowing or underflowing a buffer of some given size.
The instantaneous bitrate can vary.  If the instantaneous rate is
lower than average, the buffer will fill up, and allow (require) a
subsequent higher rate, which will start draining the buffer.

-- 
M?ns Rullg?rd
mru at inprovide.com