Status: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport
Meeting notes: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-09-27
Highlights:
- Working on 11.10 plans
- Decision on the multimedia content licenses is still pending - TSC to provide guidance
- libjpeg-turbo - oneiric upload, 11.09 natty version released to ppa:linaro-maintainers/overlay, implemented and submitted upstream (Blueprint: https://blueprints.launchpad.net/libjpeg-turbo/+spec/engr-mm-codec-jpeg-libs...), benchmarking ltj with tjbench
- Studying dma-buf scatter list feature - useless on snowball - snowball doesn't MMU on hw IP. Could use something like sg_is_last() or sg_is_chain() to say that there is only one piece of memory in the scatterlist, but the idea for using scatterlist is that the API should handle both cases - both devices that need contiguous and those that don't
- Working on the UMM testing for the Freescale i.mx5 platform
- Extracted dri2 into a separate lib for mesa (since it will be easier to extend dri2 for video). Added omap support in libdrm... still work in progress
- Testing dts decoder with gst-ffmpeg on panda and i.mx53 (mkv + dts 6ch)
- Working on the requirements for next quarter - discussion ongoing in the team taking also feedback from the rest of Linaro: * https://linaro-public.papyrs.com/public/4157/MMWG2011-UCM-FOR-ANDROID/# * https://linaro-public.papyrs.com/public/4156/MMWG2011-UMM-CAMERA-DEMO/# * UMM - split discussed between Jesse Barker and Kurt Taylor * Other requirements being looked at (missing though either blueprints or requirements in papyrs at the moment) + libpng optimization - blueprint in backlog https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmwg...
+ Better video rendering integration in UI, like X11 proposal for wayland, extended dri2
+ Audio DTS decoding - could be tricky, involves legal aspects which need to be carefully looked at, already done in libav?
+ Compressed data sound support (as in http://www.linuxplumbersconf.org/2011/ocw/proposals/633)
+ Realvideo on ARM (popular in China) - needs optimization for 720p playback, VGA is ok. Blueprint: https://blueprints.launchpad.net/linaro multimedia-project/+spec/linaro-mmwg-realvideo
+ armv6 optimizations for vp8, and 10-bit h264 optimization, both in libav - Blueprint: https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmwg...
+ Further enhancements and optimization for LJT - Blueprint: https://blueprints.launchpad.net/linaro-multimedia-project/+spec/engr-multim...
+ UCM for Android - Blueprint: https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmwg...
+ 3D video stream
+ secure streaming (like netflix)
+ audio library optimization
+ Directfb NEON optimization - Blueprint https://blueprints.launchpad.net/linaro-multimedia-project/+spec/engr-multim...
+ Audio testing - basic (Blueprint: https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmwg...) vs speech (Blueprint: https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmwg...)
Please feel free to ask any questions or let me know if you believe that something is missing
Best,
On Tue, Oct 04, 2011 at 02:42:22PM +0300, Ilias Biris wrote:
- Decision on the multimedia content licenses is still pending - TSC to
provide guidance
This was approved today.
- libjpeg-turbo - oneiric upload, 11.09 natty version released to
ppa:linaro-maintainers/overlay, implemented and submitted upstream (Blueprint: https://blueprints.launchpad.net/libjpeg-turbo/+spec/engr-mm-codec-jpeg-libs...), benchmarking ltj with tjbench
Is there any optimization (or indeed implementation) work being done here by anyone in the MMWG itself (i.e. excluding Tom)?
- Studying dma-buf scatter list feature - useless on snowball - snowball
doesn't MMU on hw IP. Could use something like sg_is_last() or sg_is_chain() to say that there is only one piece of memory in the scatterlist, but the idea for using scatterlist is that the API should handle both cases - both devices that need contiguous and those that don't
That's correct -- even if Snowball lacks an IOMMU for the hardware codecs, it should be able to use CMA to get access to a contiguous area and the dma-buf API should work for it. Who is working on this?
- Testing dts decoder with gst-ffmpeg on panda and i.mx53 (mkv + dts 6ch)
Nice -- what are the results looking like?
Please feel free to ask any questions or let me know if you believe that something is missing
Can you get the requirement laundry list polished up a little bit and sent to the TSC for feedback if any topics there look worth pursuing further into requirements?
On 5 October 2011 19:22, Christian Robottom Reis kiko@linaro.org wrote:
On Tue, Oct 04, 2011 at 02:42:22PM +0300, Ilias Biris wrote:
- Decision on the multimedia content licenses is still pending - TSC to
provide guidance
This was approved today.
- libjpeg-turbo - oneiric upload, 11.09 natty version released to
ppa:linaro-maintainers/overlay, implemented and submitted upstream (Blueprint: https://blueprints.launchpad.net/libjpeg-turbo/+spec/engr-mm-codec-jpeg-libs...), benchmarking ltj with tjbench
Is there any optimization (or indeed implementation) work being done here by anyone in the MMWG itself (i.e. excluding Tom)?
here's some comments and a question...
libjpeg-turbo is available in Oneiric, using v62 emulation. The performance improvements aren't significant at the moment. Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future. There's definitely some work coming to my mind: - package libjpeg-turbo with v8 compatibility mode enabled - test v8 emulation mode (it seems there's some functions marked as stubs, need to be confirmed) - run tjbench as part of LAVA tests to get comparisons (plain libjpeg vs ljt) - benchmark on Android platform
What's the MM WG plan for ljt? Is there some blueprints in MM WG backlog for the items I mentioned?
- Studying dma-buf scatter list feature - useless on snowball - snowball
doesn't MMU on hw IP. Could use something like sg_is_last() or sg_is_chain() to say that there is only one piece of memory in the scatterlist, but the idea for using scatterlist is that the API should handle both cases - both devices that need contiguous and those that don't
That's correct -- even if Snowball lacks an IOMMU for the hardware codecs, it should be able to use CMA to get access to a contiguous area and the dma-buf API should work for it. Who is working on this?
- Testing dts decoder with gst-ffmpeg on panda and i.mx53 (mkv + dts 6ch)
Nice -- what are the results looking like?
Please feel free to ask any questions or let me know if you believe that something is missing
Can you get the requirement laundry list polished up a little bit and sent to the TSC for feedback if any topics there look worth pursuing further into requirements? -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
libjpeg-turbo is available in Oneiric, using v62 emulation. The performance improvements aren't significant at the moment.
What are we using to measure these improvements? What is the -turbo lib being used for?
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more. At any rate, -turbo as an upstream is the only sane decision.
Who is making the choice from the Ubuntu side -- and is there a bug open for this?
There's definitely some work coming to my mind:
- package libjpeg-turbo with v8 compatibility mode enabled
- test v8 emulation mode (it seems there's some functions marked as stubs, need to be confirmed)
- run tjbench as part of LAVA tests to get comparisons (plain libjpeg vs ljt)
- benchmark on Android platform
Agreed. And you could tack onto this optimizing any other routines that are not currently NEON optimized and worth it.
What's the MM WG plan for ljt? Is there some blueprints in MM WG backlog for the items I mentioned?
Same question here!
On 5 October 2011 18:35, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more.
There is no benefit to v8. v7 added support for the rarely/never used arithmetic coding option, left out of earlier versions due to patent issues. Since nobody uses this mode, supporting it is irrelevant. v8 only adds some experimental, non-standard coding options even less relevant to any real-world uses. What is relevant is, however, that v8 is significantly slower than v6 in the default configuration. I don't remember if this slowdown was present already in v7.
At any rate, -turbo as an upstream is the only sane decision.
Agreed.
On 6 October 2011 00:43, Mans Rullgard mans.rullgard@linaro.org wrote:
On 5 October 2011 18:35, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more.
There is no benefit to v8. v7 added support for the rarely/never used arithmetic coding option, left out of earlier versions due to patent issues. Since nobody uses this mode, supporting it is irrelevant. v8 only adds some experimental, non-standard coding options even less relevant to any real-world uses. What is relevant is, however, that v8 is significantly slower than v6 in the default configuration. I don't remember if this slowdown was present already in v7.
According to Bill Allombert, v8 support more image format and provide a higher image quality. There's probably benefit to v8 if a distribution switch from v6 to v8. Though, performance is more relevant to us (point taken for v6).
At any rate, -turbo as an upstream is the only sane decision.
Agreed.
-- Mans Rullgard / mru
On 6 October 2011 06:44, Fathi Boudra fathi.boudra@linaro.org wrote:
On 6 October 2011 00:43, Mans Rullgard mans.rullgard@linaro.org wrote:
On 5 October 2011 18:35, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more.
There is no benefit to v8. v7 added support for the rarely/never used arithmetic coding option, left out of earlier versions due to patent issues. Since nobody uses this mode, supporting it is irrelevant. v8 only adds some experimental, non-standard coding options even less relevant to any real-world uses. What is relevant is, however, that v8 is significantly slower than v6 in the default configuration. I don't remember if this slowdown was present already in v7.
According to Bill Allombert, v8 support more image format
Yes, v8 (and v7) supports the arithmetic coding mode defined in the JPEG spec. Since nobody ever uses this, it is not important. If you mean more non-JPEG formats are supported by the cjpeg/djpeg tools, that is of little importance since nobody uses those in "production" either.
and provide a higher image quality.
Maybe. I have not seen any tests to substantiate this claim. When *decoding* v8 actually produces poorer results in some cases due to using dct-based upscaling of chroma planes (this is also the cause of the slowdown).
There's probably benefit to v8 if a distribution switch from v6 to v8.
Distributions sometimes do things without good reasons.
On Thu, Oct 6, 2011 at 7:28 AM, Mans Rullgard mans.rullgard@linaro.org wrote:
On 6 October 2011 06:44, Fathi Boudra fathi.boudra@linaro.org wrote:
On 6 October 2011 00:43, Mans Rullgard mans.rullgard@linaro.org wrote:
On 5 October 2011 18:35, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more.
There is no benefit to v8. v7 added support for the rarely/never used arithmetic coding option, left out of earlier versions due to patent issues. Since nobody uses this mode, supporting it is irrelevant. v8 only adds some experimental, non-standard coding options even less relevant to any real-world uses. What is relevant is, however, that v8 is significantly slower than v6 in the default configuration. I don't remember if this slowdown was present already in v7.
According to Bill Allombert, v8 support more image format
Yes, v8 (and v7) supports the arithmetic coding mode defined in the JPEG spec. Since nobody ever uses this, it is not important. If you mean more non-JPEG formats are supported by the cjpeg/djpeg tools, that is of little importance since nobody uses those in "production" either.
and provide a higher image quality.
Maybe. I have not seen any tests to substantiate this claim. When *decoding* v8 actually produces poorer results in some cases due to using dct-based upscaling of chroma planes (this is also the cause of the slowdown).
There's probably benefit to v8 if a distribution switch from v6 to v8.
Distributions sometimes do things without good reasons.
And it seems it's not yet clear for distro maintainers which libjpeg is the best one to use. A few projects already use it by default, like Firefox, Chromium, Fedora, but it seems we still need to prove the benefits by showing the numbers across platforms.
Would like to have at least one session for this topic at UDS, comparing the results and discussing Debian's plans, so we can agree and try the transition as soon P cycle starts.
Cheers,
On Thu, Oct 06, 2011 at 08:44:01AM +0300, Fathi Boudra wrote:
On 6 October 2011 00:43, Mans Rullgard mans.rullgard@linaro.org wrote:
On 5 October 2011 18:35, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more.
There is no benefit to v8. v7 added support for the rarely/never used arithmetic coding option, left out of earlier versions due to patent issues. Since nobody uses this mode, supporting it is irrelevant. v8 only adds some experimental, non-standard coding options even less relevant to any real-world uses. What is relevant is, however, that v8 is significantly slower than v6 in the default configuration. I don't remember if this slowdown was present already in v7.
According to Bill Allombert, v8 support more image format and provide a higher image quality.
I really question this statement based on what Mans and Darrell have both said (a number of times now). Where is the hard data that shows this is true?
On 6 October 2011 17:30, Christian Robottom Reis kiko@linaro.org wrote:
According to Bill Allombert, v8 support more image format and provide a higher image quality.
I really question this statement based on what Mans and Darrell have both said (a number of times now). Where is the hard data that shows this is true?
I'll try to get more information. Though I'm not biased, I want the benchmark results publicly available as well :)
On Thu, Oct 6, 2011 at 9:30 AM, Christian Robottom Reis kiko@linaro.org wrote:
On Thu, Oct 06, 2011 at 08:44:01AM +0300, Fathi Boudra wrote:
On 6 October 2011 00:43, Mans Rullgard mans.rullgard@linaro.org wrote:
On 5 October 2011 18:35, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more.
There is no benefit to v8. v7 added support for the rarely/never used arithmetic coding option, left out of earlier versions due to patent issues. Since nobody uses this mode, supporting it is irrelevant. v8 only adds some experimental, non-standard coding options even less relevant to any real-world uses. What is relevant is, however, that v8 is significantly slower than v6 in the default configuration. I don't remember if this slowdown was present already in v7.
According to Bill Allombert, v8 support more image format and provide a higher image quality.
I really question this statement based on what Mans and Darrell have both said (a number of times now). Where is the hard data that shows this is true?
Sounds like there needs to be a discussion with Bill. I would be interested how he is measuring image "quality.
-- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs
On 6 October 2011 16:41, Tom Gall tom.gall@linaro.org wrote:
On Thu, Oct 6, 2011 at 9:30 AM, Christian Robottom Reis kiko@linaro.org wrote:
On Thu, Oct 06, 2011 at 08:44:01AM +0300, Fathi Boudra wrote:
On 6 October 2011 00:43, Mans Rullgard mans.rullgard@linaro.org wrote:
On 5 October 2011 18:35, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more.
There is no benefit to v8. v7 added support for the rarely/never used arithmetic coding option, left out of earlier versions due to patent issues. Since nobody uses this mode, supporting it is irrelevant. v8 only adds some experimental, non-standard coding options even less relevant to any real-world uses. What is relevant is, however, that v8 is significantly slower than v6 in the default configuration. I don't remember if this slowdown was present already in v7.
According to Bill Allombert, v8 support more image format and provide a higher image quality.
I really question this statement based on what Mans and Darrell have both said (a number of times now). Where is the hard data that shows this is true?
Sounds like there needs to be a discussion with Bill. I would be interested how he is measuring image "quality.
IIRC v7 or v8 made some changes to the quantisation, which could in theory improve quality at a set target size. I haven't done any tests myself so I can't say if it works as intended. Also, what improves one image might degrade another. On top of that, image quality is very subjective and hard to measure. A change improving a metric like PSNR can very well decrease subjective visual quality.
On 5 October 2011 20:35, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 08:09:03PM +0300, Fathi Boudra wrote:
libjpeg-turbo is available in Oneiric, using v62 emulation. The performance improvements aren't significant at the moment.
What are we using to measure these improvements? What is the -turbo lib being used for?
We use tjbench to measure the improvements. The browsers (firefox/chromium) is a use case mentioned on the roadmap but I didn't have seen any results. Tom knows more.
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more. At any rate, -turbo as an upstream is the only sane decision.
Who is making the choice from the Ubuntu side -- and is there a bug open for this?
Bill Allombert is libjpeg Debian maintainer. At the moment, Ubuntu is following Debian. There isn't any bug open as the transition didn't started yet.
There's definitely some work coming to my mind:
- package libjpeg-turbo with v8 compatibility mode enabled
- test v8 emulation mode (it seems there's some functions marked as stubs,
need to be confirmed)
- run tjbench as part of LAVA tests to get comparisons (plain libjpeg vs ljt)
- benchmark on Android platform
Agreed. And you could tack onto this optimizing any other routines that are not currently NEON optimized and worth it.
What's the MM WG plan for ljt? Is there some blueprints in MM WG backlog for the items I mentioned?
Same question here!
On Thu, Oct 06, 2011 at 09:07:19AM +0300, Fathi Boudra wrote:
What are we using to measure these improvements? What is the -turbo lib being used for?
We use tjbench to measure the improvements. The browsers (firefox/chromium) is a use case mentioned on the roadmap but I didn't have seen any results. Tom knows more.
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more. At any rate, -turbo as an upstream is the only sane decision.
Who is making the choice from the Ubuntu side -- and is there a bug open for this?
Bill Allombert is libjpeg Debian maintainer. At the moment, Ubuntu is following Debian. There isn't any bug open as the transition didn't started yet.
I think Tom and Ricardo should probably talk to Bill about it; I see this as being a very questionable move. I'd much rather move to seeing libjpeg deprecated into a libjpeg-legacy-8b package for good and -turbo become the actual system version.
On 6 October 2011 17:34, Christian Robottom Reis kiko@linaro.org wrote:
On Thu, Oct 06, 2011 at 09:07:19AM +0300, Fathi Boudra wrote:
What are we using to measure these improvements? What is the -turbo lib being used for?
We use tjbench to measure the improvements. The browsers (firefox/chromium) is a use case mentioned on the roadmap but I didn't have seen any results. Tom knows more.
Debian/Ubuntu P are going to move to libjpeg8 by default making current package obsolete in the future.
Note that when we asked Darrell about this he questioned the performance benefits of version 8. Mans probably knows more. At any rate, -turbo as an upstream is the only sane decision.
Who is making the choice from the Ubuntu side -- and is there a bug open for this?
Bill Allombert is libjpeg Debian maintainer. At the moment, Ubuntu is following Debian. There isn't any bug open as the transition didn't started yet.
I think Tom and Ricardo should probably talk to Bill about it; I see this as being a very questionable move. I'd much rather move to seeing libjpeg deprecated into a libjpeg-legacy-8b package for good and -turbo become the actual system version.
<Debian hat> I own the ITP on Debian and already talk to Bill about our plans with ljt. </Debian hat>
On Thu, Oct 06, 2011 at 05:38:06PM +0300, Fathi Boudra wrote:
I think Tom and Ricardo should probably talk to Bill about it; I see this as being a very questionable move. I'd much rather move to seeing libjpeg deprecated into a libjpeg-legacy-8b package for good and -turbo become the actual system version.
<Debian hat> I own the ITP on Debian and already talk to Bill about our plans with ljt. </Debian hat>
That's good to know. So now you can convince him to stop this madness ;-)
On 5 October 2011 17:22, Christian Robottom Reis kiko@linaro.org wrote:
On Tue, Oct 04, 2011 at 02:42:22PM +0300, Ilias Biris wrote:
- Testing dts decoder with gst-ffmpeg on panda and i.mx53 (mkv + dts 6ch)
Nice -- what are the results looking like?
The results I see are not consistent with what Feng Wei reports. I'm waiting for him to return from holiday so we can figure out what is causing the discrepancy. Despite the differences, both results show the libav dts decoder is fairly well optimised. No obvious low-hanging fruit remains.
On 5 October 2011 11:22, Christian Robottom Reis kiko@linaro.org wrote:
On Tue, Oct 04, 2011 at 02:42:22PM +0300, Ilias Biris wrote:
- Decision on the multimedia content licenses is still pending - TSC to
provide guidance
This was approved today.
Excellent!
- libjpeg-turbo - oneiric upload, 11.09 natty version released to
ppa:linaro-maintainers/overlay, implemented and submitted upstream (Blueprint:
https://blueprints.launchpad.net/libjpeg-turbo/+spec/engr-mm-codec-jpeg-libs... ),
benchmarking ltj with tjbench
Is there any optimization (or indeed implementation) work being done here by anyone in the MMWG itself (i.e. excluding Tom)?
Tom willingly jumped on this work when we didn't have anyone else and has done a great job. Mans has been advising as needed. I see no need to take it away from Tom just because he isnt officially in the MMWG.
- Studying dma-buf scatter list feature - useless on snowball - snowball
doesn't MMU on hw IP. Could use something like sg_is_last() or sg_is_chain() to say that there is only one piece of memory in the scatterlist, but the idea for using scatterlist is that the API should handle both cases - both devices that need contiguous and those that
don't
That's correct -- even if Snowball lacks an IOMMU for the hardware codecs, it should be able to use CMA to get access to a contiguous area and the dma-buf API should work for it. Who is working on this?
Jesse and I are discussing who does what, but from the mmwg I would like Benjamin to work on this, probably with someone else from his team.
- Testing dts decoder with gst-ffmpeg on panda and i.mx53 (mkv + dts 6ch)
Nice -- what are the results looking like?
Please feel free to ask any questions or let me know if you believe that something is missing
Can you get the requirement laundry list polished up a little bit and sent to the TSC for feedback if any topics there look worth pursuing further into requirements?
There are only 3 left from the list that are bounded enough to consider: 1) Compressed data api into ALSA - driver specific kernel work and ALSA/ASoC plumbing, prob not a good fit for mmwg yet 2) ALSA port of ST-E drivers - also prob not a good fit for mmwg, already proposed as a possible requirement for the new STG team in that mail thread 3) End to end audio tests for integration - new proposal by Alexander, blueprints are already created, investigation underway, but I can write up a papyrs page for it if we need to take it in front of the TSC
-- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 5 October 2011 17:45, Kurt Taylor kurt.taylor@linaro.org wrote:
On 5 October 2011 11:22, Christian Robottom Reis kiko@linaro.org wrote:
On Tue, Oct 04, 2011 at 02:42:22PM +0300, Ilias Biris wrote:
- Decision on the multimedia content licenses is still pending - TSC to
provide guidance
This was approved today.
Excellent!
- libjpeg-turbo - oneiric upload, 11.09 natty version released to
ppa:linaro-maintainers/overlay, implemented and submitted upstream (Blueprint:
https://blueprints.launchpad.net/libjpeg-turbo/+spec/engr-mm-codec-jpeg-libs... ),
benchmarking ltj with tjbench
Is there any optimization (or indeed implementation) work being done here by anyone in the MMWG itself (i.e. excluding Tom)?
Tom willingly jumped on this work when we didn't have anyone else and has done a great job. Mans has been advising as needed. I see no need to take it away from Tom just because he isnt officially in the MMWG.
- Studying dma-buf scatter list feature - useless on snowball - snowball
doesn't MMU on hw IP. Could use something like sg_is_last() or sg_is_chain() to say that there is only one piece of memory in the scatterlist, but the idea for using scatterlist is that the API should handle both cases - both devices that need contiguous and those that
don't
That's correct -- even if Snowball lacks an IOMMU for the hardware codecs, it should be able to use CMA to get access to a contiguous area and the dma-buf API should work for it. Who is working on this?
Jesse and I are discussing who does what, but from the mmwg I would like Benjamin to work on this, probably with someone else from his team.
- Testing dts decoder with gst-ffmpeg on panda and i.mx53 (mkv + dts
6ch)
Nice -- what are the results looking like?
Please feel free to ask any questions or let me know if you believe that something is missing
Can you get the requirement laundry list polished up a little bit and sent to the TSC for feedback if any topics there look worth pursuing further into requirements?
There are only 3 left from the list that are bounded enough to consider:
- Compressed data api into ALSA - driver specific kernel work and
ALSA/ASoC plumbing, prob not a good fit for mmwg yet 2) ALSA port of ST-E drivers - also prob not a good fit for mmwg, already proposed as a possible requirement for the new STG team in that mail thread 3) End to end audio tests for integration - new proposal by Alexander, blueprints are already created, investigation underway, but I can write up a papyrs page for it if we need to take it in front of the TSC
I went ahead and created a papyrs page for this:
https://linaro.papyrs.com/page/4778/MMWG2011-E2E-Audio-Test
-- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
--
Kurt Taylor (irc krtaylor) Linaro Multimedia Team Lead
Linaro.org http://www.linaro.org/* **│ *Open source software for ARM SoCs
Follow *Linaro: *Facebook http://www.facebook.com/pages/Linaro | Twitterhttp://twitter.com/#%21/linaroorg| Blog http://www.linaro.org/linaro-blog/
On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
Is there any optimization (or indeed implementation) work being done here by anyone in the MMWG itself (i.e. excluding Tom)?
Tom willingly jumped on this work when we didn't have anyone else and has done a great job. Mans has been advising as needed. I see no need to take it away from Tom just because he isnt officially in the MMWG.
You missed my point -- I was asking if there's any implementation work being done in the MMWG. Tom isn't going to be writing optimization code, though he will work on integration code, certainly. My question to the MMWG is whether there's anything valuable left to do in terms of optimization.
On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
There are only 3 left from the list that are bounded enough to consider:
- Compressed data api into ALSA - driver specific kernel work and ALSA/ASoC
plumbing, prob not a good fit for mmwg yet
I think this is worth sketching out. Who could actually sit down and write a good description (even if without AC) so I can share the topic.
- ALSA port of ST-E drivers - also prob not a good fit for mmwg, already
proposed as a possible requirement for the new STG team in that mail thread
They don't use ALSA at all? And wouldn't this be better done within the ST-Ericsson LT?
- End to end audio tests for integration - new proposal by Alexander,
blueprints are already created, investigation underway, but I can write up a papyrs page for it if we need to take it in front of the TSC
Hmm, this is actually already represented inside a drafted blueprint:
https://linaro.papyrs.com/page/4119/LINUX2011-ENABLEMENT-TESTING/#
Can you, Alexander and Ricardo figure out whether this should be split out?
On 6 October 2011 09:38, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
There are only 3 left from the list that are bounded enough to consider:
- Compressed data api into ALSA - driver specific kernel work and
ALSA/ASoC
plumbing, prob not a good fit for mmwg yet
I think this is worth sketching out. Who could actually sit down and write a good description (even if without AC) so I can share the topic.
- ALSA port of ST-E drivers - also prob not a good fit for mmwg, already
proposed as a possible requirement for the new STG team in that mail
thread
They don't use ALSA at all? And wouldn't this be better done within the ST-Ericsson LT?
As I understand it, they do not use ALSA. I had originally proposed it be done in the ST-E LT, but Lee proposed that it be moved to the STG team (full email thread).
- End to end audio tests for integration - new proposal by Alexander,
blueprints are already created, investigation underway, but I can write
up a
papyrs page for it if we need to take it in front of the TSC
Hmm, this is actually already represented inside a drafted blueprint:
https://linaro.papyrs.com/page/4119/LINUX2011-ENABLEMENT-TESTING/#
Excellent, I will delete my papyrs page for it then.
Can you, Alexander and Ricardo figure out whether this should be split out? -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs
On Thu, Oct 06, 2011 at 11:06:32AM -0500, Kurt Taylor wrote:
On 6 October 2011 09:38, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
There are only 3 left from the list that are bounded enough to consider:
- Compressed data api into ALSA - driver specific kernel work and
ALSA/ASoC
plumbing, prob not a good fit for mmwg yet
I think this is worth sketching out. Who could actually sit down and write a good description (even if without AC) so I can share the topic.
- ALSA port of ST-E drivers - also prob not a good fit for mmwg, already
proposed as a possible requirement for the new STG team in that mail
thread
They don't use ALSA at all? And wouldn't this be better done within the ST-Ericsson LT?
As I understand it, they do not use ALSA. I had originally proposed it be done in the ST-E LT, but Lee proposed that it be moved to the STG team (full email thread).
Right, but since STG isn't going forward as a unit of itself, we should look at this again.
On Thu, Oct 6, 2011 at 1:06 PM, Kurt Taylor kurt.taylor@linaro.org wrote:
On 6 October 2011 09:38, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
There are only 3 left from the list that are bounded enough to consider:
- Compressed data api into ALSA - driver specific kernel work and
ALSA/ASoC plumbing, prob not a good fit for mmwg yet
I think this is worth sketching out. Who could actually sit down and write a good description (even if without AC) so I can share the topic.
- ALSA port of ST-E drivers - also prob not a good fit for mmwg,
already proposed as a possible requirement for the new STG team in that mail thread
They don't use ALSA at all? And wouldn't this be better done within the ST-Ericsson LT?
As I understand it, they do not use ALSA. I had originally proposed it be done in the ST-E LT, but Lee proposed that it be moved to the STG team (full email thread).
Hm, it also sounds more related with the ST-E LT than STG, even now that the LT is fully back.
- End to end audio tests for integration - new proposal by Alexander,
blueprints are already created, investigation underway, but I can write up a papyrs page for it if we need to take it in front of the TSC
Hmm, this is actually already represented inside a drafted blueprint:
https://linaro.papyrs.com/page/4119/LINUX2011-ENABLEMENT-TESTING/#
Excellent, I will delete my papyrs page for it then.
Great, and this is something we'll need to work together (Platform, MMWG and Validation), but it's ok for the Platform to lead it.
Cheers,
On Thu, Oct 06, 2011 at 11:38:35AM -0300, Christian Robottom Reis wrote:
On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
There are only 3 left from the list that are bounded enough to consider:
- Compressed data api into ALSA - driver specific kernel work and ALSA/ASoC
plumbing, prob not a good fit for mmwg yet
I think this is worth sketching out. Who could actually sit down and write a good description (even if without AC) so I can share the topic.
Note that there's already an API from Intel which people are relatively happy with, it mostly just needs some fettling for kernel integration - after that it's just a realtively straightforward integration question, more or less.
On Thu, Oct 06, 2011 at 06:44:43PM +0100, Mark Brown wrote:
On Thu, Oct 06, 2011 at 11:38:35AM -0300, Christian Robottom Reis wrote:
On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
There are only 3 left from the list that are bounded enough to consider:
- Compressed data api into ALSA - driver specific kernel work and ALSA/ASoC
plumbing, prob not a good fit for mmwg yet
I think this is worth sketching out. Who could actually sit down and write a good description (even if without AC) so I can share the topic.
Note that there's already an API from Intel which people are relatively happy with, it mostly just needs some fettling for kernel integration - after that it's just a realtively straightforward integration question, more or less.
Shouldn't we get involved in this early so that anything which doesn't fit our SoCs well gets addressed in the design phase?
On Fri, Oct 07, 2011 at 12:43:02PM -0300, Christian Robottom Reis wrote:
On Thu, Oct 06, 2011 at 06:44:43PM +0100, Mark Brown wrote:
Note that there's already an API from Intel which people are relatively happy with, it mostly just needs some fettling for kernel integration - after that it's just a realtively straightforward integration question, more or less.
Shouldn't we get involved in this early so that anything which doesn't fit our SoCs well gets addressed in the design phase?
So, I'm actually nothing to do with Linaro - just keeping an eye on this list from an ALSA upstream PoV.
On Fri, Oct 07, 2011 at 08:20:00PM +0100, Mark Brown wrote:
On Fri, Oct 07, 2011 at 12:43:02PM -0300, Christian Robottom Reis wrote:
On Thu, Oct 06, 2011 at 06:44:43PM +0100, Mark Brown wrote:
Note that there's already an API from Intel which people are relatively happy with, it mostly just needs some fettling for kernel integration - after that it's just a realtively straightforward integration question, more or less.
Shouldn't we get involved in this early so that anything which doesn't fit our SoCs well gets addressed in the design phase?
So, I'm actually nothing to do with Linaro - just keeping an eye on this list from an ALSA upstream PoV.
I know; I'm asking the wider question to linaro-dev ;-)
-
Christian Robottom Reis -
Christian Robottom Reis -
Fathi Boudra -
Ilias Biris -
Kurt Taylor -
Mans Rullgard -
Mark Brown -
Ricardo Salveti -
Tom Gall