Formato video universale senza perdite

Sto cercando di trovare il formato video lossless più adatto per video a 1280x720 a 25 fps. Il video ha 4 minuti. Il suono sarà di 320 kbps mp3, che non è un grosso problema. Condizioni ideali:

Senza perdita (può essere percezione senza perdita)
Container + codec possono essere riprodotti sulla maggior parte delle piattaforme
Il contenitore + codec può essere riprodotto su moderni lettori DVD (supportando altri formati oltre al DVD)
La dimensione è inferiore a 700 MB

È anche possibile? Sono già in difficoltà da tre giorni, senza risultati soddisfacenti, anche ottenendo file da 12 GB (sembra molto - 3 GB / minuto).

video ffmpeg video-editing

— Mrkva
fonte

Per un confronto, vedere en.wikipedia.org/wiki/List_of_codecs#Lossless_compression

— artistoex

Mi dispiace ma praticamente non puoi ottenere un video 720p (visivamente) senza perdita di 4 minuti compresso a meno di 700 MB (ho ipotizzato Megabyte qui, non "mb" che significherebbe "bit"). Perché hai un tale vincolo? Il video non può essere codificato in h.264?

— slhck,

sì, MB, scusa per la confusione. Devo inserire 5 video cca x 4 minuti in 4 GB (limiti medi).

— mrkva,

Dal momento che stai ottenendo file 12GiB suppongo che tu usi la profondità del colore 24Bit. Il flusso di dati video non compresso è di circa 4GiB al minuto. È un'enorme quantità di dati. Quello che vuoi è di circa 170 MiB al minuto. Indipendentemente dal codec che scegli, puoi ottenerlo solo con una scena statica senza molti movimenti. Temo che tu debba rilassare la contrapposizione per essere senza perdita, ridurre la frequenza dei fotogrammi o tollerare dimensioni di file maggiori.

— Marco,

Puoi chiarire "Il contenitore + codec può essere riprodotto su moderni lettori DVD (supportando altri formati oltre al DVD)"?

— llogan,

Risposte:

Il miglior formato attuale, matematicamente senza perdita di dati che conosco è huffyuv, ma questo produrrà file esilaranti e non sarebbe compatibile con molti. Per la cronaca, ffmpeg può farlo con:

ffmpeg -i input -c:v huffyuv -c:a libmp3lame -b:a 320k output.avi

X264, l'encoder h.264 open source, ha una modalità lossless. Questo può andare all'interno di un contenitore MP4 e dovrebbe essere compatibile con la maggior parte dell'hardware prodotto negli ultimi anni. Il primo comando fornirà una velocità di codifica rapida, ma file di grandi dimensioni; il secondo comando richiederà molto più tempo, ma il file dovrebbe essere circa la metà di quello con codifica rapida (sarà comunque abbastanza grande):

ffmpeg -i input -c:v libx264 -crf 0 -preset ultrafast -c:a libmp3lame -b:a 320k output.mp4

ffmpeg -i input -c:v libx264 -crf 0 -preset veryslow -c:a libmp3lame -b:a 320k output.mp4

Se ciò non ti dà un file abbastanza piccolo, un crf di 18 è generalmente considerato 'visivamente senza perdita':

ffmpeg -i input -c:v libx264 -crf 18 -preset veryfast -c:a libmp3lame -b:a 320k output.mp4

