Sunday, February 26, 2006
crudo e cotto
Uno non fa in tempo a riprendere in mano il progetto dopo una prolungata assenza dovuta a impegni esterni, che subito gli piombano tra capo e collo quei 3/4 bug da verificare. Anyway, come dicono gli albionici...
La tabella di marcia prevede come prossimo passo, in corso d'opera, l'implementazione di un ulteriore programma di supporto da inserire nella grande famiglia di tccat/tcexport/tcdemux/tcdecode/tc*, in modo da poter richiamare -e verificare- quanto piu` direttamente possibile l'encoder col nuovo codice. Si tratta, in soldoni, di aggiungere quel tanto che basta di interfaccia e codice di supporto al codice dell'encoder (nel senso transcode-iano del termine!) per farlo funzionare da solo: niente multithreading, niente filtri, niente operazioni sui frame, nulla: entrano frame YUV420P/PCM, esce roba compressa & impacchettata.
Il problema, a parte far funzionare tutto l'ambaradan, e` quello di leggere i dati grezzi.
Non sono mai stato fanatico della soluzione corrente, ovvero muovere il flusso di dati grezzo portando OOB i metadati che servono (dimensione frame video, ad esempio). Preferirei una soluzione un po` piu` cotta, tipo passare in-bound i metadati di cui sopra, magari usando formati tipo YUV4MPEG2 e WAV invece di reinventare la ruota. Piacevole effetto collaterale: interoperabilita` coi tool standard quali sox/mjpegtools/compagnia cantante.
Si tratta quindi di implementare l'opportuna interfaccia nel futuro tcexport. La cosa simpatica e` che le fondamenta dei pezzi che mancano sono gia` presenti nella base di codice esistente, si tratta "semplicemente" [1] di rivedere, riorganizzare, eventualmente estendere, il codice esistente. Quando si dice attitudine al riciclaggio ;)
+++
[1] L'esperienza passata dimostra che in questo campo la riorganizzazione del codice potrebbe essere onerosa almeno quanto una riscrittura. Ma anche questo e` il bello della diretta.
La tabella di marcia prevede come prossimo passo, in corso d'opera, l'implementazione di un ulteriore programma di supporto da inserire nella grande famiglia di tccat/tcexport/tcdemux/tcdecode/tc*, in modo da poter richiamare -e verificare- quanto piu` direttamente possibile l'encoder col nuovo codice. Si tratta, in soldoni, di aggiungere quel tanto che basta di interfaccia e codice di supporto al codice dell'encoder (nel senso transcode-iano del termine!) per farlo funzionare da solo: niente multithreading, niente filtri, niente operazioni sui frame, nulla: entrano frame YUV420P/PCM, esce roba compressa & impacchettata.
Il problema, a parte far funzionare tutto l'ambaradan, e` quello di leggere i dati grezzi.
Non sono mai stato fanatico della soluzione corrente, ovvero muovere il flusso di dati grezzo portando OOB i metadati che servono (dimensione frame video, ad esempio). Preferirei una soluzione un po` piu` cotta, tipo passare in-bound i metadati di cui sopra, magari usando formati tipo YUV4MPEG2 e WAV invece di reinventare la ruota. Piacevole effetto collaterale: interoperabilita` coi tool standard quali sox/mjpegtools/compagnia cantante.
Si tratta quindi di implementare l'opportuna interfaccia nel futuro tcexport. La cosa simpatica e` che le fondamenta dei pezzi che mancano sono gia` presenti nella base di codice esistente, si tratta "semplicemente" [1] di rivedere, riorganizzare, eventualmente estendere, il codice esistente. Quando si dice attitudine al riciclaggio ;)
+++
[1] L'esperienza passata dimostra che in questo campo la riorganizzazione del codice potrebbe essere onerosa almeno quanto una riscrittura. Ma anche questo e` il bello della diretta.
// posted by Ikitt @ Sunday, February 26, 2006 
Subscribe to Posts [Atom]