libquicktime-devel

[Libquicktime-devel] Delay determination of decoder colormodel

[Erik J. <eri...@gm...>]

Hi,

As mentioned in another thread on the list, quicktime_open() currently
uses libquicktime plugins to decode a frame to determine the decoder
colormodel (stream_cmodel). This occasionally causes error messages
for files that the ffmpeg plugin tries, but fails, to decode. If the
essence is decoded outside of libquicktime, this step is unnecessary.
The attached patch delays the determination of the decoder colormodel
until it is actually needed.

Kind regards,
Erik

Re: [Libquicktime-devel] Delay determination of decoder colormodel

[Erik J. <eri...@gm...>]

I realise I had omitted the initialisation of the stream_cmodel
variable in my patch. My apologies - attaching an updated patch.

// Erik

On Tue, Apr 29, 2014 at 12:28 PM, Erik Johansson
<eri...@gm...> wrote:
> Hi,
>
> As mentioned in another thread on the list, quicktime_open() currently
> uses libquicktime plugins to decode a frame to determine the decoder
> colormodel (stream_cmodel). This occasionally causes error messages
> for files that the ffmpeg plugin tries, but fails, to decode. If the
> essence is decoded outside of libquicktime, this step is unnecessary.
> The attached patch delays the determination of the decoder colormodel
> until it is actually needed.
>
> Kind regards,
> Erik



-- 
Erik Johansson
Barkvägen 10A
SE-541 64 Skövde, Sweden
Mobile: +46 (0)73 707 94 94
LinkedIn | YouTube | Google+ | Facebook

Re: [Libquicktime-devel] Delay determination of decoder colormodel

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

Hi,

Am 29.04.2014 15:55, schrieb Erik Johansson:
> I realise I had omitted the initialisation of the stream_cmodel
> variable in my patch. My apologies - attaching an updated patch.

I implemented it a bit differently:
A private function lqt_ensure_stream_cmodel_decode() is called from
all functions, which use the colormodel. Can you check if that works for you?

Burkhard

Re: [Libquicktime-devel] Delay determination of decoder colormodel

[Erik J. <eri...@gm...>]

Hi Burkhard,

> I implemented it a bit differently:
> A private function lqt_ensure_stream_cmodel_decode() is called from
> all functions, which use the colormodel. Can you check if that works for you?

That is a lot cleaner, thanks. Works ok in my test, which also served
as a reminder that my local build of the library is starting to lag
quite a bit behind the current CVS. Thanks for your efforts here!

Different issue: Could we have a max_stsd_index (or equivalent) in
lqt_packet_index_t too?

Thanks
// Erik

Re: [Libquicktime-devel] Delay determination of decoder colormodel

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

Hi,

Am 06.05.2014 10:26, schrieb Erik Johansson:
> Hi Burkhard,
>
>> I implemented it a bit differently:
>> A private function lqt_ensure_stream_cmodel_decode() is called from
>> all functions, which use the colormodel. Can you check if that works for you?
>
> That is a lot cleaner, thanks. Works ok in my test, which also served
> as a reminder that my local build of the library is starting to lag
> quite a bit behind the current CVS. Thanks for your efforts here!

Good.

> Different issue: Could we have a max_stsd_index (or equivalent) in
> lqt_packet_index_t too?

That would be the same as stsd->total_entries, right?

I won't use or support multiple sample descriptions per track. But
I wonder that if one would use it, we'd need to export the stsd atom for the
public API anyway, or not?

Burkhard

Re: [Libquicktime-devel] Delay determination of decoder colormodel

[Erik J. <eri...@gm...>]

On Tue, May 6, 2014 at 5:36 PM, Burkhard Plaum
<pl...@ig...> wrote:
>> Different issue: Could we have a max_stsd_index (or equivalent) in
>> lqt_packet_index_t too?
>
> That would be the same as stsd->total_entries, right?

Yes, it's the same.

> I won't use or support multiple sample descriptions per track. But
> I wonder that if one would use it, we'd need to export the stsd atom for the
> public API anyway, or not?

To add partial support for multiple stsd entries I've hacked, wrapped
and exposed a version of quicktime_stsd_get_user_atom() that takes a
parameter for the stsd entry I'm looking for. But clearly, that is
insufficient for e.g. resolution changes. Exposing the entire stsd
atom would allow support for multiple sample descriptions per track
without having to modify the library, so would be a good way forwards
for my needs.

Thanks
// Erik