Estou tentando converter minha biblioteca de vídeo no formato HEVC para ganhar espaço. Executei o seguinte comando em todos os arquivos de vídeo em minha biblioteca:

 #!/bin/bash for i in *.mp4; do #Output new files by prepending "X265" to the names avconv -i "$i" -c:v libx265 -c:a copy X265_"$i" done  

Agora, a maioria dos vídeos converte bem e a qualidade é a mesma de antes. No entanto, alguns vídeos de muito alta qualidade (por exemplo, uma impressão de filme de 5 GB) perdem qualidade – o vídeo fica todo pixelado.

Não tenho certeza do que fazer neste caso. Preciso modificar o parâmetro crf em minha linha de comando? Ou outra coisa?

A questão é que estou fazendo uma conversão em massa. Portanto, preciso de um método em que avconv ajuste automaticamente qualquer parâmetro que precise de ajuste para cada vídeo.

UPDATE-1

Eu descobri que crf é o botão que preciso ajustar. O CRF padrão é 28. Para melhor qualidade, eu poderia usar algo menor que 28. Por exemplo:

avconv -i input.mp4 -c:v libx265 -x265-params crf=23 -c:a copy output.mp4 

No entanto, o problema é que para alguns vídeos CRF valor de 28 é bom o suficiente, enquanto para alguns vídeos, CRF mais baixo é necessário. Isso é algo que eu tenho que verificar manualmente, convertendo pequenas seções dos grandes vídeos. Mas, na conversão em massa, como eu verificaria cada vídeo manualmente? Há alguma maneira de avconv ajustar o CRF de acordo com o vídeo de entrada de forma inteligente?

UPDATE-2

Eu descobri que há um --lossless opção em x265: http://x265.readthedocs.org/en/default/lossless.html .

No entanto, não sei como usá-lo corretamente. Tentei usá-lo da seguinte maneira, mas obteve resultados opostos (o vídeo ficou ainda mais pixelado):

avconv -i input.mp4 -c:v libx265 -x265-params lossless -c:a copy output.mp4 

Comentários

  • --lossless pode de fato ampliar o arquivo, se decodificar o codec anteriormente com perdas e então descodifica o que fez decodificar sem perdas. A qualidade permanecerá exatamente a mesma da entrada.
  • Se suas fontes estiverem codificadas com perdas (o que é mais provável), então o que você está tentando alcançar é impossível. não é sem perdas irá degradar a qualidade ainda mais (mesmo que não seja imediatamente visível para você) e se você converter de com perdas para sem perdas, você obterá tamanhos de arquivo maiores .

Resposta

De minha própria experiência, se você não quiser absolutamente nenhuma perda de qualidade, –lossless é o que você está procurando.

Não tenho certeza sobre avconv, mas o comando que você digitou parece idêntico ao que eu faço com FFmpeg. Em FFmpeg, você pode passar o parâmetro assim:

ffmpeg -i INPUT.mkv -c:v libx265 -preset ultrafast -x265-params lossless=1 OUTPUT.mkv 

Mais x265 (opções sem valor) podem ser especificadas desta forma (exceto aquelas somente CLI, aquelas são usadas apenas com x265 binário diretamente).

Com isso resolvido, gostaria de compartilhar minha experiência com a codificação x265. Para a maioria dos vídeos (seja WMV, MPEG ou AVC /H.264) Eu uso crf=23. x265 decide o restante dos parâmetros e geralmente faz um trabalho bom o suficiente.

No entanto, muitas vezes, antes de me comprometer com a transcodificação de um vídeo em sua totalidade, eu testo minhas configurações convertendo uma pequena parte do vídeo em questão. Aqui está um exemplo, suponha que um arquivo mkv com fluxo 0 sendo vídeo, fluxo 1 sendo áudio DTS e o stream 2 sendo uma legenda:

ffmpeg -hide_banner \ -ss 0 \ -i "INPUT.mkv" \ -attach "COVER.jpg" \ -map_metadata 0 \ -map_chapters 0 \ -metadata title="TITLE" \ -map 0:0 -metadata:s:v:0 language=eng \ -map 0:1 -metadata:s:a:0 language=eng -metadata:s:a:0 title="Surround 5.1 (DTS)" \ -map 0:2 -metadata:s:s:0 language=eng -metadata:s:s:0 title="English" \ -metadata:s:t:0 filename="Cover.jpg" -metadata:s:t:0 mimetype="image/jpeg" \ -c:v libx265 -preset ultrafast -x265-params \ crf=22:qcomp=0.8:aq-mode=1:aq_strength=1.0:qg-size=16:psy-rd=0.7:psy-rdoq=5.0:rdoq-level=1:merange=44 \ -c:a copy \ -c:s copy \ -t 120 \ "OUTPUT.HEVC.DTS.Sample.mkv" 

