[Bug 719587] rtpgstpay: delay events until first buffer so they can be timestamped

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=719587

Jan Schmidt <thaytan at noraisin.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thaytan at noraisin.net

--- Comment #11 from Jan Schmidt <thaytan at noraisin.net> ---
Here is what I have:

Dec 04 01:46:54 <wtay>  719587 (delay events until buffer) should maybe let
some events through (like GAP)
Dec 04 01:47:33 <wtay>  because you want some events to go through quickly 
Dec 04 01:47:36 <sebras>        wtay: why? as I see it this would create havoc
with the timestamping..?
Dec 04 01:48:10 <wtay>  the GAP is explicitly to fill a void (no buffers)
Dec 04 01:48:30 <wtay>  to keep the other end busy and processing, delaying it
would not help
Dec 04 01:48:51 <wtay>  but I think you want to bundle the segment and caps
with the first buffer
Dec 04 01:49:31 <sebras>        wtay: wait... does the original rtpgstpay even
handle GAP..?
Dec 04 01:49:52 <wtay>  I don't know..
Dec 04 01:50:14 <sebras>        wtay: if I were do to what you propose, then
what rtptime would I use for the very first event which appears without any
timestamp before the first buffer..?
Dec 04 01:51:35 <sebras>        wtay: this is the problem I'm seeing. the only
events that I can se that rtpgstpay handles are FLUSH_STOP, TAG,
CUSTOM_DOWNSTREAM, CUSTOM_BOTH and STREAM_START, any other event is not
propagated through to the src pad of the payloader.
Dec 04 01:51:42 <wtay>  sebras, it would be the same as the rtptime of the next
buffer
Dec 04 01:52:09 <sebras>        wtay: so basically ts_base then.
Dec 04 01:52:16 <wtay>  ok, so only the custom events are problematic
Dec 04 01:52:32 <wtay>  and flush I guess too
Dec 04 01:52:37 <sebras>        wtay: well, STREAM_START was the one that threw
me actually.
Dec 04 01:52:57 <wtay>  you can easily bundle stream-start with the next buffer
Dec 04 01:53:31 <sebras>        wtay: because I ended up with an RTP packet in
a gstbuffer in the payloader and then I queried the payloader for the last
processed buffers running time (which was the RTP packet buffer) and got
GST_CLOCK_TIME_NONE back.
Dec 04 01:53:47 <wtay>  and even if you get a GAP event after the
segment-start, you could bundle the GAP and SEGMENT_START and give it the
rtptime of the start position in the segment event
Dec 04 01:55:39 <sebras>        wtay: ok, so then between SEGMENT_START and the
first buffer the running time shoudl be the start position of the segment
event..?
Dec 04 01:56:00 <sebras>        wtay: and before SEGMENT_START it would be
GST_CLOCK_TIME_NONE.
Dec 04 01:56:58 <wtay>  sebras, segment-start is delayed until you get the
first buffer or GAP event, if you have a buffer you place the RTPtime of the
buffer, if you have a GAP you place the RTPtime of the segment start
Dec 04 01:58:34 <wtay>  you always need stream-start, segment, (caps) (,buffer
| GAP)
Dec 04 02:03:35 <sebras>        wtay: but what about the running-time
(introduced i 719415)? I have only two sources of info there, segment event
start position and the timestamp of the buffer. if the basepay have neither the
event nor the buffer, then I guess GST_CLOCK_TIME_NONE is ok, if it has the
segment event, then I expect that the start position of that event is the
current running time, and whenever basepay receives the first buffer of course
the timestamp of this buffe
Dec 04 02:05:08 <wtay>  sebras, yes, so I think your patch does good, collect
events until you either see a buffer or a GAP event, then timestamp and push
them
Dec 04 02:06:11 <wtay>  sebras, while you see the segment you update your
'current-best-timestamp-guess', when you see the buffer you know the
running-time else with the GAP you take the best guess and push
Dec 04 02:06:14 <sebras>        wtay: well, rtpgstpay doesn't handle the
SEGMENT_START event and use the start position to set the running time.
Dec 04 02:07:07 <sebras>        wtay: I can add that of course, and I think you
are asking me to..? :)
Dec 04 02:07:11 <wtay>  sebras, it does not look right
Dec 04 02:07:54 <wtay>  sebras, ah ok, yes it just passes the timestamp to the
base class, which uses the segment to do the running-time and rtptime then
Dec 04 02:09:52 <wtay>  sebras, so you need to somehow update the timestamps on
those queued packets
Dec 04 02:10:36 <wtay>  your patch does that too
Dec 04 02:11:30 <wtay>  so the trigger to release the packets should either be
a valid buffer timestamps or a GAP event
Dec 04 02:12:29 <wtay>  or event the custom-downstream event
Dec 04 02:18:29 *       wtay has quit (Read error: Connection reset by peer)
Dec 04 02:22:20 <sebras>        wtay: actually it is currently only a valid
buffer, no GAP no CUSTOM_DOWNSTREAM

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.