
Estou percorrendo um arquivo de texto, usando 'while read'. Li três variáveis de cada linha - dois nomes de arquivos e um número decimal. Eu sei que isso funciona em uma configuração vanilla (loop, linha de leitura, linha de eco, extração de variáveis, nada mais), porque testei em meu arquivo de entrada.
Estou obtendo um resultado estranho, porém, quando adiciono a essência da minha rotina - que é uma chamada ao ffmpeg para mesclar os fluxos de áudio e vídeo representados pelos nomes dos arquivos. Operações sucessivas de 'leitura' omitem os caracteres iniciais da linha. Eu leioaquique exige entrada 'read' dentro de um loop 'while read' pode causar problemas, e me pergunto se a chamada ffmpeg está fazendo algo que confunde o bash, mas isso parece improvável e bizarro! NB: Eu realmente não entendo a chamada do ffmpeg - entendi de uma resposta a outra pergunta.
Qualquer ajuda seria apreciada!
A primeira 'leitura' funciona conforme o esperado (e o comando ffmpeg é concluído):
LINE 1
vidsNeedingSound/448£generic@06_10_16-09_30_47.mp4 soundToAdd/448£generic@06_10_16-12_11_54.wav 6.988354
V: vidsNeedingSound/448£generic@06_10_16-09_30_47.mp4 A: soundToAdd/448£generic@06_10_16-12_11_54.wav D: 6.988354
A segunda 'leitura' perde 36 caracteres desde o início da linha (e o comando ffmpeg falha porque o arquivo representado pela variável V que leva o primeiro item da linha não aponta para um arquivo):
LINE 2
6-09_30_47.mp4 soundToAdd/452£generic@06_10_16-12_11_54.wav 9.64663
V: 6-09_30_47.mp4 A: soundToAdd/452...
A terceira 'leitura' funciona conforme esperado (e o comando ffmpeg é concluído):
LINE 3
vidsNeedingSound/452£left@06_10_16-09_30_47.mp4 soundToAdd/452£left@06_10_16-12_11_54.wav 9.862118
V: vidsNeedingSound/452£left@06_10_16-09_30_47.mp4 A: soundToAdd/452...
A quarta 'leitura' perde 37 caracteres (um a mais que a última falha) desde o início da linha (e o comando ffmpeg falha):
LINE 4
09_30_47.mp4 soundToAdd/452£right@06_10_16-12_11_54.wav 9.431392
V: 09_30_47.mp4 A: soundToAdd/452....
Esse é o padrão. Quando não precedido por uma chamada bem-sucedida para ffmpeg, a 'leitura' funciona conforme o esperado. Após cada chamada sucessiva de ffmpeg bem-sucedida, os caracteres são omitidos do início da linha: 36 caracteres para começar, depois 37, 38, 39...
O argumento decisivo é que quando o ffmpeg falha após uma leitura 'bem-sucedida' (devido a outro problema), a 'leitura' seguinte funciona conforme o esperado.
CONCLUSÃO: uma chamada ffmpeg bem-sucedida resulta em uma falha de leitura na próxima iteração do loop.
Por que isso acontece e como posso impedi-lo?
Aqui está o meu código: ...
# Loop through lines in the merge file
IT_COUNT=1
while read MERGE_LINE
do
echo "LINE " $IT_COUNT
((IT_COUNT+=1))
echo $MERGE_LINE # testing use
read VID_FILE AUD_FILE DURATION <<< "$MERGE_LINE" # Get the data from each line
echo "V: $VID_FILE A: $AUD_FILE D: $DURATION" # testing use
....
# add audio to video
ffmpeg -i $VID_FILE -i $AUD_FILE -filter_complex "aevalsrc=0:d=$AUD_SHIFT[s1];[s1][1:a]concat=n=2:v=0:a=1[aout]" -c:v copy -map 0:v -map [aout] $FILE_OUT -hide_banner
done <$MERGE_FILE
Obrigado por olhar!
Responder1
Use -nostdin
a opção em ffmpeg
. DeDocumentação FFmpeg:
Habilite a interação na entrada padrão. Ativado por padrão, a menos que a entrada padrão seja usada como entrada. Para desativar explicitamente a interação, você precisa especificar
-nostdin
.Desabilitar a interação na entrada padrão é útil, por exemplo, se o ffmpeg estiver no grupo de processos em segundo plano. Aproximadamente o mesmo resultado pode ser alcançado,
ffmpeg ... < /dev/null
mas requer um shell.
Responder2
Você provavelmente está certo ao dizer que o ffmpeg provavelmente está lendo sua entrada, quem sabe por quê, então simplesmente redirecione esse comando para read from /dev/null
, ou seja, adicione à linha ffmpeg </dev/null
.