Re: [Libquicktime-devel] New Demultiplexing mode

[Burkhard P. <pl...@ig...>]

Erik Johansson wrote
> Hi,
>
>> Of course we can think of exporting the index information somehow in the
>> public API.
>
> That would be nice.
>
>>> While on the topic of indexes... I've lately come across a few files
>>> from different sources that makes use of multiple entries in the stsd
>>> sample descriptions. For these files, it is also necessary to keep
>>> track of the 'description' entry in the stsc table. I guess that will
>>> require one more filed in the lqt_packet_index_entry_t struct,
>>
>> That can be added.
>>
>>> among
>>> other changes.
>>
>> And these would be a LOT. In the worst case it means to change *all*
>> stream
>> parameters (image size, codec, colormodel....) in the middle of the
>> file.
>
> Indeed. Would it make sense to add a 'raw' reading mode to the
> library? For most files, we use libquicktime to demux and extract
> essence, which is then decoded using various SDKs.

We already have lqt_read_audio_packet() and lqt_read_video_packet(),
but these are only supported for codecs which are well defined also
outside of quicktime files.

On the other hand, if the packet index is available in the public API,
the raw "reading" simply means fseek() and fread(), which can be done
without the help of the library.

> Two loose thoughts
> / observations;
> - The required changes to support multiple stsd entries would be more
> limited if reading in raw mode

Exactly. The only thing we need to do is to export all stsd entries.

> - Currently quicktime_open() tries to decode essence using the plugins
> to determine colormodels, which is unnecessary for the raw reading
> scenario (and sometimes produces error messages).

That could be avoided by obtaining the stream colormodel only when the user
asks for it (i.e. triggered by a call to lqt_get_decoder_colormodel()).

Burkhard