[yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback
Hi All, We are having some problem regarding gstreamer Vaapi Plugin would like to discuss. We are using gstreamer0.10.36 for our 1080p mp4 playback and we have used following gstraemer pipeline. filesrc- decodebin-queue-ffmpegcolorspace-xvimagesink Here we are facing lot of buffer drop and video is displaying like slow motion so, we think that may be xvimagesink is not using the video acceleration provided by Intel, hence we moved to vaapivideosink. However we found the following error while using vaapivideosink libva: VA-API version 0.32.0 libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/dri/i965_drv_video.so libva: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit Even the same error we are getting while doing 'vainfo' also. We have gone through some INTERNET search, but did't find useful informations. Basically we have 2 quires 1. Is it possible to play 1080p mp4 playback with software decoders smoothly ? How we will fix buffer drop issue ? 2. How we will use vaapi sink in other case (solving the va_openDriver() error)? Do we need to rebuild some other vaapi versions to make it work ? Our platform information: a. Intel-E3800 Baytrail b. Yocto Dora build c. Base Kernel Linux Baytrail32 3.8.0-yocto standard Thanks in advance. Thanks Regards, Meena ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback
Hi Meena, On Thu, Mar 27, 2014 at 06:58:53AM +, Meenakumari Shedole wrote: Hi All, We are having some problem regarding gstreamer Vaapi Plugin would like to discuss. We are using gstreamer0.10.36 for our 1080p mp4 playback and we have used following gstraemer pipeline. filesrc- decodebin-queue-ffmpegcolorspace-xvimagesink Here we are facing lot of buffer drop and video is displaying like slow motion so, we think that may be xvimagesink is not using the video acceleration provided by Intel, hence we moved to vaapivideosink. However we found the following error while using vaapivideosink libva: VA-API version 0.32.0 libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/dri/i965_drv_video.so libva: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit Even the same error we are getting while doing 'vainfo' also. We have gone through some INTERNET search, but did't find useful informations. Basically we have 2 quires 1. Is it possible to play 1080p mp4 playback with software decoders smoothly ? How we will fix buffer drop issue ? 2. How we will use vaapi sink in other case (solving the va_openDriver() error)? Do we need to rebuild some other vaapi versions to make it work ? I'm far from an expert in gstreamer but I used it once in a while to test intel video driver upgrades. Here's the pipeline I use: gst-launch filesrc location=./sintel_trailer-720p.mp4 ! qtdemux name=demuxer demuxer.video_00 ! vaapidecode ! vaapisink fullscreen=true I don't remember where I got this pipeline from but... maybe it works for you too. Perhaps others can give you a more in-depth explanation. laurentiu Our platform information: a. Intel-E3800 Baytrail b. Yocto Dora build c. Base Kernel Linux Baytrail32 3.8.0-yocto standard Thanks in advance. Thanks Regards, Meena ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Features in Yocto Project 1.7
On 2014-03-25 15:31, David Nyström wrote: On 2014-03-24 17:00, Richard Purdie wrote: As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle. I think from my perspective, in 1.7 I'd like to see us looking at Developer Workflow. Its a generic topic which I think covered multiple areas (in no particular order): * the ADT/SDK and how it intergrates into the rest of the system * toaster * python devshell * exteralsrc.bbclass * memory resident bitbake * how a standalone app developer might build an image +1 My wishlist: 1. Assembly of an image from a package repository using the SDK. 2. Ability to easily package multiple kernel flavours(builds with different kernel configs) with linux related bbclass:es. 3. layer based repository splitting. -- When having multiple users of a base repository. Ease management of customized repos, by having he ability to mark layers as split layers, this would yield a separate repo per split layer, which would contain packages modified/created by this layer. Said packages would also be built for the base repo, but without split-layer modifications. A customized distro would use a compound of the base repo + split repo, where the split repo would have higher priority. I guess this could mean one deploy directory per split-layer. Br, David Br, David * locked sstate and probably more I'm forgetting. If anyone does have things they plan to work on, or ideas for things that should be worked on, please do file enhancement requests in the bugzilla: https://bugzilla.yoctoproject.org/ Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] matchbox-terminal and function keys
On 27 March 2014 05:50, Stuart Longland stua...@vrt.com.au wrote: The terminal reports itself as TERM=xterm. When I do a `cat`, I observe that matchbox-terminal is reporting F1-F5 using VT100 terminal sequences, but F6-F10 using VT220 sequences. If I set TERM=vt100, I get F1-F5 working, but unfortunately, I need F10 as well. So the terminal that matchbox-terminal emulates is neither a VT100 nor a VT220 (or the superset it claims to be: xterm), but a confused mix of the two. Can you paste the output of cat to confirm the values you're seeing? The xterm guide says VT100 for F1-F4 (as VT100 doesn't define F5 onwards) and VT220 for F5-F10 and that's what I'm seeing when I attempt this (F10 specifically being ^[[21~). Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On 26 March 2014 22:12, Burton, Ross ross.bur...@intel.com wrote: On 26 March 2014 22:04, Khem Raj raj.k...@gmail.com wrote: There were interest in other threads in having musl as an alternative to eglibc/uclibc that we already have in OE, in that direction I have poured in my on and off work and put it into a contrib tree Blimey Khem that was quick. :) Agreed! I wonder if it's worth splitting this out into its own layer though (with fixes done via bbappends) so that it's easy for multiple people to contribute to. It would also mean it doesn't need rebasing onto master all the time. I'd definitely like to get involved with this. In particular I can ensure opkg (both current release and development branch) work with musl and see if some of my preferred software from meta-oe will build (vim, htop, etc). Many thanks, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback
On 27 March 2014 06:58, Meenakumari Shedole meenakumar...@hcl.com wrote: filesrc- decodebin-queue-ffmpegcolorspace-xvimagesink Try just using playbin2 instead of constructing a pipeline manually, there's lot of smarts that you'll need to do manually otherwise. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-autobuilder][PATCH] nightly-deb/ipk: don't use the default tests
We can't use RunSanityTests as it is because the default
test suites (which are defined in testimage.bbclass) include rpm and smart.
Anything included in TEST_SUITES is a mandatory test and will be a fail in this
buildset as obviously this images don't have rpm/smart.
Also we can't use 'ping auto' either (which will run all the tests suitable for
the image),
because for core-image-sato-sdk that will run cvs/iptables/sudoku build tests
which
take a long time (and we have another buildset nightly-qa-targetbuild for that)
so we need
to hardcode the list of tests - the same as the defaults for a rpm
core-image-sato-sdk,
minus rpm and smart (and without smart this RunSanity will take half of the
time)
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
buildset-config.master/nightly-deb.conf | 6 +-
buildset-config.master/nightly-ipk.conf | 6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/buildset-config.master/nightly-deb.conf
b/buildset-config.master/nightly-deb.conf
index 648401b..7ed5eed 100644
--- a/buildset-config.master/nightly-deb.conf
+++ b/buildset-config.master/nightly-deb.conf
@@ -15,5 +15,9 @@ steps: [{'SetDest':{}},
{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
{'SyncPersistDB' : {'distro' : 'poky'}},
{'BuildImages': {'images': 'core-image-sato core-image-sato-dev
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
-{'RunSanityTests': {'images': 'core-image-minimal core-image-sato
core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-minimal'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686',
'distro': 'poky', 'buildhistory' : True, 'packages': 'ipk'}},
+{'RunSanityTests': {'images' 'core-image-sato', 'suites' : 'ping ssh
auto'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686',
'distro': 'poky', 'buildhistory' : True, 'packages': 'ipk'}},
+{'RunSanityTests': {'images' : 'core-image-sato-sdk', 'suites' : 'ping
ssh df connman syslog xorg scp vnc date perl ldd gcc kernelmodule dmesg
python'}},
{'SyncPersistDB' : {'commit' : True, 'distro':'poky'}}]
diff --git a/buildset-config.master/nightly-ipk.conf
b/buildset-config.master/nightly-ipk.conf
index bf7c613..c96d098 100644
--- a/buildset-config.master/nightly-ipk.conf
+++ b/buildset-config.master/nightly-ipk.conf
@@ -15,5 +15,9 @@ steps: [{'SetDest':{}},
{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
{'SyncPersistDB' : {'distro' : 'poky'}},
{'BuildImages': {'images': 'core-image-sato core-image-sato-dev
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
-{'RunSanityTests': {'images': 'core-image-minimal core-image-sato
core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-minimal'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686',
'distro': 'poky', 'buildhistory' : True, 'packages': 'ipk'}},
+{'RunSanityTests': {'images' 'core-image-sato', 'suites' : 'ping ssh
auto'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686',
'distro': 'poky', 'buildhistory' : True, 'packages': 'ipk'}},
+{'RunSanityTests': {'images' : 'core-image-sato-sdk', 'suites' : 'ping
ssh df connman syslog xorg scp vnc date perl ldd gcc kernelmodule dmesg
python'}},
{'SyncPersistDB' : {'commit' : True, 'distro':'poky'}}]
--
1.8.5.3
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] --conf Was: Features in Yocto Project 1.7
Excellent information! Thanks for all the workflow examples, this is great. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-autobuilder][PATCH] buildsets: nightly-qa-targetbuilds: remove the mips build
The build tests for iptables/cvs/sudoku take too much time on qemumips
and usually buildbot ends up killing the step as it hits the timeout,
so we should drop them.
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
buildset-config.master/nightly-qa-targetbuilds.conf | 3 ---
1 file changed, 3 deletions(-)
diff --git a/buildset-config.master/nightly-qa-targetbuilds.conf
b/buildset-config.master/nightly-qa-targetbuilds.conf
index a95db78..96ec7f8 100644
--- a/buildset-config.master/nightly-qa-targetbuilds.conf
+++ b/buildset-config.master/nightly-qa-targetbuilds.conf
@@ -20,7 +20,4 @@ steps: [{'SetDest':{}},
{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping
ssh buildsudoku buildcvs buildiptables'}},
{'CreateAutoConf': {'machine': 'qemuppc', 'SDKMACHINE' : 'x86_64',
'distro': 'poky'}},
{'BuildImages': {'images': 'core-image-sato-sdk'}},
-{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping
ssh buildsudoku buildcvs buildiptables'}},
-{'CreateAutoConf': {'machine': 'qemumips', 'SDKMACHINE' : 'x86_64',
'distro': 'poky'}},
-{'BuildImages': {'images': 'core-image-sato-sdk'}},
{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping
ssh buildsudoku buildcvs buildiptables'}}]
--
1.8.5.3
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] matchbox-terminal and function keys
Hi Ross, On 27/03/14 22:27, Burton, Ross wrote: Can you paste the output of cat to confirm the values you're seeing? The xterm guide says VT100 for F1-F4 (as VT100 doesn't define F5 onwards) and VT220 for F5-F10 and that's what I'm seeing when I attempt this (F10 specifically being ^[[21~). Well, evidently the ncurses devs didn't get that memo as F1-F5 aren't recognised when TERM=xterm. I understood xterm was a superset of vt220. I'll do a `cat` to a file and post the contents when I get in. I'm just confused as to why ncurses applications don't seem to recognise F1-F5. Regards, -- Stuart Longland Contractor _ ___ \ /|_) | T: +61 7 3535 9619 \/ | \ | 38b Douglas StreetF: +61 7 3535 9699 SYSTEMSMilton QLD 4064 http://www.vrt.com.au -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] matchbox-terminal and function keys
On 28/03/14 05:57, Stuart Longland wrote: Hi Ross, On 27/03/14 22:27, Burton, Ross wrote: Can you paste the output of cat to confirm the values you're seeing? The xterm guide says VT100 for F1-F4 (as VT100 doesn't define F5 onwards) and VT220 for F5-F10 and that's what I'm seeing when I attempt this (F10 specifically being ^[[21~). Well, evidently the ncurses devs didn't get that memo as F1-F5 aren't recognised when TERM=xterm. I understood xterm was a superset of vt220. I'll do a `cat` to a file and post the contents when I get in. I'm just confused as to why ncurses applications don't seem to recognise F1-F5. Okay, I've done a `cat` of the respective keys: root@xg100:~# hexdump -C /tmp/fn 1b 4f 50 1b 4f 51 1b 4f 52 1b 4f 53 1b 5b 31 35 |.OP.OQ.OR.OS.[15| 0010 7e 1b 5b 31 37 7e 1b 5b 31 38 7e 1b 5b 31 39 7e |~.[17~.[18~.[19~| 0020 1b 5b 32 30 7e 1b 5b 32 31 7e 0a |.[20~.[21~.| So it indeed is sending those key commands. I've discovered that if I set TERM=xterm-xfree86, things work so evidently the ncurses here has something funny with its 'xterm' terminfo entry. Is there a way to override the terminal type set by matchbox-terminal? Regards, -- Stuart Longland Systems Engineer _ ___ \ /|_) | T: +61 7 3535 9619 \/ | \ | 38b Douglas StreetF: +61 7 3535 9699 SYSTEMSMilton QLD 4064 http://www.vrt.com.au -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Reducing nightly/release build artifacts.
Hi Beth, 于 2014年03月27日 05:30, Flanagan, Elizabeth 写道: A list of exactly what files you use for QA would be grand. We can use http://autobuilder.yoctoproject.org/pub/nightly/20140326-1/ as our base. We don't use all qemu-lsb , beagleboard-lsb, routerstationpro-lsb, and p1022ds-lsb artifacts. For the image type, we don't need minimal-dev and sato-dev. Thanks, Yi -b On Wed, Mar 26, 2014 at 2:22 PM, Otavio Salvador ota...@ossystems.com.br wrote: Hello Beth, On Wed, Mar 26, 2014 at 6:14 PM, Flanagan, Elizabeth elizabeth.flana...@intel.com wrote: I'd like to start looking at reducing the number of artifacts we're releasing both for our nightly builds (which is at 250,000 artifacts and .25 TB!) and releases. What I'm thinking is this: Reduce nightly: - Reduce ADT-REPO to just qemu* arches for all builds - If every QA team could provide me a list of what files they actually need I could reduce the published artifacts to *just* what is needed. Reduce releases: - Reduce ADT-REPO to just qemu - Don't release ipk/rpm/debs. Continue to release ipks through ADT - Don't release machines outside of BSP tarball /binary directory If folks who do QA could get me a list of all the files they use, we can start removing excess artifacts. I know this is a balance, but I'd really like us to start targeting our release artifacts to just the things we need. I fully agree on that. Is there anything you need specifically from me? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
