Hi,
[c.realtime included in case there are any dustbunnies hiding under the carpet]I'm investigating design strategies for transcoding multimedia formats. There are *way* too many codecs to try to support (plus assorted IP issues). Witness MS's approach to the problem (i.e., DL'ing codecs as content dictates).
I see this as two distinct solution domains:
- stored content
- "live" content
The latter is almost not worth addressing -- you'd have to chase every new codec development in much the same way that MS has (and, still never be assured the ability to handle some new format, "as encountered").
So, the more interesting problem is deciding how to do with *stored* content.
Clearly, if you have control over the "players", it is best to code to a format that *they* support (or *will* likely support) -- or, an approximation thereof -- and store in *that* format (container, codec) rather than having to decode/transcode each time the content is accessed (e.g., consider the case of dozens of clients).
OTOH, you don't want to discard "signal" just because you can't *currently* make use of it. For example, down-converting
1080 to 720 just because you can't "view" (carefully chosen term) 1080 at this time.So, the challenge is to figure out the best compromise between preserving "signal" while minimizing the requirements that you impose on the "player(s)". E.g., converting MP3's to FLAC almost has some rationality to it (?).
As a start, I guess surveying the available codecs in use "today" is probably the first step. See what each trades off (i.e., if a codec's sole raison d'etre is just to have a proprietary claim to the medium, then it offers no value and would have no weight in the decision)
Pointers to where I should start?
Thx,
--don