Instead of porting gstreamer, you should rather look at how to make OWB use something that is already available on OS4. The MorphOS port uses ffmpeg, for example.
kolla wrote: Instead of porting gstreamer, you should rather look at how to make OWB use something that is already available on OS4. The MorphOS port uses ffmpeg, for example.
GStreamer and ffmpeg are two completely different things. One is a streaming library, and the other is a library containing audio and video codecs. FFmpeg can be used as a gstreamer plugin.
If the MOS version of OWB doesn't use GStreamer, then what does it use to handle the input streams?
I wrote an input protocol that hooks to ffmpeg with a registered url-protocol, that takes care of buffering incoming data through the regular OWB network layer. It supports "fast seeking" by resuming (something that GStreamer backend didn't until a few weeks ago). Media data is then demuxed in another thread, which itself passes packets it to video and audio decoder threads. And since cairo rendering for such video needs isn't blazingly fast, i provided a fast overlay output mode that is enabled when fullscreen mode is enabled (it's actually a fullwindow mode, but whatever).
Of course, the whole thing is more simple than a full-blown GStreamer layer, but it does as much in this HTML5 context, and was much more interesting for me. Chrome also has a similar approach, using ffmpeg directly and implementing their own stream layer.
But having GStreamer for other things would still be interesting, of course.
Edited by Fab on 2010/7/21 3:41:18 Edited by Fab on 2010/7/21 3:42:08
@spotUP Maybe just contact with AfxGroup for taking glib library for ? Related to ExecVP - it's can be changed just on Execute imho, or even on unix one plain "Execve" or even "Exec"
i have an old version of glib2 taken from amycignyx and patched to remove all cignyx: calls. It is useful for my works but is old and if you try to use it with new projects it needs a lot of other missing functions. You can ask Edgar (Mr X) for a newer version.
A bounty for the fusion of AOS4+AROS+MOS OWB. It would/could bring OWB developers together to merge their doings to one combined browser. Once the same code compiles for all flavours, the bounty would be given (split) to all three origins.
It could be done if the 3 would have a lot in common, but there are more differences than anything else: - Different goals: The AmigaOS 4.x version is a port of OWB (with minimal features added to make it usable at all, for example a GUI, support for multiple windows/tabs and the much faster AmigaOS font implementation) while the author of the MorphOS OWB seems to try to implement a desktop browser around OWB (which makes no sense). - Neither the AROS OWB nor the MorphOS OWB use an AmigaOS GUI but Zune or MUI4 instead, i.e. you can't use anything in GUI related parts from the other 2 in the AmigaOS 4.x OWB and most of the platform specific parts depend on the GUI. Or you'd have to downgrade the GUI of the AmigaOS 4.x OWB to MUI, but it's impossible to collect a bounty large enough for me to consider touching extreme crap like MUI ever again. - To compile the same code for all OSes you have to replace every single OS function call by wrapper functions which have to be implemented for the 3 incompatible OSes. Even for my old AmigaOS 3.9 port of OWB I didn't do that, creating a new port from scratch instead which didn't share a single line of common code with my AmigaOS 4.x port was less work. - Unless you want to limit the AROS version to AROS/PPC you have to do the same for all endian depending memory accesses, for example in the AmigaOS font implementation, since AFAIK the AROS compilers for little-endian CPUs don't support generating code which automatically fixes them like the Amithlon GCC did. - No idea why, but the AROS OWB uses SDL. On AmigaOS 4.x using SDL graphics in OWB is a little bit (less than 5%) faster than using it's Cairo graphics implementation, but even if SDL would be twice as fast as Cairo on AROS they'd have to change it. The SDL graphics implementation of OWB is way too incomplete to be usable.
Cooperation would only make sense in OS and GUI independant parts of OWB, for example adding PowerPC support in SquirrelFish Extreme. The only difference between AmigaOS, AROS and MorphOS there would be allocating the executable memory.
- Different goals: The AmigaOS 4.x version is a port of OWB (with minimal features added to make it usable at all, for example a GUI, support for multiple windows/tabs and the much faster AmigaOS font implementation) while the author of the MorphOS OWB seems to try to implement a desktop browser around OWB (which makes no sense).
Why not? in this case you could use OWB with SDL/fontconfig implementation, remove all useless (tab are useless if it isn't a desktop browser) gui stuff and launch it from shell as the original version. Sorry but these are your opinions and your goal, but maybe someone would have another goal for OWB on OS4
BIG THANKS for the reply, it clears a lot of things for me.
UPDATE: what does desktop browser mean to you? Is it like workbench replacement?
"but it's impossible to collect a bounty large enough for me to consider touching extreme crap like MUI ever again"
8)
I would like to see some hard core developer putting up AOS GUI comparisson table somewhere.
- Kimmo --------------------------PowerPC-Advantage------------------------ "PowerPC Operating Systems can use a microkernel architecture with all it�s advantages yet without the cost of slow context switches." - N. Blachford
Why does it make no sense to implement a desktop browser around OWB? Maybe I don't understand the term "desktop browser" in the right way .. but if OWB shouldn't be used as a desktop browser then OWB on AOS4 makes no sense in its current state, too? Because i use OWB on AOS4 in this way
Yeah .. That is really strange to hear, that desktop browser based on OWB make no sense. For what then all that work ? Not for users ? Why then OWB for morphos with all that features implemented by Fab make sense for all morphos users ? I just tring to understand the logic here.
Unless you want to limit the AROS version to AROS/PPC you have to do the same for all endian depending memory accesses, for example in the AmigaOS font implementation, since AFAIK the AROS compilers for little-endian CPUs don't support generating code which automatically fixes them like the Amithlon GCC did.
Erm, you obviously use endian aware macros when accessing endian depending memory. Preferably one doesnt try to parse font data on the disk directly at all... but that is another story.
Keep up the good work, OWB is the best Amiga web browser I've ever used by far.
Quote:
joerg wrote: - Neither the AROS OWB nor the MorphOS OWB use an AmigaOS GUI but Zune or MUI4 instead, i.e. you can't use anything in GUI related parts from the other 2 in the AmigaOS 4.x OWB and most of the platform specific parts depend on the GUI.
Could GUI parts be taken from AWeb, which is open source and has a Reaction GUI?
Quote:
Or you'd have to downgrade the GUI of the AmigaOS 4.x OWB to MUI, but it's impossible to collect a bounty large enough for me to consider touching extreme crap like MUI ever again.
Always found MUI programs to be the least stable. For example, the Voyager browser was always problematic. Then there's the various MUI libs and making sure you have the latest or most stable for the various MUI programs you use, which is thankfully very few these days.