I need to find a solution to a particular issue.
We make live streaming with mobile connection (ISP with dynamic IP behind a CG-Nat).
Oftenly happens that connection drops , and source IP/PORT changes. Our rtmp server (using ffmpeg with hls options), in the same way, loose e restart rtmp session and the index restarts from zero.
Bitmovin, on the other hand, try to process the next-one-chunk (p.e. index1234.ts) but the new manifest has index0.ts, index1.ts, index2.ts, index3.ts.
Temporary workaound is to make a custom API on our CDN to get the real live status, and when session restart, we unload and reload Player .
Apart from the cost of generated impressions, there’s a terrible user experience. Is there a method, a tweak, to reload the same m3u8 manifest?
Hello, this is Paul Macklin and I’m the product manager for Bitmovin’s Live Encoding product.
I realise this question is directed to our player product but it seems that some of the issues are on the stability of the RTMP input and how your current encoder manages this.
Some tips would be:
If the contribution transport is unstable and you see packet loss, try switching to a transport protocol with some built in Forward Error Correction, such as Zixi or SRT. SRT is supported in FFMPEG.
Secondly, with our Live Encoder, we always write consisten segments and repeat the last good frame on input loss. Using a similar configuration in your solution or using our Live Encoder here would also provide a consistent user experience and should remove the errors with the player.
.