[NUT-devel] Broadcasting nuts [PATCH]

[Michael Niedermayer]

On Sat, Feb 09, 2008 at 03:48:21AM -0500, Rich Felker wrote:
> On Fri, Feb 08, 2008 at 09:04:49AM +0000, Måns Rullgård wrote:
> > Rich Felker <dalias at aerifal.cx> writes:
> > 
> > > I've not been around today to reply to your email but just want to let
> > > you know I agree some things might not work as well as I had hoped,
> > > though I'm not sure I agree with your claims about what happens in
> > > this example either. I'd like to look into it more but if it turns out
> > > we cannot meet your requirements for broadcast optimality with my
> > > proposals I'll be willing to see what we can come up with to remedy
> > > that. I have an idea in mind for storing clock sync/buffering data
> > > which would be more flexible and less invasive than the proposals so
> > 
> > I'd hardly call Michael's proposal invasive.
> > 
> > > far, I think, but I'll wait to write about it til I'm not about to
> > > fall asleep.
> > 
> > I'd sure like to hear what you have in mind.
> 
> My idea isn't about the semantics but about syntax. Previous proposals
> have suggested adding syntactic elements to the syncpoint. I'd like to
> suggest having clock-synch or buffer-synch data as its own stream in
> the NUT file. IMO there are several advantages:
> 
> - The frequency of the buffer/clock hints is not tied to syncpoint
>   frequency. They can occur more or less often, whatever is needed.
> 
> - There can be more than one stream of buffer/clock hints, e.g. so
>   that a single master file can contain hints for more than one
>   broadcast scheme.
> 

> - No changes are needed to the spec except for specifying something
>   which was before entirely unspecified (new stream type).

This applies to the syncpoint change as well


> 
> - It does not consume the first reserved field of syncpoints, so that,
>   if we find another thing to put in the reserved space of syncpoints
>   in the future, non-broadcast files don't have to waste a zero-byte
>   in every syncpoint to be able to use whatever the other new fields
>   are. 

>    (Along this line, it might be a good idea for all reserved
>   zones to begin with a vlc-coded bitfield of which extended fields
>   are coded, so that unused fields only consume 1 bit instead of a
>   whold byte.)

Iam extreemly strongly against this!!! This would be alot of extra
complexity for a very hypothetical case. And for headers which are not
that often placed in the file anyway. Its like 3 bytes in a file you 
avoid per field added to the main header.

We could safe many kilobytes with the info packet proposals i had.
Either the space does matter or it does not, overhead doesnt change
in importance depending on you liking or not liking a proposal!

For reference, "info packet proposals" here means the use of a single
"v" value to identify common fields instead of always storing the name
as a string.


> 
> I'm not completely wedded to this proposal nor opposed to different
> ways of doing it, but I do believe this approach has some nice
> advantages as outlined above.

While what you propose would work, i do not like it at all. It adds
tons of complexity and overhead to avoid adding 2 bytes to syncpoints.
Also it would need another set of special cases for back_ptr and index
as that stream type you describe needs neither.

Also iam not disputing that multple buffer/clock hints can be usefull.
I think their practical advantage is low. First because 99% of the broadcast
files will be tuned to one and only one (possibly) variing bandwidth.
Such files would not contain a second buffer hint stream.
And if one would want to stream at widely different bandwidths, the one
would use different bitrates for the video and audio as well.

So my questions here are
* When do we want the buffer/clock hints more often than syncpoints.
  And what do we gain by that?
* When do we want the buffer/clock hints less often than syncpoints.
  And what do we gain by that?
* In what practical scenario would we have 2 buffer hint streams and
  how much would we benefit from them?

I think these are the keypoints for a discussion of stream vs. syncpoints.
Complexity and overhead wise streams are certainly worse.

About the advanatge of several buffer hint streams
A stream will likely be encoded with some max bandwidth in mind and that
will be likely also the "main" buffer hint stream. Lower bandwidths would
fail. A twice as high bandwidth would without a second hint stream allow
half the preload, a second hint strea would allow even lower preload, but
does that make much sense anymore, its alraedy half of what was considered
ok for the main use case ...

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- 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/20080209/4d85180a/attachment.pgp>