MKV Reader/Writer SDK?

[Dan203]

Hey, I'm Dan and I work as a developer on a video editing app called VideoReDo. We're currently investigating the possibility of adding MKV support to our application. I've looked at the official libs provided by the project but they're pretty complicated and poorly documented. So before I dive into trying to use them I thought I'd look around for a simpler SDK of some sort. However I can't seem to find one. Does anyone know of any MKV SDKs (free or commercial) other then the official libs provided by the project?

I know there are a couple of developers with other commercial SDKs who hang out on these forums, so if any of them happen to read this here is what I need... It has to be low level (not DirectShow), it has to have the ability to accurately seek to a specific point within the video, it has to provide accurate time stamps for every frame/sample, it has to support input and output of multiple audio and subtitle streams, and it has to have a clear, well documented, API which will allow us to add MKV support quickly. (the main reason I'm trying to avoid the official libs)

Anyway if anyone knows of anything that might help us out please let me know.

Thanks,
Dan

[Dmitry Vergheles]

Hi Dan,

We are making MKV Splitter/ Muxer for the same purposes as yours (as we are competitors at video editing market)

If DirectShow would be suitable for you we can license VideoRedo our solutions, and implement those features that you need.

beta version MKV editing with seeking and playback, based on our components is available in this Splitter version:
http://solveigmm.com/files/SolveigMM_Video_Splitter_2_3_beta.zip

[TheFluff]

I don't think there are any existing "simple" MKV writing libraries that aren't DirectShow. There's Haali's muxer, which is used here and there by various stuff, but it is DirectShow-based. If you do find one, please let me know. :V

As for demuxing, Haali's BSD-licensed C library (matroskaparser.c) is very reliable and easy to use. It doesn't really have an official distribution URL, but a copy can be found at http://code.google.com/p/ffmpegsource/source/browse/trunk/src/core (the relevant files are matroskaparser.[ch] and stdiostream.[ch]). You can also email Haali directly to get a copy.

[kieranrk]

FFmpeg is also an option.

[TheFluff]

Muxing MKV with ffmpeg is a Bad Idea.

[Dan203]

We are making MKV Splitter/ Muxer for the same purposes as yours (as we are competitors at video editing market)

If DirectShow would be suitable for you we can license VideoRedo our solutions, and implement those features that you need[/url]

Sorry but DirectShow does not work well for us. If you guys are planning on releasing a low level SDK we'd definitely be interested in that though.

Muxing MKV with ffmpeg is a Bad Idea.

Why? I was actually in the process of investigating if ffmpeg would work for our needs since we already use it in the product for EAC3 decoding. (French TV uses it for some reason) If there is something inherently wrong with it's MKV implementation then I wont even bother considering it.

Dan

[Dark Shikari]

If there is something inherently wrong with it's MKV implementation then I wont even bother considering it.
I haven't had any problems with it personally.

By the way, this EAC3 sample (http://www.mediafire.com/?3755e4cyy4194k9) crashes your TV Suite.

<plug>Also, considered using x264 for Videoredo? It's probably quite a bit cheaper (and better) than Mainconcept...</plug>

[Dan203]

By the way, this EAC3 sample (http://www.mediafire.com/?3755e4cyy4194k9) crashes your TV Suite

Can you please send me an email with that link to support @ videoredo.com. I need an official record of it to put it into our support system.

<plug>Also, considered using x264 for Videoredo? It's probably quite a bit cheaper (and better) than Mainconcept...</plug>

We actually have. However last time we checked the commercial license for x264 wasn't available yet. Is it ready now?

As for the topic at hand.... I found a document online which explains the MKV format a lot better then the official website. Having read through it I'm more confident in my ability to write my own demuxer/muxer if push comes to shove. Although a simple SDK would still be ideal.

Dan

[Dark Shikari]

Can you please send me an email with that link to support @ videoredo.com. I need an official record of it to put it into our support system.Done.

We actually have. However last time we checked the commercial license for x264 wasn't available yet. Is it ready now?Yup, see the website CoreCodec has set up (http://www.x264licensing.com). You can email info@x264licensing.com to get started.

As for the topic at hand.... I found a document online which explains the MKV format a lot better then the official website. Having read through it I'm more confident in my ability to write my own demuxer/muxer if push comes to shove. Although a simple SDK would still be ideal.For reference, you could check out Handbrake; it uses a relatively standard muxer library (I forgot which one), but it should be a good starting point. x264 uses its own custom muxer, which is pretty straightforward (Haali wrote it) and might be useful to look at if you're writing your own.

For reading MKVs, most applications use libavformat because they read nearly everything through libavformat already.

[TheFluff]

Why? I was actually in the process of investigating if ffmpeg would work for our needs since we already use it in the product for EAC3 decoding. (French TV uses it for some reason) If there is something inherently wrong with it's MKV implementation then I wont even bother considering it.

There's nothing really inherently wrong with it as far as I know, it just seems incredibly buggy. I tried remuxing some random mkv files I had sitting around on my computer with it, and it produces broken output (files that can't be read by applications that could read the original file) with about two thirds of them. It strips attachments, does not appear to support subtitles and just messes things up in general. Remuxing the output again with mkvmerge usually fixes it, though, so I think it doesn't really write invalid output, just unconventional.