Procurarsi RecTvEdit

S7efano ha scritto:
Grazie, per le info.

Ho analizzato ancora il video (senza estrapolarlo, per cui lasciandolo così com'è).

Purtroppo nel mio caso è impossibile unirli senza glitch o senza "pulire" tagliando altri frame, nel mio caso manca proprio un frame di "raccordo"

La sequenza di memorizzazione dei frame del flusso video AVC è tipo così:

IPBBBBBPBBBBB...


La sequenza in riproduzione dev'essere così (con frame nel giusto ordine temporale)

IBBBBBPBBBBBP...

i B-frame sono preditivi, derivano da I e P frames passati/futuri.

Nel caso di queste registrazioni, mi ritrovo con un I frame come ultimo frame del primo file, e con un B-frame come primo fotogramma nella seconda parte, il che è sintomo che manca necessariamente un P-frame, perché dopo un I ci dev'essere un P-frame obbligatoriamente come ordine di decodifica... quindi è un errore se c'è subito un B-frame e il decoder non sa decodifcarlo integralmente visto che parte dello stesso è nel P mancante... il che si verifica anche in testa al primo file: il decoder come dicevo registra di punto in bianco quando si avvia, della serie 'ndo coje coje' :) invece di aspettare un I-frame (o comunque un analogo K-frame) per avere un flusso corretto... invece partendo da un B-frame si ha già un flusso errato, ma niente di grave in testa al primo file, lo taglio fino al primo I o K-frame (o lo fa comunque il programma, tipo Avidemux). A questo punto ho quasi la certezza che raggiunti i 4GiB stoppa e riavvia la registrazione in automatico... l'errore già in testa nei primi file mi porta a pensare che faccia così anche per i secondi file che fa partire automaticamente. Altrimenti il P-frame lo dovrei avere da qualche parte... ma non c'è. In riproduzione col decoder si nota meno, ma un piccolo e poco percepibile "slittamento" lo fa quando passa al secondo file.
Clicca per espandere...


Beh.. se già in riproduzione con il player del decoder noti il glitch.. mi sa che c'è veramente poco (se non nulla) da fare..
Pensavo che almeno il play via decoder fosse pulito.
Che modello è? Per non prenderlo.. devo sostituire un mio attuale registratore (LG HR550, dal punto di vista di funzioni era formidabile all'ora.. al momento non c'è niente del genere se non il Panasonic DRM-UBT1 ma cosa un botto) quando ci sarà il passaggio all'HEVC (il piccolo TS6810 è un pvr secondario.. che mi risolve 2 cose.. programmazioni sovrapposte e segnale d'antenna.. il ts6810 mangia di tutto..). Avevo pensato ai modelli VU+ (nello specifico VU+ UNO 4K SE 1x DVB-T2).. che pare creino file singoli per ogni registrazione.. così da smarcarmi dal RecTVEdit.
O in alternativa qualcosa tipo il TS6821 che ha il doppio tuner dvb-t2 (2 registrazioni contemporanee). Lato split dei file ho appena visto che contrariamente a quanto pensato crea n file.. non so se l'unione è così semplice come per il TS6810.. se ha lo stesso chip magari anche si.. ma a questo punto non rischierei.
Mi piacerebbe una soluzione esteticamente simile al mio LG.. in alternativa prendo i pezzi singoli e li metto nell'LG svuotato!!
 
Ultima modifica:
Sì, probabile non ci abbia mai fatto caso in riproduzione sul decoder, a parte che è meno evidente di suo 1) perché lo uso poco come lettore 2) perché il taglio avviene in un punto casuale, per cui può anche capitare che avvenga in un B-frame da cui non dipendono altri frames, oppure proprio in corrispondenza di un I-frame, per cui nessun problema seppur essendo molti di meno I-frames è assai improbabile che ciò avvenga: un decoder "saggio", che non gestisce altrimenti le due parti (come il tuo che comunque duplica una parte) partirebbe proprio da questi, poco prima dei 4GiB, e non aspettando rigidamente questa taglia.

