[MPlayer-dev-eng] a few nut suggestions [back-reference packets]

[Michael Niedermayer]

Hi

On Monday 04 October 2004 04:38, D Richard Felker III wrote:
> On Mon, Oct 04, 2004 at 02:38:05AM +0200, Michael Niedermayer wrote:
> > > my idea is to provide a "back-reference" packet type for streams to
> > > use. essentially it would be optional, but it would work like this.
> > > before writing a syncpoint (startcode), check each stream to see if
> > > you've written a packet for that stream since the previous syncpoint.
> > > if not, write a back-reference packet for the stream containing just
> > > the (negative) byte offset to the previous packet in the stream. that
> > > way the player can easily find the previous packet, check its
> > > duration, and see if it still applies.
> >
> > and how does this work with realtime streams? for example the song info
> > for the first played song would then be unavailable, the 5min subtitle
> > too if we missed it due to the startpos or packet drop ...
>
> actually i said all this with realtime streams in mind too. if i made
> a realtime streaming server, i would make it always send any
> still-relevant info packets at the beginning of the transmission when
> a new client connects.

ugh, so the server needs to parse and reorder the stream per client? my first 
thought is this is braindamaged and i would avoid nut then if i had the 
choice


>
> > IMHO info packets or packets in an info stream need to be repeated
> > frequently enough to avoid the above issues, and if we do repeat them
> > frequently then
>
> naturally something else needs to be done if it's a realtime stream
> the client passively receives, e.g. over radio or something. in a case
> like this, repetition might be useful. but imo repetition is just
> wasteful when streaming over any medium where a reliable channel is
> available.
>
> > the back reference becomes pretty much unnecessary as searching through
> > 0.5 or so seconds of the bitstream is easy
>
> yes. but repeating data again and again could be very wasteful.
> especially if it's big data. (and who knows what someone will want to
> store in info packets...)

yes, if we reverse the keyframe -> syncpoint index change u purposed we could 
use the index to find this data very efficiently in non realtime streams, and 
for realtime we must repeat the packets anyway due to packet loss and similar


>
> > furthermore the demuxer is able to find video keyframes, so why shouldnt
> > it also use the same method to find audio or subtitle keyframes?
>
> there will be a sane upper bound on distance between keyframes. is
> there necessarily a sane upper bound on distance between subtitles or
> infopackets? imo not...

imo there should be


[...]
> anyway, the keyframe search algorithm basically goes like this, iirc:
> 1. seek to a syncpoint (index O(1) or binary search O(n log n))
> 2. scan for keyframe (linear search O(keyint))

no, this is wrong, it simply wont work, its

find_prev{ search for the previous sync code linearly or by index }
find_next{ follow and parse all framecodes until a keyframe after the 
requested position is found }
2. do a binary search using {find_prev;find_next}

before the changes u requested it was possible to do a binary search to the 
keyframe_startcode and u had a useable keyframe after this, maybe not the 
closest keyframe but it was guaranteed to work as a low complexity seeking 
implementation

but with syncpoints and without the "MUST" rules which guaranteed the low 
complexity seeking to be possible, this doesnt work anymore

[...]
-- 
Michael

"I do not agree with what you have to say, but I'll defend to the death your
right to say it." -- Voltaire