On Wed, Nov 15, 2006 at 03:07:49AM +0100, Michael
Niedermayer wrote:
> On Wed, Nov 15, 2006 at 02:17:03AM +0200, Oded Shimon
wrote:
> > On Tue, Nov 14, 2006 at 07:04:43PM +0200, Oded
Shimon wrote:
> > > On Sun, Nov 12, 2006 at 05:27:06PM +0200,
Oded Shimon wrote:
> > > > On Fri, Nov 10, 2006 at 08:57:23AM
+0200, Oded Shimon wrote:
> > > > > This is a new proposal: Basically
identical to the previous one, only info
> > > > > packets SHOULD NOT appear "in
the wild" in non-realtime-streams instead of
> > > > > MUST NOT. Making the distinction
between file and realtime streams less
> > > > > strict. Demuxers still SHOULD NOT
search for info packets anywhere except
> > > > > after the main headers. I think
this is most clean...
> > > > >
> > > > > Comments?
> > > >
> > > > Repost. ... 48 hour notice ...
> > >
> > > Committed
> >
> > OK, I'm sorry I committed this so hastily. You
said you object until you
> > have heard from Rich. I talked to Rich on IRC and
he seemed apathetic on
> > the issue and unwilling to reply on it. I changed
my proposal to be
> > somewhat saner with a less strict distinction
between realtime and
> > non-realtime streams, and you have not made any
objection reply since.
> >
> > Can we discuss this now?
>
> yes we can, what about keeping the current info after
header + info must
> be identical rule
> with an exception like
> if a nut "file" is transmitted over the
network and no out of band method
> to update metadata is available then info packets may
be placed between
> ?syncpoints? the contents of these info packets may
change and they do
> override the info packets after the mainheader. for the
normal info
> packets after the mainheaders the normal rules apply
(=no changes)
> dumping such a network stream to disk does not
constitute a valid nut
> file, to convert such a stream to a valid nut file it
is needed to
> read the whole to find the most up to date info and
then place this
> after every main/stream header group
>
> to simplify this conversation every of the
"new" info packets must
> contain a pointer to the previous "new" info
packet?
Do you suggest adding some sort of flag to info packets
saying if they are
"new" ones or "header" ones?
> and some approproate stuffing/empty info packet should
be added
> after all main/stream headers?
Well, for one, this stuffing packet would violate the
"identical info
packets after main header" rule. Also, the main headers
are in the
begginning, and a smart network stream would have no reason
to repeat
them, so they will not point backwards to anything...
I don't think the pointer stuff helps at all - either the
stream dumper is
NUT aware, in which case it can rip out all the info packets
found during
dumping (and optionally add them to main headers somehow),
or it is not
NUT aware and it doesn't care anyway.
You seem to be scared of people putting info packets in the
middle of
files or in dumped realtime streams - I don't see this as an
issue.
Demuxers SHOULD NOT search for info packets anywhere except
after the main
header. If you were silly enough to stick an info packet
somewhere in the
middle, a demuxer will not see it until playbacking that
point (you
SHOULD NOT do this). And in the case of dumped realtime
streams, you can
fix them fairly easily by remuxing...
- ods15
_______________________________________________
NUT-devel mailing list
NUT-devel mplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|