I'm using the following pipeline to display a RTP MPEG-TS Stream
gst-launch udpsrc port=5000 caps="application/x-rtp, media=video, clock-rate=90000, encoding-name=MP2T-ES, payload=33" ! .recv_rtp_sink_0 gstrtpbin latency=800 ! rtpmp2tdepay ! aiurdemux ! vpudec ! mfw_v4lsink
It works well, however for unknown reasons it takes a long time (10 seconds) to start. See below log below for problem location
Core: BLN_MAD-MMLAYER_MPG2PARSER_04.04.14 build on Jun 25 2013 14:37:53
mime: video/mpeg, mpegversion=(int)[1,2]; video/mpegts, systemstream=true; video/x-cdxa
Seekable : No
<<----- 10 second delay here
Mpeg2CreateParser:parser created successfully
Seekable : No
Live : Yes
Duration : 0:00:00.000000000
ReadMode : File
programs : 1
Track : 2
This delay goes away if I use tsdemux instead of aiurdemux, however tsdemux leaks about 1mb worth of memory per second so that is not a great alternative.
Any ideas on what could be going on ?
A bit more research reveals that the function call in aiurdemux.c that is taking 10 seconds is
CORE_API (inf, createParser, goto fail, core_ret,
(bool) (demux->clip_info.live), file_cbks, mem_cbks, buf_cbks,
(void *) demux, &handle);
So creating the parser appears to be the cause of the delay. Problem is that (as far as I know) the parser is only distributed as a pre-compiled binary library, meaning there is no way for us to troubleshoot this any further without assistance (?). The 10 second delay is a show-stopper for us, so we would really appreciate any help even if it means paying for it.
Thanks in advance,