[NUT-devel] Another suggestion for broadcast [PATCH]

[Michael Niedermayer]

On Sun, Feb 10, 2008 at 11:14:38PM -0500, Rich Felker wrote:
> On Mon, Feb 11, 2008 at 02:19:29AM +0100, Michael Niedermayer wrote:
> > Anyway if you say a timestamp would be better, i suspect rich would be harder
> > to convince than me.
> 
> Not necessarily. If something new is needed, I want it to be
> whatever's best (hopefully without being invasive). A good question to
> ask is what stage in the content generation the buffering data would
> be generated at 

Well the transmit_ts / buffer_fullness or whatever would be generated by the
muxer or transmitter. But they are constrained by the packets from the
encoders.
So if audio and video encoders would decide to use the whole buffer, then the
muxer could not do anything short of also using the whole buffer.
The muxer only has a guranteed choice if it has more bufferspace or bandwidth
then what the encoders where told about. (interleaving is compared to mpeg
also much more constrained in nut so thats also not a real area of choice)

If the muxer had twice the bufferspace AND a little extra bandwidth AND was 
allowed to use twice the worst case preload. Then it could keep the buffer
at an average as you proposed i _THINK_.



> and if the choice of what to store would influence
> that...

buffer_fullness, transmit_ts and all of the others are equivalent
One can be found from the other if you know assumed-bitrate, actual-bitrate
and timestamps.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080211/21d73488/attachment.pgp>