search for: alphathinktink

On Wed, Jun 4, 2014 at 4:31 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Alpha Thinktink wrote: >> max_data_bytes=-11 > > That value is passed in by you. I also don't think passing such a value > would have worked in earlier releases. It indicates the size of the > buffer you are passing to the encoder to receive the encoded output. Actually, I'm

On Wed, Jun 4, 2014 at 4:41 PM, Alpha Thinktink <alphathinktink at gmail.com> wrote: > > >> max_data_bytes=-11 > This can happen with multistream cbr if the bitrate is set too low, to a value that would allow less than 4 bytes per stream, per packet. What bitrate are you using? Perhaps you set it to a value in kb/s instead of b/s. ---------...

I've developed the unofficial Opus codec support plugin for Winamp and I have been able to keep the libopusfile libraries inside a folder inside the application's install path - "%PROGRAMFILES%\WinampNarf\opusfile" - and all seemed to be fine and dandy. However, if I try to load the new libopusurl-0.dll from the same folder as I have always done as with the other libraries, I

Is it possible to get the HTTP server headers for URL streams opened with op_open_url, op_vopen_url? If not, is there an alternative that I can use get get the headers? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20130821/08162909/attachment.htm

oops: /**Use the given user name for authentication when proxying connections. > All proxy parameters are ignored for non-http and non-https URLs. > \param _user const char *: The proxy server user name. > This may be <code>NULL</code> to disable > proxy > authentication. >

Does somebody have, or is aware of, a server somewhere that is hosted on an internationalized domain name? I need a server to bang on for a little bit to test the implementation of Nameprep and Punycode encoding. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20130923/403d7697/attachment.htm

I just recently found that opus_multistream_encode_float is returning -1 (OPUS_BAD_ARG) with the libopus 1.1 build but works just fine with the libopus 1.0.1 and libopus 1.1-beta builds. I tried using opus_multistream_encoder_create and opus_multistream_surround_encoder_create. Tried with coupled and uncoupled quadraphonic and uncoupled stereo encodes. I'm dynamically loading the libopus

Finally got it to compile and attach the MSVC debugger. It fails at the following: if ((!st->variable_duration && 400*frame_size != st->Fs && 200*frame_size != st->Fs && 100*frame_size != st->Fs && 50*frame_size != st->Fs && 25*frame_size != st->Fs && 50*frame_size != 3*st->Fs) || (400*frame_size <

In debugging I saw: opus_multistream_encoder.c line 760 if(!vbr) max_data_bytes = IMIN(max_data_bytes, 3*st->bitrate_bps/(3*8*Fs/frame_size)); max_data_bytes after this code becomes -2 where as before it was 10200. I suspect it was because st->bitrate_bps was set to -1000 to indicate Auto bitrate. I imagine Max bitrate (-1) has a slightly similar effect. then in the same c file

Would it be possible to include a re-export of the malloc, calloc, realloc, and free being used by opus file's implementation of OpusTags handling? This might seem redundant or ridiculous but I'm having difficulty getting the right versions that my compiler allows that's compatible with libopusfile. In the debugger I can see that the memory location that my malloc is returning is

> Have you tried compiling it yourself? I just installed git for the first time and downloaded all of the latest source code packages directly from the site. I'm getting the following every time I try to (re)build any of the projects: 1>------ Build started: Project: opus, Configuration: Release Win32 ------ 1> fatal: Not a git repository: 'C:\My

> > This is as expected. The build system is trying to get a git revision > string out of the source tree to compile in for reference. If you're > building from a downloaded source .zip, there won't be any git > information available and it will fall back to the hard-coded release > string. That's why the error isn't fatal to the build. Ok, this seems