[matroska-devel] Re: the road to 1.0 and beyond
suxen_drol at hotmail.com
Thu Jun 26 10:35:07 CEST 2003
On Thu, 26 Jun 2003 00:56:41 +0200 ChristianHJW <christian at matroska.org>
> P.S. Pete 'Suxendrol' from the XviD team told me about an extension to
> the VfW API he has planned to allow more advanced features that current
> VCM codec API doesnt allow, but then again we had only a solution for
> Windows, and not a real x-platform opensource API ..... what do you all
> think ?
yea i have lots of plans, and that vfwext was proposed some >15 months
ago. recently i did experiment with some extension to make the vfw
configuration window aware of the encoding fps and dimensions, but thats
developing such an api, framework or protocol is both easy and hard. it
depends on the scope your want to capture within that framework. the
issues surrounding frame-based encoding and decoding and encoding
are well known, and developing a small api to deal with it isn't very
hard (and that is what xine, mplayer & transcode have done). and i agree
with mike, and have said in the past, that ffmpeg sets a very good
problems arise when you consider features which dont easy fit in either
the codec or the application layer:
- configuration. how do we configure the codec? whw is responsible for
storing the configuration info, and what if we want to re-configure the
codec during the encoding or decoding (such as preprocessing)?
vfw has a configure command which display a gui configuration, and some
commands for getting/setting a "block" of the configuration memory.
uci & ffmpeg have enum/get/set functions for enumerating through
configuration options. mplayer has something similar.
- two-pass management. 2pass is neither a codec layer issue or an
application layer issue, it fits somewhere in between.
say i encode a complete first pass, but then want to encode only a
portion of that video in the second pass. presently with xvid and divx
you have to cut your 2pass stats files, and mess around external
scaling/analysis tools. external applications such as gordinaknot(win32)
help with this process, but they're not integrated.
ideally there would be some what to manage all this stuff, thats sits
between codec and application layer. to do this, we need to define what
data the codec must provide to such a "management layer". i believe this
is difficult, because 2pass is still somewhat unsailed waters.
- suspending/restoring codec state. the ability to suspend the encoder,
reboot and resume encoding at the same position.
- future: video codecs support multiple input streams (think: mp3 stereo).
and maybe someday video segmentation will emerge to be popular.
are you looking for immediate usefulness chris (run with what we know
about video codecs now), or some future-proof-ness (dwindle on future
More information about the Matroska-devel