libyami NEWS -- summary of changes.  2019-08-06
Copyright (c) 2010, The WebM Project authors.
Copyright (C) 2011-2019 Intel Corporation
Copyright (C) 2015-2016 Alibaba

libyami 1.3.2(API:0.7.0) release, work with libva 2.5.0
=====================
Major improvements:
+c5507c2 fix build for Celadon android project
+b0ba3b1 fix vp9parser for iHD driver
+f742635 fix build on GCC9
+0c40cbf refact mpeg2 decoder, make it more readable
+37e73be fix YamiParser::NalRreader::getPos conner case

We bump api for
+b0b0a21 add motion adaptive and compensated deinterlace mode

libyami 1.3.1(API:0.6.0) release, work with libva 2.2.1.pre1 release
=====================
Major improvements:
+af43e95 h264dec: fix low lantecy mode
+160286a Add flags for SDL signoff called SDL325 - Compile With Defenses Enabled
+727db97 common: add RGB 10 bits support
+46c15b1 common: add RGB565 support
+946b7ac common: add XRGB, ARGB, XBGR, ABGR support
+9e1fc1d android: re-enable android build
+3745982 yamivpp: add rotation function for vpp

libyami 1.2.0(API:0.5.0) release, work with libva 1.8.1 release
=====================
Major improvements:
+180c3d5 improve vp9 10 bit decoder conformance
+8d29d2d improve h265 8/10 bit decoder conformance
+5b09484 add decoder/display zero-copy API.
+e46f03b use decoder/display zero copy API in v4l2 decoder
+441ee54 expose vp9 qp setting to the user.

We change API to from 0.4.0 to 0.5.0 for following interface changes.
+1fe162e get/set surface in SurfaceAllocParams
+7560ce7 add VIDEO_DATA_MEMORY_TYPE_EXTERNAL_DMA_BUF

libyami 1.1.0(API:0.4.0) release, work with libva 1.7.3 release
=====================
We add following major features:
+c8299ca add h265 10 bits decoder
+ea3bc34 add vp9 10 bits decoder
+c7364f0 add h265 10 bits encoder
+3daae20 add Hue, Saturation, Brightness and Contrast to vpp
+0c8299c fix memory leak issue in v4l2
+71ec018 fix h264 baseline encoder fail issue
+d39104d fix h264/h265 encoder generate invalid frame for long GOP
-h265,vp9 10 bits conformance pass rate is not high.


We change API from 0.3.2 to 0.4.0 since following interface change
+7c6050b add enablePrefixNalUnit to h264 encoder
+3daae20 add Hue, Saturation, Brightness and Contrast to vpp
+c7364f0 add h265 10 bits encoder

libyami 1.0.1(API:0.3.2) release, work with libva 1.7.3 release
=====================
This release mainly for SVC-T CBR support.We add following features:
+0a241d2 add h264 SVC-T CBR support. This need libva 1.7.3.
+77ba612 fix h264/h265 nalread issue in 32 bits arch
+2c1fcf3 h264parser: change luma_weight_lx from int8_t to int16_t to avoid overflow
+e2a9e07 vp8parser: fix one decoder conformance issue.
+fb83012 make yocto buildable
+518088e add wireframe function to ocl filters
+other small issues.

We change API from 0.3.0 to 0.3.2 since following interface change
+518088e add wireframe function to ocl filters
+0a241d2 add h264 SVC-T CBR support.


libyami 1.0.0(API:0.3.0) release, work with libva 2016Q3 release
=====================
We add following major features:
+ 7423a97 add vp9 encoder
+ f6f1483 add sharpening, denoise, deinterlace for vpp
+ 366d909 add support for 422H, 422V and 444P
+ 2d4a536 add wayland support to v4l2decoder
+ 784ea0f improve h264 encoder speed for memory limited system
+ e57989f improve mpeg2 pass rate from 70% to 100%
+ 112b921 improve vc1 pass rate from 70% to 92%
+ 7f2e032 add profile setting for h264encoder
+ some more encoder setting for h264 and h265
+ more bugs fix and features please refer to git log
- convert odd resolution from NV12 to I420 will make output yuv twisted
- some unittest will failed.

We change API from 0.2.0 to 0.3.0 since following interface change
9f45ee7 add vp9 encoder
765cb6d add single header Yami.h/YamiC.h for user to include
99b85bc map tr1 name space to std name space
ea0b5fd add SVC-T support for h264 CQP mode
366d909 add support for jpeg 422H, 422V and 444P
2d4a536 add wayland support to v4l2decoder
1b53e29 deleted some unused encoder API
3147d36 enc264: implement I/P/B QP setting on CQP mode
f6f1483 vpp: add denoise,sharpening and deinterlace



