On Tue, Feb 05, 2008 at 07:57:48PM +0100, Michael
Niedermayer wrote:
> On Tue, Feb 05, 2008 at 12:14:12PM -0500, Rich Felker
wrote:
> [...]
> > > With some unspecified way to store
> > > menus and all the support structures.
> >
> > Feel free to propose a specification for menus. I
believe this was on
> > the agenda for a long time but considered
sufficiently unimportant
> > (and at a separate layer of specification) that it
could be relegated
> > to after NUT was completely finished.
>
> The generic info packets would have allowed to store
menus.
As far as I can tell the existing info packet framework can
do menus
just fine, as long as there's a spec for menu markup. If you
claim
otherwise, please explain what the problem is and I'm
interested in
solving it. I do not intend to preclude use of menus, even
though I
think most users find it more of an annoyance than a
feature.
> > > ffplay, mplayer, ffmpeg, xine, vlc, ... will
then get a command line argument
> > > called mydvd.tar
> >
> > Absolutely not. One would extract the nonsensical
archive with the
> > normal archive tools, if such a thing were used.
>
> You might, none of the users will, they will more
likely just transcode it to
> matroska and use the resulting single file. And if that
happens not to work
> with a player they will choose a different player.
>
> Its a simple thing, nut either supports what people
want, and the way people
> want or people will use another container. Technical
details have very little
> effect on user decissions.
I think the degree to which menus are desired is strongly
overestimated. I've never seen anyone use them in matroska.
But
nonetheless I'm fine with supporting them.
> > > There is no mysterious protocol between the
file/http/ftp/... protocol and the
> > > demuxer unless such new second layer protocol
or demuxer is implemented. Its
> >
> > Again you are mixing unrelated issues. The topic
at hand is
> > partitioning of broadcast channels. No one in
their right mind would
> > transmit such a multi-program broadcast stream
over http/ftp/etc.
>
> Well people do up and download mpeg-ts to mphq 
>
>
> > except perhaps as a link between devices involved
in the actual
> > broadcast.
>
> Yes, you mux your mpeg-ts maybe in realtime, maybe off
line and then
> transmit it.
> Nut current cannot be used as replacement. It requires
a second layer
> which outweights its advantages over mpeg-ts. Not a
single person said
> they would even consider nut as an replacement, dont
you think thats
> maybe an indication that you are moving in the wrong
direction?
No one's considering NUT as a replacement for .rar either
because it's
for a different purpose. Sadly MPEG-TS has an incestuous
purpose,
mixing multiple logical layers into one. That doesn't mean
we should
copy it.
Even if we copied stupid MPEG-TS stuff in NUT, still no one
would use
it instead of MPEG-TS. They have lots of stupid legacy
reasons for
wanting backwards, ill-designed stuff from MPEG specs. Our
target
audience should not be people who lack any rational
capabilities or
else we have to make something lowered down to their
intelligence
level...
> And when you speak about partitioning, dont forget that
all timing and
> buffering constraints must be met. All the packets must
be transmitted
> so the decoder buffers neither over nor underflow.
Theres no feedback
> saying stop or saying "i want more packets".
Spliting this over
> 2 layers is not going to make it much simpler.
As long as the bitrate constraints are already met and
streams are
padded to occupy their allotted portion of the channel,
just
interleave according to bitrate.
And again, NUT is NOT designed for meeting ridiculous
buffering
constraints of particular hardware. It's designed for
device-independent media streams, data that's universally
usable
without gratuitous buffer requirements beyond what's
naturally needed.
This is why we don't have stupid things like preload. Now
you're
talking about all kinds of ridiculous device-dependent
issues which do
not belong in NUT. The days of tiny buffers will be over
long before
anyone adopts NUT in broadcast applications, regardless of
what design
decisions we make. The revolutionary thing is being a format
that's
oriented towards device-independence, as opposed to being
oriented
towards particular implementations.
> And that reminds me, for broadcast, we might need an
additional timestamp
> to synchronize the decoder. Oterwise clock drift
between decoder and encoder
> can cause buffer over/underflows. This also affects
single program per nut.
> But i assume the mystery protocol takes care of that as
well.
There's no use for additional timestamps. The decoder just
needs to
synchronize time to the timestamps in the stream,
compensating for any
drift. It makes no difference whether you use the audio
timestamps or
the video timestamps or some special additional out-of-band
timestamp
system as long as you do the compensation one way or
another.
Rich
_______________________________________________
NUT-devel mailing list
NUT-devel mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|
