From: <ya...@3i...> - 2001-09-18 10:55:30
|
Hi, I respect completly your license, but maybe we could agree ... I mean if you link directly on the OpenQuicktime library (without extracting some of the code, direct linking to the .so library), their is a plugin mechanism inside... For example, you could let the OQT library decompress the 3ivx data and receive raw frames directly in your quicktime demuxer ... I don't know if layers would be happy with that but user may be ;) Yann. On Tue, 18 September 2001, Heiko Schaefer wrote: > > > for VBR and 'ms0x55' for CBR) - I don't know anything for the moment > > > of the Xine codec plugin API but would it be possible to create a 3ivx > > > binary decoder plugin for your player with its own licence (I mean > > > free but binary only, see the xanim plugin licence on the 3ivx site, > > > www.3ivx.com) ? > > > > I'm not a lawyer or any sort of license zealot but xine-lib is (according > > to COPYING) under the GPL rather than the LGPL so I'm pretty sure that > > means this is right out. > > > > If Guenter wants ro release the next Xine under the LGPL, it /may/ be OK > > but I've never really understood ehat the LGPL considered a 'derrived > > work'. > > guenter himself can't decide to change the license that easily (even if > he'd like to), because xine contains lots of sources from other gpl'ed > projects. > > such is the nature of the gpl. curse or blessing ?! only time will tell. > > Heiko Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com |
From: <ya...@3i...> - 2001-09-20 09:53:08
|
On Wed, 19 September 2001, Guenter Bartsch wrote: > I have only very few quicktime test streams and it's very hard to implement > features you cannot tests - so sorry about that. Could you point me to some > more test streams? You could create some using Broadcast2000, OQTEncoder or XawTV as well ... ah, and of course Quicktime PRO ;) > the problem here (yep, you guessed it ;)) again is that I don't have any qt > test streams with mp3 audio. How do you handle ... http://www.3ivx.com/showcase.html quicktime files with 3ivx video and mp3 VBR audio. synchronization in openqt > for compressed audio formats? Most audio related functions like > quicktime_read_audio (...) require - specify "number of samples" - but > what happens here if the audio stream is compressed? I see ... you need to use all the QT atoms informations. This function is not usable for this. Basically, you will find in the quicktime header how much sample there are in a compressed chunk and so how much chunk you need to demux to get your wanted amount of samples ... > technically I don't see any problem here, perhaps it would be easier to > implement a generic "meta" plugin that implements the xanim plugin interface > and therefore technically enables all xanim plugins to be used by xine as well. could be a solution ... We're planning to create the same sort of gateway between OpenQuictime and Xanim. > So I conclude that 3ivx is proprietary software with a very restrictive > license. The license you wrote about are for codec (I mean encoder/decoder). What we (I'm also member of the 3ivx team) want to do is allow user to play 3ivx files on Linux. That's why we have a free xanim decoder plugin, but we have also all the equivalent of the test/plus/personal codec for OpenQuicktime. As I've seen that you've used OpenQuicktime to demux quicktime files, I think it could be a good idea to play 3ivx files directly in Xine. Don't worry about the 3ivx license ... for decoding, there is no problem ;) > As a free software developer you are certainly aware of the problems > that arise from the use of such proprietary software. Now the problem with > decoder plugins like w32codec or the proposed xanim-codec plugin is > that it gives users that are not aware of these licensing issues the > impression that using proprietary codecs like 3ivx and xine was in some > sense "ok". I guess therefore we should place some warning against the > use of these codecs on the xine homepage or the readme to prevent people > getting "trapped" in such non-free video formats. I agree to put this in an opensource encoder, but in my opinion it has nothing to do in a player. > Perhaps a better technical solution for the problem would be to implement > a small re-encoder tool that enables people to re-encode any proprietary > stream they may already have to an open video format such as mpeg 4 and > thus enable them to break free from the chains of proprietary software. I'm sorry I don't agree at all: - obliging people reencoding their stream to play them is a nonsence - MPEG-2 and 4 have open specifications but are full of patenting issues ... Basically, each time someone gives an encoder, he would have to pay royalties to the MPEG group ... - 3ivx is an MPEG-4v3 encoder ... so you're speaking about reencoding MPEG-4 in MPEG-4 =) In MPEG, the differences are always in the encoder, the decoder is aways the same ... I mean, you could write a MPEG-4v3 decoder and directly decode 3ivx stream without any 3ivx code... > Please tell me if you intend to implement any plugins/tools so I can > take a note of it so no work is done twice. What I would like is to be able to take any quicktime files and play it in Xine. As I'm particulary interested in playing 3ivx/MP3 files, I would like to change the demuxer to be able to use the OpenQuicktime plugins (or eventually the Xanim plugins) when no native decoder is available in Xine ... I could of course help you with MP3 as well ... In this particular case, I think we should only demux the compressed chunks and send them to your Xine mp3 decoder. Yann. Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com |
From: Heiko S. <hsc...@ft...> - 2001-09-21 10:57:52
|
Hi Yann, > > So I conclude that 3ivx is proprietary software with a very restrictive > > license. > > The license you wrote about are for codec (I mean encoder/decoder). > What we (I'm also member of the 3ivx team) want to do is allow user to > play 3ivx files on Linux. That's why we have a free xanim decoder > plugin, but we have also all the equivalent of the test/plus/personal > codec for OpenQuicktime. As I've seen that you've used OpenQuicktime > to demux quicktime files, I think it could be a good idea to play 3ivx > files directly in Xine. Don't worry about the 3ivx license ... for > decoding, there is no problem ;) does this mean that there is a plan to release the sources for the decoder under the gpl (or a compatible license) anytime soon ?! > > As a free software developer you are certainly aware of the problems > > that arise from the use of such proprietary software. Now the problem with > > decoder plugins like w32codec or the proposed xanim-codec plugin is > > that it gives users that are not aware of these licensing issues the > > impression that using proprietary codecs like 3ivx and xine was in some > > sense "ok". I guess therefore we should place some warning against the > > use of these codecs on the xine homepage or the readme to prevent people > > getting "trapped" in such non-free video formats. > > I agree to put this in an opensource encoder, but in my opinion it has > nothing to do in a player. i disagree... users should be warned of formats that are not decodable in a free environment in the context of any kind of free software project. however, it seems you are telling us that this is not the case with 3ivx (see below). in this case i would of course agree that no warning would be necessary. > - 3ivx is an MPEG-4v3 encoder ... so you're speaking about reencoding > MPEG-4 in MPEG-4 =) In MPEG, the differences are always in the > encoder, the decoder is aways the same ... I mean, you could write a > MPEG-4v3 decoder and directly decode 3ivx stream without any 3ivx > code... that sounds quite interesting... is there any documentation about this available openly ? i've tried to enable the ffmpeg decoder for the video part of the teststreams from the 3ivx website, but both decoding as 'real' mpeg4 (as used by opendivx) and as ms-mpeg4v3 failed. i'm unsure if this is a problem with xine (qt demuxer in particular) or if the format of the 3IV1 video stream has some specialties that need to be taken care of... > I could of course help you with MP3 as well ... In this particular > case, I think we should only demux the compressed chunks and send them > to your Xine mp3 decoder. i think mp3 audio in quicktime streams works in cvs now, however as the video part of the teststreams utterly fails, the general result of playing is a bit shaky ;-) cheers, Heiko |
From: <ya...@3i...> - 2001-09-21 12:45:15
|
On Fri, 21 September 2001, Heiko Schaefer wrote: > does this mean that there is a plan to release the sources for the decoder > under the gpl (or a compatible license) anytime soon ?! Sorry ... not as far as I know ... > that sounds quite interesting... is there any documentation about this > available openly ? As all the MPEG documentations, nothing is available for free for non MPEG members (except some code) ... You have to pay ISO to have the specification ... > i've tried to enable the ffmpeg decoder for the video part of the > teststreams from the 3ivx website, but both decoding as 'real' mpeg4 (as > used by opendivx) and as ms-mpeg4v3 failed. i'm unsure if this is a > problem with xine (qt demuxer in particular) or if the format of the 3IV1 > video stream has some specialties that need to be taken care of... Beware, 3ivx is MPEG4v3 ... ffmpeg may be MPEG4v2 only (bitstreams are different). MSMPEG4v3 has of course nothing in common with the ISO MPEG4v3 ;) ... As far as I know, MPEG4v3 has still not been publicly released ... we have the specification because 3ivx is member of the MPEG... But in principle MPEG4v3 is also known as MPEG4-2001 so it should be released really soon ;) > i think mp3 audio in quicktime streams works in cvs now, however as the > video part of the teststreams utterly fails, the general result of playing > is a bit shaky ;-) cool, I can't wait testing it ;) Yann. Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com |
From: <bar...@t-...> - 2001-09-26 10:44:57
|
Hi Yann, > > does this mean that there is a plan to release the sources for the decoder > > under the gpl (or a compatible license) anytime soon ?! > > Sorry ... not as far as I know ... humm, sad - ok, so I guess using the binary 3ivx decoder is the only (technical) possibility to display the mpeg 4 falvour it is using - at least at the moment. So I think we should try to find a nice technical solution here, perhaps a generic xanim plugin or openquicktime plugin interface would be a nice solution - so in the end it is up to the user to decider wheter her/she wants to use a proprietary codec or not. > Beware, 3ivx is MPEG4v3 ... ffmpeg may be MPEG4v2 only (bitstreams are > different). MSMPEG4v3 has of course nothing in common with the ISO > MPEG4v3 ;) ... As far as I know, MPEG4v3 has still not been publicly > released ... we have the specification because 3ivx is member of the > MPEG... But in principle MPEG4v3 is also known as MPEG4-2001 so it > should be released really soon ;) ah, ok, so there is at least hope we see a free decoder for it some time, perhaps ffmpeg? > > i think mp3 audio in quicktime streams works in cvs now, however as the > > video part of the teststreams utterly fails, the general result of playing > > is a bit shaky ;-) syncing is still unsolved here, I didn't have time to look into that yet - Yann, would you like to dig into this? perhaps we could move closer to the openquicktime sources here, for a first implementation I just merged all your files into one big (too big ;)) source file (basically I wanted to see if it works at all) - perhaps we can simply add a subdirectory to the xine source tree and copy the openquicktime sources there (I'm not a big fan of dynamic linking to new libraries as I guess the openquicktime interface, like most of the stuff we use, still tends to change). Cheers, Guenter -- time is a funny concept |
From: <ya...@3i...> - 2001-09-30 22:00:47
|
Hi Guenter, On Wed, 26 September 2001, Guenter Bartsch wrote: > > > i think mp3 audio in quicktime streams works in cvs now, however as the > > > video part of the teststreams utterly fails, the general result of playing > > > is a bit shaky ;-) > syncing is still unsolved here, I didn't have time to look into that yet - > Yann, would you like to dig into this? perhaps we No problemo, just a few more days and I will have time to play with Xine, see after ... could move closer to the > openquicktime sources here, for a first implementation I just merged all > your files into one big (too big ;)) source file (basically I wanted to > see if it works at all) - perhaps we can simply add a subdirectory to the > xine source tree and copy the openquicktime sources there (I'm not a big > fan of dynamic linking to new libraries as I guess the openquicktime > interface, like most of the stuff we use, still tends to change). Are you aware that OpenQuicktime is based on Quicktime4Linux which is not really a "new library" ;) Anyway, we have changed a lot of the "backend" of the library, the "frontend" is totaly compatible with Quicktime4Linux ... So the interface is becoming richer (new functions added for example for codec parameters) the compatibility has never been really broken concerning quicktime function ... About our "closed codecs" problem, I've got here the beginning of an OpenQuicktime plugin able to load Xanim codecs. As soon as it works as I want, I will try to change your quicktime demuxer to use directly OpenQuicktime that way, it could eventually load decoder plugins itself. After that, you could choose to link as you want statically or dynamically ;) Yann. PS: users may have problem to read 3ivx file : they could use either the 3ivx OpenQuicktime plugin or the Xanim OpenQuicktime plugin and the 3ivx Xanim plugin =) PPS: Xanim modules are definitly old, they are not able to output anything else than subsets of the RGBA colorspace, no YUV at all ... OpenQuicktime plugins are much better ... and are also able to encode ;) Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com |