File: notes.txt

package info (click to toggle)
liboggplay 0.3.0-3
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 3,876 kB
  • sloc: ansic: 6,273; sh: 4,484; javascript: 236; makefile: 215
file content (41 lines) | stat: -rw-r--r-- 2,023 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Tracks with Premature Endings
-----------------------------

It is possible for some tracks to end at a timeval which is less than the ending
of other tracks:


|--------------------*---------------------*|
                     audio ends            video ends


There is a 'target' member in the OggPlay struct which indicates the current
timeval target.  On each OggPlayDataCallback to the user there is a guarantee
that all active tracks have data decoded up to the 'target' timeval.  Before 
oggplay_start_decoding is called, the 'target' timeval is 0.  After a seek, the
'target' is the seeked-to position.  Hence target can be used at these points
to determine where in the file the decoder is.

During decoding (inside the oggplay_start_decoding loop), target is instead 
used to indicate where we need to decode to before calling back to the user
again.  Hence target can not be used for "where we are" inside the loop.

When decoding begins, we do not know where each stream ends.  Furthermore,
if we seek to an arbitrary location within the file, we may well seek beyond
the end of a stream.  Hence initially the final_granulepos member of each 
track's data structure is set to -1.

When the user attempts to set a track active, then we can check the 
final_granulepos value and target (this can only happen before 
oggplay_start_decoding and in callbacks, so it is safe) and throw an error if
we *know* that the timeval is out of range for the track.  When we are parsing
the stream and we get an e_o_s page in a track, then we can set the track to
not active and record the final_granulepos value.  If the user retrieves data
they get data up to the end of the track.  If they try to set the track as 
active then this will fail with an error.

A bigger problem is if the user seeks to a region of the file after a track end
without having already found the end of that track.  In this situation, there
is no simple way to determine presence or absence of the track - how will we
cope with finding the start?