Newsgroup: it.comp.os.amiga
Titolo: Beta di player divx per Amiga 68k (possibilmente emulato JIT)

Spinto da un paio di mail del NG ho fatto un veloce porting del player 
crossplatform che ho scritto per AmigaOS 68k, volevo farlo anche per 
MorphOS, ma ho ancora problemi con gli header e le librerie del 
crosscompiler ppc.
Non ho potuto testare il player, ma non penso che sia in grado di 
visualizzare a velocita' accettabili i divx su amiga reali, forse giusto 
divx francobollo 352x188 su 060.
Il test principalmente e' rivolto a chi usa emulatori JIT quali Amithlon 
o le ultime versioni di WinUAE.
Okkio che non avendo al momento un'installazione di uae funzionante sul 
pc in ufficio non ho potuto far nessun tipo di test sul funzionamento 
del binario, per questo vorrei qualche "report", non escludo che non 
parta neppure, anche se la libreria SDL su cui e' basato e' ormai 
stabile e testata su Amiga.
Il programma necessita di WB in 16+ bit (cgx o p96) e AHI per l'audio.
Va lanciato da shell, per vedere i parametri:
play -h
Sicuramente lo stack standard della shell non basta quindi prima di 
lanciarlo date uno "stack 500000" per sicurezza.
Ah, dimenticavo il link al binario:
http://ggreco.interfree.it/bin/play.lha
Bye,
  Gabry

 divx francobollo 352x188 su 060.
Riesci a fare anche una versione per WarpOS PPC? In questo modo dovresti
rimanere comunque compatibile sia con MorphOS che con AmigaOS4.
Poi quanto vorrai potrai sempre fare delle versioni native.
Per la velocità.. beh sono proprio curioso di vedere a quanto va su una
cyberstorm con 604@233!

 cyberstorm con 604@233!
Probabilmente senza frameskip per i divx 352x288 e a scatti su qualunque 
cosa di piu' grosso.
Il player e' quello di cui parlavo in un altro thread, ha anche una 
modalita' di benchmark senza "video" di mezzo.
Bye,
  Gabry

 versione finale.
Aspè! Guarda quà
http://amigaworld.net/modules/fleecymoss/index.php?cat_id=15
In particolare Q&A numero 8.
A questo punto fregatene dei context-switch (che saranno di fatto
inesistenti sia su AmigaOne che Pagasos) e compila per WarpOS, ti troverai
un eseguibile compatibile per entrambi i sistemi.
Anche se non ottimizzato per nessuno di essi è già un inizio ;-)


http://ggreco.interfree.it/bin/play.lha
mi mi fa scaricare, dice che è impossibile accedere al sitio :(

  Gabry

 Anche se non ottimizzato per nessuno di essi è già un inizio ;-)
"We'll provide an application launcher that can launch WarpUp programs"
Beh, scusa, secondo me è meglio lasciarlo (al momento) in codice 68K e farlo
andare in emulazione.
Poi, se vuole, lo ricompila/adatta in codice PPC (via gcc) per AOS4 e/o
MorphOS; in questo modo evita di aggiungere codice per gestire i
context-switch ed i sorgenti continuano a rimanere portabili.
MastroK

divx francobollo 352x188 su 060.
Ma che versione di DivX?
-- 
"Vi e' felicita' per chi accetta il proprio destino,
vi e' gloria per chi combatte il proprio destino."


http://ggreco.interfree.it/bin/play.lha
Io non lo riesco a scompattare.. :(
Andrea



Gabriele, l'archivio č difettoso...:(

 >divx francobollo 352x188 su 060.
e in 416x400? :)

 context-switch ed i sorgenti continuano a rimanere portabili.
Non č necessario riarrangiare il codice per i context switch perchč tranne
che sulle vecchie cyberstorm o blizzard questi per fortuna non esistono piů.
A regola su OS4 o MorphOS il context switch da 68k<->PPC verrŕ praticamente
ignorato o comunque sarŕ gestito in maniera molto piů leggera (qualcuno ne
sŕ di piů in proposito?).
Credo sia necessario solo utilizzare gli include giusti ed aprire la
powerpc.library il resto viene da se, poi non so l'ultima parola comunque
spetta al bravissimo Gabriele.

 e in 416x400? :)
