Formato de vídeo universal sem perdas

Estou tentando encontrar o formato de vídeo sem perdas mais adequado para vídeos de 1280x720 25fps. O vídeo tem 4 minutos. O som será mp3 de 320 kbps, o que não é grande coisa. Condições ideais:

Sem perdas (pode ser perceptivamente sem perdas)
O container + codec pode ser reproduzido na maioria das plataformas
O codec Container + pode ser reproduzido em aparelhos de DVD modernos (compatíveis com outros formatos que não DVD)
O tamanho é inferior a 700 MB

É mesmo possível? Já lutam há três dias, sem resultados satisfatórios, chegando a receber arquivos de 12 GB (parece muito - 3 GB / minuto).

video ffmpeg video-editing

— mrkva
fonte

Para uma comparação, consulte en.wikipedia.org/wiki/List_of_codecs#Lossless_compression

— artistoex

Sinto muito, mas você praticamente não pode obter um vídeo 720p (visualmente) sem perdas de 720p de 4 minutos compactado para menos de 700 MB (assumi Megabyte aqui, não "mb", o que significaria "bit"). Por que você tem essa restrição? O vídeo não pode ser codificado em h.264?

— slhck

Sim, MB, desculpe pela confusão. Preciso ajustar cca 5 vídeos x 4 minutos em 4 GB (limitações médias).

— Mrkva 11/11/12

Como você está obtendo arquivos de 12GiB, presumo que você use profundidade de cores de 24 bits. O fluxo de dados de vídeo não compactado é de cerca de 4GiB por minuto. É uma quantidade enorme de dados. O que você quer é de cerca de 170MiB por minuto. Independentemente do codec escolhido, você só pode conseguir isso com uma cena estática sem muito movimento. Receio que você precise relaxar o contraint para não perder perdas, reduzir a taxa de quadros ou tolerar um tamanho de arquivo maior.

— Marco

Você pode esclarecer: "O container + codec pode ser reproduzido em aparelhos de DVD modernos (compatíveis com outros formatos além de DVD)"?

— llogan

Respostas:

O melhor formato real, matematicamente sem perdas, que eu conheço é o huffyuv, mas que produzirá arquivos hilariantes e enormes, e não seria compatível com muito. Para o registro, o ffmpeg pode fazer isso com:

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

