"PulseVideo" Coming To Complement PulseAudio?

[gens]

There are a lot of devices supported through V4L(2). Looks like Section I Chapter 3 or 4 are relevant, or maybe section IV, here. Not really familiar with V4L, myself.

it supports shm, as all good streaming APIs should

thx for the link
it also never interested me much
it looks much simpler then i though

[schmidtbag]

Actually, this is stupid, and here's why: it's completely unnecessary. Nothing asks for this, nothing needs this, and probably nothing will really take advantage of this. All it does it add a layer of unneeded complexity. You could argue "but it could be a new standard for video" but it won't be, because that's what they always say every time.

Whether we like to admit it or not, Pulseaudio was DESPERATELY needed for anyone who wanted more than your run-of-the-mill stereo speakers + microphone setup. PA may not have been executed properly (at first) but it was still a much-needed thing to get any use out of more complex sound setups. Linux had no way of effectively muxing channels, porting applications to other sound channels, managing bass frequencies, or unifying volume controls. ALSA by itself has the potential to do most things PA does, but in most cases it's too difficult or inconsistent to configure.

All that being said - what do we need pulse video for? Most video player are already pretty smooth with decent performance. Network streaming has also been pretty refined, and runs amazingly well considering a lot of it isn't GPU accelerated.

I'll wait to see what PV is really all about, but if it's functionally the video equivalent of PA, I think all this is going to do is slow down developers.

[gens]

There are a lot of devices supported through V4L(2). Looks like Section I Chapter 3 or 4 are relevant, or maybe section IV, here. Not really familiar with V4L, myself.

thx for the link
it looks much cleaner then i thought
(and it has a shm IPC)

[xeekei]

It's always fun to watch forum dwellers act smarter than established developers. It's okay to be sceptic, but all these high horses around here is really ridiculous.

[psychoticmeow]

il publicly apologize here if this turns out to be done correctly
cuz im not one of those that dont admit mistakes

Nobody cares because you're clearly an idiot. I just wish you'd stop posting your embarrassingly dumb shit here.

[Nobu]

Dunno if the actual blog post was password protected at some point (it still is on planet gnome), but it's not protected anymore if you want to read it. Unlike PA, I can't think of many general use-cases for this, but I'm sure there are some specific cases where this would be rather useful. I don't see this being installed on many general-purpose distros by default, but I could be wrong.

[gens]

Nobody cares because you're clearly an idiot. I just wish you'd stop posting your embarrassingly dumb shit here.

i don't like to have prejudice
but do you even know how to program ?
im just curious since i never seen you write anything technical

edit:
yep, its over dbus and its for GNOME problems

also @psychoticmeow
il show you some code if you show me yours

[oleid]

PA is at major version 6 already, and it doesn't support shm

Sure, it supports shm from the beginning! Have a look at it's man page.

But shm has it's disadvantages. You've to trust both ends behave properly, e.g. one end doesn't change the data while the other end is reading them. That's why the kdbus folks introduced memfd to properly lock the shm areas. And hence, it's safer to transfer the data via kdbus instead of using shm.

[oleid]

I always thought the pulseaudio equivalent for video is the X-Server. It mixes several pixel streams (the changing windows) and outputs it all to the screen.

[gens]

Sure, it supports shm from the beginning! Have a look at it's man page.

But shm has it's disadvantages. You've to trust both ends behave properly, e.g. one end doesn't change the data while the other end is reading them. That's why the kdbus folks introduced memfd to properly lock the shm areas. And hence, it's safer to transfer the data via kdbus instead of using shm.

it was planned for version 6, but was not added
from what i remember
even if it was added, it wasn't there from the start

"You've to trust both ends behave properly, e.g. one end doesn't change the data while the other end is reading them."
and thats why you have a protocol
client -> server: "i wrote the first period"
client -> server: "i wrote the second period"
server -> client: "you are free to write to the first period"
client -> server: "i wrote the first period"
server -> client: "you are free to write to the second period"
etc
ringbuffers in shm are easy
(see alsa docs for what a period is)
ofc this would need to have a couple extra msgs for over/underruns and whatever you want


memfd locks can only be set once
making them more or less useless for this
way to use them in this would be to create a memfd, seal it then send it and then free it
and so on for every 4k of sent data (it has to be 4k)
(this would trash the cpu cache so, ignoring the fd passing, its worse then a ringbuffer)

bottom line is that the protocol is there to do synchronization, not the data transportation mechanism
and if the client does not respect the protocol and writes anyway, its the clients fault
(libalsa and libPA do that part for the program)