[XviD-devel] API changes request from MPEG4IP

[Edouard Gomez]

Edouard Gomez (ed.gomez at free.fr) wrote:
> 1) - need to be able to disable all VOL headers in the stream. This is
>      fairly simple to do - probably add a flag.

Yes a flag  would be enough. But just for curiosity,  why don't you want
VOL headers ? I  know we repeat them each IFrame, so  first i though you
wanted just a VOL for a  complete stream, but then i've read you request
again, and  realized you  wanted _no_ VOL_  header. This surprises  me a
bit as it makes XviD non standard compliant.

> 2) - need to  get the  reconstructed YUV image  back after  encoding a
>    frame.  I'd  like to  know what  you think the  best way  to return
>    this.

I  don't know  what branch  you  use for  MPEG4IP, but  perhaps a  small
reminder might be necessary for you.

0.9.x  series  are   simple  profile  encoders/decoders.   They've  been
developed on  HEAD for 0.9.0 and  0.9.1.  During this  time, an Advanced
Simple Profile version of XviD was developed in the dev-api-3 branch.

At 0.9.1 release we decided to use another development scheme where HEAD
would be unstable  and branches stable or "higly  unstable" (aka feature
branches).  So we  merged  dev-api-3 back  to  HEAD, and  0.9.x tree  on
release-0.9.1-fixes.

Following this new scheme, we  created dev-api-4 branch to prepare a new
API for xvid 1.0.x series. As  the work on dev-api-4 is near completion,
we now have this CVS situation:
  - release-0.9.[012] tags marking each SP release.
  - dev-api-3: abandoned branch
  - HEAD:  continuation of devapi3  (contains fixes,  improvements until
           eary  august).  Since  early  august, HEAD  is  inactive  and
	   waiting for a merging from dev-api-4 to prepare xvid 1.0.
  - dev-api-4: active, future base of xvid 1.0

This picture of  the xvid CVS was necessary to  make possible you choose
the right  version for  MPEG4IP. It was  also needed because  the answer
differs depending on what branch you base MPEG4IP.

Let's paste again your question:
> 2) - need to  get the  reconstructed YUV image  back after  encoding a
>    frame.  I'd  like to  know what  you think the  best way  to return
>    this.

For HEAD:
There is nice API to make this possible. However, i think all the
needed  code parts  are in  place  to retrieve  the reconstructed  image
after the  MC+fDCT+iDCT+MC. Look  at the sOriginal  field IMAGEs  of the
Encoder structure.

For dev-api-4:
You can use  the plugin API and  request the core to give  you access to
internal buffers  with REQORIG  etc etc. There  is no  documentation yet
about plugins  but you can  have a look  at them reading the  sources of
our rate controllers, lumimasking plugins.

>          I'm current using XVID_CSP_USER to pass in the data - perhaps
>    just overwriting the data there ?

That could be a solution for HEAD, but it makes your XviD usage fairly
"nont the usual way". This was not a problem when you had your own fork
of XviD but now you try to use client libs as they are on the
system... it would be difficult to modify HEAD behavior after being used
by other project in a complete different way that you propose. It may
impact others.

So as a conclusion for this exact problem:

Knowing that HEAD  is dead, that xvid 1.0 will be  based on dev-api-4, i
think  the best  solution is  to  use dev-api-4  as a  base version  for
MPEG4IP.

But, at the moment we can't  garuantee you an external stable API. There
are still some changes required. Perhaps they'll be part of XviD 1.0, or
pending for future releases.
 
> I'm also  contemplating adding small  option menus to mp4live  that will
> allow differing  options -  I'd like  to know what  opinions as  to what
> different options make sense.

That's a recurrent problem, the more the MPEG4 encoders are mature, the
more options they offer.

But from the MPEG4IP POV, it would make sense to first give access at
profile options to allow easy interoperability, easy feedback from
users trying to create content for embedded devices.

Then, in a second step you could give access to parameters impacting
on the chosen profile:
 - 4mv
 - Qpel
 - GMC
 - Usage of bframes and how many...

And in a last step, all options impacting the content creator usage of
MPEG4IP from a speed/quality of content POV:
 - Motion estimation Level 0..6 (no ME to Very High Quality)
 - RD based ME 0..4 (called VHQ)

These two options could even be put together in order to cimplify
users' life.

You  can have  a look  at the  transcode frontend  for the  xvid4 export
module. This  frontend does not  follow the advices  i gave you,  but at
least it  presents you the options  XviD presents to users  on Win32 and
transcode/mencoder:
http://ed.gomez.free.fr/vrac/xvidconf/

Sorry i don't have the url of the upstream project, you can browse the
transcode ML archives on gmane to find it.
 
-- 
Edouard Gomez