similar to: Determine number of frames

Ups! Maybe it's time somebody corrected that statement then - the wiki seems the right place to put the correct algorithm, IMHO. Cheers, Silvia. On Feb 13, 2008 10:06 AM, Ralph Giles <ralph.giles@artifex.com> wrote: > > On 12-Feb-08, at 2:57 PM, Ralph Giles wrote: > > > http://wiki.xiph.org/index.php/GranulePosAndSeeking > > I'm not sure it's helpful to

Dear all I'm aware that there have been several discussions about the seeking issue and I'm sorry to bring this up again. To solve the problem with Inter-Frame garbage, a seek to the previous keyframe 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

> No particular answers, but I can at least point out that the way > things were designed for CMML was to work with the existing Ogg > seeking algorithm. The idea is that a generic seeking routine can work > on any Ogg file, as long as it knows the granulepos->time mapping for > the logical bitstreams in the file. That's why all the > timestamp-related info is crammed into

Hi all, I'm actually learning how to use ogg, theora and vorbis. My idea is to create a small program running, that is able to concatenate ogg video+audio files. However I have some small questions. Here I will start with the first one: I read the following for seeking in ogg for a theora key-frame: ---- snipp (http://www.xiph.org/ogg/doc/ogg-multiplex.html) ---- [...]The third point

Folks have noticed that the documentation is semi-silent about how to properly encode the granule position and interleave synchronization of keyframe-based video. The primary reasons for this: a) we at Xiph hadn't had to do it yet b) there are several easy possibilities, and the longer we had to think about it before mandating One True Spec, the better that spec would likely be. The

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

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

One of the issues I've consistently run into with the cortado player app is seek behavior, so I was curious to see how cortado handles video encoded with the latest ffmpeg2theora (0.26) and the new -seek-index option, so I tried converting an h.264 video: ffmpeg2theora tronlegacy-tsr1_480p.mov --seek-index This output the following advisory messages: > Allocated 372 bytes for theora

Hi, I am continuing to try to debug my ogg/theora decoder. The issue seems to be that not enough packets are being pulled from the bitstream, here is some sample output from my player with some debugging comments put in: (playback began at first frame, this is from the middle of the clip) get page at 1765027 got packet frame++, skip is 0 frame decoded page processed, kframe=414 : offs=442 get

Question: is it permissible to put more than one frame packet into a page? At 30 fps, Ogg page overhead is on the order of 8 - 10 kbits/sec. At low datarates, this is going to be unacceptable. If I shove a few frames into a page, how does this affect the granulepos stuff? ___ Dan Miller (++,) Founder, On2 Technologies <p>--- >8 ---- List archives: http://www.xiph.org/archives/

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

> The advantage of storing this in the granulepos field itself, like > theora and CMML do, is that the seek code may already understand how > to handle the back pointer. Right now everything assumes the mapping > is from 'initialized decoder' + 'granulepos from page header' => > timestamp, or in the case of theora and CMML => 'timestamp' + 'last

Hi all, something which came up recently in relation to the design of Kate's granulepos was whether or not the granulepos of successive Ogg pages is allowed to be the same, ie. whether or not granulepos must be strictly increasing. As this question is more generally about Ogg granulepos, how about we answer it first and then get back to the discussion of Kate's granulepos ... Here is

On 02/05/07, Elaine YueLien <et@ihear.com> wrote: > Hi, > > Several months ago, I asked a question about seeking without a metric. > You can find one answer in this beta release, demonstrated in the > example program multiThreadSeek. There is also an example demuxer, and a > rewriter. Hi Elaine, congratulations :-) that's a nicely designed API you've got there.

Hi, sorry, there is a bug in the CMML spec and wiki page ... I discussed this with Silvia earlier this week but haven't gotten around to correcting it yet. CMML granulepos is much like theora's; the previous granule is stored in the higher bits, and the delta since then is stored in the lower bits. The current timestamp is the sum of the two. This is the behavior of the implementations

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 all, > One problem I see with your proposed implementation is that it does not > specify how audio and video would be synchronized, since there are no > absolute time stamps for the video frames. So it is difficult to account > for > audio latency on different systems, much like when you play an AVI file. > Ideally it would be wonderful to have timestamps that could be used

> There are a usually lot more data packets than header packets, so > having an internal length there hurts your bitrate a lot more. Of > course, it may not be significant for an uncompressed text codec. If muxed with a video, it's insignificant (well, for my test cases). > With codecs using the 'count of decodable samples' rule to calculate > their granulepos, the

Hi, I have modified fenice(streaming server) and mplayer(media client) code to support for ogg container(vorbis+theora). Now I have to implement forward and rewind of an ogg(vorbis+theora)file by time. So I would like to do file seek to start reading the file from that position. Eg:- mplayer will send +10 secs to forward request to fenice through RTSP and fenice should read and send packets from

Hi, I have modified fenice(streaming server) and mplayer(media client) code to support for ogg container(vorbis+theora). Now I have to implement forward and rewind of an ogg(vorbis+theora)file by time. So I would like to do file seek to start reading the file from that position. Eg:- mplayer will send +10 secs to forward request to fenice through RTSP and fenice should read and send packets from