[gentoo-dev] [RFC] Codec project

2020-06-10 Thread Michał Górny
Hi,

Let's split this from [1] as I suppose having it in middle of high-noise 
'up for grabs' might prevent some interested people from seeing it.

The general purpose of codec project [2] is to maintain core libraries
for various multimedia format encoder/decoder libraries.  It's like
gfx+sound+video except only for core packages and not every possible
single viewer, player, editor, frontend...  I believe that this specific
focus make more sense than the wider projects, i.e. it is more likely
than N people will actually co-maintain libraries used by many tools vs
N people co-maintain 20 alternative sound players (when they are
unlikely to use more than one at a time).

The main questions are:

1. Should the project be focused on reference/most common
implementations, or maybe more of them?  Say, giflib vs libnsgif.
I think the latter library is specific to a few programs right now but
if it gets more popular, it would fit.

2. How many kinds of media should the project accept?  Audio, graphics,
video seem pretty obvious.  Containers too.  libass makes sense as it is
specifically for video subtitles.  Anything else?

3. What about libraries implementing media-specific streaming protocols?
E.g. libshout, live...  I suppose the ones specific to voip would fall
into voip project's domain instead.


[1] 
https://archives.gentoo.org/gentoo-dev/message/79073ab9c7cebd79fc12e897e110bc3c
[2] https://wiki.gentoo.org/wiki/Project:Codec_project

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] Codec project

2020-06-10 Thread Kent Fredric
On Wed, 10 Jun 2020 20:25:20 +0200
Michał Górny  wrote:

> The general purpose of codec project [2] is to maintain core libraries
> for various multimedia format encoder/decoder libraries.  It's like
> gfx+sound+video except only for core packages and not every possible
> single viewer, player, editor, frontend...  I believe that this specific
> focus make more sense than the wider projects, i.e. it is more likely
> than N people will actually co-maintain libraries used by many tools vs
> N people co-maintain 20 alternative sound players (when they are
> unlikely to use more than one at a time).

Somehow I get the impression that "codec" as a scope is still too general.

For instance, people well acquainted with audio codecs aren't
necessarily well acquainted with video codecs, or image codecs.

A package that only does audio-playback for instance, won't be of
interest to somebody who predominantly cares about video playback.

I'm not entirely against it as a concept as-is, I just suspect it will
reiterate the previous problem.


pgpt1MEfgzDTX.pgp
Description: OpenPGP digital signature