[XviD-devel] Link xvid.dll dynamically from VirtualdubMod, using dev-API 4 ??

Christian HJ Wiesner chris at matroska.org
Fri May 16 12:24:42 CEST 2003


Hi Pete,

thanks for clarifying.

suxen_drol wrote:

>On Wed, 14 May 2003 23:37:43 +0200 Christian HJ Wiesner <chris at matroska.org> wrote:
>  
>
>>Hi,
>>
>>sorry for the stupid question, but is this possible in principal ? It 
>>seems that UCI as new, open standard codec API is dead, there hasnt been 
>>any progress on this project since months it seems, so i was wondering 
>>if the new dev API4 could be used to write OGM or matroska files from 
>>
< yes, its possible. though, i would wait until dev-api-4 is merged into 
head,
< when the api becomes set in stone.

I dont know if Cyrius was interested to do that at all, or if he finds 
the time, he is quite busy searching a job now as he has finished shool 
since some time, but it would be a pretty neat thing to do IMHO. Good to 
hear that the API is still changing, to avoid double work here. What i 
am concerned about is if Virtualdub in itself ( same for VirtualdubMod ) 
was prepared at all to work with external codec DLLs, and not VfW. 
Cyrious has done that for audio with Vorbis and AC3 already ( at least 
decoding ), but video is another story. Doing that could be seen as a 
first step in the direction of porting Vdub to Linux also, if you wnat :) .

>>VirtualdubMod, without using the VfW interface with all its nasty 
>>limitations ? Could we maybe use the interlacing features better this way ?
>>    
>>
>
>iam well aware of the encoder/decoder lag limitation, but otherwise imho
>vfw is sufficient. chris, do you have a list of this the codec api
>should support, such as interlacing or aspect ratio? 
>  
>
I am not so much concerned about the aspect ratio flag, as you know we 
can support this nicely from matroska with a codec independant flag 
sitting in the matroska video track header. sysKin promised us some code 
so we could read the MPEG4 flag from the codec header if there is one 
set, so we can copy it to the matroska field. Of course, it would be 
nice if the API will allow doing this directly when writing the video 
stream from VdubMod, but i thought the current API does support this 
already ? How could mencoder and mplayer else support this feature ?

>iam planning to restart my vfwext project, which adds aditional (but
>backwards compat) functionality to vfw. whilst this is not a perfect
>solution, it is acheivable. i think uci was too optimisitic; developing
>a generic audio/video api, discovery frame work and configuration
>enumeration, is a lot of work... then again, ffmpeg does this reasonably
>well.-- pete
>
Good to hear you are planning to come up with a better solution here, 
and if its an extention to the current system its maybe much easier to 
implement into existing applications ?

I had a lot of discussion with the Gstreamer guys about such an API, 
especially with Erik Waltinsen, the Gstreamer founder, and Thomas van 
der Stichelen. He told me he has the concept of such an API in his head 
already, based on the Gstreamer API but in a compact version that will 
not require Gstreamer as platform but can be self contained in a simple 
library. He just has no time at all to document it, leave alone to code 
the lib. Erik is a great guy, and if anybody knows about making a good 
codec/multimedia API its the Gstreamer guys, believe me ;) .... maybe 
one day i can motivate him to sit down and bring his thoughts to a piece 
of paper or whatever, and i am convinced by then the pressure to get rid 
of VfW will be high enough so that a few intelligent heads can sit down 
and make the 'Core Codec API' ( CCA ), of course hosted on corecodec.org 
;) ....

BTW, if your project needs administration or even coding support, or if 
you would like to have it hosted on corecodec.org ( there are some 
advantages compared to sourceforge, i will gladly point them out if you 
were interested ), just gimme a shout.

Christian
http://www.matroska.org



More information about the XviD-devel mailing list