I need to use the encoder H264 but the problem is that encoder does not accept except a list of MFVideoFormat.
MFVideoFormat_I420
MFVideoFormat_IYUV
MFVideoFormat_NV12
MFVideoFormat_YUY2
MFVideoFormat_YV12
The problem is that the samples from my camera are RGB24 what shall I do?
You have (at least) two options:
Transform (by yourself) your RGB24 samples (bitmaps) into NV12 (or other) samples before you pass them to the encoder. It is not that hard. There are examples: https://www.google.bg/search?q=RGB+to+NV12
You can create an instance of Color Converter DSP (https://msdn.microsoft.com/en-us/library/windows/desktop/ff819079%28v=vs.85%29.aspx) and configure it's input to receive RGB24 samples and it's output to desired color space. Then you call ProcessInput() and ProcessOutput() to transform.
Related
I want to change PCM(1k sine wave) volume by multiply a fraction between 0~1, such as:
char singlebuffer[1764];
qreal ProcessedVolume=0.5;
for (j=0;j<1764;j++)
singlebuffer[j]=singlebuffer[j]*(ProcessedVolume);
The result audio is very strange when ProceededVolume not "1". The strange audio sounds like 1K sine mix with other "ring noise" or mix with other "metal kicking noise". However, when I use oscilloscope to monitor the output audio, it still perfect 1K, only minimize volume level. I also check FFT spectrum, still only has 1K signal. However it sounds very different from original 1K audio.
Why ? Something wrong with my ear or I cannot simply multiply a fraction to original raw PCM data ?
Appreciate for any suggestions~
I am trying to understand the image1d_buffer_t type in OpenCL. From what I can tell, it is an 1D image made from a Buffer. The advantage over an image not made from a buffer it that the buffer image can usually be much larger (it does depend on the hardware, but the min size per this page is larger). Am I correct that you cannot use the linear interpolation of a sampler however? I am looking here.
So why even use the image rather than just a buffer?
Yes, you are correct that you can only use the sampler-less read functions with the image1d_buffer_t type, and therefore cannot make use of linear interpolation or the edge-handling features.
It's a minor convenience, but when using the image read/write functions you have the ability to change the data-type used to store the pixel values without having to change your kernel code. Similarly, you have the (sampler-less) read_imagef function, which will normalise the pixel value for you (and the corresponding write_imagef function).
I am working on some code to record audio using the ALSA API. I configure, then capture, then write captured samples out to a wav file. I configure ALSA for S32_LE, signed 32 bit samples. The data I am capturing has the 1st byte of every 4-byte sample equal to 0x00, so it appears that my hardware is effectively only capturing 24 bits samples. This is reasonable to me for numerous reasons.
However, when I play back the wav file, the sound is distorted. The audio is there, I can tell the samples are mostly correct, but the capture is very distorted, so something is wrong.
When I use arecord using the same configuration I used for my code, the recording is perfect, no distortion. So I know the hardware is good (and my code is bad).
This is what I do not understand. When I compare the wav files, that is, the wav file my code generated and the wav file arecord generated, the wav file headers are exactly the same (except for the chunk length values of course). So my wav file generation appears correct.
However, the sample data in the arecord capture does NOT have a 0x00 in each sample word like my code captures. It appears that arecord is indeed capturing 32 bit samples from my sound card. But when my code uses the same configuration for 32 bit samples, every sample has the 1st byte of 0x00.
Am I missing some ALSA configuration options?
My code uses snd_pcm_hw_params_get_sbits() to retrieve the effective sample word size and it indeed returns 32 for the number of sample bits. I have studied the source code for the ALSA utilities aplay/arecord and I cannot find any clues as to whether arecord is changing the captured samples in any way.
In summary, why does arecord capture 32 bit samples from hardware that will only give me 24 bit samples?
Thanks,
-Andres
How does the 68000 internally represent instructions.
I've read that there are different types of instructions: single effective operation word format instructions, brief and full extension word format instructions. The single effective operation word instruction seems to represent the instruction and the lower 6 bits of this instruction the addressing mode and register. Does this addressing mode and register tell you if there follows a brief or full extension word format instruction, which on his turn represents the operands for the instruction. Do you know a better manual than the 68000 programming reference manual.
Thanks in advance
The actual internal representation is a combination of "microcode" and "nanocode". The 68000 has 544 17-bit microcode words which dispaches to 366 68-bit nanocode words.
While this may not be what you wanted to know, this link may provide some insights:
http://www.easy68k.com/paulrsm/doc/dpbm68k1.htm
right, on m68000 indexed modes uses the brief extension. In "Address Register Indirect with Index (8-Bit Displacement) Mode" (d8, An, Xn), the BEW is filled with D/A (if Xn is a data or address register), Xn (the register number), W/L (to threat Xn contents as 16 or 32bits), scale to 0 (see note), and the 8-bit displacement.
on other hand, other modes, like the 16bit displacement, "Address with displacement" (d16,An) , the extension is only a word with the displacement.
the note is: brief extension word - m68k doesn't support the 2bits for scale so is set to 0; scale on BEW using the scale bits, and full extensions are only suported m68020,40,-> cpus. http://etd.dtu.dk/thesis/264182/bac10_19.pdf
I'm trying to create (or, if I've somehow missed it in my research, find) an algorithm to encode/decode a bmp image into/from a QR code format. I've been using a guide (Thonky) to try to understand the basics of QR codes and I'm still not sure how to go about this problem, specifically:
Should I encode the data as binary or would numeric be more reasonable (assuming each pixel will have a max. value of 255)?
I've searched for information on the structured append capabilities of QR codes but haven't found much detail beyond the fact that it's supported by QR codes -- how could I implement/utilize this functionality?
And, of course, if there are any tips/suggestions to better store an image as binary data, I'm very open to suggestions!
Thanks for your time,
Sean
I'm not sure you'll be able to achieve that, as the amount of information a QR Code can hold is quite limited.
First of all, you'll probably want to store your image as raw bytes, as the other formats (numeric and alphanumeric) are designed to hold text/numbers and would provide less space to store your image. Let's assume you choose the biggest possible QR Code (version 40), with the smallest level of error correction, which can hold up to 2953 bytes of binary information (see here).
First option, as you suggest, you store the image as a bitmap. This format allows no compression at all and requires (in the case of an RGB image without alpha channel) 3 bytes per pixel. If we take into account the file header size (14 to 54 bytes), and ignore the padding (each row of image data must be padded to a length being a multiple of 4), that allows you to store roughly 2900/3 = 966 pixels. If we consider a square image, this represents a 31x31 bitmap, which is small even for a thumbnail image (for example, my avatar at the end of this post is 32x32 pixels).
Second option, you use JPEG to encode your image. This format has the advantage of using a compression algorithm that can reduce the file size. This time there is no exact formula to get the size of an image fitting in 2.9kB, but I tried using a few square images and downsizing them until they fit in this size, keeping a good (93) quality factor: this gives an average of about 60x60 pixel images. (On such small images, it's normal not to see an incredible compression factor between jpeg and bmp, as the file header in a jpeg file is far larger than in a bmp file: about 500 bytes). This is better than bitmap, but remains quite small.
Finally, even if you succeed in encoding your image in this QR Code, you will encounter an other problem: a QR Code this big is very, very hard to scan successfully. As a matter of fact, this QR Code will have a size of 177x177 modules (a "module" being a small white or black square). Assuming you scan it using a smartphone providing so-called "HD" frames (1280x720 pixels), each module will have a maximum size on the frame of about 4 pixels. If you take into account the camera noise, the aliasing and the blur due to the fact that the user is never perfectly idle when scanning, the quality of the input frames will make it very hard for any QR Code decoding algorithm to successfully get the QR Code (don't forget we set its error correction level on low at the beginning of this!).
Even though it's not very good news, I hope this helps you!
There is indeed a way to encode information on several (up to 16) QR Codes, using a special header in your QR Codes called "Structured append". The best source of information you can use is the norm about QR Codes (ISO 18004:2006); it's possible (but not necessarily easy) to find it for free on the web.
The relevant part (section 9) of this norm says:
"Up to 16 QR Code symbols may be appended in a structured format. If a symbol is part of a Structured Append message, it is indicated by a header block in the first three symbol character positions.
The Structured Append Mode Indicator 0011 is placed in the four most significant bit positions in the first symbol character.
This is immediately followed by two Structured Append codewords, spread over the four least significant bits of the first symbol character, the second symbol character and the four most significant bits of the third symbol character. The first codeword is the symbol sequence indicator. The second codeword is the parity data and is identical in all symbols in the message, enabling it to be verified that all symbols read form part of the same Structured Append message. This header is immediately followed by the data codewords for the symbol commencing with the first Mode Indicator."
Nevertheless, i'm not sure most QR Code scanners can handle this, as it's a quite advanced feature.
You can define a fixed image size, reduce jpg header parts and using just vital information about it, so you can save up to 480bytes of a ~500bytes normal header.
I was using this method to store people photos for a small-club ID cards, images about 64x64 pixels is enough.