search for: granuleshift

> Leaving aside what the hypothetical seek algorithm would or wouldn't > do, I believe that would work. It's still different from existing > schemes though. Yes, it is different technically. However, I was trying to find something sufficiently close to the system of granuleshift, which you seem to want to become the "standard" way of mapping time to granules, despite Ogg leaving this to each codec. What I outlined is a superset of that system, with the granuleshift as in Theora/CMML, and a second granuleshift in the other direction, to mask out the lower bits, i...

...are operating on >>> something containing oggdirac. >> >> I started patching oggz sort and merge, and discovered they were very nearly >> working. After adding a custom function to convert granulepos to time for >> Dirac, rather than just going by the result of the granuleshift, it seems to >> be working. You can review the changeset here: >> >> http://trac.annodex.net/changeset/3801 > > I'll test this shortly. great, thanks > My only initial concern is about the definition > of granule_rate. My intention is to add some guidance to the...

After some more thought on this, I'm trying to work out whether the back link offset needs precision. Semantically, the only need we have for this is to be able to seek back to a point before the start of the earliest event still active at the time of the original seek. As far as I know, and please correct me if I'm wrong, nothing in Ogg mandates that this backlink actually resolves to a

...be worth having them 'warn' if they are operating on > something containing oggdirac. I started patching oggz sort and merge, and discovered they were very nearly working. After adding a custom function to convert granulepos to time for Dirac, rather than just going by the result of the granuleshift, it seems to be working. You can review the changeset here: http://trac.annodex.net/changeset/3801 please test :-) For example you can start by ripping an existing Dirac+Vorbis stream apart: $ oggz rip -c vorbis input.ogv -o vorbis.ogg $ oggz rip -c dirac input.ogv -o dirac.ogv Then merge them...

...ing is to identify which algorithm to use for converting > granulepos to time. agree. > The way the current Dirac mapping works doesn't really fit into either of > those granulepos schemes, though it does do an awesomely clever job of > allowing pt to be calculated with the Theora granuleshift method :-) The Dirac one tries to pretend to be both: - vorbis like: GP64 * gp64_rate = decode/muxing time + jitter - granuleshift like: GPH+L * gphplusl_rate = presentation time + jitter And if one knows how to decode it fully, the jitter disapears. So it is a bit quantum: it sometimes behave...

...coded > integer. This is the difference from the previous keypoint's granpos > value. The keypoint's granpos is therefore the sum of > all the granpos deltas up to and including the keypoint's. Would you expect the granulepos scaling shift to be equal to the granuleshift for theora streams, at least initially? Have you given any thought to how to determine good values for the shifts and Rice parameters? All the best, Chris P.

...position for an OggDirac elementary stream isn't the same as theora. Index: tools/oggz_tools.c =================================================================== --- tools/oggz_tools.c (revision 3759) +++ tools/oggz_tools.c (working copy) @@ -454,7 +454,15 @@ iframe = granulepos >> granuleshift; pframe = granulepos - (iframe << granuleshift); - ret = fprintf (stream, "%" PRId64 "|%" PRId64, iframe, pframe); + if (oggz_stream_get_content (oggz, serialno) != OGGZ_CONTENT_DIRAC) { + ret = fprintf (stream, "%" PRId64 "|%" PRId64,...

Is anyone working on liboggplay, and if so, is there any plan to support keyframe-based seeking? I found this, but seems to me that the feature ought to be part of liboggplay: http://pearce.org.nz/2009/05/video-seeking-improvements.html Is there a more appropriate list to post to regarding liboggplay? Shayne Wissler -------------- next part -------------- An HTML attachment was scrubbed...

...39;warn' if they are operating on >> something containing oggdirac. > > I started patching oggz sort and merge, and discovered they were very nearly > working. After adding a custom function to convert granulepos to time for > Dirac, rather than just going by the result of the granuleshift, it seems to > be working. You can review the changeset here: > > http://trac.annodex.net/changeset/3801 I'll test this shortly. My only initial concern is about the definition of granule_rate. My intention is to add some guidance to the oggdirac mapping spec on how to apply oggskel...

...ay; } int Index: src/liboggz/metric_internal.c =================================================================== --- src/liboggz/metric_internal.c (revision 3827) +++ src/liboggz/metric_internal.c (working copy) @@ -53,7 +53,7 @@ pframe = granulepos - (iframe << stream->granuleshift); pt = (iframe + pframe) >> 9; delay = pframe >> 9; - dt = (int64_t)pt - delay; + dt = (ogg_int64_t)pt - delay; units = dt * stream->granulerate_d / stream->granulerate_n;

