Re: [Gnash-dev] How does gnash get the swf file when run with URL argument?
On Fri, Nov 24, 2006 at 11:31:46PM -0800, shamju joseph wrote: Hi How does gnash get the swf file when run with URL argument, ie gnash http://name.com/file.swf ? Using libcurl Does it do streaming using RTP/RTSP or download using HTTP and play? If downloaded, where this file is saved? Streams using whatever protocol specified in the url and supported by libcurl. Uses a temporary, unnamed file as buffer. --strk; ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Bizarre screen painting outside the bounding box
I get a different problem with this movie. When I scroll, the plugin frame becomes a screen shot of my desktop, which usually signifys memory corruption someplace. Just to be really interesting, when the movie is done, if I click refresh on my browser, it works just fine! It seems to be using uninitialized graphics memory for a time -- so what you see is whatever was lying around in there last. For me it never pains outside the window frame (gtk-opengl), but stays within the window frame for the plugin. You're on Debian stable right ? Right. John ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Gnash extensions question
On Thu, Nov 23, 2006 at 10:55:06AM -0700, Rob Savoye wrote: Right now I install a Gnash extension in $prefix/lib/gnash/plugins, and Not related to your issue, but I think it would be better in $libdir/gnash/plugins such that gnash is still multilib. -- Pat ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re[2]: [Gnash-dev] video in gnash
Hello Bastiaan, Thursday, November 23, 2006, 4:03:15 PM, you wrote: BJ On Tue, 2006-11-21 at 23:24 +0100, Udo Giacomozzi wrote: Just pass a RGB(A) buffer to the renderer sounds like a simple solution to me. BJ So how does one currently pass an RGB(A) buffer to the renderer? I have to correct myself. pass a RGB buffer to the renderer is not quite correct. I suggest this: render_handler::draw_YUV_frame(YUV_video *v, const rect* bounds); which, by default (render_handler.c), could convert the data to RGB and call: render_handler::draw_RGB_frame(image::rgb* im, const rect* bounds); A render handler capable of hardware accelerated YUV playback (OpenGL) could overwrite the draw_YUV_frame() method with a direct implementation. Other render handlers (AGG, Cairo) just have to deal with a simple RGB buffer. Instead of image::rgb we could also use a plain byte buffer (unsigned char*). Don't know which would be better. The YUV_video class is not very clear to me, I suppose it can give the data for the current frame. Udo ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Gnash extensions question
On Sat, Nov 25, 2006 at 08:28:23AM -0700, Rob Savoye wrote: Patrice Dumas wrote: On Thu, Nov 23, 2006 at 10:55:06AM -0700, Rob Savoye wrote: Not related to your issue, but I think it would be better in $libdir/gnash/plugins such that gnash is still multilib. You're probably right. Since nothing is using this new code yet, I'll make the change. Also it may be more convenient to define that directory in configure.ac if it's going to be used in many Makefile.am (and maybe later a --with could be added). -- Pat ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Gnash extensions question
Patrice Dumas wrote: On Sat, Nov 25, 2006 at 08:28:23AM -0700, Rob Savoye wrote: Also it may be more convenient to define that directory in configure.ac if it's going to be used in many Makefile.am (and maybe later a --with could be added). You're right again. :-) I mostly checked this code in so we could make sure it builds everywhere. You can also set GNASH_PLUGINS to point to a list of directories. This path will only be used by the extensions themselves, but one day there may be a bunch of them, so I'll see about moving the definition to a higher level place. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] how to deal with bugs reported against packages?
Patrice Dumas wrote: I asked the reporter for -va -vp and a backtrace, but now I think it would make sense to have it handled by the gnash devellopers (even though I may have a look too). What should be done for communication between package maintainers and upstream gnash for bug reports? Bugs in the package I'd prefer to be handled by the package maintainers, but this one is an X11 bug we should probably track down and fix. Usually when there is a problem with visuals, it's often very specific to that workstation, and hard to duplicate. In this case I'd also suggest they run glxinfo and xdpyinfo, since that'll have more specific info on this problem. Ideally this bug should get reported using the Savannah bug tracking for Gnash, which is the best way to get things handled. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] Re: video in gnash
Whether it is necessary to convert YUV- RGB? Everyone video render should solve itself. I am precisely assured, that the convertion should not be in class YUV_video . Because img_convert(YUV 1024x768 = RGB) goes during ~10ms on Pentium 1.7Ghz. Our video works simultaneously with Flash player. Usually user of Flash uses 24 Frame Per Second. Hence at us is 40ms to draw flash frame video frame. The current video implementation draws video for ~(7..10)ms. Therefore addition yuv=rgb convertion can lead to that that we shall not keep within in fps. - Вы уже с Yahoo!? Испытайте обновленную и улучшенную Yahoo! Почту!___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: video in gnash
Btw, you might be instrested in looking at opengl shaders for speed conversion up instead of using combiner registers. Alas that's only part of OGL =1.4 afaik. //Markus Vitaly Alexeev wrote: Whether it is necessary to convert YUV- RGB? Everyone video render should solve itself. I am precisely assured, that the convertion should not be in class YUV_video . Because img_convert(YUV 1024x768 = RGB) goes during ~10ms on Pentium 1.7Ghz. Our video works simultaneously with Flash player. Usually user of Flash uses 24 Frame Per Second. Hence at us is 40ms to draw flash frame video frame. The current video implementation draws video for ~(7..10)ms. Therefore addition yuv=rgb convertion can lead to that that we shall not keep within in fps. ÷Ù ÕÖÅ Ó Yahoo!? éÓÐÙÔÁÊÔÅ ÏÂÎÏ×ÌÅÎÎÕÀ É ÕÌÕÞÛÅÎÎÕÀ Yahoo! ðÏÞÔÕ *http://ru.mail.yahoo.com! ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev signature.asc Description: OpenPGP digital signature ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: video in gnash
Hi, Whether it is necessary to convert YUV- RGB? Everyone video render should solve itself. I am precisely assured, that the convertion should not be in class YUV_video . Because img_convert(YUV 1024x768 = RGB) goes during ~10ms on Pentium 1.7Ghz. Our video works simultaneously with Flash player. Usually user of Flash uses 24 Frame Per Second. Hence at us is 40ms to draw flash frame video frame. The current video implementation draws video for ~(7..10)ms. Therefore addition yuv=rgb convertion can lead to that that we shall not keep within in fps. We don't have to convert from YUV to RGB for renderers that support YUV, but AGG isn't one of them, so conversion is needed, whether there is time or not. If not, then we have one more reason to look into gnashs syncing mechanism ;) cheers, Tomas __ Alt i én. Få Yahoo! Mail med adressekartotek, kalender og notesblok. http://dk.mail.yahoo.com ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re[2]: [Gnash-dev] video in gnash
--- Udo Giacomozzi [EMAIL PROTECTED] skrev: Hello Bastiaan, Thursday, November 23, 2006, 4:03:15 PM, you wrote: BJ On Tue, 2006-11-21 at 23:24 +0100, Udo Giacomozzi wrote: Just pass a RGB(A) buffer to the renderer sounds like a simple solution to me. BJ So how does one currently pass an RGB(A) buffer to the renderer? I have to correct myself. pass a RGB buffer to the renderer is not quite correct. I suggest this: render_handler::draw_YUV_frame(YUV_video *v, const rect* bounds); which, by default (render_handler.c), could convert the data to RGB and call: render_handler::draw_RGB_frame(image::rgb* im, const rect* bounds); A render handler capable of hardware accelerated YUV playback (OpenGL) could overwrite the draw_YUV_frame() method with a direct implementation. Other render handlers (AGG, Cairo) just have to deal with a simple RGB buffer. This sounds like a good and clean way to do it. I've looked at the AGG renderer, and have to admit i can't get my head around it, so could you have a look at how to do that? Instead of image::rgb we could also use a plain byte buffer (unsigned char*). Don't know which would be better. The YUV_video class is not very clear to me, I suppose it can give the data for the current frame. Maybe we should extend the image class to support YUV, and drop the use of the YUV_video class completely. cheers, Tomas __ Alt i én. Få Yahoo! Mail med adressekartotek, kalender og notesblok. http://dk.mail.yahoo.com ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] Re: video in gnash
Bastiaan Jacques bastiaan at bjacques.org writes: On Tue, 2006-11-21 at 23:49 +0100, Tomas Groth wrote: But for the other renderers we will most likely just have to rely on standard software conversion, and pass the frame as a you mentions. Since we already use libavcodec for video, we might as well use the img_convert() function which can convert YUV to RGB (and other formats). We may also want to investigate the use of the X11 XV extension which can do the same thing with hardware acceleration. Bastiaan if you plan to use ffmpeg's yuy rgb or other colorspace converters please use libswscale instead of img_convert. img_* is depreciated now. http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-November/048642.html -compn ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