libyami 0.4.0 release, work with libva 2016Q2 release
=====================
We relicensed entire project from LGPL to Apache V2
+add mpeg2 decoder
+add vc1 decoder
+merge all so to single libyami.so
-mpeg2/vc1 pass conformance rate is 70%
    fix patch should ready in near future.



libyami 0.3.1 release, work with libva 2015Q4 release
=====================
+b frame for h264 encoder
+CBR for h265 encoder
+yamitransocde application, it will do zero copy transcode, much faster than yamiencode
+fix static library link issue
+fix various issue in vaapidisplay, vp8dec, h264enc, h265enc, factory
-transocde application will use default configuration, it did not use user set one.
-if you use latest ffmpeg, vp9 decoder will failed for some clips.mentioned in #347.
    it's not core library's issue. It's a yamidecode's issue.
    You can use ffmpeg 2.6 as workaround.


libyami 0.3.0 release, work with libva 2015Q3 release
=====================
+h265 decoder
+h265 encoder
+new mode -2 for yamidecode, it will output per frame md5 for decoded yuv
+some bug fix for vp8,vp9,h264 conformance.
+simplify configure.ac

libyami 0.2.5 release, work with libva 2015Q2 release
=====================
+update codec parser to latest version
+fix all compile warnings.
+add  CBR for h264 and vp8 encoder.
+add "SharedPtr<VideoFrame> getOutput()" to decoder
+fix one loop filter issue in vp8dec
+1 bug in NativeDisplayDrm
+handle annexb format codec data in h264 decoder
+one “deref NULL” bug in v4l2 encoder.
+self-register enc/dec/vpp with their factories.
+add a simple player to demo decoder api usage(200 lines)
+add grid application to demo MxN ways decode + dipslay
+select driver name base on decoder profile


libyami 0.2.4 release
=====================
+add vpp interface for c++
+fix momory leak, uinitilized variable and invalid read reported by valgrind
+3 bug fix for vp8 encoder.
+.gitignore file
+ update correct profile name for vp9 since libva updated.
+fix "resolution changed in v4l2 egl mode makes yami crash" issue
-decode output dump can't gusss output fourcc from file extension



libyami 0.2.3 release
=====================
+add VIDIOC_G_CROP to io ctrl
+fix one ImagePtr leak issue, since ImagePtr hold DisplayPtr, it also leak VaapiDisplay

libyami 0.2.2 release
=====================

features update
---------------
+fix one include issue in capi header
+3 fixes for vp9 decoder and parser
+use cabac as default entropy mode for h264 encoder
+fix servral issues when we use v4l2 decoder in gles mode

libyami 0.2.1 release
=====================
the main target of this release is bug fix, especially the busy waiting issue.

features update
---------------
+fix one busy waiting bug in v4l2decoder.
     -It will drain out cpu resource even we pause the video.
+4 patches apply to fix vp9 conformance test.
+add fakedec, it's good start for performance measure.
+fix random crash bug when we use "yamidecoder -m -1"

libyami 0.2.0 release
=====================

features update
---------------
+ add VP9 decoder
+ add VP8 encoder
+ add JPEG encoder
+ add Demux support leverage libavformat,: --enable-avformat
  - yamidecode runs ok when there is no xwindow rendering (-m -1/0)
  - v4l2decode is ok when there is with or w/o rendering
  - support libvaformat from the version installed in Ubuntu13.10
  -	known issue: when there is video rendering, yamidecode blocks at
    XGetWindowAttributes() after libva dlopen(i965_drv).
    Add XInitThreads() make things worse. It is strange.
+ Fps update for "-m -1", we get stable performance data now
+ V4l2 fixes: seek, unconditionally stop
+ enable FFmpeg to use libyami for h264 decoding, create example player to
  demonstrate it, especially on rendering video as texture through dma_buf
  https://github.com/01org/player-ffmpeg-yami

known issues
---------------
- for avformat support in yamidecode,  when there is video rendering,
  yamidecode blocks at XGetWindowAttributes() after libva dlopen(i965_drv).
  Add XInitThreads() make things worse. It is strange.
  v4l2decode doesn't have such issue. (yamidecode is one thread application)

thoughts on libyami (media framework and window system support)
--------------------------------------------------
these points are not our priority yet.

