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

[Michael Niedermayer]

On Mon, Feb 18, 2008 at 02:40:07AM -0500, Rich Felker wrote:
> On Sun, Feb 17, 2008 at 03:47:27AM +0100, Michael Niedermayer wrote:
> > On Mon, Feb 11, 2008 at 03:11:45AM +0100, Michael Niedermayer wrote:
> > > On Sun, Feb 10, 2008 at 08:53:17PM -0500, Rich Felker wrote:
> > > > On Mon, Feb 11, 2008 at 12:54:56AM +0100, Michael Niedermayer wrote:
> > > > > On Thu, Feb 07, 2008 at 03:55:46AM +0100, Michael Niedermayer wrote:
> > > > > > Hi
> > > > > > 
> > > > > > Heres a third try, the 
> > > > > > first was transmit_ts with unspecified buffers
> > > > > > second was transmit_ts with a single specified buffer
> > > > > > 
> > > > > > Here now comes the buffer state per syncpoint.
> > > > > > It trivially allows the demuxer to find the needed preload, and allows
> > > > > > trivial clock synchronization.
> > > > > > 
> > > > > > Iam not sure how much more or less device dependant this is. It surely
> > > > > > looks better if one considers broadcasting at a higher bitrate than the
> > > > > > intended one. (lower will fail as with all other proposals)
> > > > > > 
> > > > > > Also this is the smallest solution so far, and likely also has less
> > > > > > overhead than the transmit_ts.
> > > > > 
> > > > > Iam planing to commit this in 24h, if someone has objections / wants me
> > > > > to wait say so.
> > > > 
> > > > Can you wait a little bit for some more discussion? I'm not rejecting
> > > > it but I'd like to think it through more.
> > > 
> > > ok
> > 
> > ping, i waited a week ...
> > Ill add a transmit_ts in 48h (without buffer model) unless there is some
> > sort of discussion happening before.
> 
> transmit_ts or your other proposal? I think I like transmit_ts better

transmit_ts


> but I'd like to know the motivations behind how the decision is made

Motivation, it seems transmit_ts or someting equivalent is needed for
efficient broadcast. Your suggestion of keeping the buffer at an average
is less efficient. And buffer_fullness is sensitive to packet loss.


> rather than a decision being made by default when no one discusses it.
> Even though this is not a feature I'm particularly interested in.

Well what else should we do? Theres a problem, we know a solution, noone
else suggested an equally efficient alternative. I dont have a proof that
there is no better alternative. If we wait indefinitly the problem just
wont be solved. And waiting while there are zero discussions wont lead
to a new alternative being proposed ...


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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20080218/847e7d86/attachment.pgp>