PDA

Visualizza versione completa : Acquisizione e Montaggio Virtualdub 1.9.11: colori sballati



Kirk78
09-10-11, 18: 27
Ciao a tutti :bai

Visto che era uscita alla fine dello scorso anno la versione 1.9.11 di VirtualDub ho provato a codificare le registrazioni TV (MPG) dal mio recorder digitale al posto del VDM, ovviamente con il plugin MPEG-2.
Li carica perfettamente, colori OK, audio sembra in sync.

La velocità di codifica mi sembra superiore utilizzando sempre 2 passi con Divx e LameMP3. Provo a vedere se il sync è corretto (non si sa mai).... e vedo che i colori sono quasi TUTTI sballati. :shock

1486
http://www.collectiontricks.it/attachments/forum/1487d1318177840t-virtualdub-1-9-11-colori-sballati-in_lettura.jpg
Quando carico tramite il plugin (MPEG-2 plugin v4.1) i colori, come detto, some perfetti.

Qualche idea per risolvere, oppure è un bug della versione 1.9.11? Per ora ritorno al VDM ma non mi dispiacerebbe sapere il perché. Grazie. :bai

Sabotender
09-10-11, 18: 44
Ciao Kirk.
sicuramente non è un bug, con xvid non compare ma non posso provare divx perchè da tempo ormai non ne faccio più uso e l'ho addirittura disinstallato, puoi fare la prova tu in xvid?

Kirk78
09-10-11, 19: 05
Posso sicuramente provare (anche se non mi servirebbe visto che c'è obbligo divx per colpa di un DVD che non gli piacciono gli xvid), ma non capisco il perché VDM lo stesso file lo codifica alla perfezione (con lo stesso identico divx) e VD 1.9.11 no.... Poi leggere lo legge bene (come da figura).... sia nel "pannello" input a sinstra che output a destra....

EDIT: anche Xvid identico.... però la seconda prova l'ho fatta usando le configurazioni "a mano" e ho visto che utilizzando il Full processing mode al posto di quello che uso SEMPRE con VDM Normal recompress anche il Divx è a colori normali. Il bug forse è lì: potresti provare con il Normal recompress, ovvimanente partendo da un MPG altrimenti il risultato può falsare. Io ho come al solito fatto prove su 30 secondi. Grazie.

Giusto per chiarire NON utilizzo filtri o altro devo solo passare da MPG a AVI(divx lame MP3), quindi teoricamente potrei anche usare il Fast recompress, ma ho visto che la codifica in realtà è migliore con la versione normale.
:bai

Sabotender
09-10-11, 19: 13
?? il secondo spoiler è vuoto...

I colori sballati in genere identificano un problema di conflitto ma in effetti dovrebbe verificarsi con entrambe le versioni.
Se provi con xvid anche 30 secondi in singola iniziamo a circoscrivere il problema...

Kirk78
09-10-11, 19: 24
?? il secondo spoiler è vuoto...
:boh io li vedo tutti e due.... oggi CT è proprio strano.

Comunque ho fatto l'EDIT sopra: idee?

Sabotender
09-10-11, 20: 00
Sì, in Normal Recompress lo fa anche a me ma tra le 3 modalità di ricompressione è quella meno indicata dato che converte il formato colore in RGB prima di passarlo al codec, cosa che non avviene in Fast rec e Full Processing Mode.
Con VDM non succede, può essere che andando avanti con le versioni sia una parte che è stata trascurata, non saprei...

Kirk78
09-10-11, 20: 12
Quindi diciamo che c'è un bug sul normal SOLO su VD 1.9.11 con Normal recompress! Strana questa cosa però, visto che VDM è un VD 1.5.10 modificata :boh, come dici tu l'avranno tralasciata, a questo punto potevano anche toglierla. Almeno a saperlo.... Fortuna che ho utilizzato i jobs così li modifico per provare in full (il fast non capisco perché viene diverso). Ma vedo che ci mette +/- come VDM quindi mi sa che lascio e non raddoppio :ghgh almeno fino a che non modificano.
Grazie delle prove. :bai

Sabotender
09-10-11, 20: 26
Di niente Kirk, ci teniamo in allenamento... :ghgh

Secondo me il Normal rec. è una variante inutile.
In Full Processing hai completo accesso alle modalità di compressione.
Fast rec. può essere usato per comprimere applicando filtri esterni o script e serve più che altro per rendere più snello il passaggio su VirtualDub, Normal non l'ho mai capito dato che modifica lo spazio colore in RGB mentre i codec della famiglia mpeg4 in genere lavorano in YV12, così ad occhio mi sembra un passaggio inutile.

DeST
10-10-11, 18: 27
Se te la senti potresti testare la versione 1.10 experimental di virtualdub, forse il problema è stato già risolto ;)

