similar to: Make check failure

So if I understand the libogg development practises correctly. >> (r17098 | gmaxwell | 2010-03-29 16:35:11 +1100 (Mon, 29 Mar 2010)) Gregory Maxwell checked in a change ... >> I've just grabbed a copy of SVN head for libogg and 'make check' >> is failing: ... which broke the test suite ... > If the new function stays it will likely need a test case. I'm

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

On Mon, Apr 5, 2010 at 10:15 AM, Neil Leathers <neil.leathers at rogers.com> wrote: >> If the new function stays it will likely need a test case. I'm not >> going to write one until the decision is final that we'll go that >> route. > > ... without testing the change (to demonstrate it works, or is useful, or ... anything) ... Of course I tested the change.

Hi and thanks for your interest! this is the error, i need to add the speex folder and a path to the .h file and it works Compile thumb : opus-proj <= audio-in.c In file included from jni/../../opus-tools-0.1.7/src/audio-in.c:74:0: proj/../../opus-tools-0.1.7/src/speex_resampler.h:90:32: fatal error: speex/speex_types.h: No such file or directory compilation terminated. make: ***

I am aware of a couple CELT users running the codec across a bit-error channel where corruption takes the form of flipped bits (such as a raw wireless link) rather than a packet-loss channel (like ethernet or an IP network). CELT has been designed to work reasonably well on both kinds of channel. You can turn a bit-error channel into a packet-loss channel by including a CRC across the entire

Hi All, What would be interesting would be a plot of complexity versus subjective or object audio quality. I've not had a chance to look at the new analysis code in 1.1 so maybe in the case of a 6kbps compression you could clarify what decisions would it be making that would justify the extra complexity? Best Regards Cliff Parris -----Original Message----- From: opus-request at

Chris DiBona made an odd comment regarding Theora on the WhatWG list. I am explicitly not calling for people to go sign up over there and complain. Google has done many good things for open video, and I'm sure they will continue to do so in the future. I thought the comparison I did for my response would be interesting to other people here:

I guess I'm missing something since the following minimized test case is failing: >>> #include "ogg/ogg.h" main() { ogg_sync_state the_ogg_sync_state; ogg_sync_init(&the_ogg_sync_state); ogg_sync_destroy( &the_ogg_sync_state ); } >>> $ gcc -g -logg test.c $ ./a.out *** glibc detected *** ./a.out: munmap_chunk(): invalid pointer:

I tracked down the bug to an incorrect use of restrict. I would not consider this a compiler bug: we are lying to the optimizer by telling it that a pointer is restrict when in fact it isn't. This can be fixed like so: diff --git a/celt/mdct.c b/celt/mdct.c index 1634e8e..fa5098c 100644 --- a/celt/mdct.c +++ b/celt/mdct.c @@ -276,8 +276,8 @@ void clt_mdct_backward(const mdct_lookup *l,

I have to admit that I am impressed by your results -- making 1.1 look slower than 1.0 is by no means an easy task. On the other hand, it's a great tutorial on how not to use Opus, so for the benefit of everyone, this is a summary of what we learned in this exercise: 1) When running on ARM, the fixed-point build is usually faster than floating point. This is true on the majority of ARM archs

I have run a few more test at different bitrates and 1.1 is looking even worse in terms of speed compared to previous versions. I have shared a google sheet which has the raw data and charts for 6,16 and 32 kbps. Unfortunately you cannot show proper error bars on Google sheets but the standard deviation is in the data if you want to look. You can see that the profile for 1.1 is a lot different

Hi all, I am the developer of the llcon software (llcon.sf.net) which is a software making it possible for musicians to play in real-time over the internet. Up to now I have used ADPCM or no audio coding. Gregory Maxwell was pointing me to the great CELT project. Using CELT has the advantage to be able to use higher sample rates, getting lower code rate and better error concealment. I have

Thanks for your help, I will follow that, so in order to sum up I need: - libopus 1.0.3 compiled as static or shared library - libogg 1.3.1 compiled as static or shared library - opus-tools 0.1.7 and then follow the example in opus-tools opusenc.c to get things ready, because if I try to compile opus-tools, this ask for me for the speex library, and other things I think that that will we all.

I am looking for a theora media server something like the PHP based Flash Media Server ( http://metavid.org/w/index.php/Mv_embed#PHP_based_Flash_Media_Server ) tom_a_sparks __________________________________________________________________________________ Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7. Enter now: http://au.docs.yahoo.com/homepageset/

After a few experiments, I found that both alternatives are very similar, and 2~5% slower compared to the following: diff --git a/celt/mdct.c b/celt/mdct.c index 1634e8e..e490c3b 100644 --- a/celt/mdct.c +++ b/celt/mdct.c @@ -277,7 +277,7 @@ void clt_mdct_backward(const mdct_lookup *l, kiss_fft_scalar *in, kiss_fft_scala it in-place. */ { kiss_fft_scalar * OPUS_RESTRICT yp0 =

On 1/14/17, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Ozkan Sezer wrote: > >> > Ozkan Sezer wrote: >> > >> >> unsigned int and FLAC__uint32 are used interchangeably, leading to >> >> warnings with platforms (e.g. djgpp) where int32_t is long: >> > >> > Is `sizeof int == 4` though? >> >> Yes, obviously

Cliff, Yes it would be good, but very hard to get a figure for the quality. At 6kbps I assume it does not bother trying to figure what mode to use as at that rate it can only use SILK. When I run some other bitrates it may get a bit slower trying to decide whether it is voice or music. I started with low bit rate because I am only really interested in Voice and very low bit rate. I think there

I wanted to roughly benchmark how the different version of libopus performed at each complexity level for a 6kbit/s output opus file. This was conducted on a Raspberry Pi so it is a constant hardware platform. This was done on an early Pi so only 256MB RAM but it was never used up so should not make a difference. I compiled the three final versions of each major release of libopus so that was

Wow. Let me say that again, just in case you missed it. Wow. The quality looks to be on par with what I get out of H.264, but Theora has the added benefit of free and open source software with no patent worries so I can use it with a clean conscience. Thanks, everyone.

It's been brought to my attention that Mozilla will be changing their implementation of <video/> to default deny cross-site requests. (http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104) In other words: <video src="http://someothersite/videos.ogg"/> Will not work by default. It will not work like the <img/> tag does, or like the embed/object tags do which are