Add support for two bit rates per stream: "low" 480p and "high" 1080p

[eukreign]

In order to support users on lower speed connections (and reduced download size on mobile) we need a way to support lower bit rate videos. The simplest solution is just to support a fixed two bit rates. This will require changes at all levels of the LBRY stack:

Protobufs

• [ ] Rename Stream.source to Stream.source_high_def.
• [ ] Add Stream.source_low_def field.

SDK

• [ ] publish, stream_create and stream_update add several new arguments:
  • [ ] --file_path_high_def pointing to a manually created high definition video.
  • [ ] --file_path_low_def pointing to a manually created low definition video.
  • [ ] --file_path will point to the original video and ffmpeg would be used to generate the high/low definition versions of the video
• [ ] get adds flags:
  • [ ] --high_def will only download high def version of the video
  • [ ] --low_def will only download the low def version of the video
  • [ ] default is to download the high def version

Where it's necessary for SDK to pick a bit rate, and for backwards compatibility, it should chose high definition.

ytsync

• [ ] https://github.com/lbryio/ytsync/issues/53

app

• [ ] https://github.com/lbryio/lbry-desktop/issues/3878

lbrytv

• [ ] https://github.com/lbryio/lbrytv/issues/190

Further Reading

https://mux.com/blog/youtube-viewers-dont-care-about-video-quality/

[kauffj]

Is there a naming scheme more robust to a future where there are 3, 4, or n stream types?

Just high vs low is guaranteed to change. Maybe it should be an explicit enumerated set? (120, 240, 360, 480, 720, 1080, probably something else, 4k or whatever, etc.?)

[tzarebczan]

Also, it would be a strange name for non-video content.

[eukreign]

The goal was to leave it mostly up to the creator (except in the case of ytsync would treat 420p as low and 1080p as high). For vlogs "low" might even be below 420p and for high definition nature shots "low" might be "1080p" and high is "4k". The vagueness keeps things simple.

We could also do it with separate variable for each type as you suggest but I'm not sure we've decided if we really want to publish 8 different versions of a video. I think the longer long term solution is to do variable bitrate and dynamic transcoding (from just the original video being published).

In the short term probably just a "sloppy" low and high end controllable by creators (and ytsync) should get us pretty far and might even work in the medium term too.

Also, high def and low def works for non-video content. Images, audio, etc, can all be high definition or low definition.

[eukreign]

I should add that for protobuf the naming of things doesn't matter (we can rename things whenever we want) the part that can't be changed is the position of the data in the protobuf (to change the type or meaning of a value you have to stop using the old position and use a new position).

[tzarebczan]

Also consider audio only format as a third type? https://github.com/lbryio/lbry-desktop/issues/4435

[gardenappl]

I apologize for "necroposting" on an old issue but: would it be feasible for Odysee to publish its own transcoded versions of videos on lbry:// automatically? With a public API to query available streams for a video. Could be a simpler solution to this issue, though likely a temporary one.

[belikor]

would it be feasible for Odysee to publish its own transcoded versions of videos on lbry:// automatically?

If there is 1 million videos, and then you publish 5 transcoded versions, suddenly you increase the number of claims 5 times. Also, remember, every claim requires a transaction in the blockchain, meaning staking LBC, and paying the transaction fees. Who pays for this? The user? Odysee? Odysee using the user's wallet? Will these videos be searchable? There will be duplication of videos in the search results.

I don't think it's a very sensible solution to just publish all transcoded claims. I like the solution of having multiple sources, say, low, medium, high, and letting the user choose what goes in there but only searching one by default.