Kirk78
11-10-11, 08: 41
forse il problema è stato già risolto ;)
Interessante.... Solitamente non utilizzo "experimental" o Beta sul PC di lavoro.... ma visto che VD non tocca(va) registry o dll varie mi sa che ci provo stasera e vi dico.
Comunque la cosa che non mi va giù è che non si capisce perché a parità di codec sia audio che video, senza filtri, e a parità di filmato in input avvengono file uscita diversi con le 3 modalità, anche in termini di grandezza del file: ma i kbt, fps e tutto il resto è uguale! :boh.
Io volentieri avrei sempre usato il fast (che è più veloce) ma il risultato era peggiore del normal. Prima o poi mi leggo il sorgente. :bai

Kirk78
13-10-11, 15: 46
Ho già il sistema che mi vede 2 versioni diverse di VD, quindi la prova la farò quando mi ridanno il netbook. Ma ho letto questo

VirtualDub runs in RGB when you use Normal Recompress or Full Processing Mode (in the Video dropdown menu). All of VirtualDub's internal functions and filters run in RGB colorspace only. However, Fast Recompress doesn't decode the video to RGB, and instead just shunts whatever your source is into the compressor you've selected - thus if your source is YUV it shunts the video data as YUV into the video compressor.
This is important because almost all distribution video codecs run in YUV colorspace. This includes DivX, XviD, MPEG1, MPEG2, MPEG-4, DV, etc. HuffYUV (guess where the name comes from) runs YUV colormode natively but you can indeed compress RGB video data with it (but it will be bigger). There's an option in the codec controls to automatically convert incoming RGB video data to YUV in order to save space if you want to.
Insomma pare che VD lavori anche in RGB in full mode, quindi o hanno cambiato le cose dopo (probabile), oppure non è quello il problema altrimenti mi sarebbero venuti sballati anche il full processing :boh. Inoltre ho visto che la versione experimental è uscita contemporaneamente alla 1.9.11 il 24 dicembre 2010 e i bug fixed di quella non stabile sono:


* Reduced priority of ASF pseudo-handler to avoid interfering with input handlers that detect by filename.
* AVI: The preferred handler (fccHandler) field in the video stream is now ignored by default for consistency (unless re-enabled in preferences).
* UI: Limit minimum window size to avoid caption redraw artifacts.
* UI: Fixed bug where aspect ratio of panes in unconstrained aspect mode would drift when auto-sizing was enabled.
* UI: Select Range command is now disabled when no video is loaded.
* UI: Audio conversion dialog no longer occasionally says "No change (8-bit)" for compressed formats; this was sometimes incorrect as when that option was selected the pipeline actually used what the codec produced, which was usually 16-bit.
* UI: Video codec dialog now scrolls the list on open to always show the last selected codec.
* UI: The Configure and Cropping buttons in the filter list dialog no longer lose focus when clicked.
* UI: Mouse wheel scrolling now works in the filter preview and curve control windows.
* JobControl: Auto-shutdown now works over remote desktop and records a planned shutdown on server versions of Windows.
* Images: PNG images with 16-bit/channel grayscale or RGBA format now load properly.
* Images: Fixed GIF autodetect code checking the footer instead of the header.
* Hex editor: Fixed icon in RIFF tree window.
* Filters: Switched the frame that the IVTC filter drops in reduce frame rate mode to match the old pre-filter algorithm.
* Filters: Cropping dialog now opens at the currently selected frame.
* Filters: Fixed warp sharp filter in 3D acceleration mode.
Ma tu DeST lo hai provato personalmente oppure era un'ipotesi? :bai

