Viewer-Centric Transcoding: As a broadcaster, I would like to optimise the playback for viewers in terms of framesize, framerate and bitrate

[chrishobcroft]

What's the problem? (required)

Currently I am broadcasting in FullHD 1920x1080 30fps 1820kbps on www.livepeer.tv from DSLR photographer cameras, and also experimenting with broadcasting in 4K 3840x2160 60fps 5820kbps from consumer webcams from Logitech.

For viewers to be able to watch, they must have:

• internet bandwidth: a fast enough internet connection to be able to receive the feed

• cpu: a sufficiently powerful device to process the content

• gpu: a sufficiently powerful device to display the content

• screen: a screen with enough pixels

Many many people in the world do not have all of these.

The problem is: these people might get left behind, as our collective ability to share information in real-time via livestreaming reaching unprecedented levels.

We say that Livepeer is about reaching an unlimited number of devices, so let's show the world how.

What's the current behaviour? (required)

Livepeer's transcoding marketplace provides a service to transcode livestreaming video into different framesizes, framerates and bitrates.

The current behaviour is that the video player at http://media.player.org will show an automatically selected stream to present to the viewer. The viewer has no visibility over how this stream is selected, nor is there

and also they have no way to control these parameters - framesizes, framerates and bitrates.

Do you have any personal experiences dealing with this problem? (optional)

Yes. I have not been able to successfully watch a livestream on an iPhone 4S using 3G connectivity.

It shows This broadcaster is currently offline, even when I am able to successfully watch using a Google Pixel XL on a 4G network.

Describe a possible solution you've considered (optional)

First of all, I would like to be able to enable a "debug view", which is an overlay to the livestream, showing the framesize, framerate and bitrate of the stream being played.

Secondly, I would like to add options in the media.livepeer.org video player to allow a viewer to set their own framesizes, framerates and bitrates for consuming video content.

In the short term, this could be as simple as offering an option to switch to viewing in 144p (if it is available from Livepeer's network), as well as the default. This would significantly increase the accessibility of content on Livepeer's network, to a new audience.

The ultimate solution, would be to allow viewers to:

• enable auto-selection of framesize, framerate and bitrate

  • measures the viewer's screensize, cpu, gpu and internet bandwidth
  • deliver the most appropriate stream to the viewer
  • these can be streams where transcoding was paid for by the broadcaster
  • also, allow viewers to pay for their own optimised transcoding

• select their own framesize, framerate and bitrate

  • give viewer full manual control over the quality of their livestream
  • these can be to select "available" streams where transcoding was paid for by the broadcaster
  • also, allow viewers to pay for their own personalised transcoding by tailoring precisely to optimise to the viewer's configuration

Additional context (optional)

This issue was originally raised as https://github.com/livepeer/lpms/issues/66 with comments so far from @dob and @ericxtang

[f1l1b0x]

this should be no big deal

enable auto-selection of framesize, framerate and bitrate this is how the video.js player currently is doing it afaik

for: select their own framesize, framerate and bitrate there are plenty opensrc examples out there like: https://github.com/kmoskwiak/videojs-resolution-switcher

whatever is present in the m3u8 would be able to be manually selected by the users.

I dont think it is a good idea to let the user pay for the video transcoding, it would only make sense in long tail content scenarios where the publisher wouldnt have agreed on the extra storage costs of a pre-transcoded video.

[chrishobcroft]

It would be interesting to allow the option for a viewer to fund the transcoding of a new configuration themselves, then as more people select that configuration, they start to share the costs equally.

Kinda like crowd-sourcing for transcoding costs.

• The first viewer is shown the full cost of the new transcoding configuration.
• The second viewer sees a lower cost
• The third viewer sees an even lower cost
• etc.

Allowing viewers to pay would also provide Livepeer with a whole load more customers :)

@f1l1b0x I'm not sure what storage has to do with this though? I'm talking about live transcoding for watching live and in near-real-time.

[f1l1b0x]

yeah, why not :) for long tail I can see this. a few things speak against it: if you do the abr encoding in steps it is wasteful since in your scenario each transcoding step would require to download and decode the source. it is easier and more efficient to have one transcoder do the whole job. You can crowd fund this of course but usually you want it to have happened before someone even sees your stream as your first viewer might already need a downscaled version of your stream to be able to view it. *what if that first user is not willing to pay for the transcoding?

[chrishobcroft]

• :) I have faith that you will not build a system which is wasteful ;) but also perhaps our customers might want additional flexibility than to stipulate that all the transcoding for a stream must be done by the same transcoder... what if that transcoder doesn't have the capabilities to transcode all the bitrates that broadcasters and viewers want?

• right, so the broadcaster can pay for a few different transcoding to happen, to give viewers a few options "out of the box". But why then limit Livepeer's customers to a small number of broadcasters, when it could be extended to a large number of viewers?

• :) same with everything in life @f1l1b0x ... if they aren't willing to pay, then they don't get what they want. Simple. But if they are willing to pay fees for tailored transcoding, especially if the costs are going to be as low as you predict, then why not let them?

Keep up the great work!

[f1l1b0x]

if they aren't willing to pay, then they don't get what they want

I disagree here. a publisher has the biggest interest in the viewer to watch the content. If it is long-tail content it also means the publisher isnt that successful with his videos yet and might be counting each single view. it would be a big loss to miss out on the first viewer just cause no-one wants to pay for it. how is this then competitive with a youtube, twitch and others where it is all for free from the users and publishers perspective?

[chrishobcroft]

I agree with you.

The broadcaster can still pay for a limited set of configurations of framesize, framers, bitrate... based on what they want to offer, and what they can afford (which might not be very much in some cases, think about emerging markets for example!).

But we shouldn't limit it to that, when we could relatively easily be able to offer more flexibility to broadcasters and to viewers to pay the fees.

Can't wait for this new transcoding marketplace to release!

[jozanza]

Closing this since we're talking about the same issue as #103

[chrishobcroft]

I would rather close the other one, as this one has far more depth, and also some conversation which may be relevant for future.

[jozanza]

@chrishobcroft Do me a favor, and don't mess with issues like this again. I already chose which issues to open/close. Feel free to keep discussing, but this one will remain closed.