Evaluating Fluendo timeshifter

[Krzysztof Konopko]

Thanks Josep,

That's reasurring I'm not constructing utterly spurious pipes.

I don't understand though how [1] is related. What do you mean by saying
"tsdemux doesn't provide timing info when activated in push mode"?

I deliberately added do-timestamp=false to my udpsrc so it looks a bit
more like a filesrc when it comes to timestamps but obviously it's still
considered by the pipeline a live source.

The timeshifter sends GST_FORMAT_BYTES segments and from my logs we can
see that the decodebin (tsdemux) extracts reasonable timestamps from the
stream.

Is it a latency information that's not provided by the tsdemux element
so the latency is not calculated properly when going to the PLAYING
state? Can you elaborate a bit more on this?

Thanks,
Kris

[1] https://bugzilla.gnome.org/show_bug.cgi?id=687178

On 07/11/12 17:43, Josep Torra wrote:
> Hi Kris,
>
> At least you are affected to [1] and it's not possible to do real
> testing until it being fixed.
>
> When I've developed it I've did most of the testing with a Playstation
> PlayTV usb DVB-T tuner and few tries with UDP.
>
> To simulate some sort of constant bitrate producer I've used "... !
> identity sleep-time=x ! udpsink" and tuned the sleep time into an
> appropriate value looking at file size, duration in time and buffer
> sizes.
>
> I hope this will help you.
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=687178
>
> Best regards,
>
> Josep
>
> On 7 November 2012 18:28, Krzysztof Konopko
> <krzysztof.konopko at youview.com> wrote:
> > Let me just add that if I use a TS file as a source, then the
> > timeshifter sees a burst of 18800 buffers and everyone's happy,
> >
> > So it seems to me that this is something to do with my udpsrc being slow
> > and trickling rather than streaming. Is there any buffering that could
> > remedy this situation?
> >
> > Kris
> >
> > On 07/11/12 17:18, Krzysztof Konopko wrote:
> >> Hi,
> >>
> >> I'm trying to make some real-life experiments with the Fluendo
> >> timeshifter. I stream raw video from my laptop video camera, encode and
> >> mux it into MPEG-TS and then stream it as UDP packets from the "server"
> >> machine. On the receiver I use the following pipeline:
> >>
> >> gst-launch-1.0 -v --gst-debug-no-color --gst-debug=flu*:5 \
> >>     udpsrc do-timestamp=false port=10000 \
> >>
> >>
> caps='application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)MP2T-ES'
> >> \
> >>     ! queue ! rtpmp2tdepay \
> >>     ! tsparse \
> >>     ! queue \
> >>     ! identity name=probe-before-timeshifter silent=false \
> >>     ! flumpegshifter \
> >>     ! identity name=probe-after-timeshifter silent=false \
> >>     ! decodebin \
> >>     ! identity name=probe-after-decoder silent=false \
> >>     ! queue ! autovideosink sync=false
> >>
> >> The problem is that the rendered video is very jerky. The timeshifter
> >> collects TS packets until it fills the cache slot (32kB) and than hands
> >> over to the decoder:
> >>
> >> # tsparse
> >> (probe-before-timeshifter:sink) (11280 bytes, dts: none, pts:none,
> >> duration: none, ... )
> >> (probe-before-timeshifter:sink) (2068 bytes, dts: none, pts:none,
> >> duration: none, ... )
> >> (probe-before-timeshifter:sink) (3008 bytes, dts: none, pts:none,
> >> duration: none, ... )
> >> ...
> >>
> >> # timeshifter
> >> (probe-after-timeshifter:sink) (32768 bytes, dts: none, pts:none,
> >> duration: none, offset: 131072, offset_end:  163840, flags: 00000000 )
> >>
> >> # decoder
> >> (probe-after-decoder:sink) (115200 bytes, dts: 0:00:01.040000000,
> >> pts:0:00:01.040000000, duration: 0:00:00.040000000, ... )
> >> WARNING: from element ...:autovideosink0-actual-sink-xvimage: A lot of
> >> buffers are being dropped.
> >> Additional debug info: ...:autovideosink0-actual-sink-xvimage:
> There may
> >> be a timestamping problem, or this computer is too slow.
> >> (probe-after-decoder:sink) (115200 bytes, dts: 0:00:01.080000000,
> >> pts:0:00:01.080000000, duration: 0:00:00.040000000, ... )
> >> (probe-after-decoder:sink) (115200 bytes, dts: 0:00:01.120000000,
> >> pts:0:00:01.120000000, duration: 0:00:00.040000000, ... )
> >> (probe-after-decoder:sink) (115200 bytes, dts: 0:00:01.160000000,
> >> pts:0:00:01.160000000, duration: 0:00:00.040000000, ... )
> >> ...
> >>
> >> If I remove the timeshifter, I get delayed but smooth video output.
> >>
> >> gst-launch-1.0 -v --gst-debug-no-color --gst-debug=flu*:5 \
> >>     udpsrc do-timestamp=false port=10000 \
> >>
> >>
> caps='application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)MP2T-ES'
> >> \
> >>     ! queue ! rtpmp2tdepay \
> >>     ! tsparse \
> >>     ! queue \
> >>     ! identity name=probe-before-decoder silent=false \
> >>     ! decodebin \
> >>     ! identity name=probe-after-decoder silent=false \
> >>     ! queue ! autovideosink sync=false
> >>
> >> The tsparse end decoder elements work interchangeably.
> >>
> >> (probe-before-decoder:sink) (2632 bytes, dts: none, pts:none, duration:
> >> none, ... )
> >> (probe-after-decoder:sink) (115200 bytes, dts: 0:00:00.731522222,
> >> pts:0:00:00.731522222, duration: 0:00:00.040000000, ... )
> >> (probe-before-decoder:sink) (2256 bytes, dts: none, pts:none, duration:
> >> none, ... )
> >> (probe-after-decoder:sink) (115200 bytes, dts: 0:00:00.801255555,
> >> pts:0:00:00.801255555, duration: 0:00:00.040000000, ... )
> >> (probe-before-decoder:sink) (2632 bytes, dts: none, pts:none, duration:
> >> none, ... )
> >> (probe-after-decoder:sink) (115200 bytes, dts: 0:00:00.867966666,
> >> pts:0:00:00.867966666, duration: 0:00:00.040000000, ... )
> >> (probe-before-decoder:sink) (2068 bytes, dts: none, pts:none, duration:
> >> none, ... )
> >> (probe-after-decoder:sink) (115200 bytes, dts: 0:00:00.933966666,
> >> pts:0:00:00.933966666, duration: 0:00:00.040000000, ... )
> >> (probe-before-decoder:sink) (2444 bytes, dts: none, pts:none, duration:
> >> none, ... )
> >> (probe-after-decoder:sink) (115200 bytes, dts: 0:00:00.997777777,
> >> pts:0:00:00.997777777, duration: 0:00:00.040000000, ... )
> >>
> >> Maybe the "real-life" source is too slow/pessimistic? Is there anything
> >> else I'm getting wrong?
> >> Any ideas/suggestions?
> >>
> >> Thanks,
> >> Kris
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >> gstreamer-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >>
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>