There are two tricks to make VC1 decoding work: 1) VC1 sequence and entry point headers must be present in context->extradata. 2) video width and height must be known when opening decoder. Some container formats store required extra data, but mpeg-ts does not. 1) is fixed by scanning the stream for headers and discarding all data until proper headers are found. 2) is fixed by re-opening decoder with width and height information from first open.
This adds the following functionality: * Read segment title and uses that for display in a UI There is an issue when the file does not specify a segment title. It will then fall back to a generic "(No title)", since I could not find a way to retrieve the file name the player shows. * More implementation files Added: - demux_matroska.h - demux_matroska_chapters.h This breaks the OO-ish C visibility a bit, since there need to be public (i.e. non-static) interfaces between the units. * Chapter Handling I did a rough initial implementation of Matroska's "editions" system. The demuxer will parse all editions from the header, and for each edition the top level of chapters. This is not quite the full spec as Matroska intends, but it should work fine as long as there is only a single edition and all editions/chapters only reference only one (the first and only) segment in the stream, and are supposed to apply to all tracks therein. When the stream has chapters, the demuxer will now handle skip events from the player to jump between chapters.
Using bitmeter, I found that xine's jack output suffers from the problem mentioned at the bottom of bitmeter's home page. "Although JACK itself works entirely with IEEE floating point values the conversion to and from analog audio uses integers, as do popular audio storage technologies like DAT and Red Book CDs. For correct operation JACK software which uses such integers should use the same conversion ratios as JACK itself. e.g. 16-bit samples should be divided by exactly 32768. A common mistake is to choose the value 32767 instead. You can't hear this, or see it with ordinary meters, but the bitmeter shows a clear signature for audio processed in this way. The 8th bit of the mantissa (counting the rightmost as the 0th) is orange, indicating that an unusually high percentage of samples have this bit set." (from http://users.ecs.soton.ac.uk/njl98r/code/audio/bitmeter/ via Google cache)
start_pos is of type off_t, and since we compile with D_FILE_OFFSET_BITS=64, -off_t is a 64-bit long long int, so you'd think we'd be fine here -- but we aren't, because start_time, this->duration and this->frame_size are all 32-bit ints, which means that the computed seek position gets truncated to 32 bits before it's assigned to start_pos. The simple solution is to cast start_time to off_t, expanding the computation to 64 bits in time to avoid truncation.