[davilla]

There are a few ways to handle hw decode depending on how integrated the hw decoders are.

If the audio and video hw decoders are tied together via a common pts clock, then the best way to handle this is with a new internal player (aka what dvdplayer does). It's just too hard to try to integrate this into the existing dvdplayer model. Take a look at what boxee had to do for the intel cex41xx. Icky, icky, ifdef city.

If the video hw decoder can run standalone, then clone crystalhd, vda or vtb. Those are all hw video codecs that dvdplayer can use. One thing to note is that to fit the dvdplayer model, you must be able to drop picture frames or dvdplayer will not be able to keep sync with audio...

You can either pass up decoded picture frames or you can 'bypass' this by various means, iOS does a 'bypass' using a opaque corevideoref which is rendered in LinuxRendererGLES.

Another swing point is, are hw decoded pictures auto-rendered on a separate video plane or are they just decoded to argb/yuv and then GLES needs to render it. GLES shader convert of yuv to argb can be very slow depending on GPU, so you might have to use neon to do a yuv to argb. There's existing code to do that (for iOS).

If you are really serious about this, please create a new thread in the development section of the xbmc forums. I'm sure others will chime in.

I've worked on a few 'embedded' flavors of xbmc. iOS is one, sigma is another and there are a few more than I can't talk about yet. Some use a hw decoder together with the dvdplayer model, others have dvdplayer replaced with a custom internal player to handle the hw playback details. If I would know more about exactly what panda can do with respect to hw video decode, then I can point you into the right direction.

[RockerC]

Would it not be best to try to utilize existing API standard for video acceleration like VAAPI or OpenMAX as much as possible?

Doesn't XBMC already support both VAAPI and OpenMAX?
http://www.freedesktop.org/wiki/Software/vaapi
http://www.khronos.org/openmax/

If that is the case, could you perhaps not write your own VAAPI or OpenMAX backend drivers and headers whenever the hardware manufacturer does not supply official support for these but instead only offer their own non-standard video acceleration method?

If you could do that then way XBMC's video players would maybe only have to support a few of the existing API standards instead of having direct support for all different types of video acceleration hardware using their own unique methods?

Any such backend drivers and headers that you write could then also be used by other open source projects who already support VAAPI or OpenMAX?


In related news to this there is now a new VAAPI backend design that is primarily made for ARM devices. Haihao Xiang from Intel recently published a branch of VAAPI with a VA/EGL backend. This new vaapi-egl driver is a generic implementation for VAAPI with EGL and then there are backend drivers for Intel and PowerVR hardware support using an EGL display with OpenGL ES rather than GLX/OpenGL such as the normal VAAPI

http://lists.freedesktop.org/archives/li...00717.html
http://cgit.freedesktop.org/libva/log/?h=vaapi-egl

[robclark]

Would it not be best to try to utilize existing API standard for video acceleration like VAAPI or OpenMAX as much as possible?

Doesn't XBMC already support both VAAPI and OpenMAX?
http://www.freedesktop.org/wiki/Software/vaapi
http://www.khronos.org/openmax/

If that is the case, could you perhaps not write your own VAAPI or OpenMAX backend drivers and headers whenever the hardware manufacturer does not supply official support for these but instead only offer their own non-standard video acceleration method?

It is, maybe, an option. We did used to support OpenMAX, but I'm not personally a big fan of the API.. and I expect it would turn into #ifdef city to support different OMX implementations without breaking existing platforms. And would be a bigger task that adding support for the native codec API.

VAAPI might be an option. I like the fact that it encompasses video mixing/rendering, although will have to take a closer look at how XBMC utilizes this. The big annoyance that I see so far with VAAPI is that it is just a VLD level decoder, but our decoders want the entire elementary bitstream (including things like SPS/PPS in h264, and equivalent in other formats). At least the advantage with VAAPI is it is more widely supported on linux than OMX.

In the end, the decoder is the easy part. And there is stuff like https://github.com/topfs2/xbmc/commits/gstreamer if we wanted to use a standard API. The bigger question is how to handle the rendering efficiently..

If you could do that then way XBMC's video players would maybe only have to support a few of the existing API standards instead of having direct support for all different types of video acceleration hardware using their own unique methods?

Any such backend drivers and headers that you write could then also be used by other open source projects who already support VAAPI or OpenMAX?


In related news to this there is now a new VAAPI backend design that is primarily made for ARM devices. Haihao Xiang from Intel recently published a branch of VAAPI with a VA/EGL backend. This new vaapi-egl driver is a generic implementation for VAAPI with EGL and then there are backend drivers for Intel and PowerVR hardware support using an EGL display with OpenGL ES rather than GLX/OpenGL such as the normal VAAPI

http://lists.freedesktop.org/archives/li...00717.html
http://cgit.freedesktop.org/libva/log/?h=vaapi-egl

vaapi-egl could be interesting.. does XBMC support this already? I guess it shouldn't be too big a change. I'll look more closely at how rendering is handled in vaapi decode case..

[davilla]

We supported a small subset of OpenMAX with respect to hw video decode for tegra2. I'm not sure how current that code is anymore, I've not worked on tegra2 since eons ago.

The main issue with omx is, moving decoded picts from omx into our renderer to fit the 'dvdplayer' model. Also some omx implementations want to also handle the rendering and that's where things get complicated with respect to retaining the 'dvdplayer' model.

topfs2's gstreamer only handles video decode and is more a proof of concept. I've done a complete internal gstplayer for another project, unfortunately that code cannot be made public yet.

Make no bones about it, gstreamer is a bitch and openmax is even more of a bitch. Neither is a simple API and both have pitfalls that you have to deal with. It's non-trivial.

As for vaapi-egl, I've not seen anything yet that does hw video decode on arm, only x86 (yes, they can run gles as in cex41xx)

[robclark]

We supported a small subset of OpenMAX with respect to hw video decode for tegra2. I'm not sure how current that code is anymore, I've not worked on tegra2 since eons ago.

The main issue with omx is, moving decoded picts from omx into our renderer to fit the 'dvdplayer' model. Also some omx implementations want to also handle the rendering and that's where things get complicated with respect to retaining the 'dvdplayer' model.

well, whatever approach is chosen, I think the rendering is where things get complicated..

The ideal scenario would let the render allocate YUV buffers for the decoder to decode into, and rest of XBMC would hand the GUI (ARGB) and video (YUV) to the renderer as two surfaces and let the renderer choose how to combine them. Ie. the GUI layer should have transparent/translucent pixels where the video should be.

Fwiw, I'm working on a video extension to dri2 protocol to allow this in (what I hope will be) a standard way. So the platform specific can be hidden in the x11 driver. The basic idea is to create a dri2 video drawable with a separate "OSD" drawable. The OSD drawable would be everything that isn't video, ie. subtitles, menus, etc. Ie. do something like eglCreatePixmapSurface() with the OSD drawable and render the GUI to that surface. Meanwhile the video rendering logic would (independently of GUI rendering) do DRI2SwapBuffers on the primary dri2 video drawable. The platform specific x11 driver could decide whether to combine the two layers w/ hw video overlay, GPU, etc. This would let us use hw overlays on platforms that support them (advantage: higher quality scaling and better performance) without apps like XBMC being too aware of it. (Fwiw, things like VDPAU video mixer could be implemented on top of this mechanism.)

topfs2's gstreamer only handles video decode and is more a proof of concept. I've done a complete internal gstplayer for another project, unfortunately that code cannot be made public yet.

Make no bones about it, gstreamer is a bitch and openmax is even more of a bitch. Neither is a simple API and both have pitfalls that you have to deal with. It's non-trivial.

well, gst is not too bad.. although at least the way topfs2 is using it is not really what it is intended for. It is a bit too high level for just a simple decoder interface, but if you are using it for entire pipeline building it is nice. (Or at least most of the shortcomings from my point of view are solved on 0.11/1.0 branch.) It already provides a nice plugin API, handles auto-pipeline construction (playbin2), and is supported on a lot of platforms.

Better gst support in XBMC would be well appreciated in the SoC world, I think. I would be a bit interested in how video rendering is handled in your gst player and some idea if/when you think that will be public (if that is information you could share).

As for vaapi-egl, I've not seen anything yet that does hw video decode on arm, only x86 (yes, they can run gles as in cex41xx)

Well.. at least with vaapi-egl, I could implement a backend for omap/arm. There are some niggles with how the API works compared to our hardware, which I've pointed out before. But nothing that isn't solveable. But we already have pretty good gst support and being able to re-use that would be the ideal scenario.

[davilla]

Better gst support in XBMC would be well appreciated in the SoC world, I think. I would be a bit interested in how video rendering is handled in your gst player and some idea if/when you think that will be public (if that is information you could share).

No problem there, hw video decode renders to a video plane that is below GLES. GLES does not even know it's there except for the dest rect of the video. That is blended in GLES so the video area shows through. OSD (overlays) just work No idea when it will become public, I'm not in the driver's seat regarding code release on this particular project.

Your X11 idea is interesting but that will not help most embedded where X11 is way too much overhead to tolerate.

If you look at XBMC code, you will also see a directfb implementation for GLES. That's used under sigma where like other embedded platforms, hw video decode is rendered to a video plane that is actually under the GLES layer.

[robclark]

No problem there, hw video decode renders to a video plane that is below GLES. GLES does not even know it's there except for the dest rect of the video. That is blended in GLES so the video area shows through. OSD (overlays) just work No idea when it will become public, I'm not in the driver's seat regarding code release on this particular project.

ok, interesting.. this sounds fairly similar to what I'd like to accomplish.. (tho' possibly w/ X11 in the middle.. although that may not strictly be required, but was just an idea to try and have more of a standard interface for a renderer rather than something too omap specific..)

Your X11 idea is interesting but that will not help most embedded where X11 is way too much overhead to tolerate.

just fwiw, I'm running now xbmc fullscreen, without a window manager.. in this setup, other than an extra context switch, there isn't really any runtime overhead introduced by X11. Ie. swap-buffers is just a page-flip ioctl and a pointer swap on kernel side, no extra GPU copy. That isn't necessarily the case if you are not full screen, or have a compositing window manager that doesn't bother to un-redirect fullscreen windows.

(ok, I guess there is some RAM and filesystem size footprint too.. not sure if that is what you meant..)

If you look at XBMC code, you will also see a directfb implementation for GLES. That's used under sigma where like other embedded platforms, hw video decode is rendered to a video plane that is actually under the GLES layer.

ok, cool, I'll have a poke around that bit of code over the upcoming long weekend to see if that gives me some ideas.

[phusho]

No problem there, hw video decode renders to a video plane that is below GLES. GLES does not even know it's there except for the dest rect of the video. That is blended in GLES so the video area shows through. OSD (overlays) just work No idea when it will become public, I'm not in the driver's seat regarding code release on this particular project.

Your X11 idea is interesting but that will not help most embedded where X11 is way too much overhead to tolerate.

If you look at XBMC code, you will also see a directfb implementation for GLES. That's used under sigma where like other embedded platforms, hw video decode is rendered to a video plane that is actually under the GLES layer.

that was the same way I made it work on Telechips platform - different hardware plane

[robclark]

Fwiw, maybe in need of a bit of cleanup, but got something that is basically functional:

https://github.com/robclark/xbmc/tree/gstreamer-eglimg

What I ended up doing was add eglImage rendering support, so the decoder can pass the renderer an eglImage that can be bound to a texture. This is an alternative path to the 3x texture upload plus colorconvert in shader approach. Works fine on my pandaboard, framerate seems fine for 1080p playback on 1080p display, at least as long as the window manager doesn't get in the way and refuse to unredirect the fullscreen xbmc window (so flipping instead of blitting works).

I guess, in theory, since eglImage should be something that can be used by the renderer in a standard way, possibly the OpenMAX rendering code could be cleaned up to work in the same way. But I didn't have access to any hw on which I could test this so I left the existing OpenMAX related code as-is.

