[Matroska-devel] [mosu] r3916 - in trunk/prog/video/mkvtoolnix/src: common output

[Steve Lhomme]

Moritz Bunkus wrote:
> Hey Steve,
> 
> On Saturday 20 September 2008 16:47, Steve Lhomme wrote:
> 
>> Can you update the Matroska website codec page with info about how VC1
>> is muxed in matroska ?
> 
> I'll do that once muxing is complete; madshi is giving me a lot of help
> on Doom9 at the moment how he and Haali implemented VC1 muxing. It's MS
> compatibility mode though. Anyway, it works.
> 
>> Also can you modify my email for your SVN commit notifications to
>> slhomme at matroska.org ?
> 
> Done.

Thx

>> Thx (and good job !)
> 
> Thanks :)
> 
>> PS: I've started rewriting libebml/libmatroska in C. read/write mostly
>> works (no block yet). In the coming weeks I'll try to "port"
>> mkvtoolnix to these libs, at least to verify they produce the same
>> result. The API is similar to the old C++ lib. And I plan to make a
>> C++ wrapper to mimic the old API (and another wrapper to mimic Haali's
>> code).
> 
> Sounds good. However, this will be a difficult job because all of
> mkvtoolnix is heavily using libebml and libmatroska. But it should be
> possible :)

Well, that's why I'll make a C++ wrapper that should be 100% compatible 
with the v1 libraries. So on the mkvtoolnix the changes should be 
minimal, if any. That's to validate the new code. After that we can see 
how mkvtoolnix could benefit from using the lower C layer... While 
writing the code I also saw plenty of possibilities of optimizations, 
that will come later. The new lib is also BSD licensed to the Matroska 
Foundation. That should ease the adoption. (HW manufacturers are 
currently turning to Haali's splitter)

One of the goals is to make it work in CorePlayer. Right now EBML it's 
used to store/restore a "database" of SSL certificates and it's working 
well. Later we plan to have a mkv muxer in there to do things like 
streaming (think UPNP, or DivX Connected). And maybe also for storing 
A/V files in a cache (like progressive downloads) of formats with no 
container (like RTSP streams). We may borrow some code for mkvtoolnix, 
maybe not. We already have all kinds of demuxers in the player (mostly 
the same as you plus ASF, FLV) so we probably won't need that part. 
Maybe packetizers...

One of the benefit of the new lib is that it uses a small C layer called 
Core-C that adds portability and object oriented syntax to C. That's the 
foundation on which CorePlayer is built. And it runs on big/little 
endian, windows, CE, Linux, symbian, palm, OS X, iPhone, PS2. So maybe 
mkvtoolnix could make use of it and our build system (coremake) to be 
more portable. It also has a lot of built-in code that replaces a lot of 
your outside dependencies.

http://coreforge.org/projects/corec/
http://coreforge.org/projects/coremake/
https://services.corecodec.com/svn/matroska/trunk/foundation_src/

Steve