E quel monello (in senso buono) di EMG che voleva chiudere la baracca ;) Inviato da Gennaro Montedoro Il giorno 15/dic/2011, alle ore 19:36, Alessandro <alessandro.poppi@xxxxxxxxx> ha scritto: > On Thu, 2011-12-15 at 15:30 +0100, Eugenio Ciceri wrote: > >> Di seguito riporto un esempio di come si presentano i dati in due >> pacchetti video consecutivi: >> >> 00 C0 <-- indirizzo di destinazione dei dati video >> BE <-- lunghezza del pacchetto video data da $fe - (2 * lenght) >> 80 <-- campione audio >> AA AA AA AA AA BA 0E EF >> FF FF 8F FF FF FF FF FF >> FF FF FF FF FE 3F FF FF >> FF FF FF FF E2 EB BB FF <-- pacchetto video >> 20 C0 <-- indirizzo di destinazione dei dati video >> BE <-- lunghezza del pacchetto video data da $fe - (2 * lenght) >> 83 <-- campione audio >> AA AA AA AA AA BA 3E EA >> FF FE 3F FF FE 8B FF FF >> FF FE BF FF FE 3F FF FF >> FF FF FF FF EA 8B AB FF<-- pacchetto video >> >> Quindi non capisco da dove potrebbero arrivare dei bytes spurii e >> soprattutto perché dovrebbero interferire proprio con l'audio e non >> con il video. > > Perfettamente d'accordo che se l'audio e' intercalato nel video ed il > video funziona, non ci sono sfasamenti nella lettura dovuta ai bytes in > piu' (che la card gestisce a livello di protocollo interno, ce li mette > proprio la sua logica di gestione). > > E' tuttavia altrettanto vero che se i campioni hanno tutti D4 a zero ma > forzandolo a zero il risultato cambia, vuol dire che il byte letto non > aveva D4 a zero :-) > > Sapendo che ogni campione audio ha tassativamente D4 a zero, potresti > trappare nel software un BSOD in caso di lettura di un byte con D4 '1' e > dirci il risultato, ad esempio il contesto in cui si trova quel campione > all'interno dello stream e andare a vedere se era proprio cosi'? > > Ciao! > > >