In addition to cleanup and removing debug stuff which might have gotten left, there is one remaining functional issue. The problem is that the DVDVideoCodecGStreamer instance gets deleted before the renderer. Which causes a segfault when the renderer is deleted:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x41c04110 (LWP 14210)]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x00497c10 in CLinuxRendererGLES::UnRefBuf (this=<optimized out>, index=<optimized out>) at LinuxRendererGLES.cpp:139
#2 0x00497c58 in CLinuxRendererGLES::DeleteEGLIMAGETexture (this=0x12367c0, index=0) at LinuxRendererGLES.cpp:1456
#3 0x00497334 in CLinuxRendererGLES::UnInit (this=0x12367c0) at LinuxRendererGLES.cpp:766
#4 0x00495cba in CXBMCRenderManager::UnInit (this=0x945110) at RenderManager.cpp:337
#5 0x003ac2e0 in CDVDPlayer::CloseFile (this=0x4de6b008) at DVDPlayer.cpp:416
#6 0x003ac338 in CDVDPlayer::~CDVDPlayer (this=0x4de6b008, __in_chrg=<optimized out>) at DVDPlayer.cpp:329
#7 0x003ac768 in CDVDPlayer::~CDVDPlayer (this=0x4de6b008, __in_chrg=<optimized out>) at DVDPlayer.cpp:334
#8 0x006ffe68 in CApplication::OnMessage (this=0x9445a8, message=...) at Application.cpp:4603
#9 0x0038b480 in CGUIWindowManager::SendMessage (this=0x944f58, message=...) at GUIWindowManager.cpp:77
#10 0x0038b7ce in CGUIWindowManager::DispatchThreadMessages (this=0x944f58) at GUIWindowManager.cpp:784
#11 0x006fc61c in CApplication::Process (this=0x9445a8) at Application.cpp:4705
#12 0x0075bf26 in CXBApplicationEx::Run (this=0x9445a8) at XBApplicationEx.cpp:96
#13 0x001dc836 in main (argc=1, argv=0xbefff264) at xbmc.cpp:93


I'm not sure if there is some sane way to ensure the opposite order is preserved, so renderer is cleaned up before the decoder. Otherwise I need to think of a better way to do what is done in CDVDVideoCodecGStreamer::GetEGLImage() and CDVDVideoCodecGStreamer::ReleaseEGLImage(), which I need for two reasons:

1. reference counting.. I need to hold a reference to the original gst buffer that the eglImage is created from while the renderer is using it, to avoid it getting free'd or passed back to decoder for next frame, and
   
2. defer creating the eglImage, to avoid creating the eglImage in the first case for frames that might be dropped. I think this will be less important down the road, with gst 0.11/1.0 stuff, I think we can stuff the eglImage in gst buffer metadata, and avoid unmapping/destroying the eglImage if the buffer is recycled. But for now we need something like this.
   

[davilla]

Nice, interesting that panda can deal with packed yuv directly. I'll have to digest this over the holidays.

The renderer/codec close order issue should be similar to vdpau in LinuxRendererGL. It's also passing refs around. LinuxRendererGL also can deal with different yuv packing but shader convert is different.

[robclark]

Nice, interesting that panda can deal with packed yuv directly. I'll have to digest this over the holidays.

The renderer/codec close order issue should be similar to vdpau in LinuxRendererGL. It's also passing refs around. LinuxRendererGL also can deal with different yuv packing but shader convert is different.

fwiw, I pushed another update that has a different way to deal w/ passing ref's around, so I don't run into trouble when the decoder is deleted.. this solves the crash at end of playback.

Of course, I'm neither a C++ expert nor xbmc expert, so I'm entirely sure there is some room some cleanup/refactoring.

[robclark]

btw, how exactly is seeking expected to work? I'm not sure if it is something messed up in the gst decoder, or just because I'm based off of some random commit rather than stable release version. But A/V sync goes waaay off into the weeds if I attempt to seek or resume playback from some position mid-way through a video..

[solmis]

Thank you robclark for your work, I've been really waiting for a working xbmc on my pandaboard. Anyways, I'm having problems getting this thing running. I'm using latest Ubuntu. Pulled your branch and compiled it with:

Code:

./configure --enable-neon --enable-gles --disable-vdpau --disable-optical-drive --enable-gstreamer

It starts with the following messages:

Code:

PVR:(Warning): InitContext: ignoring buffer type CBUF_TYPE_PDS_VERT_SECONDARY_PREGEN_BUFFER [778, /eglglue.c]
PVR:(Warning): InitContext: ignoring buffer type CBUF_TYPE_PDS_VERT_SECONDARY_PREGEN_BUFFER [778, /eglglue.c]

When trying to view a video (tried mkv samples and some apple trailers), I get:

Code:

GStreamer: The capabilities from source are video/x-h264, width=(int)1280, height=(int)720, framerate=(fraction)1710843747/71356439, codec_data=(buffer)01640029ffe1001967640029ac562405005ba100000303e90000bb808f1831898001000768e88e08cb22c0
GStreamer: Entire pipeline is appsrc caps="video/x-h264, width=(int)1280, height=(int)720, framerate=(fraction)1710843747/71356439, codec_data=(buffer)01640029ffe1001967640029ac562405005ba100000303e90000bb808f1831898001000768e88e08cb22c0" name="AppSrc" ! decodebin2 ! ffmpegcolorspace ! appsink caps="video/x-raw-yuv,format=(fourcc){I420,NV12}" name="AppSink"

(xbmc.bin:25788): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:2295: signal `crop' is invalid for instance `0x26d0048'
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSink changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element ffmpegcsp0 changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element typefind changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element decodebin20 changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSrc changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element pipeline0 changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element ffmpegcsp0 changed state from READY to PAUSED.
GStreamer: Message STATE_CHANGED
GStreamer: Element typefind changed state from READY to PAUSED.
GStreamer: Message STREAM_STATUS
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSrc changed state from READY to PAUSED.
GStreamer: Message STREAM_STATUS
GStreamer: Message STATE_CHANGED
GStreamer: Element ducatih264dec0 changed state from READY to PAUSED.
GStreamer: Message STATE_CHANGED
GStreamer: Element h264parse0 changed state from READY to PAUSED.
GStreamer: Message STATE_CHANGED
GStreamer: Element decodebin20 changed state from READY to PAUSED.
GStreamer: Message TAG
GStreamer: Message DURATION
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSink changed state from READY to PAUSED.
GStreamer: Message STATE_CHANGED
GStreamer: Element pipeline0 changed state from READY to PAUSED.
GStreamer: Message ASYNC_DONE
GStreamer: Message NEW_CLOCK
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSink changed state from PAUSED to PLAYING.
GStreamer: Message TAG
GStreamer: Message STATE_CHANGED
GStreamer: Element ffmpegcsp0 changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element ducatih264dec0 changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element h264parse0 changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element typefind changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element decodebin20 changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSrc changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element pipeline0 changed state from PAUSED to PLAYING.
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1470: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1481: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1470: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1481: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1470: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1481: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1470: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1481: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1470: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1481: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
GStreamer: Message TAG
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
assert: ioctl(td, TILIOC_GBLK, blk) (=-1) !== 0 at tiler_alloc(memmgr.c:438): Cannot allocate memory
assert: tiler_alloc(blks + ix) (=-1) !== 0 at MemMgr_Alloc(memmgr.c:771)

Last 4 lines get spammed to terminal until it segfaults after breaking it with ctrl-c. I can see subtitles normally, but screen stays black.

Is this somehow related to my setup or did I compile it wrong? Any chance for a binary or debian package I can test?

[davilla]

btw, how exactly is seeking expected to work? I'm not sure if it is something messed up in the gst decoder, or just because I'm based off of some random commit rather than stable release version. But A/V sync goes waaay off into the weeds if I attempt to seek or resume playback from some position mid-way through a video..

That branch is pretty old, might be best to extract the gstdecoder bits and bring in to current checkout from trunk. I did this several months ago when I was looking into gst. Was running under OSX in fact

[robclark]

Thank you robclark for your work, I've been really waiting for a working xbmc on my pandaboard. Anyways, I'm having problems getting this thing running. I'm using latest Ubuntu. Pulled your branch and compiled it with:

Code:

./configure --enable-neon --enable-gles --disable-vdpau --disable-optical-drive --enable-gstreamer

It starts with the following messages:

Code:

PVR:(Warning): InitContext: ignoring buffer type CBUF_TYPE_PDS_VERT_SECONDARY_PREGEN_BUFFER [778, /eglglue.c]
PVR:(Warning): InitContext: ignoring buffer type CBUF_TYPE_PDS_VERT_SECONDARY_PREGEN_BUFFER [778, /eglglue.c]

When trying to view a video (tried mkv samples and some apple trailers), I get:

Code:

GStreamer: The capabilities from source are video/x-h264, width=(int)1280, height=(int)720, framerate=(fraction)1710843747/71356439, codec_data=(buffer)01640029ffe1001967640029ac562405005ba100000303e90000bb808f1831898001000768e88e08cb22c0
GStreamer: Entire pipeline is appsrc caps="video/x-h264, width=(int)1280, height=(int)720, framerate=(fraction)1710843747/71356439, codec_data=(buffer)01640029ffe1001967640029ac562405005ba100000303e90000bb808f1831898001000768e88e08cb22c0" name="AppSrc" ! decodebin2 ! ffmpegcolorspace ! appsink caps="video/x-raw-yuv,format=(fourcc){I420,NV12}" name="AppSink"

(xbmc.bin:25788): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:2295: signal `crop' is invalid for instance `0x26d0048'
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSink changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element ffmpegcsp0 changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element typefind changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element decodebin20 changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSrc changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element pipeline0 changed state from NULL to READY.
GStreamer: Message STATE_CHANGED
GStreamer: Element ffmpegcsp0 changed state from READY to PAUSED.
GStreamer: Message STATE_CHANGED
GStreamer: Element typefind changed state from READY to PAUSED.
GStreamer: Message STREAM_STATUS
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSrc changed state from READY to PAUSED.
GStreamer: Message STREAM_STATUS
GStreamer: Message STATE_CHANGED
GStreamer: Element ducatih264dec0 changed state from READY to PAUSED.
GStreamer: Message STATE_CHANGED
GStreamer: Element h264parse0 changed state from READY to PAUSED.
GStreamer: Message STATE_CHANGED
GStreamer: Element decodebin20 changed state from READY to PAUSED.
GStreamer: Message TAG
GStreamer: Message DURATION
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSink changed state from READY to PAUSED.
GStreamer: Message STATE_CHANGED
GStreamer: Element pipeline0 changed state from READY to PAUSED.
GStreamer: Message ASYNC_DONE
GStreamer: Message NEW_CLOCK
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSink changed state from PAUSED to PLAYING.
GStreamer: Message TAG
GStreamer: Message STATE_CHANGED
GStreamer: Element ffmpegcsp0 changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element ducatih264dec0 changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element h264parse0 changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element typefind changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element decodebin20 changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element AppSrc changed state from PAUSED to PLAYING.
GStreamer: Message STATE_CHANGED
GStreamer: Element pipeline0 changed state from PAUSED to PLAYING.
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1470: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1481: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1470: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1481: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1470: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1481: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1470: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1481: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1470: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1481: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
GStreamer: Message TAG
GStreamer: Message TAG
GStreamer: Message DURATION
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1422: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1209: fail: GL ERROR: 1280
LinuxRendererGLES.cpp:1212: fail: GL ERROR: 1280
assert: ioctl(td, TILIOC_GBLK, blk) (=-1) !== 0 at tiler_alloc(memmgr.c:438): Cannot allocate memory
assert: tiler_alloc(blks + ix) (=-1) !== 0 at MemMgr_Alloc(memmgr.c:771)

Last 4 lines get spammed to terminal until it segfaults after breaking it with ctrl-c. I can see subtitles normally, but screen stays black.

Is this somehow related to my setup or did I compile it wrong? Any chance for a binary or debian package I can test?

Hold tight for a few days.. there are updates needed in a few other places for this all to work:

1. gst-ducati - small bugfix
   
2. gst-plugins-base - implement crop support in appsink
   
3. pvr/sgx libs - eglImageExternal support for rendering.. missing this is why you are getting spammed with "GL ERROR: 1280"
   

The gst parts you can build latest from git. But the pvr stuff, you'll at least have to wait until updates get pushed to the PPA. I'll try to bug the guys who know about the debian build stuff to do this next week but as always everyone is pretty busy.