On Tue, Apr 15, 2014 at 09:54:58AM +0200, Niels Möller wrote: > [email protected] (Niels Möller) writes: > > > 1. Do the msb/lsb reassembly. > > I've done this now (it's underspecified in some cases, in particular, > the parsing of lsbs in the case nuFixedLSBWidth > 0 seems not specified, > but that's for later, I think).
It would be nice if someone documented which parts of DTS spec are lacking, uninformative or outright lying. > > 2. Figure out how to actually generate any output to the codec user, and > > do any needed channel permutation. > > My current code processes the entire xll "asset" sequentially, from the > first header to the reconstructed samples for all channel sets. I think > this needs to be reorganized. The right way is probably to let the > functions invoked via dca_exss_parse_header parse the header only. I.e., > xll header, channel set headers, and the navi table. > > Later on, *after* the core channels are decoded, go back, iterate over > the channels set headers, and use the navi table to get to the right > data to parse and decode. I'd have to also store the offset of the start > of the data, but that should be no big deal. > > So I have two immediate questions: > > * What's the right way to do random access for the GetBitContext > (s->gb)? I suspect it's better to use new context initialised to some start position (you can simply copy it from known GetBitContext) and seek to some given position from it. > * Where's the actual output data stored? I'm a bit lost with these > frame->buf, frame->data, frame->extended_data, ff_get_buffer, > av_samples_fill_arrays, ... (type*)frame->extended_data[channel] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
