In Rilievo Bitrate e parametri vari dei canali Tivusat

isr2002 ha scritto:
Per il soggeto risoluzione Marcopolo:


Il flusso catturato e .ts oppure .avi?
Clicca per espandere...

Il flusso video/audio così trasmesso è trasmesso in contenitore .ts. Quindi di norma è catturato in ts nativo.

Alcuni decoder permettono di reincapslulare il flusso a/v al volo in altro contenitore su pennetta o HDD usb (esempio: .mpg o in un nuovo .ts stesso; oppure in un contenitore in formato proprietario del decoder che si usa). Per cui il file memorizzato su chiavetta potrebbe anche essere .mpg (= mpeg program stream), dipende dall'opzione scelta nel menu di registrazione del decoder, ammesso che permetta tale scelta.

In avi non credo esistano decoder che lo facciano... E' un contenitore comunque obsoleto. Viene usato ancora come file d'archivio (io lo uso molto per acquisizioni da VHS o riconversioni in codec Xvid/MPEG-4 per mantenere retrocompatibilità con vecchi lettori dvd che supportano MPEG-4 in AVI ma non MPEG-2 in avi).

In ogni caso non c'entra nulla il contenitore con la risoluzione usata che 'risiede' nel flusso video elementare ( .m1v, .m2v, .m4v, .h264 ... per usare le estensioni di solito usate su pc).
 
Ultima modifica:
Certo che vedere mp2 a 64Kbit ci vuole coraggio [emoji14] , spero sia in mono [emoji23] [emoji23] [emoji23]
 
Amici, ho fato anch'io il test di registrare e poi verificare il file con VLC. Avete raggione, mi mostra 720. Scuse perche ho insistato cosi'.
Comunque, il ricevitore, un Vu+Solo2, continua a mostrare 704. Non capisco perche. Ci sono anche altri programi TV che sembrano avere la stessa risoluzione (TVR International, sempre su Hotbird, per esempio).

29100h4.jpg
 
1) Scusa se ti rifaccio la domanda (banale). Ma hai riprovato a cancellare il canale e ricercarlo e memorizzarlo? Credo che non tutti i ricevitori "aggiornino" l'informazione della risoluzione memorizzata se questa cambia... così come forse altri parametri. ;)

2) Non sono sicuro, ma forse la risoluzione può essere memorizzata anche altrove (nel ts) oltre ad essere insita nel flusso video elementare (in questo caso h.264) ... Può darsi che il tuo decoder si basi su un dato nominale riportato a quel livello (che in questo caso è trasmesso con un valore diverso - errato - da quello reale)... senza fare un'analisi più effettiva del flusso. Ma non conoscendo a fondo il DVB è solo una mia ipotesi...

Il punto 1 sicuramente si può appurare facilmente ;)

e ... 3) E' un bug del software del decoder magari dovuto a una "combinazione" di parametri... o altro.
 
Ultima modifica:
Anche secondo me come consigliato da @S7efano una volta eliminato il canale e riaggiunto dovresti essere ok :) facci sapere! ;)
 
Ci sono decoder che mantengono il dato vecchio del canale rilevato in fase di sintonizzazione, altri invece aggiornano la risoluzione in tempo reale.
Stessa cosa vale per l'ID del canale, molti non aggiornano il nome del canale, bisogna risintonizzare, o cancellarlo e rifare la ricerca della frequenza. Altri invece basta fare zapping e passando sul canale, viene rinominato in automatico.
 
Rai 4K: (LCN 210)
Video: 25,90 - 25,93 Mbps / 16:9 / HEVC / 3840x2160p
Audio 1: AC3 2.0 128 kbps (Stereo)
Audio 2: AC3 5.1 192 kbps (Dolby)
 
Andydj ha scritto:
Sempre 704 , il dream legge quel valore dal flusso . Infatti su alcuni canali che variano la risoluzione ho sempre visualizzata quella attuale
Clicca per espandere...

