Tuesday, May 16, 2006
Elettroencefalogramma mezzo piatto (export profile #1)
La buona notizia: sul fronte principale finalmente si torna a viaggiare ad un ritmo decente. A breve ci dovrebbero^Wdovranno essere nuovi interessanti sviluppi.
La cattiva notizia e` che fronte secondario si va a rilento. Beh, data la situazione generale (mica ci si vuol mettere radici, in facolta`) forse non c'e` troppo di cui lamentarsi.
Tornando a bomba, e` da qualche giorno che scrivo e riscrivo il codice di gestione degli export profile per transcode. Nessuna delle stesure sinora prodotte mi soddisfa, a parte l'ultima. Ancora da verificare.
Ma andiamo con ordine.
un export profile nel nostro contesto e` sostanzialmente un set di preimpostazioni per quanto riguarda l'export layer. In soldoni, quest'opzione permette all'utente di usare semplicemente
--export_prof dvd-pal
per ottenere in output un flusso dvd-compliant pronto per essere multiplexato, senza stare a smazzarsi con tutte le specifiche opzioni quali -Z, -N, -w, -b & co.
Gli export profile sono -a ragione- una delle feature piu` usate e apprezzate in transcode: vale dunque la pena non solo mantenere questa feature, ma anche e sopratutto cercare di migliorarla il piu` possibile.
Oltretutto, riorganizzando tutto l'export layer, attivita` che sta impegnando la grande maggioranza del tempo che dedico a TC, non si puo` ignorare l'aspetto export profile. E cosi` eccoci qua.
Cosi`, qual'e` il problema? Si riassume in due parole: "spaghetti code".
Il codice attuale soffre di due difetti letali: e` sparpagliato in maniera alquanto, uhm, caotica tra core e moduli, e, piu` grave, i valori da utilizzare per i vari profili sono hardcoded nei vari moduli. Tanto per non farsi mancare nulla, la notifica core/modulo del profilo da utilizzare varia da modulo a modulo.
Piano col bastone: alcuni aspetti precedentemente elencati sono inevitabili, non si puo` uniformare tutto (con buona pace di phonon :P). Per fare un'esempio concreto, avendo piu` moduli, mettiamo, piu` encoder, che supportano tutti determinati profili, ma che hanno bisogno di ALCUNE opzioni specifiche diverse, non c'e` molto di meglio da fare che dare ad ogni modulo le sue opzioni specifiche. Parimenti, il core dovra` probabilmente fare comuqnue alcuni aggiustamenti in base al profilo selezionato. Cio` premesso, la mia idea e` che si puo` comunque fare MOLTO meglio di come si sta facendo adesso, per dirne due facili, estraendo il piu` possibile i dati dal codice, e fattorizzando il piu` possibile.
OK, molto carino. Come fare?
Idea di base: invertire il flusso di esecuzione. Attualmente, si ha questo:
configurazione: default -> opzioni da riga di comando -> valori profilo
Ovvero: la configurazione finale parte con dei default che sono modificati dagli argomenti da riga
di comando che sono a loro volta modificati dal profilo selezionato.
Risultato netto: i valori impostati da un profilo non si possono modificare, non ci puo` essere piu` di un profilo selezionato alla volta. Entrambi aspetti ragionevoli considerando profili stringenti tipo DVD, dove non ha molto senso cambiare i detti valori, ma non in generale.
L'idea, dicevo, e` di invertire il flusso di esecuzione:
configurazione: default -> (valori profilo)* -> opzioni da riga di comando
Si ottengono un tot di vantaggi in un unico fluido gesto: profili cumulabili (volevo scrivere stackabili, mi son fermato giusto in tempo ;) ), profili personalizzabili usando le solite opzioni standard, se l'utente vuole.
[continua...]
// posted by Ikitt @ Tuesday, May 16, 2006 
Subscribe to Posts [Atom]