Evaluating Fluendo timeshifter

Mon Nov 12 08:56:27 PST 2012

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
>>>
>>
> 