similar to: Building theora 1.1.1 with mingw-w64-gcc 7.1 and msys

Hi people, I fixed the problem by renaming the function and every instance of 'rint' to 'rint_az' (Round Int Away from Zero) and then encoder_example.c built successfully. Don't know if this needs to be patched upstream or not. Edgar On 6/1/2017 2:53 PM, Edgar Reynaldo wrote: > Hello, > > I recently attempted to build theora 1.1.1 with mingw-w64-gcc 7.1 and

I am coding with vorbis using mingw32 (g++ for win32 without the cygwin.dll dependency). mingw32's math library does not support rint and I can't find a replacement so I have tried the following: Use Cygwin to execute ./configure. Then: (1) "make" with Cygwin - ok. Cygwin supports rint. I encode my Aerosmith's "Get A Grip" .wav from the CD to .ogg with

Hi, I'm a highschool student, I'm looking for information about converting Wave file (*.wav) into Ogg file (*.ogg) and i found encoder_example.c inside libvorbis's example directory. I try to compile it using Microsoft Visual C++ 6.0 ,but it goes error like this : --------------------Configuration: encoder_example - Win32 Debug-------------------- Linking... encoder_example.obj :

Hi all. I'm Mat & I'm new :) I'm testing libtheora + libogg perhaps for a commercial product. I started watching encoder_example.c ... I simplified it for testing it easier. It seems ok to me but I have no experience with theora so I would like to know if my code is correct. I tried to debug it with Valgrind and I found 4 possible memory leaks... but I think they can be

Hi, I'm switching from the mainstream theora trunk to the exp one and I encounter a problem with the encoder. Every video I encode are played like a 'mosaic', I do not know how to say that. The picture is just a bunch of coloured pixels. During the encoding process the video stream is defined like that: File stream.yuv is 320x240 15.00 fps 420 video. Why 420 ? Why not YUV like for

Hello, I believe llvm.rint description in LangRef is not quite complete. Llvm seems to map math.h:rint() call to llvm.rint intrinsic, and the LangRef says that the result of llvm.rint matches the result of libm rint() call. Next, LangRef states that llvm.rint "returns the operand rounded to the nearest integer." Shouldn't the specification also say that "the actual rounding

Hi Cameron, Thank you for the comments, but I am confused even more now ☺ > llvm.rint won't honor the FPEnv in all cases. It falls under the default FPEnv The default FPEnv section specifies round-to-nearest rounding mode. In this case, how is it correct to map rint() user call to llvm.rint intrinsic call? If this is just a temporary inconsistency, and the long term solution is to map

As was briefly discussed on IRC, ffmpeg and mplayer currently output two somewhat incompatible YUV4MPEG streams. This meant that encoder_example could take input from mplayer, but not ffmpeg or movtoy4m (a QuickTime->Y4M tool). This is a patch that fixes this issue and should allow encoder_example to take input from either format: diff -urd xiph-cvs/theora/examples/encoder_example.c

Dear Friends. I found something very puzzling with constOptim(). When I change the parameters for ConstrOptim, the error messages do not seem to be consistent with each other: > constrOptim(c(0.5,0.3,0.5), f=fit.error, gr=fit.error.grr, ui=ui,ci=ci) Error in constrOptim(c(0.5, 0.3, 0.5), f = fit.error, gr = fit.error.grr, : initial value not feasible > constrOptim(c(0.5,0.9,0.5),

----- Original Message ----- > > On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter < > schnetter at cct.lsu.edu > wrote: > > > > > > > On Fri, Jun 21, 2013 at 7:54 AM, David Tweed < david.tweed at arm.com > > wrote: > > > > > > > | LLVM does not currently have special lowering handling for round(), > | and >

On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter <schnetter at cct.lsu.edu>wrote: > On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com> wrote: > >> | LLVM does not currently have special lowering handling for round(), and >> I'll propose a patch to add that, but the larger question is this: should >> fast-math change the tie-breaking

I have encoded successfully a YUV stream by using the encoder_example. Can We encode a row stream (get from a web cam) by using encoder_example. If we can not, is there any other way to encode a row stream by using theora codec. -- Nuwan Millawitiya -------------- next part -------------- An HTML attachment was scrubbed... URL:

I have encoded successfully a YUV stream by using the encoder_example. Can We encode a row stream (get from a web cam) by using encoder_example. If we can not, is there any other way to encode a row stream by using theora codec. -- Nuwan Millawitiya -------------- next part -------------- An HTML attachment was scrubbed... URL:

> > The only issue I see is that since we also assume FP operations have no > side effects by default there is no difference between llvm.rint and > llvm.nearbyint. I wouldn’t have a problem with dropping llvm.rint > completely. The forthcoming C standard ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf, 7.12.9.8) defines new function, `roundeven`, which implements

Hi all I have the raw out put of a video camera in following format: mjpegb, yuvj422p, 1920x1080, 24.00 fps(r). I cannot directly convert this raw footage to Theora due to the YUV4MPEG2 only restriction of the encoder_example. Isn't it better to support other raw formats in encoder_example, such as what I have, mjpegb, yuvj422p? I presume even if I convert the mjpegb, yuvj422p to

> > One concern with replacing llvm.rint and llvm.nearbyint with > llvm.roundeven makes it difficult to turn back into a libcall if the > backend doesn't have an instruction for it. You can't just call the > roundeven library function since that wouldn't exist in older libm > implementations. So ideally you would know which function was originally > used in the

On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com> wrote: > | LLVM does not currently have special lowering handling for round(), and > I'll propose a patch to add that, but the larger question is this: should > fast-math change the tie-breaking behavior of > | rint/nearbyint/round, etc. and, if so, should we make a specific effort > to > have all

Some clarification after getting feedback from Craig Topper…. It’s probably best to say in the documentation that the llvm.nearbyint and llvm.rint functions “assume the default rounding mode, roundToNearest”. This will allow the optimizer to transform them as if they were rounding to nearest without requiring backends to use an encoding that enforces roundToNearest as the rounding mode for these

(Theora/Vorbis) available. Message-ID: <410011E4.2040904@hut.fi> Hello, I noticed that it's quite difficult currently to create Ogg format files (Ogg Theora for video and Ogg Vorbis for audio). There's only the encoder_example-program, which is included in the libtheora source packages, but seemingly not in any libtheora/libtheora-devel packages that are around the web for e.g.

Hello. I'm trying to encode an Ogg Theora file from an unencrypted dvd using mplayer and encoder_example. I set up named pipes stream.wav and stream.yuv. I then run: mplayer -ao pcm -aofile stream.wav -vo null /dev/dvd & mplayer -vo yuv4mpeg -ao null -nosound /dev/dvd & encoder_example -v1 -a 1 stream.wav stream.yuv > lec1.ogg but I get the following error: File stream.wav is