# Release Proposal: HTTP Segment Ingress for go-livepeer

Key problems:
* How do we return multiple files per request?
* How much of the existing transcoding pipeline should be reused?

## 1. Request: HTTP POST - response tarball

Client sends a video segment into go-livepeer; go-livepeer responds with a tar archive containing the transcoded video segments.

Pros:
* Minimal client complexity, supported everywhere
* Completely stateless, each connection completely independent

Cons:
* High latency
* Output segments provided in serial instead of parallel

## 2. Request HTTP POST - response HTTP/2 Push

Client POSTs a video segment into go-livepeer; go-livepeer responds with each segment in an HTTP/2 Push

Pros:
* Consistent with recently-announced LHLS standard
* Stateless (state limited to HTTP connection)
* Output segments streamed in parallel
* We're already using HTTP/2 for stuff

Cons:
* Moderately-complex client, not all HTTP libraries will support HTTP2
* Not supported by all proxies/load balancers

## 3. Request HTTP POST - response HLS pull

Client POSTs

Pros:
* Existing go-livepeer output logic can be reused
* Output segments can be pulled in parallel

Cons:
* Requires stateful channel between media server and broadcaster

## 4. Websockets

Client initiates a websocket connection, then input and output segments are pushed back and forth

Pros:
* Well-supported in all major languages
* Output segments streamed in parallel

Cons:
* Completely non-standard, new protocol we're inventing for this
* Very complex client implementation