[MPlayer-dev-eng] new nut thread

[D Richard Felker III]

On Fri, Oct 08, 2004 at 04:13:15AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Friday 08 October 2004 00:10, D Richard Felker III wrote:
> [...]
> > 3. keyframe backpointers at syncpoints
> >
> > proposed by me
> > i'm unsure whether it's helpful or wasteful
> 
> well, i dont like the idea at all, but i dont know an alternative which would 
> work without an index and without simply repeating the keyframes, later is 
> obviously worse then pointers to them in terms of overhead
> one small improvement would be to store only approximate positions / dont 
> store the least significant bits
> 
> so summary: agree unless we find another solution

agree? if you agree with me then you're not sure if it's a good idea
or a bad one. ;)

basically i think there are several ways of looking at it:

- ignore old packets from other streams. no backpointers needed. this
  is probably fine for most players with most codecs for the
  forseeable future, but for precision encoding and editing apps it
  might be annoying not being able to find a frame. there could also
  be issues in the future if audio also has inter packets and the
  keyframes don't line up with video.

- backpointers should be a special kind of packet in a stream and
  should only appear when there was no keyframe for the stream between
  the last syncpoint and the new one. likely they should be optional.

- backpointers should be incorporated into the syncpoint and always
  present. this adds a lot of overhead.

there's of course middle ground between the second and third option
too. basically if you add backpointers to the syncpoint, there's
always going to be a little additional overhead even if they're not
needed. but if you add separate packets for backpointers for each
stream, the overhead might be bigger if lots of streams need them.

my inclination is to do all this in some way that it's optional, so
that it can be used with future codecs if needed, but so that it
doesn't waste space on files that don't need it.

> > 5. merging info header with main/stream header, adding info streams
> >
> > proposed by me
> > i don't think michael or anyone else has commented on it yet
> > i'm strongly in favor of doing this unless a good argument against it is
> > made
> 
> generic data streams: ok
> streams containing what info packets do contain: dunno, it increases 
> complexity i dont see much advantage in it
> merging info packets with the other packets: iam against that

did you read my original idea about separating info headers from
streamed (interleaved) info packets? there's a good reason i want to
do something like that. (e.g. if we have backpointers you'd want a
backpointer for info-streams too so you could find the last info
packet. also the idempotent remux thing i mentioned before.)

anyway would you mind explaining what you're against, and why?

> > 6. finalization packets
> >
> > proposed by me
> > i'm in favor and someone else liked them too
> > seems to be no objection
> 
> iam not against this but this would need to be optional, as in many cases the 
> duration is simply not known, its also a little confussing with b frames 
> allthough it should work

i tend to agree that optional is good, but it would also be really
helpful if it were always included, e.g. for streaming servers to
string files together.

rich