FFmpeg passthrough do fluxo de transporte MPEG causa erros e falhas no fluxo

0

Unbescholtener Bürger de volta com outra questão FFmpeg. Meu objetivo é ter uma instância de FFmpeg em execução que receba um fluxo de transporte mpeg via RTP, execute operações arbitrárias no fluxo recebido como transcodificação ou filtragem e, em seguida, transmita o fluxo de transporte alterado via RTP.

No entanto, não consigo trabalhar na configuração mais básica: tenho um arquivo .ts que contém um único programa que consiste em um vídeo e um fluxo de áudio. Eu uso uma instância do FFmpeg para transmitir este arquivo para localhost:

ffmpeg -re -i 1.ts -c copy -f rtp_mpegts rtp://127.0.0.1:5003

Com o ffplay, eu confirmo que isso funciona corretamente:

ffplay -i rtp://127.0.0.1:5003

O resultado parece bom, parece bom, não causa mensagens de erro no console.

Agora eu tento colocar em outra instância do FFmpeg no meio e as coisas vão para baixo. Eu só quero que o FFmpeg copie o fluxo da porta 5003 para a porta 5005 sem qualquer processamento adicional ou transcodificação:

ffmpeg -re -probesize 50M -analyzeduration 50M -i rtp://127.0.0.1:5003?fifo_size=10000 -c copy -f rtp_mpegts rtp://127.0.0.1:5005

Recebo muitas mensagens de erro recorrentes nesse console, e quando monito o fluxo na porta 5005 com ffplay, aparecem muitos artefatos, falhas e desistências. A saída do console se parece com isso na maior parte:

...
Input #0, rtp, from 'rtp://127.0.0.1:5003?fifo_size=10000':
  Duration: N/A, start: 1.400022, bitrate: N/A
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p(progressive), 352x240 [SAR 1:1 DAR 22:15], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1: Audio: ac3 ([129][0][0][0] / 0x0081), 44100 Hz, stereo, fltp, 192 kb/s
Output #0, rtp_mpegts, to 'rtp://127.0.0.1:5005':
  Metadata:
    encoder         : Lavf58.2.102
    Stream #0:0: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p(progressive), 352x240 [SAR 1:1 DAR 22:15], q=2-31, 29.97 fps, 29.97 tbr, 90k tbn, 29.97 tbc
    Stream #0:1: Audio: ac3 ([129][0][0][0] / 0x0081), 44100 Hz, stereo, fltp, 192 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=    0 fps=0.0 q=-1.0 size=       0kB time=00:00:00.48 bitrate=   0.0kbits/s speed=0.957x
frame=    0 fps=0.0 q=-1.0 size=       0kB time=00:00:01.01 bitrate=   0.0kbits/s speed=0.991x
frame=    0 fps=0.0 q=-1.0 size=       0kB time=00:00:01.53 bitrate=   0.0kbits/s speed=1.01x 
frame=    1 fps=0.5 q=-1.0 size=      57kB time=00:00:02.05 bitrate= 227.6kbits/s speed=1.01x 
frame=   17 fps=6.7 q=-1.0 size=      83kB time=00:00:02.54 bitrate= 267.6kbits/s speed=   1x 
frame=   32 fps= 11 q=-1.0 size=     121kB time=00:00:03.04 bitrate= 324.9kbits/s speed=   1x 
[rtp @ 0x3db64c0] max delay reached. need to consume packet
[rtp @ 0x3db64c0] RTP: missed 50 packets
[rtp @ 0x3db64c0] PES packet size mismatch
frame=   37 fps= 10 q=-1.0 size=     132kB time=00:00:04.07 bitrate= 266.0kbits/s speed=1.15x frame=   37 fps=9.1 q=-1.0 size=     132kB time=00:00:04.07 bitrate= 266.0kbits/s speed=1.01x 
[rtp @ 0x3db64c0] max delay reached. need to consume packet
[rtp @ 0x3db64c0] RTP: missed 1 packets
[rtp @ 0x3db64c0] PES packet size mismatch
[rtp @ 0x3db64c0] max delay reached. need to consume packet
[rtp @ 0x3db64c0] RTP: missed 1 packets
frame=   47 fps= 10 q=-1.0 size=     150kB time=00:00:04.57 bitrate= 269.3kbits/s speed=1.01x
...

Então ... alguma ideia do que deu errado e como consertar? Uma olhada no monitor de recursos não indica nenhuma alta carga de CPU, memória ou rede.

    
por UnbescholtenerBuerger 05.01.2018 / 14:24

1 resposta

0

Então, aparentemente, meu problema foi o -re flag no comando que inicia a instância do FFmpeg de passagem.

Se eu tivesse analisado a documentação oficial de antemão, não teria que fazer essa pergunta:

-re (input)

Read input at native frame rate. Mainly used to simulate a grab device, or live input stream (e.g. when reading from a file). Should not be used with actual grab devices or live input streams (where it can cause packet loss).

link

Qual é exatamente o que aconteceu comigo.

    
por 05.01.2018 / 15:33