Self serve content

content/blog/1-lets-go-inlive/index.md

@@ -0,0 +1,30 @@
+---
+# Refer to the themes/inlive/archetypes/README.md
+date: 2022-03-01
+lastmod: 2022-03-01
+title : Let's go Inlive
+slug : lets-go-inlive
+summary: inLive is going to unlock the live streaming interactions beyond comments and likes. We want to help more startups and developers to build products around live streaming and help us discover new way to interact through live streaming.
+---
+
+# To unlock the live streaming interactions beyond comments and likes
+
+Before we started inLive, we saw that live streaming is starting to be more than just game stream, or live shopping. We saw that live stream is a new way to engage and interact with more people, in more scaleable way. But engagement and interaction should'nt stop at comments and likes, there should be more we can do in a live stream. Why not many startups build something around live streaming?
+
+## Problems in live streaming ecosystem
+This the main question that we're trying to answer, why not many startups or developers build something around live streaming and unlock more interaction beyond likes and comments? We know video industry is growing significantly during this pandemic, but mostly the innovation happens only in big companies like YouTube, Netflix, or Twitch. Not many startups really come with an innovation that able to create a new way to interact through a live stream.
+
+We can't take away our eyes about the live streaming potential in Indonesia. We talked with one of Indonesia tipping platform and we estimated that the total gross merchandise value (GMV) only in live streaming tipping ecosystem in 2021 is around IDR 13,5 billions/month. We believe more money is circulated outside the tipping platform, like in live streaming platform like Twitch. 
+
+Then we asked to several startups why they're not create a live streaming feature, most of them will answer build a live streaming feature is too complicated and too costly to run the server. We understand the complicated part because not many developers build something around live streaming, and so many components will be involved like networks, video encoding process, and delivering the video through CDN. Have you ever broadcasting your own live streaming from your laptop and those laptop fans sounds even harder than the background music you play when you're doing the live streaming? And it make you keep thinking that you need more expensive laptop to do your live streaming better? The same thing with live streaming server, it will need a high specification server to be able encode your live stream and deliver the video in low latency less than 10 seconds.
+
+## inLive is here as an infrastructure to help you develop your live streaming feature
+That's why we come with inLive, an infrastructure as a service to help you focus on the use case of your live streaming and forget the complicated part on the backend. We also want to make sure you can experiment freely on building your first live streaming app, so we provide you a free quota of our service. You don't need to worry about getting expensive bills when no one watch your live stream. To make sure you can develop freely your live streaming without thinking too much about the cost, we're developing our infrastructure to able automate the server so we can charge you only when you running your live streaming. 
+
+We still developing our pricing model because we want to make sure it won't confuse you and ask you to calculate your cost estimation through a pricing calculator. We want to make sure that the cost is predictable for you, no shocking bills if suddenly your live streaming is getting populars. But hey, why not just start developing your live streaming app or build a live streaming feature in your current app while waiting our pricing? 
+
+## A self-serving platform
+inLive was started because the developer's pain point. And just like other developers, we don't like when it's required to talk with a representative first just to try the platform. That's why we're focus on the developer experiences, we focus to help developers self-serving them self to develop a live streaming apps or features with our documentations and tutorials. We still working on this, we like to provide you a comprehensive guidelines on using our platform. No need to reach out to us to try our platform, but we're very happy if you like to discuss or ask anything to help you use our platform.
+
+## Free quota during beta
+For this beta, our quota will be based on total streaming durations across your live streams, and you will get 10 hours for free each month. Let us know if you need more. We want to make sure we can help you develop your live streaming use case, so please reach out to our team if you have any questions, requests, or feedback. 

content/docs/getting-started/index.md

@@ -52,4 +52,4 @@ When you send the video source input through WebRTC or RTMP protocol, the Inlive
 
 You can choose which format you want to use if you're using your own or an open-source video player. But if you use our embedded HTML player, the player will automatically use low latency Dash if your browser is supported but will fall back to HLS format if not.
 
