similar to: liboggflac bug (flac.exe) : wrong header field

--- illiminable <ogg@illiminable.com> wrote: > Just playing around with my new flac code, and did some tests with > stuff > from the reference tools, and i noticed that one of the fields in the > first > header is wrong. (The number of headers field is 1 less than it > should be) > > The spec doc says... > > " A two-byte, big-endian binary number

After trying to find out what to do when no packets complete on a page... i reread the ogg spec and found this... "A special value of -1 (in two's complement) indicates that no packets finish on this page." So i searched through a few files and it appears that the muxer doesn't do this... has this been depracated ? In all cases i can find that this happens the page has the same

I've got a few theora vids here... and looking at the headers it seems to me they say they play at 2 frames per second... but watching them they appear to to play at a faster rate. Theres also some that say they lpay at 1 fps. Am i missing something here ? I'm getting the info from here.... http://wiki.xiph.org/TheoraSpec Is this header structure still valid ? Heres a dump of the BOS

I have a few more questions about theora... if someone could answer or point me to a source of the information... Firstly in the header there is width and height parameters. Are these fixed for the entire file ? Is it possible for say halfway through the dimensions of the video to be changed ie two different size videos are spliced together ? If it is... does the header represent the first

After a few other attempts at hacks to determine start times of pages, the only other option left is to partially decode the packets in the demuxer in order to give correct start time stamps after a seek. Someone mentioned it was relatively easy to do without a full decode. I've had a bit of a search in the mailing lists and on the web and can't find any details about it. What i need is

Since we've been debating the merits of start or end timestamping... i'm curious why the page doesn't have both stamps ? That would solve the problems for all parties wouldn't it ? It's not like the overhead is huge... less than 0.1%... so on the average audio file thats 5 megs.... it's a 5k increase, which pretty much insignificant. Even on a 1gig video file it's

I'm interested to know of any player, which can properly resync after receiving a theora+vorbis stream that has been cut somewhere in the middle... ie it doesn't start at granule 0. The problem being... when streams are cut in this way, the start time, and the times of the first few packets in each stream are unknown. When working at a packet level... the first few packets will arrive

Listening to the meeting on granule pos tonight/today it became clear that the issues everyone is concerned with for the most part don't affect my implementations and the issues i have pretty much don't affect anyone else... and in the cases where they overlap, the reasoning seems to be different. And since everyone else has had a lot more time to consider all these issues and i'm

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 14/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > Ralph wrote: > > Conrad, does this work for the other codecs as well? I vaguely > > remember libvorbis putting -1 on the header packets instead of 0. > > AFAIK, it's 0, -1 being for partial pages, from the ogg docs. -1 (or, I > suppose all negative values, but I'm not sure) mean

dear list, i am trying to write a small program which reads an ogg file and writes it to another ogg file (and changes serial number, granulepos etc on the fly). reading the ogg file is ok (ogg_sync_pageout, ogg_stream_pagein, ogg_stream_packetout). but writing the file doesn't work - the granulepos and page structures don't match with the original file. here's what i am doing.

Originally, the test is on a tiger with RHEL installed. The fs is ext3 as default. Then the oops came up. I've installed the test kernel on another tiger with Suse, reiserfs as default. The kernel can boot successfully without any trouble. Is it a known issue? Or what causes this happen? thanks, -zhen -----Original Message----- From: Wang, Zhenyu Z Sent: 2004?7?20? 16:59 To: linux-ia64 at

> I just had another play with it... and i'm seeing similar jumpiness. > <snip> Bandwidth should be OK, the servers are hosted in fast data centers... so must be one of the other points. > 1) There are data packets in the same pages as header packets. <snip> Fixed.. Thanks > 2) Pages consisting only of header packets must have granule pos zero. Fixed (I think -

Hi, I've now got another way of encoding granule (oh, not *again*, I hear you cry). I believe it's an improvement over the existing "generic" method, so I'll outline it here for your consideration. Again, it's different from what Skeleton can handle, but it's a simple superset and would be easy to add to Skeleton (and liboggz). It is also compatible with other

Hi, do you still think you need all this, if you are allowed to have equal granulepos on subsequent pages? Conrad. On 18/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > Hi, > > I've now got another way of encoding granule (oh, not *again*, I hear > you cry). I believe it's an improvement over the existing "generic" > method, so

Hi all, I've just grabbed a copy of SVN head for libogg and 'make check' is failing: ./test_framing testing single page encoding... 0, (0), granule:0 ok. testing basic page encoding... 0, (0), granule:0 1, (1), granule:6151 ok. testing basic nil packets... 0, (0), granule:0 1, (1), granule:10247 ok. testing initial-packet lacing > 4k... 0, (0), granule:0

Hi all, just letting you know that I am about to submit the final version of the Ogg 1.0 file format Internet-Draft to the IETF. It is due by today (March 3, Monday - Internet Draft final submission cut-off at 09:00 ET) for the next IETF meeting and I expect they will promote it to RFC status at the meeting. Please send any last-minute changes to me. Cheers, Silvia. <p><p>

Hi all, just letting you know that I am about to submit the final version of the Ogg 1.0 file format Internet-Draft to the IETF. It is due by today (March 3, Monday - Internet Draft final submission cut-off at 09:00 ET) for the next IETF meeting and I expect they will promote it to RFC status at the meeting. Please send any last-minute changes to me. Cheers, Silvia. <p><p>

At my company we have a bunch of music in FLAC format. We want to play it using the Windows Media Player, but none of us can get the illiminable DS filters to work. Here are some details. Illiminable DS filters http://www.wmplugins.com/ItemDetail.aspx?ItemID=681 http://www.illiminable.com/ogg/ We are using the latest build available on this website, and I have read all the known issues. My

I've got my encoder working now... and i put a proeprty page interface to allow the user to set a few encoding paramters to start off with... but changing the paramters doesn't seem to make barely any difference... These are the defaults i'm using... mTheoraInfo.target_bitrate=400000; mTheoraInfo.quality=30; mTheoraInfo.dropframes_p=0; mTheoraInfo.quick_p=1;