E' un decoderino freetoair pagato poche decine di euro..., un Majestic, di qualche anno fa (2017); è DVB-T2/DVB-S2/HEVC Main10, non ha molta importanza specifica però perché al tempo sulla stessa piattaforma hardware/sw ricordo diversi marchi più "blasonati" come Digiquest o solo sat o solo terrestri. Non me la sento però di sminuirlo diciamo, a parte questo difetto, ha per esempio una ben dettagliata schermata di Info tecniche durante la registrazione: mette file system, durate varie disponibili e diversi dati tra cui anche la velocità di registrazione / bitrate e il relativo spazio libero rimasto... si può anche navigare tra le partizioni e attivare più registrazioni in contemporanea (questo però mi guardo bene dal farlo)... Altri modelli non permettono di sapere o fare nessuna di queste altre cose (per esempio lo Humax in firma che mi registra perfettamente, ma ha altre noie: esportazione solo su chiavetta tramite seconda porta usb)... Un'altra pecca, assurda, è che non permette, una volta premuto REC, di immettere una durata di fine... almeno non ho mai capito come fare ammesso che lo permetta. Però per il basso costo, è valido.

Non saprei cosa suggerirti, ma tendo anche io prediligo i pezzi singoli... :)
 
Moseweb ha scritto:
Forse ho trovato qualcosa, ho provato con file video 'normali' quindi non con i recenti formati.
Queste prove le ho fatte per il formato Ali 3.
Questo formato è, o era, usato anche da altri sistemi non legati a decoder tv e qualcuno si è preso la briga di andare a vedere i file in profondità. A livello esadecimale.
Ha scoperto che ogni file ha in comune col precedente 47KiB, 48128 byte esatti. Andando ad eliminare dalla testa del file (successivo.. quindi da ogni spezzone tranne il primo file) tali byte ed unendo poi gli spezzoni (ho usato il semplice copy /b..), il video è perfetto e non c'è glitch.
Ho provato, ed è risultato proprio così. Perfetto e con audio sincronizzato.
Devo approfondire con altri video ma se così si conferma, i vari file di supporto del registrato sono solo utili al decoder. Il decoder durante la registrazione, a questo punto, va a salvare il file in uso e poi ricomincia col successivo tenendo un 'buffer' di 47KiB (probabilmente utile per gestire i tempi di chiusura e apertura file sul supporto). L'unione semplice degli spezzoni senza l'eliminazione dei 47KiB genera il glitch (per forza di cose). Non c'è alcun frame perso: è l'errore per via della ripetizione, che poi sfasa anche l'audio. Nell'unione pulita non c'è desync perché credo gestisca dinamicamente/periodicamente la sync durante la riproduzione grazie ad informazioni 'temporalmente regolari' inserite nel file. Infatti con mediainfo si vedono i delay dell'audio nei vari spezzoni e tali delay sono diversi ma secondo me mediainfo mostra solo la prima informazione di delay che trova, le successive presenti non le rileva. Forse questa cosa si può vedere con TSReader.
Le prove le ho fatte su una registrazione video contenente 3 tracce audio, le tracce teletext, i sottotitoli e le informazioni legate all'EPG.
Se questa cosa funziona anche con i recenti formati usati, RecTVEdit non serve più. O per lo meno solo per i formati che capisce.
Il tutto è solo un po' più elaborato perché si devono eliminare i byte dai file ma l'unione senza perdite è comunque veloce tanto quanto RecTVEdit.
Proprio quello che mi serviva.
Se la cosa torna utile anche a voi..
Clicca per espandere...
Utilissima, grazie. Finalmente dopo molti anni, ho capito perché le registrazioni a intervalli più o meno regolari, davano con ffmpeg l'errore "Packet corrupt". :)
Facendo un po' di prove, l'errore era proprio nel punto di unione dei due file TS. Ho sempre utilizzato il comando copy /b, ma non * ho mai notato difetti nel video (quindi apparentemente tutto ok).

Moseweb ha scritto:
Ok, ovviamente la cosa funziona se parliamo dello stesso formato. I file aggiuntivi che ho io sono tutti .dvr, non c'è alcun .idx.
Il blocco da togliere è preciso di 48128 byte ed ho controllato se (e lo è) corrisponde alla parte finale del precedente file in sequenza: anche nel tuo caso è così? hai 47KiB all'inizio identici ai 47KiB della parte finale del precedente? Altrimenti, ovviamente, non funziona.
Clicca per espandere...

Da una settimana sto provando il nuovo decoder DigiQuest che divide i file TS dopo 3,8 Giga. La struttura è la stessa del mio vecchio DigiQuest (che divide i TS dopo 1 Giga) e del TS6810 Stealth. Le registrazioni sono nella cartella principale ALIDVRS2, che contiene le varie cartelle delle registrazioni.

Nella cartella di ogni registrazione sono presenti i file:
info3.dvr (le info della registrazione, come titolo, canale, ora registrazione, ecc..., utili al decoder)
000.dvr
000.ts (la registrazione vera e propria)
...eventuali file successivi 001, 002, ecc... (.dvr e .ts)

Provando il nuovo decoder ho notato che nel punto di unione dei due file TS, fatta con la copia binaria, dava l'errore "Packet corrupt" utilizzando ffmpeg ...allora mi sono ricordato questa discussione e ho analizzato i file...
In effetti, ho notato che esattamente 47 KiB alla fine del primo file si ripetono all'inizio del successivo, e così anche per i file successivi.
Ho provato anche il vecchio DigiQuest (del 2015) e i 47 KiB si ripetono come con il nuovo decoder.

Ho provato ad unire i due file con la copia binaria, rimuovendo i 47 KiB finali dal primo file, e utilizzando ffmpeg, l'errore non c'era più.
Confrontando l'unione senza "taglio" e quella togliendo i 47 KiB, errori nella parte video non * ne ho trovati, ma analizzando l'audio nell'unione senza "taglio", mancavano 72 ms di audio.

Tutto ok eliminando i 47 KiB, come hai descritto. :thumbup: :eusa_clap: :eusa_clap:

* Edit: Da ulteriori prove, in alcune registrazioni (ma solo con il nuovo decoder), ho notato nel video il glitch nel punto di unione dei due file (ovviamente senza togliere i 47 KiB).

Moseweb ha scritto:
devo sostituire un mio attuale registratore (LG HR550, dal punto di vista di funzioni era formidabile all'ora.. al momento non c'è niente del genere se non il Panasonic DRM-UBT1 ma cosa un botto) quando ci sarà il passaggio all'HEVC (il piccolo TS6810 è un pvr secondario.. che mi risolve 2 cose.. programmazioni sovrapposte e segnale d'antenna.. il ts6810 mangia di tutto..). Avevo pensato ai modelli VU+ (nello specifico VU+ UNO 4K SE 1x DVB-T2).. che pare creino file singoli per ogni registrazione.. così da smarcarmi dal RecTVEdit.
O in alternativa qualcosa tipo il TS6821 che ha il doppio tuner dvb-t2 (2 registrazioni contemporanee).
Clicca per espandere...

Ti posso consigliare il DigiQuest Twin Tuner REC Small Edition, il decoder che sto provando in questi giorni, e che crea le registrazioni come il TS6810.
A giorni scriverò nella discussione del decoder, come mi sto trovando con il Twin Tuner SE.
 
Ultima modifica:
S7efano ha scritto:
No... purtroppo come vedi sono differenti:

(fine primo file)
file-A-finepezzo.png


(inizio secondo file)
file-B-iniziopezzo.png


per praticità ho messo in evidenza le parti finali dei 48kiB.
Clicca per espandere...

Prova a cercare se i primi 192 byte del secondo file, vengono ripetuti alla fine del primo file (per sapere se una parte viene ripetuta nel file successivo).

Nel caso dei .TS, i pacchetti sono da 188 byte (4 byte di intestazione + 184 byte di dati), mentre nei pacchetti degli .MTS ci sono 4 byte di intestazione extra (4 + 4 + 184 byte di dati), quindi 192 byte.

Nel nostro caso erano 47 KiB, ovvero
188 byte X 256 pacchetti = 48128 byte.

Dalle immagini si può notare che l'intestazione del pacchetto inizia sempre con 0x22 e dopo 4 byte inizia l'intestazione del TS con 0x47.

