Call for Intel Codecs

March 19th, 2012

I’ve spent two weekends and finally REd and wrote decoder for Re* Audio Lossless Format. With news like these I can deliberately call it Intel Audio Lossless Format.

So, what codecs we’re lacking so far?

  • Intel Audio Coder — it’s quite similar to IMC (Music Coder) but not identical.
  • Intel Layered Video Codec — probably it’s just h.263 variant, the only thing I know is that RealVideo 2 decoder was based on it (it’s mentioned in doxygen for Helix SDK I saw once in Internet somewhere and this supports that theory indirectly).
  • ClearVideo — a licensed fractal-based codec. It’d be rather simple DCT-based codec if not for one catch: it uses domain search to generate codes that then are used for block unpacking (and in decoder too, it seems). Maybe these patents will help?
  • Intel NGV — we’ll deal with it when it’s ready 🙂

Feel free to send any useful information about them, preferably working decoders of course.

After that we can claim full support of Real and Intel codec family.

Posted in Audio, Libav, Lossless Audio, Useless Rants | 2 Comments »

A Few Words about my ProRes Encoder

March 19th, 2012

Some people wanted to have ProRes encoder in Libav so I wrote one. And from what I gather it even has one user (not me).

In case someone is interested here is the list of possible options:

  • profile — selects ProRes profile to encode (proxy, lt, standard or hq)
  • quant_mat — selects quantisation matrix from one of profiles (proxy, lt, standard or hq). If you don’t specify it, the matrix will be picked from default profile (or use auto to be really sure). There’s also default matrix which should give the highest quality (it’s default in the sense that when quantisation matrix is not provided in frame decoder defaults to this one).
  • bits_per_mb — how many bits to give for coding one macroblock, different profiles use from 200 bits per macroblock to 2400, one can set it up to 8000.
  • mbs_per_slice — how many macroblocks are there in slice, 1-8. Default value of eight should be good for almost all situations though.
  • vendor — one can put custom vendor ID into frame like apl0 to claim it was produced by Apple encoder.
  • qscale — set fixed quantiser

How to make it encode faster?

In default mode of operation encoder has to honour frame constraints (i.e. not producing frames with size bigger than defined) while still making output picture as good as possible.
If the frame contains lots of small details it’s harder to compress it and encoder spends more time in search for appropriate quantisers for each slice. Thus setting higher bits_per_mb limit will improve the speed.

Or if you don’t care about frame size constraints just set qscale parameter to something (I’d recommend 4) and see it encode MUCH faster.

Feel free to leave wishes for features in comments, hopefully I can implement it when I have time.

P.S. For proper 4444 profile support we need 10-bit YUV with alpha. When it’s in I can add that profile too.

Posted in Uncategorized | 23 Comments »

A bit more about cooking

November 12th, 2011

Sometimes when I have an acute nostalgy I try to cook something from my homeland.

