rtmpsink recovery, almost there

[Adam Langley]

Hi,

I have written a custom element in Python (named 'recovery'), which
essentially chains from h264 to h264 to isolate the upstream from errors,
and is intended to be inserted before an "flvmux ! rtmpsink" set of
elements.
When the pipeline errors (because the network has failed), the element
pauses the pipeline, removes the flvmux and rtmpsink, and replaces them
with fresh ones, then resumes the pipeline.

Pipeline looks like this:
videotestsrc ! omxh264enc ! video/x-h264,profile=high \
! h264parse name=parse ! recover ! flvmux name=mux ! rtmpsink name=rtmp
location=rtmp://server/wowza sync=false async=false

What I am seeing, is that the 'recovery' works - wowza server gets a new
rtmp data stream as a result. However, the experience for someone who is
watching the stream is this:
 - stream is playing
 - network dies, playback stops in the player
 - gstreamer recovers and wowza reports incoming data again
 - HOWEVER: the player does not recover (the user has to click stop/start
to recover)

Note: if I KILL the gstreamer process, and start it again, then the clients
player DOES recover.

I can only think that the recovered data stream is somehow bad, which
upsets the player. Is there some kind of pre-roll header delivery that I
need to force to happen during pipeline recovery? How do I do that?

Thanks,

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161109/5a2c1c41/attachment-0001.html>