> any new fields. However, I cannot even find Dirac in oggz > http://git.xiph.org/?p=liboggz.git;a=blob;f=src/liboggz/oggz_auto.h; There's dirac.[ch] in the tools directory, though I haven't looked at what's in there. Not sure why it's segregated like that.

...available as a source tarball at: http://www.annodex.net/software/libannodex/download/libannodex-0.6.0.tar.gz New in this release: Support for Annodex version 3: * Support for reading and writing Ogg Skeleton and CMML binary headers * Support for recomposition from keyframe offsets, using granuleshift clues from Theora and CMML headers. This provides efficient playback of video and the current CMML clip. * Read-only support for reading and importing Annodex v2 content to allow existing content to be recomposed in v3 format without modification. General improvements and bugfixes: * Upda...

...Ogg FLAC files to be used with oggzmerge and similar tools. * fixed oggzmerge binary open bug on Win32 (Colin Ward) * updated Win32 project by Orum * added inbuilt parsing of Ogg Skeleton and CMML binary headers * simplified documentation related to seeking * added oggz_{get,set}_{granulerate,granuleshift}() query functions About Oggz ---------- Oggz comprises liboggz and the command-line tools oggzdump, oggzdiff, oggzmerge and oggzrip. liboggz supports the flexibility afforded by the Ogg file format while presenting the following API niceties: * Full API documentation. * Comprehensive test s...

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

...Ogg FLAC files to be used with oggzmerge and similar tools. * fixed oggzmerge binary open bug on Win32 (Colin Ward) * updated Win32 project by Orum * added inbuilt parsing of Ogg Skeleton and CMML binary headers * simplified documentation related to seeking * added oggz_{get,set}_{granulerate,granuleshift}() query functions About Oggz ---------- Oggz comprises liboggz and the command-line tools oggzdump, oggzdiff, oggzmerge and oggzrip. liboggz supports the flexibility afforded by the Ogg file format while presenting the following API niceties: * Full API documentation. * Comprehensive test s...

...is resolved in the next 48 > hours or so, before doing a 1.0.1 bugfix release. So if you have > input, now's the time! My preference would be for a bos page which the following are easily parseable: Ogg/Dirac mapping version (versioning for this mapping, not for Dirac codec) Framerate Granuleshift (unless invariant in this ogg mapping) These ideas are partly based on FLAC's Ogg mapping: http://flac.sourceforge.net/ogg_mapping.html An "extra headers field" (like in FLAC and Speex) could be useful for forwards-compatibility, eg. if there could be a vorbiscomments packet in futu...

...o 1763535876, granulepos (pt:10,dt:8,dist:6,delay:2), packetno 8: 986 bytes The dirac mapping maintains the property that GP64 (the raw granule_position) is always increasing. This value is related to dt. In order to get the presentation time of the dirac picture, you split the GP64 value at the granuleshift point yeilding high & low; these are then summed. (i call this GPH+L) Dirac is an out-of-order codec, the presentation time therefor jumps around. What you are seeing is correct. This also raises a few important points. When multiplexing streams together, it is important to use the time rel...

...t shows the two different methods and the granules generated by base/offset pairs, along with the number of bits each requires. For a timestamping precision of 1ms, as you can see by running the program, the existing method can't handle a base+offset of more than about 50 days. If you move the granuleshift around, since the two are added together, you just move the granulespace from base to offset or the other way round, without getting more actual space. With the method I've described, one can choose to lengthen the usable time space by losing precision on the base. As shown by running the prog...

...z-chop: fix detection of accumulated continued pages, ie. when all accumulated pages have granulepos -1 and thus should all be kept when advancing the accumulator * oggz-chop: add a page accumulator for plain pages. Accumulate pages even for start=0, or tracks with no granuleshift, for cases where continued pages occur at the chop time. * oggz-codecs: New tool * oggz-comment: Handle duplicate comments, with unit test Documentation ------------- * add oggz.1 man page * add examples to chop, comment, dump, info, merge, rip and sort man pages * update Chan...

...and > the granules generated by base/offset pairs, along with the number of > bits each requires. > > For a timestamping precision of 1ms, as you can see by running the > program, the existing method can't handle a base+offset of more than > about 50 days. If you move the granuleshift around, since the two are > added together, you just move the granulespace from base to offset or > the other way round, without getting more actual space. > > With the method I've described, one can choose to lengthen the usable > time space by losing precision on the base....