Cram Codec
Marion Georgi
Microsoft Video 1 or MS-CRAM[1] is an early lossy video compression and decompression algorithm (codec) that was released with version 1.0 of Microsoft's Video for Windows in November 1992. It is based on MotiVE, a vector quantization codec which Microsoft licensed from Media Vision. In 1993, Media Vision marketed the Pro Movie Spectrum, an ISA board that captured video in both raw and MSV1 formats (the MSV1 processing was done in hardware on the board).
Microsoft Video 1 operates either in an 8-bit palettized color space or in a 15-bit RGB color space.[2] Each frame is split into 44 pixel blocks.[2] Each 44 pixel block can be coded in one of three modes: skip, 2-color or 8-color.[2] In skip mode, the content from the previous frame is copied to the current frame in a conditional replenishment fashion.[2] In 2-color mode, two colors per 44 block are transmitted, and 1 bit per pixel is used to select between the two colors.[2] In 8-color mode, the same scheme applies with 2 colors per 22 block.[2] This can be interpreted as a 2-color palette which is locally adapted on either a 44 block basis or a 22 block basis. Interpreted as vector quantization, vectors with components red, green, and blue are quantized using a forward adaptive codebook with two entries.
The codec was available in Microsoft NetShow Encoder,[3] which was later renamed Windows Media Encoder, and made available via the SDK. The NetShow encoder allowed the user to select a 2 pass option, where in the first pass the video was analyzed to create a color palette, and in the second pass converted to the palettized color space and encoded. Before encoding, the video could be scaled. Later versions of Windows Media Encoder dropped support for Microsoft Video 1 and only supported Windows Media Video.
Hmm... Interesting...
Media Player Classic 6.4.9.0. All internal filters are disabled (so only OS codecs and splitters will be used). CRAM and CVID are played correctly.
If I check the Source filters/AVI checkbox -- the file is loaded and the length is correct but the play button not works.
MPC-HC works with both options (checked and unchecked) but it uses LAV Splitter.
Update:
1) MPC 6.4.9.0 plays CVID and CRAM *.avi files w/o crashes/bugs. With and without the internal AVI splitter. Except "Actua Golf 2" ones. 4 files: 2 CVID and 2 CRAM. *Censored*.
Is the MPC AVI splitter has known limitations?
2) Looks like WMP11 fails if an VFW codec is used. CVID, CRAM, IV32. I will continue the search.
FOURCC supports a very large amount of codecs, but in my experience, aside from the major codecs, whether the codec actually works varies. In my experience, I just try the different codecs until one works. lists 'CRAM' as one of their supported codecs, but it also says that it is allegedly simialr to 'MSVC'. Another codec listed is 'WHAM'. Maybe give these a try?
Yeah, I did try those for that same reason but no joy. I used CRAM first since that is what is embedded in the working video file, as you can see in the first image - easier to see if you view it full-size.
I also have the same result with IYUV which is a better-regarded codec but it's the same deal - it works if I select it from the dropdown but not if I direct VideoWriter to use that codec from the code.
I think you can reduce this to your operating system not having the necessary codecs. Could you install a software package with the most random codecs inside, like VLC media player and see if it gets solved?
Okay, I've installed VLC and ran through some codecs (DIVX, IYUV, CRAM, MSVC, WHAM, CVID, PIM1, MJPG, MP42, DIV3, U263, I263, FLV1) but nothing seems to have changed. One thing I was surprised by is I still have the same small list of options* when I pass -1 in as the codec; is there something I need to do in my build or OS environment to tell the program where to find the codecs for encoding?
One other thing I realized is I am able to generate a playable video file by passing in CVID. Unfortunately, that particular codec, whether chosen from the dropdown or specified by the code, causes my throughput to drop from 20 FPS to 6. But, it implies the code works, I just need to figure out how to get it to work with other codecs.
Well, I first tried just downloading the DivX codec and it, like the others, worked from the -1 select but not when specified directly in the code. So, I grabbed the K-lite Basic pack but it only has decoders so I grabbed the 22MB Mega pack and it has some encoders. And... one of them (X264) even works! It doesn't impact my throughput at all and it generates small files. The only issues are relatively minor: it pops up a warning about frames being lost* and a message is logged to the terminal, "Could not find encoder for codec id 28: Encoder not found". Still, much better than the -1 select menu.
NIF finds challenges and opportunities in genomics at a global scale. National programmes meet to share best practices, avoid incompatabilities, and help translate genomics into benefits for human health.
Communities of Interest find challenges and opportunities in areas such as rare disease, cancer, and infectious disease. Participants pinpoint real-world problems that would benefit from broad data use.
At GA4GH we believe in the idea of collaborating on standards and competing on implementations. Our community is dedicated to maintaining viable, open standards that work for everyone. If an implementation has a flaw or weakness, its developers should put effort into improving it, rather than producing a whole new format.
There are numerous comparisons of CRAM to alternative formats that gloss over a huge wealth of detail. CRAM files can differ in size by implementation, but even within the same implementation there are different levels of compression depending on whether the user is targeting speed, file size, or granularity of random access. Comparisons between CRAM and other tools must include not just size but also the software, version, and command line options being used.
Just like gzip, scramble has -1 to -9 arguments to favour light or heavy levels of compression. By default, neither Scramble nor Samtools uses the bzip2 and lzma codecs, but they can be enabled for higher compression. The number of sequences per slice also improves the compression ratio, albeit at the cost of less fine grained random access. For example:
The CRAM format gives complete freedom to write data in whichever blocks it likes so if the encoder puts all data in one block, there is no way to select only some types. However, the major CRAM implementations are now putting each type of data into their own blocks to facilitate ease of decoding (and have been doing this for a while). This means we can get certain types of data out much faster.
Finally, note that it is also possible to extract regions of CRAMs with zero transcoding using cram_filter (again using the -n option I mentioned before, although it could really do with a saner interface that permits e.g. X:10000000-20000000). This, along with BAM equivalents, are the backbone of the efficient GA4GH htsget protocol for streaming NGS data.
The site is secure.
The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.
Motivation: The CRAM format addresses rising DNA storage costs for short-read sequencing by aligning reads to a reference genome and encoding the resulting alignment with Huffman, subexponential, Elias gamma, rANS, gzip and other codes. The CRAM codec is complex, and until now, there has been no JavaScript implementation.
Results: We have developed a JavaScript library, Cram-JS, that natively reads and decompresses the CRAM format on-the-fly. The library is used in the JBrowse and IGV-JS genome browsers and can readily be used by other JavaScript applications, in the web browser or in Node.
Microsoft Video 1 is a vector quantizer video codec with frame differencing that operates in either a palettized 8-bit color space or a 16-bit RGB color space. Video 1 was originall developed by Media Vision and was processed in hardware by a PC expansion card.
Video 1 is a rather simple algorithm. The algorithm operates on 4x4 blocks of pixels, which implies that the source data to be compressed must be divisible by 4 in both its width and height. Just like decoding a Microsoft BMP image, decoding a frame of Video 1 data is a bottom-to-top operation.
The Video 1 codec has two variants: One variant encodes 8-bit palettized data, where the palette is stored in the AVI file header. The second variant encodes 16-bit colors. Actually, the colors are BGR555 data, and the top bit is sometimes used for extra encoding information. To determine which variant a particular AVI file uses, examine the AVI file header, specifically the biBitCount field of the bitmap header within the AVI fileheader.
In order to decode the Video 1 data, traverse through the encoded byte stream, reading the first two bytes into byte_a and byte_b, respectively. The value of byte_b will usually indicate what to do next.
This code specifies that a certain number of blocks should be skipped in the output stream. This is useful for frame differencing (encoding changes from frame to frame) and thus achieving greater compression. The formula for skipping is:
In this encoding, the next 2 bytes in the encoded byte stream are color_a and color_b, respectively. Byte_a and byte_b turn into sets of flags that represent which color, a or b, to place into a particular pixel in the decoded block. The flags are laid out as follows: