similar to: fishead granule rates

I've developed an indexer which embeds a keyframe index track in Ogg files. It embeds the index in its own track, so that players that don't understand or don't want to use the index can just ignore it. Ogg needs this to make seeking over networks faster and more efficient. Currently we must do a bisection search when seeking, which usually takes aound 6 HTTP requests, give or

I've been looking over Benjamin Schwartz's Skeleton A-mod proposal. I've been pretty busy with other projects over the past few months, so haven't had a chance to look at Ogg indexing until now... In general, I think Benjamin's ideas are sound, they're improvements, and I'm open to being convinced to take them in the next index version. We may as well get the index

Hi everybody, I've updated OggIndex to now output Skeleton 4.0 tracks. The differences between Skeleton 3.x and Skeleton 4.0 with OggIndex is: * The fisbone packet now includes a "Radix" field. * The fisbone packet now includes two new compulsory message headers; "Role" and "Name". * The fishead packet no longer includes "start time"

2008/11/21 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-21, Conrad Parker <conrad at metadecks.org> wrote: >> 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

OK... i've come across a problem trying to get the granule pos of the start of the page... it's not so crucial with single stream ogg files... but now that i have theora+vorbis in a file, i'm finding that when i seek to a position, i have no way to determine the relative offsets of the different streams at the new seek point and hence the av is out of sync. So given a page, is it

On Fri, Jun 5, 2009 at 4:30 AM, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote: > It holds the granulerate, so it'd allow this for those codecs that use the > granule shift way of encoding their granules (except for those pages > where no packet ends, as these will have no granpos set). BTW, we need to add another field out of the remaining reserved bits

[cc'd to ogg-dev] Hi Tahseen, thanks, I've checked and applied this patch to liboggz svn (rev 2378): http://trac.annodex.net/changeset/2378 Two requests for further patches: 1. could you please document the -k switch in the --help output, and in the man page (doc/oggzinfo.1.sgml) 2. there's some extra newlines between the info for each track, could you try cleaning that

With the storage array in place it's now trivial to support CLOCK_TAI in the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use of the fact that: - CLOCK ids are set in stone - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so the array slot 3 is unused - CLOCK_TAI is id 11 which results in 3 when masked with 0x3 Add the mask to the basetime array

> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > > With the storage array in place it's now trivial to support CLOCK_TAI in > the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use > of the fact that: > > - CLOCK ids are set in stone > - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so >

> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > > With the storage array in place it's now trivial to support CLOCK_TAI in > the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use > of the fact that: > > - CLOCK ids are set in stone > - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so >

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

Hi, I'm currently implementing OggSpots [1] support for VLC. In the "spec" it says that the granulerate is to be interpreted as in Ogg Skeleton so it should be possible to calculate `granulepos / granulerate` to get time. But it also says: The default granule rate for OggSpots is: 1/30 (30 frames per second resolution). To me that doesn't make sense. If we want to

Hi, I got a short question regarding the ogg skeleton. As far as I understand it, the skeleton information helps to decode the timeing from the granule position, that is available in every ogg page, so that I can say, what is the end time of the last full ogg packet within an ogg page. So but it does not help me finding out the timing information about the other packets in between? -Yorn

On 2008-11-21, Conrad Parker <conrad at metadecks.org> wrote: > 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

>>> http://trac.annodex.net/changeset/3801 >> >> I'll test this shortly. Ok, i've tested muxing some audio and video together and that works fine. woo. >> 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 oggskeleton. This raises the slight

This patch adds an applet option to Cortado. The option is off by default, meaning that the default behavior of Cortado should not change at all. If the option is activated, Cortado will display all times relative to the ogg file's basetime (i.e. first granule). This patch was written in response to a request from Se?or Ellery, who noted that files ripped from the middle of a stream do not

We have new drafts of CMML 4.0 as a text codec and ROE as an xml stream abstract, subsuming the authoring support in CMML 3.1 and earlier. Another thing we talked about at LCA is a how to specify relationships between the various streams in Ogg so that a server, muxer or player can make intelligent decisions about the contained tracks. The general idea is to use the (http-style) Message

Hi, I've seen several implementations of Ogg demuxing that use a zero granulepos to detect headers. However, I do not recall seeing this in the Ogg docs - is this an abuse that happens to work because Vorbis is timed by end granule, or is it a proper way to check ? Thanks

Oggz 0.9.9 Release ------------------ Oggz comprises liboggz and the tool oggz, which provides commands to inspect, edit and validate Ogg files. The oggz-chop tool can also be used to serve time ranges of Ogg media over HTTP by any web server that supports CGI. liboggz is a C library for reading and writing Ogg files and streams. It offers various improvements over the reference libogg,

On 16/02/2008, Ralph Giles <giles@xiph.org> wrote: > The general idea is to use the (http-style) Message Headers > in the Skeleton track to describe each logical bitstream, but no one > has ever written anything down. This is a proposal to get the ball > rolling. awesome, thanks :-) > Lang: <locale> generally I think we should go with existing HTTP and email