Home

Yet Another Media Infrastructure.

It is YUMMY to your video experience on Linux like platform.

Yami is core building block for media solution. it parses video stream and decodes them leverage hardware acceleration. one usage is to encapsulate yami into openMAX component, to be used on Chromeos, Android or Linux (by gst-omx).

related links:

• https://github.com/01org/omxil_core
• https://github.com/01org/omx_comp
• https://github.com/01org/gst-omx
• http://01org.github.io/libyami_doxygen/index.html

Coding style

• we general follows WebKit coding style in C++ code (common/, vaapi/, decoder/, encoder/): http://www.webkit.org/coding/coding-style.html
• codecparsers keeps the existing style from gst
• you can apply the style check by "cp pre-commit .git/hooks/"; it is applied after git commit. so you can check/accept/reject the suggest coding style after initial commit.

Code Review Process

1. start work on libyami by 'fork' it to your home
2. enable coding style check by: cp pre-commit .git/hooks/
   then follows by prompt.
3. commit/push to your home's repo, test it on chromeos/ubuntu
4. create 'pull requests'
5. wait for other's review
6. update your home's repo following feedbacks
   we recommend force update to avoid unnecessary commit history, your pull requests get update automatically.
7. repeat the above two steps until no disagree
8. you can integrate your patch (home repo) with the condition met:
   

• 1+ member flags ok when patches are less than 50 lines.
  
• 2+ members flag ok when patches are more than 50 lines
  
• at least one work day passed after latest patch update
  

1. integrate the patches manually (NOT the button on web page)
   

• git push git@github.com/01org/libyami.git HEAD:master
  

we do not use the 'Merge pull request' button on web page, because:

• it creates redundant commit log.
  
• it creates unclear parent-child relation between commits when two merge requests basing on unique commit id.
  

1. now, the pull request is automatically close on web page.

Quick Links

• Test libyami with gst-omx: https://github.com/01org/gst-omx/wiki
• Links to all related projects: https://github.com/orgs/01org/teams/01-org-openmax

in progress features

1. h264 encoder (guangxin)
2. jpeg decoder (changzhi)

TODO

1. data type update we’d use uint32_t(from stdint.h) in source code, instead of both uint32_t and uint32. And use some defines from limit.h instead of local define for UINT8_MAX etc. In the end, we’d remove basictype.h, but uses standard header files.

2. log system it's better to control debug info in run time by some environments

3. there are two log.h, one is from commom/, another is from codecparser/ two files with identical name is not good.

4. legacy codec: mpeg2 decoder/encoder, vc1 decoder, mpeg4/h263 decoder/encoder

5. vasink on ubuntu

6. doxygen support

7. test for vp8dec, jpegdec and h264enc; then camera + jpegdec; camera+jpegdec+h264enc

8. va drm backend support. (in chrome v4l2vda/vea, there is no X display)

9. coded buffer pool, support mmap of coded data

10. h264 decode optimization to avoid scan start code again for nalu input (use VideoDecodeBuffer.flag to indicate buffer type)

11. EGLImage support for decoded surface: getImage with RGBX first, then multiple-eglImage support

12. more fourcc/format support for encode input frame

13. get hw aligned width/height after start()