feat: add support to send TS via UDP

[RodrigoDornelles]

aqui está a feature, consegui testar em hardware real, acredito que talvez tenha muitos ajustes ainda a fazer, conforme a revisão irei trabalhar neles.

./isdbt-capture -c 30 -u 192.168.8.188:1234:4:50000000

• preciso implementar thread? (existe um nanosleep na minha implementação, a principio não teve impactos).
• a constante BUFFER_SIZE_UDP com número magico 192512 são 1024 pacotes TS, foi a maneira mais simples que pensei entre concilicar o buffer fs do linux de 4096 com buffer TS de 188 sem precisar de uma fila de buffer rotativo.
• no meu teste eu não consegui fazer funcionar com outra quantidade de TS's, talvez tenha relação que deve mudar o bitrate, conheço pouco.
• acho que essa parte de mandar a quantidade de TS fazendo um parser iria complicar, e precisaria implementar outro buffer rotativo.
• para não aumentar a quantidade de flags e também manter tudo num unico contexto, fiz pequeno parser:
  <ip>:<porta>:<numero de pacotes TS>:<bitrate in ms>
• sugestões de mensagens de erro e identação é só falar.

closes #2

[rafael2k]

Massa! Essa opção de bitrate tem alguma função?

[rafael2k]

Eu particularmente gosto de buffers circulares pra "amortecer" qualquer soluço do sistema. Eg.:
https://github.com/rafael2k/c-playground/blob/main/shm_ringbuffer/ring_buffer2.c

[rafael2k]

Lembrei do código.
Você não precisa de outro buffer nem outra constante. Pode trocar o BUFFER_SIZE para um múltiplo de 188 (o número de pacotes que foi colocar no datagrama UDP), 5 pacotes (5 * 188). E não precisao de sleep tb.

[rafael2k]

Na verdade vai precisar de duas constantes mesmo. uma na thread que le do device, output_thread(), mantem o BUFFER_SIZE com o valor que tah, e de fato cria outra constante que vai ser o tamanho pra ler do buffer circular (que poder o mesmo para todos os players, 5 * 188.

[RodrigoDornelles]

Massa! Essa opção de bitrate tem alguma função?

Sim, o bitrate administra a velocidade transmissão, quanto tempo vai levar a cada sleep.

Eu particularmente gosto de buffers circulares pra "amortecer" qualquer soluço do sistema. Eg.: https://github.com/rafael2k/c-playground/blob/main/shm_ringbuffer/ring_buffer2.c

sim sim, é uma solução que costumo usar também em muitos casos, pensei em buffer maior para fazer uma implementação menor, para não precisar envolver com o final do buffer rotativo ter meio pacote TS complemetado pelo inicio.

Lembrei do código. Você não precisa de outro buffer nem outra constante. Pode trocar o BUFFER_SIZE para um múltiplo de 188 (o número de pacotes que foi colocar no datagrama UDP), 5 pacotes (5 * 188). E não precisao de sleep tb.

Bom, eu acreditava que não precisaria, que utilizaria a própria velocidade de leitura como a velocidade de saida, e assim seria o mesmo bitrate que a transmissora, porém por algum motivo não funcionou, um dos meus equipamentos reconhece os pacotes TS chegando, mas ao todo só da imagem na tv por um leve instante.

Na verdade vai precisar de duas constantes mesmo. uma na thread que le do device, output_thread(), mantem o BUFFER_SIZE com o valor que tah, e de fato cria outra constante que vai ser o tamanho pra ler do buffer circular (que poder o mesmo para todos os players, 5 * 188.

sobre essa parte de quantidade de pacotes TS por envio, não entendo muito bem, já vi em outras implementações e outras conversas outros números como 7 * 188 e 8 * 188, no meu caso também o que funcionou melhor foi 4 * 188, acho que o melhor caso é deixar o usuário decidir.

---

@rafael2k fico no aguardo se preciso mudar para buffer circular ou não, eu optaria pelo buffer multiplo de 188 que vai acumulando, eu optaria na verdade só por mover da stack para .global, para esses buffers já serem pré-alocados na inicianilização do programa.

eu conheço buffer circular em memoria, que é um pouco chato de trabalhar quando está próximo da borda, se ring_buffer.c traz facilidades, posso reutiliza-lo então para ler pacotes e enviar os pacotes, mas a gravação do outputfile e player pode manter como está um buffer de 4096 é perfeito.

[RodrigoDornelles]

fazendo alguns testes, eu vi que tem que balencear a quantidade de pacotes e velocidade, mas mandar poucos muito rápido ou muitos muito lento causa uma instabilidade.

[rafael2k]

O buffer circular já está lá. Não precisa mexer no código do buffer nem usar outro buffer. A cadencia da leitura do device já dá a cadência do pipeline, visto que a leitura do buffer é bloqueante. Entendo ali que também o sleep seja somente para amortecer o jitter da transmissão dos datagramas UDP com 4 pacotes TS, confere? O ideal é não ter o sleep... mas se precisar, paciencia.

ps: como a cadência do TS é dada pelo device de captura, não vejo muito sentido em setar um valor de bitrate (talvez uma medida do bitrate recebido pelo device possa fazer sentido).