Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I would like to work with a codec in a project for the university. I'm interested in the VoIP telephone service. The idea is to implement the codec in a DSP and then characterize it. My question is which codec should I choose? In terms of computing resources, there are no limits and neither for bandwidth.

I have searched the web and there are two particular codecs that I find quite interesting. They are the ITU-T G.718B and the IETF Opus. I find them interesting because of their recent development and good features such as scalability and quality. What gives me doubt is if they are suitable for VoIP and why are they better options than G.729.1, G.711.1, AMR-WB or G.722.1. I have no knowledge about their usage in the industry, actually I don't know the usage of any codec besides the traditional G.711.

So, I would like to take this project in the direction of choosing two codecs in order to compare them. Also, I have been thinking in those two (G.718B and Opus) because they are supported by different organizations. But I don't know how to answer the question: Why these?

share|improve this question

closed as not constructive by Karan, Dave M, TFM, Nifle, KronoS Mar 7 '13 at 13:29

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

A few questions for you. Are you going to take existing software implementations of the codecs and integrate them into a system, or are you going to implement the entire codec from scratch? One thing you may want to consider is how complex the specification for the codec is; fully implementing a complex codec could require more advanced algorithms and more sheer volume of code, which could jeopardize your ability to get the work done in time. –  allquixotic Mar 5 '13 at 21:57
My other question: It seems like the goal of your research project is to compare two codecs, yet you are asking us which two codecs to select. Whenever you compare two things, you should understand a number of objective factors that can be used to assess the attributes of those things. So I think your question should actually be, which factors do I need to consider when comparing and contrasting two codecs. Because you don't seem to really understand those. –  allquixotic Mar 5 '13 at 21:58
@allquixotic I will implement the codecs from the specification. I have a little more than one year, in order to study first the theoretical background. –  licuadolala Mar 5 '13 at 22:16
@allquixotic You are right, I really don't know those factors because the proyect will be done in a open enviroment. I mean, there are no constraints of power consumption, quality, etc. –  licuadolala Mar 5 '13 at 22:19
Yes, but is your goal to assess these factors and compare the two codecs, or is your goal just to implement the codecs and then you're done? Focus on what it is that you are trying to accomplish. My answer accounts for a list of factors that can be used when writing a paper comparing two codecs. –  allquixotic Mar 5 '13 at 22:21

1 Answer 1

Here is a list of factors that can be used to objectively (sometimes semi-subjectively) compare the attributes of two codecs:

  • Lossiness: Is the codec lossy or lossless? That is, does it preserve bit-exact fidelity of the digital input data or not?
  • Implementation complexity: how hard is it to write a working implementation of the codec?
  • Specification formality: Unfortunately, some codecs are specified with a lot of room for interpretation by the implementation. Other codecs are specified down to a byte level with an extremely rigorous specification and without any arbitrary "vendor extensions" allowed. There are pros and cons to the formality and rigor with which the specification is given. The main drawback of less rigor / formality is that different implementations are less likely to be compatible (work properly) unless great care is given to restrict what a legal implementation can do, and make sure that a lowest common denominator path always works.
  • Encoding performance: what is the expected runtime, in either asymptotic or practical terms, of the encoding algorithm?
  • Decoding performance: what is the expected runtime, in either asymptotic or practical terms, of the decoding algorithm?
  • Hardware integratability: For reasons I don't entirely understand, but which can be explained by an electrical engineer, some codecs lend themselves very well to implementation directly in hardware, either using an FPGA or fixed gate arrays. Other codecs, for reasons of complexity or algorithmic reasons, are much, much easier to implement in higher level software languages than in hardware.
  • Quality: This is a big and complicated area of research, but the general clarity and reproduction of the sound as close as possible to the input sound. Quality can also be affected by things like psychoacoustics and other new advanced properties that are present especially in lossy codecs.
  • Suitability for a purpose: Some codecs are specifically optimized to work well with specific types of input, such as voice or music, but don't work well at all for other types of input.
  • Latency: Some codecs have a minimum block size for the encoder, which means that you can't encode less than a certain amount of information, or doing so will cause a great reduction in quality (leaving bitrate fixed) or increase in bitrate (leaving quality fixed). This is because a large sample of audio is more likely to contain patterns which can be recognized to encode low entropy data into higher entropy data. Some codecs have variable latency that is tunable by the user, and other simpler codecs have a fixed amount of latency.
  • Supported bitrates: Some codecs support more variety in bitrates than others. Also, most codecs have a "sweet spot" where their bitrate to quality ratio is the best, and going far outside that range will lead to a poor tradeoff between quality and bitrate (either lower-than-expected quality at a high bitrate, or too high of a bitrate needed to achieve a desired quality).
  • Encapsulation: How, if at all, can data encoded by this codec be encapsulated in "container formats"? A container format is a metadata structure that contains information about the encoded data within it. Container formats are often used for streaming media and for files stored on disk, to help media players identify the type of media, and to store data that does not need to be encoded by the encoder, such as text (subtitles, artist, album, etc.). You could investigate which encapsulation formats currently support the codec under study.
  • Sample format support: Does the codec support things like multiple channel audio (stereo, 5.1 surround, etc.)? Does it support a wide range of sampling rates?

And a bunch of practical, hands-on attributes as well:

  • Existing implementations / platform support: Where is the codec currently implemented today? Can you easily install and use the codec in various environments and with various software, or is it hard to get to? Is it already implemented in some hardware designs?
  • License: The codec itself, while being constructed out of, essentially, pure mathematics (number theory, algorithms, etc.), may or may not be patented. The patent status of a codec is "by itself" an inherently neutral attribute, as some purposes may desire patented codecs, while other purposes may desire non-patented codecs. Non-patented codecs carry the interesting attribute of being able to be implemented as Free Software.
  • License #2: The codec implementations (existing ones) may contain copyright license terms which are proprietary, or under some kind of Open Source or Free Software license.
  • Installed base: How many deployed devices or people are using this codec today? Or if this is a storage format, how much media (in bytes) is encoded in this format?
share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.