bash script: 'while read' percorre as linhas no arquivo de texto perdendo caracteres. linha de ffmpeg para culpar?

1

Estou fazendo um loop em um arquivo de texto, usando 'while read'. Eu 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 baunilha (loop, ler linha, linha de eco, extrair variáveis, nada mais), porque eu testei no meu arquivo de entrada.

Estou obtendo um resultado estranho, no entanto, uma vez que adiciono a carne da minha rotina - que é uma chamada ao ffmpeg para mesclar os fluxos de áudio e vídeo representados pelos nomes dos arquivos. Sucessivas operações de 'leitura' omitem os caracteres iniciais da linha. Eu li aqui que exige entrada de 'leitura' dentro de um loop 'while read' pode causar problemas, e se perguntar se a chamada ffmpeg está fazendo algo que confunde bash, mas isso parece improvável e bizarro! NB: Eu realmente não entendo a chamada do ffmpeg - eu peguei de uma resposta para outra pergunta.

Qualquer ajuda seria apreciada!

A primeira 'leitura' funciona como 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

O segundo 'read' perde 36 caracteres desde o início da linha (e o comando ffmpeg falha porque o arquivo representado pela variável V que pega 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...

O terceiro 'read' funciona como 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...

O quarto 'read' perde 37 caracteres (um a mais que o último falha) desde o começo 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 ao ffmpeg, a 'leitura' funciona conforme o esperado. Depois de cada chamada de ffmpeg sucessiva sucessiva, os caracteres são omitidos do começo da linha: 36 caracteres para começar, então 37, 38, 39 ...

O argumento é que quando o ffmpeg falha após uma leitura 'bem-sucedida' (devido a outro problema), a seguinte 'leitura' funciona como esperado.

CONCLUSÃO: uma chamada ffmpeg bem-sucedida resulta em uma falha de leitura na próxima iteração por meio do loop.

Por que isso acontece e como posso pará-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 procurar!

    
por Dilgreen 11.06.2016 / 15:51

2 respostas

3

Use a opção -nostdin em ffmpeg . De documentação do FFmpeg :

Enable interaction on standard input. On by default unless standard input is used as an input. To explicitly disable interaction you need to specify -nostdin.

Disabling interaction on standard input is useful, for example, if ffmpeg is in the background process group. Roughly the same result can be achieved with ffmpeg ... < /dev/null but it requires a shell.

    
por 11.06.2016 / 19:49
0

Você provavelmente está certo de que o ffmpeg provavelmente está lendo a sua entrada, quem sabe por quê, então simplesmente redirecione esse comando para ler /dev/null , isto é, adicione à linha ffmpeg </dev/null .

    
por 11.06.2016 / 17:22