Observe que as barras invertidas sinalizam quebras de linha em um comando longo, eu faço isso para me ajudar a manter o controle de vários bits de uma entrada CLI complexa. Antes de explicar linha por linha, a parte em que você converte apenas uma pequena parte de um vídeo é a segunda linha e a penúltima linha: -ss 0 significa buscar 0 segundo antes começa a decodificar a entrada e -t 120 significa parar de gravar na saída após 120 segundos. Você também pode usar os formatos de hora hh: mm: ss ou hh: mm: ss.sss.

Agora, linha por linha:

  1. -hide_banner evita que FFmpeg mostre informações de compilação no início. Só não quero ver quando rolar para cima no console;
  2. -ss 0 busca 0 segundo antes de começar a decodificar a entrada. Observe que, se este parâmetro é fornecido depois do arquivo de entrada e antes do arquivo de saída, torna-se uma opção de saída e informa ffmpeg para decodificar e ignorar a entrada até x segundos e, em seguida, começar a gravar na saída. Como opção de entrada, é menos precisa (porque a busca não é precisa na maioria dos formatos de contêiner), mas quase não leva tempo.Como opção de saída, é muito preciso, mas leva um tempo considerável para decodificar todo o stream antes do tempo especificado e, para fins de teste, você não quer perder tempo;
  3. -i "INPUT.mkv": Especifique o arquivo de entrada;
  4. -attach "COVER.jpg": Anexe uma arte da capa (imagem em miniatura, pôster, qualquer outro) à saída. a arte da capa é geralmente mostrada em exploradores de arquivos;
  5. -map_metadata 0: Copia sobre todos e quaisquer metadados da entrada 0, que no exemplo é apenas a entrada;
  6. -map_chapters 0: Copia as informações do capítulo (se houver) da entrada 0;
  7. -metadata title="TITLE": Defina o título do vídeo;
  8. -map 0:0 ...: Mapeie o fluxo 0 da entrada 0, o que significa que queremos que o primeiro fluxo da entrada seja gravado na saída . Visto que este fluxo é um fluxo de vídeo, é o primeiro fluxo de vídeo na saída , daí o especificador de fluxo :s:v:0. Defina seu idioma tag para inglês;
  9. -map 0:1 ...: Semelhante à linha 8, mapeie o segundo fluxo (áudio DTS) e defina seu idioma e título (para facilitar a identificação ao escolher dos jogadores);
  10. -map 0:2 ...: Semelhante à linha 9, exceto que este fluxo é uma legenda;
  11. -metadata:s:t:0 ...: Definir metadados para a arte da capa. Isso é necessário para o formato de contêiner mkv;
  12. -c:v libx265 ...: opções de codec de vídeo. É tão longo que dividi em duas linhas. Esta configuração é boa para vídeo bluray de alta qualidade (1080p) com bandas mínimas em gradiente (que x265 é péssimo). Provavelmente é um exagero para DVDs, programas de TV e vídeos de telefone. Esta configuração é principalmente roubada desta postagem do Doom9 ;
  13. crf=22:...: Continuação do codec de vídeo parâmetros. Veja a postagem do fórum mencionada acima;
  14. -c:a copy: Copiar sobre áudio;
  15. -c:s copy : Copiar sobre as legendas;
  16. -t 120: Pare de gravar na saída após 120 segundos, o que nos dá um clipe de 2 minutos para visualizar a qualidade de trancodificação;
  17. "OUTPUT.HEVC.DTS.Sample.mkv": Nome do arquivo de saída. Eu marquei meus nomes de arquivo com o codec de vídeo e o codec de áudio principal.

Ufa. Esta é minha primeira resposta, então se houver algo que eu esqueci, por favor, deixe um comentário. Não sou um especialista em produção de vídeo, sou apenas um cara que tem preguiça de assistir a um filme colocando o disco no player.

PS. Talvez esta pergunta pertença a outro lugar, pois não está fortemente relacionado ao Unix & Linux.

Comentários

  • Exatamente o que eu estava procurando ! Ótima cobertura de opções. Você sabe se o ffmpeg se recusará a c:s copy se não houver conteúdo de legenda?
  • @ElderGeek Não, o ffmpeg só dirá algo se essa opção tiver algum efeito.
  • @TheBitByte Sim e não, eu acho. Você não ‘ não deseja arquivos h265 sem perdas. É ‘ é apenas um fluxo de bits bruto, sem qualquer tipo de compressão. É ‘ enorme. Pelo que entendi sobre h265 ou especificamente a implementação x265, não é um método de compactação sem perdas. Qualquer grau de compressão resultará na perda de informações, mas não necessariamente na perda da qualidade de visualização. Mas eu ‘ não sou um especialista em tópicos h265, então ‘ é possível que eu tenha perdido algo
  • @ TheBitByte eu não ‘ não acho que haja um nível de compactação sem perdas em h265. Para a opção sem compressão, ‘ é apenas --lossless. Procurei em vão por uma conversão sem perdas de h264 para h265, e o que ‘ aprendi me diz que ‘ é matematicamente impossível. / li>
  • Você realmente deve editar o comando que contém a --lossless opção desta resposta, porque colocado lá como uma resposta a esta pergunta parece que você ‘ estou dizendo ‘ compressão sem perdas, o que é enganoso.

