On Sat, Mar 11, 2006 at 03:29:46PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 10, 2006 at 11:28:38PM +0200, Oded Shimon wrote:
On Fri, Mar 10, 2006 at 02:42:00PM +0100, Michael Niedermayer wrote:
Hi
one index for syncpoint pos, one for each stream?
Hmm, not sure it is worth it.. How do you even tell between them (I guess a stream_id_plus1 in the begginning). Doesn't add much for robustness (the stream stuff is tiny, 1-4kb of 80kb), and brings back the old index_ptr and several index complexity issues.. I'm against.
ok
btw, how much space would we gain/loose if we use - sp[i-2] + 2*sp[i-1] as sycpoint position predictor instead of sp[i-1]? or even sp[i-1] + median(sp[i-1] - sp[i-2], sp[i-2] - sp[i-3], sp[i-3] - sp[i-4])
Sorry, nothing: current: 53686 bytes method1: 52586 method2: 52823 Also, I was wrong, of the 83kb index, 53.7kb is syncpoint positions, 3kb is video, and 27kb is audio. The 27kb of audio is all the pts differences, which are all very tiny (but not similar) numbers (1 to 5) Hmm, on a different file... 65kb index, 39kb syncpoint positions, 7kb video, 20kb audio current: 38821 bytes method1: 20082 bytes method2: 20414 bytes I don't think it's worth it though, this file had 2-3mb overhead anyway (low bitrate, 620mb file), these 18kb aren't worth the complexity :) - ods15