From: Mike M. <mel...@pc...> - 2004-02-03 04:33:55
|
Hi team, The following decoders in xine's libxineadec are obsolete, as they have been ported to ffmpeg: 28k8.c adpcm.c adx.c interplayaudio.c roqaudio.c How should we go about obsoleting them? Delete them from CVS? Delete them from libxineadec/Makefile.am? Bump the audio decoder API version number so the old decoders will not be used? Something else? After a little more work, I will be ready to clean out most of the video decoders in libxinevdec as well. I just need some advice on the proper procedure. Thanks... -- -Mike Melanson |
From: Siggi L. <si...@us...> - 2004-02-03 08:34:53
|
On Mon, 2 Feb 2004, Mike Melanson wrote: > How should we go about obsoleting them? > > Delete them from CVS? yes > Delete them from libxineadec/Makefile.am? yes > Bump the audio decoder API version number so the old decoders will not be > used? I wouldn't do that unless the old decoders are broken or the API has actually changed. > Something else? > > After a little more work, I will be ready to clean out most of the > video decoders in libxinevdec as well. I just need some advice on the > proper procedure. Should be just the above. I'm assuming you won't remove decoders which are not in xine's copy of ffmpeg, and thoroughly tested... Cheers, Siggi |
From: Mike M. <mel...@pc...> - 2004-02-03 13:53:59
|
On Tue, 3 Feb 2004, Siggi Langauf wrote: > On Mon, 2 Feb 2004, Mike Melanson wrote: > > > How should we go about obsoleting them? > > > > Delete them from CVS? > yes > > Delete them from libxineadec/Makefile.am? > yes > > Bump the audio decoder API version number so the old decoders will not be > > used? > > I wouldn't do that unless the old decoders are broken or the API has > actually changed. You wouldn't do what, exactly? #3? Or #1-3? > Should be just the above. > I'm assuming you won't remove decoders which are not in xine's copy of > ffmpeg, and thoroughly tested... Naturally. Well, I didn't bother to port Dialogic ADPCM yet, but no one cares about that one, especially me. But the rest work peachy. -- -Mike Melanson |
From: Siggi L. <si...@us...> - 2004-02-03 17:30:06
|
On Tue, 3 Feb 2004, Mike Melanson wrote: > On Tue, 3 Feb 2004, Siggi Langauf wrote: > > > On Mon, 2 Feb 2004, Mike Melanson wrote: > > > > > How should we go about obsoleting them? > > > > > > Delete them from CVS? > > yes > > > Delete them from libxineadec/Makefile.am? > > yes > > > Bump the audio decoder API version number so the old decoders will not be > > > used? > > > > I wouldn't do that unless the old decoders are broken or the API has > > actually changed. > > You wouldn't do what, exactly? #3? Or #1-3? #3. IOW: I wouldn's bump API versions, unless strictly necessary. Cheers, Siggi |
From: Mike M. <mel...@pc...> - 2004-02-03 23:32:01
|
On Tue, 3 Feb 2004, Siggi Langauf wrote: > > You wouldn't do what, exactly? #3? Or #1-3? > > #3. IOW: I wouldn's bump API versions, unless strictly necessary. Okay, so I won't bump the API version. That will probably happen eventually without my help anyway...:) I will trash the CVS files and remove any reference from Makefile.am. However, I just remembered that I changed the demuxer -> decoder interaction for a few demuxers (I cheated on the standard rules since the demuxer & decoder operated together). Any installed decoders with higher priority over ffmpeg's decoders will probably crash. Realistically, this isn't much of a problem (fringe formats) unless someone is thoroughly testing all of xine's demuxers. How did we eventually handle the issue with xine's ffmpeg SVQ3 vs. the binary DLL? Thanks... -- -Mike Melanson |
From: Michael R. <mr...@us...> - 2004-02-03 21:47:35
|
Hi Mike, > The following decoders in xine's libxineadec are obsolete, as they > have been ported to ffmpeg: > > 28k8.c > adpcm.c > adx.c > interplayaudio.c > roqaudio.c Cool! > How should we go about obsoleting them? Throwing them out completely seems the best way to me, since it will reduce the compilation time for us developers. They are still in CVS if someone needs them. Michael -- /* Binary compatibility is good American knowhow fuckin' up. */ 2.2.16 /usr/src/linux/arch/sparc/kernel/sunos_ioctl.c |
From: Mike M. <mel...@pc...> - 2004-02-03 23:21:20
|
On Tue, 3 Feb 2004, James Stembridge wrote: > On Tuesday 03 Feb 2004 04:33, Mike Melanson wrote: > > The following decoders in xine's libxineadec are obsolete, as they > > have been ported to ffmpeg: > > > > 28k8.c > > Support for this ffmpeg decoder isn't actually hooked up yet. Hmm, thanks for pointing this out. I'll stick with the decoders I maintain personally and have actually tested...:) > As an intermediate measure I would suggest raising the priority of the ffmpeg > audio decoder. That way people can go back to the old decoders if there are > any problems with the ffmpeg versions. One problem is that this won't have any effect on existing xine installations. xine starts up for the first time, pulls the set of priorities from the decoders, saves them, and then uses the saved copy. You can modify the source to dictate a higher priority but it won't matter; after you install the modules with the modified priorities, xine will use its saved priorities. This is not such a big issue for the existing set of codecs as it was when the native SVQ3 decoder was rolled out last year (binary QT DLL still had priority over ffmpeg, even though binaries were not installed). Actually, there may (no, WILL) be a problem in some cases where the demuxer -> decoder interaction has changed to integrate with ffmpeg. Hmm... -- -Mike Melanson |
From: Miguel F. <mi...@ce...> - 2004-02-03 23:51:36
|
On Tue, 2004-02-03 at 18:21, Mike Melanson wrote: > > As an intermediate measure I would suggest raising the priority of the ffmpeg > > audio decoder. That way people can go back to the old decoders if there are > > any problems with the ffmpeg versions. > > One problem is that this won't have any effect on existing xine > installations. xine starts up for the first time, pulls the set of > priorities from the decoders, saves them, and then uses the saved copy. > You can modify the source to dictate a higher priority but it won't > matter; after you install the modules with the modified priorities, xine > will use its saved priorities. I guess this is no longer a problem: default values are not saved on config file anymore, or rather, they are saved as comments. so, when you change the priority within a decoder this new value will indeed be used unless user has purposely modified it. example: # decoder's priority compared to others # numeric, default: 0 #decoder.ffmpegaudio_priority:0 regards, Miguel |
From: James S. <jst...@us...> - 2004-02-04 02:17:54
|
Hi Mike On Tuesday 03 Feb 2004 04:33, Mike Melanson wrote: > The following decoders in xine's libxineadec are obsolete, as they > have been ported to ffmpeg: > > 28k8.c Support for this ffmpeg decoder isn't actually hooked up yet. > adpcm.c > adx.c > interplayaudio.c > roqaudio.c > > How should we go about obsoleting them? > > Delete them from CVS? > Delete them from libxineadec/Makefile.am? > Bump the audio decoder API version number so the old decoders will not be > used? > Something else? As an intermediate measure I would suggest raising the priority of the ffmpeg audio decoder. That way people can go back to the old decoders if there are any problems with the ffmpeg versions. James. |