File: mainpage.incl

package info (click to toggle)
gavl 1.4.0-5
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 14,912 kB
  • sloc: ansic: 437,319; sh: 10,487; makefile: 238
file content (82 lines) | stat: -rw-r--r-- 4,936 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

/*! \mainpage

 \section intro Introduction
   This is the API documentation for the Gmerlin audio video library,
   a library for handling and conversion of uncompressed audio- and video data.
 
  Click Modules (on top of the page) to get to the main API index.
  Here, you find just some general blabla :)

  \section why Why gavl?
  \subsection problem The problem

  If you start to write some software, which has any kind of audio-, video- or image-support,
  you'll soon be confronted with the fact, that the method for storing audio and image data in
  memory is by no means standardized. In the audio area, we have different ways to store
  multichannel sound (interleaved or all channels separate) and different sample sizes.
  Furthermore, it can happen, that a cheap soundcard isn't happy with the 5.1 channel sound
  and the 48 kHz samplerate, so you'll need to convert it to 44.1 kHz/Stereo.
  In the video and image area, the situation is not better. Images can be planar or packed,
  have different colorspaces, color orderings and chroma subsampling modes.

  So you can learn how to read images in 24 bit RGB and display them with GTK or SDL. Handling
  interleaved 16 bit audio samples is also no major problem. But if your program becomes
  popular, people want to have 24 bit audio, RGB images with 16 bit per color channel
  (or even floating point),
  and they are not longer satisfied with your bilinear video scaler. If you want to support
  a large number of formats, you'll want to convert each format into each other without any
  intermediate conversion (to save time and preserve accuracy).

  Now you can do some simple mathematics to find out, that for N formats, the number of
  conversions from every format to every other is N*(N-1). Assuming, you want to support
  26 pixelformats (like gavl does at the time, this file was written), you end up with
  a theoretical number of 650 conversion routines. After removing redundant conversions,
  you still have to write more than 600 functions. Since these are for pixelformats only,
  and you also want to do audio mixing for all sample formats and lots of other conversions,
  the total number of routines will soon exceed 1000.

  These numbers are probably the reason, why up to now, no universal solution for the
  problems described above, was written.

  \subsection solution The solution

  Programming universal audio/video converters is a painful process. 1000s of conversion
  routines must be written, debugged, tested and optimized.
  For this reason, a decision was made to do this madness once and make it available for other
  programmers who can afford to write GPL software. Gavl handles mainly the following tasks:

  - Definition of audio/video formats. This is done by having several enums and
    structures, which contain all information necessary for unambiguous definition of an
    Audio/Video format. A gavl enabled application will automatically have support for the
    same range of formats as gavl.
  - Containers for audio- and video-frames. These can carry A/V data in all supported
    formats. Basic routines are available to allocate/free/copy frames and some utilities.
  - Conversion among all formats. There are generic audio and video converters available,
    which have a configurable quality level. Higher quality always means lower speed.
    This means, that you can use gavl, if you must handle 100 audio streams simultaneously
    at telephone quality as well as for High Definition video production.

  A development goal of gavl is to have a complete set of conversions. You'll never get
  black images or silent audio frames because of missing conversion routines or speed losses
  because intermediate conversions are invoked. After this goal is reached, sometimes alternate
  routines are implemented, which focus either on more speed or higher accuracy. These can
  be selected by choosing a quality other than 3.

  \subsection advantages Advantages

  Using gavl in your application brings lots of advantages:

  - The most ugly tasks of multimedia programming are already done for you, so you
    can concentrate on your application
  - If you nevertheless find ways to improve the quality and/or speed of gavl, then do so.
    Making and sending a patch will still be less work, than writing such a library from scratch.
  - Without any additional labor, you handle all formats, which are supported by gavl.
    Impress your audience with 32 bit audio or floating point RGB processing.
  - Gavl fits smoothly to all existing Audio/Video and image APIs. You'll find lots of examples
    in the sourcetrees of gmerlin and gmerlin_avdecoder.
  - APIs (for codecs, hardware access, effects etc.), which are based on gavl, can
    nicely interact with each other. You can, for example, easily write an import module for
    gmerlin_avdecoder, which will decode most important Audio/Video formats.

  */