GNOME Bugzilla – Bug 745704
Losing the first packet
Last modified: 2015-03-24 22:33:25 UTC
+++ This bug was initially created as a clone of Bug #745599 +++ See testcase in the original bug ↑ There are two problems here: 1) gst-rtsp-server seeks to position 0 after the PLAY command, which then flushes away the first packet (and whole first encoded frame). It should at least check if a seek is necessary at all, most of the time it isn't. 2) GstVideoEncoder should make sure the next frame after a flush is a keyframe.
(In reply to Sebastian Dröge (slomo) from comment #0) > 2) GstVideoEncoder should make sure the next frame after a flush is a > keyframe. Seem like parser role to me, and I thought we had fixed the parsers already ?
How is that a parser thing? Only the encoder can create keyframes from nothing :)
(In reply to Sebastian Dröge (slomo) from comment #2) > How is that a parser thing? Only the encoder can create keyframes from > nothing :) Nervermind :-/ (hides)
With h264 it's losing even more than one packet, but there the first packet is a keyframe.
This only leaves vp8enc or GstVideoEncoder now. commit 852cc09f542af5cadd79ffd7fe79d6475cf57e14 Author: Sebastian Dröge <sebastian@centricular.com> Date: Mon Mar 9 16:00:07 2015 +0100 rtsp-stream: Get the seqnum-base and other information from the last buffer in the sink This gives more accurate values than asking the payloader. There might be queueing happening between the payloader and the sink. https://bugzilla.gnome.org/show_bug.cgi?id=745704 commit b58af93d83221c5cc26c69fd960db8e578f84e0f Author: Sebastian Dröge <sebastian@centricular.com> Date: Mon Mar 9 13:00:25 2015 +0100 rtsp-media: Don't seek for PLAY if the position will not change https://bugzilla.gnome.org/show_bug.cgi?id=745704
commit 8f13a31bae97722c96dda40dd628bcc801dba7e5 Author: Sebastian Dröge <sebastian@centricular.com> Date: Mon Mar 9 11:12:46 2015 +0100 rtpbuffer: Link to an explanation why the seqnum comparison function does the right thing even for wraparounds
The following patch cause a regression. The stream now plays for few seconds and stop. The remote end receives EOS. To reproduce, use any mp4 and test-mp4 example. commit b58af93d83221c5cc26c69fd960db8e578f84e0f Author: Sebastian Dröge <sebastian@centricular.com> Date: Mon Mar 9 13:00:25 2015 +0100 rtsp-media: Don't seek for PLAY if the position will not change
There might be a client side regression mixed to the lot.
This works fine now.