+ Wayland support
  We did a lot to support Wayland before:
  - add Wayland platform support in libva and driver, does hack to
    copy wayland-drm protocol from mesa/egl
  - add Wayland platform in middleware, gstreamer-vaapi for example

  the detects are:
  - so far, only plain rendering is supported: wl_surface_attach/wl_surface_damage;
    texture video rendering is still a gap
  - the shared wl_display/wl_window/wl_event_queue are complex and problematic

  it should be much easier with dma_buf.
  We neend't do anything special for native window system in either vaapi driver or
  codec library. with dma_buf handle exported, application can draw the video
  frame (dma_buf) by EGL/GLES, EGL handle native window system automatically(including
  wrap it into a wl_buffer internally).

+ GStreamer support
  We usually do a lot on hw video buffer sharing in GStreamer, hw video buffer are
  platform dependent, but the framework requires to wrap them in a generic way. we do
  a lot in decoder to wrap a platform dependent handle into a subclass of base
  video buffer, then unwrap it in video sink. and tries best to hide hw detail when
  a sw component request to access the frame data.

  it becomes simple when hw codec support dma_buf, since dma_buf is Linux generic.
  it is possible that hw video become not the 2nd class citizen any more. we don't
  need additional wrapper in decoder side, and we don't need a special video sink
  for each hw video type.

+ dma_buf rendering for legacy support
  in the above ideas, we usually consider EGL/GLES rendering context, how about
  legacy usage? it is simple as well.

  DRI3 protocol support dma_buf, it means a dma_buf handle can be sent to server
  for window update. Keith said mesa is using it, and on server side glamor handle
  the dma_buf. the remaining gap is that YUV buffer hasn't been supported yet, but
  not hard to add it.

libyami 0.1.4 release
=====================

features update
---------------
    -   Additional fixes(most are thread race condition) for v4l2 wrapper (egl/gles)
    -   Add glx support in v4l2 wrapper
    -   Basic transcoding support: encoder test accepts input data from decoder output
    -   Testscript is added, it supports one-run-for-all: with a folder including h264/vp8/jpeg/raw-ref,
        we can test them in one run. It serves as BAT (basic acceptance test) for pull request merge.
    -   Report fps in decode test, support decoding only test (skip rendering)
    -   Vp8/jpeg are supported in v4l2 decoder as well
    -   Decode test can be built/run without X11
    -   Code refinement for decoder test output and encoder classes
    -   dma_buf fixes, when video frame is exported as dma_buf, it renders well as texture
    -   with additional patch for chrome:
        V4L2VDA/V4L2VEA pass chrome video unit test
        video playback in browser draft ok
    -   for v4l2 wrapper, see: https://github.com/halleyzhao/yami-share/blob/master/Yami_V4L2_wrapper_for_Chrome.pdf

known issues
---------------
    -   this release is fully tested by validation team
    -   some jpeg file similarity <0.99 (~0.98) after decoding
            https://github.com/01org/libyami/issues/108

future release plan:
====================
    Dec: v0.2
        jpeg encoder
        vp9 decoder
        vp8 encoder (depends on driver availability)
        initial ffmpeg support

    Feb'15: v0.3
        unified input/output buffer of yami
        transcoding support with unified input/output buffer
        camera dma_buf support, camera with jpeg input
        use yami in ffmpeg for hw codec

    Future:
        h265 decoder


Libyami 0.1 release note
===========================

Libyami is core video library to accelerate decoding/encoding based on libva.
Libyami can be treated as development kit for VAAPI. It is developed by C++ language, with simple/efficient APIs, without external dependencies.
libyami targets two type of usage:
    - Hardware accelerated codec is the major gap (there is existing media framework ), for example: Chromeos/Android, maybe ffmpeg.
    - Usage is simple enough that codec is the major interest, for example: remote desktop client/server, video surveillance.
So far H.264 decode/encode, VP8 and JPEG decode are supported. VP8/JPEG encode support is under development.

There are rich tests/examples in yami for a try. The tests can run without Window system (X11/Wayland etc),
some modes of video output are supported: including raw data dump and some modes of texture (TFP, drm flink name, dma_buf).

More details see: https://github.com/01org/libyami/wiki

Known issues:
    some jpeg file similarity <0.99 (~0.98) after decoding
        https://github.com/01org/libyami/issues/108
    playback performance through gst-omx is not good:
        https://github.com/01org/libyami/issues/34
    Encodeing quality through gst-omx is not good:
        https://github.com/01org/libyami/issues/36

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