[Bug 751026] rtpjitterbuffer: calculate elapsed time based on only clock base time

[GStreamer (GNOME Bugzilla)]

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

--- Comment #10 from Hyunjun <zzoon.ko at samsung.com> ---
In gst-rtsp-server, during making play response, sometimes it gets invalid
seqnum from last-sample in multiudpsink.(in gst_rtsp_stream_get_rtpinfo)

Case :  
1. Server's streaming shared media to a client.
2. Another client requests same media.
3. Server and the client start to negotiate.
4. Finally, server sends PLAY response to client. seqnum of RTP-Info in this
play response is exactly same as previous PLAY response's seqnum.

This is an example, which you can reproduce very easily.

---------- PLAY response to the first client ------------
RTSP response message 0xb705e030
 status line:
   code:   '200'
   reason: 'OK'
   version: '1.0'
 headers:
   key: 'CSeq', value: '7'
   key: 'RTP-Info', value:
'url=rtsp://127.0.0.1:8554/test/stream=0;seq=22808;rtptime=1168841023,
url=rtsp://127.0.0.1:8554/test/stream=1;seq=15530;rtptime=1679833381'
   key: 'Range', value: 'npt=0-62.95'
   key: 'Server', value: 'GStreamer RTSP server'
   key: 'Session', value: 'zZPFVRWjP85yuYzh'
 body: length 0

---------- PLAY response to the second client ------------
RTSP response message 0xb705e030
 status line:
   code:   '200'
   reason: 'OK'
   version: '1.0'
 headers:
   key: 'CSeq', value: '5'
   key: 'RTP-Info', value:
'url=rtsp://127.0.0.1:8554/test/stream=0;seq=22808;rtptime=1168841023,
url=rtsp://127.0.0.1:8554/test/stream=1;seq=16338;rtptime=1679833381'
   key: 'Range', value: 'npt=28.747845721-62.95'
   key: 'Server', value: 'GStreamer RTSP server'
   key: 'Session', value: 'pd9ib.qQhHopBJLl'
 body: length 0


You can see same seqnum(22808) of the first stream, while another stream's
seqnum(15530, 16338) is different.

It's because basesink doesn't call gst_base_sink_set_last_buffer every render
in case of BUFFER_LIST.
Actually, in this example, rtph264pay sends BUFFER_LIST.
To be confirmed, if I set large mtu size to rtph264pay to force to send a
BUFFER in test-mp4, it's working fine.

I'm wondering if this issue should be fixed or not and what part should I fix
it?

Instead of getting last-sample from sink, get information from payloader?
(As description says, it's more accurate to get information from sink)

Or somewhere else could be fixed?

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