Re: to be effcient or not to be efficient

* Steve Lhomme <[email protected]> [2004-01-08 09:53:39 +0100]:

<snip>
> Oh, BTW. Playing a stream backward is one of my requirements. I'm not 
> sure there are many APIs that can allow that. Unless you do a timecode 
> trick (reverse it) on the source material.
hmm, thats quite tricky.
it could be implemented in a similar way as seeking: 

decode a bunch of frames (i.e. until next keyframe) and pushing them
out in reversed order ... then seeking to the previous frame-bunch
(i.e. prev keyframe)

both situations - seeking and reversing - require some way for a the
chain element where the action is made, to get others informed about 
its requirements, i.e. tell the demux to jump to a specific position
or tell the filters and output behind to flush, etc.

if we're using autonomous filters, the application layout could look like:


<storage> ==> <demux> --> <mpeg2rgbpixmap> --> <rgbpixmap-display>
                   |         ^        |          ^
                   +-- |PL| -+        +-- |PL| --+


In this model they player core explicitly fetches out data chunks
and pushes it into the next chain element.

If we wanna do seeking, it could look like this:

    ask display if it can seek / how far it can.
	--> has no cache, etc, so it will say 0.
	
    ask mpeg-decoder how far can seek
	--> a) its in the decoder's current frame-chunk (between keyframes?)
               so it tells the caller: "yes I can, please flush evrything
	       behind me (i.e. flush-until <timestamp>)"
	--> b) seeking is too far for its buffer, it will say 
               "no my dear, i cannot do this. ask my supplier"

    in case b) the player now calls the demux "bring me to the point X"
    the demux then does a seek in the underlying file (if possible) or 
    somehow change the source position in the stream (i.e. rtp, ...).
    and replies "i've brought you to the position Y which is some steps 
    before X". Now the player calls the mpeg-decoder again:
    "now flush your input and notice you're on Y, and seek forward to X,
    no matter what comes (maybe drop unused frames)"
    The mpeg-decoder then replies: okay, but please flush evrything 
    behind me.

Okay, this was the scenario for video-only playback and only one codec 
in chain. But how gets the situation if we also wanna have synchronized
audio ? And what to do if we have more filters ?

Well, for editing, we could have random-seek-improved codecs, which
do large buffering of already-decoded frames. But this should not be
the scope of this API.



cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     [email protected]
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/