theora - Apr 2008 - Dropping etheora decoding support for overlapping with oggplay?

Hey,

Commenting a SoC application about improvement of Etheora, Conrad
Parker said the development should focus first on the encoding
features since liboggplay is overlapping with Etheora.  I'm
transcripting the   here so the Etheora's priorities can be better
discussed by everyone (and searchable on the web).

_____


Conrad, you mean concentrating first on encoding part, or pehaps
dropping the decode support from etheora at all? I didn't know
liboggplay (well, in truth I thought it was used only for vorbis) and
it's clear that their purposes share a lot of funcionalities.

I believe Etheora's plan is to go a little beyond of the features
implemented in liboggplay (but maybe the liboggplay is going to have
more features added) and that they adopt some different programming
philophies (e.g., At first I wanted to ask from the user a callback
function for setting and reading data in the frame, I droppep in
favour of providing a matrix where user could read the i,j coodinate
transparently in the colorspace s/he wanted) what may difficult a
merge. However, I think there could be advocates of a merge, and I
consider the possibily of I myself to become one of them; so I'm
changing the schedule to focus on encoding features first.

 But I'd like to hear from you (and the people) if we're should be
heading for a unique decoding library (etheora working only for
encoding) or it's worth to provide 2 libraries with some overlapping
features (maybe the merger isn't possible at all for some reason, eg,
there may not be a agreement or the final functionalities the
libraries should have).

Hi,

On 06/04/2008, Ribamar Santarosa de Sousa <ribamar.santarosa at gmail.com>
wrote:
>
>  Conrad, you mean concentrating first on encoding part, or pehaps
>  dropping the decode support from etheora at all? I didn't know
>  liboggplay (well, in truth I thought it was used only for vorbis) and
>  it's clear that their purposes share a lot of funcionalities.
I meant to concentrate on the encoding first, that could make a good
SoC project (ie. concrete functionality that is achievable within the
allocated time).

After that, like you said we should discuss how the various libraries
fit together, and it would be great if you could help with simplifying
the APIs (as well as general ongoing maintenance :-)

cheers,

Conrad.