Dimensione non standard. Artefatti in codifica dovuti ai resti della
DCT, trascinamento al bordo se si attivanmo i B-Frame... non sarebbe
comunque una buona idea :-)
Marco

 Io non lo riesco a scompattare.. :(
Dunque sembra che l'archivio fosse scompattabile solo dall'lha di unix o 
dalle ultime versioni di winrar...
Di conseguenza l'ho rimosso ed ho messo un archivio .zip:
http://ggreco.interfree.it/bin/play.zip
Questo dovrebbe essere scompattabile con qualunque versione di zip o 
winzip, scusate l'inconveniente, non ricordavo che lha x amigaos fosse 
rimasto cosi' indietro...
Bye,
  Gabry

 spetta al bravissimo Gabriele.
Non e' cosi' semplice, ho fatto il porting di SDL su WarpOS un paio 
d'anni fa, ma era tutto tranne che veloce. In pratica la versione WarpOS 
su 604e/180 in certi casi era piu' lenta della versione 68k su 060 e 4 o 
5 volte piu' lenta di quella MorphOS....
Comunque anche volendo non potrei farla in quanto il gcc che compila 
codice warpos e' un hack e, oltre a non essere aggiornato da parecchio, 
non si riesce a ricompilare come crosscompilatore.
Bye,
  Gabry

 
http://ggreco.interfree.it/bin/play.zip
Ok, adesso l'ho scompattato (winzip)
MastroK

   Gabry
Con "Unarc" di  Amiga OS 3.9 non ho avuto alcun problema a scompattarlo
Ciao
Giovanni

 Con "Unarc" di  Amiga OS 3.9 non ho avuto alcun problema a scompattarlo
Allora probabilmente il problema e' nel web server di interfree, che 
probabilmente non conosce l'lha e se il browser pensa che il file sia 
testo ci aggiunge i CR corrompendolo...
Comunque lo zip, essendo comune su PC, non dovrebbe dar problemi. Non lo 
metto su Aminet perche' non ho potuto testarlo in alcun modo...
Bye,
  Gabry

 ha scritto nel messaggio
news:wKuOa.8181$79.1...@tornado.fastwebnet.it...

Con lo 'Storm C' è abbastanza semplice creare eseguibili per WarpOS diciamo
che fa tutto lui basta solo impostare le caratteristiche del progetto
all'inizio tra codice 68k, ppc, mixed binary etc.. ;-)
Che intendi dire quando parli di chiamate alle funzioni? Parli di asm o C?

 Che intendi dire quando parli di chiamate alle funzioni? Parli di asm o C?
Stiamo parlando di un progetto che genera 1.2mega di eseguibile, che 
contiene al suo interno un decoder mpeg1, un decoder mpeg4, un decoder 
mp3, un decoder ac3, un decoder wmv, un decoder wma, un decoder mpeg2, 
ecc, ecc. Dentro c'e' il lavoro (opensource) di centinaia di 
programmatori.  Il player e' ovviamente solo la punta dell'iceberg, 
l'assembly in un progetto cosi' grosso viene usato solo per piccole 
porzioni del codice ed in ogni caso all'interno del codice C. Le 
librerie hanno codice per usare l'MMX o l'altivec e ottimizzazioni in 
assembly ia32/alpha/ppc in diversi casi, ovviamente nel caso della 
compilazione amiga viene usato sempre e solo il codice in C.
Sinceramente a volte quando leggo certe risposte mi sembra che questo 
newsgroup viva fuori dal mondo, il fatto che lo storm permetta di 
generare mixed binaries e' significativo quanto il numero di scarpe del 
lead programmer originario del progetto ffmpeg...
Il sorgente delle librerie e' in C abbastanza standard (C99 direi), ma 
anche se fosse perfettamente standard dubito che un compilatore buggato 
come lo stormc possa riuscire a generare del codice funzionante senza 
modifiche, per esempio di sicuro avrebbe problemi con gli interi a 64bit 
(long long) che vengono utilizzati abbastanza spesso nella libreria.
Non parlo a caso, nel '97 quando siamo partiti come Hurricane per 
scrivere Eat The Whistle abbiamo acquistato lo StormC originale, in 
quanto il SASC non era piu' supportato, nonostante i nostri tentativi 
abbiamo poi usato il SASC per la versione release del gioco, lo StormC 
era semplicemente troppo buggato. Anche Hyperion i suoi giochi 
nonostante usino WarpOS li compila con il GCC e non con lo Storm, e non 
e' perche' sono fissati con il "gcc". L'unica cosa che ha di carino lo 
storm (e nemmeno tanto se il progetto diventa troppo complicato) e' il 
project manager che ti crea le dipendenze in modo automatico ed il 
debugger grafico, per il resto ha sempre generato codice mediocre. 
L'ultima sua incarnazione poi che senso di esistere ha? Perche' pagare 
soldi per un ambiente grafico che si basa su una versione vecchia del gcc?
Se vuoi provarci tu a compilarti il programma con lo storm i sorgenti li 
trovi all'interno del ramo contrib di AROS (contrib/play), compresi di 
librerie avcodec e avformat, se otterro' qualche report che mi dice che 
il player funziona magari poi preparo un archivio per aminet con 
sorgenti e documentazione.
Auguri comunque, probabilmente ti fermeresti prima ancora della 
compilazione in quanto non penso che il project builder dello storm sia 
in grado di replicare le dipendenze e i vari simboli di compilazione 
presenti nei vari Makefile che compongono il progetto, certo con alcune 
ore di hacking sui sorgenti riusciresti a INIZIARE a compilare, ma a che 
pro? Per avere un codice piu' grosso, piu' lento e piu' buggato?
Bye,
  Gabry

 sorgenti e documentazione.
Ci faro un salto !
(Li aggiungo a quelli di AWeb :-p )
Alessandro

rimasto cosi' indietro...
Infatti poi si e' preferito lzx...almeno io usavo quello^_____^;;;;;;


 lead programmer originario del progetto ffmpeg...
I mixed binaries non c'entrano nulla con questo porting ovviamente il mio
era un riassunto delle caratteristiche principali dello Storm C che per
quanto possa essere buggato o mal fatto è comodo da usare.
Io consiglio lo StormC 4 in GCC mode solo per i piccoli progetti nel tuo
caso non so.. bisognerebbe provare ma onestamente vista la quantità di
codice sono scettico quanto te.



Con il mio Amy 060 ed IBrowse l'ho scaricato senza problemi, l'ho anche
scompattato tranquillamente....
Albert

rimasto cosi' indietro...
A dire il vero nemmeno WinRar riusciva a scompattarlo.. :P
Andrea

 Aweb) ha consigliato a Shinkuro di usare perchè più stabile !!!
