> > On Tue, Jul 19, 2016 at 09:41:22AM -0400, Frediano Ziglio wrote: > > > I don't think we have strong reasons to support software encoding, video > > > encoding is really expensive, and that mmap/copy is not going to be > > > marginal, so even less these 2 syscalls. > > > > > > > Using HW encoding is not easy at it seems: > > - you have to have client supporting server HW encoders; > > - you have to install additional software often closed source, accepting > > patents; > > - you have to have right permission on the system. > > What are you doing if these option are not respected? Do not allow > > connections? Showing blank screen? > > With a good (local) connection I can easily play using software MJPEG, why > > we should avoid such configurations? > > What we should be aiming/optimizing for is the hardware-accelerated > case. We will need a fallback when this is not usable, but the various > copies/encoding/... are going to be very expensive by themselves. Are > these changes (passing texture rather than dmabuf) making a significant > difference with software encoding? > > Christophe >
Got some experimental results passing DRM primes to gstreamer (https://www.youtube.com/watch?v=NFDvMHfXUHA). With VAAPI it's working the full frame processing decreased by a 50%. No, they are not expensive and we could just (in case of fallback) import in a new GL context to have them extracted correctly. I'm actually trying to make it works again with software encoders (no VAAPI and having to extract raw data). It's working as with kernel 4.6 i915 allows mmap but as the texture are in a different format I get quite some garbage (they should be extracted with GL which know these problems). Frediano
