La compressione dei video crea file ancora più grandi

17

Ho usato la GUI (tasto destro => comprimi) per provare a comprimere un .tar contenente 3 video per un totale di 1,7 gb (.H264 MP4s). gzip, lrzip, 7z ecc. non fanno nulla per la dimensione del file e anche la cartella compressa è di 1,7 GB.

Ho quindi provato a eseguire lrzip dalla riga di comando (nel caso si trattasse di un problema con la GUI) e ho usato il flag -z (compressione estrema), e questo era il mio output.

inserisci qui la descrizione dell'immagine

Come mostra il rapporto di compressione, la dimensione effettiva della cartella compressa è maggiore dell'originale! Non so perché non ho fortuna, in particolare lrzip dovrebbe essere efficace in base alle recensioni casuali che ho letto e ai documenti ufficiali (file più grandi di 100 MB, maggiore è il migliore) - vedi https: //wiki.archlinux. org / index.php / Lrzip

Perché non riesco a comprimere i miei file?

gzip

— sottovento
fonte

2

Personalmente non mi preoccuperò di archiviare i video mp4 poiché questi video sono già compressi dal codec.

— carrozzina

E puoi ottenere dimensioni inferiori utilizzando strumenti di conversione / compressione video come FFMpeg .

— Jet,

carrozzina e Jet sono corretti. Questo è un comportamento previsto. È controproducente cercare di comprimere qualcosa che è già ben compresso. Se si utilizzano strumenti di conversione video, è possibile risparmiare spazio a spese della qualità del video (apparente o meno). Inizia comunque con la copia meno compressa della più alta qualità che possiedi.

— John S Gruber,

25

Come @pram ha detto sopra nel commento, i video mp4 sono già compressi e altri formati video probabilmente usano anche la compressione in una certa misura. Pertanto, il tentativo di comprimerli non comporterà una riduzione (se del caso) di dimensioni ridotte (questo vale anche, almeno in parte, per le immagini e la musica). In questo caso, sembra che i metadati (per il file compresso stesso) potrebbero causare l'aumento. L'unico formato di compressione che potrebbe (e questo è un forte punto di forza) comportare una certa riduzione è xz.

In un'altra nota, se vuoi ridurre le dimensioni di quei video, cerca invece di ricodificare i video usando qualcosa come il freno a mano.

— saiarcot895
fonte

3

Trovo che il webm abbia buoni tassi di compressione in generale. Molto più piccolo di mp4.

— Seth,

@Seth in realtà MP4 (che è o AVC aka h.264 o il più nuovo e migliore h.265 aka codec HEVC) offre file più piccoli con la stessa qualità (o una qualità migliore con le stesse dimensioni del file).

— David Balažic,

@ DavidBalažic stiamo confrontando mele e mele qui, quando stiamo cercando di parlare di arance. mp4 e webm sono entrambi contenitori, non hanno nulla a che fare con la compressione. Hai ragione sul fatto che h.264 e h.265 sono entrambi codec comunemente usati nei contenitori mp4, ma non puoi confrontare h.265 con webm . h.264 è paragonabile al codec vp8 comunemente usato nei contenitori webm, così come h.265 è paragonabile al codec vp9, anch'esso generalmente contenuto da webm. tl; dr: usa h.265 in mp4 e vp9 in webm e otterrai all'incirca la stessa qualità / efficienza.

— forresthopkinsa,

13

In realtà, il fatto che i file siano già compressi non è il problema cruciale. È questo: la compressione in generale può funzionare solo se i dati contengono una ridondanza . Questo è praticamente sempre il caso dei file non compressi, tuttavia non è necessariamente ovvio quale sia la ridondanza. Gli algoritmi di compressione per scopi generali mirano principalmente al tipo di cosa evidente nei file di testo: molte parole appaiono non solo una volta ma molte volte in forma identica, forse frasi di parole possono essere combinate, ecc. Ecc. Gli algoritmi sono abbastanza buoni in generalizzando questo a qualsiasi cosa, dagli elenchi di numeri di telefono con codifica ASCII alla poesia cinese al codice binario della macchina, ma non possono funzionare per nessun tipo di dati. In particolare, i file multimediali sono concettualmentedati analogici , in una rappresentazione digitale rumorosa. Ciò significa che non esiste davvero alcun tipo di ridondanza dei file di testo: alcuni motivi potrebbero essere ricorrenti, ma sempre con una configurazione leggermente diversa del rumore del sensore. Ecco perché tutti i formati di immagini / AV compressi utilizzano una trasformazione scelta in modo intelligente come primo passo di codifica, normalmente basato su DCT o wavelet . Queste trasformazioni in termini approssimativi spostano le porzioni di immagini e le porzioni di rumore in posizioni diverse, quindi possono essere separate e con una compressione con perdita di dati conservate solo le informazioni che ritenete più "importanti", che non includono il rumore, mentre il " una buona informazione "ha molta ridondanza. (Non è così che funziona, ma in un certo senso.)

Se i compressori per uso generale usassero queste trasformazioni, l'effetto sarebbe l'opposto: la maggior parte delle informazioni digitali verrebbero effettivamente classificate erroneamente come un qualche tipo di rumore, perché manca della struttura "liscia" che si trova nei segnali analogici. E dopo una compressione video con perdita di dati, ovviamente, né la levigatezza analogica né la ricorrenza digitale non possono più essere trovate (se lo fosse, i codec userebbero un altro bzip-stage o qualcosa di loro!)

