HyperFish: Difference between revisions
(→libogg2 documentation: updated info from duelist.) |
mNo edit summary |
||
(10 intermediate revisions by 8 users not shown) | |||
Line 1: | Line 1: | ||
{{historical}} | |||
== '''Overview''' == | == '''Overview''' == | ||
This is an experimental subgroup aimed at solving specific project barriers in a timely fashion. | This is an experimental subgroup aimed at solving specific project barriers in a timely fashion. | ||
Line 129: | Line 131: | ||
We're going to have our next meeting Wednesday, Dec. 15th, 23:59 GMT (7pm EST) on irc.freenode.net channel #HyperFish. See the [[HyperFish0412|Agenda]] for more. | We're going to have our next meeting Wednesday, Dec. 15th, 23:59 GMT (7pm EST) on irc.freenode.net channel #HyperFish. See the [[HyperFish0412|Agenda]] for more. | ||
Did the meeting happen? Thx. | |||
Past Meetings: | Past Meetings: | ||
* [[HyperFish0411|Nov. 2004]] - informal discussion and social networking | * [[HyperFish0411|Nov. 2004]] - informal discussion and social networking |
Latest revision as of 04:46, 23 June 2016
Overview
This is an experimental subgroup aimed at solving specific project barriers in a timely fashion.
A lot 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
Major Milestone I
All Xiph codecs accessable with a single library.
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).
Milestones:
- function and structure documentation. Work on this has stopped until another volunteer has stepped forward.
- Date extended Dec. 4th, appx. 10% finished but work has been delayed.
- From Duelist: I've been I've had pretty bad computer problems... circumstances have changed, I doubt I'll be able to make much progress on the docs anytime soon
- the encode/decode process, or how to actually use it.
- finishing it with figures and zero-copy explaination.
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.
I have written conversions for (4:2:0)YUYV, YVYU, YV12, (4:2:2) YUY2, (4:4:4) AYUV, RGB24 and RGB32 already in my directshow project, these could be easily appropriated for this task.
Also most of these generic stream mechanisms already exist in my project (though it is a bit biased towards directshow) and it is based off my own demux library (libOOOgg) and not libogg/libogg2 though it could be used for inspiration/appropriation. It's also written in C++, so this may be unpalatable to some.
Eg. http://svn.xiph.org/trunk/oggdsf/src/lib/core/directshow/dsfOggDemux/OggStreamFactory.cpp
Zen.
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.
Major Milestone II
All Free Software media applications which use libogg1 and/or libvorbisfile converted to use the single library solution.
Major Milestone III
Software that doesn't exist, but should/could be written, which is made easy by single library solution.
Meetings
We're going to have our next meeting Wednesday, Dec. 15th, 23:59 GMT (7pm EST) on irc.freenode.net channel #HyperFish. See the Agenda for more.
Did the meeting happen? Thx.
Past Meetings:
- Nov. 2004 - informal discussion and social networking