[FFmpeg-devel] [RFC/PATCH] matroska demuxer doesn't decode the zlib encoding on vobsubs

[Måns Rullgård]

Aurelien Jacobs wrote:
> M?ns Rullg?rd wrote:
>
>> Aurelien Jacobs <aurel at gnuage.org> writes:
>>
>> > elupus wrote:
>> >
>> >> Hi,
>> >>
>> >> Currently the vobsub data coming out of lavf, is zlib encoded, and
>> >> can't be fed directly into lavc's dvd demuxer, even thou the
>> >> codec_id matches.
>> >>
>> >> This "patch" decodes the zlib encoding. It's uggly and hackish, so
>> >> not intended to be included in ffmpeg. It's mainly for discussion,
>> >> and for anybody that needs vobsub support from lavf.
>> >>
>> >> Apperently any track in matroska can be either zlib or lzo
>> >> compressed. (i'd assume there might be others). mplayer's matroska
>> >> demuxer handles this, but lavf doesn't currently.
>> >>
>> >> Would be nice to see support for this in ffmpeg's demuxer too. I
>> >> doubt i'll work on it much more, but maybe this could get some
>> >> mplayer dev going adding support since they want to get away from
>> >> their own demuxers and use lavf's instead :)
>> >
>> > That's something I wanted to add since quite some time.
>> > But I was waiting for M?ns native zlib decoder to be commited.
>> > I hope this will happen soon.
>> > When native zlib is in, I will cleanup this patch to use it,
>> > and commit.
>>
>> Why can't you use system zlib in the meantime?  The dependency is
>> already there anyway.
>
> Sure, I could (maybe I will). I just wasn't very motivated to use
> it when something more exciting was around the corner.

Do these compressed blocks have a zlib header, or are they raw compressed
data?  If the former, you can use the uncompress() function of zlib.  If
not, the API can indeed be somewhat demotivating.

-- 
M?ns Rullg?rd
mans at mansr.com