In generale, consiglio la preimpostazione molto veloce per la codifica con x264, nella mia esperienza offre il miglior compromesso di velocità / dimensione (c'è un grande calo nella dimensione del file tra superveloce e molto veloce, qualsiasi più lento di quello ed è più incrementale). Il consiglio generale è di usare il preset più lento che puoi gestire, i preset sono: ultraveloce, superveloce, molto veloce, più veloce, veloce, medio, lento, più lento, veryslow.

Vedi qui per una guida più approfondita alla codifica x264.

— evilsoup
fonte

Non suggerire veryfastcome un buon default per x264 con perdita di dati. mediumè una buona via di mezzo, ma di solito lo uso veryslowper la codifica finale di qualsiasi cosa. Inoltre huffyuvnon è nemmeno molto veloce, non lo consiglierei a nient'altro che alla compatibilità.

— Peter Cordes,

ffmpeg ha alcuni altri codec senza perdita che potrebbero valere la pena provare [mi viene in mente anche FFv1]. GL!

— rogerdpack,

Libx264 non esegue il downsampling dei due canali di colore (in YUV UV) della metà in entrambe le direzioni anche se si utilizza un CRF di 0, quindi non è veramente senza perdita di dati. Inoltre, con errori di arrotondamento, non è garantito che i dati siano identici bit per bit dopo un giro di compressione x264.

— Adisak,

Nei miei esperimenti con ffmpeg 3.4.1, libx264 utilizzava il formato pixel yuv444, dove "444" significa "non sottocampionare la parte U, V". E l'OP non si preoccupa esplicitamente degli errori di arrotondamento: "può essere percettivamente senza perdita". Quindi, @Adisak, le tue preoccupazioni sono ragionevoli, ma non applicabili a questa risposta.

— Jim DeLaHunt

ffmpeg e libx264 in modalità YUV negozieranno un formato pixel YUV basato sull'input. Quindi, se l'input è YUV 4: 2: 0, lo è anche il formato dei pixel di output. Se l'ingresso è YUV 4: 4: 4 o RGB, allora l'uscita è YUV 4: 4: 4.

— Gyan,

In questi giorni mi piace il webm :

ffmpeg -i input.avi -c:v libvpx-vp9 -lossless 1 output.webm

Per convertire più velocemente, con processori multi-core, ho letto che si consiglia di utilizzare un thread in meno rispetto a quello dei core reali. Quindi, con un 8 core potresti specificare 7 thread in questo modo:

ffmpeg -i input.avi -c:v libvpx-vp9 -threads 7 -lossless 1 output.webm

— LonnieBest
fonte

Mi piace utilizzare la variabile di ambiente% NUMBER_OF_PROCESSORS% per determinare il conteggio dei thread da utilizzare. Se il conteggio è 1 o 2, ho usato tutti i processori. Se il conteggio è 3 o 4, utilizzo tutto tranne un processore. E se il conteggio è più alto, uso tutti i processori tranne due per il conteggio dei thread.

— Adisak,

Come espressioni DOS, è simile al seguente: se "% ADJUSTED_CPUCOUNT%" EQU "" (se% NUMBER_OF_PROCESSORS% EQU 1 (imposta ADJUSTED_CPUCOUNT = 1) altrimenti se% NUMBER_OF_PROCESSORS% EQU 2 (imposta ADJUSTED_CPUCOUNT = 2) %PROCOR EQU 3 (imposta ADJUSTED_CPUCOUNT = 2) altrimenti se% NUMBER_OF_PROCESSORS% EQU 4 (imposta ADJUSTED_CPUCOUNT = 3) altro (imposta / A ADJUSTED_CPUCOUNT =% NUMBER_OF_PROCESSORS% -2))

— Adisak

superuser.com/questions/155305/… afferma che ffmpeg sceglie già il numero ottimale di thread

— Boris,

Una scelta migliore di webm (in questi giorni) è forse il formato av1 .

— LonnieBest,

-1

# CONTENITORE

per avere la piena compatibilità con i lettori DVD, dovrai usare il formato MPEG-2, il contenitore, le restrizioni, i codec. Immagino che "giocatori moderni" significhino compatibilità "mp4", che è fondamentalmente e principalmente un lettore di file mp4 - H.264, MPEG-4, AVC => libx264
leggi di più: https://de.wikipedia.org/wiki /H.264

# VIDEO

Dai un'occhiata a https://trac.ffmpeg.org/wiki/Encode/H.264 , in particolare la parte in cui si tratta di "profilo" e "livello", per compatibilità
Usando -profile:v high -level 4.0dovrebbe farlo

# AUDIO

Evita di ricodificare le tracce audio con codec con perdita: qualsiasi formato mp3 è con perdita, anche a 320 kbps.
Usa -c:a copyinvece.

Finora ha fatto un ottimo lavoro per me. nessun problema di sincronizzazione.
I flussi audio non sono associati a fotogrammi chiave. Sono possibili tagli precisi.
Se la traccia audio è registrata a una frequenza di campionamento di 44 kHz, utilizzare max. 256kbps

Usa i codec con perdita di dati solo per la codifica finale del tuo video, se devi soddisfare determinati prerequisiti.

Ho sentito parlare di alcuni problemi di sincronizzazione audio, ma sembra che il problema principale ci fosse, era materiale protetto (!).

# Infine

Preferirei qualcosa del genere:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4

— d'oh
fonte

L'opzione "-level 4.0" non è necessaria. Il livello in x264 è determinato in base alla risoluzione e all'FPS, quindi di solito non ha senso impostarlo manualmente, ciò non migliorerà nulla. Per quanto ne so ffmpeg può impostare automaticamente il livello corretto, quindi a meno che tu non abbia ottime ragioni per forzarlo e comprendere appieno come scegliere il livello basato su FPS e risoluzione, non dovresti usare l'opzione "-level". Se ti interessa la massima compatibilità, usa il profilo "baseline" anziché "high".

— Lissanro Rayen,