Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[QUESTION] is there a way to do dual rtmp input + file fallback ? #1

Open
AlexandreLicinio opened this issue Jan 12, 2020 · 2 comments

Comments

@AlexandreLicinio
Copy link

hi, great project. Even WSE or WMS aren't able to achieve what you do and there aren't free.
Is there a way to do dual rtmp ingest + file fallback ?

In case rtmp1 push fails, it goes to rtmp2 then in case fails or in case stream is off (so no rtmp encoders involved) file fallback.
tbh i'm just looking for a solution to have dual rtmp from two different rtmp encoder to rtmp output in case rtmp encoder fails.

thanks
cheers

@ThePooN
Copy link
Owner

ThePooN commented Jan 12, 2020

Thanks! even though i don't know what WSE/WMS are ^^'

A thing to take in mind first: this tool doesn't do transcoding, which makes this task more complex. all it does is transmux the FLV (RTMP) streams to MPEG-TS, so the streams can be concatenated at the byte-stream level, and so CPU-heavy decoding & encoding isn't required. This is why it is specified in the README that both streams must have the exact same settings.

This makes a reliable fallback process way more complex: even if these streams are concatenatable, when the first stream dies, we must start outputting from the second stream exactly at a keyframe (hence why I advice using wait_key on nginx-rtmp-module in the README). otherwise, decoding errors/artifacts will occur.
in that context, using a fallback file is way easier, because a properly encoded file necessarily starts at a keyframe.
it is still possible to use a secondary rtmp stream though, i can see 2 solutions:

  • when there is no byte incoming in the current rtmp stream, we can connect to the alternative rtmp stream, wait for the first keyframe, and start outputting it (unless the primary rtmp stream has came back while this happens). this is relatively easily achievable with wait_key on nginx-rtmp-module ;
  • maintain a connection to both rtmp streams, directly outputting the current one to the rtmp output, and having a buffer on the alternate stream, collecting bytes since every keyframe, ready to output whenever necessary.

The second solution seems way more reliable and suitable, however we can no longer use nginx-rtmp-module's wait_key option. Implementing some kind of decoding is needed in order to detect keyframes in the feed, and I cannot tell how complex that is without doing some kind of research.

@AlexandreLicinio
Copy link
Author

Ok thanks @ThePooN and sorry for late reply. I will do some experiments with your project to see if can achieve 2x rtmp inputs (failover) to 1x output.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants