rtmpsink recovery, almost there

[nimble99]

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Gst-Geek]

Hi Adam,

RTMP servers expect flv header before video information. I think stream is missing the header.
Enable logs of flvmux and check whether header is generated.

~ Vinod

[Tim Müller]

On Wed, 2016-11-09 at 12:23 +1300, Adam Langley wrote:

Hi Adam,

For what it's worth, it should be enough to simply set the rtmpsink
element to NULL state after a network error and then to set it back to
PLAYING again (or you can also replace it if you like). Whilst keeping
the flvmux running, at least from GStreamer 1.8 onwards (where rtmpsink
will pick up the stream headers from the caps as well). This might
provide for more continuity, since it's effectively still the same
stream. Don't know if it will fix your problem of course.

Since 1.6 there's also an ignoreerror element which you can put before
rtmpsink and which can make sure that streaming won't stop when you
shut down/replace the rtmpsink, just suppress FLUSHING and NOT_LINKED
flow errors.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Bruno Zoppis]

Hi Adam,

I am facing same issue. I am very interested in how you did implement your recovery element in
order to implement same kind of solution in C++.

Best Regards,
Bruno