Non solo. Nel rwadme della versione 3 su Amiga dice una frase del tipo:"
la versione 3.x del GCC su Amiga è Mooooolto lenta, soprattutto in
compilazione", e se già la 295.3 in confronto al SAS-C non è una scheggia
non voglio nemmeno provare la 3 ;-)
ShInKurO
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


http://ggreco.interfree.it/bin/play.zip
Purtroppo non sono riuscito a farlo funzionare con nessun file video:(


sconosciuto, e coi divx5 "Unable to find format of..." ;-(
i video si vedono, sono riuscisto a farli andare, anche con quello che
ho fatto con il codec 5.05, che però lui riconosce come 5.03...bah :)
Per fare andare i video ho dovuto disabilitare l'AHI, altrimenti crash
del sistema....:(
Cmq i video si vedono in tante sfumatore di verde e rosa :((

 Cmq i video si vedono in tante sfumatore di verde e rosa :((
Stai usando uno schermo a 16 bit?
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                 |     Bertrand Russell
falemagn (AT) aros (DOT) org    |     The Philosophy of Logical Atomism

sconosciuto, e coi divx5 "Unable to find format of..." ;-(
Anche a me ha dato questi messaggi con qualunque file gli ho
sottoposto:(


o le ultime versioni di WinUAE.
Provato con l'ultimo WinUae e AmigaInABox, a cui ho ovviamente
sostituito le ultime librerie AHI.
Non ho dei gran video da provare, qualche mpeg a bassa risoluzione, un
divx a 640*352 25fps come massimo.
Tutti i formati che avevo sono stati riconosciuti e visualizzati,
escluso uno stream audio wmav. (mi pare)
Partiamo dai test senza sonoro: a 16 bit la visualizzazione ha dei seri
problemi... compaiono cubettoni, trails...
Passiamo a 32bit: qua sembra andare tutto bene (ah, dimenticavo, su un
Athlon XP1600+), e' fluido, ogni tanto capita uno skip ma nulla di
evidente, peccato che.... tutti i colori sono sbagliati!
Temo sia colpa del modo grafico 1024*768*32bit BGRA, ma ovviamente
potrei sbagliarmi.
Aggiungiamo ora il sonoro: qua le cose si fanno peggiori.
Si sente, forse leggermente piu' frusciante rispetto al WMP, ma rallenta
alquanto i calcoli.
Il video diventa scattoso, e in alcuni casi si blocca totalmente, con
gli skip che volano, e talvolta dei messaggi "Buffer Video Pieno!" o
qualcosa del genere; nel frattempo l'audio continua abbastanza bene.
Ciao,
Lorenzo

Purtroppo non sono riuscito a farlo funzionare con nessun file video:(
purtroppo non sono riuscito a scaricarlo :-(
"Lately you've been painting my world blue"
- MAX - ICQ: 54491134

Stai usando uno schermo a 16 bit?
si.

Si', ma... *come* sei riuscito a farli andare? ;-)
innanzitutto stavo usando Amithlon :)
uno stack 300000 e via :)
dato che come audio su amihtlion uso la scheda audio integrata AC97
che mandava in crash play!
Ho settato ahi come paula
e play visualizzava i filmati...:)

Si', ma... *come* sei riuscito a farli andare? ;-)
mi pare vada anche con uae..

 qualcosa del genere; nel frattempo l'audio continua abbastanza bene.
Questo dipende certamente dalle prestazioni della macchina. Io non so
quanto sia esente da "anomalie" l'emulazione, ma di sicuro queste non
sono attività da emulatore :-)
Quando e se Gabriele deciderà di continuare a sviluppare questo player,
sicuramente aggiungerà il codice per skippare qualche frame quando la
macchina non ce la fa, così che il framerate sarà leggermente più basso
ma la fruizione non verrà interrotta. Sempre che ne valga la pena.
Marco

qualcosa del genere; nel frattempo l'audio continua abbastanza bene.
a me con l'audio crasha tutto il sistema :(


E quello è il problema: SDL per AmigaOS (e pure AROS e probabilmente 
MOS) non supporta bene i modi a 16 bit. E' una cosa che Gabriele sa già, 
vero Gabriele? ;)


crearti un filmatino tutto rosso e vedere se ti appare violetto o blu.
Uhm... "creare un filmatino" non rientra nelle mia capacita' al
momento... se qualcuno ha voglia di farlo, saro' lieto di testarlo.
Ciao,
Lorenzo

vero Gabriele? ;)
vabbe, cmq è una versione iniziale, fatta velocemente, credo sia già
tanto essere riusciti a farla partire :)

 tanto essere riusciti a farla partire :)
Il player non c'entra niente, è SDL il problema.


 
http://www.ce.unipr.it/~dalbello/Image1.jpg
403 Accesso Negato


403 Accesso Negato
Ops, scusate, adesso dovrebbero essere a posto.
Ciao,
Lorenzo

 
http://www.ce.unipr.it/~dalbello/Image4.jpg
Osservando le due immagini, sembrano proprio invertiti i colori a base Rosso
e Blu.
Provando, al momento, ad invertire il tipo schermo in uso RGB <->BGRA
dovresti vedere i colori corretti (con profondità 32bit)
MastroK

 sconosciuto, e coi divx5 "Unable to find format of..." ;-(
Provate a lanciarlo con -dv e postate nel NG (o in email a me) quello 
che dice il player. Come detto in precedenza non ho avuto modo di 
testarlo su amiga, ma piu' che una cosa del genere sinceramente mi 
aspettavo un crash all'avvio :)
Ricordo che e' FONDAMENTALE incrementare lo stack prima di partire, 500k 
dovrebbero bastare.
La lista dei formati supportati si vede con "-i".
Bye,
  Gabry

 qualcosa del genere; nel frattempo l'audio continua abbastanza bene.
Questo player non e' stato mai testato con macchine poco performanti, in 
particolare, usando l'audio per sincronizzare il video, e' abbastanza 
"normale" che in presenza di audio il comportamento sia quello.
Comunque sono contento che funzioni, avendo compilato alla cieca non ci 
speravo :)
Bye,
  Gabry

Il player non c'entra niente, è SDL il problema.
perchè non ti ci metti pure tu a fare qualcosa, così forse in due
potreste fare un player migliore di quelli attuali..

aspettavo un crash all'avvio :)
se non cambio le impostazioni di AHI, ho un crash all'avvio :(


Mancanza di tempo, essenzialmente, ed anche voglia.


 a 16 no.
Dipende sempre da come è organizzata l'informazione a 32 bit e di come è
organizzata quella a 16 bit. Non sono più molto frequenti (ma esistono
ancora) dei sistemi che mantengono in modo "piano" le informazioni sui
pixel quando lavorano a 32 bit (ARGB o 4:4:4 nel mondo del video) e in
modo pacchettizzato quelle a 16 bit (4:2:0 o 4:2:2 o 4:1:1). 
Adesso immagina un sistema che codifica la luminanza per ciascun pixel
ma la crominanza solo per uno (quindi uno dei due pixel prende lo stsso
valore di crominanza dell'altro). Un esempio è la compressione di tipo
"4:2:0", guarda caso quella di tutti i formati di streaming che vanno
per la maggiore. una tale rappresentazione implica che i pixel non siano
indipendenti ma condividano una parte dell'informazione necessaria a
rappresentarli: ogni pixel ha una propria luminanza ma condivide le
informazioni del colore con un pixel adiacente. 
Quando vai a convertire questa rappresentazione in RGB piano, fa una
certa differenza il poter passare direttamente ad un sistema planare
invece di dover rappresentare le stesse informazioni in un altro sistema
pacchettizzato (o chunky). Quantomeno c'è un pesante passaggio in meno.
Se la profondità colore è 32 bit puoi trattare in soluzione unica due
pixel da 16 bit per volta, evitando di doverli disaccoppiare
programmaticamente.
Marco

che dice il player.
Continua a non funzionare:(
Dice quasi sempre UNKNOWN
