Hi one index for syncpoint pos, one for each stream? comments? -- Michael
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. - ods15
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]) [...] -- Michael
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])
You mean, for the syncpoint positions?.. I actually have tried that already (only the former suggestion), quite a while ago... and found it to be completely useless... At least for my test video. The numbers were pretty much out of /dev/urandom ... Actually, hmm, I tried something different, iirc it was '65536 - sp[i-1]' or something like that... I'll look into this... BTW, whats median() ?... - ods15
Hi On Sat, Mar 11, 2006 at 04:49:16PM +0200, Oded Shimon wrote:
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])
You mean, for the syncpoint positions?.. I actually have tried that already (only the former suggestion), quite a while ago... and found it to be completely useless... At least for my test video. The numbers were pretty much out of /dev/urandom ...
Actually, hmm, I tried something different, iirc it was '65536 - sp[i-1]' or something like that... I'll look into this...
BTW, whats median() ?...
median(a,b,c) = a+b+c - max(a,b,c) - min(a,b,c) [...] -- Michael
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
Hi On Sat, Mar 11, 2006 at 06:51:44PM +0200, Oded Shimon wrote: [...]
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 :)
agree [...] -- Michael
participants (2)
-
Michael Niedermayer -
Oded Shimon