HTTP Live Uplink Streaming via Chunked Transfer Encoding

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current uplink streaming protocols, such as RTMP, face limitations including lack of standardization, limited support for adding video, audio, or closed-captioning solutions, and are hindered by firewall and NAT issues, which restrict the widespread adoption of live video streaming, especially from devices behind firewalls or mobile networks.

Innovation Solution

Implementing a live uplink video solution using HTTP with an HTTP client on the client device, establishing a connection to an HTTP ingest server, and utilizing HTTP Chunked Transfer Encoding to enable reliable and elastic transport, allowing for bitrate adaptation and overcoming firewall restrictions while leveraging existing HTTP libraries and infrastructures.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If RTMP protocol is used for uplink streaming, then reliable transmission is achieved through TCP, but firewall and NAT restrictions prevent widespread adoption

Engineering Contradiction:

Improvetransmission reliabilityVSAvoidfirewall compatibility

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent uses HTTP as an intermediary protocol to bridge the gap between reliable TCP-based streaming and firewall-compatible web traffic. By encapsulating streaming data within HTTP requests and responses, the system can traverse firewalls and NAT devices that normally block direct TCP streaming connections.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system makes the HTTP protocol multi-functional by using it not only for standard web traffic but also for carrying live streaming data. This allows the same protocol to serve both web browsing and video streaming purposes, eliminating the need for separate streaming protocol configurations through firewalls.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Adaptability or versatility

If HTTP protocol is used for uplink streaming, then firewall compatibility is improved, but standard HTTP server architecture creates connection establishment issues

Engineering Contradiction:

Improvefirewall compatibilityVSAvoidconnection establishment

Core Design Contradiction:

Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent inverts the traditional HTTP server-client model by placing the HTTP client functionality on the streaming source device (camera/mobile device) and the HTTP server on the receiving end. This inversion allows the streaming device to initiate connections outward through firewalls rather than having incoming connections blocked by firewall rules.

Inventive Principle:

Principle #13The other way round (Inversion)

3Adaptability or versatility

If RTMP protocol is used, then proprietary control is maintained, but standardization and security function re-use are limited

Engineering Contradiction:

Improveprotocol standardizationVSAvoidprotocol implementation

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

By using the universal HTTP protocol for streaming, the system can leverage existing, widely-available HTTP libraries and infrastructure instead of implementing proprietary RTMP protocols. This reduces implementation complexity while maintaining standardization benefits.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system allows existing HTTP security mechanisms (HTTPS, authentication, encryption) to serve the streaming protocol's security needs automatically. Rather than implementing separate security layers for streaming, the protocol benefits from HTTP's built-in security capabilities.

Inventive Principle:

Principle #25Self-service

Data Source

PatentUS11805163B2Apparatuses, methods, computer programs, and computer program products for live uplink adaptive streaming

Publication Date: 2023.10.31 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)

AI summary

A method for providing a media feed to a server. The method includes a client transmitting to the server over a transport layer connection a message comprising a header and a body, wherein the header of the message does not indicate the size of the body of the message. The method also includes the client storing in a transmit buffer media data corresponding to the media feed, wherein an encoding bitrate setting is used to generate the media data. Transmitting the body of the first message to the server over the transport layer connection comprises: 1) before transmitting any media data corresponding to the media feed, the client transmitting to the server over the transport layer connection a movie box comprising information identifying a codec and codec configuration information; 2) after transmitting the movie box, transmitting one or more Common Media Application Format (CMAF) chunks, wherein each CMAF chunk comprises media data corresponding to the media feed; and 3) after transmitting the one or more CMAF chunks, transmitting an end of stream indication, wherein the end of stream indication is i) an end of stream flag or ii) a zero-size chunk.