Live shopping combines socializing, entertainment, and of course, shopping! A typical live shopping event features a well-known social media influencer or celebrity who will host a session where they talk about their favorite products. As they display and discuss each product, viewers have the opportunity to buy and sometimes engage with the session host via chat or call-in. This is one of the most popular shopping options worldwide. In 2023, the estimated market size for livestream e-commerce in the United States alone reached 31.7 billion dollars*

While live shopping is highly lucrative, what makes it difficult to get started, is finding the right video platform.

While live shopping is highly lucrative, what makes it difficult to get started, is finding the right video platform. Options include building and maintaining a platform yourself, or choosing a company that does this for you. In either case, similar issues arise — it’s difficult to set everything up so it’s cost-effective, reliable, and scalable. When users rush to a live shopping session featuring their favorite products and celebrities, the servers must be able to successfully handle every interaction, and continuously deliver multiple high quality, live video streams. Interruptions and pauses can result in loss of sales, hosts, and viewer interest.

Raskenlund builds reliable, scalable platforms that ensure companies can stream multiple high quality, fast live shopping streams every time. It all starts with understanding the live shopping workflow. One common workflow looks something like this (but could include other technologies depending on your desired setup):

1. Publish: The publisher/broadcaster uses a mobile device or web browser to send a live stream to a Media Server like Kurento Media Server, Ant Media Server or Norsk.
2. Invite: The publisher/broadcaster invites everyone who will appear on the live stream to the session associated with the live stream. With Raskenlund’s solution, you can have a composition of multiple separate streams with one host stream and zero or more guest streams.
3. Compose: The media platform merges the streams into a single output stream that the show host can manage using a web-based control panel.
4. Distribute: The composited output stream is sent off for transcoding into adaptive bitrate (ABR) and further distribution.

To manage workflows like this, Raskenlund developed a software program that controls the interaction between all the components of the streams. Some of the tasks it manages include:

• Communicating with the back-end in order to set up the show and user verification
• Providing instructions to the media server or service for how to produce the output stream
• Managing the flow through transcoding and packaging services
• Load-balancing for the multiple instances required to handle multiple live shopping shows occurring at once

. . .

With the control software handling the hard work of creating and delivering consistent, reliable setups for live shopping shows, there’s just one issue left — scalability. Auto-scaling is a part of what cloud service providers offer customers, however the service is focused on handling web requests. It’s fine to move web requests to different servers as part of scaling, but making reassignments like this as part of autoscaling for live streams can cause all kinds of undesirable issues. It can lower video quality or cause interruptions and delays in video streams.

Raskenlund’s auto-scaling solution uses metrics and algorithms that are specific to streaming media

Raskenlund solves the auto-scaling problem with its own auto-scaling solution called Ztream Escalator. Rather than using metrics that are focused on what’s needed to scale web requests, Ztream Escalator uses metrics and algorithms that are specific to streaming media. The product dynamically adapts to sudden changes without causing stream interruptions, anticipates scaling needs, and can be configured in advance to handle predictable surges in livestream viewership. Last but not least, Ztream is fully customizable to each platform. It works with any streaming protocol, provider, or region.

If you’re looking for a consistent, customized live streaming solution, contact Raskenlund to talk about your tech stack today and reap the benefits of:

• Virtually unlimited scaling of streaming resources
• Fully-automated workflow
• Ability to run live streams with guests
• Low-latency streaming for host and guests
• Reliable, high quality distribution to large audiences

. . .

Resources:

• Livestreaming commerce sales in the United States between 2022 and 2026
• Autoscaling: What It Is and Why You Need It
• Why Traditional Autoscaling Is Deficient for Streaming Media

Here’s how we can start building your Live-Shopping Platform together.

When building your own Live-Shopping solution, a good approach is to start by making an MVP with essential features and then enhancing it with more features based on customer feedback.

An MVP, or “Minimum Viable Product”, is a version of the platform with just enough features to be usable by customers who can then provide feedback for future product development.

As an example, your MVP could include

• The E-Commerce software, with payment integration
• Video Streaming capabilities
• Interactive features, e.g. chat
• Some integration with Social Media platforms

Based on the feedback from your customers, information from the market, and based on your own creative mind, after the MVP, you can expand the solution with new features and functionalities, like:

• Simulstream (Live streaming to multiple platforms)
• Further integration with Social Media platforms
• Adding an option to Invite guests to your show
• etc.

1. Tell us about your business model.
2. Let’s define the MVP together. Choose an e-commerce platform; cloud-based, or self-hosted video streaming, what features will be included, etc.
3. We set up a project plan. PS: We love working in small steps (using a so-called “agile” methodology)
4. Get to work! Our team will develop, integrate, implement and document. We’ll keep you updated underway through regular meetings.
5. Acceptance: We review the first step of the project plan (see #3), and then we move on the the next step.
6. We repeat #4 and #5, and implement the functionality that we decided in the project plan, and that form the MVP
7. Go Live!
8. Now we go over desired features, and functionality. We filter and sort, and we make an expansion plan.
9. Step by Step we add new features and functionality. We stick to the same principle as mentioned in #4 and #5
10. Success! You are part of an industry that is projected to touch USD 3,901.74 billion by 2031, exhibiting a CAGR of 11.28%^*. A smart move.

From the time your platform is set in production, we offer Maintenance and Support. We will help you to keep your solution in great shape, and your customers satisfied.

Remember that the industry is constantly on the move, and your business isn’t static. Fortunately, neither are we; and we got your back. We’ll keep using our growing experience and expertise to advise, support and keep you at the forefront of the market.

For live streaming, we recommend WebRTC. It is a standard that enables real-time communication. You can choose from different options depending on your needs. For example, you can use Ant Media Server if you want to host your own servers, Ceeblue if you prefer a cloud-based service, or Amazon IVS.

When it comes to e-commerce platforms, there are some interesting choices available. WooCommerce and Magento are two popular examples that offer a lot of features and flexibility. We have partnered with experts who can help you install, customize and maintain these platforms. Alternatively, you can also build your own platform from scratch, which gives you full control over every aspect of your online store.

Another challenge that you may face is integrating your website or app with social platforms. These platforms may change their so-called “SDKs”, which can affect your functionality and user experience. We can help you keep up with these changes and ensure a smooth integration.

*) Live E-commerce Market Growth, Size, Share By 2031 Forecast Value (businessresearchinsights.com)

Live-shopping is an interactive e-commerce experience that combines the convenience of online shopping with the real-time engagement of live streaming.

In essence, it allows brands to connect with their audience through live video broadcasts, showcasing products, answering questions, and creating a dynamic shopping environment. This trend originated in Asia and has rapidly spread globally, transforming the traditional online shopping experience.

Key Features of Live-Shopping

1. Real-Time Interaction: Live-shopping enables direct communication between sellers and consumers in real-time. Viewers can ask questions, seek advice, and receive instant responses, creating a more personalized and engaging shopping experience.
2. Limited-Time Offers: One of the driving forces behind live-shopping is the sense of urgency it creates. Sellers often provide exclusive discounts or limited-time offers during live sessions, motivating viewers to make quick purchase decisions.
3. Product Demonstrations: Live-streamed product demonstrations allow customers to see the product in action, providing a better understanding of its features, functionality, and potential benefits.
4. Social Media Integration: Many live-shopping sessions take place on popular social media platforms, leveraging the existing user base for wider reach. Viewers can easily share the live stream with their networks, contributing to organic marketing efforts.

Why Should You Let Built Your Own Live-Shopping Solution

1. Enhanced Engagement: Live-shopping fosters a deeper connection with your audience compared to traditional e-commerce. The interactive nature of live sessions builds trust and loyalty, ultimately driving customer engagement and repeat business.
2. Increased Conversion Rates: The combination of real-time interaction and limited-time offers often leads to higher conversion rates. Viewers are more likely to make immediate purchase decisions when presented with exclusive deals during a live-shopping session.
3. Competitive Edge: As live-shopping gains popularity, businesses that adopt this trend early gain a competitive edge. Developing your own live-shopping solution positions your brand as innovative and forward-thinking in the ever-evolving e-commerce landscape.
4. Data Insights: Live-shopping platforms provide valuable data insights into customer behavior, preferences, and buying patterns. Analyzing this data can inform marketing strategies, product development, and overall business decisions.

Live-shopping is not just a passing trend; it’s a transformative force in the e-commerce industry. The blend of entertainment, interactivity, and convenience makes it a compelling option for businesses looking to stay ahead in a competitive market.

By developing your own live-shopping solution, you’re not only meeting the current demands of consumers but also future-proofing your brand in the dynamic world of online retail. Embrace the live-shopping revolution, and watch as your e-commerce experience takes on a new dimension.

The standard module development approach advertised by Wowza in their tutorials is a great starting point for absolute beginners to Java. It gives them a rapid start with the experience of rapid deployments to a co-located Wowza Streaming Engine installation. We found that this approach is not aligned to our vision for three major reasons:

• Relying on the local installation of WSE is too much overhead for lightweight CI builds, it practically makes builds non-portable
• Lack of dependency resolution can cause problems when the module’s own open-source library dependencies clash or overlap with the dependencies of the installed WSE version itself
• Apache Ant as a build tool is on sunset and is not considered a strategical build tooling by the industry

We decided to go for a Gradle build process that can be easily executed on popular cloud-based continuous integration services.

Gradle is a very popular build tool that uses a declarative domain-specific language expressed in Groovy or Kotlin. It stands somewhere on the middle ground between Ant and Maven: you get the flexibility of ad-hoc scripting wherever needed in the build process, but it has convention-over-configuration approach and features a sophisticated dependency resolution system compatible with Maven repositories.

A vanilla installation of Wowza Streaming Engine 4.8.17 drops nearly 140 individual jar files into the lib folder which all will be on the classpath when your module is loaded. Our commercial modules have to be tested and made compatible with a range of WSE versions. Wowza release notes might or might not mention version changes in the dependencies, only bigger, breaking changes (e.g. log4j 1.x to 2.x) are expected to be highlighted.

The installed jar files fall into two categories: the API of WSE itself (wse-*.jar) and third-party dependencies. In the beginning, we tried to keep track of the versions of certain libraries that our modules were using, to make sure they are not incompatible with the ones shipped with Wowza itself. Some of the libraries that our modules often share with Wowza are: Google Gson, Apache HttpClient, AWS SDK, etc. We had to branch our code based on which Wowza version they were compatible with, and keeping these branches on the same feature level was an administration overhead.

We wanted to specify the Wowza version that we are building and testing our modules with, as a parameter in our build, expecting Gradle to bring in the right set of WSE SDK jar files and the right set of accompanying dependencies at the same time.

To achieve this we set up a private Maven repository and started to discover and publish the dependencies in it as a bill-of-material (“BOM”), similarly to how it is done in the open-source Spring Boot project. To automate this publication, we wrote a simple Groovy script that we execute against every new release of Wowza Streaming Engine shortly after the announcement. The script publishes the wse-*.jar files into our Maven repository under the group identifier com.wowza.

As a second step, we scan and identify individual third-party open source dependencies and identify them in the public Maven repository based on the jar file SHA1 checksums that we can calculate for each file. Within a minute as the result of the scan, we produce a list of canonical maven coordinates that we can put into a BOM. There is a small set of known “outlier jar” files that are not present in Maven central and we deal with them separately.

The produced BOM file is also published to our Maven repository, making it consumable for CI builds. Besides the pom.xml files we also generate Gradle module files that can keep track of additional information, such as the Java version used by WSE in (e.g.”org.gradle.jvm.version”: 9) attribute.

As an end result, we can compile our modules against an arbitrary version of WSE by simply putting the below few lines in our build.gradle file and the code just compiles on our CI server:

gradle.properties:
wowzaVersion=4.8.17

build.gradle:
dependencies {
    implementation group: 'com.wowza', name: 'wowza-bom', version: wowzaVersion
}

If our modules use a third-party dependency, such as Gson for working with JSON payloads, importing the Wowza BOM provides it to the Java compiler and when the module is deployed into the server, the required classes will be available on the classpath. This is relatively simple and safe to rely on in most cases but can lead to incompatibilities with future versions if at some point in time Wowza ships with a newer version of the library that has incompatible changes. Those would break our modules resulting in unpredictable runtime exceptions.

Application servers and servlet containers have gone a long way to provide classloader isolation to hosted applications and allow different versions of libraries to coexist using separate classloaders. This has not been a priority in a media-focused server. We decided to use the shadow technique to repackage dependencies under a different Java package name which provides isolation even if additional third-party modules are installed that ship with clashing transitive dependencies.

