WC 11 Beta 1 - Webstream Plugin

Hi team.

Firstly, congratulations on moving the web stream code out of the main wirecast module into a seperate plugin. This type of forward thinking is what will take wirecast to the next level... by making the core code rock solid, and moving items like this to seperate processes that are only activated when necessary. Congratulations on that thinking.

This architecture should make it easier to take this one step further. The current plugin allows PULL requests from a listening server. What I am looking for is something that can receive PUSH requests from equipment that supports this capability. I know this is in the wishlist... but I just wanted to provide the feedback on the great progress, and hoping that this is the future intent now that you have the foundation laid.

GK

12replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Thanks for the kind words Greg.

     

    What exactly what you mean by "PUSH requests". Do you mean that you want Wirecast to open a port and listen for RTMP streams sent from an IP camera or  another app?

    Reply Like
  • PaulM - Correct. I'd like the web stream plugin to be able to listen to something else pushing RTMP. Just imagine one wirecast user was sending RTMP to another wirecast user. That is a good simple test case that will do what I need.

    You could do this two ways. If you wanted a simple solution with minimal effort, I have already done a sample proof of concept using nginx on my streaming workstation. You could use that approach and bundle a copy of nginx with wirecast to do the same thing. Or, you could create your own RTMP proxy within the streaming module.

    GK

    Reply Like
  • Thanks for the further explanation but I'd like to narrow it down even further. A common pitfall is to request a solution without fully explaining the specific use cases.  What specific problem(s) are you trying to solve?

     

    Are you specifically looking to send the output one instance of Wirecast to another instance of Wirecast?  If so, why? Are they always running on different machines? Are they always running on the same LAN?

    Are you looking to pipe another piece of software that outputs RTMP into Wirecast? If so, what product is it?

    Are you looking to support a specific device that outputs RTMP?  If so, what device is it?

    Reply Like
  • PaulM - I am looking at multiple ideas - but let me give you an example. An Osmo camera is a good use case... It can send direct to youtube. But, it also allows a custom RTMP url. If I can point that to wirecast and have it ingest that stream, that would be good.

    Reply Like
  • Greg Kuhnert

     

    Why not point the camera to a streaming media server and point Wirecast to the server?  That should be trivial.

    Reply Like
  • PaulM - Latency, packet loss, and network bandwidth. In the third world in Australia - our internet is not as great as other parts of the world. To get an Oslo into wirecast for example over Wifi (if it supported this) would have no network issues. But, if I have to send it to some remote server on the other side of the planet - and then pull that into wirecast, the latency performance and quality would be pretty ordinary.

    Hope that makes sense.

    GK

    Reply Like
  • Greg Kuhnert 

    Why not set up a streaming media server on the LAN... You can even run it on the same machine as Wirecast.

    Reply Like
  • PaulM - Yes. Possible. I've setup nginx to do that... but thats complications that most users dont want. They just want their camera to come into wirecast. I can point an OSMO to a RTMP url - and it will push the stream there... but when it comes to wirecast - it will not receive. Your average end user is not wanting to get extra components just to ingest a camera. Thats why this would be good to add in.

    Reply Like
  • Greg Kuhnert 

    The advantage of running a media server is that it stays running all the time which is what you want as opposed to a source plugin which will exit when Wirecast exits.  Are these cameras all robust enough to deal with servers that come and go?  Will they keep polling for the server to come back up?  If not, you have to leave the server running.

    Reply Like
  • PaulM 

    Yes, they are robust enough to deal with servers that come and go. I've tested it and it works just fine... and wirecast handled it well too... and this request is pending review by product marketing in WIRE-14424 - Have to see what they decide. Interesting debate either way.

    When I get some time, I'll try to throw together a video documenting how well it works the way I have set it up - to see if other people might want to get that same functionality available in their rig.

    Regards,
    Greg

    Reply Like
  • Some of the devices I've tested have a difficult enough time connecting to the media server just once let alone polling and reconnecting when the server goes down and comes back up. 

    Reply Like
  • PaulM - I've tested this today and produced a short video on my setup and testing. Some observations are listed below:

     

    Restart of the RTMP source: This worked fine, and continued to ingest into Wirecast via the proxy.

    1. Restart of Wirecast: This also worked fine - Wirecast connected to the proxy, and all worked fine
    2. Restart of the proxy: RTMP will negotiate different ports. This is never going to end well. However, in my experience - nginx is pretty rock solid, and restarts of nginx are unlikely.

    The configuration as described in the video is very simple. The only complexity is getting nginx or equivalent products installed. Once that is done, the rest is easy.

    If this were to be bundled as a pre-compiled component in Wirecast, this would overcome a hurdle for non technical users to push RTMP to their Wirecast workstation, without the need to compile and configure open source components. If it was pre-installed, the actual usage of the proxy is VERY easy.

    For reference, the configuration fragment that is required for nginx is listed below:

    rtmp {
            server {
                    listen 1935;
                    chunk_size 4096;
                    application live {
                            live on;
                            record off;
                    }
            }
    }
    

    Regards,
    Greg Kuhnert

    Reply Like
reply to topic
Like Follow
  • 1 mth agoLast active
  • 12Replies
  • 180Views
  • 2 Following