Major Open-Source Code Drop For XvBA, PowerVR Coming

[phoronix]

Phoronix: Major Open-Source Code Drop For XvBA, PowerVR Coming

Still trying to grasp the situation, but as I tweeted yesterday, there's some big news to deliver today beyond the AMD Llano launch. This news is that a lot of VA-API and XvBA related Linux video code is being opened up by Splitted Desktop Systems. There's also a PowerVR VA-API driver to be opened...

http://www.phoronix.com/vr.php?view=OTU2Ng

[d2kx]

So the open source version has less functionality and development for at least xvba-video is coming to an end. I fully support Gwenolé Beauchesne, he did amazing things and will probably do amazing things in his future job, but that's hardly good news for (AMD) users. Wish we had proper VDPAU support with radeon already.

[droidhacker]

So... open source wrapper for a binary blob rather than a binary wrapper for a binary blob. How does this help to get rid of the binary blob?

Answer: it doesn't.



Boring.....

[Nille]

Q is this now the big OSS Release?

[gbeauche]

Phoronix: Major Open-Source Code Drop For XvBA, PowerVR Coming

Still trying to grasp the situation, but as I tweeted yesterday, there's some big news to deliver today beyond the AMD Llano launch. This news is that a lot of VA-API and XvBA related Linux video code is being opened up by Splitted Desktop Systems. There's also a PowerVR VA-API driver to be opened...

http://www.phoronix.com/vr.php?view=OTU2Ng

Wrt. the PVR release, this is unrelated to the SDS work. It's just that I wanted to push {xvba,vdpau}-video to fd.o, then also move the current i965_drv_video out of the main libva/ tree to a dedicated repository. Since this impacted Intel people too, I notified them and Austin asked me to help them create a repository for pvr-driver too. The reason why is because doing so (creating fd.o repositories) turns out to incur a certain delay, so starting early is not a bad idea. There is also another candidate open source driver for VA-API but I didn't have the time to notify that (non-Intel) person either.

This bug was a means to say, "different parties want to make the media experience look good on Linux desktop (and others) and want to publish sources to various VA-API drivers. How can we proceed?". e.g. what top-level hierarchy to use, how to better organize the bug reporting system, etc.

Concerning the actual Intel intends on PVR you probably will have to wait further. I would say I don't know for sure what's going on and I would be interested to know what your sources told you earlier.

[monraaf]

What about the gstreamer-vaapi plugin? Is this now going to be moved to the gstreamer repository at freedesktop.org?

[V!NCENT]

So... open source wrapper for a binary blob rather than a binary wrapper for a binary blob. How does this help to get rid of the binary blob?

Answer: it doesn't.



Boring.....

Well if your boss is a total bitch, at least you can open source what you can, I suppose... :'P

[sirGrey]

I get errors when running make.
Libs versions mismatch it seems, maybe has to do with ffmeg git checkout.
Maybe someone had more luck , or is building packages on regular basis?

Yes, running Debian squeeze / sid.

libmpcodecs/vd_ffmpeg.c: In function 'draw_slice':
libmpcodecs/vd_ffmpeg.c:491:36: warning: unused parameter 'type' [-Wunused-parameter]
libmpcodecs/vd_ffmpeg.c: In function 'get_buffer':
libmpcodecs/vd_ffmpeg.c:610:23: error: 'AVCodecContext' has no member named 'hurry_up'
libmpcodecs/vd_ffmpeg.c:616:27: error: 'AVCodecContext' has no member named 'hurry_up'
libmpcodecs/vd_ffmpeg.c: In function 'decode':
libmpcodecs/vd_ffmpeg.c:833:10: error: 'AVCodecContext' has no member named 'hurry_up'
libmpcodecs/vd_ffmpeg.c:922:6: warning: return discards 'const' qualifier from pointer target type [enabled by default]
libmpcodecs/vd_ffmpeg.c: In function 'get_format':
libmpcodecs/vd_ffmpeg.c:1023:58: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]