Who's Online |
170 user(s) are online ( 128 user(s) are browsing Forums)
Members: 0
Guests: 170
more...
|
|
Headlines |
-
amiarcadia.lha - emulation/gamesystem
Apr 28, 2024
-
ifarchive_dl.lha - utility/script
Apr 28, 2024
-
kt_scripts.lha - utility/script
Apr 28, 2024
-
stream.lha - utility/benchmark
Apr 27, 2024
-
thumbnailmaker.lha - video/misc
Apr 26, 2024
-
mce.lha - game/utility
Apr 23, 2024
-
theme_list.lha - utility/misc
Apr 23, 2024
-
faac.lha - audio/convert
Apr 22, 2024
-
faad2.lha - audio/convert
Apr 22, 2024
-
seq.lha - audio/misc
Apr 22, 2024
|
|
|
|
|
Re: "YouTube and Clipdown not working again"
|
Posted on: 2011/9/8 9:12
#121
|
Just popping in 
|
No need for clipdown with OWB (MUI). Just read getvideo readme, it tells how to configure getvideo in OWB contextmenus properly (as well as in Ibrowse). Basically, you just add a contextmenu entry for the page, link and image elements, and you pass the correct parameters to getvideo.
|
|
|
|
|
|
Re: Can my program minimise it's own MUI window?
|
Posted on: 2011/8/21 12:47
#122
|
Just popping in
|
set(your_app_obj, MUIA_Application_Iconified, TRUE);
|
|
|
|
|
|
Re: Flash plugins again...
|
Posted on: 2011/8/18 17:28
#123
|
Just popping in
|
Quote:
Different approach: Some sites offer to switch to HTML5. Would that be an easier alternative?
Sites providing HTML5 mode (youtube, dailymotion, vimeo, ...) make it easy to retrieve the media source, since it's merely <video|audio src="blah"> tag. To be noted some sites protect that somewhat with cookies and/or referrers. Also to be noted that with the help of userscripts, you can do a bit like getvideo does, retrieve media URLs and then you can add direct links to the page itself. For instance, i do that for Youtube when the video isn't available as HTML5 mode (yet), as well as removing the Flash element and adding a video element instead (which looks like that in the end: http://fabportnawak.free.fr/owbshots/ ... player-youtube-script.png ).
|
|
|
|
|
|
Re: Flash plugins again...
|
Posted on: 2011/8/18 12:39
#124
|
Just popping in
|
Quote:
Many sites, only hides the URL in some js code so you can bypass flash completely. But other sites seem to generate the URL within the running flash file. So basically I would like to be able to "run" a swf file enough to make it spit out that damn URL :) In stand-alone mode or as a plugin.
And for that, you need to implement a great part of the ActionScript 3 interpreter (if you want to deal with all these players requiring Flash9/10, that is). So it will be quite some work, the same the other Flash implementations struggle with. Quote:
So, instead of doing like a real plugin would do, i.e. play the file inside itself on its own surface, it would instead just print the URL and stop, or possible save the stream to disk.
Isn't that what you already have btw??
Well, the swfdec plugin is more than an ad viewer, you know. It does all that and more (upto Flash8, unfortunately). Playing the media in the browser or just displaying the direct link is the easy part. In the swfdec plugin, i use ffmpeg to play the file (instead of gstreamer originally used in swfdec), and i also show the streamed URLs in a resource window accessible from the plugin area contextmenu. Besides, the plugin uses the browser network infrastructure, so the streamed URLs also appears in network activity window, anyway. Anyway, there's no shortcut for what you want to achieve. Whatever you do, you need an ActionScript 3 interpreter able to run your swf file. And since this task is already a huge work, why would you stop at interpreting and not poursuing with rendering then ? :)
|
|
|
|
|
|
Re: Flash plugins again...
|
Posted on: 2011/8/17 13:50
#125
|
Just popping in
|
Swfdec is about the same as Gnash regarding compatibility (sometimes better, sometimes worse). On the other hand, it's better designed than Gnash for plugin usage. Gnash was just insane in that regard (they did some work on that, since, but it's still insane for other reasons, Boost usage being one of them).
As for your Flash10 specs, they're public, and they won't help you a lot to retrieve stream urls, unless you write an intepreter for ActionScript 3. In practice, most Flash video players (youtube & co) play an external media (URL being computed by the flash app in various ways), so you're out of luck if you plan to extract the media from the swf file. :)
|
|
|
|
|
|
Re: OWB 3.32
|
Posted on: 2011/4/26 9:35
#126
|
Just popping in
|
@K-L
About the scroll thing, it's about sites using background-attachment: fixed attribute/value.
This kind of site is normally very slow, because everything has to be rendered again, even if you just scroll 1 pixel.
This option from WebKit just ignores this attribute, and was originally introduced for slow/mobile computers.
As for the wait+100%cpu at tab closing, i assume it happens while there's still network activity ? If so, it would indicate that this new threaded resolver implementation kind of busy loops when signaled to abort, which is really not something one wants.
|
|
|
|
|
|
Re: gnash plugin on the Sam460ex ?
|
Posted on: 2011/4/6 15:13
#127
|
Just popping in
|
@Futaura
I could actually port my swfdec plugin for Ibrowse 2.4, especially since I took inspiration from IBrowse flash plugin sources(in its morphos version, from Piru).
Though I changed some browser methods (redrawing) and got rid of unnecessary things for me, but that's not a big deal anyway.
The only trouble is that the plugin library base has to be relative, since like most unix stuff, swfdec (or rather the underlying libraries like cairo, glib and so on) rely on many globals.
And while i know how to do that with MorphOS, i have no clue how to deal with several openers and relative globals on OS3.x or OS4.
|
|
|
|
|
|
Re: When Escape should (not) close a window...
|
Posted on: 2010/12/6 0:22
#128
|
Just popping in
|
For information, the MUI keys are configurable. Here I have shift + ESC configured to close windows, for instance.
|
|
|
|
|
|
Re: Aquaria full game. How?
|
Posted on: 2010/12/3 14:54
#129
|
Just popping in
|
@Cool_amigaN
Besides, Aquaria is a really nice game, written by only two programmers, and not widely promoted, as you said.
The real merit is on the authors who spent months to write it, not the porter who just did a plain configure/make that takes about 5 minutes of actual work (and it also applies to me, by the way, since I compiled it for MorphOS).
|
|
|
|
|
|
Re: Aquaria full game. How?
|
Posted on: 2010/12/2 15:28
#130
|
Just popping in
|
@Phantom
I don't know if the OS4 binary has been compiled as the full version or not, but the datas supplied in the archive are definitely enough to complete the game (great game and great scenario, btw).
|
|
|
|
|
|
Re: Aquaria full game. How?
|
Posted on: 2010/12/2 15:20
#131
|
Just popping in
|
@Phantom
Actually, the datas supplied with the OS4 archive (and possibly other platform demo archives?) are the same as in the full game. I completed the game (on MorphOS) with these datas.
So, i'd say that the demo is only determined by the game executable itself (and its build options).
|
|
|
|
|
|
Re: MPlayer development thread
|
Posted on: 2010/11/21 15:25
#132
|
Just popping in
|
@Varthall
As i said, MPlayer itself is modular enough. You can have several backends living happily together. Ideally they should rather be sent to MPlayer svn itself, but it would be quite time-consuming and painful to have these accepted, as afxgroup told (besides, there are few (rare) changes to "generic" sources that could be seen as intrusive by MPlayer maintainers, which certainly wouldn't be accepted).
I also don't plan to manage this "MPlayer for AmigaOS" project for all OS flavours: not enough time, too much "administrative" overhead and possible conflicts later in some of the design choices. It's a bit sad, but I think it's much more efficient to work alone on this kind of small project (MPlayer itself is not a small project, but the port is).
My original suggestion was just that you could still use these sources as a base, since it implements most of the features you might want and is stable. Then, whether it's maintained for all OS flavours or only forked for OS4 in the long run, we'll see. The former would be ideal, but i think the latter will happen, unless someone "neutral" manages it. I don't care a lot, because it won't stop me from maintaining my port in any case. )
|
|
|
|
|
|
Re: MPlayer development thread
|
Posted on: 2010/11/20 13:17
#133
|
Just popping in
|
@afxgroup First, the GUI module is fully optional (be it at compilation or runtime). The GUI module uses a couple MUI4 extensions (mainly for playlist class and dtpic.mui with alpha channel), but Deadwood managed to backport this to AROS (except for the overlay drivers and their integration in the GUI window, since AROS doesn't provide overlay support yet). OS4 may also not have all the necessary bits for the overlay integration in the GUI (at least not using cgx API), but even then, MPlayer is modular enough, so you could re-use and improve the vo_p96pip driver, implementing the same functionality as vo_cgx_overlay or cgx_overlay_gui drivers (cgx_overlay_gui allows the video to be embedded inside the GUI itself, instead of opening a separate window as cgx_overlay or cgx_wpa would). Here's how it looks like in embedded mode: http://fabportnawak.free.fr/mplayer/MPlayer.pngAnd if for any reason the MUI GUI is an issue, you could add a separate reaction GUI backend (see gui/ directory).
|
|
|
|
|
|
Re: MPlayer development thread
|
Posted on: 2010/11/19 18:07
#134
|
Just popping in
|
@abalaban
I merge MPlayer regularly. The os-dependant API (libvo, libao, dvdcss, gui, ...) is relatively stable, so the merge process is generally not much trouble. I generally need half a day or so to update to a newer MPlayer revision and compile it, if there are no major conflicts or changes.
Now, i seriously wonder why you all want to fork MPlayer when another amiga-like version with full GUI support already exists (and has been ported almost as-is for AROS too). But up to you, i guess. :)
|
|
|
|
|
|
Re: Gallium (OpenGL) being ported to OS4 now!
|
Posted on: 2010/11/2 8:44
#135
|
Just popping in
|
@Cool_amigaN
Would be nice to have the exact benchmark conditions, because from what i can see with the OpenArena test, I get better results on a stone-old r200 on a stone-old pegasos2 with tinygl/morphos, which is somewhat unexpected, compared to the tested setups (R300/CoreDuo). The R5xx/CoreI3 performance also looks really quite poor.
|
|
|
|
|
|
Re: Simple wishlist for next AmigaOS
|
Posted on: 2010/10/16 20:37
#136
|
Just popping in
|
@Fairdinkem Quote:
Yeah I'm with you on having A full FLASH and JAVA implimentation into AmigaOS 4.x. I don't pretend to understanding programing because I don't, but I really can't understand why GNASH port to AmigaOS4.x ended up being to slow to use but I would like to know why? Is it a hardware limitation or is Gnash not a very good flash solution ie. Is it bloatware, not lean enough for nimble software like AmigaOS4.x? I use a HTML5 solution on MorphOS for Youtube video in OWB and although its good it is still slow and loses audio and video syncronisation sometimes. All I know is AmigaOS4.x can't wait for the internet to convert to HTML5 and for Flash to disappear which I believe it won't because Adobe will hardly surrender that easy!
Just to avoid any confusion, HTML5 video isn't slow, Cairo is (at least with a software surface). OWB (MorphOS) uses an overlay output in "fullscreen" mode, and when enabled, it runs just as fast and smoothly as MPlayer (youtube 360p typically requires 30% cpu on a pegasos2 in OWB). When overlay is not enabled, all the time is spent in cairo blitting and frameskip happens if needed, but audio is unaffected, though. Video/audio synchronous, as long as you don't try to play some 720p H264 file (you'd need a mac mini to handle this at proper speed and in sync).
|
|
|
|
|
|
Re: OWB and plugins?
|
Posted on: 2010/9/24 1:09
#137
|
Just popping in
|
@joerg
Let's try again. You have two choices:
- Implement the windowless mode. In this case, the plugin would be passed some drawable (cairo surface, rastport, or anything that could make sense) in the setup phase. When it needs to draw, it would request a drawing operation to the browser, which would answer by sending the plugin a 'paint' order for a given rect when it's ready to do so (according to z-order, transparency or not, ...). The plugin can then compose its own content with the browser content.
- Implement the windowed mode. The plugin is passed some "window" handle (the mui window object, for instance, but it could be anything else depending on implementation) and a rect at setup. When it feels like drawing, it just calls a MUI method on the window object to draw content according to the npwindow rect set previously.
[removed public moderation discussion yet again]
Edited by Fab on 2010/9/24 2:04:11
Edited by ssolie on 2010/9/24 21:17:20
|
|
|
|
|
|
Re: OWB and plugins?
|
Posted on: 2010/9/23 22:34
#138
|
Just popping in
|
The OS4 OWB uses Reaction and with Reaction plugins are impossible. Maybe it's possible with QT, but on AmigaOS4 with Reaction you'd have to use something as extremely ugly as workaround. :)
[EDIT]: added a smiley
|
|
|
|
|
|
Re: OWB and plugins?
|
Posted on: 2010/9/22 13:29
#139
|
Just popping in
|
@joerg Quote:
The MorphOS OWB uses MUI and with MUI plugins are impossible. Maybe it's possible with MUI4, but on AmigaOS with MUI 3.9 you'd have to use something as extremely ugly as it had to be done in IBrowse as workaround where the browser, instead of the plugin itself, has to render the plugin graphics into the window.
In case you wouldn't know, NPAPI specifies two rendering modes: windowed, where the plugin redraws itself (breaking possibly transparency and z-order in the page) and windowless, where the plugin draws only when the browser requests it. Windowed mode sucks, but it is generally used for speed reasons. Both can be done with or without MUI, that's totally irrelevant here.
Edited by ssolie on 2010/9/22 20:54:02
|
|
|
|
|
|
Re: I have some good news, 98% of OWB compiles in cygwin :-)
|
Posted on: 2010/9/1 0:48
#140
|
Just popping in
|
@joerg
Fine, let's say what i do is pointless. I have just one question for you then:
why do you bother developing for an OS like OS4 when you could just use linux/osx/windows instead? I can't see any reason, because according to you, it's clearly pointless to try competing against these OSes, so your work just makes no sense at all either.
Now, let's be serious again. This "cellphone browser" outperforms firefox in several areas, including speed and standards compatibility.
Sure, OWB itself is nothing more than a SDL implementation and a simple API over WebKit (cloning WebKit win API, actually), which serves no other purpose than having a very portable but very useless port.
But what really matters is the core itself, WebKit, which, as everyone knows, is used in many mainstream browsers, including Chrome and Safari, and these browsers certainly can't be qualified as "cellphone browsers". Obviously, it needs serious GUI work to be used as a normal desktop browser with standard functionality, but this part is not an impossible task to achieve, even for a single developer.
Edited by Fab on 2010/9/1 1:05:00
Edited by Fab on 2010/9/1 3:18:51
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