First time I made
Köttbullar (med potatis och lingonsylt självfallet). Too bad I could not do it SWEDISH STYLE! :-(. This time I tried to make Janssons frestelse. Jag hade inget burk ansjovis men bohusmatjessill i stället blev lagom bra.

Posted in #chemicalexperiments | 1 Comment »

A Codec Cookbook

November 12th, 2011

With the addition of VBLE decoder I thought once again about codecs and how they are written.

Lossless Video Codecs

There are two approaches:

  • Take a frame, apply one or two general compression schemes to it. Can be zlib, RLE+zlib or motion compensation from previous frame + zlib.
  • Discover spatial prediction (usually from left neighbour or median) and add some coding for residues. HuffYUV, Lagarith, UtVideo, VBLE, LOCO, FFV1, whatever.

Lots of people try it, find that their codec is faster/compresses better than HuffYUV and release results. Usually those codecs don’t live long and the only bad thing about it is they being released to public in the first place.

Lossy Video Codecs

The codecs are usually more complex, so there are less of them. But there are more ways to create one.

  • lossily quantise raw data or DCT output Every self-respecting company producing frame grabbing cards has written such codec.
  • take a draft of some standard codec and base your work on it That’s how we got Window$ Media, R3al and Off2 video codecs.
  • WAVELETS!!!!111oneone
  • another approach to compression like vector quantisation, binary or quad tree decomposition, object-oriented representation (though this one is mostly used in screen capturing codecs), etc.

The main problem with these codecs is achieving good compression parameters without much hassle. For example, libavcodec MPEG-4 encoder may be the best around here but (like Soviet machinery) one has to work real hard to find out which parameters he/she needs to set to which values to get good compression. That’s the reason why people often choose Xvid instead.

Lossless Audio Codecs

There is one approach to those: add lots of crazy filtering (usually several chained filters) and equally crazy coding of residues. There you got it. Simple filters = faster compression, complex filters = slightly better compression with significantly longer compression times.

Last abstract from lossless video codecs applies to audio as well.

Lossy Audio Codecs

Those appear not too often because it’s very hard to satisfy everybody’s ears. Thus (IMO) it’s mostly limited to speech codec development. And there’s Xiph of course.

Posted in Useless Rants | 1 Comment »

Why FFmpeg is “better” than Libav by Numbers but not in Reality

October 15th, 2011

Time from time there are mails from FFmpeg developers to different distributions saying “Oh, we are better, have more features and more secure, pick us and not libav”. In case somebody wonders here are two examples: Ubuntu and Debian.

So let’s walk through and see the claims. Comparison was made from git snapshots made 2011-10-15 11:00 CEST.

More codecs

FFmpeg claims to have more codecs. In numbers that’s true. Let’s see what are those codecs though:

  • VDPAU accels for MPEG-1 and MPEG-2.
  • AMV encoder. Really just a quick hack to flip picture before using standard JPEG encoding.
  • 8SVX raw audio. Really just a hack to support one particular case of raw planar audio.
  • Flash Screen Video 2 encoder. If you look at the discussion here and the committed file you’ll see that encoder was committed by the same person who had some objections but they never were addressed. Also committing encoder for the codec without any working opensource decoder (well, no decoder beside Adobe Flash client could decode the output properly) is not the brightest idea IMO.
  • CrystalHD MPEG-2, MPEG-4, H.264 and VC-1 support.
  • JPEG-2000 codec. Known to be very buggy and yet included.
  • M$ Video 1 encoder. That was the last review for it – link on gmane and then it was just committed verbatim. Such hypocrisy is one of the reasons I don’t contribute to FFmpeg directly (they pull all patches from libav anyway).
  • DTS encoder. It was considered not to be good enough by the person who was responsible for its development (Benjamin Larsson) but not bad enough to not be included to FFmpeg.
  • G.723.1 codec. The same story.
  • G.729 decoder. It was abandoned halfway by original developer so it’s not complete and buggy.
  • Sonic codec. An experimental codec that was not touched since 2004. It’s not supported by anything and my tests show that it often cannot even compress audio losslessly (output size is bigger than original). That’s why we finally threw it out at libav.
  • Subtitle and text codecs.
  • Stagefright H.264 decoder. It’s too ugly to be included to libav (C++ ABI issues, internal bitstream filter usage).
  • Speex encoder wrapper and Celt encoder wrapper.
  • libaacplus encoder wrapper. It’s based on 3GPP source code and hence not redistributable.

In conclusion, those additional codecs supported by FFmpeg are either hardware acceleration (VDPAU, CrystalHD, stagefright), trivial or some old patches previously rejected but now picked up to maintain impression of superiority.

More muxers and demuxers

Now to muxers and demuxers.

  • ACT and BIT demuxers. Containers for G.729 data.
  • ADF/IDF/bintext/xbin demuxers Containers for text formats.
  • CAF muxer.
  • G.723 demuxer. Container for G.723 data
  • LOAS demuxer. It’s just a hack for probing raw AAC stream.
  • MicroDVD subtitles muxer and demuxer.
  • PMP demuxer.
  • WTV muxer.
  • libmodplug Module tracker file support (libmodplug decodes the files, demuxer outputs decoded raw sound and optional text information).

Most of (de)muxers are either for formats we don’t support or trivial. But I admit there are maybe two demuxers and one muxer that can be included into libav after some cleanup.

Filters

I’m not fully familiar with filter subsystem but it still has too many problems and having an ugly wrapper for MPlayer filters (which are also not of the highest code quality) was one of the points that drove FFmpeg-libav split.

Features, security and overall

When FFmpeg claims to have more features than libav it’s true — they merge everything from libav nowadays. And FFmpeg gets more side features for two reasons: the name is more known and it’s easy to get a feature in because nobody seems to bother with proper reviews nowadays. As for security, it’s the same. For example, when there was a report for some minor security flaw in Chinese AVS decoder, original patch from security investigators (applied in FFmpeg) just made decoder more secure but it still crashed on that file, in libav we created our own patch that dealt with both of these problems. FFmpeg often reminds me of a saying “Socialistic system successfully overcomes the problems it creates itself”.

In conclusion, my opinion is that FFmpeg is trying to compete with libav by lowering standards on accepted stuff. Hence the name of this post.

And I’m glad we can’t have commits like this. For those who have not so good C understanding: it compares addresses of two different strings and it’s an undefined operation that works mostly by luck. So my advise is simple: if you want quality then choose libav, if you want some special features — look for suitable fork at github.

Posted in CEmpeg, Useless Rants | 22 Comments »

Some notes on codecs I’d like to RE but don’t have time to do so

August 27th, 2011

There are some codecs that I’d like to RE (mostly for completeness sake) but I don’t have time for that.

Intel Audio Codec

This one seems to be a lot like its predecessor IMC (Intel Music Codec), it even codes coefficients the same way but with different codebooks. I’ve tried to hack IMC decoder to make it use proper tables but it still decodes garbage.

Along with Indeo4 decoder it would make our Intel codec family complete, but unfortunately we have decoder for neither.

ClearVideo

The codec that was present in AVI, QT and RealMedia. My investigations showed that it was not-so-fractal codec, it still codes blocks with DCT and even does that in simpler fashion than H.263. Though a patent assigned to Iterated System describes what can be the base of this codec: DCT-based codec that uses fractal search to determine the best code for the current block or something like this. Maybe that’s the reason why there are no Huffman tables in decoder while it obviously uses some.

RALF

That’s rather special lossless codec that stands aside from other RealMedia codecs: the file format was altered for that codec (so far I’ve seen only standalone RALF files, not, say, RV40+RALF).

It looks like the codec is rather simple and employs context-dependent codes instead of generic ones. I remember finding about eight hundred static Huffman tables in decoder for that purpose.

Also codec developers were very grateful to their source of inspiration, that’s why codec IS is “LSD:”.

WMA Lossless

Nothing much to say about it. As I remember, it uses infinite impulse response filters for compression and least squares method for finding (and maybe updating) filter coefficients. Should be not so hard to RE but nobody bothered so far.

M$ Screen 1 and 2 (aka WM Screen)

I’ve dabbled in REing MSS1, not MSS2 (which was later relabeled as WM Screen) but they should be related.

MSS1 was rather simple screen codec based on classic arithmetic coding (with adaptive models too IIRC) and binary partitioning. So decoding process was simple: get point for subframe division (horizontal and vertical) and modes for decoding those partitions (fill, skip, subdivide).

VoxWare MetaSound

This codec is obviously based on TwinVQ, it even has similar huge tables for different samplerates and bitrates and I found almost the same header reading code.

In conclusion I want to say that if somebody wants to RE those codecs he’ll be more than welcome (especially for Apple ProRes but I don’t care about it much).

Posted in RealVideo, Useless Rants | 2 Comments »

That is not dead which can eternal buffer, And with strange aeons RALF may be implemented.

August 7th, 2011

And now for something completely different, a post about our favourite eldritch abomination (the word “buffering” should tell it all).

I’ve decided to spend some time on RealVideo codecs.

  • RM demuxer — the one in Libav is based on some scarce guesswork and does many things incorrectly (reporting incorrect FPS, reporting PTS while container stores only DTS, ignoring interleavers, selecting video codec by version reported in its extradata, etc.). I hope improve it a bit or kill trying.
  • RV1/2 — our decoder is based mostly on guesswork, I’ve looked at it and tried to correct header parsing at least. For these codecs internal version number actually matters for bitstream reading. Another funny fact: Real didn’t develop RV2 fully by themselves, they based it on Intel ILVC sources (even some header from Helix distribution says it and I wondered why some functions in RV2 have Hive* names like in Indeo 4 and 5). Also decoder sports some artefacts related to motion vectors outside picture boundaries, maybe it will be fixed too.
  • RV3 — there was a problem with chroma drift, it’s finally fixed.
  • RV4 — there’s well-known problem caused by lack of weighted MC. I’ve finally implemented it, after some cleaning and related work on RV3/4 decoder it should appear in Libav soon.

P.S. So far there are two codecs not supported by Libav, RALF (yet another pointless lossless audio format in its own special container too, or in slightly twisted RM at least) and ClearVideo (yes, it was possible to have non-RV there, anybody remembers that fractal codec?). While RALF is unlikely to be implemented ever (I think I wrote about it once), ClearVideo might be supported eventually but don’t hold your breath on it.

Posted in RealVideo | 5 Comments »

Är du från Norrland?

August 6th, 2011

That’s the question you may ask when you see what I’ve eaten. Since it’s August, it’s the best time to try the famous Norrlandish product (if you ever dare, most people don’t).

A Tin of You-Know-What

A Tin of You-Know-What

I would lie if I say that I’ve eaten it all, I’ve managed to eat only two or three bits (with hard bread from Wasa and local milk). That should be enough for a lifetime.

As for common beliefs: yes, it’s easy to open the tin without getting sprayed by fluid (though I wore a T-shirt with FFmpeg logotype just in case); the stench is not that vile (especially if you freeze or cool it before opening and you can bear garbage dumps in heat) though it’s definitely better to open the tin outside and away from houses and maybe catching cold; the taste is rich, salty and quite peculiar so it’s better left to the gourmets.

At least it’s an excuse to drink a bottle of Trocadero.

Posted in Uncategorized | Comments Closed

A bit about soft drinks

June 11th, 2011

I’m rather picky person, so I don’t drink alcohol, try to avoid drinking Coca-Cola or Pepsi and hate still water (especially Danish one). So here’s my review of what I could drink in different countries.

Ukraine

There are many different soft drinks, mostly of mediocre quality, but some are quite good. There are some good mineral waters too (the best one is hard to find outside the region where I lived, sometimes it’s hard to find there as well).

And usually drinks are sold in all varieties of bottles — from 0.5l to 2l

Germany

Mostly you get here is very good selection of mineral water, Apfelschorle and variations of Spezi (aka tyska oriktiga Trocadero). There are also some strange flavours like cherry+ginseng or bitter lemon (tastes mostly like lemon skin). Oh, and 0.5l bottles for those drinks made by Coca Cola company (seems Germans prefer local inventions to their main product) look like designed by Norwegian, the bottle is made from too thick plastic and maybe it was designed in 3D CAD without Bezier curves support.

Switzerland

Mostly the same as in Germany but with more pathos and higher prices (while in Austria Apfelschorle is called something like “sprudel Apfelsaft”, in Switzerland I’ve seen “Shorley”). That goes for most Swiss products anyway.

Denmark

Those people seem to hate carbonated mineral water (usually Danish mineral water with gas has only two bubbles to distinguish it from still water) and the only time I tasted their drink it was too sugary.

Belgium

Looks like it’s better to buy orange juice there instead.

Finland

Very good selection of drinks.

Norway

Limited but rather decent selection of drinks. The bottles look like they were made from single piece of plastic mostly with axe.

Sweden

One of the reasons I love Sweden. Excellent selection of drinks, including special seasonal ones (Julmust and Påskmust). Here’s an example of Påskmust:

img_7247

And of course, there’s the ultimate drink (IMO):
The Trollcadero

There are about eight different breweries producing it, I have tried it all except for two breweries.
And I have tried all but one soft drinks from Vasa Bryggeri. Probably I should go to Norrland again.

As for mineral water, they have Ramlösa, good water from Bergslagen region and even from the tap in many regions (it’s drinkable everywhere in Sweden, but tastes especially good in some places).

Posted in Useless Rants | 2 Comments »

Some notes on video in LucasArts games

April 2nd, 2011

Recently I’ve been trying to add video support from LucasArts games to Libav and I must admit it’s not that easy. While there are only two container formats (one for paletted videos and one for 16-bit ones) there are too many compression methods used for palettised videos.

Here are some known codec numbers:

  • 1­–3 (the same codec actually)
  • 5
  • 21
  • 37
  • 47
  • 48

Codecs 1-3, 37 and 47 are common in adventure games, so I have more interest in supporting them (and ScummVM has decoders for them). But starting with at least codec 37 they added subcodecs, so there are several compression methods may be employed with each of them (ranging from raw data to RLE to vector quantisation). That means a lot of reverse-engineering work to support it so don’t expect full-featured decoder soon. And there’s also audio.

Posted in Game Video | Comments Closed

« Older Entries
Newer Entries »