Valutazione 4.87/ 5 (100.00%) 5838 voti

Condividi:        

UYVY e YUV420

Problemi di Codec - AC3, MPEG, DivX, Xvid...? Vuoi aiuto con la tua musica? Non sai come masterizzare i tuoi mp3? In questo forum tutte le risposte alle tue domande legali!

Moderatori: axelrox, m.paolo

UYVY e YUV420

Postdi Marco83 » 28/11/10 17:42

Ciao a tutti,
qualcuno riuscirebbe a spiegarmi cosa sono e come funzionano questi due formati?
Grazie mille in anticipo
Marco
Marco83
Utente Senior
 
Post: 166
Iscritto il: 12/09/06 16:32

Sponsor
 

Re: UYVY e YUV420

Postdi nikita75 » 28/11/10 19:03

sono formati per me sconosciuti !!!Ti posto qualcosa catturato in rete

YUV
Y 'sta per la luma componente (la luminosità) e U e V sono la crominanza (colore) componenti; luminanza viene indicata con Y e luminanza da Y '- i simboli primo (') denotano la compressione gamma,[1] con "luminanza "significato percettivo (scienza del colore), luminosità, mentre "luma" è elettronica (tensione del display) luminosità.

Il YPbPr modello di colore usato in analogico component video e la sua versione digitale YCbCr usata nel video digitale sono più o meno da esso derivati, e talvolta sono chiamati Y'UV. (CB/ P,B e CR/ P,R sono deviazioni dal grigio su blu-giallo e ciano-assi rosso, mentre U e V sono di colore blu-luminanza e-luminanza differenze di colore rosso.) Il Y'IQ spazio colore utilizzato nella analogico NTSC sistema di trasmissione televisiva è ad esso correlati, anche se in un modo più complesso.UYVY vs YUY2
I formati video su Windows sono descritte principalmente da un "codice a quattro caratteri", o FOURCC in breve. Mentre la maggior parte descrivere formati compressi come Cinepak e varie MPEG-4 varianti, FOURCCs sono assegnati anche per formati compressi YCbCr che non sono supportate nativamente dal regolare GDI API grafiche. Questi FOURCCs vengono utilizzati per consentire codec video di riconoscere il proprio formato per fini di decodifica, oltre che per consentire a due codec ad accordarsi su un formato di scambio comune.

Due FOURCCs comune YCbCr sono UYVY e YUY2. Sono interleaved, il che significa che tutti i componenti YCbCr vengono memorizzate in un unico flusso. Crominanza (colore) le informazioni sono memorizzate a metà risoluzione orizzontale rispetto al luma, con i campioni di crominanza situato sulla parte superiore del campione luma sinistra di ogni coppia; gamma di luminanza è 16-235 e la gamma cromatica è 16-240. I formati sono chiamati dopo l'ordine di byte, quindi per UYVY è U (Cb), Y (luma 1), V (Cr), Y (luma 2), mentre i byte di luminanza e crominanza sono scambiati per YUY2 - Y / U / Y / V.
........................................................................................................
Su Windows, sembra che YUY2 è il più comune dei due formati - Avisynth e Huffyuv lo preferiscono, la decodifica MPEG-1 elenca in primo luogo, hardware, ecc maggior parte è anche in grado di utilizzare entrambi i formati. Di solito io considero che supporta solo YUY2, salvo che il dispositivo di Adaptec Gamebridge Ho recentemente acquistato supporta solo UYVY. Ora, quando si lavora con questi formati in codice della CPU in base regolare, la distinzione tra questi formati è minima, come permutando gli indici è sufficiente per accogliere entrambi. (In VirtualDub, la conversione tra UYVY e YUY2 è lossless.) Quando si lavora con le unità vettoriali, tuttavia, la differenza tra loro può diventare problematico.

Nel mio caso particolare, sto cercando di conversione Direct3D con accelerazione di questi formati in RGB, in modo da un'unità vettoriale la scheda grafica è la pertinente uno.

Ci sono alcuni motivi sto perseguendo questa strada. Uno è che il supporto DirectDraw su Windows Vista RTM sembra essere abbastanza preso una cantonata su; video sovrapposizioni sembrano essere male rotto i driver correnti NVIDIA per Vista, anche con Aero Glass disabili. In secondo luogo, sto sperimentando con effetti shader in tempo reale sul video dal vivo, e si vuole eliminare l'attuale conversione da RGB a YCbCr basati su CPU che si verifica quando display Direct3D è attivata in VirtualDub. In terzo luogo, non ho mai fatto prima.

Se si ha familiarità con Direct3D, è lecito chiedersi perché non mi basta usare YUY2 supporto hardware o UYVY. Beh, purtroppo, anche se le texture YCbCr sono supportate da ATI, non sono supportati su hardware NVIDIA. Entrambi fanno StretchRect supporto () da una superficie YCbCr a un target di rendering RGB, ma ci sono problemi gamma di luminanza durante questa operazione. Quindi si è scesi a pixel shader.

Ora, io ho un po 'di simpatia per il vecchio hardware, e come tale, io voglio che questo lavoro sul profilo più basso pixel shader, pixel shader 1.1. L'idea generale è quella di caricare i dati di UYVY YUY2 alla scheda video come A8R8G8B8 dati, e quindi convertire che in pixel shader ai dati RGB. Le equazioni per la conversione dei dati UYVY/YUY2 a RGB sono i seguenti:

R = 1,164 (Y-16) + 1,596 (Cr-128)
G = 1,164 (Y-16) - 0,813 (Cr-128) - 0,391 (Cb-128)
B = 1,164 (Y-16) + 2.018 (Cb-128)

Come si è visto, questo funziona molto bene per UYVY. Cb e Cr naturalmente cadere nei circuiti blu e rosso della trama A8R8G8B8; croma verde può essere calcolata tramite un prodotto scalare e fusa con una lerp. Un po 'di logica per la selezione tra i due campioni di luminanza basata su pari / dispari posizione orizzontale, e abbiamo finito. Heck, possiamo anche usare l'hardware di filtraggio bilineare di interpolare la croma, anche.

YUY2, tuttavia, è più fastidioso, perché caduta Cb e Cr in verde e alfa, rispettivamente. Pixel shader 1.1 è molto limitato nella manipolazione dei canali disponibili e le istruzioni possono né swizzle i canali RGB né scrivere solo ad alcuni di essi, inoltre, non c'è DP4 istruzioni per alfa compresi in un prodotto scalare in 1.1. Basta spostare la scala Cb e Cr in posizione consuma due degli otto preziose istruzioni vettoriali:

def c0, 0, 0,5 mila quarantacinque, 0, 0; c0.g = Cb_to_B_coeff / 4 def c1, 1, 0, 0, 0,798; c1.rgb = red | c1.a = Cr_to_R_coeff / 2 DP3 r0.rgb, t1_bx2, c0 ; decodificare Cb (verde) - crominanza blu / 2 + Mul r0.a>, t1_bias, c1.a; decodificare Cr (alfa) -> rosso chroma / 2 r0.rgb LRP, c1, r0.a, r0 tipo merge chroma rosso
Il risultato netto è che finora, la mia shader YUY2 richiede una coppia di istruzioni più shader UYVY. Non so se questo è significativo, in pratica, in quanto il sottostante combinatore registro di configurazione di una GeForce 3 è molto diversa e molto più potente di Direct3D ps1.1 - che può fare punti (A, B) + puntino (C, D) o A * B + C * D in un ciclo - ma non ho idea di quanto sia efficace il conducente è a ricompilare il shader per tale architettura.

(Se siete disposti a passo fino a una Radeon 8500 e ps1.4, tutto questo diviene inutile a causa della disponibilità di Splatting canale, arbitraria scrivere maschere, e di quattro componenti dot operazioni di prodotto ... ma dove sta il divertimento che !?)

Sembra che, almeno per le unità vettoriali senza swizzling economici, UYVY è una migliore corrispondenza per i formati immagine BGRA di YUY2 dovuta al modo che i canali line up. Ho cercato di pensare a dove YUY2 potrebbe essere più opportuno, ma il meglio che posso venire in mente è ABGR, che è un formato rara. L'altra possibilità è che qualcuno stava facendo un trucco strano SIMD-in-scalare su una CPU che ha coinvolto sfruttando i canali invertiti, facendo un 8 bit spostamento su un 80286 o 68.000 sarebbe stato costoso
Avatar utente
nikita75
Utente Senior
 
Post: 4389
Iscritto il: 31/07/09 13:36


Torna a Audio/Video e masterizzazione

Chi c’è in linea

Visitano il forum: Nessuno e 3 ospiti