HyperFish0411

This is was the first HyperFish meeting. Alot of people showed up and alot of dissonance between various project goals, but good connections resulted from it.

--- Log opened Wed Nov 24 18:58:35 2004
18:58 -!- FishLogger [~root@rp1.lightlink.com] has joined #Xiphmeet
18:58 -!- Topic for #Xiphmeet: Welcome to the Xiph.org meeting and discussion channel | Next montly meeting at 23:59 GMT December 1 : http://wiki.xiph.org/MonthlyMeeting200412 | log of the last meeting at http://westfish.xiph.org/~giles/200411_meeting.txt
18:58 -!- Topic set by rillian [] [Thu Nov  4 00:44:44 2004]
18:58 [Users #Xiphmeet]
18:58 [ AndrewBachmann] [ FishLogger ] [ j^    ] [ philk   ] 
18:58 [ Arc           ] [ foolip     ] [ kfish ] [ van_peru] 
18:58 [ derf_         ] [ illiminable] [ murdos] [ zaheerm ] 
18:58 -!- Irssi: #Xiphmeet: Total of 12 nicks [0 ops, 0 halfops, 0 voices, 12 normal]
18:58 -!- Channel #xiphmeet created Tue Oct 12 06:06:00 2004
18:58 -!- Irssi: Join to #Xiphmeet was synced in 1 secs
18:58 -!- [freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
18:59 < Arc> ok
19:00 < Arc> so quite a few of us have come, so lets start with a brief (one-line) into each, including what we want to contribute to these kinds of projects
19:00 -!- ozone [~pan068@c211-30-78-105.belrs2.nsw.optusnet.com.au] has joined #xiphmeet
19:00 < ozone> greetings
19:00 < AndrewBachmann> alphabetical?
19:00 < Arc> in any order. :-)
19:00 < illiminable> morning ozone
19:00 < ozone> you're up zen? :}
19:01 < philk> Hi there!
19:01 < ozone> or you haven't gone to bed yet ...
19:01 -!- SebastianG [~yay@c-180-198-23.bi.dial.de.ignite.net] has joined #xiphmeet
19:01 < Arc> my name is Arc, I'm involved with development, especially around libogg2, and am interested in contributing more to getting this ready for "primetime"..
19:01 -!- MikeS [~msmith@CPE-144-137-38-92.vic.bigpond.net.au] has joined #xiphmeet
19:01 < AndrewBachmann> ok, I'm from the haiku project (formerly known as OpenBeOS)..  I wrote a ogg plugin for our media framework, based on libogg.  I'm interested in helping to ensure the library addresses my issues with that. :-)
19:02 < Arc> others?
19:02 < illiminable> I guess this is me... my names zen (is this an AA meeting ?)... i work on the directshow project and associated windows stuff.
19:02 < zaheerm> im from the gstreamer project, i have created the caster livecd thats ome of you may have seen, and do streaming for the local mosque in various forms..mp3, ogg (vorbis audio) and experimentinf with  ogg (theora/vorbis) with flumotion
19:03 < j^> im j, i wrote the jackplugin for ices-kh and ffmpeg2theora, right now im working on some theora tools related for media distribution
19:03 < illiminable> ozone: yeah not often i'm waking up at this time... "There's an 8 o clock in the morning now?"
19:03 < ozone> hi, i'm from the annodex project (www.annodex.net).  we're working on metadata in multimedia, particularly web-like metadata, such as annotation and hyperlinking of video and audio.  i'm also working on the xine media player, and dabble in videolan
19:03 < philk> I'm working on the Vorbis RTP spec and implementation.
19:04 < MikeS> Hi. I'm Mike Smith. I wrote much of vorbis-tools and icecast, and help out with lots of other things. 
19:05 < Arc> ok we're missing some people but i guess they're idle.. 
19:05 < kfish> i do annodex stuff, and wrote some wrappers for xiph libraries (liboggz, libfishsound), wrote the sound editor sweep, and random stuff in xine etc.
19:07 < Arc> ok
19:07 < Arc> (others can greet as we're going along..)
19:08 < Arc> so the purpose of this meeting is to *begin* forumulating a vision and roadmap for where we'd like to see Xiph in a year (two years, etc)
19:08 < SebastianG> hi! i don't wanna be rude (not greeting) but I guess I've not much to contribute ;)
19:08 < Arc> lots of different ideas, some which work together, some that don't, and not everyone on the same page
19:09 < Arc> (SebastianG: everyone has something to contribute :-))
19:09 < Arc> so the question of "where are we at in a year" is pretty broad, I'd like to start with something fairly small: the overall Ogg framework
19:10 < Arc> I've already layed out what I'd like to see in a year on the wiki, so how about someone else start with this
19:10 -!- DanielWH [~chatzilla@m09105e42.tmodns.net] has joined #xiphmeet
19:10 < ozone> what's the wiki page?
19:10 < DanielWH> hello
19:10 < Arc> wiki.xiph.org/HyperFish
19:11 < AndrewBachmann> http://wiki.xiph.org/HyperFish
19:11 < kfish> ok Arc, I'm very much looking forward to libogg2 documentation
19:12 < Arc> kfish: what do you want to see as a result of that documentation being available?
19:12 < kfish> but i'd like some clarification on what liboggstream is supposed to achieve
19:12 < Arc> ah ok.
19:12 < illiminable> Well, for me... within 1 year, i'd like a commercial quality sdk to be available for windows. And ogg support to be on more than 1 million windows machines
19:13 < AndrewBachmann> I'm primarily here for liboggstream too
19:14 < Arc> (answering kfish's question briefly): Real, Quicktime, etc have media frameworks around their formats.  Not only does it handle codec stuff automatically, that is, no direct software support needed by the application, but also "auto-downloads" plugins for codecs you don't yet support
19:14 < DanielWH> My name is Daniel Holth, I wrote a wrapper for theora that lets you decode it from within Python, it is now really easy to do things like turn frames of theora into png images. I really like programming in Python and C++
19:15 < kfish> Arc, ok, so you're talking about decode/playback; for which I'd offer that ensuring support in the existing frameworks (gstreamer, DirectShow, QuickTime, as well as xine, mplayer, videolan etc.) should be our priority
19:15 < DanielWH> I also wrote a nice wrapper for doing libshout from C++ and Python, and a prototype theora streaming function for icecast + shout.
19:15 < Arc> so the goal is a library, similar to VorbisFile but for all Ogg files, part of the libogg2 package, which supports this on a variety of different levels.. from "just handle the codec, thanks" to "please do all IO for me, oh and btw, please output it to my video/soundcard too if you would.."
19:15 < ozone> Arc: you are suggesting to turn ogg into a media framework?  there are a few around which already exist ...
19:15 < zaheerm> Arc: how is the auto-codec downloading stuff meant to work on non-windows platforms (ie all the multiple architectures (distributions) around
19:15 < illiminable> Just a point on oggstream... it is somewhat redundant, since directshow already does all this stuff, and it's tried, tested and stable.
19:16 < MikeS> Arc: Can you explain why it's useful to invent a whole new framework, rather than produce production-quality implementations of ogg (and the xiph codecs) within the existing frameworks (as, for instance, illiminable is doing on windows/DShow)?
19:16 < zaheerm> and gstreamer on other platforms...
19:16 < Arc> I think everyone just answered their questions with eachother's questions.
19:16 < MikeS> Hrm. It looks like other people asked my question faster than I managed to :-)
19:16 < Arc> multiple parrellel implementations.
19:16 < DanielWH> I would like to ensure the theora wrapper is finished as the theora api finishes.
19:16 < AndrewBachmann> I was hoping oggstream would be a "bigger, better" version of liboggz
19:17 < AndrewBachmann> which is hardly a media framework :-)
19:17 < kfish> AndrewBachmann, sure :)
19:17 < Arc> it's not a media framework as in gstreamer. it's designed for Ogg.. gstreamer is much more
19:17 < AndrewBachmann> such a thing would be useful for gstreamer, dshow folks, etc.
19:17 < MikeS> Arc: the point is integrating with platform services, which is absolutely _critical_ for widespread adoption on desktops. oggstream might be useful on its own, but gets us no closer to proper system integration. Isn't this, then, a step in the wrong direction?
19:18 < ozone> Arc: question is, who's going to use an Ogg-only media framework, when other perfectly good ones exist?
19:18 < ozone> i.e. what's the motivation for the project?
19:18 < Arc> hold up :-)  everyone's asked the same question, let me answer it :-)
19:18 < illiminable> and the other frameworks support ogg and all the other media formats (ie directshow)
19:19 < MikeS> illiminable: You said something on the lists that suggested that large parts of your directshow code isn't directly tied to directshow - implying that it'd be very useful as a base part of implementations for quicktime, gstreamer, etc, etc. Would you be able to elaborate on that a little? Or tell me I'm totally confused, if that's the case...
19:19 < Arc> every existing framework, because we've lacked something like oggstream/oggfile, have ended up building their own Ogg support seperate.  every framework has it's own quirks, and as new codecs are deployed, they must be released for each.
19:19 < illiminable> I would imagine for non-windows something like gstreamer (which is directshow like) would be a good place to implement without re-inventing the wheel
19:20 < AndrewBachmann> I think we've already got at least three or four wheels around for doing OggStream-type stuff
19:20 < AndrewBachmann> it'd be better if we all had one, I think :-)
19:20 < kfish> Arc, so, for example, the approach i took with liboggz was to make a simple Ogg mux/demux library that fits into the demux stage of existing frameworks
19:20 < Arc> ok let me give a scenario
19:20 < AndrewBachmann> I'm talking about what MikeS referred to
19:20 < illiminable> mikes: Well... where possible, if it didn't really need to be tied to directshow it's not... and in some places where it is, it was just for simplicity and could be factored out
19:20 < Arc> we have this new video format, Dirac, which we want to integrate with Ogg.
19:20 < illiminable> So yeah... a lot of it could easily be reused.
19:21 < Arc> ok.  We need to integrate it with gstreamer, and libavcodec, and this, and that, oh and Real has to have their own implementation because they're not going to depend on any of those because they have their own..
19:21 < illiminable> dirac will soon be in ogg... i've been working with the dirac folks a bit ! :)
19:21 < MikeS> Arc: right. I think we agree with you on that - that doing all the ogg support stuff 10 times over is a bad idea. However, your vision for oggstream seems to be as an end-to-end solution, but what people actually seem to want is a '80%' solution, so they can write the other 20% to plug it in to existing frameworks. Why isn't that the goal?
19:21 < Arc> MikeS, that is the goal.
19:22 < zaheerm> Arc: theres a dirac plugin in gstreamer
19:22 -!- kjoonlee [~kjoonlee@218.147.148.33] has joined #xiphmeet
19:22 < Arc> OggStream is generic.  it's small.  it fits with libogg2 quite nicely.  
19:22 < SebastianG> dirac ? wow ... how's decoder performance currently,  illiminable ?
19:22 < zaheerm> Arc: helix guys will not use another framework
19:22 < AndrewBachmann> ok Arc, I want to ask a simple question.. do you see OggStream as giving me a codec identifier, with which I go find the codec myself, or do you see it as "automatically" finding the codec for me?
19:22 < ozone> Arc: sure, and it won't fit with any of the existing media frameworks out there
19:22 < ozone> thus rendering itself to be doomed
19:22 < Arc> its the plugins which give it flexibility, and apps/frameworks can choose to use it at any level
19:22 < illiminable> not good ! I'm waiting for their 0.5 release before i continue, as there were a few api issues with the previous one
19:22 < kfish> Arc, a single API that allows generic media decode is not "simple" and sure as hell doesn't "fit within libogg2"
19:23 < MikeS> Arc: well, it doesn't seem to be. Your description makes it sound neither generic nor small. 
19:23 < kfish> however, it is quite feasible to build on top of libogg2 to make an API, or set of complementary APIs
19:23 < Arc> AndrewBachmann: how would an application know which codec it's looking at without detecting it first?
19:23 -!- Atamido [~Atamido@user-0ccsqgl.cable.mindspring.com] has joined #xiphmeet
19:24 < Arc> kfish: actually, it is.  and it' for encode/streaming/etc too. :-)
19:24 < zaheerm> Arc: my opinion is to push ppl oin each of these frameowrks' projects to make sure they have adequate ogg support..rather than creating a new one
19:24 < Arc> take a look at the OggStream wiki page, the application api
19:25 < Arc> all this is doing is processing data of different kinds between plugins. it's the standardisation of those plugins that's important
19:25 < ozone> Arc: you are rewriting an entire media framework
19:25 < AndrewBachmann> Arc I don't understand your response... is it the first or the second thing I mentioned?
19:25 < illiminable> i agree with zaheerm... since most things will want to support more than just ogg, so using the same framework as they'll use for their other types will stop them needing to implement once for everythign else and once for ogg... which will mean many people just won't do it
19:25 < ozone> if you want to do it properly, you will be walking down the path of gstreamer/directshow
19:25 < MikeS> Arc: ok, can you answer this: why won't your 'oggstream' have the same problems as 'vorbisfile' does - that everyone who wants to integrate with basic platform services can't use it, because they all have different models of how various bits must interact?
19:25 < ozone> libxine is _really_ simple in comparison to gst/ds, and even it's more than complex enough
19:25 < zaheerm> Arc: maybe even having "xiph" helpers on each project's developer list :)
19:25 < illiminable> yeah... the whole 'circuit', 'source', 'codec' 'output' thing is basically directshow
19:26 < Arc> MikeS: flexibility in the i/o plugins.
19:26 < illiminable> arc: most of the frameworks have changable io plugins already
19:26 < Arc> illiminable: it's difficult not to be, when you look at it, without being overly rigid
19:27 < Arc> illiminable: so it's not very difficult for them to deploy a new one if the existing one isnt working for them
19:27 < ozone> Arc: feel free to write one, then tell us it's not difficult :)
19:27 < MikeS> Arc: this sounds an awful lot like "oh, that's merely a trivial matter of implementation, we can ignore it at this point" - and ignores the complexities that you actually find when you try to do this. Things like dshow and gstreamer have actually tackled these problems - and look how complex they are!
19:27 < Arc> ozone: I'm working on it. :-)
19:28 < illiminable> that's what i mean... it was a good idea thats been well tested... i don't see the need to reimplement it when directshow + gstreamer does this and covers all platforms pretty much
19:28 < ozone> Arc: put it this way, it's several orders of magnitude more complex than liboggz
19:28 < illiminable> And they are conceptually simple... but implementation wise deceptively complex
19:29 < AndrewBachmann> yeah, I want at most a single order of magnitude of complexity over liboggz :-)
19:29 < zaheerm> also these frameworks are unlikely to use any of the fancy features of the framework...they would use the lowest level possible
19:29 < ozone> ask kfish how easy it was to implement liboggz, and perhaps you'll get a slightly different answer than you expect
19:29 < j^> illiminable quicktime right now is the big missing platform, verry important for media production
19:29 < Arc> illiminable: can you give an example
19:29 < MikeS> Are we better off trying to have a more structured, more organised group trying to do platform-specific implementations, with (possibly) large amounts of shared code, along the lines of liboggz?
19:29 < zaheerm> these frameworks being gst/dshow
19:29 < ozone> j^: agreed
19:29 < ozone> MikeS: also agreed
19:29 < zaheerm> j^: there are vorbis plugins for quicktime right?
19:29 < AndrewBachmann> I think so MikeS
19:30 < AndrewBachmann> I've seen ogg-vorbis streams in quicktime
19:30 < zaheerm> im sure i played an ogg in itunes
19:30 < zaheerm> ogg/vorbis audio file i mean
19:30 < illiminable> Well... directshow is already done... and that does most of the hard stuff, like "sych", the graph architecture etc... but it's still taken me nearly a year to get an almost stable set of codecs. If i had to do the directshow backend too... i hate to think how long it would take
19:30 < AndrewBachmann> I mean, ".mov" file with ogg/vorbis stream [not a .mov file with vorbis stream]
19:31 < ozone> zaheerm: yeah, but i think MikeS means things beyond just vorbis decoding (e.g. encoding, theora support, etc)
19:32 < Arc> illiminable: are the directshow plugins ready for effects codecs?
19:32 < zaheerm> ozone: yah i know...didnt know what the plugin that provided vorbis gave...decoding i know, may have given encoding 
19:32 < MikeS> Maybe the first step is just to create an appropriate mailing list (for _ogg_, not for vorbis or theora or... - up till now, most of this sort of discussion has been on the theora list), and actually get all the relevent people to join and participate - discuss strategies, etc? 
19:32 < kfish> as for the approach of separate libraries -- liboggz wants libogg2 support, and we were discussing a companion libfishvideo library to abstract out video encoding/decoding, similar to libfishsound
19:33 < AndrewBachmann> that sounds good MikeS
19:33 < Arc> kfish: the major issue i have with the liboggz implementation is you assume audio/video.  there's no place for effects codecs and no place for non-av codecs
19:33 < ozone> MikeS: yep!
19:33 < ozone> i like the mailing list idea
19:33 < illiminable> arc: No... there is a rough and ready subtitle renderer... but the project is getting fairly large now... so i'm basically prioritising my time to things that are most used/most important/most wnated.
19:34 < Arc> illiminable: are your codecs drawn from seperate plugins, such that they can be dropped in like puzzle pieces and implemented without retooling your whole kit?
19:34 < illiminable> And for the moment, making the support for the AV 'good' i feel is more important than putting time towards something new
19:34 < MikeS> I think this gets back to our ongoing process issues - the core xiph group is (as far as I can tell) seen by outsiders as being insular and uninviting - and our unix backgrounds have tended to annoy away all the windows people.  So we don't have much in the way of discussion with all these people. Obviously, this is a problem.
19:34 < illiminable> arc: please explain ?
19:35 < AndrewBachmann> it seems okay to me MikeS, but I'm neither unix nor windows folk :-)
19:35 < kfish> MikeS, that sounds better than the usual random cross-posting :)
19:35 -!- SebastianG [~yay@c-180-198-23.bi.dial.de.ignite.net] has quit ["ChatZilla 0.8.31 [Mozilla rv:1.4/20030624]"]
19:35 < Arc> ok. say I want to implement a MNG overlay codec.  it would need to grab the output of a video codec, modify it, and output a new video stream
19:35 < Arc> how does this codec get integrated with the directshow system you've designed
19:35 < kfish> Arc, liboggz certainly doesn't make any assumptions about the data being audio/video -- quite the opposite
19:35 < ozone> arc: yes, that's exactly the way directshow/gst work
19:36 < MikeS> AndrewBachmann: well, it seems to be what happens - the (for example) windows developers get annoyed because we use cvs (well, now svn) and want patches sent... and we're not very tolerant of the fact that they just don't work that way. So we keep turning off people who would otherwise be happy to help. 
19:36 < AndrewBachmann> I think a MNG overlay code would output the overlay image, and then each platform is going to write an overlay plugin that can take overlay images (from any overlay codec) and overlay them
19:36 < Arc> kfish: when I speak "liboggz system", im refering to the combination of liboggz/libfishsound/libfishvideo
19:36 < zaheerm> Arc: frameworks allow u to plug compatible elements together
19:36 < illiminable> arc: basically derive a new filter from my abstract classes, setup the media types for input and output, write a transform function.
19:37 < zaheerm> Arc: so it would allow u to connect a theora encoder to an mpeg4 decoder, but itd allow u to connect a an audio source to an audio effect to a vorbsi encoder
19:37 < j^> Arc libfishsight is the plan i think
19:37 < Arc> illiminable: how is such a thing deployed. does it require modification to your code, is there a way the user can download such a thing automatically, etc
19:37 < DanielWH> I think it would be much better for the framework to run some hardware overlay function on some codec that was giving it, say, one video and five language overlays?
19:37 < MikeS> Arc: note that it's common for video hardware to directly support overlays of various types, so this is something you really DON'T want in common code.
19:38 -!- jack [~jack@i.cantcode.com] has joined #xiphmeet
19:38 < DanielWH> "the framework
19:38 < kfish> arc: as opposed to liboggz/libbollox for handling Ogg Bollox non-AV data format :)
19:38 < ozone> i move to have this discussion struck from the agenda, and run with mike's idea (set up a mailing list)
19:38 < DanielWH> meaning QuickTime or something.
19:38 < DanielWH> but the APIs for the existing codecs are depressingly non-uniform.
19:38 < MikeS> kfish: Please do not invent a codec called Bollox. 
19:38 < Arc> hold on
19:38 < Arc> this isn't a decidion making meeting
19:38 < Arc> this is for brainstorming
19:38 < kfish> ok, the other item on the agenda was libogg2
19:39 < illiminable> Arc: Right now, no... but that's ust because i haven't been ready to commit to an api yet, but it really just needs a bit of code added to the demux to translate a start packet to a directshow media type. It was designed to allow this... but i haven't exposed it, because i don't want people to use it until i can be sure i have covered all the bases and i'm not going to create trouble for my self with versioning
19:39 < Arc> having a ogg/hyperfish/etc mailing list is all well and good but we're not here to make decidions about whats going to happen, but share information and ideas with eachother
19:40 < DanielWH> good idea. new api with better documentation and crystal clear memory management semantics sounds like a good idea to me.
19:40 < AndrewBachmann> it might be a good idea for people from different frameworks to post their desires on the wiki?
19:40 < Arc> here's what I want to see
19:40 < DanielWH> libogg has all sorts of strange do-this invalidate-that things that make using it w/o segfault hard.
19:41 < AndrewBachmann> true DanielWH
19:41 < Arc> when it's time to implement Dirac, we have one (1) plugin written for it.  cross compatable. illiminable's directshow uses it, gstreamer uses, xmms uses it, mplayer/xine use it..
19:41 < illiminable> I can only speak for myself... but i probably won't be using this new oggstream thing... since i've basically already done this work, and in a language that's more windows friendly, ie C++ / .NET langauges
19:41 < DanielWH> so experimenting is hard, and you just have to painstakingly copy the order of operations from vorbis-example-program.c
19:41 < MikeS> yeah. libogg is good for two things: encoding, and decoding, and doing it fast. It's not developer-friendly, and it's a real pain for doing more complex things like editing files.
19:41 < kfish> DanielWH, which for example are exactly the kinds of things liboggz prevents the user from doing
19:41 < DanielWH> yes
19:41 < AndrewBachmann> or seeking!
19:41 < DanielWH> I like liboggz.
19:42 < AndrewBachmann> ditto
19:42 < DanielWH> if we rewrote it with the words Xiph and Different Licence.txt it would be far more acceptable to the Xiph community, if I understand correctly.
19:42 < Arc> I believe the functionality of liboggz belongs in libogg2.
19:43 < kfish> liboggz? it's under the same license as xiph stuff, just different copyright holder
19:43 < zaheerm> Arc: to do a cross compatile dirac plugin will be difficult..each framework just wraps libdirac and its done
19:43 < MikeS> DanielWH: I think the Xiph community is actually quite happy with liboggz. That said, we'd love to have it as a more official part of our software. What's the license on it
19:43 < illiminable> the problem with "cross-compatable" is although C and C++ are cross-compatable... the coders on the platforms have difference wants... a C library may be cool for *nix... but very few windows programmers use C... almost all app programming on windows has been object oriented for a long time
19:43 < MikeS> ?
19:43 < Arc> kfish: that's asking for a dual-copyright if integrating with libogg2
19:43 < MikeS> oh, kfish answered that
19:44 < Arc> kfish, also, is liboggz built to support discontinuous bitstreams
19:44 < DanielWH> I enjoyed writing Python wrappers that went through a C++ wrapper I also wrote, and wound up liking the C++ wrapper at least as much.
19:44 < DanielWH> of libshout
19:45 < kfish> Arc, liboggz certainly supports metadata streams :)
19:45 < AndrewBachmann> I think anything that oggz does should also be supported by oggstream somehow
19:45 < Arc> kfish: but does it understand their unique granulepos handling in regards to seeking/streaming
19:45 < kfish> Arc, it correctly handles the ogg granluepos mux semantics
19:45 < zaheerm> p[ardon my ignorance but what do you mean by discontinuoys bitstreams
19:45 < MikeS> illiminable: I think that's something we can talk through on the lists. Whether C++ is acceptable, or if C wrappers of C++ code is acceptable, etc. The more code we can share, the better...
19:46 < Arc> zaheerm: continuous bitstream is one which has one piece directly after another, ie, audio and video
19:46 < Arc> discontinuous, for example, would be a subtitle format where each packet starts irregularly and has variable duration, prehaps even overlapping
19:46 < zaheerm> MikeS: C++ wrapping C is cleaner than the other way
19:46 < zaheerm> Arc: understood
19:47 < kfish> ok, who can set up ogg-devel?
19:47 < illiminable> mikes: i think that's one of the things that has made it scary for windows programmers, is all the libraries are C. Even C++ is getting used les for apps in favour of .NET, this will be moreso on the next version of windows where the entire API will be managed code.
19:48 < kfish> ogg-dev@xiph.org i mean
19:48 < zaheerm> illiminable: then the ideal situation is if there was a C library and a C# library with a C++, python, perl wrapper of the C library
19:48 < Arc> zaheerm: and who is writting all these?
19:49 < zaheerm> Arc: no idea im just saying the ideal situation
19:49 < illiminable> But i mean you get to a point where you have several levels of nesting... in a lot of cases, it's just as easy to write it in C++ as it is to wrap and handle marshalling.
19:49 < Arc> how about like we have now.. C library with C++ wrapper
19:50 < Arc> we already have a python layer, py-ogg2.
19:50 < Arc> oh kfish py-ogg2 is a really good way of seeing how things work in libogg2 before docs are written. 
19:50 < Arc> we should have libogg2 docs by the end of the month
19:51 < zaheerm> illiminable: u just said that the windows ppl will use .net anyway in a few years...so writing an official .net ogg library would be  ideal
19:51 < kfish> arc: that would be great
19:51 < zaheerm> illiminable: theres already a c++ wrapper as Arc said
19:52 < illiminable> zaheerm: It's already underway ! But like with other things, i want to stabilise apis before i expose them to the masses.
19:52 < Arc> ok I want to share my vision now that things have died down a bit
19:52 < illiminable> And like i said... i've already written all this code already, so i'm not seeing any incentive for me to do it all again with another API
19:53 < kfish> arc: i visited monty recently (with ozone) and we discussed making libogg2 backwards compatible to libogg -- are you up for coding that?
19:53 < Arc> personally, and this isn't ment to offend anyone, I could care less about non-Ogg formats.  xine/mplayer/gstreamer/etc serve a purpose, but they're not part of what im concerned about
19:54 < Arc> kfish: i don't think that's possible.  see the work I did to port theora for an example
19:54 < kfish> arc: monty agreed and we discussed the implementation strategy, i'm just looking for someone who knows ogg2 internals well enough to help carry it through
19:54 < Arc> I care about making Ogg codecs easily deployable, that being, when we want to add a new codec we do so by compiling it and adding it to an autodownload list (along with license, etc)
19:55 < illiminable> This vision is really only a few months away on windows arc :) ie auto-download etc.
19:55 < Arc> kfish: I don't believe it can be done.  you would have to explain how such a thing is possible...
19:55 < Arc> illiminable: yes but that is windows.
19:56 < kfish> ok, i'll post to ogg-dev about it, as soon as MikeS sets up the mailing list ;-)
19:56 < zaheerm> Arc: the point lots of ppl here wer emaking is that the frameworks which are used 90% of the time by app writers etc. wont use the high level features of such a framework....
19:56 < ozone> would be similar on the mac if a proper quicktime plugin was implemented
19:56 < illiminable> true... just a mere 90% of computer users :)
19:56 < Arc> that's not macosx (quicktime) or linux (gstreamer/mplayer/xine/etc)
19:56 < ozone> as for unix, choose a media framework and let it do it for you
19:56 < MikeS> kfish: I can't. I'll get ralph to, or someone else who can, as soon as possible.
19:56 < kfish> MikeS, ok :) i'll go get some coffee anyway ...
19:56 < DanielWH> ogg2 and ogg1 depending on how new the code is, with a discriminator in the struct to allow them to be muxed together? is that what you mean?
19:57 < Arc> illiminable: i'm not devaluing their accessability to this, but it's just windows.  it's not macosx, it's not gnu/linux
19:57 < ozone> MikeS: schweet, thanks
19:57 < kfish> DanielWH, no, the format is the same, just api cleanup really
19:57 < MikeS> kfish: bring me one, too! :-)
19:58 < MikeS> I'll send out an email to the lists I can think of when it's set up, and please invite anyone else who might be interested to join!
19:58 < zaheerm> Arc: i think what will happen is that you will have to write the plugins for the frameworks directx, gstreamer, quicktime, helix etc. for ppl to even think of using this api
19:58 < Arc> zaheerm: what I've been expressing is that those features that 90% of the time wouldn't be used are seperate plugins, not part of the core
19:58 < illiminable> arc: true... but all it takes is one person to take it by the balls and just get on with it :)
19:58 < MikeS> Arc: yes, and windows is a critical platform for us. Absolutely critical, regardless of whatever pseudo-political viewpoints you have.
19:59 < Arc> MikeS: and again I'm not discounting Windows, but we certainly shouldn't concentrate on it as our core offering.  we'd loose our base within the free software community, which is shakey at best
19:59 < Arc> Xiph is not seen as core, it's seen as "another one of those groups"
19:59 < illiminable> mikes: yes... regardless of what people think about windows... it's the one platform that .ogg is not well known on... and it's the biggest... you're preching to the converted on *nix
20:00 < MikeS> Of course, we have no intention of concentrating on it as as _sole_ implementation target, but it's crucial to our long-term success.
20:00 < MikeS> That's why we all love illiminable :-)
20:00 < Arc> illiminable: I disagree.  Linux users are not "converted", a vast majority if them continue to use mp3 and divx.
20:00 < zaheerm> Arc: thats due to existing media
20:00 < kfish> Arc, yeah, but at least all the media software on linux already supports ogg
20:00 < kfish> ALL OF IT
20:01 < zaheerm> Arc: and hardware mp3 players being prevalent....
20:01 < MikeS> kfish: untrue. My copy of mpg123 won't play vorbis very well.
20:01 < illiminable> Arc: I think the bigger question is why... i'd contend it's because most of these files were encoded on windows
20:01 < Arc> kfish: not all. some. and most only supports Ogg Vorbis.
20:01 < kfish> MikeS, :-P
20:01 < illiminable> And these are the preferred types to use on windows.
20:01 < Arc> try sending xmms a chained vorbis/speex file and you'll see the problem
20:01 < Arc> let me give you an example of where oggstream is going to come in use:
20:01 < Arc> Xinloe.
20:02 < Arc> I have implemented this damned piece of code more times than I can count, now.  The code to detect Ogg codecs and parse granulepos for seeking/etc
20:02 < ozone> Arc: that's because you don't use a media framework :)
20:02 < Arc> it's all in Python, using py-ogg2, and can now properly display a stream (muxed/chained) in it's various components and lengths
20:02 < Arc> ozone: any generic media framework is not going to expose information about Ogg.
20:02 < kfish> arc: ok, so you're in the same situation i was two years ago before i started liboggz/libannodex hacking :)
20:02 < zaheerm> Arc: GStreamer, xine, vlc, mplayer, helix player all play ogg files (at the bare minimum both theora and vorbis)...in the case of gstreamer theora, vorbis, flac, speex etc. inside ogg can be decoded and encoded 
20:03 < ozone> Arc: err, yeah they will
20:03 < Arc> I'm not talking about playing Ogg files.  I'm talking about editing them, moving them around, streaming them
20:03 < illiminable> somedirectshowfilter->QueryInterface(GIVE_ME_OGG_INFO);
20:03 < ozone> yeah, media frameworks do those things too
20:03 < Arc> ozone: really?  I'm going to be able to grab Vorbis packets from gstreamer to crop and recombine a stream?
20:03 < zaheerm> Arc: why not...try using marlin
20:03 < DanielWH> crop vorbis?
20:04 < kfish> Arc, out of the ogg demux, sure
20:04 < kfish> that's the whole point of separate demux and decode -- you can do stuff like that
20:04 < ozone> Arc: err, yeah
20:04 < kfish> and then you can route it through a framework with effects and editing and stuff
20:04 < ozone> what do you think all the numerous video editors on windows/mac are written with?  all their own code from scratch?
20:04 < kfish> and oh lookie -- the frameworks already exist!
20:04 < zaheerm> ARc: gstreamer can give u access to the raw vorbis u need if u want it
20:05 < Arc> ozone: those editors work on decoded information.
20:05 < Arc> I dont want to decode then re-encode, I want to use the information as it is but repack it
20:05 < illiminable> directshow even has a whole buch of editing services interfaces... for advanced editing (and i haven't had the time to play with)
20:05 < kfish> Arc, so you want to do compressed-domain effects?
20:05 < Arc> amoung other things, yes
20:05 < zaheerm> Arc: gst-launch-0.8 filesrc location=blah.ogg ! oggdemux ! vorbisdec ! yourelementhere ! oggmux ! filesink location=newfile.ogg
20:05 < kfish> Arc, that's nice, I used to work on compressed domain mp3 stuff a few years ago
20:06 < zaheerm> sorry remove vorbisdec
20:06 < zaheerm> if u want the vorbis frames
20:06 < zaheerm> replace vorbisdec with audio/x-vorbis as the filtercaps...
20:06 < kfish> Arc, until we realised it was a waste of time really, and inflexible
20:07 < zaheerm> kfish: but preserves encoded quality
20:07 < illiminable> arc: What pumps out of my demux is ogg packets... you can connect whatever you want to it and use the packets just like you were using libogg/z
20:07 < kfish> zaheerm, sure, it's ok if all you're doing is cut/paste editing :)
20:07 < zaheerm> kfish: yah
20:07 < Arc> illiminable: you mean ogg pages, right?
20:08 < illiminable> no packets... but i am going to write a version with pages... which makes certain operations easier
20:08 < MikeS> Arc: I doubt he does; it wouldn't be demuxing if it were outputting pages
20:08 < zaheerm> Arc: what we are trying to say is media frameworks give you a whole load of control as to what you want...and have been doing for ages
20:08 < ozone> Arc: a proper media framework will permit what you want to do
20:09 < ozone> in the case of directshow, need to write some code so that (as illiminable said), it pumps out ogg pages rather than packets
20:09 < AndrewBachmann> my demux demuxs to packets
20:09 < Arc> and which one can be supported by Xiph (ie, by default does not include any patented systems or codecs)
20:09 < ozone> an ogg muxer can just take those pages on an input pin and remux them without looking at what's inside
20:09 < AndrewBachmann> I think I did pages at one point but it just didn't work
20:09 < Arc> oh and, let's add, doesn't encourage the use of
20:10 < zaheerm> Arc: look at how gstreamer is packaged in fedora
20:10 < Arc> zaheerm: that's how its packaged. I'm talking about default.
20:10 < kfish> liboggz demuxes to packets or pages as desired ...
20:10 < zaheerm> Arc: also as of gstreamer 0.9, the plugins tarball is going to be split into compeletely free tarball and "suspect" tarball
20:11 -!- DanielWH_ [~chatzilla@m09105e42.tmodns.net] has joined #xiphmeet
20:11 < zaheerm> Arc: gstreamer itself comes with no codecs...gst-plugins package is the one containing everything, and its being split up to free and not necessarily free
20:11 < zaheerm> so xiph can support gstreamer
20:12 < kfish> that would be a great way to go!
20:12 < DanielWH_> bye now
20:12 < Arc> kfish: Monty had a plan for deploying libogg2.  it included an infrastructure release, OggFile, and a complete "everything from this point on is libogg2"
20:12 < kfish> later DanielWH!
20:12 -!- DanielWH_ [~chatzilla@m09105e42.tmodns.net] has left #xiphmeet []
20:12 < zaheerm> gstreamer also has excellent python bindings
20:12 < kfish> Arc, yeah, thankfully the new plans are more realistic though :)
20:12 < Arc> what I would like to talk with you about is integrating the functionality of liboggz with libogg2 so to remove a seperate dependency layer, since it's pretty much required for working with Ogg
20:13 < Arc> kfish: I still don't see how you're going to provide backward compatability
20:13 < Arc> I would have to see how the different objects and function calls worked together
20:13 < Arc> if it were possible and I understood it, yes, I could do it.
20:13 < kfish> ie. gradual transition to libogg2, and a suite of complementary libraries for demux/decode and encode/mux
20:13 < Arc> (at this point, I'm probobally more familiar with the code than Monty is since last I talked to him he had said that he was going to have to relearn it all)
20:14 < kfish> Arc, ok, so the first step is to rename the conflicting type names, ie. ogg_sparse_packet in libogg2
20:14 < kfish> instead of conflicting witht the ogg_packet type in libogg
20:14 < Arc> kfish: eep, you're killing me.. what?
20:14 < kfish> it's a symbol rename arc, that step isn't so hard ...
20:15 < Arc> ok go on
20:15 < kfish> and the next step is to put in support for libogg ogg_packet and related function calls
20:15 < kfish> through a non-zerocopy compatability layer
20:15 < Arc> (libtheora and py-ogg2 aren't things i intended to have to change again)
20:15 < kfish> just a bit of search and replace :)
20:15 < Arc> ok except things work differently
20:16 < kfish> yeah, so the function calls and types which clash are to be renamed in libogg2
20:16 < Arc> im not sure if monty explained this, but the buffers aren't there anymore. the app cant grab them. and there's no clean "do this only when the application requests it" code.
20:16  * illiminable is glad about now he wrote his own demux :)
20:16 < zaheerm> illiminable: :)
20:17 < Arc> so in other words, libogg2 is going to have to work overtime to keep those buffers working.
20:17 < AndrewBachmann> it'd be nice to have some links to all the framework ogg code
20:17 < MikeS> illiminable: libogg2 is only this complex because it needs to be ridiculously memory-efficient. Different constraints... ;-)
20:17 < Arc> zerocopy is also faster.
20:17 < Arc> its not complex. it's really not. its actually quite simple.
20:17 < Arc> just dont look under the hood.
20:17 < AndrewBachmann> zerocopy is incompatible with all frameworks, I suspect
20:18 < kfish> the compatability layer doesn't need to be so memory-efficient -- it's for compatability in existing situations, like frameworks
20:18 < AndrewBachmann> one-copy could be compatible
20:18 < kfish> yeah, so that's what we'll work towards
20:19 < kfish> so that we can have a smooth transition to libogg2 support
20:19 < kfish> and encourage an optimisation path
20:19 < kfish> without breaking existing apps
20:19 < Arc> kfish: libogg1 and libogg2 can exist side by side on the same system
20:19 < Arc> so how is this helping matters?
20:19 < Arc> the only thing we haven't done is allow theora/vorbis/etc to be compiled for each
20:20 < MikeS> kfish: right. zerocopy is nice for some cases, painful for others, and essential for some (like hardware mp3 players that have almost no memory)
20:20 < kfish> as soon as you fix the symbol clashes, libogg1 and libogg2 will be able to be linked into the same app, which is currently not possible
20:20 < Arc> that doesn't matter since you cant exchange the objects
20:20 < kfish> and once libogg2 is backwards compatible with libogg1, we can deprecate libogg1 and just encourage libogg2 installation
20:20 < illiminable> mikes: maybe... but my core C++ library isn't a memory hog... i doubt it's much less efficient memory wise.
20:21 < illiminable> It's only the directshow parts that take liberties with memory allocation
20:21 < Arc> kfish: i dont see how this helps matters at all.  an app either supports libogg1 or libogg2.  there's no interoperation between ogg_page objects from the two versions
20:22 < Arc> the codec is what's important.
20:22 < kfish> Arc, indeed, that's exactly the problem
20:22 < Arc> kfish: that's not a problem tho
20:22 < j^> Arc it helps installing libogg2
20:22 < Arc> a single app is either going to use libogg1 OR libogg2.  there's no reason to support both at the same time
20:22 < j^> it helps porting and app, since libogg2 is installed by default
20:22 < MikeS> illiminable: I wasn't suggesting it was - libogg2 was designed for situation where having one copy of the data for the original page(s), and one copy for the demuxed packet(s), wasted too much memory. I doubt you avoid that case; it's pretty painful (because you end up having the packets be discontinuous in memory)
20:23 < kfish> Arc, it becomes a problem as soon as you encounter frameworks where different plugins use different libraries
20:23 < kfish> or, when you want to make a theora/speex player for example
20:23 < kfish> or something that supports both tremor and speex
20:23 < illiminable> mikes: yes, the original parsed packet is passed through, it parses directly to packets and doesn't copy unless you tell it to.
20:23 < Arc> kfish, speex doesnt care if its libogg1 or libogg2.
20:24 < kfish> in any case, the lack of compatability is an existing design problem with a clear path to resolution
20:24 < Arc> vorbis is the only codec needing conversion
20:24 < j^> Arc in python its possible to import ogg and ogg2, right now i have some scripts that are using both
20:25 < Arc> which raises the issue again that we have 3rd party frameworks using Ogg but without any interaction with us.  to deploy, we have to go through them
20:25 < kfish> libspeex provides/expects contiguous buffers
20:25 < illiminable> mikes: anyway... pretty much irrelevant to the discussion at hand ! :)
20:25 < MikeS> illiminable: true. 
20:25 < Arc> kfish: exactly, and you have to copy this buffer with libogg2's bitpacker.
20:25 < Arc> there's no way around this that either jmspeex or monty could find
20:26 < zaheerm> Arc: thats why i suggested if xiph have xiph-friendly ppl in these projects its easier to communicate through
20:26 < kfish> Arc, ok, it's not "an issue", it's the reason the rest of us have been working to integrate ogg framing and codecs in existing frameworks?
20:26 < kfish> it's an opportunity :)
20:27 < Arc> zaheerm: I am looking at it from a different approach.  We need to reconstitute Xiph with new developers and get some lifeblood going, because we're sliding, bigtime.
20:27 < kfish> Arc, well there's certainly some vapourware floating around ;-)
20:27 < zaheerm> Arc: maybe its time to tell the different projects that you want to work with them, but would like their help too
20:28 < Arc> in my view, these seperate implementations have evolved out of Xiph, which really should have done this in the first place, not having an Ogg framework in place.
20:28 < kfish> Arc, gstreamer should have come out of xiph?
20:29 < Arc> so gstreamer, mplayer, xine, videolan, ffmpeg, quicktime, and directshow all implemented seperatly
20:29 < kfish> anyway, i wholly agree that we should encourage more formal co-operation with framework developers
20:29 < Arc> kfish: no.  gstreamer does what gstreamer does.  it's not Xiph
20:29 < illiminable> Xiph should focus on what it's good at... and leave the frameworks to the dedicated projects
20:29 -!- DanielWH [~chatzilla@m09105e42.tmodns.net] has quit [Connection timed out]
20:29 < zaheerm> Arc: I dont thik thats the right view to have...yes they should have all been able to just cut and patse good quality code and just connect it together to consytitute the relevant plugins
20:30 < illiminable> and work together to mutual benefit
20:30 < Arc> zaheerm: no, not cut and paste. we should have had a framework in place for them to take verbatim
20:30 < AndrewBachmann> i think that we should start from: "look at all the people who have written seek algorithms for ogg -- why?"
20:30 < Arc> that's where the idea of i/o plugins come in
20:30 < zaheerm> Arc: but thinking that these frameworks would have wrapped another over-complicated framework is not the right way of thinking...
20:31 < Arc> ok, take gstreamer for example. there could be a specific "gstreamer" input/output plugin which is built to glue oggstream and gstreamer together
20:31 < kfish> Arc, yes, I/O plugins, and their interaction with seeking, are the most important parts of liboggz
20:31 < kfish> and it's crucial that frameworks can take advantage of these
20:31 < Arc> kfish: i agree.
20:31 < Arc> I'd love to pull liboggz as part of this
20:32 < Arc> I want oggstream to be a toolkit that frameworks can use, to whatever level they want or need
20:32 < Arc> have it distributed without any plugins beyond prehaps file, http, and a general callback mechanism
20:33 < zaheerm> Arc: explain to me this I/O plugin thing
20:33 < illiminable> One of the things is... it's hard to be everything to everybody... all the frameworks have their quirks... and sometimes being forced to particular api is really painful... the framewokrs have their own public apis so it doesn't matter what happens inside
20:33 < Arc> zaheerm: see http://wiki.xiph.org/OggStream
20:34 < Arc> illiminable: exactly. thats why they implement their own OggStream plugins to interoperate with themselves.
20:34 < kfish> so, a convenience library needs to be able to interact with the I/O plugins in a framework
20:34 < kfish> for example, directshow, or gstreamer, has i/o plugins
20:34 < Arc> yes.
20:34 < zaheerm> Arc: I think toolkit is a better word than framework...
20:34 < kfish> so, an ogg library needs a layer to interact nicely with that, ie. http://www.annodex.net/software/liboggz/html/oggz__io_8h.html
20:34 < Arc> ok, then call it toolkit.
20:34 < Arc> Monty called this a framework.
20:34 -!- K`rai [~xor@m195-243.dsl.tsoft.com] has joined #xiphmeet
20:34 < AndrewBachmann> Arc, each framework wants to have an OggStream plugin, and a separate Vorbis plugin, and a separate Theora plugin, etc.
20:35 < Arc> this is all basically Monty's idea for OggFile.  I'm just using a different name because 1) I hate the way VorbisFile is designed, no offense to Monty, and 2) because I'm not going to steal his name for it
20:35 < Arc> AndrewBachmann: why would each framework want a seperate Vorbis plugin
20:35 < zaheerm> Arc: what if gstreamer wanted to analyse raw vorbis audio only for example
20:35 < Arc> that's universal
20:35 < Arc> zaheerm: then gstreamer requests "vorbis" data vs "pcm"
20:36 < Arc> OggStream doesn't know what "pcm" is - that's an important distinction.
20:36 < AndrewBachmann> because if you want to put vorbis into quicktime container, you want a separate vorbis plugin
20:36 < zaheerm> Arc: no, this vorbis audio did not come in an ogg container
20:36 < AndrewBachmann> then the quicktime plugin connects to the vorbis plugin
20:36 < Arc> it only knows that it's the labeled type and it has these values and, by golly, these other pieces of software sure seem to know what they're doing with it
20:36 < illiminable> arc: I'm just saying trying to have a common api, isn't always the best approach because you end up trying to hack around it when your framework requires it... most of the proposed oggstream stuff is in the frameworks already... so writing another layer to duplicate this doesn't make much sense
20:36 < Arc> zaheerm: ok then you SUBMIT vorbis data from the input plugin ;-)
20:37 < Arc> illiminable: but those frameworks dont support Ogg.
20:37 < kfish> Arc, huh?
20:37 < illiminable> They don't need to they are generic... they support everything if you implement it
20:38 < Arc> illiminable: big 'if'
20:38 < AndrewBachmann> tiny if
20:38 < Arc> possible 'if', but big 'if'
20:38 < kfish> Arc, which is exactly what we're doing!
20:38 < zaheerm> yes
20:38 < AndrewBachmann> the lone if
20:38 < Arc> ok I'm confused now lol
20:38 < kfish> illiminable has been implementing directshow support
20:39 < Arc> ok I was refering to "what IF someone writes a mpeg codec plugin"
20:39 < zaheerm> BBB, wtay, thomasvs, Company have been doing ogg, vorbis, theora, speex, flac etc. plugins in gstreamer
20:39 < kfish> then ...
20:39 < illiminable> All the pluggable elements are part of the framework... you just implement these interfaces with your codec/format specific code
20:39 < kfish> ozone and i and a bunch of others have been working on xine support
20:39 < AndrewBachmann> ok, here's a good question, how do you expect to handle mpeg4 in ogg.. should xiph write a codec plugin for this?
20:39 < kfish> acolwell's been working on heli
20:39 < kfish> x
20:39 < AndrewBachmann> all the frameworks already have mpeg4 plugins
20:39 < Arc> AndrewBachmann: someone could, but god I hope not
20:40 < illiminable> Can be done in ogm already
20:40 < kfish> vlc, mplayer, quicktime ........
20:40 < Arc> but that's the issue of having Xiph host the plugin download. have it be open, but list the license and include information about it
20:40 < illiminable> and because ogm chose a standardised initial packet... it never requires demux changes for new codecs
20:40 < AndrewBachmann> ogm files are ogg files, so what is the intended plan of support for them?
20:41 < Arc> AndrewBachmann: if someone writes support, it'll work. if not, well, it wont.
20:41 < Arc> we're volunteers, after all.
20:41 < illiminable> it seems officially none... but my filters already do
20:41 < AndrewBachmann> what does "writes support" entail, in your vision?
20:41 < kfish> so really, the current approach of xiph publishing re-usable libraries for demux and each decode has worked for allowing people to put support into all the frameworks
20:41 < Arc> AndrewBachmann: writtin a plugin.
20:41 < AndrewBachmann> a xiph-plugin?
20:41 < zaheerm> Arc: linux distributions can usually emerge, apt-get, yum install newer versions of these plugins for gstreamer...if the linux distribution is setup right, it will even tell you when certain packages need updating
20:42 < Arc> see, in one example, I plan on writting a OggMP3 codec.  It will ONLY accept mp3 as an input, no encoding, nor will the decoder output anything but mp3, but that's enough for players who already support mp3
20:42 < Arc> zaheerm: please read the wiki.  you're asking questions already on it
20:42 < Arc> see /OggStream in the "Auto Update" section
20:42 < AndrewBachmann> well, I've got to go
20:42 < AndrewBachmann> I'll try putting what I'd like to see in oggstream someplace in the wiki
20:43 < Arc> if the distros package it right, the "Auto Update" would run through their system
20:43 < zaheerm> Arc: yes, what i am trying to get at is why the duplication fo effort
20:43 < Arc> AndrewBachmann: feel free also to use the Talk: (discussion) page
20:43 < zaheerm> into creating a liboggstream
20:43 < illiminable> oggmp3 ? I'm not seeing your point (and ogm does mp3 already too!)
20:43 < zaheerm> that does what the frameworks do, but just for ogg
20:44 < Arc> illiminable: Ogg MP3 so that MP3 can be streamed without transcoding along with Vorbis over Icecast
20:44 < illiminable> hmmm... if icecast added ogm header support they could support any audio or video codec in one hit.
20:44 < Arc> zaheerm: because with this only one set of codec plugins must be written. well, two considering Windows
20:44 < Arc> illiminable: yes but ogm is dead.
20:44 < zaheerm> Arc: it can be already...use the tee element in gstreamer
20:45 < Arc> zaheerm: but that's gstreamer. not mplayer xine quicktime libavcodec etc etc
20:45 < kfish> Arc, yes, some of those are simply player backends
20:45 < Arc> i know.
20:45 < zaheerm> Arc: gst-launch-0.8 alsasrc ! tee name=tee0 ! rawvorbisenc ! oggmux ! shout2send { tee0.src%d ! queue ! lame ! shout2send }
20:45 < Arc> and some players dont use frameworks
20:45 < kfish> whereas the full frameworks allow the kind of flexibility you're after
20:46 < kfish> no, they use xiph libraries
20:46 < Arc> kfish: I'm personally not in favor of media frameworks like gstreamer.
20:46 < illiminable> arc: why should it be dead ? It doesn't need to be an ogm file... but the header is the core of ogm.. and that one header supports all common audio and video types in one hit... and not the random codec at a time implementation the other ciph codecs use
20:46 < Arc> and some media players simply don't play that game
20:46 < illiminable> ciph=xiph
20:46 < kfish> well, xiph.org has a community responsibility to be in favour of gstreamer etc.
20:46 < Arc> illiminable: because I personally don't want to encourage non-free codecs in Ogg.
20:46 < Arc> but you're free to implement something. it's wide open
20:46 < illiminable> but yo just said mp3/icecast ?
20:47 < kfish> and gstreamer is a great supporter of xiph
20:47 < Arc> kfish: why community responsibility? kde has their own system, mplayer theirs. whats special about gstreamer
20:47 < zaheerm> Arc: to get ogg and hence free codecs used everywhere...u have to have the frameworks that are already commonplace support them well
20:47 < kfish> and mplayer, etc.
20:47 < Arc> kfish: that's great. but that doesn't mean we're going to play favorites
20:47 < Arc> and personally, when I'm coding something Ogg-only in Python, I don't want to have to open gstreamer
20:47 < kfish> not just gstreamer -- the point is that we must play nicely with frameworks
20:47 < illiminable> And the fact is a lot of people like vorbis, but still prefer their other video codecs for now... you're better to get them half in, than using matroska or avi
20:48 < kfish> because they already exist and work well, and are widely deployed, and do the job properly
20:48 < Arc> illiminable: ok then you should take this on as your project.
20:48 < zaheerm> Arc: use gst-python works well, and u can use it for ogg-only stuff
20:48 < Arc> kfish: there is nothing that is not playing well with frameworks that I'm working on
20:49 < Arc> zaheerm: it's overkill for what I use
20:49 -!- foolip [~philip@f42.ryd.student.liu.se] has quit [Remote closed the connection]
20:49 < Arc> if an app only does Ogg, there's no need for it
20:49 < zaheerm> Arc: then any framework is overkill for what u use, and u just need a libogg wrapper
20:49 < Arc> if they're doing something they need a framework for, great, use gstreamer
20:49 < kfish> Arc, it seems like you have a personal project to implement, which is the best way to start coding something useful
20:50 < zaheerm> Arc: and gstreamer is not overkill for most things...nokia and sony are using it in embedded devices like phones and camcorders
20:50 < illiminable> yeah sure you don't always need the frameworks... but that's the exception rather than the rules
20:50 < illiminable> -s
20:50 < Arc> I am implementing it.  Somehow, alot of people seem to have been confused, thinking that this meeting was to discuss wether my work was a good idea or not
20:51 < zaheerm> we were gonna talk about ideas of how we would like to see xiph int he future
20:51 < zaheerm> hence our input as to working closer with the frameworks
20:51 < illiminable> zaheerm: yes
20:51 < kfish> totally :)
20:51 < Arc> that's the how, not the what
20:51 < Arc> where is Xiph going to be Dec. 2005
20:52 < Arc> what is it going to look like, what is it going to represent to the community
20:52 < Arc> where is Ogg going to be.
20:52 < kfish> technically? better supported in players and frameworks
20:52 < zaheerm> and implementing an ogg specific framework is overkill for what the other frameworks want
20:52 < illiminable> zaheerm: agreed
20:52 < zaheerm> kfish: and encoders, transcoders, special effects stuff and anything multimedia really
20:53 < illiminable> DRM is something i'd like to talk about (I know it's unpopular) !
20:53 < kfish> zaheerm: sounds great!
20:53 < Arc> I'm seeing IceShare as a big boost to this, but it depends on the infrastructure
20:53 < Arc> illiminable: there's already Ogg DRM.  it failed.
20:53 < illiminable> where, why ?
20:54 < illiminable> why did it fail... it's not because of 'drm' generically... since everyone else seems to be hapilly drm'ing in their formats
20:54 < Arc> lol, me thinks ye don't read slasdot as ye should.
20:54 < Arc> illiminable: Ogg is free. DRM is in direct contrast to our goals.
20:54 < illiminable> No i prefer to get stuff done :)
20:55 < zaheerm> Arc: doesnt mean ppl shouldnt sell audio stuff in ogg formats
20:55 < Arc> no but DRM is something that just doesn't work
20:55 < illiminable> why ?
20:55 < Arc> especially not in the free world
20:55 < illiminable> The world is not free.
20:55 < illiminable> I think it's time to be realistic
20:55 < zaheerm> by not supporting drm, u dont care about other ppls copyrights on anything multimedia
20:56 < illiminable> Free is cool... but not everyone who has invested millions in something agrees !
20:56 < MikeS> Is this meeting still being even slightly productive?
20:56 < Arc> illiminable: hmm, with your views, I'd like to hear what draws you to Xiph
20:56 < Arc> illiminable: I'm refering to freedom.  when I talk of free cost, I call it gratis.
20:56 < ozone> MikeS: personally, i'm getting lunch in 10 minutes
20:57 < zaheerm> Arc: xiph is meant to be totally free..commercial ppl can use it, hobbyists can use it...all at no expense
20:57 < MikeS> ozone: I'm in the same time zone as you, so I was thinking more or less the same thing ;-)
20:57 < zaheerm> Arc: and no restrictions
20:57 < illiminable> And i've got to go video conference soon.
20:57 < Arc> MikeS, I think you came in with false expectations of what this meeting is for.  This is not a decidion making meeting, this is a discussion and brainstorming meeting
20:57 < zaheerm> and i need some sleep :)
20:57 < kfish> ok, well we've certainly decided to work closer with frameworks
20:57 < MikeS> Arc: my point was that it has degenerated into a bitching-about-DRM-session.
20:57 < kfish> and continue to build libraries that support that goal
20:58 < Arc> kfish: :-) no we've discussed how. this isnt about decidion making
20:58 < zaheerm> kfish: its decided or is it being pointed out that it would be a good idea
20:58 < illiminable> arc: Why am i here at xiph... because i think there are business opportunities surrounding it, and i'd like other people with the resources to recognise them.
20:59 < kfish> zaheerm, ooh, i think it's tabled as an proposal for further discussion towards a goal-oriented consensus forum!
20:59 < Arc> illiminable: http://www.sidespace.com/products/oggs/ is Ogg DRM
20:59 < zaheerm> btw one thing that would help frameworks....is if there was a way that vorbis would tell you what caps (sample rate, number channels) are supported at say bitrate 16000bps
21:00 < zaheerm> by vorbis i mean the vorbis library
21:01 < zaheerm> or even resample if you provide an incompatible caps audio stream
21:01 < kfish> zaheerm, could you flesh that idea out a bit more on vorbis-dev?
21:01 < MikeS> vorbisenc library, I assume you mean. Yeah, that would probably be useful. 
21:01 < zaheerm> kfish: will do
21:01 < zaheerm> MikeS: I assume it is potentially changable right?
21:01 < MikeS> design an API, send a proposal to the list?
21:01 < MikeS> zaheerm: the library? Of course. 
21:02 < zaheerm> MikeS: will do...just added to my todo list
21:02 < zaheerm> MikeS: no not the library, the encoder may become better and support higher sample rates at low bitrate?...hence an api would be better than just specifying in docs
21:03 < MikeS> zaheerm: obviously, this info exists in some form inside the library (otherwise it wouldn't know to reject things when it does...), so this is possible. It's just a matter of deciding how to present that information, and then implementing. Implementing wouldn't be entirely trivial (the data isn't in a terribly helpful form for figuring this out), but it wouldn't be too hard either.
21:03 < MikeS> zaheerm: I'm not sure what you're asking, then. 
21:03 < MikeS> zaheerm: because I thought we were both talking about adding things to the vorbisenc library.
21:04 < zaheerm> MikeS: i mean is it just set...and no new implementation of the vorbis encoding algorithm will change the capabilities at differing bitrates
21:05 < MikeS> oh, I see. 
21:05 < MikeS> Yeah, these thing can, and do, change. 
21:05 < zaheerm> MikeS: ok then having an api addition would be beneficial
21:06 < MikeS> For example, there are 3rd party libvorbis forks that provide much lower bitrates than normal libvorbis does - and those are likely to get adopted into libvorbis one day
21:06 < MikeS> Yes.
21:06 < MikeS> Any other matters, people?
21:06 < zaheerm> out of interest, in theora what happens in this regards?
21:07  * MikeS bangs his gavel and announces the meeting adjourned :-)
21:07 < Arc> um, MikeS.. again. this isn't that kind of meeting.
21:07 < Arc> but thanks for continually pushing for it to be so
21:07 < zaheerm> ie resolution and framerate
21:07 < MikeS> zaheerm: not sure. theora has 64 (?) fixed levels, but I don't know how they map to bitrates. People in #theora might be able to help.
21:07 < MikeS> Arc: fuck off, arc. It was a joke.
21:08 < Arc> MikeS: I'm frustrated at the kind of energy that was brought here.
21:08 < kfish> Arc, we're all happy free software hackers working towards a common goal
21:08 < zaheerm> Arc: i didnt mean to be hard on you...i was just putting my view as a framework developer what we would like to see
21:08 < ozone> being passionate is all good, unless you're a jedi
21:09 < Arc> we're all volunteers
21:09 < Arc> we work on what we work on
21:09 < illiminable> agreed... we're all just sharing our ideas
21:09 < zaheerm> yep
21:09 < Arc> the question is not what work gets done, because we're going to do whatever we do
21:09 < Arc> the question is how we can work together
21:09 < MikeS> Arc: why? It looks like we got a lot of the relevent people here (especially given the short notice!), and had a useful and productive discussion.
21:09 < illiminable> arc: agreed
21:09 < Arc> much of tonight has been "we shouldn't do this or that"
21:09 < Arc> negetive thinking
21:09 < zaheerm> ya id like to see theora get a new release out too :)
21:10 < Arc> I want to talk about how we can work together, collectivly, and see if a real working group can't be formed
21:10 < illiminable> arc: i don't think it's we shouldn't do this or that... everyones just got their own views on things
21:10 < Arc> MikeS: oh yes, useful people, and it's good that everyone showed up.
21:10 < zaheerm> and be better supported in windows for n00bs...fluendo's java applet is excellent but itd be nice if the main players could have auto codec downloads for xiph plugins
21:11 < illiminable> arc: i don't think anyone is saying don't do something if you want... just it may not be something everyone else is interested in
21:11 < zaheerm> illiminable: u said its happening soon for the ogg ones in WMP?
21:11 < derf_> zaheerm: Theora supports any resolution and any framerate at any bitrate... it'll just drop a ton of frames to keep up.
21:12 < derf_> The actual limits that avoid frame-dropping are content-dependent.
21:12 < zaheerm> derf_: ok...so is there recommended framerates for each resolution anywhere for each bitrate....or is there a formula to work that out
21:12 < illiminable> zaheerm: yes... i'm just focussing on getting the current stuff working... and making sure that as i add new codecs, that my api really is generic enough before i start trying to get people to build on it
21:13 < illiminable> I've written for speex, theora, flac, vorbis, cmml and dirac... and i'm getting more confident that it's pretty close now.
21:13 < derf_> zaheerm: It depends on if your scene has a lot of motion, complex textures or hard edges, etc.
21:14 < zaheerm> derf_: ok i get the picture...is there a decent way of testing....?
21:14 < zaheerm> it would be nice if lets say a transcoding app would recommend resolution/framerate for target bitrate
21:14 < derf_> zaheerm: Try something out... if it doesn't work, change it.
21:14 < zaheerm> for certain prerecorded scenes
21:15 < zaheerm> derf_: so currently trial and error, any stats output i can get from libtheoras encoder as to % dropped frames
21:16 -!- ozone [~pan068@c211-30-78-105.belrs2.nsw.optusnet.com.au] has left #xiphmeet []
21:17 < derf_> The encoder keeps a DropCount internally, but doesn't expose it anywhere.
21:17 < kjoonlee> (Pardon me, but is this being logged? Will logs be provided on the web?)
21:17 < Arc> kjoonlee: yes. see FishLogger 
21:18 < derf_> Hmm, actually that drop count is only for consecutive frames, so it gets reset the next time one is actually coded.
21:18 < zaheerm> oh ok
21:19 < zaheerm> so no way except by viewing the stream whether its ideal or not
21:19 < derf_> With current tools, that's correct.
21:19 -!- kjoonlee [~kjoonlee@218.147.148.33] has quit ["Leaving"]
21:19 < derf_> Ideally you could make a first pass to estimate the compressibility of the material.
21:21 < zaheerm> yah
21:22 < zaheerm> but that first pas sneeds ot know the number of dropped frames
21:22 < zaheerm> to estimate the compressibility
21:22 < derf_> Well, you could use a lot more information than that.
21:23 < derf_> i.e., look at coefficient distribution, motion vector bits, etc.
22:44 -!- Netsplit sterling.freenode.net <-> irc.freenode.net quits: K`rai
22:48 -!- j^ [~j@gw.bootlab.org] has quit [Read error: 113 (No route to host)]
22:50 -!- Netsplit over, joins: K`rai
--- Log closed Wed Nov 24 22:56:45 2004