Ticket #12491 (new defect)

Opened 20 months ago

Last modified 16 months ago

Implement vMeta for XO-4

Reported by: dsd Owned by: dsd
Priority: high Milestone: 13.2.0
Component: kernel Version: not specified
Keywords: Cc: humitos, greenfeld, sridhar, jvonau
Action Needed: add to build Verified: no
Deployments affected: Australia Blocked By:


vmeta needs to be made working and tested on XO-4 as a high priority task (but not a production blocker).

This should ideally involve providing libraries for both gstreamer-0.10 and gstreamer-1.0, unless that is a particularly complicated task. I can attempt to help with the porting.


gst1.patch (4.7 kB) - added by dsd 19 months ago.
initial gstreamer-plugins-marvell porting to gstreamer-1.0

Change History

Changed 20 months ago by dsd

  • cc humitos added

We will proceed with the plans to provide vmeta for both gstreamer-0.10 and gstreamer-1.0, but the unknown is how much work will be needed to the gstreamer-vmeta code to make it work with 1.0. Hopefully not too much.

Changed 19 months ago by dsd

Providing vmeta for gstreamer-0.10 should be easy.

For gstreamer-1.0, it looks like it would be at least a few hours work to port the code, plus a suitably large amount of time for testing/debugging/fixing. Here is a good reference: http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/random/porting-to-1.0.txt

I've attached an patch for initial porting of gstvmetadec. There are quite a few big things left to port. vmetadec_push_frame_to_downElement needs to use the GstMemory API (e.g. gst_memory_new_wrapped) to feed memory into the GstBuffers that it creates, and probably use the GstMemory GDestroyNotify for freeing. For IPPGST_BUFFER_CUSTOMDATA we can probably use gst_mini_object_set_qdata on the GstBuffer. Then there are a load of pad and caps API users to fix up as well.

Not to forget the vmetaxv code that will probably need similar treatment.

I suggest that we continue focusing on the XO-4 graphics driver and other priority items, and when things are stable, reinstate vmeta on gstreamer-0.10. When we are that far, we can revisit providing vmeta for gstreamer-1.0. As we currently don't integrate vmeta into the release, we are not bound by the usual deadlines, we just have to try and complete the work by the time that customers recieve machines.

If we don't provide vmeta for gstreamer-1.0, a deployment that wants to use vmeta in Jukebox can can probably just use the Jukebox version from 12.1.0. Not ideal, but it should work. We'll have to give that a quick test.

Changed 19 months ago by dsd

initial gstreamer-plugins-marvell porting to gstreamer-1.0

Changed 18 months ago by greenfeld

  • next_action changed from never set to code

The XO-4 Linux kernel still needs vmeta devices added as of 13.1.0 os30.

/dev/pmem_adsp and /dev/uio0 should be present.

If the vmeta software libraries are present and these devices are not, the failure to use them can be somewhat subtle (fallback to software codecs).

Changed 16 months ago by dsd

  • owner changed from jnettlet to dsd
  • milestone changed from 13.1.0 to 13.2.0

Changed 16 months ago by dsd

  • next_action changed from code to communicate

I have split out the gstreamer-1.0 porting to #12665, leaving this ticket focused on getting vmeta working on XO-4 as well as it was on XO-1.75.

This work is complete, we just need Marvell's permission to release the code. http://wiki.laptop.org/go/Vmeta

Changed 16 months ago by dsd

  • cc greenfeld added
  • next_action changed from communicate to test in build

13.2.0 build 5 includes the required base here. Ready for testing by Sam when he has time.

Changed 16 months ago by sridhar

  • deployment_affected set to Australia

Changed 16 months ago by sridhar

  • cc sridhar, jvonau added

Changed 16 months ago by dsd

  • next_action changed from test in build to add to build

vmeta and supporting codecs will be included by default in future XO-4 builds.

Note: See TracTickets for help on using tickets.