Sabotender
13-10-11, 19: 10
C'è differenza...

-in Full Processing Mode lo spazio colore viene convertito in RGB per permettere l'uso dei filtri di VDub che lavorano in questa modalità, poi il flusso viene riconvertito in YV12 per passare il flusso ai codec.

-In Fast Recompress tutto resta in YV12.

-In Normal Recompress i passaggi sono gli stessi che per Full Processing Mode salvo l'utilizzo dei filtri quindi questa doppia conversione la vedo inutile come procedimento e dannosa per il risultato finale. In pratica, a che serve modificare due volte lo spazio colore per passare un flusso video al codec?

In teoria il risultato in Fast Recompress è migliore in assoluto se non si devono usare i filtri interni sia in termini di tempo che di qualità, forse in Normal Recompress si incasina lo spazio colore durante la doppia conversione perchè sicuramente il processo è diverso dal Full dove non ci sono porblemi.
Sinceramente in tutti questi anni è una modalità che non ho mai usato, o Full Processing o Fast Rec a seconda delle necessità e volendo estremizzare, meglio su tutti il Fast caricando il video con uno script di Avisynth per l'applicazione dei filtri che lavorano in YV12 quindi nessuna riconversione aggiuntiva.

Kirk78
13-10-11, 21: 05
Difatti di solito usavo il Fast recompress in VD, ma alcune volte era peggio il risultato finale e quindi ho scelto appunto il Normal in VDM che ha sempre funzionato alla grande.
Non ho trovato le specifiche sul sito di VD di quanto realmente fa ma penso che il Normal Recompress dia la possibilità di scelta del "Color Depth"
1491
Ma non penso sia quello il problema visto che ho gli stessi paramentri che ci sono nel Full.

A questo punto mi chiedo se non era un problema di una sola versione di VD che aveva un difetto nella modalità veloce, e che mi ha fatto lasciare VD per il VDM con Normal Recompress: accidenti che sfortuna!

Mi sa che adesso farò qualche prova con la nuova versione con un po' di opzioni e poi vi faccio sapere. :bai

P.S. come avete letto NON uso Avisynth ma i plugin, con VirtualDub normale.

Sabotender
13-10-11, 23: 17
Lo spazio colore è diverso dalla profondità colore...

Ho approfondito la cosa e penso che il problema sia nel plugin mpeg2.vdplugin o nella sua compatibilità con VDub.
Infatti in Normal Recompress il problema si ha solo caricando file mpeg2, da avi ad avi non si verifica e non si verifica caricando gli mpeg tramite avisynth. Con VDM il problema non si pone dato che accetta gli mpeg senza bisogno di supporti esterni.

Kirk78
16-10-11, 00: 54
Grazie Sabo, come sempre, del tuo interessamento ed approfondimento, che serve anche a chi leggerà i nostri post.
Con la nuova versione di VD, quella di questa discussione, la Fast Recompress và alla grande per qualità ma anche in termini di grandezza del file, oltre ovviamente alla velocità. Ho fatto una prova addirittura per una registrazione da TV di 2 ore: perfetta. Ritorno quindi alle "origini" ringraziano tutti dell'apporto che mi ha fatto tornare a VD.

Unica pecca: per andare in modo "batch" bisogna fare 2 passaggi e non come VDM andare direttamente su "Salva con nome". Chissà perché l'hanno cambiato. Comunque esiste sempre il Ctrl-F7.

:bai