— leftaroundabout
fonte

12

Il motivo per cui non hai fortuna è che mp4 è già compresso, non puoi comprimerlo ulteriormente. Tutto quello che stai facendo è aggiungere le informazioni di intestazione del formato di compressione al file.

Poiché i file sono già compressi e non è possibile comprimerli ulteriormente, ciò comporta un aumento delle dimensioni del file poiché tutto ciò che stai facendo è mantenere le stesse informazioni e aggiungere qualche byte in più di informazioni sull'intestazione.

— terdon
fonte

5

Questo è un bell'esempio del principio del buco del piccione .

Dato che il file è già compresso (con perdita), non c'è nessuna o nessuna riduzione da ottenere ovunque, il che significa che sei già a guadagno netto pari a zero. Come menzionato dagli altri, il formato compresso stesso ha una certa perdita, generalmente trascurabile, nei propri metadati. Tutto ciò si combina significa che probabilmente non è rimasto alcun buco nel set di file uguali o più piccoli e quindi i dati compressi rientrano nel set di file più grandi.

— Livio
fonte

4

Mi dispiace, ma si tratta di un'applicazione errata di tale principio. È possibile applicare la stessa logica a un file da 1,7 GB pieno di zero e ottenere una risposta errata. Il principio pigeonhole viene generalmente utilizzato per dimostrare l' esistenza di file non comprimibili, non per dimostrare che un determinato file sia effettivamente non comprimibile. (Quest'ultimo è imputabile, poiché la funzione di complessità di Kolmogorov non è una funzione calcolabile).

— nneonneo,

1

@nneonneo Quindi sentiti libero di correggere l'articolo di Wikipedia collegato. L'esistenza di file incomprimibili ne deriva direttamente e quindi si aggiungono i metadati di compressione e improvvisamente si ha un file più grande dell'originale. È esattamente quello che ho detto. La prova che il file non è ulteriormente comprimibile in una data implementazione di un determinato algoritmo è che l'output non è più piccolo. Naturalmente, è anche possibile che i metadati siano semplicemente più grandi della vincita della compressione, ma non sono sicuro di averlo descritto come compresso in senso orientato all'utente.

— Livio

@Livius L'articolo di Wikipedia è corretto: usa il principio del piccione per dimostrare l' esistenza di file non comprimibili per ogni dato algoritmo di compressione senza perdita. Ma non puoi derivare la incomprimibilità di un determinato file solo dal principio pigeonhole.

— David Richerby,

@DavidRicherby Sì, ma il fatto che il file non sia compresso da una determinata implementazione di un determinato algoritmo è la prova che non è comprimibile. A meno che non vi siano altri motivi per l'esistenza di file incomprimibili, ne consegue che la mancata compressione è dovuta al PP. L'unica altra ragione possibile sarebbe perché un determinato algoritmo non vede alcun modo per ridurne le dimensioni, che sembra essere ancora un caso di "sotto i presupposti dell'algoritmo, non esiste un file più piccolo con le stesse informazioni; tali casi esistono necessariamente a causa della PP ".

— Livio

Più precisamente, il PP forza l'algoritmo ad avere input la cui immagine non si trova nello spazio di file più piccoli. Ogni decisione che porta all'immagine di un dato file che non rientra in quello spazio è quindi su un certo livello guidato dal PP e dai compromessi che forza, (assumendo una sana definizione di algoritmo di compressione). Quindi qualsiasi file la cui immagine non è più piccola appartiene all'insieme che la PP ha escluso dalla compressione. La prova che un determinato file non è comprimibile è la sua incapacità di comprimere; in senso lato, l'incomprimibilità è sempre il risultato della PP e dei suoi compromessi.

— Livio

4

Se vuoi comprimere questi file dovrai ridurre la qualità.

Senza sapere per quanto tempo e quale formato e tipo di contenuto questi file sono difficili da capire se questi file hanno spazio per essere ridotti senza una notevole perdita di qualità.

BluRays con video 1080p tende a salire di 25 GB, quindi è improbabile che tu abbia già un rapporto qualità-dimensione ottimale per H.264.

Puoi provare a usare ffmpego avconvper convertire i file.

Potresti iniziare con ffmpeg -i input_file.mp4 -preset slower -crf 20 -c:a copy output_file.mp4

Il anconvcomando funzionerà in modo simile.

Aumenta il -crfvalore per ridurre la dimensione e la qualità del file, non ti consiglio più di 25.
È possibile modificare la preimpostazione su slowo mediumper aumentare la velocità, ma le dimensioni del file ne risentiranno rispetto slowero addirittura veryslow(se si è molto pazienti!).
Altre impostazioni sono disponibili qui: http://mewiki.project357.com/wiki/X264_Settings
Consiglio di stare alla larga dalla maggior parte poiché i preset forniscono impostazioni predefinite corrette, con -tunel'eccezione.
Prova un denoiser se il tuo contenuto è film ( -vf hqdn3d) puoi migliorare la qualità visiva rispetto all'uso di un -crfvalore elevato .
Riduci i contenuti -vf scale=-1:720per 720p e -vf scale=-1:480480p per migliorare la velocità di codifica e mantenere la qualità.

— Daniel Hill
fonte