An original MP4 video (360p) directly converted in FLV format (240p) with SMTube ---------------------------------------------------------------------------------------------------------------------
Through by "distored audio" i assume you mean whole video plays x2 fast instead of original speed. Just watch more than first seconds, and you will see that video are x2 fast together with audio. Something in mp4 codec in that old core of mplayer i use then.
@samo Found: that distored audio (in reality dbl speed), caused when we use ahi audio output. If we use ahi_dev, all is fine. So its ahi output which cause problems, and now i start to remember that somewheer on aw.net fab says that there was indeed bug in ahi output which he fix in his latest builds. Through i do not know what, can only guess. But in end of all can just reuse version from google-code.
It seems that google code just didn't have any ahi outputs at all ! Not low level, not hi level ones. I checked all mplayers we have , and afxgroups one just use pure SDL output only. Liveforit's one use ahi_dev from Fab's code and works ok because just by default ahi_dev in use.
So, bug is in ahi output, but checking fab's changelog on mplayer i can't find anything which come after year 2010 which can fix that (instead, i found in year 2008 some comment about that, but code i have are from 2010 or something, so past of that date).
It just didn't happens in our previous versions because none of them have ahi output, just lately liveforit re-use fab's ahi_dev.
@Fab Maybe you can point out what to fix in ao_ahi.c to avoid dbl-speed of sound/video if you fix that already ?
Now, this double speed issue is old and fixed since several years. It was triggered with mono audio tracks (this format was not properly handled by the ahi audio ouput). So if you don't have a recent enough version of mplayer, the easiest solution is to force the audio output to stereo, using -af format=s16be or whatever.
But i tried:
ram:> mplayer -af format=s16be ram:test.mp4
and still dbl-speed is here.
Also read in changelog from year 2007 :
Quote:
10.11.2007 - Fixed a long standing bug in ahi audio code: mono signal was never handled properly by MPlayer ahi driver, but in older MPlayer versions, signal was always passed as stereo (and thus it always sounded correctly), which changed since 1.0pre8 or so. This should fix the "too fast audio playback" in video files coming with a mono audio stream.
@Thematic
-afm faad help indeed. But i still want to fix it ahi output itself, so it all will be fine everywhere.
Through by "distored audio" i assume you mean whole video plays x2 fast instead of original speed
Yes sorry, problem is exactly that (dbl speed)
Quote:
Found: that distored audio (in reality dbl speed), caused when we use ahi audio output. If we use ahi_dev, all is fine
Yes confirmed
Quote:
It seems that google code just didn't have any ahi outputs at all ! Not low level, not hi level ones. I checked all mplayers we have , and afxgroups one just use pure SDL output only.
So it means that in MPlayer version (i mean the original one from afxgroup) even if we are using a p96_pip in reality we are still using SDL for the audio output ?
Or just he didn't upload in Google site his full source of the AHI audio part ?
Aniway some spare considerations about both graphic and audio issues:
- This problem with the Audio seems affected only the MUI version of MPlayer, in my experience i never note such issue with the Afxgroup/LiveForIt versions (atleast for sure i never seens it on the Andrea's version using it in many years)
- In both versions (the MUI one and the old Andrea version) sometimes we have such graphics corruption, just they are not always the same, it means that sometimes a video that is corrupted in MUI version seems fine on the afxgroup version and viceversa
- In MUI version and with the MP4 files (and maybe with FLV aswell) such graphic problem is reproducible also playing with the Video/Rotate functionality
@samo mplayer have different outputs for video and audio
for list of video drivers: mplayer -vo help for list of audio drivers: mplayer -ao help
so you can see yourself what support what
afxgroup's one: audio output sdl by default and no ahi outputs. liveforits one: sdl and fabs ahidev output, micks - sdl only. and only muimplayer have normal native outputs for audio - ahi and ahidev. ahi output just have some bug which fab already fix seems so, ahidev didnt. by default pure ahi output in use so you meet with that bug. in others mplayers you didnt have it as it use sdl (slower) audio outputs, or as in case with liveforits version it use fabs ahidev which ok too.
ie you can have any mix : p96 for video and sdl for audio or sdl for video and ahi for audio. just defaults different.
Joerg are working on it because another unrelated issue, but i point him to this thread, hopefully he can found a method to fix also the twice speed issue with the audio
Double-speed issue is in ao_ahi.c output, not in ao_ahi_dev.c which joerg and liveforit use now. I.e. in another audio output which in no use in their builds. With ao_ahi_dev.c output muimplayer have no problems too.
I can't fix anything for which the sources aren't available. Since ahi_dev is broken as well I might implement something completely new instead, but only after I finished the video output and that will take some time, for example my current vo amiga version is only usable on Voodoo, Radeon and RadeonHD gfx cards, but not on SM502 (Sam460ex) and most classic Amiga gfx cards yet.
Differences between ao_ahi and ao_ahi_dev is that "ahi" is default driver and uses music unit (exclusive mode) and "ahi_dev" uses device mode (means it can be shared). For sake of choice having both are better than just ao_ahi_dev, but then ao_ahi have problems with mono tracks: when they detected, then sound/video speed is doubled.
Try to add that pure ao_ahi to your build as well (will be the same easy as with ao_ahi_dev), and check with that new audio output from that link http://www.sendspace.com/file/wykoqd, MP4 video : you will see that speed of audio/video is doubled, while with ao_ahi_dev all is fine.
Since ahi_dev is broken as well I might implement something completely new instead
Well define it as "broken" it's probably a strong term, it maybe need only a little fix
Quote:
but only after I finished the video output and that will take some time, for example my current vo amiga version is only usable on Voodoo, Radeon and RadeonHD gfx cards, but not on SM502 (Sam460ex) and most classic Amiga gfx cards yet.
Good news
@kas1e
Quote:
Try to add that pure ao_ahi to your build as well (will be the same easy as with ao_ahi_dev), and check with that new audio output from that link http://www.sendspace.com/file/wykoqd, MP4 video : you will see that speed of audio/video is doubled, while with ao_ahi_dev all is fine.
Tested both videos of my test with the latest "mplayer-joerg-beta7" and all seems fine (audio in mp4 file and video in flv file)
However, while video works normally, instead the OSD slider looks bad with the flv file, see grab:
@samo But i already told you: joerg and liveforit use one single audio ahi driver output (i don't take sdl in account): ao_ahi_dev. Muimplayer have more than one, it have 2: ao_ahi_dev and ao_ahi. And i explain their differences and why there is good to have 2 , and not just one.
In muimplayer ao_ahi is default one, and have that "dobule-speed" bug. Of course joerg's or liveforit's builds didn't have it, they use ao_ahi_dev which do not have that bug.
Going sucky and easy way like removing ao_ahi from muimplayer port, but keep ao_ahi_dev only, or make ao_ahi_dev to be default one, kind of suck and not fix, but ugly workoround.
I mean, why you in surprise that joerg's or liveforit's build didn't have that bug, if, they dont use second output driver at all, and only use ao_ahi_dev ?
But i already told you: joerg and liveforit use one single audio driver output: ao_ahi_dev. Muimplayer have more than one, it have 2: ao_ahi_dev and ao_ahi. And i explain their differences and why there is good to have 2 , and not just one.
All right
In general for now i will make in standby any discussion about the MUI version just to avoid other confusion (once Joerg and LiveForIt will complete their work then all usefull parts can applied later in your MUI port aswell no ?)
To be honest actually my "concern" is about the other 3 different versions:
- Afxgroup version - LiveForIt version - Joerg version
All that 3 are different, sometimes they share the same code, sometimes one is better in a specific area while the others not, sometimes a version have somethings not availible on the other etc .. and sometimes they even rewrote a specific part that was already done ..
To help the future merge I wonder if it could be a good idea to open a new thread just to collect all that differences between that 3, to organize better the whole work of our devs etc .. what do you think ?
As I see it I'm working on the AfxGroup version, but maybe I'm wrong. Joerg’s version I understand will be merged when the repo when its updated to the newest mplayer code base.
Now about differences, my idea is to standardize the vo_* so they share as mutch as possible, this is way my vo_p96_pip is using cgx_common.c, I'm going to rename that file gfx_common.c not done so yet.
Then when that is done, I'm going to make templet for GUI's or take a peek at the stuff in GUI directory and see whit done already.
Some thing like
OpenGui() CloseGui() do_GUI_Events()
it's not 100% clear what name should be used or if should use function pointer to abstract the GUI so you can switch GUI while application runs or not, but lets see when we get there.
But the aim here is that we should be able to have Reaction GUI, MUI GUI, Custom GUI's working, and all vo_* should able to use any GUI you like.
This is the direction I like to take Mplayer.
Also to be clear all my changes will go into code.google.com repo, that also includes vo_comp.
When it comes to vo_*, I do not belive in one output driver for all, I think its easier for every one if vo_* is as simple as possible whit out over complicating it.
I believe in gfx_common.c (or cgx_common.c) as back end for everything.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
@samo Afxgroups version: is that version on google-code, on which LiveForIt works. That version contain old mplayer core, and that reasons why joerg do not want to submit new vo_p96_pip there. Backporting through should be easy even to that old core (same as was in case with all that audio output drivers, etc), but probably we will be unable to convince joerg to loose time on backporting to old core.
To be honest, i think it was just wrong to release new version with liveforit fixes as "mplayer-liveforit". It should be released as "mplayer" and version on os4depot from afxgroup should be just replaced by it. And that all. No need to call it "liveforit-mplayer", enough to put credits to text file, to avoid mess. It is the same version from afxgroup, just updated by few fixes and vo_comp.
Probably renaming can be done if he will ask Orgin to sort it all , and to avoid user's mess, if liveforit will ask for that. I.e:
1. rename "mplayer-liverofrit.lha" to "mplayer.lha" 2. replace by this old mplayer.lha (that one on which afxgroup works , and which he put on google-code, and which _is_ that mplayer-liveforit). 3. add to readme that its version from google-code, and which was before as afxgroup one, and later liveforit start to works on it.
That will be a start to structure that chaotic ego mess. At least no one will ask what is afxgrops version, what is liveforit version, what is google-code version. Readme will containt all the info : i.e. that version from google-code page, before agxgroups works on it, laterly other ppls contribute, and there is new version with those changes, and no problems.
But probably there will be another explain why we need to have another name and make users be crazy :)
Joerg version: he works on pure latest version of mplayer taken from official original mplayer repo (week or so old). I.e. no amiga native code, nothing at all, pure mplayer. Just now with his new p96_pip output, and ao_ahi_dev taken from muimplayer. But no arexx, or whatever used for example in google-code version (afxgroup-liveforit one).
Varti repo: another repo, where Varti put latest svn's mplayer code and just upload amiga files, but nothing connected, not code done.. I.e. nothing important, just code is here. Why he not do the same on that google-code page where afxgroups version placed and on which liveforit works: i do not know. Probably to avoid mess. Probably he want to make another branch later, and that "sandbox" repo used as tests, or maybe just to give ability to Joerg to share his new vo_p96_pip , or maybe he want to make all from scratch again. Ask Varti :)
muimplayer-morphos-port: once vo_comp from liveforit and new vo_p96_pip from joerg will be shared, i can add it to muimplayer with no problems. Probably, if Fab will give "ok", mui gui code can be also commited to some standard repo later, but he may say "not ok" too, and then there will be still 2 versions: our shared one with all the stuff, and port from morphos.
But at least 2 is better than 10. And, of course, only if ppls will release that we need 1 single repo, with one single release name, and all commiters will works on it only. Because if not, and if i were fab, i never ever will say 'ok' to put my code to that mess.
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
Donate