Scusa non capisco. Se lo leggesse dal flusso (video) allora il valore si aggiornerebbe in automatico, o perlomeno indicherebbe quello corretto riscansionando e rimemorizzando il canale. Se il valore sballato è dovuto a qualcosa di inviato errato allora lo legge da qualche altro parametro del DVB o del TS, ma non ricavandolo dal flusso video vero e proprio (h264 in questo caso). Altrimenti, più probabilmente secondo me è un errore del firmware del decoder: per qualche motivo su questo canale (e potenzialmente su altri) lo 'calcola' in modo errato...
 
Il Digiquest che è un decoder semplice ed essenziale riporta la risoluzione corretta e in tempo reale premendo due volte info, il Clarke Tech proprio non riporta quei valori. Sempre il Digiquest cambia l'id cioè il nome del canale facendo zapping sul canale o canali di quella frequenza, col Clarke invece bisogna fare una ricerca canali di quella frequenza perché si aggiorni il nome. Il Digiquest però non fornisce il valore in dB della qualità segnale ma solo la percentuale. Ogni decoder ha i suoi punti di forza e le sue debolezze, cioè anche i decoder da centinaia di Euro non sono per forza in tutto perfetti.
 
Probabilmente è un "BUG" e con il codec MPEG-4 indica risoluzioni errate ;)
Ad esempio, non so se era già stato spiegato o no, ma se salvo l'immagine da un canale MPEG-4, VLC me la salva con risoluzione 1047x576 (se 16:9) invece di 1024x576 e 785x578 invece di 768x576 (se in 4:3). Non ricordo se in passato era già stato spiegato il perchè. Non ricordo più :)
 
Guardando al volo i sorgenti di Enigma2 qui
Ho trovato un paio di cose: la prima è che come commentato da uno sviluppatore alcuni hardware, quindi alcuni box con un certo tipo di processore (e se non sbaglio il tuo come quello dell'altro utente hanno processore broadcom e potrebbere essere il vostro caso), non invalidano all'apertura del canale i dati riguardo appunto la larghezza e l'altezza dell'immagine, quindi il sistema non viene "avvisato" del cambio risoluzione e fin qui tutto combacia perchè viene letto il valore "vecchio":
Codice: 
		/*
		 * Some hardware does not invalidate the video attributes,
		 * when we open the video device.
		 * If that is the case, we cannot rely on receiving VIDEO_EVENTs
		 * when the new video attributes are available, because they might
		 * be equal to the old attributes.
		 * Instead, we should just query the old attributes, and assume
		 * them to be correct untill we receive VIDEO_EVENTs.
		 *
		 * [B]Though this is merely a cosmetic issue[/B], we do try to detect
		 * whether attributes are invalidated or not.
		 * So we can avoid polling for valid attributes, when we know
		 * we can rely on VIDEO_EVENTs.
		 */

Ma, per ovviare al problema, e aggirarlo, hanno dovuto andare "a pescare" i dati direttamente richiamando le api DVB ( infatti viene chiamato il metodo
Codice: 
[URL="https://linuxtv.org/downloads/v4l-dvb-apis/uapi/dvb/video-get-size.html"]int ioctl(int fd, VIDEO_GET_SIZE, video_size_t *size)[/URL]
) (metodo che tra l'altro nelle ultime versioni del kernel linux è deprecato). Però è evidente che anche in questo caso viene proposta la vecchia risoluzione: vuoi perché legge un valore in cache o vuoi perché chi ha prodotto i driver lo ha implementato male .
Al posto vostro quindi se ci "tenete" che funzioni come deve potreste aprire una segnalazione qui descrivendo il problema ( ovviamente in inglese meglio specificare :p ) però se non avete mai fatto debug e collezionato log lascerei stare.
I box basati su enigma e in generale linux sono dei piccoli gioiellini, hanno un sacco di funzioni e permettono di fare un sacco di cose. Per questo "problemuccio" non ci perderei il sono: sapete che per queste cose (risoluzione framerate) vi conviene registrare quei 10 secondi di video e analizzarlo poi col pc e non affidarvi all'OSD. :) ;)
 
Ho eliminato il programma, poi resintonizzato. Sempre 704. Ho letto il post di anthontex. Ha ragione: lasciamolo stare :)
Comunque, mi si e rotto il H-H (Stab) :-(
 
Devi accedere o registrarti per poter rispondere.
Indietro
Alto Basso