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

[Anssi Hannula]

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?

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.

Thanks for your quick reply.

-- 
Anssi Hannula