Puoi notare una sequenzialità:
22 5E F2
22 5E F3

...e anche...
47 00 C9 12
47 00 C9 13

L'unione dei due file non deve interrompere la sequenzialità dei pacchetti.
Ricorda di tagliare multipli di 192 byte (un pacchetto).
 
Grazie 1000 e contento per voi, appena posso proverò e farò sapere.
Ma sono abbastanza scettico nel mio caso. Temo che semplicemente stoppi la registrazione per qualche istante, per cui mi manca fisicamente il contenuto video,

Già come ho detto il primo file è corrotto in testa, perché un flusso H.264 non può cominciare da un B-frame. DEVE cominciare da un IDR-Frame. Quindi il PVR dovrebbe attendere quello in trasmissione(qualche istante), o se assente, perlomeno marchiarlo come "K-Frame" con apposita regola (SEI/Recovery Point per chi vuole approfondire)... Tipo di fotogrammi che comunque dovrebbero essere presenti nei flussi dei canali tv, da quel che ho constatato(avevo verificato sui Mediaset tivusat)... in nessun modo dovrebbe essere consentito l'inizio con un comune B-Frame del flusso. A seconda degli editor con cui si va a editare, o unire più file, questa parte iniziale rimane (corrotta) oppure viene 'silenziosamente', ma più correttamente, tagliata via fino all'incontro di un IDR-Frame o K-frame (tanto non viene riprodotta o VLC addirittura mi blocca la riproduzione).
Questo per dire che già questo mio decoder fa questo errore col primo file della registrazione (non sempre, è casuale ,in base a quando faccio partire la registrazione, non è prevedibile).

Voi non mi sembra abbiate anche questo problema sul primo file.
 
Ultima modifica:
S7efano ha scritto:
Già come ho detto il primo file è corrotto in testa, perché un flusso H.264 non può cominciare da un B-frame. DEVE cominciare da un IDR-Frame. Quindi il PVR dovrebbe attendere quello in trasmissione(qualche istante),
[...]
A seconda degli editor con cui si va a editare, o unire più file, questa parte iniziale rimane (corrotta) oppure viene 'silenziosamente', ma più correttamente, tagliata via fino all'incontro di un IDR-Frame o K-frame (tanto non viene riprodotta o VLC addirittura mi blocca la riproduzione).
Questo per dire che già questo mio decoder fa questo errore col primo file della registrazione (non sempre, è casuale ,in base a quando faccio partire la registrazione, non è prevedibile).

Voi non mi sembra abbiate anche questo problema sul primo file.
Clicca per espandere...

Invece il primo file ha gli stessi problemi anche con questi decoder. Con VLC, spesso non parte, mentre con Windows Media Player non ho avuto problemi.
Il decoder salva semplicemente il flusso da punto a punto, senza fare alcun controllo/modifica, non è un registratore vero e proprio, in lettura si comporta esattamente come quando si cambia canale (aspetta il fotogramma "giusto").
Per utilizzare la registrazione con VLC, devo ricreare il TS, copiando audio e video con ffmpeg.


Ho notato che la dimensione dei file registrati col vecchio e nuovo decoder è sempre divisibile per 47 KiB, praticamente il file è un insieme di pacchetti (caratteristica del TS).
Ho provato ad eliminare il pacchetto ripetuto (47 KiB) da vecchie registrazioni già unite con COPY /B (ovviamente senza alcuna modifica), sapendo che i file vengono divisi a 1 GiB, con una differenza massima di una decina di pacchetti.
Con un editor esadecimale, con pochi tentativi, sono riuscito a trovare ed eliminare il pacchetto ripetuto nei punti di unione dei file, e la registrazione adesso è perfetta senza errori. :)
 
