Evaluating Fluendo timeshifter

[Josep Torra]

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