Displaying 4 results from an estimated 4 matches for "datawise".
2008 Feb 11
4
Seeking to granules in discontinuous streams
....
Following on your point about a lower bound on the frequency, maybe one
could add "keepalive" packets when no data packets have been issued for
a long enough time, and such packets would carry no data but the backlink
itself. Hmm, I like the idea. The packets would be very small (well, datawise,
most of the data will be Ogg header stuff), and we wouldn't get that bad data
duplication that was inherent in the "echo" method described in the Writ doc.
Mind you, that kind of frequency info is something that might be usefully put
in a new skeleton field, if it could help the see...
2008 Feb 12
0
Seeking to granules in discontinuous streams
...point about a lower bound on the frequency, maybe one
> could add "keepalive" packets when no data packets have been issued for
> a long enough time, and such packets would carry no data but the backlink
> itself. Hmm, I like the idea. The packets would be very small (well,
> datawise,
> most of the data will be Ogg header stuff), and we wouldn't get that bad
> data
> duplication that was inherent in the "echo" method described in the Writ
> doc.
We have considered the "keepalive" idea for CMML, too, for similar reasons.
I think it may well...
2008 Feb 11
0
Seeking to granules in discontinuous streams
...und on the frequency, maybe
> one
> could add "keepalive" packets when no data packets have been issued
> for
> a long enough time, and such packets would carry no data but the
> backlink
> itself. Hmm, I like the idea. The packets would be very small
> (well, datawise,
> most of the data will be Ogg header stuff), and we wouldn't get
> that bad data
> duplication that was inherent in the "echo" method described in the
> Writ doc.
That's the sort of thing I was talking about.
> Mind you, that kind of frequency info is someth...
2008 Feb 07
2
Seeking to granules in discontinuous streams
> No particular answers, but I can at least point out that the way
> things were designed for CMML was to work with the existing Ogg
> seeking algorithm. The idea is that a generic seeking routine can work
> on any Ogg file, as long as it knows the granulepos->time mapping for
> the logical bitstreams in the file. That's why all the
> timestamp-related info is crammed into