hi-tech84 ha scritto:
Invece il primo file ha gli stessi problemi anche con questi decoder. Con VLC, spesso non parte, mentre con Windows Media Player non ho avuto problemi.
Il decoder salva semplicemente il flusso da punto a punto, senza fare alcun controllo/modifica, non è un registratore vero e proprio, in lettura si comporta esattamente come quando si cambia canale (aspetta il fotogramma "giusto").
Per utilizzare la registrazione con VLC, devo ricreare il TS, copiando audio e video con ffmpeg.
Clicca per espandere...
Sì, giusta osservazione, riguardo il primo file da un certo punto di vista è corretto che sia così il comportamento del pvr... nel senso che non mette il becco dentro il flusso video elementare e 'cattura' grezzamente da quando vogliamo noi premendo "REC", e il TS (mts nel mio caso) è formalmente corretto. Il problema è "rimandato" al decoder h.264 che legge il flusso estrapolato dal .ts , quindi forse è VLC che incorpora il decoder video elementare (il codec h.264 interno che utilizza) che dovrebbe essere più 'intelligente' e non far arrivare al suo decoder quella parte "illegale" per h.264 e a non far bloccare la riproduzione con odioso freeze.

Ho notato che la dimensione dei file registrati col vecchio e nuovo decoder è sempre divisibile per 47 KiB, praticamente il file è un insieme di pacchetti (caratteristica del TS).
Ho provato ad eliminare il pacchetto ripetuto (47 KiB) da vecchie registrazioni già unite con COPY /B (ovviamente senza alcuna modifica), sapendo che i file vengono divisi a 1 GiB, con una differenza massima di una decina di pacchetti.
Con un editor esadecimale, con pochi tentativi, sono riuscito a trovare ed eliminare il pacchetto ripetuto nei punti di unione dei file, e la registrazione adesso è perfetta senza errori. :)
Clicca per espandere...

Mi fate ben sperare :D purtroppo con questo caldo non riesco a mettermi a fare queste prove... mi spazientisco subito. Appena riesco ci riprovo con calma. Anche perché ho alcune registrazioni a cui tengo che non ho convertito (o anche solo editate e masterizzate su disco) in attesa di riuscire a risolvere in qualche modo quei fastidiosi glitch nelle giunzioni...
 
Moseweb ha scritto:
A livello esadecimale.
Ha scoperto che ogni file ha in comune col precedente 47KiB, 48128 byte esatti. Andando ad eliminare dalla testa del file (successivo.. quindi da ogni spezzone tranne il primo file) tali byte ed unendo poi gli spezzoni (ho usato il semplice copy /b..), il video è perfetto e non c'è glitch.
Ho provato, ed è risultato proprio così. Perfetto e con audio sincronizzato.
[...]
Il tutto è solo un po' più elaborato perché si devono eliminare i byte dai file ma l'unione senza perdite è comunque veloce tanto quanto RecTVEdit.
Proprio quello che mi serviva.
Clicca per espandere...

Ho trovato un programma per velocizzare il taglio dei 47 KiB e l'unione. Si chiama Swiss File Knife, ed è utilizzabile direttamente da linea di comando.
La funzione che ci interessa è partcopy.
Nel caso di Windows, il metodo più semplice è quello di creare una cartella, copiare l'eseguibile scaricato (rinominandolo in sfk.exe), copiare i file TS della registrazione "divisa" in file 000.ts, 001.ts, 002.ts, ... , e creare un file .bat

Il file .bat avrà i seguenti comandi:
Codice: 
sfk partcopy -verbose 001.ts -allfrom 48128 000.ts -append -yes
sfk partcopy -verbose 002.ts -allfrom 48128 000.ts -append -yes
questo esempio è valido per registrazioni in tre file (000.ts, 001.ts, 002.ts), nel caso di due file, basta la prima riga, per quattro file, bisogna aggiungere una terza linea cambiando il nome del file (da 002 a 003)
ATTENZIONE: partcopy non chiede conferma per la sovrascrittura. Per provare i comandi omettere "-yes", la copia sarà soltanto simulata ("-verbose" serve per avere un minimo di info), senza "-append", il file 000.ts verrà sovrascritto dall'inizio.

Il comando della prima riga serve per copiare l'intero file 001.ts, tranne i primi 47 KiB ("-allfrom 48128"), alla fine del file 000.ts ("-append"). La seconda riga esegue lo stesso comando sul file successivo (002.ts).

