search for: keyframe_granule_shift

...z/oggz_auto.c =================================================================== --- liboggz/oggz_auto.c (revision 3759) +++ liboggz/oggz_auto.c (working copy) @@ -358,31 +358,26 @@ static int auto_dirac (OGGZ * oggz, long serialno, unsigned char * data, long length, void * user_data) { - char keyframe_granule_shift = 32; - int keyframe_shift; + int granule_shift = 22; /* not a typo */ dirac_info *info; info = malloc(sizeof(dirac_info)); dirac_parse_info(info, data, length); - /* - FIXME: where is this in Ogg Dirac? - keyframe_granule_shift = (char) ((header[40] & 0x03) << 3); -...

Hi Sahana I must admit I'm not an expert in Theora. But the error message "Could not set keyframe interval to 64" might indicate that an attempt to set the keyframe frequency failed. Have a look at the keyframe_granule_shift attribute in the th_info struct. It says: The maximum distance between key frames is 1<<keyframe_granule_shift. So I could imagine that the error might be caused by setting the keyframe_frequency to a larger value than permitted by the keyframe_granule_shift field (e.g. with TH_ENCCTL_SET_KEY...

...info.fps_numerator = 10; info.fps_denominator = 1; My understanding is that this is the framerate, and that the parameters above means 10 frames per second, Is that right? info.aspect_denominator = 0; info.aspect_numerator = 0; Here I use the default, and hope that is OK. info.keyframe_granule_shift = 10; I'm uncertain on what the intention of the parameter is. It seems like it is the frequency keyframes are sent in, so the parameter above would mean that every 10th frame is a keyframe, but I'm not sure that is right, and would like this parameter to be explained, as it was not ob...

...ti.fps_numerator = 30; ti.fps_denominator = 1; ti.aspect_numerator = 0; ti.aspect_denominator = 0; ti.colorspace = TH_CS_UNSPECIFIED; ti.pixel_fmt = TH_PF_422; ti.target_bitrate = -1; ti.quality = 48; ti.keyframe_granule_shift=ilog(keyframe_frequency-1); What can cause such a problem? Regards Mario

...has to be made. The keyframe number should be extracted from the granulepos of the frame where we want to seek to. I hope I understood the theory - unfortunately a few questions have rised during implementation: - How do I extract the keyframe number? Is shifting the granule position by "keyframe_granule_shift" correct? - How can this be implemented using the OGGZ library? My current, _UGLY_, approach is the following: a) At the start of seeking, set the Packet-/Page-Callback to a new "Seek"-Callback b) A first OGGZ seek jumps to the desired frame number. c) OGGZ read() with som...

On 15-Feb-08, at 6:44 AM, ogg.k.ogg.k@googlemail.com wrote: > Well, it doesn't quite work because the second part of the gpos is > an offset, > rather than absolute, and the precision we shed on one, we need to > recover > on the other one, to keep the ability to timestamp events at the > correct > granularity. It would have worked if the second part was absolute

...fraction is the same for both base and offset, so backwards compatibility is kept for streams encoded with the existing method. For reference, the code difference between the two methods is: Current method (from libtheora's toplevel.c): ogg_int64_t iframe=granulepos>>pbi->keyframe_granule_shift; ogg_int64_t pframe=granulepos-(iframe<<pbi->keyframe_granule_shift); return (iframe+pframe)* ((double)pbi->info.fps_denominator/pbi->info.fps_numerator); Proposed method (from libkate's kate_granule.c): base=granulepos>>ki->granule_shift; offset=(gr...

...so > backwards compatibility is kept for streams encoded with the existing > method. > > > > For reference, the code difference between the two methods is: > > Current method (from libtheora's toplevel.c): > > ogg_int64_t iframe=granulepos>>pbi->keyframe_granule_shift; > ogg_int64_t pframe=granulepos-(iframe<<pbi->keyframe_granule_shift); > > return (iframe+pframe)* > ((double)pbi->info.fps_denominator/pbi->info.fps_numerator); > > Proposed method (from libkate's kate_granule.c): > > base=granulepos>...

...necessary because ogg only tells you where a frame ends, not where it starts. My code has two further optimisations: - if playing sequentially (current_frame - last_frame < threshold), you don't need to seek again (from trial and error I found threshold is best if it is around 1/4 of the keyframe_granule_shift). Just continue decoding. - I create a hash table of largest granule pos -> keyframe as this is discovered. Doing a binary tree search of this first can help narrow the initial search range for keyframes which have already been discovered It's all in the code here: http://lives.svn.sourcef...

...ot where it starts.<br><br><br><br>My code has two further = optimisations:<br>- if playing sequentially (current_frame - last_frame &lt= ; threshold), you don&#39;t need to seek again (from trial and error I foun= d threshold is best if it is around 1/4 of the keyframe_granule_shift). Jus= t continue decoding.<br> <br>- I create a hash table of largest granule pos -&gt; keyframe as this i= s discovered. Doing a binary tree search of this first can help narrow the = initial search range for keyframes which have already been discovered<br> <br>It&am...