[gst-devel] Alternative solution for ASF demuxing

[Juho Vähä-Herttua]

Hi,

I am writing this just to mention what I've been doing lately and maybe
hear some comments if someone has any. So don't hesitate to give opinion
if you have one.

I am mainly active in the XMMS2 music player project that is not
directly related to gstreamer in itself. However a major problem that we
came across when developing support for wma playing was the lack of good
ASF demuxer library. After checking the source code of mplayer, ffmpeg,
xine, gstreamer and VLC and noticing they all have a different ASF
demuxer and all lack the required abstractions (except libavformat that
SUCKED), I started writing a new one and it is getting closer to being
finished.

The resulting library is libasf, licensed under LGPL with C89 and based
somewhat on VLC implementation, although it is written from scratch. It
has been tested widely on little-endian and big-endian machines and
different operating systems with XMMS2, including the embedded OSD
project Neuros. In my personal biased opinion the code quality is quite
good and there hasn't so far been bugs that couldn't have been fixed in
a few hours. It also does zero allocations and memcopys doing the
reading process after the buffers have been initialized to correct size
first, so it is pretty lightweight in that sense. Valgrind has been also
heavily used during testing...

Now I'm just asking would anyone be interested in using this library
outside of XMMS2 like in gstreamer? It doesn't do any muxing so it can't
totally replace all the ASF stuff in gstreamer. But in my opinion
centralizing the fragmented ASF demuxer codebase wouldn't hurt, myself I
have been writing a proof-of-concept video demuxer for VLC so far. I'm
aware of the regressions and that probably none of the "old" projects
want to do this big changes, but it's better to let everyone know the
options.

And for people who read this far, the current source can be found in
http://code.google.com/p/libasf/ and can be compiled with no
dependencies whatsoever. I haven't cared about patents as haven't other
implementations either apparently, but all copyright issues are
addressed.


Regards,

Juho Vähä-Herttua