@all Question : should we have by default in prefs/media all options being set to ON, instead as it now, when only fastseeking and mp4 is enabled ?
Those options when off, mean that when you click on those formats, they didn't plays in browser but bring you save-as requester to download it instead. But imho, the other way around expected to be defaul : everything enabled, and if one wish, he disable it.
So question, should i just enable them all by default ?
Question : should we have by default in prefs/media all options being set to ON
I vote all on since they seem to be working well. Are there issues on slower systems than the X1000 or X5000? People with slower systems might answer differently if they have issues.
@ktadd But then, if you visit a page with video, you probabaly want to watch it ? And without let's say enabled webm, or ogg, you will have no ability to do so. But if you didn't visit those video pages, then it does not matter if things for media on or off, it will be the same by speed of odyssey usage.
In end, those options still will be there of course, and anyone will have a wish to not have video/audio played in browser can disable it easyly.
I just fear, some ppls unpack it, run, and then just didn't have working video/audio in some parts think "damn crap, odyssey can't play them", and they surely will not thing that to have working video/audio, they need to enabled those options (which in all other browsers everywhere just default thing).
@ktadd Also what make me curious : i tested video of webp which you point out on (that with Lava one), and there i can choice any format : webp, vp8 and vp9 too, and all works. But in prefs/media we have string "WebM (VP8) support", but then , should't it be "WebP (VP8,VP9) support" instead ?
Also what make me curious : i tested video of webp which you point out on (that with Lava one), and there i can choice any format : webp, vp8 and vp9 too, and all works. But in prefs/media we have string "WebM (VP8) support", but then , should't it be "WebP (VP8,VP9) support" instead ?
VP9 Codec is the successor to VP8 and was released in 2017. Since we can play it, go ahead and add it.
If it supports "new" webp modes, maybe due 'cos you updated webp support, just changing the string in catalog/cd/ct to "WebP (VP8,VP9) support" will be nice.
I tried yotube on my SAM460ex it crawls, but doesn't freeze/crash as on your system, I'm using bultin sound sm502 (IIRC).
Will try yhat web page with webp video and see what happens.
THX everyone testing and kas1e to take time to update Odyssey, thx!!!!
Found a good HTML5 Video/Audio test page with many different containers formats and video/audio codecs. Says it's mainly for Crome and Firefox so spoofing as those might help. Webm also supports a newer codec AV1 but we are not able to play it. You might even get a crash while trying to.
Probably for you localisation in OS are broken, and Mar translate to some Tue, if that Tue dind't mean Mar in italian
Right, abbreviation of the letters for the day and the name of the month are the same in italian, also the order of the month/number of day is inverted in english compared to what it will be in italian so this probably can lead to some confusion :)
What wrong about reusing the old but very standard scheme for the date ? like: 16.03.2020
What wrong about reusing the old but very standard scheme for the date ?
That just need properly done stuff: need to create version.c , which will be always compiled does not matter if other files touched or not (so compilation date will be taken from every compile) , and that in turn mean needs to change a bit CMakefiles and some other stuff so makefiles for odyssey (at least for the amiga parts) will be generated with that force-to-compile version.c file with necessary flag to provide date.
That all easy, just boring stuff which can be done later, and instead i just use inbuild __DATE__ macro of GCC which have that format you see now
Thanks to Frank from AmiBoing/EntwicklerX Odyssey now uses Frank's real amiga shared libs for all FFmpeg parts handling video/audio in the browser. That in comparison with my older static FFmpeg compile mean:
1. We have now FFmpeg 2.2.16 instead of an older 2.2.1 (why not 3.x and 4.x ? Because since 2.2.16 some decoders start to be slower). 2. Binary of Odyssey is smaller on 5mb now, as no FFmpeg code built-in, that code in the shared libs instead. 3. Frank's version recognize Altivec unit and if available, uses the Altivec code automatically (so theoretically those ones who has Altivec machines can have better speed in video playback). Quite interesting to see comprassion results on x1000 when play the same mediafile via beta03 and beta04. 4. ffmpeg libs can be updated separately, without odyssey updates.
All the shared libs also placed in the LIBS folder of Odyssey and will be used from there now, so users will have no issues. But of course, you can move them all to system LIBS: directory if you wish: AmigaOS4 will firstly search libs in the LIBS: directory of Odyssey, and if nothing found then the system's one.
-- In the prefs/media enabled by default WebM, Flv and Ogg (before they were disabled), so everything works out of the box. If users wish to not have video/audio be played in the browser but to have downloads instead, then those options can be disabled.
-- incorporated some changes which Deadwood did for 1.25 version back in past and which wasn't in our version till now, such as: Improved audio/video sync code in MediaPlayer and Free locale resources regardless of application creation.
-- one more user-agent for spoofing by request: Nintendo Wii
Github also updated with all latest changes, so SDK includes/libs also changed quite heavy, and everyone who will build latest odyssey should update all the SDK files. Also frank's ffmpeg libraries should be in the LIBS directory when you will test odyssey (take them of from beta04, or from Frank directly: https://sourceforge.net/projects/ffmpeg-amigasharedlibraries/files/
Not bad, smart move using external libs from Frank :) Maybe just placebo sensation but the old audio/video sync code patch from deadwood seems improved a little bit the video testing of html5videoplayer, expecially when reverting/forwarding the stream
Tested more and more and got this same crash almost twice, i will try to reproduce, so just have a look for now
Quote:
Crash log for task "Odyssey" Generated by GrimReaper 53.19 Crash occured in module avformat2.library at address 0x6C810420 Type of crash: DSI (Data Storage Interrupt) exception Alert number: 0x80000003
@samo I got this one randomly few times too. That function in which it crashes was private in ffmpeg and should't be used at all (but was), and so in 2.2.16 it was removed and Frank add it on top of his port , so possible it may have some bug. Will ask Frank about, maybe he will see a bug just from crashlog. Sadly it can't be reproduced very easyly (as usual wth Odyssey) :)
edit: sended mail to Frank
@pvanni Yeah, cool! Altivec made a difference then, was worth of :)
I have the feeling that the image search in google is yet way faster than before. Fine. Video plays with beta4 little faster (on X1000) i think also. I like it. Many thanks to all involved :D
@kas1e Thanks for the latest version you released. And the Nintendo Wii spoffing, thanks. Now the H.264 videos work well and in the same session going on Youtube the audio is heard perfectly. Thanks again.
Ok good Just an unrelated question, did you changed something in bookmark behaviour since the first beta 1 compared to the public version ?
I ask because i noted i'm unable to "import" the bookmark from my stable release to any of that new betas .. instead everything works fine copying the bookmarks.html file from a beta to another (tested in all versions) ... when i open the bookmark from OWB i can see my saved links, but all the old links i saved with the public version cannot be read in any of that new betas
@samo Nope, didn't change anything about bookmarks, but as it was recompiled with newer GCC and since that with lots of new libraries, mixing os4depot version and new ones is bad idea.
Maybe you just find some bug in "importn" fucntion which was hided on gcc 4.x as was with path names trashing, dunno.
News feed
OS4 Feedback forum
OS4Depot Feedback 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
Donate
