Evaluating Fluendo timeshifter

Edward Hervey bilboed at gmail.com
Tue Nov 13 03:37:14 PST 2012 

Hi,

  This should be fixed in master now.

On Mon, 2012-11-12 at 16:56 +0000, Krzysztof Konopko wrote:
> Thanks Josep.
> 
> I can confirm that both tsmuxer and tsdemuxer were not "helping" the
> timeshifter. So far I removed tsmuxer from my pipeline. I get a TS
> stream from the genuine DVB source (dvbsrc) which is supposed to be a
> properly formed, "pristine" TS stream source. The timeshifter behaves
> much better, i. e. the rendered video is smooth now.
> 
> When I start sending seek events though it looks like the tsdemuxer
> behaves incorrectly when it receives a resulting flush event. This time
> poor timeshifter is hampered by the other side of the pipe :)
> 
> I found that there's some work in this area tracked with [1]. Can the
> tsdemuxer flush misbehaviour result in memory corruption/crashes?
> 
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=688091
> 
> Cheers,
> Kris
> 
> On 08/11/12 05:51, Josep Torra wrote:
> > Dear Kris,
> > 
> > The timestamps I'm referring to are does encoded as PTS/DTS in the
> > mpegts stream.
> > 
> > When I did my first tests with 1.0 port I've noticed that tsddemux
> > wasn't pushing buffers with timestamped data.
> > 
> > Maybe there's something else that needs to be fixed in the timeshift
> > element for 1.0 but I couldn't run real tests due the tsdemux issue.
> > 
> > I would suggest you try timeshift in 0.10 paired with flutsdemux until
> > the issues 1.0 were fixed. There's also the pvr.py [1] example app
> > which only works in 0.10 for now which will show you a complete ussage
> > of the timeshift element.
> > 
> > Just in case you don't have it, here [2] is my talk on timeshifting.
> > 
> > Please ping me at #gstreamer, my nickname is ad-n770.
> > 
> > [1] https://core.fluendo.com/gstreamer/trac/browser/trunk/gst-fluendo-timeshift/examples/pvr.py
> > [2] http://gstconf.ubicast.tv/videos/time-shifting-with-gstreamer/
> > 
> > Best regards,
> > 
> > Josep
> > 
> > On 7 November 2012 19:20, Krzysztof Konopko
> > <krzysztof.konopko at youview.com> wrote:
> >> 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
> >>>
> >>
> > 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

More information about the gstreamer-devel mailing list