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

[Anssi Hannula]

On 27.12.2010 17:41, Kostya wrote:
> On Mon, Dec 27, 2010 at 01:09:33PM +0200, Anssi Hannula wrote:
>> On 27.12.2010 11:46, Kostya wrote:
>>> On Mon, Dec 27, 2010 at 04:51:06AM +0200, Anssi Hannula wrote:
>>>> ---
>>>> This patch makes the dca decoder provide profile information of the
>>>> stream, so that users can easily differentiate between the DTS types.
>>>>
>>>> Couple of things related to this I'm not sure of:
>>>> - The values of the profile #defines. In this patch I put them into an
>>>>   approximate order of quality, with space in between for future
>>>>   profiles. Is this OK, or should I just make them sequential from 0?
>>>
>>> I'd rather not do it this way - first, one should detect HD part in
>>> frame ( which is easy) and divide profile into HRA or base, then if needed
>>> scan core part for X96k/XCh/XXCh extensions and set profile according to
>>> that. HD part has too complex structure - it may contain several
>>> substreams (or ass-ets as they call it), each one with its own
>>> capabilities. So unless you can parse it properly better not touch it at
>>> all.
>>
>> Well, my main motivation for this patch is to provide end applications
>> some way of detecting core-only/HRA/MA cases, so that they can show the
>> type to the user and decide whether to use full passthrough / pass core
>> only / whatever, so I'd really like the HD type to be shown here (the
>> ES/96_24 types were just a bonus).
>>
>> I believe I could parse the HD header more thoroughly, separating the
>> assets, and then only look at the first asset. Would that be OK for you?
> 
> Yes, though I'm just grumbling.
> 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)

Hmm, and are those bitmasks provided on a per-asset basis?

>> Also, what exactly do you mean by dividing profile?
>>
>> Something like this?
>>
>> #define FF_PROFILE_DTS_CORE    0x00ff
>> #define FF_PROFILE_DTS_BASE    0x0001
>> #define FF_PROFILE_DTS_ES      0x0002
>> #define FF_PROFILE_DTS_96_24   0x0003
>>
>> #define FF_PROFILE_DTS_HD      0xff00
>> (#define FF_PROFILE_DTS_EXPRESS 0x0100)
>> #define FF_PROFILE_DTS_HD_HRA  0x0200
>> #define FF_PROFILE_DTS_HD_MA   0x0300
>>
>> My idea was to have a generic profile value that would provide the user
>> a basic idea of the quality / used encoding method, instead of exporting
>> too much information about the used extension packets in the bitstream
>> or their location. Or is that what you wanted? i.e. should we provide
>> exact information about the used extension types (in a bitfield) instead
>> of using the high-level profile names?
>> IMHO that would complicate the simple use case too much for little
>> benefit, but I'm ok with that if that is what you want.
> 
> 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

> 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).

> And let's wait for word from other DTS maintainer.

Ah, the more opinions the better :)

>> Thanks for your quick reply.
>>
>> -- 
>> Anssi Hannula


-- 
Anssi Hannula