Raspberry Pi Forums

blackshard83

Great job indeed!
Congratulations!

blackshard83

Yep, looks like the Ultibo OpenVG examples is based on AJStarkes code and that uses JPEGlib so it is probably not accelerated :( But who knows, you have to dig deep to find the real code and with so many layers I get confused. This in VGShapes.pas function VGShapesCreateImageFromJpeg(const filename...

blackshard83

I was exactly thinking about https://github.com/raspberrypi/firmware/blob/master/hardfp/opt/vc/include/EGL/eglext_brcm.h include header. Listing the official EGL extensions I get these ones: EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_vg_parent_image EGL_KHR_gl_texture_2D_image EGL...

blackshard83

Thanks for the answer, but it does not help. I was specifically asking some documentation about EGL and OpenVG broadcom extensions.
EGL and OpenVG libraries are well documented by khronos specifications available on their site for free

blackshard83

I see that in /opt/vc/include egl and openvg directories there are some import header files dealing with some broadcom specific extensions to EGL and OpenVG, but I can't find any documentation about them. I'm curious about what they do and if can be generally useful. I guess that most probably they ...

blackshard83

AFAIK there is no documented way for a process to get the handle to a dispmanx layer of another process, so you can't free it after the leak. Though I never tried to store the dispmanx handles somewhere (maybe on the filesystem) and let another process pick them up and do the calls to free them. Fro...

blackshard83

It looks weird to me too, you should "just" see the colors altered if you fail to match the channels from the source image to the OpenVG format. Nonetheless it could be tricky because if you map a color channel to the alpha channel you may actually miss some parts of the image because the color chan...

blackshard83

Hello, I don't know if this is a news or it is well-known, but I found a way to freeze the VideoCore and make the ARM unable to reboot. issuing: vcgencmd set_logging level=128 and then running any video using the omxplayer will flood the VideoCore log and bring the GPU to its knees. Unfortunately th...

blackshard83

No, I didn't. My basic block is a simple audio rendering driver, just a little piece of code that outputs some raw audio. In my experience, usually you program the audio consumer part (the audio_render component, in this case) with the latency you want (in terms of buffers/samples) and then the cons...

blackshard83

Hmmm, I guess I got it wrong: my initial thought was that I had to feed the omx component as soon as every buffer is completed, so I have a semaphore which is increased as soon as a buffer is done, catching the EmptyBufferDone callback. This is not ideal because, I realize, the buffer is emptied imm...

blackshard83

Hi all, I'm not sure if there's already an answer, I could not find any googling around. Related to my old forum post (https://www.raspberrypi.org/forums/viewtopic.php?f=70&t=175450), I would like to know what is the latency, in milliseconds or samples, added by audio_render OMX component? I see tha...

blackshard83

Just for knowledge:

I discovered, digging into raspberry kernel fork, that the driver bypass the OMX components, hence reduces the latency of the stream

blackshard83

As per subject, I'm facing the HDMI DMA issue and would like to understand what is the way ALSA uses to render the output. My guess was that it was using the audio_render OMX component, but after some tests I made I'm not so sure about. Also the audio_render component is forced to pass through the a...

blackshard83

Don't expect miracles, the h264 hardware encoder is pretty basic and produces very low quality output even at high bitrates, and software encoding is still very slow on ARM machines.

blackshard83

Ok fine, thanks a lot. So now I'm in the people asking for a fix

blackshard83

Hello, I'm trying to run multiple omxplayer instances but I noticed a problem that only happens when output is set to "omx:hdmi" that probably relates to some shared state in omx components or firmware. The following commands starts two omxplayer instances with two video side by side, you should run...

blackshard83

I really appreciate your answer pointing me to the issues, thank you! Apparently it looks really similar to https://github.com/raspberrypi/firmware/issues/449, but the OP says that his problem is more severe on pi1 than pi2, instead mine happens only on pi2. I'll double check the discussions. My pla...

blackshard83

Hello, I get strange, sporadic and unreplicable issues when running videos with a modified omxplayer on raspberry pi 2 models. Practically the video gets stuck on a frame and audio stops, sometimes the time goes on (given by a OMX Scheduler component), sometimes also the time freezes. The system is ...

blackshard83

Thanks for pointing me the github issue.

Unfortunately my kernel resides on a read only squashfs custom root filesystem which should be rebuilt and distributed to several remote devices. I prefer to avoid the kernel upgrade until it is really necessary.

blackshard83

As the subject suggests, is it safe to mix an older raspbian kernel (3.18) with newer firmware files (start.elf, mainly)? I noticed that an older firmware I was using brought the hardware decoder into unstable state in case of 4:2:2 h.264 videos, due to lack of proper hardware decoding capacity. The...

blackshard83

Thanks, got it. I tried with more instances and found that the limit has been raised.
I wonder the bcm2805 ALSA driver do use a slot or not...

blackshard83

All my fault: the problem seems to disappear upgrading to latest kernel and firmware; multiple audio_render instances seems to work fine now, even when in use with omxplayer.
I'll stress a bit the system though to be sure it satisfies my needs.

blackshard83

I tried to run more than one instance of hello_audio to verify how many separate instances of audio_render components can be running in different processes at the same time. It turns out that more than three instances cause severe problems to the whole VideoCore IV system I launched hello_audio thre...

blackshard83

Good initiative! I've been using OpenVG since the launch of the first Pi and GPU memory corruption was an issue then and now (Jessie Lite - RPi-2). My approach is similar to yours with a thin C++ wrapper library (including vector fonts) on top of the OpenVG API. Errors show up as damaged fonts (ove...

blackshard83

Probably you can't just do that in the omxplayer because the omxplayer doesn't know when the new frame is rendered. Actually the omxplayer just feeds the OMX video decoder component which is in turn connected (tunnelled) to OMX render component and timing is given by an OMX scheduler. So the omxplay...

Search found 92 matches

Re: OpenCL on the VideoCore IV!

Re: EGL and OpenVG broadcom extensions, what they do?

Re: EGL and OpenVG broadcom extensions, what they do?

Re: EGL and OpenVG broadcom extensions, what they do?

EGL and OpenVG broadcom extensions, what they do?

Re: How to free unused dispmanx layer (in case of SIGSEGV)

Re: OpenVG & vgWritePixels

Recipe to freeze the VideoCore (and freeze on reboot)

Re: audio_render time latency

Re: audio_render time latency

audio_render time latency

Re: ALSA driver uses audio_render component?

ALSA driver uses audio_render component?

Re: ffmpeg & h264_omx on pi3 very slow

Re: Shared state bug in audio_render when output is HDMI

Shared state bug in audio_render when output is HDMI

Re: Multicore bugs in OMX video components fixed lately?

Multicore bugs in OMX video components fixed lately?

Re: [raspbian]Mix older kernel with newer firmware

[raspbian]Mix older kernel with newer firmware

Re: Bug in OMX audio render component?

Re: Bug in OMX audio render component?

Bug in OMX audio render component?

Re: Call for review: fixing OpenVG wrapper library reliabili

Re: Hacking the source code of the omxplayer