Wow, ten seconds is a long time. What's the setup here? Do you just take a BBC ONE DVB-T stream and re-send it via UDP?

Does it change anything if you use flags=0x7 (i.e. no deinterlacer) ?

Does it change anything if you use:

  gst-launch-0.10 -v uridecodebin uri=udp://239.192.2.203:5000 ?

does it change anything if you use:

  gst-launch-0.10 -v udp://239.192.2.203:5000 ! tsdemux ! mpegvideoparse ! mpeg2dec ! fakesink sync=true

  gst-launch-0.10 -v udp://239.192.2.203:5000 ! tsdemux ! mpegvideoparse ! mpeg2dec ! fakesink sync=false

  gst-launch-0.10 -v udp://239.192.2.203:5000 ! tsdemux ! mpeg2dec ! fakesink sync=true

  gst-launch-0.10 -v udp://239.192.2.203:5000 ! tsdemux ! mpeg2dec ! fakesink sync=false

  gst-launch-0.10 -v udp://239.192.2.203:5000 ! tsdemux ! fakesink sync=true

  gst-launch-0.10 -v udp://239.192.2.203:5000 ! tsdemux ! fakesink sync=false

?

(Also, testing with 1.0 / git master would be more interesting to us if that's an option)

Ping?

Sorry I missed your reply after returning from holiday.

In the meantime I built slightly newer versions of the software:

gstreamer 955693fc36ac38dc604e1e616e1c441cc3c25e1c
-base 12ef907f8a3762685da0b96391edc30a78d31805
-good c1f1b62ca26106fba30fca65b0945c31da0ffe22
-bad e3b09c25b16c42ca7a83472c61054f34a31f572c
-ugly afeffcdb44135c04c5767bba8b10fab82ec9a9df
-ffmpeg 1db8779252afa264996e59c18430f70cc5582b28

(In reply to comment #1)
> Wow, ten seconds is a long time. What's the setup here? Do you just take a BBC
> ONE DVB-T stream and re-send it via UDP?

Yes, essentially a custom application reads the stream from V4L and sends it to the network as multicast. It is unlikely the problem is at this end since it is static - I mean source remains static while different versions of GStreamer demonstrate different behaviour.

> Does it change anything if you use flags=0x7 (i.e. no deinterlacer) ?

No. I also tried 0x3 (no subtitles) but no improvement.

> Does it change anything if you use:
> 
>   gst-launch-0.10 -v uridecodebin uri=udp://239.192.2.203:5000 ?

I added "! queue ! xvimagesink" here and the delay is still here.

> does it change anything if you use:
> 
>   gst-launch-0.10 -v udp://239.192.2.203:5000 ! tsdemux ! mpegvideoparse !
> mpeg2dec ! fakesink sync=true
> 
>   gst-launch-0.10 -v udp://239.192.2.203:5000 ! tsdemux ! mpegvideoparse !
> mpeg2dec ! fakesink sync=false

This setup only knows of a legacympegvideoparse plugin, is that OK?

Anyway, I tried gst-launch-0.10 -v udp://239.193.88.0:20001 ! queue ! tsdemux ! legacympegvideoparse ! mpeg2dec ! queue ! xvimagesink and that starts in ~2 seconds.

I assumed this result gets away with the need to test your further pipelines?

Can I test something next?

> (Also, testing with 1.0 / git master would be more interesting to us if that's
> an option)

Unfortunately that is a much bigger ask for which I just don't have the time right now. Eventually our platform will get there, but not sooner than it gets released in a Fedora release.

Ok, thanks for testing. It's a bit odd that you only have 'legacympegvideoparse' but then not 'mpegvideoparse' from the videoparsersbad plugin - I assume you just don't build it?

Given the last pipeline starts in ~2 seconds, I would guess that there's something going on/wrong with the TS demuxer and the multiqueue in uridecodebin/decodebin2, possibly related to the lack of no-more-pads emission and all that. I wonder if it could be because of some stream that doesn't carry data very often - multiqueue will then expand until it's got data for all streams or until it's full, or something like that (bug #597195 might be related).

Truth is, however, that it's unlikely anyone is going to look at this much more in a 0.10 context I'm afraid, so I don't really know what to do about this.

FWIW, Fedora 18 is going to ship with 1.0.x. You still have chances to get bug-fixes into that now. And for development you need a custom setup with fixes anyway, no (rather than rely on the distro versions)?

665814(In reply to comment #4)
> Ok, thanks for testing. It's a bit odd that you only have
> 'legacympegvideoparse' but then not 'mpegvideoparse' from the videoparsersbad
> plugin - I assume you just don't build it?

Not explicitly via configure, no, only if it can decide to disable itself for some reason. I haven't looked into this to tell you what actually happens.

> Given the last pipeline starts in ~2 seconds, I would guess that there's
> something going on/wrong with the TS demuxer and the multiqueue in
> uridecodebin/decodebin2, possibly related to the lack of no-more-pads emission
> and all that. I wonder if it could be because of some stream that doesn't carry
> data very often - multiqueue will then expand until it's got data for all
> streams or until it's full, or something like that (bug #597195 might be
> related).

Ah.. that rings a bell.. possibly consequences of bug #665814? There were multiple fixes done to the old demuxer (and related components) for us by Vincent. Some got merged, some did not, and then some like this one got reverted. 
 
> Truth is, however, that it's unlikely anyone is going to look at this much more
> in a 0.10 context I'm afraid, so I don't really know what to do about this.
> 
> FWIW, Fedora 18 is going to ship with 1.0.x. You still have chances to get
> bug-fixes into that now. And for development you need a custom setup with fixes
> anyway, no (rather than rely on the distro versions)?

If 0.10 is abandoned I don't see you can do anything other than close this one as well.

Closing then.

We'll re-open when people can actually reproduce the issue and provide input/logs.