YAVDR 0.2

[persat]

.. grazie Fritz,

ho provato a reinstallare come dici, ho anche applicato la patch per il flusso TS-eac3

http://xine-lib.alioth.debian.org/patch ... te_decoder sul demuxer

Ora faccio qualche test poi ci sentiamo.

Ciao !!

[persat]

.. non va

continua a freezzare su alcuni canali HD.
Config ccorretti.

Sembra che il problema sia legato al "buffer overflow on Device X" che appare in log proprio quando il buffer si satura.

E' sicuramente un problema di xine-lib, appena posso lancio un trace e vediamo se riusciamo ad eliminarlo definitivamente.

P.S sulla mailing list molti altri hanno lo stesso problema.

Ciao

[persat]

Risolto !!!!!!!!

CXXFLAGS

[lukkino]

Risolto !!!!!!!!

CXXFLAGS

e che hai fatto alla variabile CXXFLAGS? che parametri hai messo? tanto per capire anche noi

ciao

[von fritz]

gia'

che versione nvidia-vdpau (libvdpau) usi?

bye

[persat]

nvidia : 256.53

CXXFLGS x Atom : CXXFLAGS = -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -mfpmath=sse -march=atom -msse -msse2 -msse3 -mtune=atom -pipe -fomit-frame-pointer


Vorrei però capire perchè sul sito tedesco dicono che la versione V15 della patch senza lo "stream" è buggata vedi questo link :
http://vdr-portal.de/board/thread.php?t ... =0&page=35

sembra che si debba patchare con lo stream, tuttavia se applico la "stream" scatta.

Ora andrebbe modificata la patch vdpau_h264.c

NON riesco ad applicarla correttamente in : ..../src/videodev/libvdpau/vdpau.h264.c

Questa dovrebbe essere la soluzione definitiva.

Inoltre sempre nello stesso link si parla della patch per l'overflow, anche qui vorrei sapere dove si trova "inputsoftdevice.c"


Grazie a tutti per l'Aiuto

A presto

[persat]

.. ho un sospetto, ma ho bisogno di un vs. aiuto.

Dopo vari test e letture ho provato a scaricare la versione vdr-xineliboutput-cvs-20100719 e la patch : xineliboutput-cvs-20100117-vdpau-extensions-v11.diff

lancio il tutto e noto uno strano "scatto" dopo pochi secondi, poi TUTTO OK nessun buffer overflow !!!! (a parte il primo)

Mi domando come mai, forse il CVS del xineliboutput contiene errori, o magari non è "allineato" alle xine-lib-1.2.

invece .....

vado in /home/pippo/.xine/config_xineliboutput e vedo che engine.buffers.video_num_buffers = 200 !!!!! (meno del default)

la cosa strana è che con questo valore FUNZIONA SENZA SCATTI.

ora il sospetto è che il motore vdr-xineliboutput (la parte local) legga il config in un punto diverso da forntend, e il valore TROPPO ALTO DEL BUFFER sul lato frontend generi uno scostamento dal frame-rate HD !!!!! tradotto :

buffer overflow on device 1

Ora vi chiedo, quale config legge la parte vdr-xinelibout (quella che gira dentro il vdr per capirsi "-L none" ) e soprattutto quale config legge il frontend (vdr-sxfe remoto)


Ciao

[von fritz]

CUT

Vorrei però capire perchè sul sito tedesco dicono che la versione V15 della patch senza lo "stream" è buggata vedi questo link :
http://vdr-portal.de/board/thread.php?t ... =0&page=35

sembra che si debba patchare con lo stream, tuttavia se applico la "stream" scatta.

Ora andrebbe modificata la patch vdpau_h264.c

NON riesco ad applicarla correttamente in : ..../src/videodev/libvdpau/vdpau.h264.c

Questa dovrebbe essere la soluzione definitiva.

Inoltre sempre nello stesso link si parla della patch per l'overflow, anche qui vorrei sapere dove si trova "inputsoftdevice.c"


Grazie a tutti per l'Aiuto

A presto

buggata se ti riferisci alla xine-0.9.3-vdpau-extensions-v13.1.diff che aveva il problema di un "buco" di memoria sistemato poi con la v13.2.diff o alla "dimenticanza" :

--- vdpau_h264.c.orig 2010-06-13 21:23:35.000000000 +0200
+++ vdpau_h264.c 2010-06-14 10:43:21.000000000 +0200
@@ -582,6 +624,66 @@
+ if(firstpts == 0)
+ firstpts = this->completed_pic->pts;
+ else if(firstpts != -1)
+ {
+ if((this->completed_pic->pts + 60000) completed_pic->pts - 60000, firstpts);
+
+ firstpic = 1;
+ free_parser(this->nal_parser);
+ this->nal_parser = init_parser(this->xine);
+ //dpb_free_all( (this->nal_parser->dpb) );
+
+ }
+ else if(this->completed_pic->pts bitstream) != NULL)
+ free((uint8_t*)vdp_buffer->bitstream);
+ printf("--> skip frame...\n");
+
+ return 0;
+ }
+ else if(!slc->field_pic_flag /*|| !this->wait_for_bottom_field*/)
+ firstpts = -1;
+
+ }

poi sistemata anche quella con le ultime v15.diff
resta il problema che la parte stream-start crea i fastidiosi freez nella visione dei HD "nostrani".
mi viene un dubbio, tu ti stai riferendo alla yavdr vero? yavdr usa le vdpau 195.30

ritornando in tema yavdr.
Allora come preannunciato, se si fa un :

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

yavdr aggiorna alla 0.3

Pero', ci sono dei problemi riscontrati oggi, anzi adesso.
riavviato dopo l'aggiornamento e niente audio.
verificando da interfaccia web a parte la prima schermata che adesso si presenta in 2 parti : configurazione e vdr-live
selezionando la pagina di configurazione mi visualizza solo una schermata blu vuota.
ho notato pero' che durante l'upgrade non mi aggiorna il pacchetto yavdr-essential nemmeno con apt-get dist-upgrade.
dunque vado di apt-get install yavdr-essential pero' dopo l'avvio niente interfaccia web di configurazione.
penso che sia ancora prestino per "rischiare" un upgrade
mi sposto nel thread yavdr 0.3 visto che ormai la 0.2 se ne sta andando

bye

[persat]

appena possibile ti aggiorno, ho risolto tuttooooooooo

controparte : è difficilissimo !!!!!

non esiste una regola, ma tutta una serie di parametri che seguono esattamente il tuo hardware specifico.

il mio vdr (lato server -LOCAL) adesso regge un transfert di 18 Mbs !!!!!! con cpu mai oltre il 18% per CPU intendo 1 core e non la media dei 4

Super

Nessun problema AUDIO
Nessun Freeze
Nessun problema Video



Due settimane di lavoro