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/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Thursday, June 12, 2003, at 03:28 am, Dan Miller wrote:> 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.Yes that's fine. There wouldn't be any point to having pages if they weren't different from packets, and as you suggest, it's necessary to keep the overhead down.> If I shove a few frames into a page, how does this affect the > granulepos stuff?It's actually pages that have granulepos. The granulepos in the packet structure is just how they're passed to the ogg layer. Granulepos is 'the total samples encoded after including all packets finished on this page', so libogg sets the page granulepos to the greatest granulepos of the packets that ended on that page. Help? -r --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
right, my issue is that we're using granulepos somewhat stragely right now with certain bits indicating keyframes, etc. That scheme seems to break under the scenario of >1 frame/page. I'm concerned about this as we're about to release a supposedly stable bitstream, and ffmpeg & mplayer are already supporting the format with more to come hopefully. <p>-----Original Message----- From: Mauricio Piacentini [mailto:mauricio@tabuleiro.com] Sent: Thu 6/12/2003 10:49 AM To: theora-dev@xiph.org Cc: Subject: Re: [theora-dev] question about ogg mapping And how would you get the absolute time for each frame in this scenario (multiple packets per page?) This is absolutely necessary for a player to operate correctly. Or is there anything I am missing, like a way to get the absolute position from the packet data and not the page granulepos? regards, Mauricio> Yes that's fine. There wouldn't be any point to having pages if they > weren't different from packets, and as you suggest, it's necessary to > keep the overhead down. > > > If I shove a few frames into a page, how does this affect the > > granulepos stuff? > > It's actually pages that have granulepos. The granulepos in the packet > structure is just how they're passed to the ogg layer. Granulepos is > 'the total samples encoded after including all packets finished on this > page', so libogg sets the page granulepos to the greatest granulepos of > the packets that ended on that page. >--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered. <p><p><p> -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3428 bytes Desc: winmail.dat Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20030612/69cb9e81/winmail-0001.bin
> On Thursday, June 12, 2003, at 10:43 am, Ralph Giles wrote: > > > as you suggest, it's necessary to keep the overhead down. > > Sorry, I wasn't thinking clearly.yes you were. 27 bytes = 216 bits * 30 frames/sec = 6,480 bits per second overhead, no matter how low the datarate is. 6.5 kbits is way too high for low-datarate apps. It needs to be on the order of < 1000 bits. ___ Dan Miller (++,) Founder, On2 Technologies --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> From: Mauricio Piacentini [mailto:mauricio@tabuleiro.com]> Answering my own question: by walking through the code I can > see that each > packet has its own granulepos, so it should not be a big > issue , providedIncorrect -- each *page* has a granulepos. The data packet itself starts with a zero (one == header packet), then there's a 'predicted' bit (0=keyframe), etc -- no granulepos at all, that's an Ogg thing. It occurs to me that as it stands, there is actually no way to even get to the second frame in a page without parsing through the whole first frame and so on. There isn't even a bytecount or anything to skip frames -- that info is buried deep within the bitstream structure. <p>> those are being set correctly. Not sure however if there are> implications > for seeking, we have to try and see what happens. I suspect > we can simply > stuff more packets in a page, up to the optimal 4-8k number. > > Regards, > Mauricio >___ Dan Miller (++,) Founder, On2 Technologies --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
The problem is this: right now, with each frame in its own page, granulepos can be used to guess whether the frame is a keyframe. If we put multiple frame packets in a page, there is presently no mechanism to find the first keyframe in that page to start playing from. We could impose the following limitation, which would work in most scenarios: if a page contains multiple frames, and there are any keyframes within that page, then the first frame in the page must be a keyframe (and granulepos will reflect this, calling the whole page a 'keyframe'). What's bothering me I guess is that we're imposing ad-hoc rules about the theora/Ogg mapping. These sorts of things should really be codec independent. I guess once we try to oggify another video codec, we'll see where these independent properties are and bring them out of anything Theora-specifc. Perhaps there needs to be a 'video codec mapping' document that is independent of the Theora spec. <p> ___ Dan Miller (++,) Founder, On2 Technologies <p>> -----Original Message-----> From: Ralph Giles [mailto:giles@xiph.org] > Sent: Thursday, June 12, 2003 11:45 AM > To: theora-dev@xiph.org > Subject: Re: [theora-dev] question about ogg mapping > > > On Thursday, June 12, 2003, at 04:34 pm, Dan Miller wrote: > > > right, my issue is that we're using granulepos somewhat > stragely right > > now with certain bits indicating keyframes, etc. That > scheme seems to > > break under the scenario of >1 frame/page. > > Broken in the sense that it's more complicated than you thought? This > is was always the plan. > > If your compressed data is fixed bitrate, seeking is easy. You just > multiply the desired time by the rate, seek to that offset in > the file, > and start decoding again. Unfortunately, fixed bitrate codecs are > inefficient, which is why codecs like vorbis and theora are variable > bitrate. > > With variable bitrate data you don't know a priori where in > the stream > a given playback time will be, so you basically have to jump a bit, > start decoding, see where you are, and them jump some more. In the > naive sense, that's fairly expensive, so people do things to try and > speed it up. > > I believe quicktime adds a seek table after the file is > encoded, giving > offsets for various times you pick the closest one, and then hunt > around if you need more accuracy. Another approach is to add > timestamps > as the stream is generated. Ogg uses this method because it > simplifies > working with live streams. > > So the stream is chopped up into pages, each of which has a > header with > a 'granulepos' field that acts as a timestamp. To seek you > guess, jump > to a likely point in the stream, search for the beginning on an ogg > page, read out the granulepos, and then you know where you are. > Applying this information to the next guess lets you do a binary > search, which is about as efficient as it gets. For rough > seeking, just > take a granulepos near the requested time. For more accurate seeking, > start decoding the page after the one with the greatest > granulepos less > than the seek time, and only start playback when you reach the > requested time. This scheme works for sample-accurate seeking in > vorbis, see vorbisfile.c for an example implementation. > > Everything so far work applies to vorbis as well as theora. > There is an > added complication with video however. Once the decoder is > initialized > with the header packets, the vorbis decoder can playback starting at > any packet in the stream. In contrast, theora has a concept of > keyframes, which stand on their own and are distinct from the > majority > of frames, which only encode the difference to the previous keyframe. > Thus while our seeking scheme would get you to the right place, it > wouldn't decode correctly unless the frame happened to be a keyframe. > Thus you either have to skip ahead to the next keyframe, skip > *backwards* to the previous, or generate incorrect output for a while. > > To get around this, monty added the 'granulepos hack' where > instead of > being the literal frame number, the granulepos is divided into two > parts recording the number of keyframes and the offset from the last > keyframe. So you just need to look for the point where that > offset goes > through zero and start decoding there. This also preserves the Ogg > feature of not having to peek inside the data packets to do perfect > seeking; everything can be done at the page level. > > I guess that was kind of long, but that's my understanding of how > seeking works. And I don't see anything wrong with it, or a > better way > that fits with the design goals we have. > > -r > > --- >8 ---- > List archives: http://www.xiph.org/archives/ > Ogg project homepage: http://www.xiph.org/ogg/ > To unsubscribe from this list, send a message to > 'theora-dev-request@xiph.org' > containing only the word 'unsubscribe' in the body. No > subject is needed. > Unsubscribe messages sent to the list will be ignored/filtered. >--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'theora-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.