GNOME Bugzilla – Bug 612264
Notification needed when the first buffer is pushed by the basertppayloader
Last modified: 2010-09-06 11:36:49 UTC
Created attachment 155624 [details] [review] First solution suggestion When sending the RTSP play response a rtptime (holding the rtp timestamp of a buffer) is included. In the case of a live source there is no preroll and therefore no buffer has been pushed when the pipeline has entered PAUSE state. In the case that the source does not timestamp from zero but rather directly from the clock, it is impossible to predict what the rtp timestamp will be until the first buffer has been prepared in the payloader. The clockbase works if the source timestamps from zero, but that is not always the case. To wait until the pipeline has been set to playing is not a good idea either since you cannot be certain that you read the timestamp and seqnum after the first packet. If the GOV length in h264 is really long a missed I-frame hurts, and thus it is important that we get the rtptimestamp for the first buffer holding the I-frame. Blocking the pads will not work either since these will block on the NewSegment event and no buffer will ever be sent. The solutions suggestion is to set a flag every time the element enters PLAYING state and when a buffer is prepared send notify on the timestamp and seqnum properties, as well as clearing the flag of course.
Pushed a slightly different and more threadsafe version. It's quite hard to do this completelyy correctly in all cases, it needs to be added to the sink. Can you check that this one works as well? commit 9fd1c4826752149f4bb31ebea9a90c3ba402f233 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Sep 6 13:14:00 2010 +0200 rtppayload: notify of first timestamp/seqnum Notify of the first timestamp/seqnum pushed out by the payloader. Fixes #612264
Oh, just figured that we could use SINK_MESSAGE too.