similar to: Inverse DCT in coding stage

Hi. I am trying to find calls of idct/fdct.c functions by tracing png2theora.c calls. But found only: analyze.c:oc_dct_cost2() Where and when idct/fdct/mmxidct/mmxfdct.c functions are used? Mentions of "dct" word: ==== pacify at optima-amd64:/usr/src/libtheora-1.2.0alpha1/lib$ grep dct *.c | cut -f1 -d":" | uniq -c ???? 19 analyze.c ???? 28 decode.c ???? 22 encode.c ????? 4

Why for white-pixel image, oc_enc_fdct8x8_c() returns the matrix with non-zero AC-coefficients? _x[64]: * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 * 107 107 107 107 107 107 107 107 _y[64]: * 3426

Good day! I'm creating HDL IP CORE (for using in FPGA) for theora encoder (now only I-frames). I don't undestand one moment. Now i develop such stages: 1. From RBG(byer) to YCbCr converter 2. DCT processing (8x8 pixels blocks) 3. Quantizator of DCT coeff. 4. Zig-Zag of quantized DCT coeff. and now i have uresolved last stage of compression - how i must send 8x8 blocks to huffman

Looking for the DCT function, but don't see it in the signal pkg. http://rss.acs.unt.edu/Rdoc/library/signal/html/signal.package.html http://rss.acs.unt.edu/Rdoc/library/signal/html/00Index.html As I understand it, the 'signal' functions are ports of the corresponding matlab/octave code, where the DCT exists. Did I miss it (different name?) or is someone working on a port for

> I put debug code in a function in C, > but the function oc_enc_fdct8x8() not called. > Why? There is no function oc_enc_fdct8x8. It's a macro, which usually calls a platform-specific version via _enc->opt_vtable.fdct8x8, though on some platforms, it will call a specific version directly (e.g., oc_enc_fdct8x8_x86_64sse2 on x86-64). All of the functions with platform-specific

Dear all, I was wondering whether anyone knows about a program which converts (part of) a data definition file (such as a .dct file for stata, or .sas file for sas) into an R-script. Here is an example with a .sas file: <-- snipp VALUE HTYPE (default=32) 0 = "Not in household" 1 = "Married couple family household" 2 =

We are pleased to announce a new stable release of libtheora, the Xiph.org Foundation's reference implementation of the royalty-free Theora video format. This new release, version 1.1, codenamed Thusnelda, incorporates all of the recent encoder improvements we have been making over the past year, though some of the code had its genesis all the way back in 2003. It also brings substantial speed

We are pleased to announce a new stable release of libtheora, the Xiph.org Foundation's reference implementation of the royalty-free Theora video format. This new release, version 1.1, codenamed Thusnelda, incorporates all of the recent encoder improvements we have been making over the past year, though some of the code had its genesis all the way back in 2003. It also brings substantial speed

This has to do with your own timezone. If I run that code on my computer, both formats are correct. If I do this after Sys.setenv(TZ = "UTC") Then: > cbind(format(dlt), format(dct)) [,1] [,2] [1,] "2016-12-06 21:45:41" "2016-12-06 20:45:41" [2,] "2016-12-06 21:45:42" "2016-12-06 20:45:42" The reason for that, is that

> On 18 May 2017, at 13:47 , Joris Meys <jorismeys at gmail.com> wrote: > > Correction: Also dlt uses the default timezone, but POSIXlt is not recalculated whereas POSIXct is. Reason for that is the different way values are stored (hours, minutes, seconds as opposed to minutes from origin, as explained in my previous mail) > I would suspect that there is something more subtle

After installing R-3.4.0 I ran 'make check' which halted here: $ > tail reg-tests-1d.Rout.fail -n 16 > ## format()ing invalid hand-constructed POSIXlt objects > d <- as.POSIXlt("2016-12-06"); d$zone <- 1 > tools::assertError(format(d)) > d$zone <- NULL > stopifnot(identical(format(d),"2016-12-06")) > d$zone <- "CET" # =

After installing R-3.4.0 I ran 'make check' which halted here: $ > tail reg-tests-1d.Rout.fail -n 16 > ## format()ing invalid hand-constructed POSIXlt objects > d <- as.POSIXlt("2016-12-06"); d$zone <- 1 > tools::assertError(format(d)) > d$zone <- NULL > stopifnot(identical(format(d),"2016-12-06")) > d$zone <- "CET" # =

(Disclaimer: this is not an LPC vs. LSP question) After looking at the Vorbis code I was wondering why you were using LSP to quantize the spectral envelope instead of simply quantizing the cepstrum (DCT(log(envelope))) or modified cepstrum (DCT(envelope.^alpha)). To me it seems like when the information is already in the frequency domain, there's no need to go back to LPC. Also, I think a DCT

On Wed, 17-May-2017 at 01:21PM +0200, Peter Dalgaard wrote: |> |> Anyways, you might want to |> |> a) move the discussion to R-devel |> b) include your platform (hardware, OS) and time zone info System: Host: MTA-V1-427894 Kernel: 3.19.0-32-generic x86_64 (64 bit gcc: 4.8.2) Desktop: KDE Plasma 4.14.2 (Qt 4.8.6) Distro: Linux Mint 17.3 Rosa Machine: System:

Hi, Attached is the first version of the DCT callback. It's still a bit WIP, but now you have something to refer to when I'm rambling :) Best Regards, Thorvald -------------- next part --------------

> On 18 May 2017, at 14:58 , Martyn Plummer <plummerM at iarc.fr> wrote: > > > >> On 18 May 2017, at 14:51, peter dalgaard <pdalgd at gmail.com> wrote: >> >> >>> On 18 May 2017, at 13:47 , Joris Meys <jorismeys at gmail.com> wrote: >>> >>> Correction: Also dlt uses the default timezone, but POSIXlt is not recalculated

On Thu, 18-May-2017 at 05:46PM +0200, Martin Maechler wrote: |> ..... |> |> Being pretty "stretched" time wise currently, I'm happy for |> timezone-portable propositions to change the test. Meantime, anyone who lives where DST happpens in December who wants to get through the remaining tests can avoid this one by changing the line > stopifnot(length(fd) == 10,

Good day! I create diagram of encoder process. Using it i create implementation of encoder in FPGA (Xilinx/Altera). Please critique it. Is there missing stages? Here is blog http://developer-fpga.blogspot.com/ Here is picture of encoding stage 1 https://lh4.googleusercontent.com/-NV8o9DG3jvE/TYjYXr-dYGI/AAAAAAAAAos/U06O-YvhSI0/s1600/stage1.jpg Here is picture of encoding stage 2

When I tried LLVM for a function with an array as an argument, the type infomation of the array seems lost. For example, for this function, void DCT(short data[64], char step, char offset), its corresponding LLVM code will be void %DCT8_int(short* %data, sbyte %step, sbyte %offset) , and every access of "data" will be a pointer access, instead of an array access. Is there any way to

Hi, Keep up the good work! The file sizes of Theora's output is amazing! I have just joined the list, and would like to contribute to the