[gstreamer-bugs] [Bug 635226] [PATCH] gdppay fails to sync if added to pipeline during playback

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=635226
  GStreamer | gst-plugins-base | 0.10.30

Alexey Chernov <4ernov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|NOTABUG                     |

--- Comment #5 from Alexey Chernov <4ernov at gmail.com> 2010-12-12 16:19:15 UTC ---
Well, the first thing I should say is it's bug anyway because that's the exact
situation which I try to solve using documented functions and it doesn't work.

As to dropping events and buffers - I tried not only to drop but also to block
the queue. This way no buffers and events are dropped. But nothing was changed.
In my description I pointed that in order to make gdpdepay with my patch
working correctly you need to switch on the do-timestamp property on filesrc.
In this case adapter timestamps stop to be -1 and are the timestamps when the
undepayed buffer was created.

Next, let's look at gst_dp_buffer_from_header(). It's part concerning buffer
timestamp is this:

GST_BUFFER_TIMESTAMP (buffer) = GST_DP_HEADER_TIMESTAMP (header);

And GST_DP_HEADER_TIMESTAMP marco is

#define GST_DP_HEADER_TIMESTAMP(x)      GST_READ_UINT64_BE (x + 10)

And what is written in (x + 10) address during paying? Let's see
dataprotocol.c:147 and it's:

GST_WRITE_UINT64_BE (h + 10, GST_BUFFER_TIMESTAMP (buffer));

It is the remote pipeline's timestamp. So no timestamp management is done on
gdpdepay's side and we have depayed buffers with some wild timestamps.

I can't find any way to keep track new-segment of the pipeline and then push it
to element, I tried to do it using seeking whole pipeline but I think it should
be done somewhere not in user's code but somewhere inside elements which are
connected during playback.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.