NihAV — A New Approach to Multimedia Pt. 3

More on codecs handling

First of all, people are often AVI-centric and decide that you can always use 4-character code to identify a codec. Well, technically it’s true because there’s significantly less than 4 billion codecs in existence (I hope). The problem is uneven mapping — MPEG containers use integers for codec IDs, AVI uses 4-character code for video and 2-byte integer for audio, MOV uses 4-character code for both audio and video, Matroska uses long strings like V_MPEG4/MS/V3 etc etc. So in any case you have a problem of mapping codecs found by demuxers to internal decoders. In libavcodec it’s handled by having an insane enumeration of codec IDs and I’ve mentioned in part 2 that I’m not a fan of such approach.

So what I suggest instead? A global registry of codec names in string form. And splitting out media information database explicitly. After all, why not provide some codec information even if we cannot support it? Less effort when you add a new decoder and you can query some information about codec even if it’s not supported. Demuxer maps internal ID to codec name (if it can), codec database can be queried about that codec at any time to see what information is known about it and a decoder can be requested for that codec as well.

Here’s an example:

  1. Bink demuxer encounters KB2g;
  2. It reports binkvideo2 decoder;
  3. (optional) From database one can retrieve its name — “Bink Video 2”;
  4. A decoder for binkvideo2 is requested for it but that request is failed because noone has bothered to write such decoder;
  5. Or a decoder implemented by a special plugin that calls TotallyRADVideo.dll is called.

Just replace enum with string and you get better flexibility and only VideoLAN won’t like it.

4 Responses to “NihAV — A New Approach to Multimedia Pt. 3”

  1. compn says:

    i look forward to binary decoder loader support in lavc.

    then maybe ***tube can get rid of mencoder ;P

  2. Kostya says:

    Generic binary decoder loader is pretty useless these days — it needs to be x86 32-bit (or 64-bit for those few codecs that provide such decoders) and it’s better to have native support anyway 🙂 And if you look at old MPlayer loader it had too many hacks for specific .dll to make them work.

  3. compn says:

    arent we still missing r3d and few other big codecs?

    there arent a lot of reverse engineering devs around.
    but there are always new codecs.

    reverse engineering a wavelet codec , or even writing one from spec like h264/h265 is incredibly difficult.

    binary loader is required.

    did you look at r3d before? i dont remember.

  4. Kostya says:

    I think no-one has tried REing a wavelet codec before (or write it from the spec). And I vaguely remember r3d being motion JPEG-2000 or something.