HyperFish: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
Line 32: Line 32:




=== libogg2 documentation ===
Currently (afair) only Monty and myself (Arc) know libogg2's API well enough to port existing codec libraries (vorbis, speex, flac) to use it.  Documenting libogg2 will allow additional people to get involved in the "fun".
This requires the person writting the docs to get the appropriate information from the source code and by talking to either Monty or Arc (most probobally, some combination of the two). 
The first milestone is function and structure documentation.  This will be finished by Nov. 24th.
The second milestone is the encode/decode process, or how to actually use it.  This will be finished by Dec. 1st.
The third milestone is finishing it with figures and zero-copy explaination.  This will be finished by Dec. 15th.
=== writ codec plugin ===
Writ is an extremely simple "codec" and, really, simply needs to be handled by the application.  However, a codec plugin is still required to detect and get basic information from the header for OggStream.  This is a good place to start because it's simple.
It requires liboggstream to be finished and approximatly 10 hours of Arc's time.
=== libvorbis porting/plugin ===
libvorbis needs to be ported to libogg2 and have a codec plugin written for it.
This requires liboggstream to be finished and libogg2 to be documented (unless Arc or Monty writes it).  It will take approximatly 12 hours to port to libogg2 (everything but VorbisFile, which disappears now) and 36 hours to write and debug the codec plugin.  Some of this time will be spent working on general OggStream audio issues.
First milestone is libogg2 porting
Second milestone is decode support
Third milestone in encode support
No dates on these milestones can be set until OggStream's timeline is established.
=== libtheora plugin ===
libtheora has already been ported to libogg2 (by Arc), but still needs a codec plugin written for it.
This requires liboggstream to be finished.  It will take approximatly 52 hours to write and debug the codec plugin, much of this time will be spent writting raw video format conversion functions.
First milestone is YUV 4:2:0 decode support
Second milestone is YUV 4:2:0 encode support
Third milestone is YUV 4:2:2, 4:4:4, RGB24, and Greyscale conversion
No dates on these milestones can be set until OggStream's timeline is established.
=== libspeex plugin ===
libspeex uses it's own bitpacker, so it cannot take advantage of libogg2's zerocopy advantages.  Therefore, the codec plugin will use libspeex as it currently exists and "copy" (from memory to bitpacker) the packets into libogg2, or vice versa for decode, as speexenc/speexdec do.
This requires liboggstream to be finished, libogg2 to be documented, and approximatly 48 hours to write and debug the codec plugin (likely half this estimate if the libvorbis plugin author tackles this immediatly afterward).
First milestone is decode support
Second milestone is encode support
=== libflac plugin ===
liboggflac needs to be ported to libogg2 as well as the codec plugin written for it. 
This requires liboggstream to be finished, libogg2 to be documented, and the new OggFLAC encapsulation format be standardized so there's not a wasteful repetition of work.  It will take approximatly 16 hours to port and 48 hours to write the codec plugin.  Again, this would be less if the libvorbis/libspeex author tackled this job as they would already be familiar with how to write audio plugins.
First milestone is decode support
Second milestone is encode support
=== [[MNGOverlay]] plugin ===
It's been suggested that MNG be used not just as video but also for graphical subtitles.  This ''may'' mean that this codec acts as a meta/effects codec, inputting video output from another codec and outputting it with the overlay merged properly.
This task needs to be discussed further.
=== Linux media player porting ===
Existing free media players (Xine, MPlayer, XMMS, VLC, etc) need to be ported to use liboggshare instead of libvorbisfile (or whatever they are using now for theora+vorbis).
This task needs to be discussed further.


== '''Next Meeting''' ==
== '''Next Meeting''' ==


We're going to have our first meeting Wednesday, November 24th, 23:59 GMT (7pm EST) on irc.freenode.net channel #Xiphmeet - it will be mostly preliminary visioning, since most everything depends on [[OggStream]] (or equiv)
We're going to have our first meeting Wednesday, November 24th, 23:59 GMT (7pm EST) on irc.freenode.net channel #Xiphmeet - it will be mostly preliminary visioning, since most everything depends on [[OggStream]] (or equiv)

Revision as of 03:01, 20 November 2004

Overview

This is an experimental subgroup aimed at solving specific project barriers in a timely fashion.

