From: James S. <jst...@us...> - 2004-01-30 19:27:22
Attachments:
ffmpeg_split.diff.bz2
|
Hi, The attached patch splits the ffmpeg decoder into more managable audio and video specific files. Any objections to me committing? James. |
From: Mike M. <mel...@pc...> - 2004-01-30 21:18:29
|
On Fri, 30 Jan 2004, James Stembridge wrote: > The attached patch splits the ffmpeg decoder into more managable audio and > video specific files. Any objections to me committing? Outstanding. This is something I have been wanting to do (or see) for a long time. I gave your patch a quick look and nothing bad jumped out at me. Have you tested it against many (or better yet, all) of the supported BUF_TYPEs? If you say it checks out, go ahead and commit it. Thanks... -- -Mike Melanson |
From: James S. <jst...@us...> - 2004-01-30 21:30:14
|
Hi Mike, On Fri, 30 Jan 2004 14:18:24 -0700 (MST), "Mike Melanson" <mel...@pc...> said: > Have you tested it against many (or better yet, all) of the > supported BUF_TYPEs? If you say it checks out, go ahead and commit it. I've tested a few, but no where near all of them. I'd forgotten just how many codecs ffmpeg supports these days :) I'll download some more samples to try and commit if I don't encounter any problems. James. |
From: James S. <jst...@us...> - 2004-01-31 17:25:39
|
Hi Mike, While testing the ffmpeg decoder I came across a couple of game format related problems: The idcin demuxer tries to copy a 64k huffman table into an 8k buffer - This is really a general problem that afaik hasn't been tackled elsewhere. I guess headers that are too big to fit into a single buffer will have to be split across several. The native xine wc3video decoder (which is used instead of the ffmpeg one by default) sefgaults because of what looks like a double free. Other than that things seem to be working well :) James. |
From: Mike M. <mel...@pc...> - 2004-01-31 17:44:06
|
On Sat, 31 Jan 2004, James Stembridge wrote: > The idcin demuxer tries to copy a 64k huffman table into an 8k buffer - This > is really a general problem that afaik hasn't been tackled elsewhere. I guess > headers that are too big to fit into a single buffer will have to be split > across several. Not sure about this one... > The native xine wc3video decoder (which is used instead of the ffmpeg one by > default) sefgaults because of what looks like a double free. I saw this problem, too (and I've seen it before). xine is trying to use the obsoleted xineplug_decode_wc3video module instead of the ffmpeg module. They have different interfaces which is causing the crash. Delete the old module and the ffmpeg one will take over. > Other than that things seem to be working well :) Nice work, especially on the table with the names. I am presently working to sync/clean the ffmpeg tree and import a bunch of new decoders. Thanks... -- -Mike Melanson |