You can hit "w" while playing to fit the window to video size. We played around while developing and from all choices it was the best to make it this way.
But that's not what the "w" key does! Well, it does sort of, but in a way that is completely useless for my needs:
1. I start Emotion Player, and it appears with some window size.
2. I load a video. Emotion Player rescales the video to fit in the current window size. This usually means there are black borders above/below (or left/right) of the video, since the window's aspect ratio wasn't an exact match for the video's.
3. I press the "w" key, and the window is resized SMALLER, so as to remove the black borders.
So I don't see how you can tell me the "w" key will do what I want, because it doesn't. (I think in an older version of the Emotion Player it did do what I want (enlarge the window to the video's native size), but that behaviour was unexpectedly changed/removed.) i.e. It is ESSENTIALLY IMPOSSIBLE to get Emotion Player to show a video in it's native size (no scaling).
I really don't understand WHY this feature would be removed, because *every other video player ever made* (on Amiga or PC) either does this by default, or at least offers the option to do it.
And to make it worse, this useful feature (resizing the window to show the video at maximum quality) was replaced by a trivial feature (*) that can be manually replicated anyway - using LAmiga+LAlt+two arrow keys. (* reducing the window size slightly, so you can see your Workbench backdrop (etc) instead of black borders)
P.S. I fully support developers having the final say about what their program does or does not do (not that there is really any other option!). If it becomes clear to me that my misgivings are properly understood, and you are still adamantly against adding support for this feature, then I will drop the subject... albeit with great sadness, since I had high hopes Emotion Player could replace the good-but-imperfect LiveForIt-MPlayer. (And it seems VERY close to doing so.)
Edited by ChrisH on 2017/6/16 9:25:02 Edited by ChrisH on 2017/6/16 9:26:35 Edited by ChrisH on 2017/6/16 16:56:50 Edited by ChrisH on 2017/6/16 17:05:02 Edited by ChrisH on 2017/6/16 17:06:09 Edited by ChrisH on 2017/6/16 17:07:27
SMTube was broken recently because, apparently, YT doesn't allow anymore to don't use HTTPS to retrieve videos information.
SMTube author fixed the issue by removing the possibility to discard https "YT_DISCARD_HTTPS = FALSE" but now, Emotion doesn't work anymore with SMTube.
They would need to implement Application Library support. Then, the registered Emotion app would enter the "game mode" each time it starts playing. This should inform the ScreenBlankerEngine to not kick in. Estimated developer time: 30 minutes.
Screenblanker also here does not start, if i remember right Emotion is using application.library for this (i ask Frank, i am not the coder in our team ;) ).
For Updates and news: An update for Emotion is in the work but needs some time. As written before on other places, the last year was not easy for us and we had to focus on keeping alive. So Amiga related stuff where less then before. We hope that we find more time this year (ehm, if i say "we", i mean Frank because i only do concept and graphics/gui ;) ).
The biggest task is to bring SSL Support to emotion, so ffmpeg (the libraries around) has to be adjusted and this needs time and is very much work. So the main feature for a next release is this feature. Second, we need an "eject" button... a very, very big task for me (i have paint an icon, needs 5 -10 minutes). And if there is really a problem with screenblanker, we have a new thing on our list.
The developmnent blog is also very outdated, simply no time and no much readers.
I think Raziel takes it a little bit easy than it is. Yes it is a paid product as candi that not works for you (but for all/most others, it seems..). But behind the projects there are only two people where only one can code and they fight for every spare time minute. The whole situation, our and the AmigaOS situation is not the best. It is also not very motivating to spend freetime if around nothing works well. We hope for a fast tabor release that we all can look forward. Currently i have the feeling that only a hand full of users are out and we hope that it could rise a bit again.
Our work is half fun/hobby based but also half business based. We could sell around 150 Emotions, we do not make secrets about such things. After Amistore fee, there are 16,- Euros here and then on top some tax (income for each and business tax). So the net amount of 2400 is getting reduced a little bit again. Then a 50/50 split and here we are... So it is nice for AmigaOS software and we are very happy. BUT we also see it a bit through pink glasses (is this the right word for it, Rosarote Brille ;)? ). Frank spent more than 6 Month in FULLTIME on Emotion. So in every thread we hear "it is paid, paid, paid and we want it uptaded every day", it makes it not easyer to get motivated. If we spent the time not for Emotion than on games on other platforms instead, we maybe never had such a year like last one.
In future, we also have to focus. We want to make some AmigaOS related stuff but we don´t know how much time we can spend. With our game engine, we can build some games based on existing ones. So i can make graphics for another platformer or work on new games pased on our prototypes (we have a lot of them ;) ), this needs time. And then, this could be the time for Frank to work on AmigaOS stuff (if i am behind with my gfx stuff). But all ideas and dreams also could be delayed. For instance we want to support PS4 later this year, so Frank has to port the engine to this system which needs much time too (PC, Xbox, Switch is done!).
Maybe it sounds a bit negative, but we are looking forward. And becaus we had to focus last year, the current one has started much better. So we can see it slightly positive again ;)
The biggest task is to bring SSL Support to emotion, so ffmpeg (the libraries around) has to be adjusted and this needs time and is very much work.
Out of curiosity, why does ffmpeg need adjustments for SSL support? Does ffmpeg include networking code?
Quote:
We hope for a fast tabor release that we all can look forward. Currently i have the feeling that only a hand full of users are out and we hope that it could rise a bit again.
Agreed. It would be great if Tabor/A1222 were released soon. There is demand for a low-cost machine, and it will increase the user-base once it's available.
The bigger the user-base, the more time us developers can devote to AmigaOS projects...
SSL: puh, maybe Frank has to include it on a different place. He know it better as he does it (and also had begun). So please belive not me to much in case of coding ;) But Frank doesn´t write a lot. So i have to say some words from time to time to break the silence ;)
Yes as imago already wrote, the avformat library needs ssl support ... I would have liked to integrate amissl for that. The only problem is that the network code is written in POSIX and AmiSSL needs the socket interface pointer, which I don't get easily from newlib. Therefore the network code must also be adapted, this is feasible, needs only time. When I get some time again, I'll take care of it, if no one else wants to make this before ... the code is open.
Thanks for updating us regarding the development of Emotion. It is one of the most important software we have on AmigaOS 4.1.
Regarding SSL, I've been using YT.Rexx with SmTube and Emotion for a while now and it works without any trouble (but it would be great to have it included directly in emotion, that's for sure)
I prefer Rexx for this, because each structure potentially works for a couple of months only.
And, as I understand it, AmiSSL would make it possible for a pretty old application to still use secure connections, if AmiSSL updates were done transparently.
Interesting. I didn't expect a video codec library to include some networking code. Normally you'd want to keep those separate so that the modules are nicely independent.
Hope it doesn't suck up too much time.
Quote:
The only problem is that the network code is written in POSIX and AmiSSL needs the socket interface pointer, which I don't get easily from newlib.
How to do this really should be in AmiSSL's SDK. I don't see any example code in the repository, although you could use the test code as reference.
Quote: The only problem is that the network code is written in POSIX and AmiSSL needs the socket interface pointer, which I don't get easily from newlib.
How to do this really should be in AmiSSL's SDK. I don't see any example code in the repository, although you could use the test code as reference.
There are no examples on how to do this because you can't, you *must* use the bsd.library directly not the new lib wrappers for it. THis is not so difficult to do, mostly just adding ISocket-> in front of the network calls and makng sure you don't confuse socket and file descriptors.
see my pythonssl on os4depot.net for clues an how to approach this, though code is much more generalised due to it's nature, it should be easier with an end application usage.
There are no examples on how to do this because you can't, you *must* use the bsd.library directly not the new lib wrappers for it. THis is not so difficult to do, mostly just adding ISocket-> in front of the network calls and makng sure you don't confuse socket and file descriptors.
That's a shame. It makes life difficult for people writing portable networking code. I can understand why people use the openssl shared-object instead of AmiSSL, or even use a statically linked version.
That's a shame. It makes life difficult for people writing portable networking code. I can understand why people use the openssl shared-object instead of AmiSSL, or even use a statically linked version.
Not only that, but also the fact that when one use AmiSSL he forced to wait for hell of time when any kind of update or new version will arrive (years ?), while, when one use pure openssl without any needs to worry about amissl usage, then developer can update his code very fast, without needs to wait when amissl authors will do anything and made a release.
Because of that i never understand needs to made amigassl.library at all. I mean.. its just amiga-specific wrapper over usuall openssl, which is more easy to use and to update when need it in its original form. Without touching any single line of code. Why there needs to add more work and waiting-time, just so it will be placed in libs: and called amigassl.library, while it just the same openssl ?:)
AmiSSL predates AmigaOS 4, so it was originally created before we could use shared objects. It would be my preferred way to use SSL because AmigaOS libraries are truly shared while shared objects aren't (each application loads and links its own copy).