search for: granule_shift

...intention is to add some guidance to the oggdirac mapping spec on how to apply oggskeleton. This raises the slight problem for me in that i don't find the specification of skeleton particularly rigorous[1]. Actually, i don't even know what the definition of granule_rate applies to when a granule_shift is present[2]. Is it the whole number or the higher word. If we assume it is the higher word, i believe the granulerate would need to be 2*(1<<9)*fps_n/fps_d; in order to allow dumb tools to get things vaguely right. Ie, if you were to perform a remux by: foreach logical_stream s: forea...

...to.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); -...

2008/11/15 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >> It seems oggz chop, merge and sort will need some attention to deal >> with the Dirac granulepos and dependency ordering, so let's leave them >> for the next release. > > ok. -- may be worth having them 'warn' if they are operating

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

...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...

...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>...

...t;> mapping spec on how to apply oggskeleton. This raises the slight >> problem for me in that i don't find the specification of skeleton >> particularly rigorous[1]. >> >> Actually, i don't even know what the definition of granule_rate applies >> to when a granule_shift is present[2]. Is it the whole number or the higher >> word. If we assume it is the higher word, i believe the granulerate would >> need to be 2*(1<<9)*fps_n/fps_d; in order to allow dumb tools to get things >> vaguely right. > > a granule is a frame, field, sample e...

...dance to the oggdirac > mapping spec on how to apply oggskeleton. This raises the slight > problem for me in that i don't find the specification of skeleton > particularly rigorous[1]. > > Actually, i don't even know what the definition of granule_rate applies > to when a granule_shift is present[2]. Is it the whole number or the higher > word. If we assume it is the higher word, i believe the granulerate would > need to be 2*(1<<9)*fps_n/fps_d; in order to allow dumb tools to get things > vaguely right. a granule is a frame, field, sample etc., and granulerate...

...t;stats.h" +#include "video_preview.h" #define CATMODULE "format-theora" +#define PREVIEW_KEYFRAME_INTERVAL 3 #include "logging.h" +#include <png.h> - typedef struct _theora_codec_tag { theora_info ti; @@ -40,9 +41,14 @@ int granule_shift; ogg_int64_t last_iframe; ogg_int64_t prev_granulepos; +#ifdef WITH_PNG + theora_state td; + video_preview_t *video_preview; + yuv_buffer yuv; + int frame_count; +#endif } theora_codec_t; - static void theora_codec_free (ogg_state_t *ogg_info, ogg_code...

Updated version of video preview covering frame writing every 3 keyframe and a xsl typo. Best regards :) kysucix -- Make things as simple as possible, but no simpler. - Albert Einstein

Hi. Here it is my patch to put a video preview of a theora stream in status.xsl. I just added a: <video-preview>1</video-preview> parameters in icecast.xml.in that control the previewing function. It encodes a png in $webroot/$mountname.tmp and then move it to $webroot/$mountname.png As for now it saves a frame every theora keyframe, which is probably too heavy for the server but

David Flynn has proposed a new Ogg Dirac mapping. The draft is here: http://davidf.woaf.net/dirac-mapping-ogg.pdf This is a much bigger break from other codecs than my draft (at http://wiki.xiph.org/index.php/OggDirac). We talked a bit about it on IRC today. Below is my summary; hopefully David can correct anything I got wrong or misleading. Comments? There are two main differences