Current status of GStreamer on Raspberry Pi

[Alexey Chernov]

Sebastian, thank you for detailed information.

В письме от 11 фев 2013 09:10:10 Вы написали:
> You should use the master branch and call configure with
> --with-omx-struct-packing=4

Will 1.0.5 release do to build it or is it against master of gstreamer either?

> > I also have a question on gst-omx module, would appreciate if you could
> > give some hint on that. It's about OpenMAX sink implementation using
> > tunneling and/or 'video_render'-like OpenMAX module. Is there any
> > technical issues or serious difficulties in their implementation or it's
> > a question of concept and resources? I consider implementing something
> > like these elements, RPi examples don't look too difficult, but can't
> > estimate well whether I'm able to do it by myself.
> 
> It can be done, just needs someone to actually do it. It's a bit tricky
> though because you have to integrate the GStreamer synchronization model
> with the OpenMAX synchronization model.

I actually started implementing two sinks: one for 'video_render' component 
and raw input video and another with tunnel inside. Didn't finish any to see 
the video result yet, but hopefully try to do it this week.

I managed to learn a way to initialize OpenMAX properly, but 'raw' videosink 
displays garbage now instead of videotestsrc signal. I think I should sort out 
with video formats and buffer filling routine (I guess it should be something 
reciprocal to fill_buffer procedure in videodec).

As to integrating syncronization models I rely on 'clock' component of 
OpenMAX. In omxplayer and video_pi example it seems that it can synchronize 
tunnel quite well and GstClock is probably enough to feed the decoder with 
encoded data. Given that consumption of tunnel is quite constant, I believe it 
should work right. But any advice is highly appreciated.

> 
> And if you want to add tunnelling support you have two options:
> a) Implement tunneling inside your new sink, i.e. have multiple OpenMAX
> component in the sink (video_decode, video_schedule, video_render).
> Which has all the problems of sinks handling compressed data.
> 
> b) Implement tunnelling between different GStreamer elements. This is
> very complicated and I currently don't have any good suggestions about
> how to implement it properly.

I've chosen the first option for now, hope the result will be satisfactory.

The second option looks better in terms of architecture, but I'm so 
uncomfortable with OpenMAX stuff at the moment and not much experienced in low 
level GStreamer mechanics so it would be too great task for me. Now it looks 
like it requires to wrap tunnel between OpenMAX components with pads' 
chain_function, if I get it right.

Thanks again for detailed suggestions!