Alot of energy has gone into Xiph, and while producing extremely useful software, it's history is also littered with frustrated, burned out hackers. I'd like to see us evolve a new way of working, and I believe this begins by a subgroup forming a vision, goals, and a strategy towards getting these goals met.

  • Hyperfish members will:
    • work openly and *transparently*, even if we're the only person working on a project
    • report *regularly* to the group how we are progressing (ie, if we're on schedule)
    • meet monthly (on IRC) to discuss our progress, timeline, and collectivly brainstorm

 

  • Each HyperFish project will have:
    • clearly documented purpose and list of needs
    • milestones with specific dates for completion
    • frequency of progress reports expected, depending on the size of the project and how critical it is

 

If this process proves useful, it will hopefully be adopted by Xiph as standard procedure.


Roadmap

OggStream

It's basically what OggFile was suppost to be; a universal Ogg stream handler through "codec plugins" so that media players, stream software, encoders, etc don't have to add support for each codec seperatly. This is a basic foundation for most other projects, since if they are codecs they will reach our audience faster through it and if they're applications they'll be able to use all current and future Ogg codecs with only one API to support.

It needs developer time both for coding and for settling on an easy to implement API that's flexible enough to handle any kind of future codec (including meta/effects codecs).

The first milestone is a rough API blueprint for which future discussion can take place through. This will be documented on project page and ready for discussion by Wed. Nov. 24th.

Future milestone will be discussed and detirmined at the next (first) meeting.


libogg2 documentation

Currently (afair) only Monty and myself (Arc) know libogg2's API well enough to port existing codec libraries (vorbis, speex, flac) to use it. Documenting libogg2 will allow additional people to get involved in the "fun".

This requires the person writting the docs to get the appropriate information from the source code and by talking to either Monty or Arc (most probobally, some combination of the two).

The first milestone is function and structure documentation. This will be finished by Nov. 24th. The second milestone is the encode/decode process, or how to actually use it. This will be finished by Dec. 1st. The third milestone is finishing it with figures and zero-copy explaination. This will be finished by Dec. 15th.


writ codec plugin

Writ is an extremely simple "codec" and, really, simply needs to be handled by the application. However, a codec plugin is still required to detect and get basic information from the header for OggStream. This is a good place to start because it's simple.

It requires liboggstream to be finished and approximatly 10 hours of Arc's time.


libvorbis porting/plugin

libvorbis needs to be ported to libogg2 and have a codec plugin written for it.

This requires liboggstream to be finished and libogg2 to be documented (unless Arc or Monty writes it). It will take approximatly 12 hours to port to libogg2 (everything but VorbisFile, which disappears now) and 36 hours to write and debug the codec plugin. Some of this time will be spent working on general OggStream audio issues.

First milestone is libogg2 porting Second milestone is decode support Third milestone in encode support

No dates on these milestones can be set until OggStream's timeline is established.


libtheora plugin

libtheora has already been ported to libogg2 (by Arc), but still needs a codec plugin written for it.

This requires liboggstream to be finished. It will take approximatly 52 hours to write and debug the codec plugin, much of this time will be spent writting raw video format conversion functions.

First milestone is YUV 4:2:0 decode support Second milestone is YUV 4:2:0 encode support Third milestone is YUV 4:2:2, 4:4:4, RGB24, and Greyscale conversion


No dates on these milestones can be set until OggStream's timeline is established.


libspeex plugin

libspeex uses it's own bitpacker, so it cannot take advantage of libogg2's zerocopy advantages. Therefore, the codec plugin will use libspeex as it currently exists and "copy" (from memory to bitpacker) the packets into libogg2, or vice versa for decode, as speexenc/speexdec do.

This requires liboggstream to be finished, libogg2 to be documented, and approximatly 48 hours to write and debug the codec plugin (likely half this estimate if the libvorbis plugin author tackles this immediatly afterward).

First milestone is decode support Second milestone is encode support


libflac plugin

liboggflac needs to be ported to libogg2 as well as the codec plugin written for it.

This requires liboggstream to be finished, libogg2 to be documented, and the new OggFLAC encapsulation format be standardized so there's not a wasteful repetition of work. It will take approximatly 16 hours to port and 48 hours to write the codec plugin. Again, this would be less if the libvorbis/libspeex author tackled this job as they would already be familiar with how to write audio plugins.

First milestone is decode support Second milestone is encode support


MNGOverlay plugin

It's been suggested that MNG be used not just as video but also for graphical subtitles. This may mean that this codec acts as a meta/effects codec, inputting video output from another codec and outputting it with the overlay merged properly.

This task needs to be discussed further.


Linux media player porting

Existing free media players (Xine, MPlayer, XMMS, VLC, etc) need to be ported to use liboggshare instead of libvorbisfile (or whatever they are using now for theora+vorbis).

This task needs to be discussed further.

Next Meeting

We're going to have our first meeting Wednesday, November 24th, 23:59 GMT (7pm EST) on irc.freenode.net channel #Xiphmeet - it will be mostly preliminary visioning, since most everything depends on OggStream (or equiv)