Evaluating Fluendo timeshifter

[Krzysztof Konopko]

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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Krzysztof Konopko]

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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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
<[hidden email]> 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
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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
> <[hidden email]> 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
> >> [hidden email]
> >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >>
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > [hidden email]
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Krzysztof Konopko]

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
> <[hidden email]> 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
>>> <[hidden email]> 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
>>>>> [hidden email]
>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> [hidden email]
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Edward Hervey]

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
> > <[hidden email]> 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
> >>> <[hidden email]> 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
> >>>>> [hidden email]
> >>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> gstreamer-devel mailing list
> >>>> [hidden email]
> >>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >>>
> >>
> >
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel