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

[Michael Niedermayer]

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


> 
> > But putting it in info packets just doesnt work without allowing
> > changeable info. Putting it in streams is a huge mess and changing nothing
> > wont work as has been shown and i belive isnt disputed anymore?
> 
> I agree that it probably won't work "optimally". I still think it's
> reasonable to ask for transmit_ts-dts to remain constant over
> moderate-sized windows, but Michael is correct that there are
> bitrate-utilization gains to be made by bending this rule. So if
> people want to make use of such gains, some solution is needed.

Theres also the issue that encoders, be it mpeg4 or mpeg2 do not 
neccesarily make any
attempt to keep transmit_ts-dts constant. Thus a muxer using such a rule
will have to work with input that has been encoded without such a rule.
Also a muxer will not know ahead of time how much off the input streams
will be from a constant transmit_ts-dts. So it has to assume the worst
case and that causes a considerable worse preload and buffer size.

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/8cf9eb69/attachment.pgp>