Resposta

Recentemente, tive o problema de transcodificar todo o meu catálogo de vídeos para HEVC. Eu uso https://github.com/FallingSnow/h265ize com as seguintes configurações.

h265ize -v -m medium -q 20 -x –no-sao – -aq-mode 3 –delete –stats

-v – Saída detalhada
-m meio – Meio velocidade de codificação (menor, maior qualidade, qualquer coisa mais lenta que eu achar que não vale a diferença de tempo / qualidade)
-q 20 – o CRF usado, 20 é semelhante a 18 ou mais em x264, mas hey.Isso é para conteúdo 1080p (90% da minha TV). Costumo usar 22 para meus filmes 4K
-x – Use os comandos definidos centralmente x265
–no-sao desativa o Sample Adaptive Offset (melhora a velocidade de codificação)
–aq-mode 3 – use a quantização adaptativa com variância automática, ajuda a codificar 8 bits, especialmente em áreas escuras, para a maior parte das bandas que podem acontecer (embora às custas do tempo de codificação)
–delete – substitua o arquivo de codificação por arquivo codificado (teste antes de usar este)
–stats – Grava estatísticas em um arquivo csv na raiz do caminho que você percorreu.

As velocidades de codificação estão em torno de 30 fps (para a maioria das coisas de 1080p) no meu equipamento. Dual Xeon E5 2687W v2, mas eu forço o processo FFMPEG a não usar o primeiro lado de um dos processadores (é meu servidor Plex, então tenho que ter certeza de que há sobrecarga para transcodificação se necessário na reprodução, etc.)

Sim, demorou um pouco para converter a maior parte dele, e agora tenho uma tarefa agendada que é executada duas vezes ao dia para codificar as coisas daquele dia para x265.

A economia de espaço foram enormes. Meu SAN inicial estava com 20 TB de uso, agora está em torno de 12, mas obviamente também foi adicionado com mais 6 meses de conteúdo.

Eu comecei a transcodificar todos os meus filmes também, no entanto, isso é um processo contínuo, já que tenho que identificar os níveis de qualidade (felizmente, Radarr rotula bem) e usar uma das três configurações de transcodificação:

-m slower -q 18 -x --no-sao --aq-mode 3 para transcodificações 720p
-m medium -q 20 -x --no-sao --aq-mode 3 para 1080p
-m medium -q 22 -x --no-sao para 2160p

Espero que ajude algumas pessoas. Grite se alguém precisar de manualmente configurando tudo. E antes de codificar tudo para x265, pense na reprodução, se o cliente não suportar x265 nativo, a transcade pode ser cara em termos de CPU e qualidade.

Comentários

  • Com x265 2.4 e posterior (com as novas tabelas lambda que fornecem codificações mais nítidas), SAO é geralmente uma boa coisa para qualidade por taxa de bits. Ainda mancha um pouco, mas reduz outros artefatos o suficiente para valer a pena.
  • -q 20 não é CRF 20, é ‘ s controle de proporção QP constante . O modo padrão e recomendado, CRF, aumenta o QP em cenas de alta complexidade, de forma que não ‘ gasta muito bits em cenas que são muito difíceis de codificar. (Se você quiser mais perto do QP uniforme, eleve qcomp do padrão 0,6 para talvez 0,7 ou 0,8. Mais perto de 1,0 é mais perto do CQP.)
  • como você lida com codificações hdr / sdr quando você não ‘ não sabe qual é a fonte?

Resposta

A sintaxe correta para ativar o modo sem perdas para o codificador x265 no ffmpeg é -x265-params lossless=1 (você precisa anexar =1).

No entanto, para codificação sem perdas, existem melhores opções de codec. Eu descobri testando que FFV1 compacta muito melhor (tamanho do arquivo = ~ 80% de x265) pelo menos em alguns tipos de vídeo (se as melhores configurações forem escolhidas para ambos codecs). E também funciona mais rápido e (AFAIK) não é onerado por patentes. Ou seja, é superior ao H.265 sem perdas em todos os aspectos para arquivamento de vídeo. O compromisso, entretanto, é a compatibilidade com o software e hardware de reprodução atual.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *