ndufresne libcamera gives a standard method to pipewire for us to integrate into firefox/chrome even cheese
bryanodonoghue, So what you're saying is you're waiting for 'libencoder' ;-)
I think my q is - is there worthwhile work what could be done to plug codecs into pipewire given the direction being taken with libcamera/pipewire
yeah ... I guess
(fwiw, I think libencoder already exists, and it's called gstreamer/ffmpeg)
right - I'm thinking of how/where to deploy effort to "get stuff working out of box on qcom in ubuntu/arch/debian"
so gstreamera/ffmpeg integration in chrome firefox is the answer .. ?
Or direct v4l2m2m ... but I have no idea really.
It comes up in libcamera discusions too though as people often expect to be able to encode a stream from a camera, and many orgs/communities seem to think a camera should deliver a ready made encoded stream. Which might be lovely except for all the parameters and further complications that would then bring ;-)
bryanodonoghue: then why not plug gpus ?
we already struggle with the handful of controls in libcamera, have you considered the challenge for stateless codecs ?
not to mention the overhead
ndufresne, I think that's /why/ libcamera doesn't have encoders ;-)
And that's what I mean by "all the parameters and further complications that would bring"
on thing to note, is that camera and audio card have exclusive access in common, were gpu and codecs can be multi-plexed (well stateful firmware can suck, but that's HW vendor mistake)
ndufresne, But how should firefox/chromium/other apps generically hardware accellerate video encoding on arm ? Or do they already have the required developments?
They can call directly into v4l2, there is not magic sauce there
The ultiimate question (If I'm assuming bryanodonoghue's predicament, and can put words in his mouth) Can an arm laptop hold a hardware accelerated video call already.
lol, there is millions of chromebooks out there 
chromium have decoder and encoder support for both stateful and stateless mainline codecs
Yes ;-) of course. But are there millions of chromebooks running debian that can do the same ;-)
the challenge is of course to build chromium for generic linux, which ChromeOS team don't prioritize
and *that* is bryanodonoghue's question. How do we make chromium / firefox work on generic linux to handle video calls.
(I think, if I understood bryanodonoghue correctly, and I'm still waiting for him to tell me I missed the point)
we made the decoders work on RK3399, so its possible, if time wasn't an issue, I'd try to make a flatpak, but again, I'm not in love with chrome in general, I usually prefer firefox, an firefox media stack is ... can't describe it ...
If the answer is - they already do - then - things are all groovy right ;-)
the Linux/Firefox media dev statement recently is that "we suck at this", so if we can use it through ffmpeg, fine, otherwise we'll do software
so if someone send patches to enable ffmpeg v4l2m2m codecs (stateful, but bryanodonoghue is on Qualcomm HW so that's good for him), then you will solve the problem
bryanodonoghue, It sounds like I can return to my original answer then. you need 'libencoder' which is also known as gstreamer/ffpmeg ;-)
or a GN expert to solve the chromium build for generic arm distro
ndufresne: chromium can already use pipewire for webrtc, would that use gst as well for video decoding? (I'm not familiar on the pipewire/gst interaction for this part)
javierm: camera capture and screencast is very different from decoding and encoding
when you screencast, you actually interface with the compositor through pipepewire (no gst, just mutter/kwin/wlroot etc.)
when you do libcamera capture through pipewire, you interface with pipewire only, since it has a plugin (SPA plugin) that can use libcamera
you can of course use GStreamer to feed nodes into pipewire graph, similar to what your compositor do
what pipewire gives you is multi-plexing across multiple process
its really bad with compressed data though
ndufresne: that's the part that wasn't clear to me. If was using the libcamera SPA plugin or using gst as a video src 
ndufresne: wait, so my work on RPI4B brc8235-codecs won't be used on FF/chromium? unless someone patches FF to use ffmpeg v4l2m2m?
Correct, but its not only about the Pi, its literally all the ARM stuff, as said, chromium have the code, its a build issue, the v4l2 stuff has been made to depends on chromeos specifics, but my colleague Chris Oboard have made it work recently, so its fixable for sure, I actually think we are close, but for Firefox, there is a lot more work
chromium have been doing v4l2 codecs since 2010 in fact
but the focus is always around chromebooks
so, no aarch64 then?
what do you mean ?
i thought chromeos was targeted to 32bit only?
(on arm)
i read somewhere that's where that drm crap always is a problem, there was no arm64 build of it
maybe it's changed now?
alien_lappy: chromeos has aarch64 based products for years 
in fact, I don't think that any armv7 chromebook is supported any longer
Hello! I'm looking for a changelog or something similar for the uvcvideo driver. Is there such a thing somewhere? I couldn't find anything, but I'm not sure I've looked in the right places
At my company, we have a number of fairly legacy robotic systems that use old 5.x Linux kernels and UVC cameras, and we have noticed that we need to give the cameras very different settings, especially in terms of manual exposure, to achieve comparable photographs across different kernel versions. We'd like to know more about the differences between, say, uvcvideo 5.4.x and 5.10.x, in order to inform our usage of the cameras until we can migrate our s
...homogeneous, recent kernel configuration. That's why I'm looking for a changelog of uvcvideo. Or maybe a git log?
alien_lappy: no anymore
picsea, take the most recent linux kernel and run "git log --oneline ./drivers/media/usb/uvc/"
kbingham, thanks! I'm cloning git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git right now (lmk if not the correct repo pls)
picsea, I'm sure thats' fine.
kbingham, I've got the git log now, thank you very much. Now, commits are timestamped, but the kernels we're running have a version number (5.4.x, 5.10.x). Is there a way for me to know which commits I'm looking at made it into which kernel release?
You could filter your git log command to between specfific tags. 
git log v5.4..v5.5 ./drivers/media/usb/uvc/ does the trick, thanks!