Who's Online |
121 user(s) are online ( 59 user(s) are browsing Forums)
Members: 3
Guests: 118
kas1e, emeck, BSzili,
more...
|
|
Headlines |
-
amidisas.tar.bz2 - development/utility
Apr 16, 2024
-
wildmidi.lha - audio/play
Apr 15, 2024
-
liba52.lha - development/library/audio
Apr 14, 2024
-
libcurl.lha - development/library/misc
Apr 14, 2024
-
libopenssl.lha - development/library/misc
Apr 14, 2024
-
bermudasyndrome.lha - game/action
Apr 14, 2024
-
amigagpt.lha - network/chat
Apr 14, 2024
-
curl.lha - network/misc
Apr 14, 2024
-
dgen_sdl.lha - emulation/gamesystem
Apr 12, 2024
-
amiarcadia.lha - emulation/gamesystem
Apr 11, 2024
|
|
|
|
|
Re: Video editing software bounty?
|
Posted on: 2011/8/17 1:38
#41
|
Just popping in 
|
Quote:
magnetic wrote:
328gts:
FYI "YOMGUI" from Morphzone, a Morphos dev who did the ports of Blender3d and Python for Morphos has the Video editing aspects of Blender 3d working in a beta state! I think he even had it working with morphos Firewire driver for Capture!!!
I have been doing video editing on my A1 with OS4 using Blender since a couple of months :) The problems is that Blender seems to run too slow on some systems, or not at all because of lack of 3D drivers. Varthall
|
|
|
|
|
|
Re: Video editing software bounty?
|
Posted on: 2011/8/5 23:15
#42
|
Just popping in
|
@Antique & LiveForIt
Those are two good observations, a simpler video editor for slower systems or with beta video drivers would be a good idea. I had some time ago the idea to update the FLTK port and after that try to port Open Movie Editor, but after Blender has been released I started using it instead. BTW Hans' idea to have the codecs inside a library, then to have an editor using it is even better, whileI don't think the idea of using 2 MPlayer instances at the same time and to hack them would be a good idea, it's much better to start from scratch and code a small native application, or port an existing software instead.
Varthall
|
|
|
|
|
|
Re: Video editing software bounty?
|
Posted on: 2011/8/5 8:21
#43
|
Just popping in
|
Remember that we already have Blender, which has good video editing capabilities.
Varthall
|
|
|
|
|
|
Re: Thunderbird possible after Timberwolf/Firefox?
|
Posted on: 2011/5/10 13:11
#44
|
Just popping in
|
@Hans Quote:
The biggest shortcoming in SimpleMail and YAM for me is the lack of complete modern HTML support. These days HTML emails are commonplace, and so not having HTML support is a problem. Yes, SimpleMail has SimpleHTML, but:
- SimpleHTML is read-only (i.e., no writing of HTML emails)
- SimpleHTML is very dated (e.g., no CSS)
Regarding YAM, for me it's the opposite, I prefer it to other mailers for being text-mails oriented, and especially for its good on the fly HTML-to-text conversion. As far as I have seen, email clients which support both HTML and text messages have usually poor support for the latter. I remember I needed quite some time to configure Thunderbird to display all the text to one specific font and size, and still occasionally some text would have been displayed differently. Varthall
|
|
|
|
|
|
Re: Problems with clipdown and mplayer
|
Posted on: 2011/4/14 10:14
#45
|
Just popping in
|
Quote:
DAX wrote:
@Varthal
Vsync would be cool :)
As for the crashes on exit, what do you think it could be that differentiate my experience from others? (I mean, shouldn't they happen to all users?)
No idea really, I can't reproduce the crashes as well (I'm talking about the ones when replaying streaming videos), only the problem with unfreed memory on exit, which should be happening on your system as well. @kas1e As default, MPlayer uses p96pip. Varthall
|
|
|
|
|
|
Re: Problems with clipdown and mplayer
|
Posted on: 2011/4/13 15:16
#46
|
Just popping in
|
@all So far, crashes have been reported both when using SDL ( https://code.google.com/p/mplayer-amigaos/issues/detail?id=14) and sometimes when streaming videos ( https://code.google.com/p/mplayer-amigaos/issues/detail?id=5). @DAX Quote:
I use it very often, whatch a movie (even with clip down) and no matter if I close it manually or wait for the movie to finish (where it closes automatically) it never crashed here (ho wait, once it crashed because a manually reduced the video window to a tiny spot, it would seem there is no limit in the reduction department, and whe you get tooo small, it crashes).
Yes, I have on my system the same resize problem, although not everyone is able to reproduce it: https://code.google.com/p/mplayer-amigaos/issues/detail?id=1Quote:
I might complain about performance on hi-res videos, lack of vsync (DVplayer has it) but crashes on exit? Never happens here.
Never thought about the lack of vsync, I'll make some comparative tests between DVPlayer and MPlayer tonight and eventually open a new ticket, thanks for reporting it. @kas1e Quote:
If you can build current debug-version , i can test that stuff about crash on exit, and with debug info stack-trace will give us actual and usable information in which function crash happens.
Thanks, but I'd first like to fix the memory leakage on exit, if the crashes are triggered by the same problem, fixing the leakage might fix the crashes as well. Varthall
|
|
|
|
|
|
Re: Problems with clipdown and mplayer
|
Posted on: 2011/4/13 8:00
#47
|
Just popping in
|
@kas1e
I have not done any work on the crash on exit issue, I'm working on other parts now. Thanks for the hints though, that will help me when debugging the code.
Varthall
|
|
|
|
|
|
Re: Problems with clipdown and mplayer
|
Posted on: 2011/4/7 16:01
#48
|
Just popping in
|
Quote:
kas1e wrote:
@Varthall
Btw, what you think about releasing 2 versions: which use sobjs and in which everything inside ? I think many of us would prefer static bin, to avoiding that sobjs hell.
My idea was actually to release a static-only version of MPlayer. Afx has been working on releasing a sobj version of MPlayer, but I prefer static bins as well, IMHO ports using sobjs are more meaningful for those projects which generate huge statically compiled binaries, such as Timberwolf or (from what I have read on Linux) 3D engines like OGRE or Crystal Space 3D. Varthall
|
|
|
|
|
|
Re: Problems with clipdown and mplayer
|
Posted on: 2011/4/7 13:05
#49
|
Just popping in
|
Quote:
DAX wrote:
As Sundown said, Varthall is doing the job with help from Abalaban too.
There is a very active thread on an Italian forum where he provides test builds for him to keep an eye on bugs and performance issues on different HW.
Actually I have so far only compiled a single new build of MPlayer, based on the unmodified sources from AfxGroup. I won't recommend this version (and I prefer not to provide a link to it) since it doesn't provide anything new apart for a drafted version of the GUI, moreover it requires quite a number of sobjs which makes it relatively difficult to run it. I'm working these days on fixing the most important bugs, I plan to release a new version (and officially announce it) when they will be fixed, and leave the other, minor problems plus any planned new feature for a later release. Varthall
|
|
|
|
|
|
Re: MPlayer development thread
|
Posted on: 2010/11/28 14:21
#50
|
Just popping in
|
We will try merge everything as much as possible. Abalaban is already merging Afx changes, and we have received Fab's sources as well. For now there's no plan to make a single repository for both OS4 and MOS, but I think (and I'd like this to happen) there will be more source sharing between the two projects. Aros and 68k AmigaOS specific changes will be welcome, too, if there will be any contributor for those two platforms I'll be happy to include changes and binaries for them as well. As for now there are still no sources online, once they will be ready we'll upload them.
Varthall
|
|
|
|
|
|
Re: MPlayer development thread
|
Posted on: 2010/11/22 20:20
#52
|
Just popping in
|
@centaurz http://www.amigans.net/modules/newbb/viewtopic.php?topic_id=4432That was just an example. Providing that that native QT port will see the light of day, it would be interesting to try to make, or port, a GUI using it. Another possibility would be FLTK, although that has not been further developed since long time. Anyway, this is low priority stuff that I'll eventually take in consideration in the future. Varthall
|
|
|
|
|
|
Re: MPlayer development thread
|
Posted on: 2010/11/22 15:12
#53
|
Just popping in
|
@abalaban I agree with what you said, my only point was what happens when we have released a binary and we want to start working on the next release by updating to the newest official sources. The options I see are two: - download the newest official sources, merge all of them with the whole AmigaOS MPlayer sources (your proposal) - start anew: remove the old AmigaOS MPlayer sources from the trunk, put there the newest official sources, merge them with the AmigaOS-specific patches Shouldn't be the second option faster (you don't need review any diff before the old and new official sources, as you are already working on the new ones)? @fab, @abalaban I was thinking to try to merge Fab's sources at a later stage, but on second thought it is indeed better to directly start to work on them and compare them, after that we can check afx' changes too. Thanks for your help Fab, I have sent you a PM with my email address. @all Let's get the ball rolling: https://code.google.com/p/mplayer-amigaos/Abalaban, and any other who would like to contribute, please send me you Google Code usernames so that I can add you. Varthall
|
|
|
|
|
|
Re: MPlayer development thread
|
Posted on: 2010/11/21 14:49
#54
|
Just popping in
|
@abalaban
Thanks for the info about branching in a CVS. I have downloaded and printed the SVN manual, and I have started reading it, so far it seems to be very well written and easy to understand.
Regarding the branching: as I have understood, when it would be decided to update the Amiga port of Mplayer, you would just merge the latest official source with the Amiga version. I believe that to do so you'll have to review each change manually. I suspect that we'll not have time to do the "update" procedure once in a while, but only when we'd be working on a new release. After e.g. one year, I believe most of the changes between the Amiga version and the official one would be related to old vs. new official MPlayer code. Wouldn't it be faster to skip this step by directly starting to work on the new sources and only apply the Amiga relevant patches? As long as this is possible with SVN, of course.
@Fab
I also fully support your idea, my only fear is that in the long term all the differences between MOS, AROS and OS4 might make it difficult to mantain the project (I'm thinking of CGX vs. P96 - later CGX vs. new OS4 gfx subsystem, ARexx vs. Python, eventually MUI vs. Reaction - later MUI vs. QT), but still it's better to start and see how this evolves.
I'm still available to mantain the project, but since I believe you have the best knowledge on how MPlayer works among everyone here, if you wish and have the time to take yourself this task, that would be no problem from my side.
Varthall
|
|
|
|
|
|
Re: Searching for MPlayer mantainer
|
Posted on: 2010/11/19 12:44
#55
|
Just popping in
|
@all The topic has now changed, better to switch to a new thread here. Varthall
Edited by Varthall on 2010/11/19 13:00:11
Edited by Varthall on 2010/11/19 13:00:55
|
|
|
|
|
|
MPlayer development thread
|
Posted on: 2010/11/19 12:41
#56
|
Just popping in
|
Continuing from this thread. @abalaban Quote:
abalaban wrote:
@Varthall
I must have deeper look but I think it will not be as hard as I anticipated. Maybe you can already try to register a new project at Google Code?
Ok, that's good news. I'm ATM waiting for the password retrieval email for my Google account. Quote:
But please don't import Afxgroup sources yet, if we want to go the right way we must first identify the official version they are from, import them into the repository and only then import afxgroup sources. This is the only way we would be able to easily identify and track AmigaOS patches, what will afterwards be very helpful in updating our sources to the latest official one.
If I have understood well, you'd create two source trees, one with the official sources Afx worked on, the other one with a verbatim copy of afx' sources, is this correct? Varthall
|
|
|
|
|
|
Re: Freeciv SDL (GUI stuff)
|
Posted on: 2010/11/18 10:02
#57
|
Just popping in
|
@Thematic There's a similar problem reported here, I don't know if it's related: http://code.google.com/p/os4sdl/issues/detail?id=10The SDL OS4 source code is available, so you might try to see if there's a bug there in the keyboard handling. Varthall
|
|
|
|
|
|
Re: Searching for MPlayer mantainer
|
Posted on: 2010/11/17 20:08
#58
|
Just popping in
|
@abalaban
Ok :) It's just that's better to define first some things before continuing. Looking forward for your analysis; if you want I can send you my Mencoder sources and porting instructions as well. At this point I'll release Mencoder as-is (fully functional, just missing afx' stuff), the next release will be compiled from the final, merged sources from the SVN. Of course any comment from anyone will be very appreciated :)
I like the idea to use SVN. Also, I have taken a closer look at Google Code and it has indeed a cleaner interface and it's easier to use than Sourceforge, I'd use that. I wonder if the Wiki part could be used as a sort of blog, to report any progress on the project.
Varthall
|
|
|
|
|
|
Re: Searching for MPlayer mantainer
|
Posted on: 2010/11/17 13:57
#59
|
Just popping in
|
@abalaban
Your help is appreciated, but at this point we need first to define who between you and me will be the maintainer of this project before you create a repository and start working on the sources. It's better if there's only one person who will decide what will go in the SVN and what not.
It's not a problem for me to be just a contributor (althought I would have liked to learn how to manage a project), but in this case it will be up to you to decide how to manage everything.
Varthall
|
|
|
|
|
|
Re: Searching for MPlayer mantainer
|
Posted on: 2010/11/17 10:23
#60
|
Just popping in
|
@MickJT I have sent you a PM. @abalaban I have never maintained/contributed to a CVS before, so my knowledge on the matter is limited. My initial thought was that it would be overkill to setup one if there's only one person working on it, but as you said a CVS would help maintaining the project nevertheless. @all Any recommendation for a CVS? Sourceforge? @samo79 Quote:
Yes, Andrea use exactly the mainstream progressive SVN number (f.e. 1.0 RC3 29xxx) imho it's perfect as is because we can easly compare the Amiga version and the original version/source
My complain is that a progressive number like that isn't very readable (e.g. SVN-r29532-4.2.3 vs. SVN-r29068-4.2.3). I'd avoid following the official 1.x versioning too, those version seem to be coming out once every 1-2 years and when they do are already considered obsolete (see the comment on the latest 1.0rc3 version: "Note that this code is ancient, e.g. it still contains this long-fixed bug. Unless you are at least deadly allergic to it, use latest SVN instead."). On the other side, using a new, separated versioning might be not a good idea too, as it might also lead to confusion ("Is OS4's 1.0 version newer or older than the official 1.0rc3?"). So, my suggestions: - assign a new name to this project and create a new versioning path, e.g. AmyMPlayer 1.0, based on MPlayer 1.0 RC3 29xxx. The exe would output both "AmyMPlayer 1.0" and "MPlayer 1.0 RC3 29xxx". - use the date of the source as a version number, e.g. MPlayer 1.0 2010-11-01. I have seen that the MOS port uses this type of versioning. AFAIR the date is not printed by the exe ("MPlayer SVN-r32198-4.2.5 (C) 2000-2010 MPlayer Team"). Varthall
|
|
|
|
|
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