Avviato il file .bat, al termine dei due comandi, il file 000.ts sarà la copia binaria dei tre file uniti, senza i 47 KiB ripetuti tra i file (una volta verificata la registrazione, i file 001,002,... potranno essere cancellati).
La registrazione sarà perfetta anche nei punti di unione dei file.
 
Ultima modifica:


niente da fare :(

Provato sia con 192 che con 188 byte di lunghezza.

( per distrazione avevo cercato come valori testuali, e l'immagine è di quella ricerca, in ogni caso non cambia niente nemmeno come valore esadecimali effettivi).

Poi anche a occhio se scorro giù nel primo file e poi confronto col primo... sono uguali solo i primi byte dopo il 0x22
 
Ultima modifica:
S7efano ha scritto:
niente da fare :(
[...]
Poi anche a occhio se scorro giù nel primo file e poi confronto col primo... sono uguali solo i primi byte dopo il 0x22
Clicca per espandere...

Prova a cercare la stessa stringa partendo da 47 00 C9 14 .... (senza i primi 4 byte) alla fine del primo file.

Hai controllato il numero del pacchetto TS (inizia con 0x47)? Si ripete ogni 12 "righe", da 47 00 C9 10, a 47 00 C9 1F (sono 16) poi ricomincia.

Se il secondo file inizia con 22 5E F3 15 47 00 C9 14, il primo file (ultimi 192 byte) dovrebbe finire con 22 .... 47 00 C9 13.

hi-tech84 ha scritto:
Dalle immagini si può notare che l'intestazione del pacchetto inizia sempre con 0x22 e dopo 4 byte inizia l'intestazione del TS con 0x47.

Puoi notare una sequenzialità:
22 5E F2
22 5E F3

...e anche...
47 00 C9 12
47 00 C9 13

L'unione dei due file non deve interrompere la sequenzialità dei pacchetti.
Clicca per espandere...

Se vuoi, puoi mandarmi in MP gli ultimi 4 Mb (circa) del primo file, e i primi 4 Mb (circa) del secondo file. La cosa mi ha incuriosito. :)
 
Ultima modifica:
Allora, ne sono venuto a capo a notte fonda... e fondendo... meno male che non volevo fare prove col caldo...

E' sufficiente il semplice copy /b !

Ciò che mi ingannava è che quella registrazione ha problemi di segnale proprio nei pressi della giunzione, e solo lì!, un'altra cosa che mi confondeva era quel 22 iniziale del secondo file... ma è un puro caso, provando con altre registrazioni infatti sia la fine del primo file che nell'inizio del secondo i dati sono casuali, nel senso che è più facile capire che l'interruzione è in un punto casuale del pacchetto. Ovviamente i programmi normali tipo avidemux e MKVtolnix possono tagliare via la parte del pacchetto sia alla fine del primo file che all'inizio del primo file... perché li ritengono punti incompleti/corrotti di 2 mts da unire. Sto scoprendo l'acqua calda visto che sicuramente ne avevamo già parlato (ora non ho riletto la parte di mesi fa della discussione...).

Inoltre ho anche altri file di un altro decoder (mi sembra siano dei .ts ma con estensione .mts).... non ricordo ora se forse in quel caso il copy l'avevo provato e non risolveva e allora forse devo provare a vedere lì se c'è la ripetizione...
 
hi-tech84 ha scritto:
Ho trovato un programma per velocizzare il taglio dei 47 KiB e l'unione. Si chiama Swiss File Knife, ed è utilizzabile direttamente da linea di comando.
La funzione che ci interessa è partcopy.
Nel caso di Windows, il metodo più semplice è quello di creare una cartella, copiare l'eseguibile scaricato (rinominandolo in sfk.exe), copiare i file TS della registrazione "divisa" in file 000.ts, 001.ts, 002.ts, ... , e creare un file .bat

Il file .bat avrà i seguenti comandi:
Codice: 
sfk partcopy -verbose 001.ts -allfrom 48128 000.ts -append -yes
sfk partcopy -verbose 002.ts -allfrom 48128 000.ts -append -yes
questo esempio è valido per registrazioni in tre file (000.ts, 001.ts, 002.ts), nel caso di due file, basta la prima riga, per quattro file, bisogna aggiungere una terza linea cambiando il nome del file (da 002 a 003)
ATTENZIONE: partcopy non chiede conferma per la sovrascrittura. Per provare i comandi omettere "-yes", la copia sarà soltanto simulata ("-verbose" serve per avere un minimo di info), senza "-append", il file 000.ts verrà sovrascritto dall'inizio.

Il comando della prima riga serve per copiare l'intero file 001.ts, tranne i primi 47 KiB ("-allfrom 48128"), alla fine del file 000.ts ("-append"). La seconda riga esegue lo stesso comando sul file successivo (002.ts).

Avviato il file .bat, al termine dei due comandi, il file 000.ts sarà la copia binaria dei tre file uniti, senza i 47 KiB ripetuti tra i file (una volta verificata la registrazione, i file 001,002,... potranno essere cancellati).
La registrazione sarà perfetta anche nei punti di unione dei file.
Clicca per espandere...


Ciao.
Torno ora sul forum dopo una lunga pausa. Sono contento di poter esser stato utile con la segnalazione. Io nel frattempo avevo provato con il comando dd portato su windows ma poi cercando avevo trovato il tuo stesso comando che sulla carta sembra essere migliore, soprattutto nelle tempistiche. Devo provarlo!
 
Ultima modifica:
S7efano ha scritto:
Allora, ne sono venuto a capo a notte fonda... e fondendo... meno male che non volevo fare prove col caldo...

E' sufficiente il semplice copy /b !

Ciò che mi ingannava è che quella registrazione ha problemi di segnale proprio nei pressi della giunzione, e solo lì!, un'altra cosa che mi confondeva era quel 22 iniziale del secondo file... ma è un puro caso, provando con altre registrazioni infatti sia la fine del primo file che nell'inizio del secondo i dati sono casuali, nel senso che è più facile capire che l'interruzione è in un punto casuale del pacchetto. Ovviamente i programmi normali tipo avidemux e MKVtolnix possono tagliare via la parte del pacchetto sia alla fine del primo file che all'inizio del primo file... perché li ritengono punti incompleti/corrotti di 2 mts da unire. Sto scoprendo l'acqua calda visto che sicuramente ne avevamo già parlato (ora non ho riletto la parte di mesi fa della discussione...).

Inoltre ho anche altri file di un altro decoder (mi sembra siano dei .ts ma con estensione .mts).... non ricordo ora se forse in quel caso il copy l'avevo provato e non risolveva e allora forse devo provare a vedere lì se c'è la ripetizione...
Clicca per espandere...


Ciao.
Sinceramente avevo capito che copy /b l'avessi già testato senza successo. Certo è che se hai la sfortuna di aver preso una registrazione 'danneggiata' proprio sul salto..
 
Ultima modifica:
hi-tech84 ha scritto:
Ti posso consigliare il DigiQuest Twin Tuner REC Small Edition, il decoder che sto provando in questi giorni, e che crea le registrazioni come il TS6810.
A giorni scriverò nella discussione del decoder, come mi sto trovando con il Twin Tuner SE.
Clicca per espandere...

Ciao. Senza che impazzisca a cercarlo.. lo hai poi recensito? Grazie..
 
Moseweb ha scritto:
Ciao.
Sinceramente avevo capito che copy /b l'avessi già testato senza successo. Certo è che se hai la sfortuna di aver preso una registrazione 'danneggiata' proprio sul salto..
Clicca per espandere...
Ora è passato un po' di tempo e magari ricordo male.
Forse l'avevo provato solo sulle registrazioni danneggiate e ricordo bene quella coincidenza del valore esadecimale iniziale sul secondo file...

In tutti i casi una volta ottenuto il file .ts unito con copy /b, da qualche mese do una ripassata con ffmpeg in modo che questo mi "sistemi" le eventuali parti corrotte (per quanto possibile), e rimuxo in mkv, scartando eventuali tracce audio che non mi servono.
Con un comando del tipo
Codice: 
c:\ffmpeg\bin\ffmpeg -i "video1.ts" -ss 00:00:03 -to 02:30:00 -vcodec copy -map 0:0 -acodec copy -map 0:1 "d:\video1.mkv"
pause

Con -ss e -to delimito l'inizio e la fine(nell'esempio taglio i primi 3 secondi), soprattutto il primo (-ss) che toglie la "testa", così il video lo faccio cominciare sempre con un k-frame(nell'esempio è al secondo 3 ), mentre il decoder registra anche a partire da un delta-frame e questo manda in crisi alcuni player tipo VLC (forse in mkv lo digerisce, non ho provato mi sa, ma comunque mi pare più sensato partire da un k-frame).

Prima usavo Avidemux per 'ripassare' il file , ma a volte se trova qualcosa che non va nel flusso magari a metà film, crasha... e il video termina in quel punto. Per cui Avidemux lo uso solo per editare il file, dopo averlo preventivamente ripassato con ffmpeg di linea di comando. In ultimo il file definitivo lo ripasso in ogni caso con mkvtoolnix per impostare al meglio il contenitore mkv. Anche mkvtoolnix usato direttamente sul .ts acquisito può incappare in problemi se ci sono punti corrotti.
 
Ultima modifica:
S7efano ha scritto:
Ora è passato un po' di tempo e magari ricordo male.
Forse l'avevo provato solo sulle registrazioni danneggiate e ricordo bene quella coincidenza del valore esadecimale iniziale sul secondo file...

In tutti i casi una volta ottenuto il file .ts unito con copy /b, da qualche mese do una ripassata con ffmpeg in modo che questo mi "sistemi" le eventuali parti corrotte (per quanto possibile), e rimuxo in mkv, scartando eventuali tracce audio che non mi servono.
Con un comando del tipo
Codice: 
c:\ffmpeg\bin\ffmpeg -i "video1.ts" -ss 00:00:03 -to 02:30:00 -vcodec copy -map 0:0 -acodec copy -map 0:1 "d:\video1.mkv"
pause

Con -ss e -to delimito l'inizio e la fine(nell'esempio taglio i primi 3 secondi), soprattutto il primo (-ss) che toglie la "testa", così il video lo faccio cominciare sempre con un k-frame(nell'esempio è al secondo 3 ), mentre il decoder registra anche a partire da un delta-frame e questo manda in crisi alcuni player tipo VLC (forse in mkv lo digerisce, non ho provato mi sa, ma comunque mi pare più sensato partire da un k-frame).

Prima usavo Avidemux per 'ripassare' il file , ma a volte se trova qualcosa che non va nel flusso magari a metà film, crasha... e il video termina in quel punto. Per cui Avidemux lo uso solo per editare il file, dopo averlo preventivamente ripassato con ffmpeg di linea di comando. In ultimo il file definitivo lo ripasso in ogni caso con mkvtoolnix per impostare al meglio il contenitore mkv. Anche mkvtoolnix usato direttamente sul .ts acquisito può incappare in problemi se ci sono punti corrotti.
Clicca per espandere...

Io di solito procedo in questo modo, ma ovviamente il fatto di usare i comandi in linea ti permette di ottimizzare la cosa anche tramite batch.. e lo capisco nel caso si abbia a che fare con una marea di file..

1, unisco gli spezzoni
2, uso vidcoder per tagliare la testa e la coda ed avere un mp4 magari anche ridimensionato (per certe registrazioni avere un FHD potrebbe anche essere troppo), cntrollando il risultato lato lipsync (si può anche usare handbrake ma vidcoder è un pelo più intuitivo nei parametri; tieni conto che comunque mi salvo i preset di ricodifica così a seconda della sorgente scelgo quello più adatto)
3, uso avidemux che mastica molto meglio un mp4 rispetto un ts (decisamente molto meglio.. non fa nellemo l'index in apertura..) e tolgo le pubblicità.. e spesso non serve ricodificare nulla dato che puoi impostare semplicemente la modalità copy.. avendo già il sorgente sistemato lato codec e lipsync si guadagna un po' di tempo (non sempre è così ma quando si può..)

Tengo tutto con una perdita del 15%/18% che è un buon compromesso tra qualità e dimensione del file finale quando riduci da FHD a HDReady ad esempio.
 
Devi accedere o registrarti per poter rispondere.
Indietro
Alto Basso