Configuring the shadowJar plugin in Gradle is fairly easy:

plugins {
    id 'java'
    id 'com.github.johnrengelman.shadow' version '6.1.0'
}

dependencies {
    shadow group: 'com.wowza', name: 'wowza-bom', version: wowzaVersion
    implementation 'org.apache.commons:commons-text:1.9'
    implementation 'com.raskenlund:wse-modules-common:1.1.1'

    testImplementation(platform('org.junit:junit-bom:5.7.0'))
    testImplementation('org.junit.jupiter:junit-jupiter')
    testImplementation('org.assertj:assertj-core:3.18.1')
}

shadowJar {
    relocate 'org.apache.commons.text', 'com.raskenlund.shadow.caption.text'
}

In the above example the wowza-bom dependency is put into the shadow configuration because we don’t want to package it into our output jar file. The commons-text dependency is very popular and is quite probable that it would be used in other modules, so the safest thing to do is relocating it under a different Java package name. We also embed our own common code library into the output jar to make the final product a single, self-contained “fat jar”.

By filling in the gap of undefined dependencies, we were able to set up a professional delivery pipeline that allows us to deliver changes from pull requests to deployable artifacts going through the necessary steps of compilation, automated testing, packaging in a WSE agnostic cloud environment. Targeting different versions of Wowza Streaming Engine is a now a parameter of our CI pipeline and makes our work more efficient.

As a first step, we need to copy the wse-raskenlund-captioning-1.0.0-all.jar file to the lib folder of your Wowza installation, which on Linux servers is typically located under /usr/local/WowzaStreamingEngine/lib.

The module can be configured for different use-cases, in this post we are going to use CEA608 captions ingested from REST API calls. For this you need to add the com.raskenlund.caption.ModuleOnTextDataToCEA608 module to your application. You can do this by manually editing the conf/live/Application.xml file or by using the Engine Manager UI.

You can find configuration details for other possible use-cases in the documentation.

Next, we need to add a custom property to the application that contains the license key for the module:

Don’t forget to press the Save button after adding the property.

There are some additional configuration changes we need to make in the Application.xml file which is not exposed on the UI, so please open the conf/live/Application.xml file with your favorite text editor and add the highlighted lines to the TimedText tag:

The captionLiveIngestLanguages property should be a comma-separated list of those languages that you are going to use. This is necessary because the REST API allows you to specify the language for each incoming subtitle and the module allows you to select which one or ones you are interested in.

To make the REST API exposed and capable of accepting incoming subtitles, we need to edit the conf/VHost.xml file as well. This file enumerates multiple HostPort tags and you need to pick the one on which you’d like to listen for API calls.

In this post, we are going to use the Default Admin HostPort, which listens on port 8086. This requires you to open up this port on your firewall, which will also expose the other admin functions as well. In the production environment, it is recommended to expose only the minimal required functionality and use TLS.

Once these settings have been changed, please restart Wowza Streaming Engine to make sure the changes are picked up.

To demonstrate the module working, we are going to publish a live RTMP stream from OBS. First, let’s disable the default source security in the live application to make things easier:

Next, we are going to publish some content from OBS:

Once our stream is live, we can actually go and try out the REST API exposed by the module. You can use command line tools, such as curl to construct the API call, but in this example we’ll use Postman, a popular developer tool to work with the API.

Postman can import the module API specification that is published in OpenAPI 3.0 format along with the documentation. (Using tools like swagger, you can generate a client stub in your favourite programming language too).

The URL to the latest specification file is https://docs.raskenlund.com/wse-raskenlund-captioning/latest/_static/wse-raskenlund-captioning.yaml

Once the API is imported, we need to make small adjustments to the default generated request, because the spec file does not contain the actual mapping that we’ve configured in the VHost.xml file and is also not capable of picking up the example values in the yaml file.

Once the request has been edited, you can press the Send button and you should get the below result within a few milliseconds:

Concurrently, you can start playback in any player, e.g. VLC, and make sure you are explicitly turning on captions. (The list of recognized subtitle tracks might only become available after the player receives the very first subtitle)

The MEDIANTEK online magazine answers the needs and queries of the MEDIANTEK community. Our Case Study with MAP Digital, “When multichannel conferences become the new standard” is featured on page 14-15 of the Summer Issue.

Click here to read the full article (PDF)