Estoy usando gstreamer para transmitir a través de un AppSink personalizado que imita a UdpSink. Lo estamos haciendo de esta manera para poder incorporar la escucha en otros puertos de algunos metadatos. Además, el stock de UdpSink está roto. De todos modos, logré transmitir video con éxito, pero los paquetes UDP parecen no estar empaquetados correctamente. Me pregunto si me he saltado algún paso.
Aquí está mi canal de envío:
filesrc (mpeg TS file) ! displayQueue ! streamTee ! tsdemux ! decoder ! videosink
streamTee ! sendQueue ! udpSink (our custom one)
el extremo receptor:
UdpSrc (custom) ! queue ! mpegtsdemux ! queue ! (mpegdecode || h264decode) ! ... ! videosink
La transmisión funciona. Pero parece muy frágil. A veces simplemente se detiene. Hay muchos artefactos.
Entonces, probé VLC. Lo configuré para transmitir a través de unidifusión UDP. Funciona muy bien. Noté que VLC envía el video de manera diferente a mi canal. Usé Wireshark para analizar los paquetes:
Protocolos utilizados: VLC: IP:UDP:MP2T(y PETpaquetes PMTy todo otro tipo de cosas relacionadas con TS)
Mío:IP:UDP:Data
Parece que la canalización que estoy usando simplemente envía video sin formato a través de UDP sin ninguna corrección de errores. ¿Qué me estoy perdiendo? Los vídeos utilizados son .mpgarchivos codificados en h264 o mpeg.
Estoy usando gstreamer-java para programar los elementos UdpSink y UdpSrc personalizados, pero no puedo usar gstreamer en la consola para realizar pruebas ya que el stockEl complemento UdpSink está roto. Probé una canalización simple en una máquina virtual Linux y obtuve un grupo de paquetes similar al de VLC:
gst-launch-0.10 -v videotestsrc ! mpeg2enc ! mpegtsmux ! udpsink host=192.168.2.100 port=1234
Respuesta1
Esto es sólo una idea, no estoy muy familiarizado con gstreamer, así que no sé cómo funciona filesrc, pero supongo que no entiende MPEG-TS. MPEG-TS requiere que los paquetes lleguen en ciertos límites (normalmente 188 bytes). Intentaría poner tu camiseta después de demux y luego agregaría un mpegtsmux antes de tu udpSink.
Me doy cuenta de que esto hará más trabajo del que realmente es necesario (demux solo para volver a mezclar), pero asegurará que los paquetes estén alineados correctamente. Si funciona y necesita eliminar la sobrecarga, es posible que deba considerar implementar una fuente de archivos más inteligente.
Respuesta2
Estás cerca. El complemento filesrc no sabe nada sobre el contenido del archivo que está leyendo. GStreamer necesita saber que los datos son un flujo de transporte para poder transmitirlos correctamente. Si bien la demuxing y la muxing de la transmisión hacen ese trabajo, existe una manera mejor:
Source: gst-launch -v filesrc location=myvideo.ts ! tsparse set-timestamps=true ! udpsink host=192.168.2.100 port=1234
Dest: gst-launch udpsrc caps="video/mpegts, systemstream=(boolean)true, packetsize=(int)188" port=1234 ! tsdemux ! (video decoder) ! autovideosink
El complemento tsparse lee la transmisión y analiza información sobre la transmisión. También identifica su salida como un flujo de transporte. Esto por sí solo puede ser suficiente para sus necesidades de transmisión, ya que permite a udpsink saber que los datos están en paquetes de 188 bytes. En el lado receptor, se necesita tsdemux para analizar la transmisión de video real. El elemento "set-timestamps" le dice a tsparse que establezca marcas de tiempo en los paquetes salientes para que udpsink envíe cada cuadro a tiempo en lugar de tan rápido como pueda.
También puede utilizar rtpmp2tpay y rptmp2depay, que empaquetan los datos para que udpsink los envíe. También establece el nombre de codificación en MP2T. Puedes intentarlo de ambas maneras.
Source: gst-launch -v filesrc location=myvideo.ts ! tsparse set-timestamps=true ! rtpmp2tpay ! udpsink host=192.168.2.100 port=1234
Dest: gst-launch udpsrc caps="application/x-rtp, systemstream=(boolean)true, packetsize=(int)188" port=1234 ! rtpmp2tdepay ! tsdemux ! (video decoder) ! autovideosink