[FFmpeg-devel] [PATCH] dca: export profile information on decode

[Anssi Hannula]

On 27.12.2010 19:06, Kostya wrote:
> On Mon, Dec 27, 2010 at 06:46:24PM +0200, Anssi Hannula wrote:
>> On 27.12.2010 17:41, Kostya wrote:
> [...]
>>> And mind you, that HD header contains all extensions information coded
>>> as flags, though it may be still easier to search for synccodes ;)
>>
>> Well, I'd rather use the active extensions bitfield to avoid any false
>> positives (as I don't skip the extension payloads as I don't know the
>> extension header formats), but I didn't manage to parse it correctly. I
>> can take another look, though. Do you have any information about the
>> format/location of the active extensions bitmask? (to rule out any
>> mistakes on my part)
> 
> IIRC, HD block structure is the following:
> 
> HD header
> 1-4 asset headers
> asset 1 data
> asset 2 data
> ....

Yep.

> This is all described in DTS-HD decoder substream interface document,
> it's proprietary+confidential ^TM but maybe someone can pirately provide
> you with a copy. The main PITA is that this information is stored after
> mixing info, so you have to parse quite a lot, sometimes in non-trivial
> way.

Duh, indeed I don't have enough information about the format to parse
beyond the mixing info.
I thought it was the masks right after asset count, but that seems to be
something else.

I'll go with the scanning approach then for now at least (actually, not
much scanning is involved in most files as we immediately encounter
XBR/XLL in most cases after which we know everything we wanted to know).

>> Hmm, and are those bitmasks provided on a per-asset basis?
> 
> Of course. Though it may be missing because there are four asset
> types:
> 0 - ordinary, extension mask present since that's the only case where
> it's needed
> 1 - LBR (low bitrate stuff, I guess nobody cares about it) only

Well, IMO it is the most interesting as it is the only widely used (e.g.
comment tracks / DTS Express) DTS format we can't decode at all (since
it has no core).

> 2 - XLL (lossless) only
> 3 - aux codec (yes, you can put some other codec like AC3 inside HD
>     frame this way)
> 
> [...]
>>>
>>> I meant this flow:
>>> 1) determine HD frame position (from core frame length + size checks)
>>> 2) if HD is present -> set profile to DTS_HD
>>
>> Well there was no DTS_HD profile in the initial proposal. To get the
>> distinct DTS_HD types, I guess one should add
>>
>> 2.5) search the DTS_HD frame for extensions (or look at the bitmask if
>> possible), and upgrade profile accordingly
> 
> as you like
> 
>>> 3) else do steps 4-5
>>> 4) set profile to DTS_CORE
>>> 5) search in core frame for XCh and X96 extensions, if found, upgrade
>>>    profile to DTS_ES or DTS_96_24
>>>
>>> Or, alternatively, you can reuse asset flags system just to signal what
>>> extensions are present (0x1 -> core, 0x10 -> core in HD frame,
>>> 0x200 -> lossless, etc).
>>
>> Yep. As I said above, though, I'd prefer to not make profile a bitfield
>> (I consider profiles to be defined collections of settings / encoding
>> methods, not a variable that tells every aspect of the bitstream format).
> 
> Personally I think there are only two profiles - fully decoded by lavc
> and not :) but I recognise other people's needs.
>  
>>> And let's wait for word from other DTS maintainer.
>>
>> Ah, the more opinions the better :)
> 
> Opinions based on some knowledge at least.

-- 
Anssi Hannula