| 6 Nov 2022 |
 thaytan#5292 | and an LGPL dependency instead of GPL | 12:41:59 |
|  laov joined the room. | 12:51:24 |
 Xytovl | I don't think gstreamer is suitable, x264 here is used because it has a very specific feature that lets us receive data before the whole frame is processed, saving precious time on network transfer.
There are also implementations for vaapi (using ffmpeg) and nvenc, which don't require GPL.
One option could be to do like ffmpeg https://ffmpeg.org/legal.html. There's an --enable-gpl configuration option, which is required to enable x264. | 12:54:02 |
 Jakob Bornecrantz#6482 | What's that feature called? | 12:59:05 |
| Xytovl | https://code.videolan.org/videolan/x264/-/blob/master/x264.h#L576
"low-level callback for low-latency encoding." if that is a feature name...
Instead of waiting for the encode function to return, x264 uses callback when a slice is available, which we send as soon as possible. | 13:34:46 |
| Jakob Bornecrantz#6482 | Thanks | 13:36:52 |
| Jakob Bornecrantz#6482 | I have vague recollection that something like that was done for gstreamer. | 13:37:04 |
| Jakob Bornecrantz#6482 | * I have a vague recollection that something like that was done for gstreamer. | 13:37:10 |
| Xytovl | It could be, but if we use gstreamer and do software encoding, that will be with x264 and we end up with GPL again | 13:46:34 |
| Jakob Bornecrantz#6482 | Doesn't have to be x264 that implements that feature in gstreamer. | 13:51:20 |
| Xytovl | https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/README.md#building-plugins-with-agpl-licensed-dependencies | 13:52:32 |
| Xytovl | x264 is the only fast h264 software encoder | 13:52:52 |
| Jakob Bornecrantz#6482 | For the project perspective what people put into it downstream doesn't matter to use at all, like you could run Monado on a GPL Vulkan driver, or use it from a GPL program, or combine it with GPL code and it wouldn't matter to us. "You" are doing the combining. What matters is the licenses for files that are in the main repo. If you are including x264 headers in your files they also needs to be GPL so they can't be in the main repo. So if somebody combines Monado with a GPLed version of gstreamer it doesn't matter. Because Monado only depends on gstreamer which is LGPL, you did the GPL upgrade downstream not upstream.
That's one work-around, there are others as well. | 13:54:32 |
| Jakob Bornecrantz#6482 | Anyway, I think we can figure out something that works for everybody involved. | 13:56:54 |
| Xytovl | We could do the same by having encoders dynamically loaded, there is an abstraction already. nvenc, vaapi and x264 implementations could be compiled and distributed separately | 13:58:37 |
| Jakob Bornecrantz#6482 | Oh that's one option yeah | 13:59:12 |
| Jakob Bornecrantz#6482 | Heading out for now, be back later.
Great work! 😄 | 14:00:11 |
|  LaoGaoBeBePao joined the room. | 15:50:23 |
|  moshi 🌈🐈 changed their display name from Moses Turner to meowshi#6942. | 19:27:35 |
| moshi 🌈🐈 changed their display name from meowshi#6942 to Meowses Turner. | 19:27:37 |
| 7 Nov 2022 |
|  malekire#0 joined the room. | 00:04:44 |
| malekire#0 | this is amazing | 00:04:44 |
 technobaboo#0 | omggggggggggggggggg | 00:06:10 |
|  Sovinox joined the room. | 02:32:41 |
|  dwagenk joined the room. | 07:18:52 |
| thaytan#5292 | Ah, interesting (doing low-latency slice-based encoder). GStreamer calls it 'subframe encoding', and it's implemented for a few encoders (nvenc, for example), but not x264 as it happens. It'd be great to implement support more widely - but you're right, right now it'd lead to higher latency.
Yes - tying the feature behind a --enable-gpl toggle is one option | 07:58:49 |
| thaytan#5292 | Great work, btw - it's an exciting feature | 07:59:07 |
| Xytovl | I just realized Collabora is behind monado and actively supporting gstreamer as well 😄
If someone wants to help me port the encoding to gstreamer, it could be nice.
The tricky things we do are mapping from vulkan frames, encoding portions of each frame using different encoder implementations concurrently (and sequentially if configured, to help with lack of sub-frame encoding on vaapi), sub-frame encoding for x264.
I am also not 100% confident on colour standards, for x264 I have to do conversion to YUV myself, and if I set any option (such as full-range, or changing the transfer function, colour matrix), the decoder seem to happily ignore it, both when using Android's MediaFormat metadata and h264 VUI parameters. | 08:49:55 |
| Xytovl | Also, a big disappointment is that I don't seem to be able to run any real software with this: I don't own many VR games, openComposite seem to fail with No Man's Sky which is the only proper game I own. Valve's "The Lab" also fails, I can run helloXR or godot's VR sample and that's almost it... | 08:52:01 |
| thaytan#5292 | Quest link encodes 4 subframe streams too, without encoder support I assume - slicing each frame into 4 pieces and encoding in parallel, then reassembling on the device | 08:56:42 |