-Check the play video section in our complete tutorial on using Inlive APIs to get the video and play it in your app.
+Check the [play video section in our complete tutorial](/docs/tutorial/app-with-webrtc/#6-get-the-video) on using Inlive APIs to get the video and play it in your app.

content/docs/tutorial/app-with-webrtc/index.md

@@ -112,60 +112,80 @@ async function startStream(){
 }
 ```
 
-### 3. Initiate the WebRTC connection by sending offer SDP and receiving an answer from inLive API
+### 4. Prepare the live stream
+For now, we need you to call this `prepare` API endpoint before starting to initiate the WebRTC connection. This is to start your live stream session, and this is where the billing will start counting your live streaming duration. In the future, we will automate the preparation process so the preparation will start automatically once we receive your video ingestion. Let's create a function that will be used to call the `prepare` API endpoint:
+
+```js
+async function prepareStream(slug){
+    const url = `${options.origin}/${options.apiVersion}/streams/${slug}`;
+    try{
+      resp = await apiRequest(options.apiKey, url, 'POST');
+      if (resp.code !== 200) {
+            throw new Error('Failed to prepare stream session');
+        }
+    } catch(err) {
+      console.error(err)
+    }
+}
+```
+
+### 5. Initiate the WebRTC connection by sending offer SDP and receiving an answer from inLive API
 Once the video stream input is available, we're ready to send the video stream to Inlive encoder and start publishing our live video stream. To send the video, these are the steps we need to follow:
 1. Create `RTCPeerConnection` object and add the media stream tracks to this RTCPeerConnection. This is an important step to make sure the Offer SDP that we will generate will have information about our media tracks, like video and audio codec information. The RTCPeerConnection also will need to have a media track before being able to start the ice gathering process.
 
-    We modify the start stream function and adding some lines to send the video through WebRTC connection.
+    We modify the start stream function and added some lines to send the video through WebRTC connection. We also need to call the `prepare` API endpoint first before start capturing the video camera. 
 
    ```js
     async function startStream(){
-        const videoEl = document.querySelector('video');
-        const constraints = {
-                video: {
-                frameRate: 30,
-                width: 1280,
-                height: 720,
-                },
-                audio: true
-            };
-
-        const localStream = await navigator.mediaDevices.getUserMedia(constraints);
-        videoEl.srcObject = localStream;
-
-        const servers = {
-            iceServers: [
-                { urls: 'stun:stun.l.google.com:19302' },
-                {
-                    urls: 'turn:34.101.121.241:3478',
-                    username: 'username',
-                    credential: 'password'
-                }
-            ]
-        }
+        try {
+            // call the prepare endpoint first
+            await prepareStream('my-first-stream');
+
+            const videoEl = document.querySelector('video');
+            const constraints = {
+                    video: {
+                    frameRate: 30,
+                    width: 1280,
+                    height: 720,
+                    },
+                    audio: true
+                };
+
+            const localStream = await navigator.mediaDevices.getUserMedia(constraints);
+            videoEl.srcObject = localStream;
+
+            const servers = {
+                iceServers: [
+                    { urls: 'stun:stun.l.google.com:19302' },
+                    {
+                        urls: 'turn:34.101.121.241:3478',
+                        username: 'username',
+                        credential: 'password'
+                    }
+                ]
+            }
 
-        const peerConnection = new RTCPeerConnection(servers);
+            const peerConnection = new RTCPeerConnection(servers);
 
-        peerConnection.oniceconnectionstatechange = () => {
-            // handle state change (disconnect, connected)
-            const iceConnectionState = peerConnection.iceConnectionState;
-            console.log('iceConnectionState', iceConnectionState);
+            peerConnection.oniceconnectionstatechange = () => {
+                // handle state change (disconnect, connected)
+                const iceConnectionState = peerConnection.iceConnectionState;
+                console.log('iceConnectionState', iceConnectionState);
 
-        }
+            }
 
-        peerConnection.onicecandidate = async (event) => {
-            // initiate the stream process once ice gathering is finished
-            if (event.candidate === null) {
-                await initStream(slug,peerConnection,options);
+            peerConnection.onicecandidate = async (event) => {
+                // initiate the stream process once ice gathering is finished
+                if (event.candidate === null) {
+                    await initStream(slug,peerConnection,options);
+                }
             }
-        }
 
-        // we use stream from the webcam that we captured from previous step
-        localStream.getTracks().forEach((track) => {
-            peerConnection.addTrack(track, localStream);
-        });
+            // we use stream from the webcam that we captured from previous step
+            localStream.getTracks().forEach((track) => {
+                peerConnection.addTrack(track, localStream);
+            });
 
-        try {
             const offerSession = await peerConnection.createOffer();
             peerConnection.setLocalDescription(offerSession);
         } catch (err) {
@@ -206,7 +226,7 @@ Once the video stream input is available, we're ready to send the video stream t
 
 3. Once the RTCPeerConnection is set with both offer and answer SDP, it will initiate the connection to the remote peer, and the `peerConnection.oniceconnectionstatechange` will be triggered if the connection state is changing.
 
-### 4. Get the video
+### 6. Get the video
 Once we streamed the video from our webcam through WebRTC, we can watch the video by getting the video URL through the stream detail endpoint.
 Get the stream detail by sending HTTP GET request to the API endpoint `https://api.inlive.app/v1/streams/${streamid}`. Let's create a get stream function that we can call later
 ```js

content/docs/video-input/index.md

@@ -14,9 +14,20 @@ menu:
 ---
 
 # Video Input
-Inlive is support 2 ways to sending the video source input to our encoder. You can use either WebRTC or RTMP. This page will explain the different between this two and how you can choose which input method that fit with your case.
+Inlive is support 2 ways to send the video source input to our encoder. You can use either [WebRTC](https://webrtc.org/)(Web Real Time Communication) or RTMP(Real-Time Messaging Protocol - coming soon). This page will explain the difference between these two and how you can choose which input method fits your case.
 
 ## WebRTC
+WebRTC is a web standard protocol for video communication that is used by Google Meet. It's a UDP-based network transport by default which is known to reduce latency, but we still can make it work through TCP if needed. The better latency is the main reason why we focus on WebRTC input first instead of the RTMP that is already standard input in the live streaming app. Another reason is WebRTC can work everywhere including in the browser, something that RTMP can't do. With this, we can build a live streaming broadcaster app like OBS but on the web. No need to install anything.
+
+So if you want to build a live streaming app that can capture the camera on all platforms, not only in the mobile apps but also on the web, then WebRTC is your choice. Check out [our tutorial](/docs/tutorial/tutorial-app-with-webrtc/) on how to capture a camera on the web and send it as a video stream input. For mobiles, there are some tutorials and examples that you can use as well. 
 
 
 ## RTMP
+RTMP is the most popular standard protocol for live streaming. It was used by Adobe Flash to stream the video from the server to a Flash player. But now RTMP is mostly known as a video input standard for YouTube, Twitch, and other live stream services. The main issue with RTMP is it's not supporting the web. So we can't build a broadcaster client on the web and use it as video stream input like WebRTC can do. And compared with WebRTC, RTMP is using TCP as their network transport. It's more reliable because TCP can guarantee all the network packets will be received by the server.
+
+## Conclusion
+WebRTC and RTMP can be used as a video input protocol for our live stream, but which one you should use? It depends. The main difference between WebRTC and RTMP is the network transport protocol. WebRTC has better latency but can't guarantee reliability, which means you might have better latency but you probably will see some glitch in the video when the broadcaster host internet network is not that good. 
+
+If you're hosting a live stream that doesn't need interactivity, like a live concert, sports event, or any one-way broadcasting where the quality of the video is important and that broadcast usually can be seen on TV as well, then you probably want to use RTMP because it will have a better video quality of the live stream. But if you're hosting an interactive live stream, like a live shopping, trivia quiz, online bidding, or any live stream where the low latency is a must, then WebRTC will be a good option. 
+
+Another consideration is the platform support, if you're thinking to have a broadcaster feature on all platforms including the web, then WebRTC is the only way. RTMP can't be used on a browser, only on native mobile platforms like Android and iOS. Let us know if you still need more insights on which video input to choose.

themes/inlive/layouts/blog/single.html

@@ -19,11 +19,11 @@
     <section class="max-w-3xl mx-auto">
       <h2 class="mb-4 font-extrabold text-3xl lg:text-4xl text-blue-900 text-center">Try inLive today</h2>
       <p class="text-base text-gray-600 mx-auto mb-6 lg:mb-8 text-center">
-        Explore Developer Portal to get up and running with inLive API as easy as count 1-2-3, or create an account in inLive Studio to start live streaming from your browser.
+        Explore our documentations to get up and running with inLive API as easy as count 1-2-3, or create an account in inLive Studio to start live streaming from your browser.
       </p>
     </section>
     <nav class="max-w-3xl mx-auto flex flex-col sm:flex-row gap-4 text-center justify-center">
-      <a href="/docs/introduction/" class="w-full sm:w-auto py-2 px-4 bg-blue-100 rounded-md font-medium text-sm text-blue-700">Visit Developer Portal</a>
+      <a href="/docs/introduction/" class="w-full sm:w-auto py-2 px-4 bg-blue-100 rounded-md font-medium text-sm text-blue-700">Visit Our Docs</a>
       <a href="{{ .Site.Params.inliveStudioOrigin }}/login" class="w-full sm:w-auto py-2 px-4 bg-blue-100 rounded-md font-medium text-sm text-blue-700">Open inLive Studio</a>
     </nav>
   </div>

themes/inlive/layouts/partials/footer/footer.html

@@ -23,7 +23,7 @@
           <strong class="font-semibold text-gray-900">Resources</strong>
         </li>
         <li class="text-sm leading-6">
-          <a href="/docs/introduction/" class="text-gray-500">Developer Portal</a>
+          <a href="/docs/introduction/" class="text-gray-500">Docs</a>
         </li>
       </ul>
     </nav>