O X264, o codificador h.264 de código aberto, possui um modo sem perdas. Isso pode ir para dentro de um contêiner MP4 e deve ser compatível com a maioria dos hardwares fabricados nos últimos anos. O primeiro comando fornecerá uma velocidade rápida de codificação, mas um arquivo grande; o segundo comando levará muito mais tempo, mas o arquivo deve ter cerca da metade do tamanho do codificado rapidamente (ainda será bastante 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 isso não fornecer um arquivo pequeno o suficiente, um crf de 18 é geralmente considerado 'visualmente sem perdas':

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

Geralmente, recomendo a predefinição muito rápida para codificação com x264; na minha experiência, ela oferece a melhor relação velocidade / tamanho (há uma grande queda no tamanho do arquivo entre super-rápida e muito rápida, mais lenta que isso e mais incremental). O conselho geral é usar a predefinição mais lenta possível, as predefinições são: ultra-rápida, super-rápida, muito rápida, mais rápida, rápida, média, lenta, mais lenta, baixa velocidade.

Veja aqui um guia mais aprofundado sobre a codificação x264.

— evilsoup
fonte

Não sugerir veryfastcomo um bom padrão para x264 com perdas. mediumé um bom meio termo, mas eu costumo usar veryslowpara a codificação final de qualquer coisa. Também huffyuvnão é muito rápido, eu não o recomendaria por nada além de compatibilidade.

— Peter Cordes

O ffmpeg possui alguns outros codecs sem perdas que podem valer a pena tentar [o FFv1 vem à mente] também. GL!

— Rogerdpack

A libx264 não reduz a amostragem dos dois canais de cores (em YUV, UV) pela metade em qualquer direção, mesmo se você usar um CRF de 0, para que não seja verdadeiramente sem perdas. Além disso, com erros de arredondamento, não é garantido que os dados sejam indenticos bit a bit após uma rodada de compactação x264.

— Adisak

Nas minhas experiências com o ffmpeg 3.4.1, a libx264 usou o formato yuv444 pixel, onde "444" significa "não reduz a amostra da parte U, V". E, o OP explicitamente não se importa com erros de arredondamento: "pode ser perceptivamente sem perdas". Portanto, @Adisak, suas preocupações são razoáveis, mas não aplicáveis a esta resposta.

— Jim DeLaHunt

ffmpeg e libx264 no modo YUV negociarão um formato de pixel YUV com base na entrada. Portanto, se a entrada for YUV 4: 2: 0, também será o formato do pixel de saída. Se a entrada for YUV 4: 4: 4 ou RGB, a saída será YUV 4: 4: 4.

— Gyan

Hoje em dia eu gosto de webm :

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

Para converter mais rapidamente, com processadores com vários núcleos, li que é recomendável usar um thread a menos do que os núcleos reais. Portanto, com um núcleo 8, você pode especificar 7 threads como este:

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

— LonnieBest
fonte

Eu gosto de usar a variável de ambiente% NUMBER_OF_PROCESSORS% para determinar a contagem de threads a ser usada. Se a contagem for 1 ou 2, usei todos os processadores. Se a contagem for 3 ou 4, utilizo apenas um processador. E se a contagem for maior, eu uso todos os processadores, exceto dois, para a contagem de threads.

— Adisak

Como expressões do DOS, fica assim: se "% ADJUSTED_CPUCOUNT%" EQU "" (se% NUMBER_OF_PROCESSORS% EQU 1 (defina ADJUSTED_CPUCOUNT = 1) ou se% NUMBER_OF_PROCESSORS% EQU 2 (defina ADJUSTED_CPUCOUNT = 2) ou se% NUMBER_OU EQU 3 (conjunto ADJUSTED_CPUCOUNT = 2) else if% NUMBER_OF_PROCESSORS% EQU 4 (conjunto ADJUSTED_CPUCOUNT = 3) else (conjunto / A ADJUSTED_CPUCOUNT =% NUMBER_OF_PROCESSORS% -2)

— Adisak

superuser.com/questions/155305/… diz que o ffmpeg já escolhe o número ideal de threads

— Boris

Uma escolha melhor do que webm (atualmente) talvez seja o formato av1 .

— LonnieBest

-1

# CONTAINER

para ter total compatibilidade com DVD-players, você precisará usar o formato MPEG-2, contêiner, restrições, codecs. Eu acho que "players modernos" significa compatibilidade "mp4", que é basicamente e principalmente um player de arquivos mp4 - H.264, MPEG-4, AVC => libx264
leia mais: https://de.wikipedia.org/wiki /H.264

# VÍDEO

Ter um olhar para https://trac.ffmpeg.org/wiki/Encode/H.264 , especialmente a parte onde é sobre "perfil" e "nível", para compatibilidade
Usando -profile:v high -level 4.0deve fazê-lo

# AUDIO

Evite recodificar faixas de áudio com codecs com perda - qualquer formato mp3 é com perda, mesmo 320kbps.
Use em -c:a copyvez disso.

Até agora, ele fez um bom trabalho para mim. sem problemas de sincronização.
Os fluxos de áudio não estão vinculados aos quadros-chave. Cortes precisos são possíveis.
Se a sua faixa de áudio for gravada na taxa de amostragem de 44kHz, use no máx. 256kbps

Use codecs com perdas apenas para a codificação final do seu vídeo, se precisar atender a certos pré-requisitos.

Já ouvi falar de alguns problemas de sincronização de áudio, mas parece que o principal problema era o material protegido (!).

# Finalmente

Eu preferiria algo assim:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4

— d'oh
fonte

A opção "-level 4.0" não é necessária. O nível em x264 é determinado com base na resolução e no FPS; portanto, normalmente não há motivo para defini-lo manualmente, isso não melhora nada. Tanto quanto sei, o ffmpeg pode definir o nível correto automaticamente, portanto, a menos que você tenha um bom motivo para forçá-lo e compreenda completamente como escolher o nível com base no FPS e na resolução, não use a opção "-level". Se você se preocupa com a maior compatibilidade, use o perfil "baseline" em vez de "high".

— Lissanro Rayen