similar to: Make check failure

Erik de Castro Lopo wrote: >> I've just grabbed a copy of SVN head for libogg and 'make check' >> is failing: >The breakage happened in this commit: > > r17098 | gmaxwell | 2010-03-29 16:35:11 +1100 (Mon, 29 Mar 2010) | 1 line > Firstly, is gmaxwell on this list? [snip] > Secondly should be be trying controvertial changes in HEAD? Surely thats > what

On Tue, Aug 12, 2008 at 5:46 AM, ogg.k.ogg.k wrote: > This could be something to add to Skeleton. Kate (and probably CMML) > needs the one-packet-per-page thing also, and any discontinuous codec > probably needs it as well (well, not *need*, but no good buffering without > it). It's trivial for a muxer to do, and it's transparent to a demuxer. That's a good idea. Any

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>

Howdy, yeah, I've finally collected all your feedback on my I-D on the Ogg encapsulation format, many thanks to all of you! Below, I've listed the changes that I have made to the previous version and the attachment contains the complete new I-D. If there are any more change requests, please send me wording proposals as it's easier to include. :) Monty, in case you are doing any

Howdy, yeah, I've finally collected all your feedback on my I-D on the Ogg encapsulation format, many thanks to all of you! Below, I've listed the changes that I have made to the previous version and the attachment contains the complete new I-D. If there are any more change requests, please send me wording proposals as it's easier to include. :) Monty, in case you are doing any

Hello Tim I am referring to the following file https://en.wikipedia.org/wiki/File:Sample_of_%22Another_Day_in_Paradise%22.ogg I opened the file in a HEX editor. I do not see the string OpusHead in the packet. It starts with Oggs. Also checking the occurrence of Oggs, I see that the first packet has BOS, the next all (except last) have 00 (which is not defined in the RFC as continuation) and

Hi all, Here are some thoughts on Vorbis framing, which may make it easier to stream Vorbis in real time. The suggested changes also move more audio data closer to the beginning of each page. A note in the Vorbis framing spec suggests a simple 'bandwidth limited' mode whereby important information is placed at the front of each page and the end of each page is discarded. When operating

Xiph.Org is pleased to announce a full release of libogg 1.2.1 and libvorbis 1.3.2. This is not a coordinated release, it was merely convenient to do a release cycle for both at the same time. Changes and fixes in the new libogg release include: * Various build updates (see SVN) * Add ogg_stream_pageout_fill() to API to allow applications greater explicit flexibility in page sizing. *

Xiph.Org is pleased to announce a full release of libogg 1.2.1 and libvorbis 1.3.2. This is not a coordinated release, it was merely convenient to do a release cycle for both at the same time. Changes and fixes in the new libogg release include: * Various build updates (see SVN) * Add ogg_stream_pageout_fill() to API to allow applications greater explicit flexibility in page sizing. *

Xiph.Org is pleased to announce a full release of libogg 1.2.1 and libvorbis 1.3.2. This is not a coordinated release, it was merely convenient to do a release cycle for both at the same time. Changes and fixes in the new libogg release include: * Various build updates (see SVN) * Add ogg_stream_pageout_fill() to API to allow applications greater explicit flexibility in page sizing. *

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I thought I would separate this out into a separate mail since it's not comment specific stuff -- There seem to be a couple of inconcistanies in the Ogg spec as regards to lacing values: *) "The raw packet is logicaly divided into [n] 255 byte segments and a last fractional segment of < 255 bytes." However, in the wild, I've

On Wed, Aug 13, 2008 at 3:05 AM, ogg.k.ogg.k at googlemail.com wrote: > And that's the canonical way AFAIK. Comparing times computed from > the granpos you get from pages you get from a bsearch requires good > knowledge of the codec, whereas comparing granpos can seek within > any codec. No. it's in general impossible to calculate the granulepos that corresponds to a

I downloaded current version of FLAC sources and compiled it with: * GCC 4.8.1 (MSYS from http://xhmikosr.1f0.de/tools/) * Intel C++ Composer XE 2013 update 5 * MSVS 2010 SP1 * MSVS 2012 update 3 (SSSE3 and SSE4.1 code was disabled for all compilers) Stereo 24-bit WAV file was encoded with -8 preset. Encoding time, in seconds: GCC 32-bit: 209 ICC 32-bit: 130 VS10 32-bit: 116 VS12 32-bit: 114

Someone could tell me the question about the question about lacing values values of segments. I mean i know what happens about segmentation but reading ogg specs i didn't understand this lines: "We simply add the lacing values for the total size; the last lacing value for a packet is always the value that is less than 255. Note that this encoding both avoids imposing a maximum packet

I noticed that, when decoding an ogg vorbis file that was encoded with the xiph library, that the comment header and setup header are encoded on one page. Okay, the vorbis documentation says you can do this, no problem. My question is, the lacing values seem to indicate where the packet boundaries for the two of these are, is this required, or is this just a hint? Further, I'm seeing

Hi, I'm currently trying to implement the Ogg specification in pure Java from scratch. (I know, something like that does exist, but that's a rewrite from C, at least that's my impression). I'm a bit confused with the number of lacing values/segments in a page, and the maximum length a page can have. The specification says, that there can be 255 segments in a page, 255 bytes each

>Searching for 'vorbis' to find the packet boundary is wrong however. >The lacing values in the Ogg page header tells you exactly where the >division is. OK, so given the fact that a page can also contain multiple packets this means that the lacing values of one page could be like the following example: 255 255 189 (something less than 255, indicating that a new packet starts

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