[XviD-devel] API changes request from MPEG4IP

[Bill May]

Edouard Gomez wrote:

> 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.

Answered that for Pete - but mp4live generates it's own VOSH/VO/VOL - we
don't want/need it in the stream - only in the SDP, and later in the mp4
file as the decoder specific info.

If you had an API to just generate the VOSH/VO/VOL, that would be fine.

>>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.

Right - this is what I'm working off of.

> 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.

Until stable, I don't want to work on this.

> 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.

Okay - no problems.

> 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.

Which API ?

> 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.

Again - we'll implement to this when you've officially released something
stable (if we get to it - it's taken a while to get to 0.9.2 - my time is
fairly limited).

> 
>>         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.

Sorry - can't do - for reasons of your next statement...

> 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.

Well, I'll do the changes that I need and try to feed them back - perhaps you
could keep these in mind when you do 1.0 ?

> 
>>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...

All good things...

> 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.

I'll take a look at your other email.

Thanks,
Bill