similar to: further debugging of my ogg/theora decoder

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

Hello, I'm just totally confused. In my theora streams encoded using ffmpeg2theora (but also when using my own encoder) I have packets with a granulepos of -1 so I can't identify the packet during a seeking operation correctly. I can also see those strange value when I just print the packet granulepos before sending it to the Theora decoder. I know why there are PAGES with granularpos of

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/

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

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

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

I am trying to figure out how theora timestamps map to absolute time values. This information would be needed to seek by 1 sec, 5 secs etc. I understand the granulepos is interpreted as Absolute number of key frames so far | number of frames since last key frame. E.g. 1000|1, 1000|2, ... How does this map to absolute time in millisecs since the start, I can think of the following formula: Total

> 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

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

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

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

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

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

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 just committed an image flip for compatibility with VP3 lossless transcode. Thanks to mau and derf for verifying that this was needed. It's a little hacky on the decode side; suggestions for improvement are welcome. Since this is a bitstream change, and we're still a ways from having a complete spec (which is the gating item for beta 1 and the bitstream freeze) we're

Oggz 0.9.8 Release ------------------ Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip, oggz-chop, oggz-comment, oggz-scan, oggz-sort and oggz-validate. oggz-chop can be used to serve time ranges of Ogg media over HTTP by any web server that supports CGI. liboggz is a C library providing a simple programming interface for reading and writing Ogg

Oggz 0.9.8 Release ------------------ Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip, oggz-chop, oggz-comment, oggz-scan, oggz-sort and oggz-validate. oggz-chop can be used to serve time ranges of Ogg media over HTTP by any web server that supports CGI. liboggz is a C library providing a simple programming interface for reading and writing Ogg

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

I have almost finished integration of Theora into our videoconferencing program. Since a videoconferencing program is realtime, it is UDP-based and wraps the Theora stream in RTP (More on that later). The problem here is that most examples I could find, wraps the theora stream in ogg, and used over tcp or files. I send over UDP and clients need to be able to start in the middle of the stream.