spiff314
Posts: 4
Joined: Sun May 01, 2016 7:22 pm

Hacking the source code of the omxplayer

Tue May 10, 2016 8:49 pm

Hi Guys

I asked this question in the c/c++-forum (viewtopic.php?f=33&t=147419) and was suggested to move it to this part of the forum:

My question is related to the source code of the omxplayer:

I would like to be able to use my Raspberry Pi to show a video on a TV and get it to generate a trigger pulse via the GPIOs when each frame of the video is shown on the TV. My plan is to use the wiringPi-library to write a function for generating the pulse and then include this function at the right place in the source code for omxplayer.

My problem is, however, that the source code for the omxplayer is not well documented with comments, so I don't know where to add this function.

When I asked the question the first time, it was kindly suggested that I should take a look at the COMXCoreComponent::DecoderFillBufferDone-function defined in OMXCore.cpp.

As an initial test I have defined the parameter

Code: Select all

int ind = 1;
in the top of the OMXCore.cpp-file, and then added the line

Code: Select all

printf("%d \n",ind);ind++;
in the definition of the DecoderFillBufferDone-function, as it can be seen below:

Code: Select all

OMX_ERRORTYPE COMXCoreComponent::DecoderFillBufferDone(OMX_HANDLETYPE hComponent, OMX_BUFFERHEADERTYPE* pBuffer)
{
   printf("%d \n",ind);ind++;


  if(m_exit)
    return OMX_ErrorNone;

  #if defined(OMX_DEBUG_EVENTHANDLER)
  CLog::Log(LOGDEBUG, "COMXCoreComponent::DecoderFillBufferDone component(%s) %p %d/%d\n", m_componentName.c_str(), $
  #endif
  pthread_mutex_lock(&m_omx_output_mutex);
  m_omx_output_available.push(pBuffer);

  // this allows (all) blocked tasks to be awoken
  pthread_cond_broadcast(&m_output_buffer_cond);

  pthread_mutex_unlock(&m_omx_output_mutex);

  return OMX_ErrorNone;
}

In this way I thought I should be able to see how many times DecoderFillBufferDone was called when I played a video. But when I play a video, I don't see anything; no value of the ind-parameter is printed to the terminal. I think this leads to the conclusion that either the DecoderFillBufferDone-function is the wrong function to modify OR I have totally misunderstood what I am doing.

It should be mentioned, however, that when I add the line "printf("%d \n",ind);ind++;" to other functions defined in OMXCore.cpp, I see the value of "ind" printed to the terminal when a video is played.

Do any of you know if I'm on the right track here or how and which function in the omxplayer I should modify in order to generate the trigger for each frame?

Thanks in advance

Ps I have uninstalled the version of omxplayer that comes with Raspbian and downloaded and compiled the version found at https://github.com/popcornmix/omxplayer

blackshard83
Posts: 79
Joined: Fri Jan 10, 2014 8:31 am

Re: Hacking the source code of the omxplayer

Mon Jun 06, 2016 3:17 pm

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 omxplayer doesn't really know when a frame is rendered on screen because everything happens behind the scene (and mostly inside the broadcom firmware/hardware) and it is all orchestrated by omx components.

You may investigate if there is a sort of callback given by omx video rendered, but probably there isn't any.
There may be a chance to use EGLRenderer instead of VideoRenderer, but it may complicate things (see the hello_pi examples, the one with the rotating teapot and textured with a video)

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5176
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Hacking the source code of the omxplayer

Mon Jun 06, 2016 4:26 pm

As blackshard83 says, omxplayer isn't the best choice for this because the arm doesn't control rendering of frames. It just shovels encoded data to the gpu which runs a pipline omxplayer has created to decode, schedule and render the frames.

Something like MMAL in Kodi may be a better base as frames are scheduled directly by the ARM, but Kodi is a huge program with a lot of dependencies, so it's not easy to build and understand.

Are you running omxplayer with "-r" option? (So HDMI mode is chosen to match video).
If so then you may just need to hook up to the HDMI vyncs. That can be done quite easily.
See: https://github.com/raspberrypi/userland ... anx.h#L136

Return to “OpenMAX”