We? The royal 'we'?On 5 Feb 2008, at 12:17, Hong Yu wrote:
Currently we are further modifying Gnash-cvs source for the option '--enable-media=ffmpeg' and have had the following plans:
[1] Modify 'configure.ac' and set the default value of 'media_handler' to be 'gst'
[2] Create directory 'libmedia/ffmpeg' and copy the current program dependencies 'AudioDecoderFfmpeg.*', 'sound_handler_sdl.*', 'VideoDecoderFfmpeg.*' under the directory
[3] Rename the directory 'libmedia/sdl' and exclude it from build temporarily
[4] Modify files 'Makefile.am' accordingly wherever necessary
[5] Create files 'ffmpegNetStreamUtil.*' in the directory 'libmedia/ffmpeg', and move the utility classes 'raw_mediadata_t', 'multithread_queue<T>', and 'AudioResampler' from 'server/asobj/NetStreamFfmpeg.h'
[6] Create files 'NetConnectionFfmpeg.*' in the directory 'libmedia/ffmpeg' and copy partial implementation of 'server/asobj/NetConnection.*' of Gnash-0.8.1, which is invoked in 'server/asobj/NetStreamFfmpeg.*'
[7] Test and debug the above changes with YouTube
We will post our debugging results with YouTube soon afterwards. And look forward to your helpful suggestions!
Best regards,
Hong Yu
Hong Yu wrote:
We would be very happy to cleanup our patch to comply with your new media abstraction. But I need to first invest more time learning from the source code. It would definitely shorten my learning curve, if you would provide more suggestions on Gnash's new media abstraction design?
Best regards,
Hong Yu
strk wrote:
On Fri, Feb 01, 2008 at 02:03:01PM +0100, strk wrote:
On Fri, Feb 01, 2008 at 05:47:59PM +0800, Hong Yu wrote:
So would you consider the option '--enable-media=ffmpeg' for the new or future release(s)?
I'd be for using it in the upcoming (0.8.2) release.
The only concern would be changing the configure script to not fallback
automatically to ffmpeg if gst is not found, assuming the ffmpeg version
would not be as stable as the gst one.
Sorry, I just looked at the patch. Another concern is not making the redesign
process harder, and this patch doesn't help with that in its current incarnation
(too many compile-time switches).
I think you mentioned the early state of your patch, so my question would be:
do you think you'll be able to clean it investing more on the abstraction
of the interfaces ?
-strk;
_______________________________________________
Gnash-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnash-dev
|
PGP.sig