[NUT-devel] Issues

[Michael Niedermayer]

Hi

On Mon, Mar 06, 2006 at 10:39:01AM +0200, Ivan Kalvachev wrote:
[...]
> > this is not a cosmetic issue, you guys want restrictions which make no sense
> > and which restrict actually usefull and needed cases
> >
> >
> > heres what i have in my nut fork on my disk: (note, there are no info streams)
> >
> > Rules for realtime streams:
> >
> > If a info packet X is transmitted anywhere then an info packet with the same
> > chapter and stream_id MUST be placed so that there is never a mainheader
> > and following frame covered by the info packet without the info packet
> > inbetween
> > example: M(mainheader) F(frame covered by infoPacket) f(other frame) I(info)
> >  M f f M f I f F F M I F F M I F F f f M f f M
> > as a special exception very large and unimportant info packets can be
> > transmitted less often
> >
> > If 2 info packets have the same chapter_id and stream_id then the earlier
> > MUST be ignored (the last info packet is the most correct, this allows
> > updating or correcting info)
> >
> > Rules for non realtime streams:
> >
> > 2 info packets with the same chapter_id and stream_id MUST be identical
> >
> > Every info packet which is stored anywhere in the file MUST also be stored
> > after every mainheader-streamheader set
> 
> Somehow I don't like to distinguish between realtime and non-realtime streams.
> 
> I am  concern about how will the later info stream be found on
> seeking. It is quite possible for
> it to be missed. (assuming you can seek in realtime stream, e.g. by
> storing or buffering it).

well, lets see, if the seek happens purely in the clients buffer then theres
no issue as the client must have seen all the needed info already, that
leaves the issue with asking the server to seek to X, here there are a few
specific cases
1. the server dynamically inserts the needed info (no problem)
2. back_ptrs are set so that they point to the info pakets (no problem)
3. back ptrs ignore info packets (problem here)

so only case 3 matters for us, we could simply add a rule that dissalows
it in realtime streams

now how does the rich-oded proposal differ, not at all their info streams
would either force back_ptrs to point to info frames or would missuse EOR
and cause info not to be found, we can achive the same here

so again lets see which solutions there would be for case 3 (serverside seek
but server is not able to dynamically insert info packets and backptrs ignore
info packets)
A. dissalow it
B. use info streams and dissalow ranodom EORs (practically identical to A.)
C. per stream back ptrs and pts in the syncpoints, and require the demuxer to
   seek first to the info packets and then seek to the actual video/audio
   (O(N*log(N)) overhead per N streams, mandatory high complexity on the
   demuxer side)

iam in favor of A. and iam strongly against C.

[...]

-- 
Michael